Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
Seems like it would work fine. But why would we expect 80pct to signal for
the exact same implementation - when we can't get 40pct.
It will be contingent on some HF code that allows him to continue using
asicboost, or is too aggressive, or some other unreasonable request.
On May 22, 2017 6:43 PM, "Matt Corallo via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
Given the overwhelming support for SegWit across the ecosystem of
businesses and users, this seems reasonable to me.
On May 22, 2017 6:40:13 PM EDT, James Hilliard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>I would like to propose an implementation that accomplishes the first
>part of the Barry Silbert proposal independently from the second:
>
>"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
>in a way that
>
>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.
>
>By activating segwit immediately and separately from any HF we can
>scale quickly without risking a rushed combined segwit+HF that would
>almost certainly cause widespread issues.
>
>Draft proposal:
>https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.
mediawiki
>
>Proposal text:
>
> BIP: segsignal
> Layer: Consensus (soft fork)
>Title: Reduced signalling threshold activation of existing segwit
>deployment
> Author: James Hilliard
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
>
>
>==Abstract==
>
>This document specifies a method to activate the existing BIP9 segwit
>deployment with a majority hashpower less than 95%.
>
>==Definitions==
>
>"existing segwit deployment" refer to the BIP9 "segwit" deployment
>using bit 1, between November 15th 2016 and November 15th 2017 to
>activate BIP141, BIP143 and BIP147.
>
>==Motivation==
>
>Segwit increases the blocksize, fixes transaction malleability, and
>makes scripting easier to upgrade as well as bringing many other
>[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>
>This BIP provides a way for a simple majority of miners to coordinate
>activation of the existing segwit deployment with less than 95%
>hashpower. For a number of reasons a complete redeployment of segwit
>is difficulty to do until the existing deployment expires. This 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. A redeployment of segwit will need to redefine all these
>things and doing so before expiry would greatly complicate testing.
>
>==Specification==
>
>While this BIP is active, all blocks must set the nVersion header top
>3 bits to 001 together with bit field (1<<1) (according to the
>existing segwit deployment). Blocks that do not signal as required
>will be rejected.
>
>==Deployment==
>
>This BIP will be deployed by a "version bits" with an 80%(this can be
>adjusted if desired) activation threshold BIP9 with the name
>"segsignal" and using bit 4.
>
>This BIP will have a start time of midnight June 1st, 2017 (epoch time
>1496275200) and timeout on midnight November 15th 2017 (epoch time
>1510704000). This BIP will cease to be active when segwit is
>locked-in.
>
>=== Reference implementation ===
>
>
>// Check if Segregated Witness is Locked In
>bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>Consensus::Params& params)
>{
>LOCK(cs_main);
>return (VersionBitsState(pindexPrev, params,
>Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>THRESHOLD_LOCKED_IN);
>}
>
>// SEGSIGNAL mandatory segwit signalling.
>if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
>&&
> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>// Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>and is not active.
>{
>bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>VERSIONBITS_TOP_BITS;
>bool fSegbit = (pindex->nVersion &
>VersionBitsMask(chainparams.GetConsensus(),
>Consensus::DEPLOYMENT_SEGWIT)) != 0;
>if (!(fVersionBits && fSegbit)) {
>return state.DoS(0, error("ConnectBlock(): relayed block must
>signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>}
>}
>
>
>https://github.com/bitcoin/bitcoin/compare/0.14...
jameshilliard:segsignal-v0.14.1
>
>==Backwards Compatibility==
>
>This deployment is compatible with the existing "segwit" bit 1
>deployment scheduled between midnight November 15th, 2016 and midnight
>November 15th, 2017. Miners will need to upgrade their nodes to
>support segsignal otherwise they may build on top of an invalid block.
>While this bip is active users should either upgrade to seg
Re: [bitcoin-dev] I do not support the BIP 148 UASF
I'm glad some discussion has been moved back here. Correct me if I am wrong, but currently core developers are arguing over whether or not to allow an optional configuration switch which defaults off but signals and enforces BIP148 when used. Who are we protecting users from, themselves? Are you protecting core? from what? I am somewhat genuinely befuddled by those who can't even allow a user config switch to be set. I guess I find it all incredibly silly, but perhaps I suffer from some basic confusion. On Mon, May 22, 2017 at 3:23 PM, Suhas Daftuar via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I also do not support the BIP 148 UASF, and I'd like to add to the points > that Greg has already raised in this thread. > > BIP 148 would introduce a new consensus rule that softforks out non-segwit > signalling blocks in some time period. I reject this consensus rule as > both arbitrary and needlessly disruptive. Bitcoin's primary purpose is to > reach consensus on the state of a shared ledger, and even though I think > the Bitcoin network ought to adopt segwit, I don't think that concern > trumps the goal of not splitting the network. > > Many BIP 148 advocates seem to start with the assumption that segwit > already has a lot of support, and suggest that BIP 148 does as well. > However I don't think it's fair or correct to separate the activation > proposal for segwit from the rest of the segwit proposal. The deployment > parameters for segwit are consensus-critical; assuming that some other > deployment has consensus because it would result in the rest of the segwit > proposal activating is an unjustified leap. > > Even if there were no feasible alternate segwit deployment method > available to us, I would hesitate to recommend that the network adopt a > potentially consensus-splitting approach, even though I firmly believe that > the ideas behind segwit are fundamentally good ones. But fortunately that > is not the situation we are in; we have substantially less disruptive > methods available to us to activate it, even if the current BIP 9 > deployment were to fail -- such as another BIP 9 deployment in the future, > or perhaps a BIP 149 deployment. > > If we do pursue a "user-activated" deployment of segwit, I'd recommend > that we do so in a more careful way than BIP 148 or 149 currently suggest, > which as I understand would otherwise make very few changes to the current > implementation. However, due to the BIP 9 activation assumption, the > Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together > the idea that miners would both enforce the rules and mine segwit blocks. > However, we can separate these concerns, as we started to do in the Bitcoin > Core 0.14.1 release, where mining segwit blocks is not required in order to > generally mine or signal for segwit in the software. And we can go further > still: without too much work, we could make further improvements to > accommodate miners who, for whatever reason, don't want to upgrade their > systems, such as by improving block relay from pre-segwit peers [1], or > optimizing transaction selection for miners who are willing to enforce the > segwit rules but haven't upgraded their systems to mine segwit blocks [2]. > > If we would seek to activate a soft-fork with less clear miner signaling > (such as BIP 149), then I think such improvements are warranted to minimize > network disruption. In general, we should not seek to censor hashpower on > the network unless we have a very important reason for doing so. While the > issues here are nuanced, if I were to evaluate the BIP 148 soft-fork > proposal on the spectrum of "censorship attack on Bitcoin" to "benign > protocol upgrade", BIP 148 strikes me as closer to the former than the > latter. There is simply no need here to orphan these non-signalling blocks > that could otherwise be used to secure the network. > > To go further: I think BIP 148 is ill-conceived even for achieving its own > presumed goals -- the motivation for adding a consensus rule that applies > to the version bits on blocks is surely for the effect such bits have on > older software, such as Bitcoin Core releases 0.13.1 and later. Yet in > trying to bring those implementations along as segwit-enforcing software, > BIP 148 would risk forking from such clients in the short term! If one > really cared about maintaining consensus with older, segwit-enabled > software, it would make far more sense to seek segwit activation in a way > that didn't fork from them (such as BIP 149, or a new BIP 9 deployment > after this one times out). And if one doesn't care about such consensus, > then it'd be far simpler to just set (e.g.) August 1 as the flag day > activation of segwit, and not play these contortionist games with block > version bits, which carry no useful or intrinsic meaning. Either of these > two approaches should have the advantage of reduced fork risk, compared > with BIP 148. > > Of
Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees
On Mon, May 22, 2017 at 12:05 AM, Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The SHA256 compression function takes two inputs: > > 1. A 256-bit value for the previous chunk in a chain, or an initial vector > in the case of the first chunk. > 2. A 512-bit chunk of data. > > sha256Compress : Word256 × Word512 -> Word256 > > In total, the SHA256 compression function compresses 768-bits into > 256-bits. The Merkle roots of two branches occupy 512 bits, and this > leaves another 256-bits of space available for tags. > Ya know, when you're building a Merkle Trie that's exactly the primitive you need. In my own construction the assumption is that the values are already hashed down to 256 bits when they're passed in, and the tags (which are currently done by sacrificing bits instead of using tags, that needs to be fixed) include three states for either side: empty, unary, or middle. Three of those possibilities are unreachable (empty/empty, empty/unary, unary/empty) so there are 6 possible tags needed. This approach essentially skips doing the unary hashes, a further performance improvement. There doesn't appear to be any downside in leveraging this trick as long as tags are cheap. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Rolling UTXO set hashes
Gregory Maxwell via bitcoin-dev writes: > On Tue, May 16, 2017 at 6:17 PM, Pieter Wuille > wrote: >> just the first - and one that has very low costs and no normative >> datastructures at all. > > The serialization of the txout itself is normative, but very minimal. I do prefer the (2) approach, BTW, as it reuses existing primitives, but I know "simpler" means a different thing to mathier brains :) Since it wasn't explicit in the proposal, I think the txout information placed in the hash here is worth discussing. I prefer a simple txid||outnumber[1], because it allows simple validation without knowing the UTXO set itself; even a lightweight node can assert that UTXOhash for block N+1 is valid if the UTXOhash for block N is valid (and vice versa!) given block N+1. And miners can't really use that even if they were to try not validating against UTXO (!) because they need to know input amounts for fees (which are becoming significant). If I want to hand you the complete validatable UTXO set, I need to hand you all the txs with any unspent output, and some bitfield to indicate which ones are unspent. OTOH, if you serialize more (eg. ...||amount||scriptPubKey ?), then the UTXO set size needed to validate the utxohash is a little smaller: you need to send the txid, but not the tx nVersion, nLocktime or inputs. But in a SegWit world, that's actually *bigger* AFAICT. Thanks, Rusty. [1] I think you could actually use txid^outnumber, and if that's not a curve point SHA256() again, etc. But I don't think that saves any real time, and may cause other issues. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Drivechain -- Request for Discussion
Good morning,
>What you read is only an introduction of BMM. You may also consult the notes
>(at the bottom of the BMM post) or the code, although this is time consuming
>of course.
Looking over the code, I have a question: Is OP_BRIBE supposed to be softforked
in, or hardforked? From my understanding, the code as published in your linked
github cannot be softforked in, since it is not a softfork-compatible
replacement for OP_NOP: it replaces the stack top value with a 0/1 value. Both
CLTV and CSV do not touch the stack, only flag an error if they fail.
(What happens if the h* to be put in the coinbase, by chance - even very
unlikely chance - is 0? Then OP_NOP4 is not the same as OP_BRIBE
scripts in result - the former will be rejected by old nodes, the latter will
be accepted by new nodes)
Does Drivechain require a hardfork? My understanding is that you want to use
some kind of softforked anyone-can-spend transaction to use Drivechain. So I
don't quite understand why OP_BRIBE is written the way it is.
Is OP_BRIBE the same as the OP_h_is_in_coinbase operation you described?
How is OP_BRIBE superior to just using a OP_RETURN script? Cannot a
sidechain scan the block for OP_RETURN attesting that the block hash is present
in the block? OP_BRIBE encodes twice (once in the transaction, once in the
coinbase), OP_RETURN encodes it once (once in the transaction)
>The literal answer to your question is that mainchain Bitcoin will notice
>that, for the second withdrawal, the sum of the inputs is less than the sum of
>the outputs and they the transaction is therefore invalid.
You misunderstand. The first withdrawal was done by double-spending, and
exchanging your sidechain funds for mainchain funds using some off-chain
method. The second withdrawal is done on-chain.
That said, I confused OP_h_is_in_coinbase as your method of getting out of the
sidechain into the mainchain. It seems, OP_h_is_in_coinbase is only for blind
mining?
>I feel that my proposal is more secure, as it can operate healthily and
>quickly while using spv proofs which are much slower and much much easier to
>audit.
I don't quite understand how Drivechain handles sidechain reorgs, while keeping
Bitcoin miners blinded. It seems sidechains need to be known ("seen") by the
miner, so I don't see what is being blinded by blinded merge mining.
>>seems to me that your OP_is_h_in_coinbase should scan a series of sidechain
>>block headers backed by mainchain (meaning at the minimum that sidechains
>>should have some common header format prefix), rather than just mainchain
>>depth as your article seems to imply.
>
>How would security be improved as a result? In either case, 51% of hashrate
>can cause a reorg. The sidechain software itself does scan block headers, of
>course.
I misunderstand the purpose of your OP_is_h_in_coinbase, sorry.
>>Blind merged mining seems strictly inferior ... a rich attacker can simply
>>reorg the sidechain outright without playing such games.
>
>In the future, when there is no block subsidy, a rich attacker can also do
>that in mainchain Bitcoin.
I see. However, block subsidies will drop far in the future, do you mean to
say, that sidechains will be used only in the far future?
>>How does your proposal handle multiple side block creators on the same
>>sidechain, with the possibility that chain splits occur?
>
>The side block is only "mined" if it is committed to in a mainchain Bitcoin
>blog, and each mainchain block can only contain one block per sidechain. In
>this way, drivechain sidechains are different from classical Namecoin merged
>mining (where one _could_ run the entire system, mining included, without
>interfacing with Bitcoin at all).
I assume you mean "mainchain Bitcoin block" here.
What mechanism ensures only one mainchain block can contain only one sidechain
block? It seems, this isn't implemented by OP_BRIBE yet. Can you elaborate on
this mechanism?
>>Regarding your dig about people who dislike data centers, the main issue with
>>miners blindly accepting sidechain commitments is that it violates "Don't
>>trust, verify", not that allows datacenters to be slightly smaller by not
>>including side:nodes.
>
>As I explain early on, in earlier rounds of peer review, the focus was on
>harms the sidechain technology might do to mainchain Bitcoin, and the
>"datacenter point" was specifically the chief objection raised. So I am afraid
>you are entirely incorrect.
I see. It seems, the main problem, is that sidechains can be used to sneak in
block size increases. Of course, the advantage of sidechains, is that when it
increases block size irresponsibly, only those who participated in the
sidechain will suffer.
>In point of fact, the transactions *are* validated...by sidechain full nodes,
>same as Bitcoin proper.
But from blind merge mining by itself, how would the blinded merge miner know
that there exists an actual sidechain full node that actually did v
Re: [bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
Given the overwhelming support for SegWit across the ecosystem of businesses
and users, this seems reasonable to me.
On May 22, 2017 6:40:13 PM EDT, James Hilliard via bitcoin-dev
wrote:
>I would like to propose an implementation that accomplishes the first
>part of the Barry Silbert proposal independently from the second:
>
>"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
>in a way that
>
>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.
>
>By activating segwit immediately and separately from any HF we can
>scale quickly without risking a rushed combined segwit+HF that would
>almost certainly cause widespread issues.
>
>Draft proposal:
>https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>
>Proposal text:
>
> BIP: segsignal
> Layer: Consensus (soft fork)
>Title: Reduced signalling threshold activation of existing segwit
>deployment
> Author: James Hilliard
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
>
>
>==Abstract==
>
>This document specifies a method to activate the existing BIP9 segwit
>deployment with a majority hashpower less than 95%.
>
>==Definitions==
>
>"existing segwit deployment" refer to the BIP9 "segwit" deployment
>using bit 1, between November 15th 2016 and November 15th 2017 to
>activate BIP141, BIP143 and BIP147.
>
>==Motivation==
>
>Segwit increases the blocksize, fixes transaction malleability, and
>makes scripting easier to upgrade as well as bringing many other
>[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>
>This BIP provides a way for a simple majority of miners to coordinate
>activation of the existing segwit deployment with less than 95%
>hashpower. For a number of reasons a complete redeployment of segwit
>is difficulty to do until the existing deployment expires. This 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. A redeployment of segwit will need to redefine all these
>things and doing so before expiry would greatly complicate testing.
>
>==Specification==
>
>While this BIP is active, all blocks must set the nVersion header top
>3 bits to 001 together with bit field (1<<1) (according to the
>existing segwit deployment). Blocks that do not signal as required
>will be rejected.
>
>==Deployment==
>
>This BIP will be deployed by a "version bits" with an 80%(this can be
>adjusted if desired) activation threshold BIP9 with the name
>"segsignal" and using bit 4.
>
>This BIP will have a start time of midnight June 1st, 2017 (epoch time
>1496275200) and timeout on midnight November 15th 2017 (epoch time
>1510704000). This BIP will cease to be active when segwit is
>locked-in.
>
>=== Reference implementation ===
>
>
>// Check if Segregated Witness is Locked In
>bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
>Consensus::Params& params)
>{
>LOCK(cs_main);
>return (VersionBitsState(pindexPrev, params,
>Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
>THRESHOLD_LOCKED_IN);
>}
>
>// SEGSIGNAL mandatory segwit signalling.
>if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
>Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
>&&
> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
>// Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
>and is not active.
>{
>bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
>VERSIONBITS_TOP_BITS;
>bool fSegbit = (pindex->nVersion &
>VersionBitsMask(chainparams.GetConsensus(),
>Consensus::DEPLOYMENT_SEGWIT)) != 0;
>if (!(fVersionBits && fSegbit)) {
>return state.DoS(0, error("ConnectBlock(): relayed block must
>signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>}
>}
>
>
>https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1
>
>==Backwards Compatibility==
>
>This deployment is compatible with the existing "segwit" bit 1
>deployment scheduled between midnight November 15th, 2016 and midnight
>November 15th, 2017. Miners will need to upgrade their nodes to
>support segsignal otherwise they may build on top of an invalid block.
>While this bip is active users should either upgrade to segsignal or
>wait for additional confirmations when accepting payments.
>
>==Rationale==
>
>Historically we have used IsSuperMajority() to activate soft forks
>such as BIP66 which has a mandatory signalling requirement for miners
>once activated, this ensures that miners are aware of new rules being
>enforced. This technique can be leveraged to lower the signalling
>threshold of a soft fork while it is in the process of bei
[bitcoin-dev] Reduced signalling threshold activation of existing segwit deployment
I would like to propose an implementation that accomplishes the first
part of the Barry Silbert proposal independently from the second:
"Activate Segregated Witness at an 80% threshold, signaling at bit 4"
in a way that
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.
By activating segwit immediately and separately from any HF we can
scale quickly without risking a rushed combined segwit+HF that would
almost certainly cause widespread issues.
Draft proposal:
https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
Proposal text:
BIP: segsignal
Layer: Consensus (soft fork)
Title: Reduced signalling threshold activation of existing segwit deployment
Author: James Hilliard
Status: Draft
Type: Standards Track
Created: 2017-05-22
License: BSD-3-Clause
CC0-1.0
==Abstract==
This document specifies a method to activate the existing BIP9 segwit
deployment with a majority hashpower less than 95%.
==Definitions==
"existing segwit deployment" refer to the BIP9 "segwit" deployment
using bit 1, between November 15th 2016 and November 15th 2017 to
activate BIP141, BIP143 and BIP147.
==Motivation==
Segwit increases the blocksize, fixes transaction malleability, and
makes scripting easier to upgrade as well as bringing many other
[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
This BIP provides a way for a simple majority of miners to coordinate
activation of the existing segwit deployment with less than 95%
hashpower. For a number of reasons a complete redeployment of segwit
is difficulty to do until the existing deployment expires. This 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. A redeployment of segwit will need to redefine all these
things and doing so before expiry would greatly complicate testing.
==Specification==
While this BIP is active, all blocks must set the nVersion header top
3 bits to 001 together with bit field (1<<1) (according to the
existing segwit deployment). Blocks that do not signal as required
will be rejected.
==Deployment==
This BIP will be deployed by a "version bits" with an 80%(this can be
adjusted if desired) activation threshold BIP9 with the name
"segsignal" and using bit 4.
This BIP will have a start time of midnight June 1st, 2017 (epoch time
1496275200) and timeout on midnight November 15th 2017 (epoch time
1510704000). This BIP will cease to be active when segwit is
locked-in.
=== Reference implementation ===
// Check if Segregated Witness is Locked In
bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
Consensus::Params& params)
{
LOCK(cs_main);
return (VersionBitsState(pindexPrev, params,
Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
THRESHOLD_LOCKED_IN);
}
// SEGSIGNAL mandatory segwit signalling.
if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
&&
!IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
// Segwit is not locked in
!IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
and is not active.
{
bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
VERSIONBITS_TOP_BITS;
bool fSegbit = (pindex->nVersion &
VersionBitsMask(chainparams.GetConsensus(),
Consensus::DEPLOYMENT_SEGWIT)) != 0;
if (!(fVersionBits && fSegbit)) {
return state.DoS(0, error("ConnectBlock(): relayed block must
signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
}
}
https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1
==Backwards Compatibility==
This deployment is compatible with the existing "segwit" bit 1
deployment scheduled between midnight November 15th, 2016 and midnight
November 15th, 2017. Miners will need to upgrade their nodes to
support segsignal otherwise they may build on top of an invalid block.
While this bip is active users should either upgrade to segsignal or
wait for additional confirmations when accepting payments.
==Rationale==
Historically we have used IsSuperMajority() to activate soft forks
such as BIP66 which has a mandatory signalling requirement for miners
once activated, this ensures that miners are aware of new rules being
enforced. This technique can be leveraged to lower the signalling
threshold of a soft fork while it is in the process of being deployed
in a backwards compatible way.
By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
deployment, this BIP can cause the existing "segwit" deployment to
activate without needing to release a new deployment.
==References==
*[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/
Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees
On May 22, 2017 23:05, "Peter Todd" wrote: On Mon, May 22, 2017 at 03:05:49AM -0400, Russell O'Connor via bitcoin-dev wrote: > MerkleRoot := SHA256(SHA256(LeftRoot ⋅ RightRoot)) > sha256Compress : Word256 × Word512 -> Word256 To be clear, what math operations do you mean by "⋅" and "×"? By "⋅", I usually mean concatenation (though I also use it for function composition in one instance). By "×", I mean the Cartesian product. ___ 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 May 22, 2017 3:13 PM, "Tier Nolan via bitcoin-dev" wrote: On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > In the future, when there is no block subsidy, a rich attacker can also do > that in mainchain Bitcoin. > I don't think they are the same. With Bitcoin, you only get to reverse recent transactions. If you actually reversed 2-3 weeks of transactions, then the Bitcoin price would fall, destroying the value of the additional coins you managed to obtain. Even if their was no price fall, you can only get a fraction of the total. I would replace "Bitcoins you manage to steal" with "Bitcoins you manage to double-spend". Then, it still seems the same to me. With BMM, you can "buy" the entire reserve of the sidechain by paying (timeout) * (average tx fees). If you destroy a side-chain's value, then that doesn't affect the value of the bitcoins you manage to steal. It may destroy great value if it shakes confidence in the sidechain infrastructure. Thus, the value of the stolen BTC may decrease, in addition to the lost future tx fee revenues of the attacked chain. http://www.truthcoin.info/blog/drivechain/#drivechains-security In my view, sidechains should only exist at all if they positively impact Bitcoin's value. It is therefore desirable for miners to steal from chains that provide no value-add. > In point of fact, the transactions *are* validated...by sidechain full > nodes, same as Bitcoin proper. > > The big difference is that Bitcoin holds no assets on another chain. A side-chain's value is directly linked to the fact that it has 100% reserves on the Bitcoin main chain. That can be targeted for theft. Again, I don't really think it is that different. One could interchange "recent txns" (those which could be double-spent within 2-3 weeks) with "sidechain deposit tnxs". ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
I also do not support the BIP 148 UASF, and I'd like to add to the points that Greg has already raised in this thread. BIP 148 would introduce a new consensus rule that softforks out non-segwit signalling blocks in some time period. I reject this consensus rule as both arbitrary and needlessly disruptive. Bitcoin's primary purpose is to reach consensus on the state of a shared ledger, and even though I think the Bitcoin network ought to adopt segwit, I don't think that concern trumps the goal of not splitting the network. Many BIP 148 advocates seem to start with the assumption that segwit already has a lot of support, and suggest that BIP 148 does as well. However I don't think it's fair or correct to separate the activation proposal for segwit from the rest of the segwit proposal. The deployment parameters for segwit are consensus-critical; assuming that some other deployment has consensus because it would result in the rest of the segwit proposal activating is an unjustified leap. Even if there were no feasible alternate segwit deployment method available to us, I would hesitate to recommend that the network adopt a potentially consensus-splitting approach, even though I firmly believe that the ideas behind segwit are fundamentally good ones. But fortunately that is not the situation we are in; we have substantially less disruptive methods available to us to activate it, even if the current BIP 9 deployment were to fail -- such as another BIP 9 deployment in the future, or perhaps a BIP 149 deployment. If we do pursue a "user-activated" deployment of segwit, I'd recommend that we do so in a more careful way than BIP 148 or 149 currently suggest, which as I understand would otherwise make very few changes to the current implementation. However, due to the BIP 9 activation assumption, the Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together the idea that miners would both enforce the rules and mine segwit blocks. However, we can separate these concerns, as we started to do in the Bitcoin Core 0.14.1 release, where mining segwit blocks is not required in order to generally mine or signal for segwit in the software. And we can go further still: without too much work, we could make further improvements to accommodate miners who, for whatever reason, don't want to upgrade their systems, such as by improving block relay from pre-segwit peers [1], or optimizing transaction selection for miners who are willing to enforce the segwit rules but haven't upgraded their systems to mine segwit blocks [2]. If we would seek to activate a soft-fork with less clear miner signaling (such as BIP 149), then I think such improvements are warranted to minimize network disruption. In general, we should not seek to censor hashpower on the network unless we have a very important reason for doing so. While the issues here are nuanced, if I were to evaluate the BIP 148 soft-fork proposal on the spectrum of "censorship attack on Bitcoin" to "benign protocol upgrade", BIP 148 strikes me as closer to the former than the latter. There is simply no need here to orphan these non-signalling blocks that could otherwise be used to secure the network. To go further: I think BIP 148 is ill-conceived even for achieving its own presumed goals -- the motivation for adding a consensus rule that applies to the version bits on blocks is surely for the effect such bits have on older software, such as Bitcoin Core releases 0.13.1 and later. Yet in trying to bring those implementations along as segwit-enforcing software, BIP 148 would risk forking from such clients in the short term! If one really cared about maintaining consensus with older, segwit-enabled software, it would make far more sense to seek segwit activation in a way that didn't fork from them (such as BIP 149, or a new BIP 9 deployment after this one times out). And if one doesn't care about such consensus, then it'd be far simpler to just set (e.g.) August 1 as the flag day activation of segwit, and not play these contortionist games with block version bits, which carry no useful or intrinsic meaning. Either of these two approaches should have the advantage of reduced fork risk, compared with BIP 148. Of course, everyone is free to run the software of their choosing. I write this to both generally convey my opposition to a careless proposal, which I believe represents a way of thinking that is detrimental to Bitcoin's long run success, and specifically explain why I oppose inclusion of this proposal in the Bitcoin Core implementation [3]. The Bitcoin Core project hasn't been, and shouldn't be, careless in deploying consensus changes. Instead, I think the Bitcoin Core project ought to stand up for the best practices that our community has learned about how to deploy such changes (specifically for minimizing chain-split risk when deploying a soft fork!), and I think we should all avoid adoption or encouragement of practices that would depart from
Re: [bitcoin-dev] Drivechain -- Request for Discussion
On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > In the future, when there is no block subsidy, a rich attacker can also do > that in mainchain Bitcoin. > I don't think they are the same. With Bitcoin, you only get to reverse recent transactions. If you actually reversed 2-3 weeks of transactions, then the Bitcoin price would fall, destroying the value of the additional coins you managed to obtain. Even if their was no price fall, you can only get a fraction of the total. With BMM, you can "buy" the entire reserve of the sidechain by paying (timeout) * (average tx fees). If you destroy a side-chain's value, then that doesn't affect the value of the bitcoins you manage to steal. The incentive could be eliminated by restricting the amount of coin that can be transferred from the side chain to the main chain to a fraction of the transaction fee pay to the bitcoin miners. If the side chain pays x in fees, then at most x/10 can be transferred from the side chain to the main chain. This means that someone who pays for block creation can only get 10% of that value transferred to the main chain. Main-chain miners could support fraud proofs. A pool could easily run an archive node for the side chain in a different data center. This wouldn't harm the performance of their main operations, but would guarantee that the side chain data is available for side chain validators. The sidechain to main-chain timeout would be more than enough for fraud proofs to be constructed. This means that the miners would need to know what the rules are for the side chain, so that they can process the fraud proofs. They would also need to run SPV nodes for the side chain, so they know which sidechain headers to blacklist. > In point of fact, the transactions *are* validated...by sidechain full > nodes, same as Bitcoin proper. > > The big difference is that Bitcoin holds no assets on another chain. A side-chain's value is directly linked to the fact that it has 100% reserves on the Bitcoin main chain. That can be targeted for theft. > Paul > > > Regards, > ZmnSCPxj > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A proposal to reintroduce the disabled script opcodes
My OP_CAT usecase only needs to glue together hash outputs, so two 32 Bytes inputs generating a 64 Byte output. However increasing this would enable additional space savings. I would push for an OP_CAT which can generate an output of no greater than 512 Bytes. Is there are maximum byte vectors size for script? The ideal instruction for this usecase be an instruction that pops N vectors of the stack, concatenates them together and hashes them. OP_CATHASH256(N) --> OP_HASH256(v1||v2||..||vN) where || denotes concatenation. You could do this in a streaming fashion so that memory usage would never exceed 32 Bytes regardless of the size of the input vectors. However I recognize that OP_CAT is more generally useful and it already in scripts but just disabled. On Mon, May 22, 2017 at 12:14 PM, Peter Todd wrote: > On Mon, May 22, 2017 at 10:41:40AM -0400, Ethan Heilman wrote: >> >It'd help your case if you gave us some examples of such scripts being >> used. >> >> I want OP_CAT so that I can securely and compactly verify many hashes and >> hash preimages. This would shrink offchain Tumblebit transactions >> significantly. >> >> For instance if I want a transaction TxA which checks that a transaction >> TxB releases preimages x1,x2,...,x10 such that >> y1=H(x1), y2=H(x2),...,y10=H(x10). Currently I just put y1,...y10 and check >> that the preimahes hash correctly. With OP_CAT I would only have to store >> one hash in TxA, yhash >> >> ytotal = H(OP_CAT(H(OP_CAT(y1, y2)),y3)...y10) >> >> TxA could then just hash all the preimages supplied by TxB and confirm they >> hash to TxA. This would reduce the size of TxA from approx 10*32B to >> 32+10*16B. I have a version which improves this further but it is more >> complex. >> >> Most of the math OP codes aren't particularly helpful due to their 32bit >> nature and their strange overflow behavior. > > Great! That's exactly the type of justifying use-case we need for a BIP. > > An OP_CAT will have to have limits on maximum output size; how big an output > does your application need? > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org ___ 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 May 22, 2017 10:39 AM, "ZmnSCPxj" wrote: Good morning Paul, I read only http://www.truthcoin.info/blog/blind-merged-mining/ >From just this document, I can't see a good justification for believing that a main->side locking transaction can be safely spent into a side->main unlocking transaction. Do you have a better explanation? Yes, a better explanation is in the drivechain spec, at: http://www.truthcoin.info/blog/drivechain/ What you read is only an introduction of BMM. You may also consult the notes (at the bottom of the BMM post) or the code, although this is time consuming of course. If I attempt to spend a main->side locking transaction on the basis of a "mistaken" side block #49, what prevents me from this sequence: The literal answer to your question is that mainchain Bitcoin will notice that, for the second withdrawal, the sum of the inputs is less than the sum of the outputs and they the transaction is therefore invalid. 1. Put a side:side->main transaction into a block together with TheDAO's hacked money. So far, the only good side->main transfer I know of is in Blockstream's original sidechains paper, with the main:side->main transaction ... Is your proposal at the technical level actually similar, or does it truly seem to be riskier? I feel that my proposal is more secure, as it can operate healthily and quickly while using spv proofs which are much slower and much much easier to audit. seems to me that your OP_is_h_in_coinbase should scan a series of sidechain block headers backed by mainchain (meaning at the minimum that sidechains should have some common header format prefix), rather than just mainchain depth as your article seems to imply. How would security be improved as a result? In either case, 51% of hashrate can cause a reorg. The sidechain software itself does scan block headers, of course. Blind merged mining seems strictly inferior ... a rich attacker can simply reorg the sidechain outright without playing such games. In the future, when there is no block subsidy, a rich attacker can also do that in mainchain Bitcoin. Or is your proposal strictly for centralized sidechains, where only one entity creates side blocks? Not at all. How does your proposal handle multiple side block creators on the same sidechain, with the possibility that chain splits occur? The side block is only "mined" if it is committed to in a mainchain Bitcoin blog, and each mainchain block can only contain one block per sidechain. In this way, drivechain sidechains are different from classical Namecoin merged mining (where one _could_ run the entire system, mining included, without interfacing with Bitcoin at all). Regarding your dig about people who dislike data centers, the main issue with miners blindly accepting sidechain commitments is that it violates "Don't trust, verify", not that allows datacenters to be slightly smaller by not including side:nodes. As I explain early on, in earlier rounds of peer review, the focus was on harms the sidechain technology might do to mainchain Bitcoin, and the "datacenter point" was specifically the chief objection raised. So I am afraid you are entirely incorrect. In point of fact, the transactions *are* validated...by sidechain full nodes, same as Bitcoin proper. Paul Regards, ZmnSCPxj Sent with ProtonMail Secure Email. Original Message Subject: [bitcoin-dev] Drivechain -- Request for Discussion Local Time: May 22, 2017 6:17 AM UTC Time: May 22, 2017 6:17 AM From: bitcoin-dev@lists.linuxfoundation.org To: Bitcoin Dev Dear list, I've been working on "drivechain", a sidechain enabling technology, for some time. * The technical info site is here: www.drivechain.info * The changes to Bitcoin are here: https://github.com/drivechain-project/bitcoin/tree/mainchainBMM * A Blank sidechain template is here: https://github.com/drivechain-project/bitcoin/tree/sidechainBMM As many of you know, I've been seeking feedback in person, at various conferences and meetups over the past year, most prominently Scaling Milan. And I intend to continue to seek feedback at Consensus2017 this week, so if you are in NYC please just walk up and start talking to me! But I also wanted to ask the list for feedback. Initially, I was hesitant because I try not to consume reviewers' scarce time until the author has put in a serious effort. However, I may have waiting too long, as today it is actually quite close to a working release. Scaling Implications - This upgrade would have significant scaling implications. Since it is the case that sidechains can be added by soft fork, and since each of these chains will have its own blockspace, this theoretically removes the blocksize limit from "the Bitcoin system" (if one includes sidechains as part of such a system). People who want a LargeBlock bitcoin can just move their BTC over to such a network [1], and their txns will have no longer have an impact on "Bitcoin Core
Re: [bitcoin-dev] A proposal to reintroduce the disabled script opcodes
On Mon, May 22, 2017 at 10:41:40AM -0400, Ethan Heilman wrote: > >It'd help your case if you gave us some examples of such scripts being > used. > > I want OP_CAT so that I can securely and compactly verify many hashes and > hash preimages. This would shrink offchain Tumblebit transactions > significantly. > > For instance if I want a transaction TxA which checks that a transaction > TxB releases preimages x1,x2,...,x10 such that > y1=H(x1), y2=H(x2),...,y10=H(x10). Currently I just put y1,...y10 and check > that the preimahes hash correctly. With OP_CAT I would only have to store > one hash in TxA, yhash > > ytotal = H(OP_CAT(H(OP_CAT(y1, y2)),y3)...y10) > > TxA could then just hash all the preimages supplied by TxB and confirm they > hash to TxA. This would reduce the size of TxA from approx 10*32B to > 32+10*16B. I have a version which improves this further but it is more > complex. > > Most of the math OP codes aren't particularly helpful due to their 32bit > nature and their strange overflow behavior. Great! That's exactly the type of justifying use-case we need for a BIP. An OP_CAT will have to have limits on maximum output size; how big an output does your application need? -- 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] Drivechain -- Request for Discussion
Good morning Paul, I read only http://www.truthcoin.info/blog/blind-merged-mining/ From just this document, I can't see a good justification for believing that a main->side locking transaction can be safely spent into a side->main unlocking transaction. Do you have a better explanation? OP_is_h_in_coinbase, as described, does not seem to protect against a sidechain reorg in your next section of the document. If I attempt to spend a main->side locking transaction on the basis of a "mistaken" side block #49, what prevents me from this sequence: 1. Put a side:side->main transaction into a block together with TheDAO's hacked money. 2. Wait for a reorg to revert TheDAO. 3. Spend my now-free-in-the-reorg funds on Lightning Network to get mainchain funds. 4. Create a main:side->main transaction with the side:side->main transaction in the TheDAO-hacked block as witness. 5. Get another set of mainchain funds from the same sidechain funds. So far, the only good side->main transfer I know of is in Blockstream's original sidechains paper, with the main:side->main transaction spending into a timelocked transaction that may be burned if a reorg proof is submitted (i.e. you try to create a main:side->main transaction with the side:side->main transaction in the mistaken #49 and #50 as your proof, but someone else can come along and show a corrected #49, #50, #51 without your side:side->main transaction and burn your funds). Is your proposal at the technical level actually similar, or does it truly seem to be riskier? It seems to me that your OP_is_h_in_coinbase should scan a series of sidechain block headers backed by mainchain (meaning at the minimum that sidechains should have some common header format prefix), rather than just mainchain depth as your article seems to imply. Also, blinded merge mining seems strictly inferior to proof-of-burn: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007012.html Proof-of-burn integrates a lottery to reduce the ability of a mainchain-rich attacker to reorg the sidechain by burning its greater funds. However it still seems to me that a rich attacker can simply make more bets in that scheme by some trivial modification of the side block. Blind merged mining seems strictly inferior as a rich attacker can simply reorg the sidechain outright without playing such games. Or is your proposal strictly for centralized sidechains, where only one entity creates side blocks? How does your proposal handle multiple side block creators on the same sidechain, with the possibility that chain splits occur? Regarding your dig about people who dislike data centers, the main issue with miners blindly accepting sidechain commitments is that it violates "Don't trust, verify", not that allows datacenters to be slightly smaller by not including side:nodes. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. Original Message Subject: [bitcoin-dev] Drivechain -- Request for Discussion Local Time: May 22, 2017 6:17 AM UTC Time: May 22, 2017 6:17 AM From: bitcoin-dev@lists.linuxfoundation.org To: Bitcoin Dev Dear list, I've been working on "drivechain", a sidechain enabling technology, for some time. * The technical info site is here: www.drivechain.info * The changes to Bitcoin are here: https://github.com/drivechain-project/bitcoin/tree/mainchainBMM * A Blank sidechain template is here: https://github.com/drivechain-project/bitcoin/tree/sidechainBMM As many of you know, I've been seeking feedback in person, at various conferences and meetups over the past year, most prominently Scaling Milan. And I intend to continue to seek feedback at Consensus2017 this week, so if you are in NYC please just walk up and start talking to me! But I also wanted to ask the list for feedback. Initially, I was hesitant because I try not to consume reviewers' scarce time until the author has put in a serious effort. However, I may have waiting too long, as today it is actually quite close to a working release. Scaling Implications - This upgrade would have significant scaling implications. Since it is the case that sidechains can be added by soft fork, and since each of these chains will have its own blockspace, this theoretically removes the blocksize limit from "the Bitcoin system" (if one includes sidechains as part of such a system). People who want a LargeBlock bitcoin can just move their BTC over to such a network [1], and their txns will have no longer have an impact on "Bitcoin Core". Thus, even though this upgrade does not actually increase "scalability" per se, it may in fact put an end to the scalability debate...forever. This work includes the relatively new concept of "Blind Merged Mining" [2] which I developed in January to allow SHA256^2 miners to merge-mine these "drivechains", even if these miners aren't running the actual sidechain software. The goal is to prevent sidechains from affecting the levelness
Re: [bitcoin-dev] Drivechain -- Request for Discussion
Charlie, I'll be mostly in the tech track, of course. And I've already
planned to meet RSK guys after their event tomorrow.
Ryan, the more review the better. We aren't in any direct rush, other than
the natural desire to have cool things as early as possible.
Peter, responses below:
On May 22, 2017 9:33 AM, "Peter Todd" wrote:
On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote:
> This work includes the relatively new concept of "Blind Merged Mining"
> [2] which I developed in January to allow SHA256^2 miners to merge-mine
> these "drivechains", even if these miners aren't running the actual
> sidechain software. The goal is to prevent sidechains from affecting the
> levelness of the mining "playing field". BMM is conceptually similar to
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
> required for drivechain, but it would address some of the last remaining
> concerns.
Thanks for the credit, although I think the security properties of what
you're
proposing are very different - and much weaker - than what I proposed in
Zookeyv.
As you state in [2] "if miners never validate sidechains at all, whoever
bids
the most for the chain (on a continuous basis), can spam a 3-month long
stream
of invalid headers, and then withdraw all of the coins deposited to the
sidechain." and "Since the mining is blind, and the sidechain-withdrawal
security-level is SPV, miners who remain blind forever have no way of
telling
who “should” really get the funds."
Finally, you suggest that in this event, miners *do* have to upgrade to a
full
node, an expensive and time-consuming operation (and one that may be
impossible
for some miners if necessary data isn't available).
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.
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.
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.
It's unclear to me what the incentive is for miners to do any of this. Could
you explain in more detail what that incentive is?
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.
Paul
> [2] http://www.truthcoin.info/blog/blind-merged-mining/
> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
--
https://petertodd.org 'peter'[:-1]@petertodd.org
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A proposal to reintroduce the disabled script opcodes
>It'd help your case if you gave us some examples of such scripts being used. I want OP_CAT so that I can securely and compactly verify many hashes and hash preimages. This would shrink offchain Tumblebit transactions significantly. For instance if I want a transaction TxA which checks that a transaction TxB releases preimages x1,x2,...,x10 such that y1=H(x1), y2=H(x2),...,y10=H(x10). Currently I just put y1,...y10 and check that the preimahes hash correctly. With OP_CAT I would only have to store one hash in TxA, yhash ytotal = H(OP_CAT(H(OP_CAT(y1, y2)),y3)...y10) TxA could then just hash all the preimages supplied by TxB and confirm they hash to TxA. This would reduce the size of TxA from approx 10*32B to 32+10*16B. I have a version which improves this further but it is more complex. Most of the math OP codes aren't particularly helpful due to their 32bit nature and their strange overflow behavior. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A proposal to reintroduce the disabled script opcodes
On Fri, May 19, 2017 at 09:07:41AM +0300, Mark Boldyrev via bitcoin-dev wrote:
> Back in 2010, there was a bug found in Core which allowed denial-of-service
> attacks due to the software crashing on some machines while executing a
> script - see CVE-2010-537.
> I believe the removed ("disabled") opcodes should be re-introduced along
> with a standardized behavior definition.
> For example, when execution of an opcode results in an arithmetic error,
> such as OP_DIV with a zero divisor, the script should exit and fail.
> The string splice opcodes should also check their arguments for
> correctness, etc.
>
> These opcodes would enhance the flexibility of scripts and allow
> sophisticated native smart contracts to be created.
It'd help your case if you gave us some examples of such scripts being used.
See the CHECKSEQUENCEVERIFY and my own CHECKLOCKTIMEVERIFY bips for examples of
how to write up such use-cases.
--
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] 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: > MerkleRoot := SHA256(SHA256(LeftRoot ⋅ RightRoot)) > sha256Compress : Word256 × Word512 -> Word256 To be clear, what math operations do you mean by "⋅" and "×"? -- 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] Drivechain -- Request for Discussion
On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote: > This work includes the relatively new concept of "Blind Merged Mining" > [2] which I developed in January to allow SHA256^2 miners to merge-mine > these "drivechains", even if these miners aren't running the actual > sidechain software. The goal is to prevent sidechains from affecting the > levelness of the mining "playing field". BMM is conceptually similar to > ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not > required for drivechain, but it would address some of the last remaining > concerns. Thanks for the credit, although I think the security properties of what you're proposing are very different - and much weaker - than what I proposed in Zookeyv. As you state in [2] "if miners never validate sidechains at all, whoever bids the most for the chain (on a continuous basis), can spam a 3-month long stream of invalid headers, and then withdraw all of the coins deposited to the sidechain." and "Since the mining is blind, and the sidechain-withdrawal security-level is SPV, miners who remain blind forever have no way of telling who “should” really get the funds." Finally, you suggest that in this event, miners *do* have to upgrade to a full node, an expensive and time-consuming operation (and one that may be impossible for some miners if necessary data isn't available). It's unclear to me what the incentive is for miners to do any of this. Could you explain in more detail what that incentive is? > [2] http://www.truthcoin.info/blog/blind-merged-mining/ > [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log -- 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
I couldn't agree more. It would require however for the Devs to throw their weight behind this with a lot of momentum. Spoonnet has been under development for quite some time now. Counter offering SegWit plus Spoonnet 12-24 months later would be a very progressive stance that I think would catch the interest of large swaths of the community. I'd be curious to hear Johnson's opinion on this. How much more testing would his proposal require? Daniele -- > > Message: 1 > Date: Mon, 22 May 2017 11:23:22 +0200 > From: Hampus Sj?berg > To: shaolinfry > Cc: Bitcoin Protocol Discussion > > Subject: Re: [bitcoin-dev] Barry Silbert segwit agreement > Message-ID: > tq6f1omhkde...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I'm really happy to see people trying to cooperate to get SegWit activated. > But I'm really unsure about the technicalities about Silbert's proposal. > > If we're going to do a hardfork, it makes most sense to assist Johnson in > his spoonnet/forcenet proposals. > Just doing a simple 2MB without fixing anything else is very uninteresting, > and a hardfork without addressing replay protection seems really > unprofessional to me. > And proposing a hardfork in 4 months in the future, is completely insane. > You cannot expect a 100% of all nodes in P2P network to upgrade in 4 > months. > > I think it's much better to activate BIP141 ASAP, and then hardfork to 2MB > September 2018, or 2019 (together with forcenet/spoonnet). > And if not, BIP148 is gaining momentum once again so that sounds much more > interesting. > > Hampus > > 2017-05-22 8:12 GMT+02:00 shaolinfry via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org>: > > > Someone sent me a copy of the Barry Silbert agreement, an agreement > forged > > between a select number of participants https://pastebin.com/VuCYteJh > > > > Participants agree to immediately activate Segwit, however, under a > > different activation proposal. Since I have spent the last few months > > researching various activation strategies of the current BIP141 > deployment, > > as well as redeployment, I feel I am quite well placed to comment on the > > technicalities. > > > > To be clear, the proposal as far as I can see does not activate BIP141, > > but is a completely new deployment which would be incompatible with the > > BIP141 deployment. I'm not sure how that can be considered "immediate" > > activation. Surely immediate activation would just be for miners to start > > signalling and segwit would be activated in 4-5 weeks. The proposal seems > > to require a lower 80% threshold, I assume because they were unable to > > convince 95% of the hashpower to go trigger activation. > > > > There are a few options to activating segwit now, the first being for 95% > > of hashrate to signal. The second is for the community to deploy BIP148 > > UASF which will force miners to signal segwit. Being a UASF it is date > > triggered. The third option is a redeployment of segwit on a new bit, but > > requires waiting for the existing deployment to time out, because all the > > p2p messages and service bits related to segwit must be replaced too > (which > > is what BIP149 does). > > > > A fourth option, first suggested to me by James Hilliard, was to make > > BIP148 miner triggered (MASF) with a lower threshold, above 50%. I coded > > this up a few weeks ago https://github.com/bitcoin/ > > bitcoin/compare/master...shaolinfry:segsignal but didnt get around to > > posting to the ML yet. This effectively lowers the threshold from 95% to > > 65% as coded, or could be upped to 80% or whatever was preferable. > > > > I think this removes the primary risk of BIP148 causing the creation of > > two chains, and gives an improved chance to get segwit activated quickly > > (assuming a majority of miners wish to go this route). But hash a primary > > disadvantage of still leaving the activation in the hands of miners. If > it > > doesn't work out, then BIP149 can then be used as proposed, but it'll be > > even safer because we'll have futher guaged support. > > > > References: > > > > SEGSIGNAL: https://github.com/bitcoin/bitcoin/compare/master... > > shaolinfry:segsignal > > BIP148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki > > BIP149: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki > > > > I think the Barry Silbert agreement is very ill considered, and clearly > > lacking peer review from the technical community. Suggestions of a HF in > 4 > > months are completely unrealistic and without technical merits. But more > > importantly, closed door agreements between selected participants is not > > how to garner consensus to change a $30bn decentralized system. The > purpose > > of my email is to try and assist in the "immediate activation of segwit" > > which only requires hashrate to participate; and to provide some > techincal > > input since I have
[bitcoin-dev] BIP135 implementation on Bitcoin Core available for review
I'm pleased to announce the completion of a Bitcoin Core implementation of BIP135: https://github.com/bitcoin/bitcoin/pull/10437 Review comments appreciated, and happy to discuss / answer questions about the implementation in this thread or on Github. Sancho BIP135: https://github.com/bitcoin/bips/blob/master/bip-0135.mediawiki___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Drivechain -- Request for Discussion
Dear list, I've been working on "drivechain", a sidechain enabling technology, for some time. * The technical info site is here: www.drivechain.info * The changes to Bitcoin are here: https://github.com/drivechain-project/bitcoin/tree/mainchainBMM * A Blank sidechain template is here: https://github.com/drivechain-project/bitcoin/tree/sidechainBMM As many of you know, I've been seeking feedback in person, at various conferences and meetups over the past year, most prominently Scaling Milan. And I intend to continue to seek feedback at Consensus2017 this week, so if you are in NYC please just walk up and start talking to me! But I also wanted to ask the list for feedback. Initially, I was hesitant because I try not to consume reviewers' scarce time until the author has put in a serious effort. However, I may have waiting too long, as today it is actually quite close to a working release. Scaling Implications - This upgrade would have significant scaling implications. Since it is the case that sidechains can be added by soft fork, and since each of these chains will have its own blockspace, this theoretically removes the blocksize limit from "the Bitcoin system" (if one includes sidechains as part of such a system). People who want a LargeBlock bitcoin can just move their BTC over to such a network [1], and their txns will have no longer have an impact on "Bitcoin Core". Thus, even though this upgrade does not actually increase "scalability" per se, it may in fact put an end to the scalability debate...forever. This work includes the relatively new concept of "Blind Merged Mining" [2] which I developed in January to allow SHA256^2 miners to merge-mine these "drivechains", even if these miners aren't running the actual sidechain software. The goal is to prevent sidechains from affecting the levelness of the mining "playing field". BMM is conceptually similar to ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not required for drivechain, but it would address some of the last remaining concerns. Total Transaction Fees in the Far Future - Some people feel that a maximum blocksize limit is needed to ensure that future total equilibrium transaction fees are non-negligible. I presented [4] on why I don't agree, 8 months ago. The reviewers I spoke to over the last year have stopped bringing this complaint up, but I am not sure everyone feels that way. Juxtaposition with a recent "Scaling Compromise" - Recently, a scalability proposal began to circulate on social media. As far as I could tell, it goes something like "immediately activate SegWit, and then HF to double the nonwitness blockspace to 2MB within 12 months". But such a proposal is quite meager, compared to a "LargeBlock Drivechain". The drivechain is better on both fronts, as it would not require a hardfork, and could *almost immediately* add _any_ amount of extra blockspace (specifically, I might expect a BIP101-like LargeBlock chain that has an 8 MB maxblocksize, which doubles every two years). In other words, I don't know why anyone would support that proposal over mine. The only reasons would be either ignorance (ie, unfamiliarity with drivechain) or because there are still nagging unspoken complaints about drivechain which I apparently need to hear and address. Other Thoughts --- Unfortunately, anyone who worked on the "first generation" of sidechain technology (the skiplist) or the "second generation" (federated / Liquid), will find that this is very different. I will admit that I am very pessimistic about any conversation that involves scalability. It is often said that "talking politics lowers your IQ by 25 points". Bitcoin scalability conversations seem to drain 50 points. (Instead of conversing, I think people should quietly work on whatever they are passionate about until their problem either is solved, or it goes away for some other reason, or until we all agree to just stop talking about it.) Cheers, Paul [1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling [2] http://www.truthcoin.info/blog/blind-merged-mining/ [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log [4] https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Barry Silbert segwit agreement
I'm really happy to see people trying to cooperate to get SegWit activated. But I'm really unsure about the technicalities about Silbert's proposal. If we're going to do a hardfork, it makes most sense to assist Johnson in his spoonnet/forcenet proposals. Just doing a simple 2MB without fixing anything else is very uninteresting, and a hardfork without addressing replay protection seems really unprofessional to me. And proposing a hardfork in 4 months in the future, is completely insane. You cannot expect a 100% of all nodes in P2P network to upgrade in 4 months. I think it's much better to activate BIP141 ASAP, and then hardfork to 2MB September 2018, or 2019 (together with forcenet/spoonnet). And if not, BIP148 is gaining momentum once again so that sounds much more interesting. Hampus 2017-05-22 8:12 GMT+02:00 shaolinfry via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > Someone sent me a copy of the Barry Silbert agreement, an agreement forged > between a select number of participants https://pastebin.com/VuCYteJh > > Participants agree to immediately activate Segwit, however, under a > different activation proposal. Since I have spent the last few months > researching various activation strategies of the current BIP141 deployment, > as well as redeployment, I feel I am quite well placed to comment on the > technicalities. > > To be clear, the proposal as far as I can see does not activate BIP141, > but is a completely new deployment which would be incompatible with the > BIP141 deployment. I'm not sure how that can be considered "immediate" > activation. Surely immediate activation would just be for miners to start > signalling and segwit would be activated in 4-5 weeks. The proposal seems > to require a lower 80% threshold, I assume because they were unable to > convince 95% of the hashpower to go trigger activation. > > There are a few options to activating segwit now, the first being for 95% > of hashrate to signal. The second is for the community to deploy BIP148 > UASF which will force miners to signal segwit. Being a UASF it is date > triggered. The third option is a redeployment of segwit on a new bit, but > requires waiting for the existing deployment to time out, because all the > p2p messages and service bits related to segwit must be replaced too (which > is what BIP149 does). > > A fourth option, first suggested to me by James Hilliard, was to make > BIP148 miner triggered (MASF) with a lower threshold, above 50%. I coded > this up a few weeks ago https://github.com/bitcoin/ > bitcoin/compare/master...shaolinfry:segsignal but didnt get around to > posting to the ML yet. This effectively lowers the threshold from 95% to > 65% as coded, or could be upped to 80% or whatever was preferable. > > I think this removes the primary risk of BIP148 causing the creation of > two chains, and gives an improved chance to get segwit activated quickly > (assuming a majority of miners wish to go this route). But hash a primary > disadvantage of still leaving the activation in the hands of miners. If it > doesn't work out, then BIP149 can then be used as proposed, but it'll be > even safer because we'll have futher guaged support. > > References: > > SEGSIGNAL: https://github.com/bitcoin/bitcoin/compare/master... > shaolinfry:segsignal > BIP148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki > BIP149: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki > > I think the Barry Silbert agreement is very ill considered, and clearly > lacking peer review from the technical community. Suggestions of a HF in 4 > months are completely unrealistic and without technical merits. But more > importantly, closed door agreements between selected participants is not > how to garner consensus to change a $30bn decentralized system. The purpose > of my email is to try and assist in the "immediate activation of segwit" > which only requires hashrate to participate; and to provide some techincal > input since I have done a great deal of research and development into the > topic. > > Given the history we've already passed the point where we should be > expecting miners to cooperate in lowering their own fee income with a > capacity increase; but we should be open to all reasonable options in the > interest in moving things forward in a safe and collaborative way. > > ___ > 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] A Method for Computing Merkle Roots of Annotated Binary Trees
## Introduction This document aims to specify and justify a method for computing Merkle roots for tree structures whose nodes are annotated with other data. While this proposal could be used to replace Bitcoin's Merkle root calculation, it is primarily aimed at new applications such as MAST, (U)TXO commitments or other Merklized structures. ## Background Bitcoin uses a Merkle tree construction to build a commitment to a sequence of transactions for a Bitcoin block. The main operation for computing a Merkle tree is one that takes the recursively computed Merkle roots of two branches and combines them to compute the Merkle root of the tree with those two branches. In Bitcoin, a Merkle root is 256 bits and the construction is MerkleRoot := SHA256(SHA256(LeftRoot ⋅ RightRoot)) One problem with this construction is that it is unnecessarily expensive. While the concatenation of the LeftRoot and the RightRoot fits in 512 bits, the size of a SHA256 chunk, a second chunk is needed to fit SHA256's padding. This means that inner SHA256 call invokes the SHA256 compression function twice, once for each chunk. The outer SHA256 call invokes the SHA256 compression function a third time. Bitcoin's Merkle root procedure calls the SHA256 compression function a total of three times per node. The main purpose of composing two calls to the SHA256 hash function is to protect against length extension attacks. A length extension attack is where an attacker has access to the hash of a message `HASH(msg)` and, without knowing `msg`, is able to construct the hash of a new message `HASH(msg ⋅ attackerMsg)`. This is attack is usually used against poorly constructed MACs (Message Authentication Codes). In the case of Bitcoin there are no secret messages that are hashed, so the outer call to SHA256 is unnecessary. As mentioned above, the inner call to SHA256 requires two chunks because of SHA256's padding. For the MerkleRoot construction added padding value is always 0x8000 0200 because the input is of a fixed length. SHA256's padding function is designed 1. to add bits to the message so that the resulting message size is a multiple of the chunk size (which is 512-bits in the case of SHA256). 2. to satisfy the Merkle--Damgård property which says that if we can find a hash collision in SHA256, which operates on variable length messages, then we can find a hash collision in SHA256's compression function, which operates on fixed length messages. We could remove the second call to the SHA256 compression function and use SHA256 without padding. If we did, we would lose the Merkle--Damgård property. While this may be acceptable for some use cases, we are still left with no room to add annotation data held at a node. For Bitcoin's Merkle tree this is not a problem, because its trees are not annotated. However, for other applications, we would need to add another chunk to hold the annotation, which would mean adding back the second call to the SHA256 compression function per node of the tree. ## A New Merkle Root Algorithm Below is an algorithm for computing Merkle roots that directly uses the SHA256 compression function. This algorithm operates on binary trees and supports per node annotations. Furthermore this proposal satisfies the Merkle--Damgård property and more. Remark 1 Any finitely branching tree can be represented by a binary tree, so this construction also applies to arbitrary finitely branching trees. The SHA256 compression function takes two inputs: 1. A 256-bit value for the previous chunk in a chain, or an initial vector in the case of the first chunk. 2. A 512-bit chunk of data. sha256Compress : Word256 × Word512 -> Word256 In total, the SHA256 compression function compresses 768-bits into 256-bits. The Merkle roots of two branches occupy 512 bits, and this leaves another 256-bits of space available for tags. Let us define a recursive type for binary trees annotated with tags. type Tree tag where Leaf : tag -> Tree tag Unary : tag × Tree tag-> Tree tag Binary : tag × Tree tag × Tree tag -> Tree tag We define a recursive algorithm for trees whose tags are 256-bit Words (or whose tags can be represented by 256-bit words). merkleRoot : Tree Word256 -> Word256 merkleRoot (Leaf (t)):= sha256Compress(sha256(ApplicationName), 0b0^256 ⋅ t) merkleRoot (Unary (t, child)):= sha256Compress(merkleRoot(child), 0b0^256 ⋅ t) merkleRoot (Binary (t, left, right)) := sha256Compress(merkleRoot(left), merkleRoot(right) ⋅ t) We need some initial value for the `Leaf` case. This could be taken as the initial vector for SHA256. However, I suggest using the hash of an application specific name. ApplicationName : BitString We further require that the tags dictate the kind of node it
