Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees
On Mon, May 22, 2017 at 03:05:49AM -0400, Russell O'Connor via bitcoin-dev wrote: > Not all of the inputs to the SHA256 compression function are created > equal. Only the second argument, the chunk data, is applied to the SHA256 > expander. `merkleRoot` is designed to ensure that the first argument of > the SHA256 compression function is only fed some output of the SHA256 > compression function. In fact, we can prove that the output of the > `merkleRoot` function is always the midstate of some SHA256 hash. To see > this, let us explicitly separate the `sha256` function into the padding > step, `sha256Pad`, and the recursive hashing step, `unpaddedSha256`. This doesn't hold true in the case of pruned trees, as for the pruning to be useful, you don't know what produced the left merkleRoot, and thus you can't guarantee it is in fact a midstate of a genuine SHA256 hash. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Barry Silbert segwit agreement
On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote: > > why? > > the main > issue is due to 0.13.1+ having many segwit related features active > already, including all the P2P components, the new network service > flag, the witness-tx and block messages, compact blocks v2 and > preferential peering. Hmm, the flags are identical in 0.13 and 0.14 clients. Either way, this is rather trivial to solve. If bugs in older clients mean they can’t operate properly when SW is activated (via bit 4) but they don’t know its activated (since they only look at bit1), then just ban them when they misbehave. And tell people to upgrade to a version where SegWit is less buggy. > You would have to then have multiple activation > codepaths to test for such as BIP141(active)->HF BIP141(inactive)->HF > etc. By doing BIP141 first you then only have the BIP141(active)->HF > activation codepath to test for, and you also can't be sure you can > rely on BIP141(inactive)->HF activation codepath being the only one > until segwit activation expires. Heh, well, this is rather simple to solve by not having all those activation codepaths and just picking **one**. You can safely replace the bit1 activation code with a bit4 activation logic, which is based on 80% and has no end-date. We both know that the bip9 (bit1) based activation will not trigger before the expiration date anyway. These worries are rather trivial to solve if you do a little bit of proper architecture of the solution. This honestly can’t be a reason for saying NO to the majority of the mining hash power giving you a break and offering a better SegWit activation. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Drivechain -- Request for Discussion
On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> Surprisingly, this requirement (or, more precisely, this incentive) does
> not effect miners relative to each other. The incentive to upgrade is only
> for the purpose of preventing a "theft" -- defined as: an improper
> withdrawal from a sidechain. It is not about miner revenues or the ability
> to mine generally (or conduct BMM specifically). The costs of such a theft
> (decrease in market price, decrease in future transaction fee levels) would
> be shared collectively by all future miners. Therefore, it would have no
> effect on miners relative to each other.
That's not at all true. If I'm a miner with a better capability than another
miner to prevent that theft, I have reasons to induce it to happen to give me
political cover to pushing that other miner off the network.
This is a very similar problem to what we had with zeroconf double-spending,
where entities such as Coinbase tried to pay off miners to guarantee something
that wasn't possible in a geninely decrentralized system: safe zeroconf
transactions.
> Moreover, miners have other recourse if they are unable to run the node.
> They can adopt a policy of simply rejecting ("downvoting") any withdrawals
> that they don't understand. This would pause the withdraw process until
> enough miners understand enough of what is going on to proceed with it.
Why are you forcing miners to run this code at all?
Equally, you're opening up miners to huge political risks, as rejecting all
withdrawals is preventing users' from getting their money, which gives other
miners a rational for kicking those miners off of Bitcoin entirely.
> Finally, the point in dispute is a single, infrequent, true/false question.
> So miners may resort to semi-trusted methods to supplement their decision.
> In other words, they can just ask people they trust, if the withdrawal is
> correct or not. It is up to users to decide if they are comfortable with
> these risks, if/when they decide to deposit to a sidechain.
Why do you think this will be infrequent? Miners with a better ability to
validate the drivechain have every reason to make these events more frequent.
> It is a matter of comparing the costs and benefits. Ignoring theft, the
> costs are near-zero, and the benefits are >0. Specifically, they are: a
> higher BTC price and greater transaction fees. Theft is discouraged by
> attempting to tie a theft to a loss of confidence in the miners, as
> described in the spec/website.
> In general the incentives are very similar to those of Bitcoin itself.
This is also a very dubious security model - I would argue that Bitcoin is much
*more* valuable if miners do everything they can to ensure that drivechains
fail, given the huge risks involved. I would also argue that users should do
user-activated-soft-forks to ensure they fail.
By comparison, note Adam Back and my own efforts to ensure miners have a
smaller part in the ecosystem, with things like committed (encrypted)
transactions and my closed-seal-set/truth-list approach(1). We want to involve
miners as little as possible in the consensus, not more.
I have to ask: What use-cases do you actually see for drivechains? Why can't
those use-cases be done in the much safer client-side validation fashion?
1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
--
https://petertodd.org 'peter'[:-1]@petertodd.org
signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Barry Silbert segwit agreement
On Sun, May 28, 2017 at 3:51 PM, Tom Zander via bitcoin-dev wrote: > On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote: >> > why? >> >> the main >> issue is due to 0.13.1+ having many segwit related features active >> already, including all the P2P components, the new network service >> flag, the witness-tx and block messages, compact blocks v2 and >> preferential peering. > > Hmm, the flags are identical in 0.13 and 0.14 clients. > > Either way, this is rather trivial to solve. If bugs in older clients mean > they can’t operate properly when SW is activated (via bit 4) but they don’t > know its activated (since they only look at bit1), then just ban them when > they misbehave. > And tell people to upgrade to a version where SegWit is less buggy. That would partition off those clients, which is not something we would want to happen. > >> You would have to then have multiple activation >> codepaths to test for such as BIP141(active)->HF BIP141(inactive)->HF >> etc. By doing BIP141 first you then only have the BIP141(active)->HF >> activation codepath to test for, and you also can't be sure you can >> rely on BIP141(inactive)->HF activation codepath being the only one >> until segwit activation expires. > > Heh, well, this is rather simple to solve by not having all those activation > codepaths and just picking **one**. This isn't possible until either BIP141 segwit is active or BIP141 segwit has expired. > > You can safely replace the bit1 activation code with a bit4 activation > logic, which is based on 80% and has no end-date. > We both know that the bip9 (bit1) based activation will not trigger before > the expiration date anyway. We don't know that since bip9 bit1 only needs 55% hashpower to be triggered(see BIP91 activation method for how this can be done) > > These worries are rather trivial to solve if you do a little bit of proper > architecture of the solution. This honestly can’t be a reason for saying NO > to the majority of the mining hash power giving you a break and offering a > better SegWit activation. BIP91 activation is clearly superior than trying to fully redeploy, it is far simpler and can be done almost immediately with only miners needing to upgrade. > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Compatibility-Oriented Omnibus Proposal
This proposal is written under the assumption that the signatories to the Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms of the agreement, and intend to enact the updates described therein. As such, criticisms pertaining to the chosen deployment timeline or hard fork upgrade path should be treated as out-of-scope during the initial discussion of this proposal. Because it includes the activation of a hard fork for which community consensus does not yet exist, this proposal is not likely to be merged into Bitcoin Core in the immediate future, and must instead be maintained and reviewed in a separate downstream repository. However, it is written with the intent to remain cleanly compatible with future network updates and changes, to allow for the option of a straightforward upstream merge if community consensus for the proposal is successfully achieved in the following months. BIP: ? Layer: Consensus Title: Compatibility-oriented omnibus proposal Author: Calvin Rechner Comments-Summary: No comments yet. Comments-URI: ? Status: Draft Type: Standards Track Created: 2017-05-28 License: PD ===Abstract=== This document describes a virtuous combination of James Hilliard’s “Reduced signalling threshold activation of existing segwit deployment”[2], Shaolin Fry’s “Mandatory activation of segwit deployment”[3], Sergio Demian Lerner’s “Segwit2Mb”[4] proposal, Luke Dashjr’s “Post-segwit 2 MB block size hardfork”[5], and hard fork safety mechanisms from Johnson Lau’s “Spoonnet”[6][7] into a single omnibus proposal and patchset. ===Motivation=== The Consensus 2017 Scaling Agreement[1] stipulated the following commitments: • Activate Segregated Witness at an 80% threshold, signaling at bit 4 • Activate a 2 MB hard fork within six months This proposal seeks to fulfill these criteria while retaining maximum compatibility with existing deployment approaches, thereby minimizing the risks of a destructive chain split. Additionally, subsequent indications of implied criteria and expectations of the Agreement[8][9] are satisfied. The proposed hard fork incorporates a legacy witness discount and 2MB blocksize limit along with the enactment of Spoonnet-derived protectionary measures, to ensure the safest possible fork activation within the constraints of the requirements outlined in the Scaling Agreement. ===Rationale=== To the extent possible, this represents an effort at a best-of-all-worlds proposal, intended to provide a common foundation from which all mutually-inclusive goals can be achieved while risks are minimized. The individual constituent proposals include the following respective rationales: James Hilliard’s “Reduced signalling threshold activation of existing segwit deployment”[2] explains: > The goal here is to minimize chain split risk and network disruption while > maximizing backwards compatibility and still providing for rapid activation > of segwit at the 80% threshold using bit 4. Shaolin Fry’s “Mandatory activation of segwit deployment”[3] is included to: > cause the existing "segwit" deployment to activate without needing to release > a new deployment. Both of the aforementioned activation options (“fast-activation” and “flag-day activation”) serve to prevent unnecessary delays in the network upgrade process, addressing a common criticism of the Scaling Agreement and providing an opportunity for cooperation and unity instead. Sergio Demian Lerner’s “Segwit2Mb”[4] proposal explains the reasoning behind linking SegWit’s activation with that of a later hard fork block size increase: > Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB block > size hard-fork activated ONLY if segwit activates (95% of miners signaling > ... to re-unite the Bitcoin community and avoid a cryptocurrency split. Luke Dashjr’s “Post-segwit 2 MB block size hardfork”[5] suggestions are included to reduce the marginal risks that such an increase in the block size might introduce: > if the community wishes to adopt (by unanimous consensus) a 2 MB block size > hardfork, this is probably the best way to do it right now... Legacy Bitcoin > transactions are given the witness discount, and a block size limit of 2 MB > is imposed. Johnson Lau’s anti-replay and network version updates[6][7] are included as general hard fork safety measures: > In a blockchain split, however, since both forks share the same historical > ledger, replay attack would be possible, unless some precautions are taken. ===Copyright=== This document is placed in the public domain. ===Specification=== ###Proposal Signaling### The string “COOP” is included anywhere in the txn-input (scriptSig) of the coinbase-txn to signal compatibility and support. ###Soft Fork### Fast-activation (segsignal): deployed by a "version bits" with an 80% activation threshold BIP9 with the name "segsignal" and using bit 4... [with a] start time of midnight June 1st, 2017 (epoch t
Re: [bitcoin-dev] Drivechain -- Request for Discussion
Seems to me an obvious use case for drive chains are to have high speed
small transactions on a side chain, eventually cleared to the main chain.
Not sure why miners would want this to fail any more than any other side
chain, like Liquid or lightning.
On May 28, 2017 5:23 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> Surprisingly, this requirement (or, more precisely, this incentive) does
> not effect miners relative to each other. The incentive to upgrade is only
> for the purpose of preventing a "theft" -- defined as: an improper
> withdrawal from a sidechain. It is not about miner revenues or the ability
> to mine generally (or conduct BMM specifically). The costs of such a theft
> (decrease in market price, decrease in future transaction fee levels)
would
> be shared collectively by all future miners. Therefore, it would have no
> effect on miners relative to each other.
That's not at all true. If I'm a miner with a better capability than another
miner to prevent that theft, I have reasons to induce it to happen to give
me
political cover to pushing that other miner off the network.
This is a very similar problem to what we had with zeroconf double-spending,
where entities such as Coinbase tried to pay off miners to guarantee
something
that wasn't possible in a geninely decrentralized system: safe zeroconf
transactions.
> Moreover, miners have other recourse if they are unable to run the node.
> They can adopt a policy of simply rejecting ("downvoting") any withdrawals
> that they don't understand. This would pause the withdraw process until
> enough miners understand enough of what is going on to proceed with it.
Why are you forcing miners to run this code at all?
Equally, you're opening up miners to huge political risks, as rejecting all
withdrawals is preventing users' from getting their money, which gives other
miners a rational for kicking those miners off of Bitcoin entirely.
> Finally, the point in dispute is a single, infrequent, true/false
question.
> So miners may resort to semi-trusted methods to supplement their decision.
> In other words, they can just ask people they trust, if the withdrawal is
> correct or not. It is up to users to decide if they are comfortable with
> these risks, if/when they decide to deposit to a sidechain.
Why do you think this will be infrequent? Miners with a better ability to
validate the drivechain have every reason to make these events more
frequent.
> It is a matter of comparing the costs and benefits. Ignoring theft, the
> costs are near-zero, and the benefits are >0. Specifically, they are: a
> higher BTC price and greater transaction fees. Theft is discouraged by
> attempting to tie a theft to a loss of confidence in the miners, as
> described in the spec/website.
> In general the incentives are very similar to those of Bitcoin itself.
This is also a very dubious security model - I would argue that Bitcoin is
much
*more* valuable if miners do everything they can to ensure that drivechains
fail, given the huge risks involved. I would also argue that users should do
user-activated-soft-forks to ensure they fail.
By comparison, note Adam Back and my own efforts to ensure miners have a
smaller part in the ecosystem, with things like committed (encrypted)
transactions and my closed-seal-set/truth-list approach(1). We want to
involve
miners as little as possible in the consensus, not more.
I have to ask: What use-cases do you actually see for drivechains? Why can't
those use-cases be done in the much safer client-side validation fashion?
1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
--
https://petertodd.org 'peter'[:-1]@petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
