Re: [bitcoin-dev] Three hardfork-related BIPs

On Friday, January 27, 2017 11:53:02 PM Andrew Johnson via bitcoin-dev wrote: > I don't think that the 17% yearly increase is too far off base considering > current global trends(although I still don't particularly like the idea of > centrally planning the limit, especially not that far into the

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

Oops, forgot to mention, in the "parent" (ie old) block header, we should: 1) fix the version field so its a static constant 2) swap first 2 bytes of the merkle root with the timestamp's two high-order bytes (preferably more, I'm not sure how much ASIC hardware has timestamp-rolling in it

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

Looks cool, though I have a few comments inline. One general note - it looks like you're letting complexity run away from you a bit here. If the motivation for something is only weak, its probably not worth doing! A hard fork is something that must be undertaken cautiously because it has so much

Re: [bitcoin-dev] Extension block softfork proposal

Hey Johnson, As you know I've always been a rather large critic of this approach. First a bit of background. Pieter's excellent post on the security of soft forks [1] covers pretty well why soft forks are preferable to hard forks by debunking much of the "soft forks are less secure" arguments.

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Johnson, It's actually clear from your original post - you treat "all zeros" in a special way - as the equivalent of all ones. The semantics match the impression I got originally. Sorry we got sidetracked. ___ bitcoin-dev mailing list

Re: [bitcoin-dev] Three hardfork-related BIPs

On Fri, Jan 27, 2017 at 03:47:20PM -0500, Greg Sanders via bitcoin-dev wrote: > Note that the 4MB number comes from a single network metric. > > Quotes directly from the paper in question: > http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf > > >Our results hinge on the key metric of effective

Re: [bitcoin-dev] Three hardfork-related BIPs

Note that the 4MB number comes from a single network metric. Quotes directly from the paper in question: http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf >Our results hinge on the key metric of effective throughput in the overlay network, which we define here as which blocks propagate within an

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

> On 26 Jan 2017, at 03:32, Tom Harding wrote: > > On 1/24/2017 8:03 PM, Johnson Lau wrote: >> it seems they are not the same: yours is opt-out, while mine is opt-in. > > I missed this. So in fact you propose a self-defeating requirement on the > new network, which would

[bitcoin-dev] Consensus critical limits in Bitcoin protocol and proposed block resources limit accounting

There are many consensus critical limits scattered all over the Bitcoin protocol. The first part of this post is to analyse what the current limits are. These limits could be arranged into different categories: 1. Script level limit. Some limits are restricted to scripts, including size (1

Re: [bitcoin-dev] Three hardfork-related BIPs

On Jan 27, 2017 03:03, "Andrew Johnson via bitcoin-dev" wrote: Other researchers have come to the conservative conclusion that we could handle 4MB blocks today. I believe this is a mischaracterization of the research conclusions. The actual conclusion

Re: [bitcoin-dev] Three hardfork-related BIPs

Regarding #1, I agree with Johnson Lau and others who have responded since then—this proposal is not appropriate and should not be adopted for the following reasons: 1. Miners will view it as way too little, delivered way too late. And as soon as you say 300kb blocks, you've lost them all. 2.

Re: [bitcoin-dev] Three hardfork-related BIPs

Your BIP implementation should stress the capacity to softfork the rate of blocksize increase if necessary. You briefly mention that: *If over time, this growth factor is beyond what the actual technology offers, the intention should be to soft fork a tighter limit.* However this can work both

Re: [bitcoin-dev] Three hardfork-related BIPs

On Jan 26, 2017 10:15 PM, "Luke Dashjr" wrote: On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote: > Comment on #1. You're dropping the blocksize limit to 300KB and only > reaching the limit that we have in place today 7 years later? The limit only drops all the way