Re: [bitcoin-dev] BIP draft: Extended block header hardfork

> On 3 Apr 2017, at 04:39, Russell O'Connor wrote: > > On Sun, Apr 2, 2017 at 4:13 PM, Johnson Lau via bitcoin-dev > > wrote: > • the witness of the first input of the coinbase transaction MUST > have exactly one stack item (the "extended

Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives

On Sun, Apr 2, 2017 at 1:43 PM, praxeology_guy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > TL;DR: using spentness bits scales linearly... vs swapping digest leafs > with empties can scale with logorithmically increasing storage > requirements. So if you are using a 32 byte h

Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives

TL;DR: using spentness bits scales linearly... vs swapping digest leafs with empties can scale with logorithmically increasing storage requirements. So if you are using a 32 byte hash and spentness bits, you are pretty much limited to only being able to prune 8 to 12 layers. This corresponds to

Re: [bitcoin-dev] BIP draft: Extended block header hardfork

On Sun, Apr 2, 2017 at 4:13 PM, Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > • the witness of the first input of the coinbase transaction MUST > have exactly one stack item (the "extended header"), with the following > data: > • bytes 0 to 3

[bitcoin-dev] BIP draft: Extended block header hardfork

This is the first of a series of BIPs describing my “spoonnet” experimental hardfork. Recently many bitcoin businesses expressed their requirements for supporting a hardfork proposal. While it is proven to be extremely difficult to obtain community-wide consensus, spoonnet fulfills all the commo

Re: [bitcoin-dev] High fees / centralization

Jared Lee Richardson via bitcoin-dev schreef op do 30-03-2017 om 19:01 [-0700]: > That would be blockchain sharding. > > Would be amazing if someone could figure out how to do it trustlessly. > So far I'm not convinced it is possible to resolve the conflicts > between the shards and commit transac

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Jared Lee Richardson via bitcoin-dev schreef op wo 29-03-2017 om 12:10 [-0700]: > The proportion of users believing in microtransactions for all is also > larger than 5%, In order to evaluate this statement the definition of microtransaction has to be defined. I guess there will also be no consens

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

Jared Lee Richardson via bitcoin-dev schreef op wo 29-03-2017 om 12:07 [-0700]: > > It is all very unhealthy for Bitcoin. Both sides need to accept that > microtransactions from all humans cannot go on-chain, and that never > increasing the blocksize doesn't mean millions of home users will run

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Just saying that we can talk in terms of weight alone after segwit. 8 mb weight is much more clear than 2 mb size to me. 2 mb size seems to obfuscate the actual new limit with the proposed hf, which simply 8 mb weight. On 2 Apr 2017 12:03 pm, "Natanael" wrote: > My point, if you missed it, is th

Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

My point, if you missed it, is that there's a mathematical equivalence between using two limits (and calculating the ratio) vs using one limit and a ratio. The output is fully identical. The only difference is the order of operations. Saying there's no blocksize limit with this is pretty meaningles