Chris Priest [ARCHIVE] on Nostr: 📅 Original date posted:2016-02-07 📝 Original message:Segwit requires work from ...
📅 Original date posted:2016-02-07
📝 Original message:Segwit requires work from exchanges, wallets and services in order for
adoption to happen. This is because segwit changes the rules regarding
the Transaction data structure. A blocksize increase does not change
the Transaction rules at all. The blocksize increase is a change to
the Block structure. Most wallets these days are Block agnostic.
Essentially, if a client has been built using a library that abstracts
away the block, then that client's *code* does not need to be updated
to handle this blocksize limit change. An example is any service using
the Bitcore javascript library. Any wallet built using Bitcore does
not need any changes to handle a blocksize upgrade. I have one project
that is live that was built using Bitcore. Before, during, and after
the fork, I do not need to lift a finger *codewise* to keep my project
still working. Same goes for projects that are built using
pybitcointools, as well as probably a few other libraries.
A wallet using Bitcore also has to work in tandem with a blockchan
api. Bitcore itself does not provide any blockchain data, you have to
get that somewhere else, such as a Node API. That API has to be based
on a Node that is following the upgraded chain. My wallet for instance
is built on top of Bitpay Insight. If bitpay doesn't upgrade their
Node to follow the 2MB chain, then I must either...
1) Change my wallet to use my own Bitpay Insight. (Insight is open
source, so you can host you own using any Node client you want)
2) Switch to another API, such as Toshi or Bockr.io, or
Blokchain.Info, or ... (there are dozens to choose from)
A blockchain service such as a blockexplorer does need to be upgraded
to handle a blocksize hardfork. The only work required is updating
their node software so that the MAX_BLOCKSIZE parameter is set to 2MB.
This can be done by either changing the source code themselves, or by
installing an alternate client such as XT, Classic, or Unlimited.
On 2/6/16, Adam Back via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Gavin
>
> It would probably be a good idea to have a security considerations
> section, also, is there a list of which exchange, library, wallet,
> pool, stats server, hardware etc you have tested this change against?
>
> Do you have a rollback plan in the event the hard-fork triggers via
> false voting as seemed to be prevalent during XT? (Or rollback just
> as contingency if something unforseen goes wrong).
>
> How do you plan to monitor and manage security through the hard-fork?
>
> Adam
>
> On 6 February 2016 at 16:37, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Responding to "28 days is not long enough" :
>>
>> I keep seeing this claim made with no evidence to back it up. As I said,
>> I
>> surveyed several of the biggest infrastructure providers and the btcd
>> lead
>> developer and they all agree "28 days is plenty of time."
>>
>> For individuals... why would it take somebody longer than 28 days to
>> either
>> download and restart their bitcoind, or to patch and then re-run (the
>> patch
>> can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?
>>
>> For the Bitcoin Core project: I'm well aware of how long it takes to
>> roll
>> out new binaries, and 28 days is plenty of time.
>>
>> I suspect there ARE a significant percentage of un-maintained full
>> nodes--
>> probably 30 to 40%. Losing those nodes will not be a problem, for three
>> reasons:
>> 1) The network could shrink by 60% and it would still have plenty of open
>> connection slots
>> 2) People are committing to spinning up thousands of supports-2mb-nodes
>> during the grace period.
>> 3) We could wait a year and pick up maybe 10 or 20% more.
>>
>> I strongly disagree with the statement that there is no cost to a longer
>> grace period. There is broad agreement that a capacity increase is needed
>> NOW.
>>
>> To bring it back to bitcoin-dev territory: are there any TECHNICAL
>> arguments why an upgrade would take a business or individual longer than
>> 28
>> days?
>>
>>
>> Responding to Luke's message:
>>
>>> On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev
>>> > wrote:
>>> >> Blog post on a couple of the constants chosen:
>>> >> http://gavinandresen.ninja/seventyfive-twentyeight
>>> >
>>> > Can you put this in the BIP's Rationale section (which appears to be
>>> > mis-named
>>> > "Discussion" in the current draft)?
>>
>>
>> I'll rename the section and expand it a little. I think standards
>> documents
>> like BIPs should be concise, though (written for implementors), so I'm
>> not
>> going to recreate the entire blog post there.
>>
>>>
>>> >
>>> >> Signature operations in un-executed branches of a Script are not
>>> >> counted
>>> >> OP_CHECKMULTISIG evaluations are counted accurately; if the signature
>>> >> for a
>>> >> 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the
>>> >> top
>>> >> of the execution stack, it is counted as one signature operation. If
>>> >> it
>>> >> is
>>> >> satisfied by the public key nearest the bottom of the execution
>>> >> stack,
>>> >> it
>>> >> is counted as twenty signature operations. Signature operations
>>> >> involving
>>> >> invalidly encoded signatures or public keys are not counted towards
>>> >> the
>>> >> limit
>>> >
>>> > These seem like they will break static analysis entirely. That was a
>>> > noted
>>> > reason for creating BIP 16 to replace BIP 12. Is it no longer a
>>> > concern?
>>> > Would
>>> > it make sense to require scripts to commit to the total accurate-sigop
>>> > count
>>> > to fix this?
>>
>>
>> After implementing static counting and accurate counting... I was wrong.
>> Accurate/dynamic counting/limiting is quick and simple and can be
>> completely
>> safe (the counting code can be told the limit and can "early-out"
>> validation).
>>
>> I think making scripts commit to a total accurate sigop count is a bad
>> idea-- it would make multisignature signing more complicated for zero
>> benefit. E.g. if you're circulating a partially signed transaction to
>> that
>> must be signed by 2 of 5 people, you can end up with a transaction that
>> requires 2, 3, 4, or 5 signature operations to validate (depending on
>> which
>> public keys are used to do the signing). The first signer might have no
>> idea who else would sign and wouldn't know the accurate sigop count.
>>
>>>
>>> >
>>> >> The amount of data hashed to compute signature hashes is limited to
>>> >> 1,300,000,000 bytes per block.
>>> >
>>> > The rationale for this wasn't in your blog post. I assume it's based
>>> > on
>>> > the
>>> > current theoretical max at 1 MB blocks? Even a high-end PC would
>>> > probably take
>>> > 40-80 seconds just for the hashing, however - maybe a lower limit
>>> > would
>>> > be
>>> > best?
>>
>>
>> It is slightly more hashing than was required to validate block number
>> 364,422.
>>
>> There are a couple of advantages to a very high limit:
>>
>> 1) When the fork is over, special-case code for dealing with old blocks
>> can
>> be eliminated, because all old blocks satisfy the new limit.
>>
>> 2) More importantly, if the limit is small enough it might get hit by
>> standard transactions, then block creation code (CreateNewBlock() /
>> getblocktemplate / or some external transaction-assembling software) will
>> have to solve an even more complicated bin-packing problem to optimize
>> for
>> fees paid.
>>
>> In practice, the 20,000 sigop limit will always be reached before
>> MAX_BLOCK_SIGHASH.
>>
>>
>>>
>>> >
>>> >> Miners express their support for this BIP by ...
>>> >
>>> > But miners don't get to decide hardforks. How does the economy express
>>> > their
>>> > support for it? What happens if miners trigger it without consent from
>>> > the
>>> > economy?
>>
>>
>> "The economy" does support this.
>>
>>
>>>
>>> >
>>> > If you are intent on using the version bits to trigger the hardfork, I
>>> > suggest
>>> > rephrasing this such that miners should only enable the bit when they
>>> > have
>>> > independently confirmed economic support (this means implementations
>>> > need a
>>> > config option that defaults to off).
>>
>>
>> Happy to add words about economic majority.
>>
>> Classic will not implement a command-line option (the act of running
>> Classic
>> is "I opt in"), but happy to add one for a pull request to Core, assuming
>> Core would not see such a pull request as having any hostile intent.
>>
>>
>>> >
>>> >> SPV (simple payment validation) wallets are compatible with this
>>> >> change.
>>> >
>>> > Would prefer if this is corrected to "Light clients" or something.
>>> > Actual SPV
>>> > wallets do not exist at this time, and would not be compatible with a
>>> > hardfork.
>>
>>
>> Is there an explanation of SPV versus "Light Client" written somewhere
>> more
>> permanent than a reddit comment or forum post that I can point to?
>>
>>>
>>> >
>>> >> In the short term, an increase is needed to continue the current
>>> >> economic
>>> >> policies with regards to fees and block space, matching market
>>> >> expectations
>>> >> and preventing market disruption.
>>> >
>>> > IMO this sentence is the most controversial part of your draft, and it
>>> > wouldn't suffer a loss to remove it (or at least make it subjective).
>>
>>
>> Happy to remove.
>>
>>>
>>> > I would also prefer to see any hardfork:
>>> >
>>> > 1. Address at least the simple tasks on the hardfork wishlist (eg,
>>> > enable some
>>> > disabled opcodes; fix P2SH for N-of->15 multisig; etc).
>>
>>
>> Those would be separate BIPs. (according to BIP 1, smaller is better)
>>
>> After this 2MB bump, I agree we need to agree on a process for the next
>> hard
>> fork to avoid all of the unnecessary drama.
>>
>>> > 2. Be deployed as a soft-hardfork so as not to leave old nodes
>>> > entirely
>>> > insecure.
>>
>>
>> I haven't been paying attention to all of the
>> "soft-hardfork/hard-softfork/etc" terminology so have no idea what you
>> mean.
>> Is THAT written up somewhere?
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
📝 Original message:Segwit requires work from exchanges, wallets and services in order for
adoption to happen. This is because segwit changes the rules regarding
the Transaction data structure. A blocksize increase does not change
the Transaction rules at all. The blocksize increase is a change to
the Block structure. Most wallets these days are Block agnostic.
Essentially, if a client has been built using a library that abstracts
away the block, then that client's *code* does not need to be updated
to handle this blocksize limit change. An example is any service using
the Bitcore javascript library. Any wallet built using Bitcore does
not need any changes to handle a blocksize upgrade. I have one project
that is live that was built using Bitcore. Before, during, and after
the fork, I do not need to lift a finger *codewise* to keep my project
still working. Same goes for projects that are built using
pybitcointools, as well as probably a few other libraries.
A wallet using Bitcore also has to work in tandem with a blockchan
api. Bitcore itself does not provide any blockchain data, you have to
get that somewhere else, such as a Node API. That API has to be based
on a Node that is following the upgraded chain. My wallet for instance
is built on top of Bitpay Insight. If bitpay doesn't upgrade their
Node to follow the 2MB chain, then I must either...
1) Change my wallet to use my own Bitpay Insight. (Insight is open
source, so you can host you own using any Node client you want)
2) Switch to another API, such as Toshi or Bockr.io, or
Blokchain.Info, or ... (there are dozens to choose from)
A blockchain service such as a blockexplorer does need to be upgraded
to handle a blocksize hardfork. The only work required is updating
their node software so that the MAX_BLOCKSIZE parameter is set to 2MB.
This can be done by either changing the source code themselves, or by
installing an alternate client such as XT, Classic, or Unlimited.
On 2/6/16, Adam Back via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Gavin
>
> It would probably be a good idea to have a security considerations
> section, also, is there a list of which exchange, library, wallet,
> pool, stats server, hardware etc you have tested this change against?
>
> Do you have a rollback plan in the event the hard-fork triggers via
> false voting as seemed to be prevalent during XT? (Or rollback just
> as contingency if something unforseen goes wrong).
>
> How do you plan to monitor and manage security through the hard-fork?
>
> Adam
>
> On 6 February 2016 at 16:37, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Responding to "28 days is not long enough" :
>>
>> I keep seeing this claim made with no evidence to back it up. As I said,
>> I
>> surveyed several of the biggest infrastructure providers and the btcd
>> lead
>> developer and they all agree "28 days is plenty of time."
>>
>> For individuals... why would it take somebody longer than 28 days to
>> either
>> download and restart their bitcoind, or to patch and then re-run (the
>> patch
>> can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?
>>
>> For the Bitcoin Core project: I'm well aware of how long it takes to
>> roll
>> out new binaries, and 28 days is plenty of time.
>>
>> I suspect there ARE a significant percentage of un-maintained full
>> nodes--
>> probably 30 to 40%. Losing those nodes will not be a problem, for three
>> reasons:
>> 1) The network could shrink by 60% and it would still have plenty of open
>> connection slots
>> 2) People are committing to spinning up thousands of supports-2mb-nodes
>> during the grace period.
>> 3) We could wait a year and pick up maybe 10 or 20% more.
>>
>> I strongly disagree with the statement that there is no cost to a longer
>> grace period. There is broad agreement that a capacity increase is needed
>> NOW.
>>
>> To bring it back to bitcoin-dev territory: are there any TECHNICAL
>> arguments why an upgrade would take a business or individual longer than
>> 28
>> days?
>>
>>
>> Responding to Luke's message:
>>
>>> On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev
>>> > wrote:
>>> >> Blog post on a couple of the constants chosen:
>>> >> http://gavinandresen.ninja/seventyfive-twentyeight
>>> >
>>> > Can you put this in the BIP's Rationale section (which appears to be
>>> > mis-named
>>> > "Discussion" in the current draft)?
>>
>>
>> I'll rename the section and expand it a little. I think standards
>> documents
>> like BIPs should be concise, though (written for implementors), so I'm
>> not
>> going to recreate the entire blog post there.
>>
>>>
>>> >
>>> >> Signature operations in un-executed branches of a Script are not
>>> >> counted
>>> >> OP_CHECKMULTISIG evaluations are counted accurately; if the signature
>>> >> for a
>>> >> 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the
>>> >> top
>>> >> of the execution stack, it is counted as one signature operation. If
>>> >> it
>>> >> is
>>> >> satisfied by the public key nearest the bottom of the execution
>>> >> stack,
>>> >> it
>>> >> is counted as twenty signature operations. Signature operations
>>> >> involving
>>> >> invalidly encoded signatures or public keys are not counted towards
>>> >> the
>>> >> limit
>>> >
>>> > These seem like they will break static analysis entirely. That was a
>>> > noted
>>> > reason for creating BIP 16 to replace BIP 12. Is it no longer a
>>> > concern?
>>> > Would
>>> > it make sense to require scripts to commit to the total accurate-sigop
>>> > count
>>> > to fix this?
>>
>>
>> After implementing static counting and accurate counting... I was wrong.
>> Accurate/dynamic counting/limiting is quick and simple and can be
>> completely
>> safe (the counting code can be told the limit and can "early-out"
>> validation).
>>
>> I think making scripts commit to a total accurate sigop count is a bad
>> idea-- it would make multisignature signing more complicated for zero
>> benefit. E.g. if you're circulating a partially signed transaction to
>> that
>> must be signed by 2 of 5 people, you can end up with a transaction that
>> requires 2, 3, 4, or 5 signature operations to validate (depending on
>> which
>> public keys are used to do the signing). The first signer might have no
>> idea who else would sign and wouldn't know the accurate sigop count.
>>
>>>
>>> >
>>> >> The amount of data hashed to compute signature hashes is limited to
>>> >> 1,300,000,000 bytes per block.
>>> >
>>> > The rationale for this wasn't in your blog post. I assume it's based
>>> > on
>>> > the
>>> > current theoretical max at 1 MB blocks? Even a high-end PC would
>>> > probably take
>>> > 40-80 seconds just for the hashing, however - maybe a lower limit
>>> > would
>>> > be
>>> > best?
>>
>>
>> It is slightly more hashing than was required to validate block number
>> 364,422.
>>
>> There are a couple of advantages to a very high limit:
>>
>> 1) When the fork is over, special-case code for dealing with old blocks
>> can
>> be eliminated, because all old blocks satisfy the new limit.
>>
>> 2) More importantly, if the limit is small enough it might get hit by
>> standard transactions, then block creation code (CreateNewBlock() /
>> getblocktemplate / or some external transaction-assembling software) will
>> have to solve an even more complicated bin-packing problem to optimize
>> for
>> fees paid.
>>
>> In practice, the 20,000 sigop limit will always be reached before
>> MAX_BLOCK_SIGHASH.
>>
>>
>>>
>>> >
>>> >> Miners express their support for this BIP by ...
>>> >
>>> > But miners don't get to decide hardforks. How does the economy express
>>> > their
>>> > support for it? What happens if miners trigger it without consent from
>>> > the
>>> > economy?
>>
>>
>> "The economy" does support this.
>>
>>
>>>
>>> >
>>> > If you are intent on using the version bits to trigger the hardfork, I
>>> > suggest
>>> > rephrasing this such that miners should only enable the bit when they
>>> > have
>>> > independently confirmed economic support (this means implementations
>>> > need a
>>> > config option that defaults to off).
>>
>>
>> Happy to add words about economic majority.
>>
>> Classic will not implement a command-line option (the act of running
>> Classic
>> is "I opt in"), but happy to add one for a pull request to Core, assuming
>> Core would not see such a pull request as having any hostile intent.
>>
>>
>>> >
>>> >> SPV (simple payment validation) wallets are compatible with this
>>> >> change.
>>> >
>>> > Would prefer if this is corrected to "Light clients" or something.
>>> > Actual SPV
>>> > wallets do not exist at this time, and would not be compatible with a
>>> > hardfork.
>>
>>
>> Is there an explanation of SPV versus "Light Client" written somewhere
>> more
>> permanent than a reddit comment or forum post that I can point to?
>>
>>>
>>> >
>>> >> In the short term, an increase is needed to continue the current
>>> >> economic
>>> >> policies with regards to fees and block space, matching market
>>> >> expectations
>>> >> and preventing market disruption.
>>> >
>>> > IMO this sentence is the most controversial part of your draft, and it
>>> > wouldn't suffer a loss to remove it (or at least make it subjective).
>>
>>
>> Happy to remove.
>>
>>>
>>> > I would also prefer to see any hardfork:
>>> >
>>> > 1. Address at least the simple tasks on the hardfork wishlist (eg,
>>> > enable some
>>> > disabled opcodes; fix P2SH for N-of->15 multisig; etc).
>>
>>
>> Those would be separate BIPs. (according to BIP 1, smaller is better)
>>
>> After this 2MB bump, I agree we need to agree on a process for the next
>> hard
>> fork to avoid all of the unnecessary drama.
>>
>>> > 2. Be deployed as a soft-hardfork so as not to leave old nodes
>>> > entirely
>>> > insecure.
>>
>>
>> I haven't been paying attention to all of the
>> "soft-hardfork/hard-softfork/etc" terminology so have no idea what you
>> mean.
>> Is THAT written up somewhere?
>>
>> --
>> --
>> Gavin Andresen
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>