I've been tossing around an idea in my head that involves time-locked
encryption [0] and I wondered what the devs here think about it. In a
nutshell: the timechain is a serial chain of time-lock encrypted GPG keys
at N minute intervals (meaning that it requires N minutes to decrypt a
single link /
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/02/2015 04:03 AM, Mike Hearn wrote:
(...)
>
> If you really believe that decentralisation is, itself, the end,
> then why not go use an "ASIC resistant" alt coin with no SPV or web
> wallets which resembles Bitcoin at the end of 2009? That'd b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm way late to this one, I guess, but adding some thoughts here... it
seems that anything which mitigates the problem of reuse should be to
the maximum extent possible, the user's option... if a person wants to
have an address that lasts forever they
Thanks Bryan for collating these links in one great list. This is very
helpful and thanks for sharing it.
Feel free to fork https://github.com/EthanHeilman/BlockSizeDebate
edit to add the list of proposals and create a pull request to Ethan.
There's also a miningconsensus.slack.com group to have
On Fri, Jun 12, 2015 at 1:04 PM, Eric Lombrozo wrote:
> Miners currently only collect an almost negligible portion of their
> revenue from fees.
Then they shouldn't care about the block size limit, since an increase in
block size (and thus in the number of txs they get fees from) will only
incr
On Friday, June 12, 2015 11:01:02 PM Vincent Truong wrote:
> RE: miner economics
> Miners who have an agenda can forego fees to achieve it and create their
> own txns if it is completely txn/user driven. It is better to just count
> miners votes and let the user votes be their backing.
Just simpli
(Sorry for spam, forgot to cc the mailing list)
RE: miner economics
Miners who have an agenda can forego fees to achieve it and create their
own txns if it is completely txn/user driven. It is better to just count
miners votes and let the user votes be their backing.
Although miners need to inclu
Since everyone's busy, I went ahead and made a pull request to add this as
an informational BIP 79 to the bips directory.
https://github.com/bitcoin/bips/pull/157
Regards,
Kristov
On Tue, Jun 9, 2015 at 4:14 PM, Peter Todd wrote:
> On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote:
Miners currently only collect an almost negligible portion of their revenue
from fees. While I certainly welcome any proposals that move us in the
direction of defining a smooth metaconsensus process, I think with the
curent economics, miners (and especially those with significant hashing
power) ha
The `n` is the curve order, as shown here:
https://en.bitcoin.it/wiki/Secp256k1
This step is necessary to keep you on the curve. The
secp256k1_ec_privkey_tweak_add function from libsecp256k1 handles this
automatically, but if you use OpenSSL or some non-EC math library, you
probably have to do it
I'm imagining in Peter's proposal it's not the transaction votes that are
counted but only the votes in the blocks? So miners get to vote but they
risk losing money by having to exclude counter voting transactions. But
garbage transactions are no problem at all.
Note that users that want to cast a
Here are some proposals regarding the minimum block size questions, as well
as other related scalability issues.
Dynamic block size limit controller (maaku)
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html
https://www.reddit.com/r/Bitcoin/comments/35c47x/a_propo
For the purposes of finding the median, halve < same < double. It will only
change if a majority of non-apathetic votes are for halve or a majority of
non-apathetic votes are for double.
On Fri, Jun 12, 2015 at 11:54 AM, Matt Whitlock
wrote:
> On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrot
On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
> On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
> > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > > > Why should miners only be able to vote for
On Friday, 12 June 2015, at 7:44 pm, Peter Todd wrote:
> On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
> > On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > > > Why should miners only be able to vote for
Looking at the BIP32 definition, I hit a line that I would appreciate
clarification on.
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
Under the section "Private parent key → private child key" there is a step:
"The returned child key ki is parse256(IL) + kpar (mod n)."
Can some
On Fri, Jun 12, 2015 at 08:39:21PM +0200, Benjamin wrote:
> This is a misguided idea, to say the least. If such a mechanism of of
> user input would be possible, one would use it for transaction
> verification in the first place. In proof-of-stake outcomes are
> determined by vote by stake (that vo
On Fri, Jun 12, 2015 at 02:36:31PM -0400, Matt Whitlock wrote:
> On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> > On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > > Why should miners only be able to vote for "double the limit" or "halve"
> > > the limit? If you're going
This is a misguided idea, to say the least. If such a mechanism of of
user input would be possible, one would use it for transaction
verification in the first place. In proof-of-stake outcomes are
determined by vote by stake (that vote has very different
characteristics than vote by compute power).
If there is a benefit in producing larger more-fee blocks if they propagate
slowly, then there is also a benefit in including high-fee transactions
that are unlikely to propagate quickly through optimized relay protocols
(for example: very recent transactions, or out-of-band receoved ones). This
ef
On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote:
> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
> > Peter it's not clear to me that your described protocol is free of miner
> > influence over the vote, by artificially generating transactions which they
> > claim in th
On Friday, 12 June 2015, at 7:34 pm, Peter Todd wrote:
> On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> > Why should miners only be able to vote for "double the limit" or "halve"
> > the limit? If you're going to use bits, I think you need to use two bits:
> >
> > 0 0 = no p
On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote:
> Why should miners only be able to vote for "double the limit" or "halve" the
> limit? If you're going to use bits, I think you need to use two bits:
>
> 0 0 = no preference ("wildcard" vote)
> 0 1 = vote for the limit to
On Fri, Jun 12, 2015 at 01:21:46PM -0400, Gavin Andresen wrote:
> Nice work, Pieter. You're right that my simulation assumed bandwidth for
> 'block' messages isn't the bottleneck.
>
> But doesn't Matt's fast relay network (and the work I believe we're both
> planning on doing in the near future to
Sure, and you did indeed say that.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-developme
On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
> Peter it's not clear to me that your described protocol is free of miner
> influence over the vote, by artificially generating transactions which they
> claim in their own blocks
Miners could fill their blocks with garbage transaction
I'm merely proving the existence of the effect.
On Jun 12, 2015 8:24 PM, "Mike Hearn" wrote:
> are only connected to each other through a slow 2 Mbit/s link.
>>
>
> That's very slow indeed. For comparison, plain old 3G connections
> routinely cruise around 7-8 Mbit/sec.
>
> So this simulation is
>
> are only connected to each other through a slow 2 Mbit/s link.
>
That's very slow indeed. For comparison, plain old 3G connections routinely
cruise around 7-8 Mbit/sec.
So this simulation is assuming a speed dramatically worse than a mobile
phone can get!
-
Why should miners only be able to vote for "double the limit" or "halve" the
limit? If you're going to use bits, I think you need to use two bits:
0 0 = no preference ("wildcard" vote)
0 1 = vote for the limit to remain the same
1 0 = vote for the limit to be halved
Peter it's not clear to me that your described protocol is free of miner
influence over the vote, by artificially generating transactions which they
claim in their own blocks, or conforming incentives among voters by opting
to be with the (slight) majority in order to minimize fees.
Wouldn't it in
Jeff Garzik recently proposed that the upper blocksize limit be removed
entirely, with a "soft" limit being enforced via miner vote, recorded by
hashing power.
This mechanism within the protocol for users to have any influence over
the miner vote. We can add that back by providing a way for transa
On Fri, Jun 12, 2015 at 06:51:02PM +0200, Pieter Wuille wrote:
> The configuration used in the code right now simulates two groups of miners
> (one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected
> internally, but are only connected to each other through a slow 2 Mbit/s
> link.
>
>
Nice work, Pieter. You're right that my simulation assumed bandwidth for
'block' messages isn't the bottleneck.
But doesn't Matt's fast relay network (and the work I believe we're both
planning on doing in the near future to further optimize block propagation)
make both of our simulations irreleva
Hello all,
I've created a simulator for Bitcoin mining which goes a bit further than
the one Gavin used for his blog post a while ago. The main difference is
support for links with different latency and bandwidth, because of the
clustered configuration described below. In addition, it supports dif
Once the 75% threshold is reached, miners who haven't updated are at risk
of mining on invalid blocks.
If someone produces a version 3 block that violates the new rules, then
miners who haven't upgraded will end up wasting mining power building on
that block.
This could be used as an expensive wa
35 matches
Mail list logo
