public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] Two Drivechain BIPs
@ 2017-12-01 18:38 Paul Sztorc
  2017-12-03 21:32 ` Matt Corallo
  0 siblings, 1 reply; 16+ messages in thread
From: Paul Sztorc @ 2017-12-01 18:38 UTC (permalink / raw)
  To: Bitcoin Dev; +Cc: luke_bipeditor

Hello,

First, Drivechain has vaguely escaped vaporware status. If you've ever
thought "I'd like to take a look into Drivechain when there is code",
then now is a pretty good time. (Unfinished items include M1, and M8_V2.)

https://github.com/drivechain-project/bitcoin/tree/mainchainBMM

Also,
Site:  http://www.drivechain.info/
Blank sidechain:
https://github.com/drivechain-project/bitcoin/tree/sidechainBMM

Second, I think drivechain's documentation / BIP-Drafts are tolerably
readable.

Here they are:

1.
https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md
2.
https://github.com/drivechain-project/docs/blob/master/bip2-blind-merged-mining.md

cc: Luke, I think they are ready to be assigned formal BIP Numbers.

This is also a request for code review. The most helpful review will
probably take place on GitHub.

Regular review is also welcome. Although, please read our
recently-updated FAQ, at: http://www.drivechain.info/faq .
And also see major earlier discussions:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014559.html

Have a nice weekend everyone,
Paul




^ permalink raw reply	[flat|nested] 16+ messages in thread

• * Re: [bitcoin-dev] Two Drivechain BIPs
    2017-12-01 18:38 [bitcoin-dev] Two Drivechain BIPs Paul Sztorc
  @ 2017-12-03 21:32 ` Matt Corallo
    2017-12-04 19:05   ` Paul Sztorc
    2017-12-05  7:41   ` Luke Dashjr
    0 siblings, 2 replies; 16+ messages in thread
  From: Matt Corallo @ 2017-12-03 21:32 UTC (permalink / raw)
    To: Paul Sztorc, Bitcoin Protocol Discussion; +Cc: luke_bipeditor
  
  Process note: It looks like the BIPs have never been posted to
  bitcoin-dev, only high-level discussion around the idea. As I understand
  it, this is *not* sufficient for BIP number assignment nor
  (realistically) sufficient to call it a hard "proposal" for a change to
  consensus rules.
  
  Would love to get feedback from some others who are looking at deploying
  real-world sidechains, eg the RSK folks. We can't end up with *two*
  protocols for sidechains in Bitcoin.
  
  Comments on BIP 1:
  
  At a high level, I'm rather dissapointed by the amount of data that is
  going into the main chain here. Things such as a human readable name
  have no place in the chain, IMO. Further, the use of a well-known
  private key seems misplaced, why not just track the sidechain balance
  with something that looks like `OP_NOPX genesis_block_hash`?
  
  I'm not convinced by the full semantics of proposal/ack of new
  sidechains. Given the lack of convincing evidence of that "Risk of
  centralisation of mining" drawback in section 4.3 of the sidechains
  paper has been meaningfully addressed, I'd say its pretty important that
  new sidechains be an incredibly rare event. Thus, a much simpler system
  (eg a version-bits-based upgrade cycle with high threshold) could be
  used to add new sidechains based on well-known public parameters.
  
  The semantics of the deposit process seem very suboptimal. You note that
  only one user can deposit at a time, but this seems entirely
  unnecessary. As implemented in the first Elements Alpha release (though
  I believe subsequently removed in later versions due to the nature of
  Elements of targeting asymmetric "federated" sidechains), if you have
  outputs that look like `OP_NOPX genesis_block_hash` as the sidechain
  deposit/storage address, deposit can be fully parallel. To reduce
  blockchain bloat, spending them for the purpose of combining such
  outputs is also allowed. You could even go further and allow some new
  sighash type to define something like SIGHASH_ALL|SIGHASH_ANYONECANPAY
  which further specifies some semantics for combining inputs which all
  pay into the same output.
  
  Finally, you may also want to explore some process for the removal of
  sidechain balances from the main chain. As proposed it seems like a
  sidechain might, over time, fade into an insecure state as mining power
  shifts and new miners no longer consider it worth the value to mine an
  old sidechain (as has happened over time with namecoin, arguably).
  
  
  Comments on BIP 2:
  
  I may be missing something, but I find the security model here kind of
  depressing...Not only do hashpower-secured sidechains already have a
  significantly reduced security level, but now you're proposing to
  further (drastically) reduce it by requiring users to potentially pay in
  excess of the value an attacker is willing to pay to keep their chain
  secure, on a recurring basis? It seems like if a chain has 10 BTC stored
  in it, and I wish to reorg it for a potential gain of, lets say, 6 BTC,
  I can pay 6 * 1 BTC (1 per block) to reorg it, and users on the chain
  would be forced to pay >6 BTC to avoid this?
  
  While I appreciate the desire to implement the proposed mitigation in
  section 4.3 of the sidechains paper (delegating the mining effort of a
  merge-mined sidechain to an external entity), I believe it was primarily
  referencing pooling the sidechain work, not blindly taking the highest
  bidder. I suppose, indeed, that, ultimately, as long as the sidechain is
  of relatively small value in comparison to BTC, miners do not risk the
  value of their BTC/mining investment in simply taking the highest bidder
  of a merge-mined block, even if its a clear attack, but I don't think
  thats something to be celebrated, encouraged, or designed to be possible
  by default. Instead, I'd, in line with Peter Todd's (and others')
  objection to merged mining generally, call this one of the most critical
  issues with the security model.
  
  Ultimately, I dont believe your proposal here really solves the drawback
  in section 4.3 of the paper, and possibly makes it worse. Instead, it
  may be more useful to rely on a high threshold for the addition of new
  sidechains, though I'd love to see discussion on this point specifically
  on this list. Further, I'd say, at a minimum, a very stable
  default-available low-bandwidth implementation of at least the
  pool-based mitigation suggested in the paper must exist for something
  like this to be considered readily stable enough to be deployed into the
  Bitcoin ecosystem.
  
  Matt
  
  On 12/01/17 13:38, Paul Sztorc via bitcoin-dev wrote:
  > Hello,
  > 
  > First, Drivechain has vaguely escaped vaporware status. If you've ever
  > thought "I'd like to take a look into Drivechain when there is code",
  > then now is a pretty good time. (Unfinished items include M1, and M8_V2.)
  > 
  > https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
  > 
  > Also,
  > Site:  http://www.drivechain.info/
  > Blank sidechain:
  > https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
  > 
  > Second, I think drivechain's documentation / BIP-Drafts are tolerably
  > readable.
  > 
  > Here they are:
  > 
  > 1.
  > https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md
  > 2.
  > https://github.com/drivechain-project/docs/blob/master/bip2-blind-merged-mining.md
  > 
  > cc: Luke, I think they are ready to be assigned formal BIP Numbers.
  > 
  > This is also a request for code review. The most helpful review will
  > probably take place on GitHub.
  > 
  > Regular review is also welcome. Although, please read our
  > recently-updated FAQ, at: http://www.drivechain.info/faq .
  > And also see major earlier discussions:
  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html
  > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014559.html
  > 
  > Have a nice weekend everyone,
  > Paul
  > 
  > 
  > _______________________________________________
  > bitcoin-dev mailing list
  > bitcoin-dev@lists•linuxfoundation.org
  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  > 
  
  
  ^ permalink raw reply	[flat|nested] 16+ messages in thread

• • * Re: [bitcoin-dev] Two Drivechain BIPs
      2017-12-03 21:32 ` Matt Corallo
    @ 2017-12-04 19:05   ` Paul Sztorc
      2017-12-04 19:36     ` Chris Pacia
      2017-12-05  7:41   ` Luke Dashjr
      1 sibling, 1 reply; 16+ messages in thread
    From: Paul Sztorc @ 2017-12-04 19:05 UTC (permalink / raw)
      To: Matt Corallo, Bitcoin Protocol Discussion
    
    Hi Matt,
    
    Thanks for very much for your thoughtful review
    
    Comments below.
    
    On 12/3/2017 4:32 PM, Matt Corallo wrote:
    > ...
    >
    > ...
    >
    > Comments on BIP 1:
    >
    > At a high level, I'm rather dissapointed by the amount of data that is
    > going into the main chain here. Things such as a human readable name
    > have no place in the chain, IMO.
    
    Well, that is quite a minor quibble, because it is just a one-time cost
    of 120 bytes per sidechain.
    
    To address it, there could instead be a hash commitment to this
    information. That commitment could be "optional", in that old nodes
    wouldn't need to possess the 120 bytes. Although, all of the sidechains
    are themselves optional. And old nodes will be ignoring all of this data
    anyways. So I do not think
    
    The inclusion of this field is deliberate. Probably, you do not buy my
    lengthy argument about "categorical control".
    
    http://www.drivechain.info/faq/#categorical-control
    
    Perhaps you have seen my May 2016 presentation on the topic. It was
    itself a lengthy reply to comments that Greg Maxwell made about the
    original Nov 2015 Drivechain post.
    
    https://www.youtube.com/watch?v=xGu0o8HH10U&list=PLw8-6ARlyVciMH79ZyLOpImsMug3LgNc4&index=1
    
    Either you aren't aware [of why I want each sidechain to have a
    comprehensible category]. Or, you are aware and you disagree. But if it
    is the latter we might just have to agree to disagree.
    
    > ....                                 Further, the use of a well-known
    > private key seems misplaced, why not just track the sidechain balance
    > with something that looks like `OP_NOPX genesis_block_hash`?
    
    I agree. I myself am unhappy with the private key approach, as it
    results in a totally pointless signature being generated, and a
    pointless CheckSig operation. (Somewhere, buried in
    documentation/GitHub-issue purgatory, there is a discussion of replacing
    it with OP TRUE.)
    
    Basically, our way was just a hack to make sure uses knew where they had
    to send the money, and also to get the balances to show up in all user's
    wallets. I do not pretend to have any expertise in this area (or even
    experience) so it is surely an area for improvement.
    
    >
    > I'm not convinced by the full semantics of proposal/ack of new
    > sidechains.  ...           I'd say its pretty important that
    > new sidechains be an incredibly rare event.
    
    Well, I partially agree.
    
    However, if drivechain is a soft fork, and if 51% hashrate can add new
    softforks at any time, then our ability to alter the rate of
    sidechain-creation is very low. While we might use the rules of
    "Drivechain I" to impose restrictions on the "add a sidechain" process,
    nothing prevents 51% hashrate from re-adding Drivechain to Core a second
    time, creating a "Drivechain II" system with its own "add a sidechain"
    rules. Thus, the activation speed can increase, even if miners are
    incapable of writing any code. Or, miners might add "Drivechain I" to
    one of the sidechains. (And of course the new-sidechain-rate can
    decrease, through mere miner-censorship.)
    
    So, I think there really is no threat model, other than to say: we
    either open Pandora's box or we do not. My vision (for any Redditors who
    may be reading this, years in the future!!) is of a stable, conservative
    Bitcoin Core with 3-8 sidechains, of which at least one is rather
    experimental, and at least one of which has its own sidechains. But who
    knows.
    
    More importantly, the problem you've outlined is much much worse for
    extension blocks.
    
    (It can scarcely be denied that hashrate wants more block space, and
    that they can easily add one or many extension blocks, in public or in
    secret, at any time. Will a UASF really be able to disable an in-use
    extension block? I think the UASF-case is much less persuasive,
    especially since it involves loss/freezing of user funds.)
    
    So I would argue that one of *the* greatest benefits of Drivechain is
    that it neutralizes the threat of extension blocks by giving everyone a
    better alternative. In fact, I do not know of any other way to
    neutralize this threat.
    
    >  ... Thus, a much simpler system
    > (eg a version-bits-based upgrade cycle with high threshold) could be
    > used to add new sidechains based on well-known public parameters.
    
    I don't have a problem with this. In fact that is mostly how we have it
    today.
    
    My concern is a scenario where:
    
    Person A: is running the latest version of Bitcoin (which has
    drivechain), and full nodes for 3 out of 3 sidechains
    Person B: is running the 2nd-latest version of Bitcoin (which has
    drivechain), and was disconnected when the 3rd sidechain activated
    Person C: is running the 3rd-latest version of Bitcoin (which has
    drivechain), but was disconnected for the activation of all sidechains.
    Person D: is running 0.5.3 and has no idea what drivechain is.
    
    Then, we consider a case where someone attempts a side-to-main
    withdrawal from sidechain #2, but which tries to cheat the drivechain
    rules (which are mainchain-enforced).
    
    In one setup, C's security is downgraded. But in other settings it is
    not. And in other settings it might do something complicated.
    
    (Although, I also plan to introduce minimum parameter values, both to
    prevent C from being harassed in this case, and to force all
    drivechain-killing actions to be comparable to each other.)
    
    My thought was to have all drivechain parts to either stand or fall by
    themselves. But I am open-minded on this.
    
    > The semantics of the deposit process seem very suboptimal. You note that
    > only one user can deposit at a time, but this seems entirely
    > unnecessary. As implemented in the first Elements Alpha release (though
    > I believe subsequently removed in later versions due to the nature of
    > Elements of targeting asymmetric "federated" sidechains), if you have
    > outputs that look like `OP_NOPX genesis_block_hash` as the sidechain
    > deposit/storage address, deposit can be fully parallel. To reduce
    > blockchain bloat, spending them for the purpose of combining such
    > outputs is also allowed. ....
    
    Well, your proposal doesn't reduce the bloat, it merely makes
    bloat-reduction possible. And your way relies (slightly) on
    miner-charity, because it imposes an opportunity cost on miners. (Miners
    could sell their blockspace for fees, but instead they must use it to
    make these combinations you describe.)
    
    In contrast, the one-user-deposits-at-a-time not only allows bloat to be
    addressed, but also forces it to be addressed. It is like forcing
    someone who uses a shared kitchen to leave it exactly as clean as they
    found it.
    
    While I am concerned by the one-at-a-time concept, I would point out:
    
    * It is NOT one deposit per block. Just one at a time. In general, there
    can be as many deposits as needed.
    * It will not be a problem if [a] transactions propagate very quickly,
    and [b] transactions are signed very quickly.
    * If the deposit fails, it will likely be easy for the user to re-do it
    (or, this will be made easy, in the UX eventually).
    * It may ultimately be the case, that the task of shepherding the coins
    around is one that is only ever performed by specialists. They would
    have their own ways of batching txns to deal with this issue. In
    contrast, regular users might always use atomic swaps / ShapeShift-like
    tools.
    
    Nonetheless, I think this is another opportunity for improvement.
    Probably, if someone goes deeper into the scripting language and block
    validation rules, they will be able to achieve all of the objectives
    simultaneously. As you say:
    
    > ...                       You could even go further and allow some new
    > sighash type to define something like SIGHASH_ALL|SIGHASH_ANYONECANPAY
    > which further specifies some semantics for combining inputs which all
    > pay into the same output.
    
    
    > Finally, you may also want to explore some process for the removal of
    > sidechain balances from the main chain. As proposed it seems like a
    > sidechain might, over time, fade into an insecure state as mining power
    > shifts and new miners no longer consider it worth the value to mine an
    > old sidechain (as has happened over time with namecoin, arguably).
    
    Yes, I think there should be some kind of switch for saying "please
    withdraw all of your funds because this chain is being closed down".
    However, if miners stopped mining a chain, I think sidechain-users would
    notice because their blocktimes would start to increase (under blind
    merged mining, anyway).
    
    
    > Comments on BIP 2:
    >
    > I may be missing something, but I find the security model here kind of
    > depressing...Not only do hashpower-secured sidechains already have a
    > significantly reduced security level, but now you're proposing to
    > further (drastically) reduce it by requiring users to potentially pay in
    > excess of the value an attacker is willing to pay to keep their chain
    > secure, on a recurring basis?
    
    I think you are missing a few things.
    
    First of all, I think the security model for sidechains is the same as
    that of every blockchain
    
    People will say things, like "but with sidechains 51% hashrate can steal
    your coins!", but as I have repeated many times, this is also true of
    mainchain btc-tx. As I say on drivechain.info:
    
     """ In theory, the incentives of miners and investors are very strongly
    aligned: both are compensated most when the exchange rate is highest.
    And, in practice, we do not see large reorganizations (where miners can
    “steal”, by first depositing BTC to major exchanges, then selling that
    BTC for fiat (which they withdraw), and finally rewriting the last 3 or
    4 days of chain history, to un-confirm the original deposits). These
    reorgs would devastate the exchange rate, as they would cast doubt on
    the entire Bitcoin experiment. The thesis of Drivechain is that
    sidechain-theft would also devastate the exchange rate, as it would cast
    doubt on the entire sidechain experiment (which would itself cast doubt
    on the Bitcoin experiment, given the anti-competitive power of
    sidechains). """
    
    In fact, it is true of everything, including the lightning network. LN
    has the advantage of allowing victims to spend the attacker's funds on
    tx fees (as these victims desperately try to get their txn included).
    But the LN loses the blockchain's "strength in numbers" advantage --
    miners can single-out unpopular individuals, figure out their channels,
    and steal from them (and only them) at an inopportune time.
    
    This is not to knock the lightning network -- I believe it is
    well-designed and likely to be secure. I am merely saying that this
    concept of stringing these security models on a line from "most secure"
    to "least secure" is a concept which is reductionist and incorrect.
    
    Drivechain will be more secure if sidechains are popular. But if they
    are not popular, the question of how secure they are is not really
    interesting, is it?
    
    Secondly, I think you have overlooked something very important indeed.
    Sidechains are optional, and so their use should be up to each
    individual user, and no one else. Users should be free to make their own
    mistakes -- specifically, they should be the ones to decide for
    themselves if they want to use an "insecure" system or not.
    
    It would be another matter, if you had a competing sidechain idea which
    accomplished the same goal. But you do not.
    
    Thirdly, I do not agree with your claim that the security model is
    reduced by BMM. In fact, the way I see it, it is the same as the model
    we already have, if not better.
    
    To make this point, let me ask: Who determines the contents (valid or
    otherwise) of "the next block that meets the difficulty requirement"?
    
    In Mainchain Bitcoin Core: "Highest Cumulative Difficulty"
    BMM Sidechain: "Highest BTC Payment"
    
    But these are actually the very same thing! We merely need to clarify
    our thinking with a few simplifications. First, substitute "Most Hashes"
    for "Cumulative Difficulty" (as these are expected converge to each
    other). Second, ignore *unexpected* fluctuations in the two denominator
    prices in the following:
    
    "Most Hashes" = "Most USD Spent on Mining" / (hashes-per-usd price)
    "Highest BTC Payment" = "Most USD Spent on Mining" / (btc-per-usd price)
    
    "Most Hashes" = "Highest BTC Payment" = "Most USD Spent on Mining"
    
    It should be clearer now that they are the same model. While the
    mainchain follows the heaviest chain, measured in hashes, the sidechain
    follows the heaviest chain, measured in BTC. Both are expressions of the
    same concept ("value sacrificed")...just expressed in different units.
    
    With that explained, let me bring in this:
    
    >      ...                  It seems like if a chain has 10 BTC stored
    > in it, and I wish to reorg it for a potential gain of, lets say, 6 BTC,
    > I can pay 6 * 1 BTC (1 per block) to reorg it, and users on the chain
    > would be forced to pay >6 BTC to avoid this?
    
    Your example (which is a great example) sounds bleak, but it is in fact
    the security model of Bitcoin itself, in the long future without the
    block subsidy. Likely, Bitcoin will have new advantages by then
    (assuming it survives that long). But this is a problem that just
    *can't* be solved without a new block subsidy (which can't be added to
    sidechains).
    
    So, you may be successfully arguing that sidechains can never work. (But
    that is different from saying that users should be prohibited from
    trying them out, as I said above). Or, you may be successfully arguing
    that Bitcoin itself will stop working when fees overwhelm the block
    subsidy. (Since that hour is rapidly approaching, we might as well start
    running experiments now).
    
    The equivalence between hashes and purchases is not perfect. Certainly,
    regular miners might be better-behaved than BM-miners, because r-miners
    stand to lose their entire hardware investment if the system fails,
    whereas BM-miners do not. On the other hand, BMM is *better* in a few
    ways, namely that it makes "mining" much more competitive, because it
    lowers the barriers to entry for sidechain-mining all the way to zero.
    Any node can do it. Furthermore, BM-miners are more cypherpunk-like:
    they will not be confined to any physical location, they do not give
    away their location (via power usage or thermal exhaust), when they
    greedily move into high-efficiency spaces (data centers, EC2 instances)
    they can instantly destroy themselves and reappear somewhere else.
    
    I'm not sure if that made you more, or less depressed. But here is a
    smiley face :-] .
    
    > While I appreciate the desire to implement the proposed mitigation in
    > section 4.3 of the sidechains paper (delegating the mining effort of a
    > merge-mined sidechain to an external entity), I believe it was primarily
    > referencing pooling the sidechain work, not blindly taking the highest
    > bidder.
    
    Well, BMM is more efficient when there are pools. Without them, the
    sidechain nodes would be trying to connect to all mainchain miners.
    
    And there's no need for that. In my view, pools are cannot really do
    anything wrong (ie, pools cannot do anything except what their members
    want them to do). If a pool operator goes rogue and attempts to censor a
    transaction, what has actually happened is just that the transaction is
    delayed (until the hashers learn about the inefficient policy, and
    switch pools). Same for everything else.
    
    In other words, yes pool operators would almost certainly be running a
    node of each sidechain.
    
    >  ...  I suppose, indeed, that, ultimately, as long as the sidechain is
    > of relatively small value in comparison to BTC, miners do not risk the
    > value of their BTC/mining investment in simply taking the highest bidder
    > of a merge-mined block, even if its a clear attack, ...
    
    It is not about the amount of BTC on the sidechain. It is about miner's
    estimations of user's valuation of their option to use the sidechain at
    any point in the future. The idea of "911 emergency response" is
    valuable, and people would complain about a motion to get rid of it,
    even though most of those people wouldn't currently be using it.
    
    > Ultimately, I dont believe your proposal here really solves the drawback
    > in section 4.3 of the paper, and possibly makes it worse.
    
    That is interesting because that section reads:
    
     """ As miners provide work for more blockchains, more resources are
    needed to track and validate them all. Miners that provide work for a
    subset of blockchains are compensated less than those which provide work
    for every possible blockchain. Smaller-scale miners may be unable to
    afford the full costs to mine every blockchain, and could thus be put at
    a disadvantage compared to larger, established miners who are able to
    claim greater compensation from a larger set of blockchains. """
    
     Which is exactly what BMM does address. It allows miners to ignore the
    resource-cost of the sidechain, and therefore smaller miners will not be
    at a revenue-disadvantage.
    
    Do you think that the drawback is something else?
    
    And, are you ever going to define "miner centralization"? Is it "the
    economic barrier-to-entry for mining", to you?
    
    Paul
    
    >
    > On 12/01/17 13:38, Paul Sztorc via bitcoin-dev wrote:
    >> Hello,
    >>
    >> First, Drivechain has vaguely escaped vaporware status. If you've ever
    >> thought "I'd like to take a look into Drivechain when there is code",
    >> then now is a pretty good time. (Unfinished items include M1, and M8_V2.)
    >>
    >> https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
    >>
    >> Also,
    >> Site:  http://www.drivechain.info/
    >> Blank sidechain:
    >> https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
    >>
    >> Second, I think drivechain's documentation / BIP-Drafts are tolerably
    >> readable.
    >>
    >> Here they are:
    >>
    >> 1.
    >>
    https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md
    >> 2.
    >>
    https://github.com/drivechain-project/docs/blob/master/bip2-blind-merged-mining.md
    >>
    >> cc: Luke, I think they are ready to be assigned formal BIP Numbers.
    >>
    >> This is also a request for code review. The most helpful review will
    >> probably take place on GitHub.
    >>
    >> Regular review is also welcome. Although, please read our
    >> recently-updated FAQ, at: http://www.drivechain.info/faq .
    >> And also see major earlier discussions:
    >>
    https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014364.html
    >>
    https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014559.html
    >>
    >> Have a nice weekend everyone,
    >> Paul
    >>
    >>
    >> _______________________________________________
    >> bitcoin-dev mailing list
    >> bitcoin-dev@lists•linuxfoundation.org
    >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    >>
    
    
    
    
    ^ permalink raw reply	[flat|nested] 16+ messages in thread

  • • * Re: [bitcoin-dev] Two Drivechain BIPs
        2017-12-04 19:05   ` Paul Sztorc
      @ 2017-12-04 19:36     ` Chris Pacia
        2017-12-04 20:11       ` Chris Stewart
        2017-12-05 18:05       ` Paul Sztorc
        0 siblings, 2 replies; 16+ messages in thread
      From: Chris Pacia @ 2017-12-04 19:36 UTC (permalink / raw)
        To: Paul Sztorc, Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 744 bytes --]
      
      I think you are missing a few things.
      
      First of all, I think the security model for sidechains is the same as
      that of every blockchain
      
      People will say things, like "but with sidechains 51% hashrate can steal
      your coins!", but as I have repeated many times, this is also true of
      mainchain btc-tx.  is something else?
      
      
      There are substantial opportunity costs as well as a collective action
      problem when it comes to re-writing the mainchain.
      
      Is there anything similar for drivechains? As far as I can tell there is no
      opportunity cost to casting a malicious vote, no repercussions, and no
      collective action barrier that needs to be overcome.
      
      Unless I'm missing something I wouldn't liken the security of a drivechain
      to that of the mainchain.
      
      [-- Attachment #2: Type: text/html, Size: 1376 bytes --]
      
      ^ permalink raw reply	[flat|nested] 16+ messages in thread

    • • * Re: [bitcoin-dev] Two Drivechain BIPs
          2017-12-04 19:36     ` Chris Pacia
        @ 2017-12-04 20:11       ` Chris Stewart
          2017-12-05 19:55         ` Paul Sztorc
          2017-12-05 18:05       ` Paul Sztorc
          1 sibling, 1 reply; 16+ messages in thread
        From: Chris Stewart @ 2017-12-04 20:11 UTC (permalink / raw)
          To: Chris Pacia, Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 4099 bytes --]
        
        >As far as I can tell there is no opportunity cost to casting a malicious
        vote, no repercussions, and no collective action barrier that needs to be
        overcome.
        
        There is another interesting analysis on BMM and drivechains from /u/almkglor
        on reddit
        <https://www.reddit.com/r/Bitcoin/comments/6ztp3b/lets_discuss_something_techrelated_for_a_change/dn0rsdo/>.
        I'm going to share here for visibility.
        
        The problem with drivechains and blind merged mining is the disconnect
        > between voting and "blind" merge mining. With BMM, a miner can do:
        >
        >    1. Not accept BMM, not vote.
        >    2. Not accept BMM, operate their own sidechain node, mine sidecoin,
        >    and vote correctly.
        >    3. Not accept BMM, always upvote (i.e. allow theft).
        >    4. Not accept BMM, always downvote (i.e. strangle).
        >    5. Accept BMM, not vote.
        >    6. Accept BMM, operate their own sidechain node, and vote correctly.
        >    (not mine sidecoin directly: they get paid in maincoin by sidecoin-only
        >    miners).
        >    7. Accept BMM, always upvote (i.e. allow theft).
        >    8. Accept BMM, always downvote (i.e. strangle).
        >
        > 3 and 7 will mean that non-verifying miners will be (inadvertently)
        > complicit in theft. Drivechains have 1008-block cycles ostensibly to
        > protect against theft, so that someone can "raise the alarm" and tell
        > miners to downvote a particular theft withdrawal, but that sounds too much
        > like centralized collusion to me.
        >
        > Strategy 8 will dominate over strategy 6, since the miner does not have to
        > run a sidechain node (reduced cost) while still earning the same as
        > strategy 6.
        >
        > Strategies 5->8 are all strictly superior to 1->4, so BMM does not really
        > change anything: strategy 8 (equivalent to strategy 4 if BMM is not
        > implemented) will still choke strategy 6 (equivalent to strategy 2 if BMM
        > is not implemented)
        >
        > It seems Drivechain's security model is: miners always upvote by default.
        > If a theft withdrawal is done on the mainchain, some sidechain nodes call
        > up their miner friends (which makes me worry about miner centralization) to
        > downvote it instead.
        >
        > The problem is: what if after a theft withdrawal is defeated, another
        > theft withdrawal is done? And another, and another? This weakens the peg:
        > while a theft withdrawal is on-going, a genuine withdrawal can't be posted
        > (at least as I understand Sztorc's explanation). This chokes the sidechain
        > withdrawal.
        >
        > The difference from maincoin is that attempts to choke the block are
        > somewhat costly and a maincoin user can offer a higher transaction fee to
        > beat the spam. If side->main is choked, no amount of sidecoin can be
        > offered to beat the spammed theft transactions.
        >
        > I don't know, it seems like very weak security to me.
        >
        TLDR: a miner is most profitable if he always accepts BMM bribes, but
        downvotes withdrawal transactions (WT). This obviously isn't ideal because
        a withdrawal will never occur from the drivechain if enough miners employ
        this strategy -- which seems to be the most profitable strategy.
        
        -Chris
        
        
        On Mon, Dec 4, 2017 at 1:36 PM, Chris Pacia via bitcoin-dev <
        bitcoin-dev@lists•linuxfoundation.org> wrote:
        
        >
        > I think you are missing a few things.
        >
        > First of all, I think the security model for sidechains is the same as
        > that of every blockchain
        >
        > People will say things, like "but with sidechains 51% hashrate can steal
        > your coins!", but as I have repeated many times, this is also true of
        > mainchain btc-tx.  is something else?
        >
        >
        > There are substantial opportunity costs as well as a collective action
        > problem when it comes to re-writing the mainchain.
        >
        > Is there anything similar for drivechains? As far as I can tell there is
        > no opportunity cost to casting a malicious vote, no repercussions, and no
        > collective action barrier that needs to be overcome.
        >
        > Unless I'm missing something I wouldn't liken the security of a drivechain
        > to that of the mainchain.
        >
        >
        > _______________________________________________
        > bitcoin-dev mailing list
        > bitcoin-dev@lists•linuxfoundation.org
        > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >
        >
        
        [-- Attachment #2: Type: text/html, Size: 5656 bytes --]
        
        ^ permalink raw reply	[flat|nested] 16+ messages in thread

      • • * Re: [bitcoin-dev] Two Drivechain BIPs
            2017-12-04 20:11       ` Chris Stewart
          @ 2017-12-05 19:55         ` Paul Sztorc
            2017-12-07  7:28           ` ZmnSCPxj
            0 siblings, 1 reply; 16+ messages in thread
          From: Paul Sztorc @ 2017-12-05 19:55 UTC (permalink / raw)
            To: Bitcoin Protocol Discussion
          
          [-- Attachment #1: Type: text/plain, Size: 5806 bytes --]
          
          Hi Other Chris,
          
          Thanks for pointing this out. Here are my responses.
          
          On 12/4/2017 3:11 PM, Chris Stewart wrote:
          >There is another interesting analysis on BMM and drivechains from
          /u/almkglor on reddit. I'm going to share here for visibility.
          >> 3 and 7 will mean that non-verifying miners will be (inadvertently)
          complicit in theft. Drivechains have 1008-block cycles ostensibly to
          protect against theft, so that someone can "raise the alarm" and tell
          miners to downvote a particular theft withdrawal, but that sounds too
          much like centralized collusion to me.
          
          Well, that is simply not what "centralized" means. "Centralized" means
          that one person has special, irreplaceable influence. In contrast,
          "decentralized" means that the process is not uniquely influenced by
          what any *one* individual does or believes. Which is the case here: each
          miner can independently make a decision about what to check, how to
          check it, and what to do as a result. They could do undertake this
          process, even if they ignored what everyone else was doing.
          
          >> ...
          >>
          >> It seems Drivechain's security model is: miners always upvote by
          default. If a theft withdrawal is done on the mainchain, some sidechain
          nodes call up their miner friends (which makes me worry about miner
          centralization) to downvote it instead.
          >>
          >> The problem is: what if after a theft withdrawal is defeated, another
          theft withdrawal is done? And another, and another? This weakens the
          peg: while a theft withdrawal is on-going, a genuine withdrawal can't be
          posted (at least as I understand Sztorc's explanation). This chokes the
          sidechain withdrawal.
          
          This is a good question.
          
          The answer is that there are mechanisms in place to address these
          problems. Contrary to the reviewer's interpretation, multiple
          withdrawal-attempts *are* allowed simultaneously. (This part of design
          may have changed between now and Nov 2015, and I'm not sure if it was
          ever documented anywhere until very recently). Second, only one
          withdrawal can be upvoted at a time [ie, per sidechain per main:block].
          Third, upvoting one withdrawal automatically downvotes all of the other
          withdrawals (all in-progress withdrawals for that sidechain). Thus, we
          have the asymmetry we desire. An "auditor class" can ignore all of the
          withdrawals, until a significant amount of time has been invested in one
          candidate. This makes the attempt more futile. Since they are unlikely
          to be meaninglessly harassed, this opens the door to a "farmer class"
          who can take it upon themselves to make sure the good withdrawals get
          in, and get upvotes (especially early upvotes). Thus, the system can
          tolerate a large "loafer class" who just lazily upvotes everything (or
          nothing, or only the front-runner).
          
          > TLDR: a miner is most profitable if he always accepts BMM bribes, but
          downvotes withdrawal transactions (WT). This obviously isn't ideal
          because a withdrawal will never occur from the drivechain if enough
          miners employ this strategy -- which seems to be the most profitable
          strategy.
          >
          >-Chris
          
          I agree that miners should "always accept BMM bribes". In my recent
          email to Matt Corallo, I described that this is basically the same as
          saying that miners should "always mine on top of the heaviest chain".
          (Of course, in mainchain Bitcoin miners are advised to mine atop the
          heaviest *valid* chain, which is different from this case. It is
          different because blind-merged-miners have no way of knowing if the
          sidechain blocks they are mining are valid or not, which is kind of the
          point. In practice I estimate that between 70% and 100% of today's
          hashpower is already mining the mainchain "blind" -- through some
          combination of pools, spv and spy mining.)
          
          I don't agree with the conclusion (that the optimal policy is "always
          downvoting", see above), but even if this analysis turns out to be
          correct, it isn't a total disaster. The result (which is in the original
          Nov 2015 specification) is that miners are the ones who perform the
          atomic swaps. Then they walk the coins side-to-main (which, at this
          point, are *their* coins). As long as there are a few large mining
          groups, competition will drive the atomic swap fees down to negligible
          levels. This slightly encourages mining to consolidate into two large
          pools...but of course that is also true of the status quo!
          
          Paul
           
          >
          > On Mon, Dec 4, 2017 at 1:36 PM, Chris Pacia via bitcoin-dev
          > <bitcoin-dev@lists•linuxfoundation.org
          > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote:
          >
          >
          >         I think you are missing a few things.
          >
          >         First of all, I think the security model for sidechains is the
          >         same as
          >         that of every blockchain
          >
          >         People will say things, like "but with sidechains 51% hashrate
          >         can steal
          >         your coins!", but as I have repeated many times, this is also
          >         true of
          >         mainchain btc-tx.  is something else?
          >
          >
          >     There are substantial opportunity costs as well as a collective
          >     action problem when it comes to re-writing the mainchain. 
          >
          >     Is there anything similar for drivechains? As far as I can tell
          >     there is no opportunity cost to casting a malicious vote, no
          >     repercussions, and no collective action barrier that needs to be
          >     overcome. 
          >
          >     Unless I'm missing something I wouldn't liken the security of a
          >     drivechain to that of the mainchain.
          >
          >     _______________________________________________
          >     bitcoin-dev mailing list
          >     bitcoin-dev@lists•linuxfoundation.org
          >     <mailto:bitcoin-dev@lists•linuxfoundation.org>
          >     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          >     <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
          >
          >
          
          
          [-- Attachment #2: Type: text/html, Size: 8459 bytes --]
          
          ^ permalink raw reply	[flat|nested] 16+ messages in thread

        • • * Re: [bitcoin-dev] Two Drivechain BIPs
              2017-12-05 19:55         ` Paul Sztorc
            @ 2017-12-07  7:28           ` ZmnSCPxj
              2017-12-12 22:16             ` Paul Sztorc
              0 siblings, 1 reply; 16+ messages in thread
            From: ZmnSCPxj @ 2017-12-07  7:28 UTC (permalink / raw)
              To: Paul Sztorc, Chris Stewart; +Cc: Bitcoin Protocol Discussion
            
            [-- Attachment #1: Type: text/plain, Size: 3528 bytes --]
            
            Good morning Paul and Chris,
            
            >I don't agree with the conclusion (that the optimal policy is "always downvoting", see above), but even if this analysis turns out to be correct, it isn't a total disaster. The result (which is in the original Nov
            >2015 specification) is that miners are the ones who perform the atomic swaps. Then they walk the coins side-to-main (which, at this point, are *their* coins). As long as there are a few large mining groups,
            >competition will drive the atomic swap fees down to negligible levels.
            
            Assuming there are three large mining groups who will ruthlessly want to undercut their competition, and with roughly 33% of total hashpower each (with the remaining 1% being some negligible hoi polloi), then one strategy to undercut your competitors would be to upvote only your own withdrawals and downvote that of your competitors.  A miner using this strategy hopes that the other miners will give up on withdrawing their own coin and trade their sidecoins at a discount to the undercutting miner.  That is, it is a hostage attempt of the sidecoin funds of the other miners.
            
            In the case of three large mining pools that mistrust one another, then, no withdrawal would ever push through and drivechains stabilize to one-way pegs.
            
            Now suppose that two of the mining pools collude.  They join their withdrawals into a single withdrawal proposal and upvote that, while downvoting the withdrawal of the third miner.  I observe that this is an opposite disaster: the 66% colluding miners can instead decide to simply outright make an invalid withdrawal of all funds, split up in half between themselves.
            
            --
            
            But three exactly equal mining pools is unnatural, for that matter
            
            Suppose that there are three mining pools: A with 34%, B with 33%, C with 32%, and the hoi polloi making up the remaining 1%.  Those three pools cannot safely let the others withdraw funds.
            
            Suppose A colludes with C to join their withdrawal proposals and their hashpower to withdraw.  This means that B can be pressured to sell its sidecoins for a discount to the joint coalition of A and C, since B cannot withdraw its own coins.  This lowers the profitability of B, causing grinders to leave them in favor of either A or C.  Since A is slightly larger than C, it is slightly more preferable, so it grows in size slightly more than C does.  Eventually B dies due to the coalition of A and C.  A and C are the only remaining pools, with A slightly larger than C.  In this case, A can break from the coalition and squeeze C of its sidecoins, since only A can withdraw (as it has more hashpower than C).  Again, grinders will leave C for A.  A rational C that is capable of considering this possible future path will thus never ally with A in a coalition to crush B, as it will then be next in line for being destroyed.
            
            Similar analyses for coalitions of (B, C) and (A, B).
            
            Knowing this, and knowing that they will end up sidecoin bagholders if they cannot withdraw coins, all miners decide to collude together and put all their withdrawals into a single withdrawal proposal.  But this removes any check-and-balance that the single withdrawal proposal is truthful to the sidechain: that is, the single coalition of A,B, and C can decide to just steal all sidechain funds and reassign them in proportion to their hashpower.  This might be stable at end-of-life for the sidechain where all ordinary users of the sidechain have exited it, but is otherwise a theft risk if the sidechain is operating normally.
            
            Regards,
            ZmnSCPxj
            
            [-- Attachment #2: Type: text/html, Size: 4021 bytes --]
            
            ^ permalink raw reply	[flat|nested] 16+ messages in thread

          • • * Re: [bitcoin-dev] Two Drivechain BIPs
                2017-12-07  7:28           ` ZmnSCPxj
              @ 2017-12-12 22:16             ` Paul Sztorc
                0 siblings, 0 replies; 16+ messages in thread
              From: Paul Sztorc @ 2017-12-12 22:16 UTC (permalink / raw)
                To: ZmnSCPxj, Chris Stewart; +Cc: Bitcoin Protocol Discussion
              
              Hello ZmnSCPxj,
              
              Thanks for contributing your thoughts. I wish I were able to respond sooner!
              
              1. I'm a little confused about the second half of your message, and its
              emphasis on pools. As you know, pools can be created or destroyed an
              unbounded number of times, costing only a small time lag. So I do not
              see why anyone would care about pool-death (except for the administrator
              of the pool of course -- and this exception is, itself, strong evidence
              that pools will reflect the interests of their members). Pools are just
              some naturally-occurring phenomenon that arise when many different
              hashers all want similar things.
              
              2. You have quoted a section where I suppose that miners are offering an
              'atomic swaps' service. And you usually talk about that hypothetical
              scenario I've outlined. But sometimes you talk in a way that leads me to
              believe that you have departed from that hypothetical. For example you
              talk about frozen withdrawals, invalid withdrawals, and miner-to-user
              harm. But that isn't possible in my hypothetical, because users can
              escape all of those things by using atomic swaps (which, recall are
              instant and competitively priced, see #4). Moreover, miners can pretend
              to be users (for the purpose of using these atomic swaps). If you want
              to talk about a world where users aren't using these swaps, I would
              appreciate it if you were more clear.
              
              3. The question of miners harassing each other using strategy is a very
              interesting one.
              
              First, (as you seem to know) the withdrawals are designed to be
              combine-able. This is in fact not only the default behavior but also the
              most efficient behavior. (Assuming that n quantity of economic transfers
              must go across, it is of course best to do them in one transaction.) So,
              your complaint must immediately be limited to the case of "spiteful"
              miners who care more about blocking opponent's transfers (for whatever
              reason) than they care about upvoting their own transfers.
              
              However, if any miner pursues a spiteful strategy, the victim(s) can
              respond by orphaning. For example, if 33% are producing 'spiteful
              blocks', the other 66% can easily orphan these. The central issues, as I
              see it, is that to be *spiteful* is also to be *different* and
              *noticeable*. Thus, different blocks can be orphaned.
              
              Some may worry that this opens the door to endless vindictive arbitrary
              orphaning (and that this is either the reason that such an alternative
              will not work and therefore not be persuasive, or else that the outcome
              of endless arbitrary orphaning would itself be a bad one). My view (and
              observation) is that the threat of eventual orphaning is sufficient, and
              that therefore there will be no actual orphaning. This is because the
              antagonizing 33% group is now its own victim group, and they now have an
              overwhelming incentive to either [a] stop being different (in this case,
              spiteful), or else to [b] quickly obtain an additional 18% hashrate so
              as to survive the orphaning. Should they add 18% to their 33%, "they"
              will have 51%, and we might wonder if they will try orphaning of their
              own. However, if they do, it merely restarts the above logic, with the
              49% fighting to persuade a critical 2% to join.
              
              So far, this logic may terminate with two 50% pools that each stubbornly
              refuse to interact. But eventually chance will one of their blockchains
              ahead of the other's, and the members of the disfavored group will feel
              pressure to defect (or else they are likely to be left behind). It is no
              different from traditional miner-bitterness over having not found the
              most-recent block.
              
              Users who move side-to-main via atomic swaps will have no reason to care
              about any of this. 
              
              4. As I point out in the Nov 2015 specification and security model, and
              as you have suggested, the atomic swaps will only be ultra-cheap and
              ultra-available if there exists *some other way* of *eventually* moving
              side-to-main with *certainty*. The goal is to have a side-to-main method
              that definitely will work, even if it takes a very long time to work.
              Then the atomic swap is paying a premium for speed only, relative to
              this method. This is why the security model of drivechain relies
              (partially) on investor disappointment that sidechains are no longer
              going to be supported. And it is why the slow (non-AtomicSwap)
              withdrawal process is so slow and delay-able in the first place -- to
              increase its security. If it is secure enough to withstand any attack,
              then attackers will eventually give up (or else, they will never attack
              in the first place). This satisfies the criterion of an alternative
              withdrawal process that is certain and eventual.
              
              Paul
              
              
              On 12/7/2017 2:28 AM, ZmnSCPxj wrote:
              > Good morning Paul and Chris,
              >
              > >I don't agree with the conclusion (that the optimal policy is "always
              > downvoting", see above), but even if this analysis turns out to be
              > correct, it isn't a total disaster. The result (which is in the
              > original Nov
              > >2015 specification) is that miners are the ones who perform the
              > atomic swaps. Then they walk the coins side-to-main (which, at this
              > point, are *their* coins). As long as there are a few large mining
              > groups,
              > >competition will drive the atomic swap fees down to negligible levels.
              >
              > Assuming there are three large mining groups who will ruthlessly want
              > to undercut their competition, and with roughly 33% of total hashpower
              > each (with the remaining 1% being some negligible hoi polloi), then
              > one strategy to undercut your competitors would be to upvote only your
              > own withdrawals and downvote that of your competitors.  A miner using
              > this strategy hopes that the other miners will give up on withdrawing
              > their own coin and trade their sidecoins at a discount to the
              > undercutting miner.  That is, it is a hostage attempt of the sidecoin
              > funds of the other miners.
              >
              > In the case of three large mining pools that mistrust one another,
              > then, no withdrawal would ever push through and drivechains stabilize
              > to one-way pegs.
              >
              > Now suppose that two of the mining pools collude.  They join their
              > withdrawals into a single withdrawal proposal and upvote that, while
              > downvoting the withdrawal of the third miner.  I observe that this is
              > an opposite disaster: the 66% colluding miners can instead decide to
              > simply outright make an invalid withdrawal of all funds, split up in
              > half between themselves.
              >
              > --
              >
              > But three exactly equal mining pools is unnatural, for that matter
              >
              > Suppose that there are three mining pools: A with 34%, B with 33%, C
              > with 32%, and the hoi polloi making up the remaining 1%.  Those three
              > pools cannot safely let the others withdraw funds.
              >
              > Suppose A colludes with C to join their withdrawal proposals and their
              > hashpower to withdraw.  This means that B can be pressured to sell its
              > sidecoins for a discount to the joint coalition of A and C, since B
              > cannot withdraw its own coins.  This lowers the profitability of B,
              > causing grinders to leave them in favor of either A or C.  Since A is
              > slightly larger than C, it is slightly more preferable, so it grows in
              > size slightly more than C does.  Eventually B dies due to the
              > coalition of A and C.  A and C are the only remaining pools, with A
              > slightly larger than C.  In this case, A can break from the coalition
              > and squeeze C of its sidecoins, since only A can withdraw (as it has
              > more hashpower than C).  Again, grinders will leave C for A.  A
              > rational C that is capable of considering this possible future path
              > will thus never ally with A in a coalition to crush B, as it will then
              > be next in line for being destroyed.
              >
              > Similar analyses for coalitions of (B, C) and (A, B).
              >
              > Knowing this, and knowing that they will end up sidecoin bagholders if
              > they cannot withdraw coins, all miners decide to collude together and
              > put all their withdrawals into a single withdrawal proposal.  But this
              > removes any check-and-balance that the single withdrawal proposal is
              > truthful to the sidechain: that is, the single coalition of A,B, and C
              > can decide to just steal all sidechain funds and reassign them in
              > proportion to their hashpower.  This might be stable at end-of-life
              > for the sidechain where all ordinary users of the sidechain have
              > exited it, but is otherwise a theft risk if the sidechain is operating
              > normally.
              >
              > Regards,
              > ZmnSCPxj
              
              
              
              
              
              ^ permalink raw reply	[flat|nested] 16+ messages in thread

      • * Re: [bitcoin-dev] Two Drivechain BIPs
          2017-12-04 19:36     ` Chris Pacia
          2017-12-04 20:11       ` Chris Stewart
        @ 2017-12-05 18:05       ` Paul Sztorc
          2017-12-05 18:20         ` AJ West
          2017-12-06  4:49         ` ZmnSCPxj
          1 sibling, 2 replies; 16+ messages in thread
        From: Paul Sztorc @ 2017-12-05 18:05 UTC (permalink / raw)
          To: Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 5960 bytes --]
        
        Hello Chris,
        
        1. Marginal Cost
        
        There actually is a very small cost to casting a malicious vote,
        relative to an honest vote. This is because the software (when run
        as-is), will automatically vote correctly. But to vote fraudulently you
        must decide on what to do instead, and configure that! This might not be
        as easy as it seems (see collective action part, below).
        
        It is true that there is no *marginal* cost to creating a bad vote, in
        the fraudulent withdrawal case. But then again there is no marginal cost
        to creating a good vote either -- in fact there is no cost at all. In
        fact, there is no marginal cost to creating a bad block either, in the
        51% hashrate reorganization case. Epistemologically, the protocol has no
        way of differentiating a "bad" block/vote from a good one. So one cannot
        "cost" more than the other, in a narrow sense.
        
        I suppose in the reorganization case there is the risk of lost mining
        effort on a chain that actually does *not* have 51% and therefore won't
        catch up. But this only encourages conformity to the longest chain,
        including fraudulent chains. For example, imagine that the
        reorganization is done via secretly mining a longer chain -- once that
        chain is published, it will be the longest. Then, according to your
        framework, there will be a "marginal cost" to doing the *right* thing
        (trying to preserve the honest, transparent chain). So I'm afraid I
        don't understand what you mean.
        
        2. Repercussions
        
        As for there being no repercussions, that is incorrect. The miner's
        choice to engage in a fraudulent withdraw is one that has several
        negative consequences. They take a variety of forms and likelihoods, but
        they definitely exist and are very relevant.
        
        The first repercussion is the loss of victim-sidechain future tx-fees. A
        second is the loss of all future tx fees on all sidechains. A third is
        that the Bitcoin super-network is changed from being a "sidechain
        enabled" network to a "sidechain disabled" network.
        
        The impact of these repercussions is still unclear and open to
        interpretation. On one hand, the impact may be small and therefore not
        very persuasive (as in the case where a sidechain has few tx-fees, few
        sidechains are used, few are expected to be created/used, and so little
        is lost by attacking). On the other hand, a single fraudulent withdrawal
        might motivate the creation of a new spinoff network that is exactly the
        same as the old network, but with merely two changes: the fraudulent
        withdrawal surgically removed (as if it were never attempted) AND a new
        proof of work algorithm. Since the withdrawals are so slow, there would
        be plenty of time to organize such an option (and people who already
        want a pow-change would jump at this glaring opportunity). Will the
        repercussions be small or large? Even if there is only a *risk* of large
        repercussions, it can be very persuasive. (Just as the IRS is very
        persuasive to tax-paying Americans, even though only a tiny proportion
        of tax returns are audited.)
        
        0. Useless Sidechain Fallacy
        
        Finally, you are joining the long list of people who are committing the
        "useless sidechain fallacy". You are saying that because you believe the
        sidechain is useless, therefore everyone must believe as you do, and
        therefore the option to use a sidechain must be one that has zero value.
        However, in the real world people are heterogeneous. They may decide
        that your interpretation contains errors, or else their circumstances
        might incline them towards a different risk-reward tradeoff. Finally,
        this fallacy obfuscates the main benefit of sidechains, which is that
        they are optional -- the sidechain-designer must convince users to
        deposit funds there.
        
        3. Collective Action Problem
        
        There actually is a collective action problem inherent to fraudulent
        withdrawals.
        
        If miners wish to fraudulently withdraw from the sidechain, they need to
        choose the destination addresses (on mainchain Bitcoin Core) months in
        advance. Then they need to upvote/downvote this destination, despite
        that fact that --during this time-- new hashpower might be coming
        online/offline, and/or hashers might be joining/leaving specific pools.
        I bring this up to demonstrate that even the most straightforward attack
        (of "a 51% hashrate group attacks a sidechain and distributes the
        proceeds to the group proportional to hashpower") is actually one that
        contains a difficult (and potentially interminable) negotiation. The
        effort required to initiate the negotiation is the source of the
        collective action problem here.
        
        I think that this collective action problem is actually more burdensome
        than Bitcoin's -- for mainchain Bitcoin miners merely need to decide
        which block height they intend to reorganize from.
        
        You may wish to read Drivechain's security model to learn more:
        http://www.truthcoin.info/blog/drivechain/#drivechains-security
        
        In this case, I don't see a way to measure "security" cardinally or
        ordinally. Instead, I am only able to see it as either "secure enough"
        or "not secure enough". But perhaps someone can enlighten me as to the
        math they are using to produce these cardinal/ordinal rankings.
        
        --Paul
        
        On 12/4/2017 2:36 PM, Chris Pacia wrote:
        >
        >     I think you are missing a few things.
        >
        >     First of all, I think the security model for sidechains is the same as
        >     that of every blockchain
        >
        >     People will say things, like "but with sidechains 51% hashrate can
        >     steal
        >     your coins!", but as I have repeated many times, this is also true of
        >     mainchain btc-tx.  is something else?
        >
        >
        > There are substantial opportunity costs as well as a collective action
        > problem when it comes to re-writing the mainchain. 
        >
        > Is there anything similar for drivechains? As far as I can tell there
        > is no opportunity cost to casting a malicious vote, no repercussions,
        > and no collective action barrier that needs to be overcome. 
        >
        > Unless I'm missing something I wouldn't liken the security of a
        > drivechain to that of the mainchain.
        
        
        
        [-- Attachment #2: Type: text/html, Size: 8032 bytes --]
        
        ^ permalink raw reply	[flat|nested] 16+ messages in thread

      • • * Re: [bitcoin-dev] Two Drivechain BIPs
            2017-12-05 18:05       ` Paul Sztorc
          @ 2017-12-05 18:20         ` AJ West
            2017-12-06  4:49         ` ZmnSCPxj
            1 sibling, 0 replies; 16+ messages in thread
          From: AJ West @ 2017-12-05 18:20 UTC (permalink / raw)
            To: Paul Sztorc, Bitcoin Protocol Discussion
          
          [-- Attachment #1: Type: text/plain, Size: 6931 bytes --]
          
          Hello,
          
          I would like to refer to these BIPs in other contexts and conversations.
          Regardless of the pitfalls or benefits, the discussion and technical review
          happening in this thread (and the ones before) are well-formed ideas with
          an active champion. The point of BIP numbers/conventions are so we're all
          on the same page about what we're talking about.
          
          Please assign these BIP numbers so discussion may continue in a controlled,
          tagged, linear manner, instead of "the first BIP" and "the second BIP."
          
          Thank you
          AJ West
          
          On Tue, Dec 5, 2017 at 1:05 PM, Paul Sztorc via bitcoin-dev <
          bitcoin-dev@lists•linuxfoundation.org> wrote:
          
          > Hello Chris,
          >
          > 1. Marginal Cost
          >
          > There actually is a very small cost to casting a malicious vote, relative
          > to an honest vote. This is because the software (when run as-is), will
          > automatically vote correctly. But to vote fraudulently you must decide on
          > what to do instead, and configure that! This might not be as easy as it
          > seems (see collective action part, below).
          >
          > It is true that there is no *marginal* cost to creating a bad vote, in the
          > fraudulent withdrawal case. But then again there is no marginal cost to
          > creating a good vote either -- in fact there is no cost at all. In fact,
          > there is no marginal cost to creating a bad block either, in the 51%
          > hashrate reorganization case. Epistemologically, the protocol has no way of
          > differentiating a "bad" block/vote from a good one. So one cannot "cost"
          > more than the other, in a narrow sense.
          >
          > I suppose in the reorganization case there is the risk of lost mining
          > effort on a chain that actually does *not* have 51% and therefore won't
          > catch up. But this only encourages conformity to the longest chain,
          > including fraudulent chains. For example, imagine that the reorganization
          > is done via secretly mining a longer chain -- once that chain is published,
          > it will be the longest. Then, according to your framework, there will be a
          > "marginal cost" to doing the *right* thing (trying to preserve the honest,
          > transparent chain). So I'm afraid I don't understand what you mean.
          >
          > 2. Repercussions
          >
          > As for there being no repercussions, that is incorrect. The miner's choice
          > to engage in a fraudulent withdraw is one that has several negative
          > consequences. They take a variety of forms and likelihoods, but they
          > definitely exist and are very relevant.
          >
          > The first repercussion is the loss of victim-sidechain future tx-fees. A
          > second is the loss of all future tx fees on all sidechains. A third is that
          > the Bitcoin super-network is changed from being a "sidechain enabled"
          > network to a "sidechain disabled" network.
          >
          > The impact of these repercussions is still unclear and open to
          > interpretation. On one hand, the impact may be small and therefore not very
          > persuasive (as in the case where a sidechain has few tx-fees, few
          > sidechains are used, few are expected to be created/used, and so little is
          > lost by attacking). On the other hand, a single fraudulent withdrawal might
          > motivate the creation of a new spinoff network that is exactly the same as
          > the old network, but with merely two changes: the fraudulent withdrawal
          > surgically removed (as if it were never attempted) AND a new proof of work
          > algorithm. Since the withdrawals are so slow, there would be plenty of time
          > to organize such an option (and people who already want a pow-change would
          > jump at this glaring opportunity). Will the repercussions be small or
          > large? Even if there is only a *risk* of large repercussions, it can be
          > very persuasive. (Just as the IRS is very persuasive to tax-paying
          > Americans, even though only a tiny proportion of tax returns are audited.)
          >
          > 0. Useless Sidechain Fallacy
          >
          > Finally, you are joining the long list of people who are committing the
          > "useless sidechain fallacy". You are saying that because you believe the
          > sidechain is useless, therefore everyone must believe as you do, and
          > therefore the option to use a sidechain must be one that has zero value.
          > However, in the real world people are heterogeneous. They may decide that
          > your interpretation contains errors, or else their circumstances might
          > incline them towards a different risk-reward tradeoff. Finally, this
          > fallacy obfuscates the main benefit of sidechains, which is that they are
          > optional -- the sidechain-designer must convince users to deposit funds
          > there.
          >
          > 3. Collective Action Problem
          >
          > There actually is a collective action problem inherent to fraudulent
          > withdrawals.
          >
          > If miners wish to fraudulently withdraw from the sidechain, they need to
          > choose the destination addresses (on mainchain Bitcoin Core) months in
          > advance. Then they need to upvote/downvote this destination, despite that
          > fact that --during this time-- new hashpower might be coming
          > online/offline, and/or hashers might be joining/leaving specific pools. I
          > bring this up to demonstrate that even the most straightforward attack (of
          > "a 51% hashrate group attacks a sidechain and distributes the proceeds to
          > the group proportional to hashpower") is actually one that contains a
          > difficult (and potentially interminable) negotiation. The effort required
          > to initiate the negotiation is the source of the collective action problem
          > here.
          >
          > I think that this collective action problem is actually more burdensome
          > than Bitcoin's -- for mainchain Bitcoin miners merely need to decide which
          > block height they intend to reorganize from.
          >
          > You may wish to read Drivechain's security model to learn more:
          > http://www.truthcoin.info/blog/drivechain/#drivechains-security
          >
          > In this case, I don't see a way to measure "security" cardinally or
          > ordinally. Instead, I am only able to see it as either "secure enough" or
          > "not secure enough". But perhaps someone can enlighten me as to the math
          > they are using to produce these cardinal/ordinal rankings.
          >
          > --Paul
          >
          >
          > On 12/4/2017 2:36 PM, Chris Pacia wrote:
          >
          >
          > I think you are missing a few things.
          >
          > First of all, I think the security model for sidechains is the same as
          > that of every blockchain
          >
          > People will say things, like "but with sidechains 51% hashrate can steal
          > your coins!", but as I have repeated many times, this is also true of
          > mainchain btc-tx.  is something else?
          >
          >
          > There are substantial opportunity costs as well as a collective action
          > problem when it comes to re-writing the mainchain.
          >
          > Is there anything similar for drivechains? As far as I can tell there is
          > no opportunity cost to casting a malicious vote, no repercussions, and no
          > collective action barrier that needs to be overcome.
          >
          > Unless I'm missing something I wouldn't liken the security of a drivechain
          > to that of the mainchain.
          >
          >
          >
          > _______________________________________________
          > bitcoin-dev mailing list
          > bitcoin-dev@lists•linuxfoundation.org
          > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          >
          >
          
          [-- Attachment #2: Type: text/html, Size: 9877 bytes --]
          
          ^ permalink raw reply	[flat|nested] 16+ messages in thread

        • * Re: [bitcoin-dev] Two Drivechain BIPs
            2017-12-05 18:05       ` Paul Sztorc
            2017-12-05 18:20         ` AJ West
          @ 2017-12-06  4:49         ` ZmnSCPxj
            2017-12-06 20:51           ` CryptAxe
            2017-12-12 22:29           ` Paul Sztorc
            1 sibling, 2 replies; 16+ messages in thread
          From: ZmnSCPxj @ 2017-12-06  4:49 UTC (permalink / raw)
            To: Paul Sztorc, Chris Stewart; +Cc: Bitcoin Protocol Discussion
          
          [-- Attachment #1: Type: text/plain, Size: 6041 bytes --]
          
          Good morning Paul and Chris,
          
          >3. Collective Action Problem
          >
          >There actually is a collective action problem inherent to fraudulent withdrawals.
          >
          >If miners wish to fraudulently withdraw from the sidechain, they need to choose the destination addresses (on mainchain Bitcoin Core) months in advance. Then they need to upvote/downvote this
          >destination, despite that fact that --during this time-- new hashpower might be coming online/offline, and/or hashers might be joining/leaving specific pools. I bring this up to demonstrate that even the most
          >straightforward attack (of "a 51% hashrate group attacks a sidechain and distributes the proceeds to the group proportional to hashpower") is actually one that contains a difficult (and potentially
          >interminable) negotiation. The effort required to initiate the negotiation is the source of the collective action problem here.
          >
          >I think that this collective action problem is actually more burdensome than Bitcoin's -- for mainchain Bitcoin miners merely need to decide which block height they intend to reorganize from.
          
          I actually devised a way to work around this collective action problem, and discussed it obliquely in a private e-mail with Chris, while I was preparing my article on sidechain weaknesses.  I removed it before publication of the sidechain weaknesses article, but perhaps I should not have.
          
          Collective action can be ensured by contract.  In a world where some system can enforce certain actions programmatically, it is possible to ensure collective action via a program, i.e. a "smart contract".
          
          The thief pays out to the destination address that is a P2SH of the below script:
          
          OP_IF
            OP_HASH160 <hash> OP_EQUALVERIFY
            OP_DUP OP_HASH160 <thiefPubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
          OP_ELSE
            <withdrawTime+1week> OP_CHECKLOCKTIMEVERIFY OP_DROP
            OP_TRUE
          OP_ENDIF
          
          If the thief does not publish the preimage of the hash within 1 week of the withdrawal time, then it becomes possible for anyone to spend the above script; basically, some lucky miner who wins the first block past the specified time will get the entire winnings.  Let us call the above script, the Theft Contract.
          
          The thief then recruits accomplices to the theft.  Note that the attack can be prepared and initiated before the accomplices are even recruited.
          
          The thief locks some coins (the "cut" the accomplice gets), to the below script, for each accomplice it tries to entice:
          
          OP_IF
            OP_HASH160 <hash> OP_EQUALVERIFY
            OP_DUP OP_HASH160 <accomplicePubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
          OP_ELSE
            <withdrawTime+2week> OP_CHECKLOCKTIMEVERIFY OP_DROP
            OP_DUP OP_HASH160 <thiefPubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
          OP_ENDIF
          
          Let us call the above script, the Accomplice Contract.  If the accomplice accepts, he or she then starts to vote for the invalid withdrawal.
          
          If the invalid withdrawal succeeds, the thief acquires the entire theft price from the Theft Contract by publishing the preimage to the <hash>.  (If he or she does not, then, some randomly-selected miner will acquire the money after the timeout, so the thief needs to publish the hash, before the timeout in the Theft Contract).
          
          This publishes the preimage on the blockchain.  Each accomplice can then acquire their "cut" of the theft by copying the preimage and claiming from the Accomplice Contract.
          
          If the theft never succeeds, then there is no reason for the thief to ever publish the preimage, and after the timeout on the Accomplice Contract, the thief can recover his or her offered funds at no loss (minus transaction fees),  This incentivizes accomplices to actually cooperate with the thief, as they will not get paid if the theft does not push through.
          
          All that is necessary is for a single "mastermind" thief to begin this process.  Accomplices can be recruited later, with the "cut" they get negotiated according to how much hashpower they can bring to bear on theft.
          
          Newly-created miners and mining pools can be enticed at the time they arise by offering an Accomplice Contract to them.  Thus, newly-created miners and mining pools can be brought into cooperation with the thief as soon as they make a presence on the blockchain.
          
          Even if some mining pool makes a public statement that they will not assist in the theft, the thief may still commit an Accomplice Contract for them on-chain anyway, and publicize it, in order to put the integrity of that mining pool in question and drive out support from that mining pool.  True accomplices may pretend to initially be honest and then signal dishonestly later, in order to make it more plausible that a pool that "committed" to not support the theft is not trustable since they have an Accomplice Contract that will compensate them if they support the theft, creating further confusion and discord among honest miners.  The thief may also use the existence of such an Accomplice Contract while negotiating with more minor miners and mining pools, in order to entice those also to join, and thus gain additional buffer against the stochastic process of miner voting.
          
          With the Theft Contract and the Accomplice Contract, negotiation can be done in parallel with the theft attempt, reducing the cost of organizing collective action, as we have all hoped "smart contracts" would do.
          
          ----
          
          While it is true, that this requires that the thief have significant funds in reserve prior to theft (in order to fund the Accomplice Contracts he or she will have to offer to potential accomplices), we have always been assured that theft can be initiated by miners only, and that miners already have a significant amount of money they control.  So it will be no problem for a potential thief to reserve some funds for paying to Accomplice Contracts.
          
          This vulnerability can be fixed if withdrawals are restricted to simple P2PKH or P2WPKH only, but in the presence of Scriptless Script and Bellare-Neven signatures, that may be sufficient to create the Theft Contract and the Accomplice Contract (but I know too little of Scriptless Script to be sure).
          
          Regards,
          ZmnSCPxj
          
          [-- Attachment #2: Type: text/html, Size: 7218 bytes --]
          
          ^ permalink raw reply	[flat|nested] 16+ messages in thread

        • • * Re: [bitcoin-dev] Two Drivechain BIPs
              2017-12-06  4:49         ` ZmnSCPxj
            @ 2017-12-06 20:51           ` CryptAxe
              2017-12-08 15:40             ` ZmnSCPxj
              2017-12-12 22:29           ` Paul Sztorc
              1 sibling, 1 reply; 16+ messages in thread
            From: CryptAxe @ 2017-12-06 20:51 UTC (permalink / raw)
              To: bitcoin-dev
            
            On 12/05/2017 08:49 PM, ZmnSCPxj via bitcoin-dev wrote:
            
            > ...
            > This vulnerability can be fixed if withdrawals are restricted to
            > simple P2PKH or P2WPKH only,
            
            Limiting the withdrawal outputs to P2PKH and perhaps P2WPKH (would there
            be any network benefit to supporting witness pubkeys for withdrawals?)
            wouldn't be too much work for me. The downside is that people might want
            to withdraw to multisig scripts, or any other legitimate P2SH. If it
            prevents a huge issue, then it is probably worth it.
            
            
            > but in the presence of Scriptless Script and Bellare-Neven signatures,
            > that may be sufficient to create the Theft Contract and the Accomplice
            > Contract (but I know too little of Scriptless Script to be sure).
            >
            > Regards,
            > ZmnSCPxj
            >
            
            I'm curious if anyone on this list could help answer this.
            
            Thanks!
            
            
            
            
            ^ permalink raw reply	[flat|nested] 16+ messages in thread

          • • * Re: [bitcoin-dev] Two Drivechain BIPs
                2017-12-06 20:51           ` CryptAxe
              @ 2017-12-08 15:40             ` ZmnSCPxj
                0 siblings, 0 replies; 16+ messages in thread
              From: ZmnSCPxj @ 2017-12-08 15:40 UTC (permalink / raw)
                To: CryptAxe; +Cc: bitcoin-dev
              
              [-- Attachment #1: Type: text/plain, Size: 3756 bytes --]
              
              Good morning CryptAxe,
              
              I have come to realize that P2PKH is powerful enough to write a Theft Contract from which other Accomplice Contracts can derive.
              
              The core of the Theft Contract and the Accomplice Contract is that they are both HTLCs.  The difference is that the Theft Contract, the timelock is anyone-can-spend after the time limit.  The Accomplice Contract is an ordinary HTLC.
              
              However, P2PKH, plus an off-chain method, can be combined to form a HTLC with anyone-can-spend after the timelock.
              
              P2PKH includes <pubKeyHash>.  Spending from a P2PKH reveals the preimage to <pubKeyHash>, the public key.  Thus, the Accomplice Contract can use the P2PKH <pubKeyHash> as the hash, and when the P2PKH is spent, acquire the public key to be used as the preimage of the hashlock.
              
              The remaining ingredient is a timelock with anyone-can-spend after the time limit.  And I belatedly realized that I have in fact seen an offchain method of imposing a timelock on information: https://www.gwern.net/Self-decrypting-files  To create a timelock, the "mastermind" thief encrypts the private key to the P2PKH in such a timelocked-encryption scheme, and publishes it as part of the theft attempt to commit themselves to the timelock, together with a zero-knowledge proof that the timelock-encrypted private key is correctly the private key to the given public key hash (I am not mathematically gifted enough to know if such a proof if possible, however, and if this is impossible, then this entire scheme cannot work).  Thus, if the thief does not spend the P2PKH (which reveals the preimage to the hash, which unlocks the Accomplice Contracts and pays the accomplices), then someone else can grind the timelock-encryption and spend the P2PKH (and also incidentally unlocks the Accomplice Contracts anyway).
              
              Of course, timelock-encryption is significantly less reliable as a time measure (different sequential processing speeds yield different timelocks from the same timelock-encrypted data), but that may be enough to have a reasonably trustless Thief-Accomplice coordination structure.
              
              Another issue is that if the Accomplice does not cooperate and the theft fails, the Accomplices may still grind the timelock-encryption and acquire the private key, from which they can compute the public key, which is also the preimage to their hashlock.  So there may not actually be an incentive to coordinate with the Thief under this structure.  But perhaps this idea may trigger someone else to consider how to exploit the precise mathematics of P2PKH to create something similar to a HTLC.
              
              Regards,
              ZmnSCPxj
              
              -------- Original Message --------
              Subject: Re: [bitcoin-dev] Two Drivechain BIPs
              Local Time: December 7, 2017 4:51 AM
              UTC Time: December 6, 2017 8:51 PM
              From: bitcoin-dev@lists•linuxfoundation.org
              To: bitcoin-dev@lists•linuxfoundation.org
              
              On 12/05/2017 08:49 PM, ZmnSCPxj via bitcoin-dev wrote:
              ...
              This vulnerability can be fixed if withdrawals are restricted to
              simple P2PKH or P2WPKH only,
              
              Limiting the withdrawal outputs to P2PKH and perhaps P2WPKH (would there
              be any network benefit to supporting witness pubkeys for withdrawals?)
              wouldn't be too much work for me. The downside is that people might want
              to withdraw to multisig scripts, or any other legitimate P2SH. If it
              prevents a huge issue, then it is probably worth it.
              
              but in the presence of Scriptless Script and Bellare-Neven signatures,
              that may be sufficient to create the Theft Contract and the Accomplice
              Contract (but I know too little of Scriptless Script to be sure).
              Regards,
              ZmnSCPxj
              
              I'm curious if anyone on this list could help answer this.
              
              Thanks!
              
              bitcoin-dev mailing list
              bitcoin-dev@lists•linuxfoundation.org
              https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
              
              [-- Attachment #2: Type: text/html, Size: 4642 bytes --]
              
              ^ permalink raw reply	[flat|nested] 16+ messages in thread

          • * Re: [bitcoin-dev] Two Drivechain BIPs
              2017-12-06  4:49         ` ZmnSCPxj
              2017-12-06 20:51           ` CryptAxe
            @ 2017-12-12 22:29           ` Paul Sztorc
              2017-12-14  3:24             ` ZmnSCPxj
              1 sibling, 1 reply; 16+ messages in thread
            From: Paul Sztorc @ 2017-12-12 22:29 UTC (permalink / raw)
              To: ZmnSCPxj, Chris Stewart; +Cc: Bitcoin Protocol Discussion
            
            Hi Zmn,
            
            I'm actually not sure that the existence of these tools makes the
            attacker's collective action problem that much easier to solve.
            
            As I said: "...even the most straightforward attack (of "a 51% hashrate
            group attacks a sidechain and distributes the proceeds to the group
            proportional to hashpower") is actually one that contains a difficult
            (and potentially interminable) negotiation."
            
            But even under your scheme, there is someone who has to seek out the
            Accomplices, and has to try to figure out what is acceptable to pay
            them. This sparks a tiresome negotiation that drains both parties of
            time and effort and might potentially last forever. Problematically,
            there is a Market for Lemons problem with respect to how many blocks an
            Accomplice "will" mine. If many people try to be Thieves at once, then
            each individual Thief has less of an incentive to bother trying to steal
            in the first place.
            
            And so, even if your scheme does work, the improvement seems small. And
            even if the improvement is very great, the remaining collective action
            problem is still more difficult than the one in the comparative "reorg
            case" (in which the problem is just to "pick the block number from which
            to start the reorg").
            
            Paul
            
            
            
            On 12/5/2017 11:49 PM, ZmnSCPxj wrote:
            > Good morning Paul and Chris,
            >
            > >3. Collective Action Problem
            > >
            > >There actually is a collective action problem inherent to fraudulent
            > withdrawals.
            > >
            > >If miners wish to fraudulently withdraw from the sidechain, they need
            > to choose the destination addresses (on mainchain Bitcoin Core) months
            > in advance. Then they need to upvote/downvote this
            > >destination, despite that fact that --during this time-- new
            > hashpower might be coming online/offline, and/or hashers might be
            > joining/leaving specific pools. I bring this up to demonstrate that
            > even the most
            > >straightforward attack (of "a 51% hashrate group attacks a sidechain
            > and distributes the proceeds to the group proportional to hashpower")
            > is actually one that contains a difficult (and potentially
            > >interminable) negotiation. The effort required to initiate the
            > negotiation is the source of the collective action problem here.
            > >
            > >I think that this collective action problem is actually more
            > burdensome than Bitcoin's -- for mainchain Bitcoin miners merely need
            > to decide which block height they intend to reorganize from.
            >
            > I actually devised a way to work around this collective action
            > problem, and discussed it obliquely in a private e-mail with Chris,
            > while I was preparing my article on sidechain weaknesses.  I removed
            > it before publication of the sidechain weaknesses article, but perhaps
            > I should not have.
            >
            > Collective action can be ensured by contract.  In a world where some
            > system can enforce certain actions programmatically, it is possible to
            > ensure collective action via a program, i.e. a "smart contract".
            >
            > The thief pays out to the destination address that is a P2SH of the
            > below script:
            >
            > OP_IF
            >   OP_HASH160 <hash> OP_EQUALVERIFY
            >   OP_DUP OP_HASH160 <thiefPubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
            > OP_ELSE
            >   <withdrawTime+1week> OP_CHECKLOCKTIMEVERIFY OP_DROP
            >   OP_TRUE
            > OP_ENDIF
            >
            > If the thief does not publish the preimage of the hash within 1 week
            > of the withdrawal time, then it becomes possible for anyone to spend
            > the above script; basically, some lucky miner who wins the first block
            > past the specified time will get the entire winnings.  Let us call the
            > above script, the Theft Contract.
            >
            > The thief then recruits accomplices to the theft.  Note that the
            > attack can be prepared and initiated before the accomplices are even
            > recruited.
            >
            > The thief locks some coins (the "cut" the accomplice gets), to the
            > below script, for each accomplice it tries to entice:
            >
            > OP_IF
            >   OP_HASH160 <hash> OP_EQUALVERIFY
            >   OP_DUP OP_HASH160 <accomplicePubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
            > OP_ELSE
            >   <withdrawTime+2week> OP_CHECKLOCKTIMEVERIFY OP_DROP
            >   OP_DUP OP_HASH160 <thiefPubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
            > OP_ENDIF
            >
            > Let us call the above script, the Accomplice Contract.  If the
            > accomplice accepts, he or she then starts to vote for the invalid
            > withdrawal.
            >
            > If the invalid withdrawal succeeds, the thief acquires the entire
            > theft price from the Theft Contract by publishing the preimage to the
            > <hash>.  (If he or she does not, then, some randomly-selected miner
            > will acquire the money after the timeout, so the thief needs to
            > publish the hash, before the timeout in the Theft Contract).
            >
            > This publishes the preimage on the blockchain.  Each accomplice can
            > then acquire their "cut" of the theft by copying the preimage and
            > claiming from the Accomplice Contract.
            >
            > If the theft never succeeds, then there is no reason for the thief to
            > ever publish the preimage, and after the timeout on the Accomplice
            > Contract, the thief can recover his or her offered funds at no loss
            > (minus transaction fees),  This incentivizes accomplices to actually
            > cooperate with the thief, as they will not get paid if the theft does
            > not push through.
            >
            > All that is necessary is for a single "mastermind" thief to begin this
            > process.  Accomplices can be recruited later, with the "cut" they get
            > negotiated according to how much hashpower they can bring to bear on
            > theft.
            >
            > Newly-created miners and mining pools can be enticed at the time they
            > arise by offering an Accomplice Contract to them.  Thus, newly-created
            > miners and mining pools can be brought into cooperation with the thief
            > as soon as they make a presence on the blockchain.
            >
            > Even if some mining pool makes a public statement that they will not
            > assist in the theft, the thief may still commit an Accomplice Contract
            > for them on-chain anyway, and publicize it, in order to put the
            > integrity of that mining pool in question and drive out support from
            > that mining pool.  True accomplices may pretend to initially be honest
            > and then signal dishonestly later, in order to make it more plausible
            > that a pool that "committed" to not support the theft is not trustable
            > since they have an Accomplice Contract that will compensate them if
            > they support the theft, creating further confusion and discord among
            > honest miners.  The thief may also use the existence of such an
            > Accomplice Contract while negotiating with more minor miners and
            > mining pools, in order to entice those also to join, and thus gain
            > additional buffer against the stochastic process of miner voting.
            >
            > With the Theft Contract and the Accomplice Contract, negotiation can
            > be done in parallel with the theft attempt, reducing the cost of
            > organizing collective action, as we have all hoped "smart contracts"
            > would do.
            >
            > ----
            >
            > While it is true, that this requires that the thief have significant
            > funds in reserve prior to theft (in order to fund the Accomplice
            > Contracts he or she will have to offer to potential accomplices), we
            > have always been assured that theft can be initiated by miners only,
            > and that miners already have a significant amount of money they
            > control.  So it will be no problem for a potential thief to reserve
            > some funds for paying to Accomplice Contracts.
            >
            > This vulnerability can be fixed if withdrawals are restricted to
            > simple P2PKH or P2WPKH only, but in the presence of Scriptless Script
            > and Bellare-Neven signatures, that may be sufficient to create the
            > Theft Contract and the Accomplice Contract (but I know too little of
            > Scriptless Script to be sure).
            >
            > Regards,
            > ZmnSCPxj
            
            
            
            
            
            ^ permalink raw reply	[flat|nested] 16+ messages in thread

          • • * Re: [bitcoin-dev] Two Drivechain BIPs
                2017-12-12 22:29           ` Paul Sztorc
              @ 2017-12-14  3:24             ` ZmnSCPxj
                0 siblings, 0 replies; 16+ messages in thread
              From: ZmnSCPxj @ 2017-12-14  3:24 UTC (permalink / raw)
                To: Paul Sztorc; +Cc: Bitcoin Protocol Discussion
              
              [-- Attachment #1: Type: text/plain, Size: 9463 bytes --]
              
              Good morning Paul,
              
              It seems many blocks have a coinbase that pays out to a P2PKH.
              
              The public key hash of a potential Accomplice is then readily visible on-chain on the P2PKH of the coinbase.
              
              What is more, the potential Accomplice's hashpower can be judged on-chain also: the more blocks pay out to their P2PKH, the greater their hashpower.
              
              From this, the motivating Thief can blindly and automatically create HTLCs paying out to the public key hash of potential Accomplices, weighed according to how many blocks were mined by those.
              
              Then the motivating Thief can broadcast (perhaps on some website they control, via social media, and so on) the fact of the HTLCs existing, without negotiating with the Accomplices.  It is a simple "take it or leave it": if the theft succeeds (whether the Accomplice assisted in the theft or not) the Accompilce can get paid.  Thus, communication overhead is reduced to a single broadcast message (the Thief might batch a number of different possible Accomplices, and in addition, might want to play on the psychological effect of the broadcast), and the Accomplice is simply faced with the choice: either participate in the theft (and increase the chance they earn money from it) or protect against the theft (and reduce the chance they earn money from it).
              
              Regards,
              ZmnSCPxj
              
              Sent with [ProtonMail](https://protonmail.com) Secure Email.
              
              > -------- Original Message --------
              > Subject: Re: [bitcoin-dev] Two Drivechain BIPs
              > Local Time: December 13, 2017 6:29 AM
              > UTC Time: December 12, 2017 10:29 PM
              > From: truthcoin@gmail•com
              > To: ZmnSCPxj <ZmnSCPxj@protonmail•com>, Chris Stewart <chris@suredbits•com>
              > Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
              >
              > Hi Zmn,
              >
              > I'm actually not sure that the existence of these tools makes the
              > attacker's collective action problem that much easier to solve.
              >
              > As I said: "...even the most straightforward attack (of "a 51% hashrate
              > group attacks a sidechain and distributes the proceeds to the group
              > proportional to hashpower") is actually one that contains a difficult
              > (and potentially interminable) negotiation."
              >
              > But even under your scheme, there is someone who has to seek out the
              > Accomplices, and has to try to figure out what is acceptable to pay
              > them. This sparks a tiresome negotiation that drains both parties of
              > time and effort and might potentially last forever. Problematically,
              > there is a Market for Lemons problem with respect to how many blocks an
              > Accomplice "will" mine. If many people try to be Thieves at once, then
              > each individual Thief has less of an incentive to bother trying to steal
              > in the first place.
              >
              > And so, even if your scheme does work, the improvement seems small. And
              > even if the improvement is very great, the remaining collective action
              > problem is still more difficult than the one in the comparative "reorg
              > case" (in which the problem is just to "pick the block number from which
              > to start the reorg").
              >
              > Paul
              >
              > On 12/5/2017 11:49 PM, ZmnSCPxj wrote:
              >
              >> Good morning Paul and Chris,
              >>
              >>> - Collective Action Problem
              >>>
              >>> There actually is a collective action problem inherent to fraudulent
              >>> withdrawals.
              >>> If miners wish to fraudulently withdraw from the sidechain, they need
              >>> to choose the destination addresses (on mainchain Bitcoin Core) months
              >>> in advance. Then they need to upvote/downvote this
              >>> destination, despite that fact that --during this time-- new
              >>> hashpower might be coming online/offline, and/or hashers might be
              >>> joining/leaving specific pools. I bring this up to demonstrate that
              >>> even the most
              >>> straightforward attack (of "a 51% hashrate group attacks a sidechain
              >>> and distributes the proceeds to the group proportional to hashpower")
              >>> is actually one that contains a difficult (and potentially
              >>> interminable) negotiation. The effort required to initiate the
              >>> negotiation is the source of the collective action problem here.
              >>> I think that this collective action problem is actually more
              >>> burdensome than Bitcoin's -- for mainchain Bitcoin miners merely need
              >>> to decide which block height they intend to reorganize from.
              >>
              >> I actually devised a way to work around this collective action
              >> problem, and discussed it obliquely in a private e-mail with Chris,
              >> while I was preparing my article on sidechain weaknesses.  I removed
              >> it before publication of the sidechain weaknesses article, but perhaps
              >> I should not have.
              >> Collective action can be ensured by contract.  In a world where some
              >> system can enforce certain actions programmatically, it is possible to
              >> ensure collective action via a program, i.e. a "smart contract".
              >> The thief pays out to the destination address that is a P2SH of the
              >> below script:
              >> OP_IF
              >>   OP_HASH160 <hash> OP_EQUALVERIFY
              >>   OP_DUP OP_HASH160 <thiefPubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
              >> OP_ELSE
              >>   <withdrawTime+1week> OP_CHECKLOCKTIMEVERIFY OP_DROP
              >>   OP_TRUE
              >> OP_ENDIF
              >> If the thief does not publish the preimage of the hash within 1 week
              >> of the withdrawal time, then it becomes possible for anyone to spend
              >> the above script; basically, some lucky miner who wins the first block
              >> past the specified time will get the entire winnings.  Let us call the
              >> above script, the Theft Contract.
              >> The thief then recruits accomplices to the theft.  Note that the
              >> attack can be prepared and initiated before the accomplices are even
              >> recruited.
              >> The thief locks some coins (the "cut" the accomplice gets), to the
              >> below script, for each accomplice it tries to entice:
              >> OP_IF
              >>   OP_HASH160 <hash> OP_EQUALVERIFY
              >>   OP_DUP OP_HASH160 <accomplicePubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
              >> OP_ELSE
              >>   <withdrawTime+2week> OP_CHECKLOCKTIMEVERIFY OP_DROP
              >>   OP_DUP OP_HASH160 <thiefPubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
              >> OP_ENDIF
              >> Let us call the above script, the Accomplice Contract.  If the
              >> accomplice accepts, he or she then starts to vote for the invalid
              >> withdrawal.
              >> If the invalid withdrawal succeeds, the thief acquires the entire
              >> theft price from the Theft Contract by publishing the preimage to the
              >> <hash>.  (If he or she does not, then, some randomly-selected miner
              >> will acquire the money after the timeout, so the thief needs to
              >> publish the hash, before the timeout in the Theft Contract).
              >> This publishes the preimage on the blockchain.  Each accomplice can
              >> then acquire their "cut" of the theft by copying the preimage and
              >> claiming from the Accomplice Contract.
              >> If the theft never succeeds, then there is no reason for the thief to
              >> ever publish the preimage, and after the timeout on the Accomplice
              >> Contract, the thief can recover his or her offered funds at no loss
              >> (minus transaction fees),  This incentivizes accomplices to actually
              >> cooperate with the thief, as they will not get paid if the theft does
              >> not push through.
              >> All that is necessary is for a single "mastermind" thief to begin this
              >> process.  Accomplices can be recruited later, with the "cut" they get
              >> negotiated according to how much hashpower they can bring to bear on
              >> theft.
              >> Newly-created miners and mining pools can be enticed at the time they
              >> arise by offering an Accomplice Contract to them.  Thus, newly-created
              >> miners and mining pools can be brought into cooperation with the thief
              >> as soon as they make a presence on the blockchain.
              >> Even if some mining pool makes a public statement that they will not
              >> assist in the theft, the thief may still commit an Accomplice Contract
              >> for them on-chain anyway, and publicize it, in order to put the
              >> integrity of that mining pool in question and drive out support from
              >> that mining pool.  True accomplices may pretend to initially be honest
              >> and then signal dishonestly later, in order to make it more plausible
              >> that a pool that "committed" to not support the theft is not trustable
              >> since they have an Accomplice Contract that will compensate them if
              >> they support the theft, creating further confusion and discord among
              >> honest miners.  The thief may also use the existence of such an
              >> Accomplice Contract while negotiating with more minor miners and
              >> mining pools, in order to entice those also to join, and thus gain
              >> additional buffer against the stochastic process of miner voting.
              >> With the Theft Contract and the Accomplice Contract, negotiation can
              >> be done in parallel with the theft attempt, reducing the cost of
              >> organizing collective action, as we have all hoped "smart contracts"
              >> would do.
              >> ---------------------------------------------------------------
              >>
              >> While it is true, that this requires that the thief have significant
              >> funds in reserve prior to theft (in order to fund the Accomplice
              >> Contracts he or she will have to offer to potential accomplices), we
              >> have always been assured that theft can be initiated by miners only,
              >> and that miners already have a significant amount of money they
              >> control.  So it will be no problem for a potential thief to reserve
              >> some funds for paying to Accomplice Contracts.
              >> This vulnerability can be fixed if withdrawals are restricted to
              >> simple P2PKH or P2WPKH only, but in the presence of Scriptless Script
              >> and Bellare-Neven signatures, that may be sufficient to create the
              >> Theft Contract and the Accomplice Contract (but I know too little of
              >> Scriptless Script to be sure).
              >> Regards,
              >> ZmnSCPxj
              
              [-- Attachment #2: Type: text/html, Size: 12198 bytes --]
              
              ^ permalink raw reply	[flat|nested] 16+ messages in thread

  • * Re: [bitcoin-dev] Two Drivechain BIPs
      2017-12-03 21:32 ` Matt Corallo
      2017-12-04 19:05   ` Paul Sztorc
    @ 2017-12-05  7:41   ` Luke Dashjr
      1 sibling, 0 replies; 16+ messages in thread
    From: Luke Dashjr @ 2017-12-05  7:41 UTC (permalink / raw)
      To: Matt Corallo; +Cc: Bitcoin Protocol Discussion, luke_bipeditor
    
    On Sunday 03 December 2017 9:32:15 PM Matt Corallo wrote:
    > Given the lack of convincing evidence of that "Risk of centralisation of
    > mining" drawback in section 4.3 of the sidechains paper has been
    > meaningfully addressed, I'd say its pretty important that new sidechains be
    > an incredibly rare event.
    
    This is impossible to guarantee. Federated sidechains are already possible 
    with simple multisig (and they could very well be merge-mined chains instead 
    of simply signed). At the same time, the value of permissionless sidechain 
    innovation is potentially huge.
    
    Luke
    
    
    ^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2017-12-14  3:24 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-01 18:38 [bitcoin-dev] Two Drivechain BIPs Paul Sztorc
2017-12-03 21:32 ` Matt Corallo
2017-12-04 19:05   ` Paul Sztorc
2017-12-04 19:36     ` Chris Pacia
2017-12-04 20:11       ` Chris Stewart
2017-12-05 19:55         ` Paul Sztorc
2017-12-07  7:28           ` ZmnSCPxj
2017-12-12 22:16             ` Paul Sztorc
2017-12-05 18:05       ` Paul Sztorc
2017-12-05 18:20         ` AJ West
2017-12-06  4:49         ` ZmnSCPxj
2017-12-06 20:51           ` CryptAxe
2017-12-08 15:40             ` ZmnSCPxj
2017-12-12 22:29           ` Paul Sztorc
2017-12-14  3:24             ` ZmnSCPxj
2017-12-05  7:41   ` Luke Dashjr

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox