Re: [bitcoin-dev] Segregated Witness features wish list

1. I think we should limit the sum of the block and witness data to nBlockMaxSize*7/4 per block, for a maximum of 1.75 MB total. I don't like the idea that SegWit would give us 1.75 MB of capacity in the typical case, but we have to have hardware capable of 4 MB in adversarial conditions (i.e.

Re: [bitcoin-dev] Segregated Witness features wish list

Off-topic: If you want to decentralize hashing, the best solution is probably to redesign p2pool to use DAGs. p2pool would be great except for the fact that the 30 sec share times are (a) long enough to cause significant reward variance for miners, but (b) short enough to cause hashrate loss

Re: [bitcoin-dev] Segregated Witness features wish list

Jannes Faber via bitcoin-dev writes: > Segregated IBLT > > I was just wondering if it would make sense when we have SW to also make > Segregated IBLT? Segregating transactions from signatures and then tune the > parameters such that transactions have a

Re: [bitcoin-dev] Segregated Witness features wish list

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm trying to list the minimal consensus rule changes needed for segwit softfork. The list does not cover the changes in non-consensus critical behaviors, such as relay of witness data. 1. OP_NOP4 is renamed as OP_SEGWIT 2. A script with

Re: [bitcoin-dev] Segregated Witness features wish list

On Sun, Dec 13, 2015 at 4:25 PM, jl2012--- via bitcoin-dev wrote: > I'm trying to list the minimal consensus rule changes needed for segwit > softfork. The list does not cover the changes in non-consensus critical > behaviors, such as relay of witness data.

Re: [bitcoin-dev] Segregated Witness features wish list

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pieter Wuille 2015-12-13 13:07 : The use of a NOP opcode to indicate a witness script was something I considered at first too, but it's not really needed. You wouldn't be able to use that opcode in any place a normal opcode could occur, as it

Re: [bitcoin-dev] Segregated Witness features wish list

Segregated IBLT I was just wondering if it would make sense when we have SW to also make Segregated IBLT? Segregating transactions from signatures and then tune the parameters such that transactions have a slightly higher guarantee and save a bit of space on the signatures side. IBLT should of

Re: [bitcoin-dev] Segregated Witness features wish list

On Thu, Dec 10, 2015 at 6:47 AM, jl2012--- via bitcoin-dev wrote: > 4. Sum of fee, sigopcount, size etc as part of the witness hash tree: for I should have also commented on this: the block can indicate how many sum criteria there are; and then additional

Re: [bitcoin-dev] Segregated Witness features wish list

On Thu, Dec 10, 2015 at 6:47 AM, jl2012--- via bitcoin-dev wrote: > It seems the current consensus is to implement Segregated Witness. SW opens > many new possibilities but we need a balance between new features and > deployment time frame. I'm listing by my

Re: [bitcoin-dev] Segregated Witness features wish list

Note that the unused space in coin base input script allows us to soft-fork an additional SW Merkle tree root into the design, therefore please make sure the new SW data structure also has a new slot for future extension. Tamas Blummer ___

[bitcoin-dev] Segregated Witness features wish list

It seems the current consensus is to implement Segregated Witness. SW opens many new possibilities but we need a balance between new features and deployment time frame. I'm listing by my priority: 1-2 are about scalability and have highest priority 1. Witness size limit: with SW we should