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 fro
I think people have a variety of sequences in mind, eg some would
prefer to deploy versionBits first, so that subsequent features can be
deployed in parallel (currently soft-fork deployment is necessarily
serialised).
Others think do seg-witness first because scale is more important.
Some want to
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.
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 slightly higher guarantee and save
> a bit of
-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 need
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.
>
> 1. OP_NOP4 is renamed as OP_SEGWIT
>
-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 OP_SEGW
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 co
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
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 ones could be soft-forked
in. Haven't tri
On Thu, Dec 10, 2015 at 12:47 AM, jl2012 wrote:
> 3. SIGHASH_WITHINPUTVALUE [1]: there are many SIGHASH proposals but this one
> has the highest priority as it makes offline signing much easier.
nhashtype proposal:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md
OP_CODESEP
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 priority:
> 2. Deployment time frame:
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 allo
13 matches
Mail list logo
