[bitcoin-dev] Two Drivechain BIPs

[bitcoin-dev] Two Drivechain BIPs

[Paul Sztorc]

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

Re: [bitcoin-dev] Two Drivechain BIPs

[Matt Corallo]

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
> 

Re: [bitcoin-dev] Two Drivechain BIPs

[Paul Sztorc]

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
>>

Re: [bitcoin-dev] Two Drivechain BIPs

[Chris Pacia]

[-- 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 --]

Re: [bitcoin-dev] Two Drivechain BIPs

[Chris Stewart]

[-- 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 --]

Re: [bitcoin-dev] Two Drivechain BIPs

[Paul Sztorc]

[-- 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 --]

Re: [bitcoin-dev] Two Drivechain BIPs

[ZmnSCPxj]

[-- 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 --]

Re: [bitcoin-dev] Two Drivechain BIPs

[Paul Sztorc]

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

Re: [bitcoin-dev] Two Drivechain BIPs

[Paul Sztorc]

[-- 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 --]

Re: [bitcoin-dev] Two Drivechain BIPs

[AJ West]

[-- 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 --]

Re: [bitcoin-dev] Two Drivechain BIPs

[ZmnSCPxj]

[-- 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 --]

Re: [bitcoin-dev] Two Drivechain BIPs

[CryptAxe]

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!

Re: [bitcoin-dev] Two Drivechain BIPs

[ZmnSCPxj]

[-- 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 --]

Re: [bitcoin-dev] Two Drivechain BIPs

[Paul Sztorc]

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

Re: [bitcoin-dev] Two Drivechain BIPs

[ZmnSCPxj]

[-- 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 --]

Re: [bitcoin-dev] Two Drivechain BIPs

[Luke Dashjr]

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