[bitcoin-dev] Drivechain -- Request for Discussion

[bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc]

Dear list,

I've been working on "drivechain", a sidechain enabling technology, for
some time.

* The technical info site is here: www.drivechain.info
* The changes to Bitcoin are here:
https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
* A Blank sidechain template is here:
https://github.com/drivechain-project/bitcoin/tree/sidechainBMM

As many of you know, I've been seeking feedback in person, at various
conferences and meetups over the past year, most prominently Scaling
Milan. And I intend to continue to seek feedback at Consensus2017 this
week, so if you are in NYC please just walk up and start talking to me!

But I also wanted to ask the list for feedback. Initially, I was
hesitant because I try not to consume reviewers' scarce time until the
author has put in a serious effort. However, I may have waiting too
long, as today it is actually quite close to a working release.


Scaling Implications
---------------------

This upgrade would have significant scaling implications. Since it is
the case that sidechains can be added by soft fork, and since each of
these chains will have its own blockspace, this theoretically removes
the blocksize limit from "the Bitcoin system" (if one includes
sidechains as part of such a system). People who want a LargeBlock
bitcoin can just move their BTC over to such a network [1], and their
txns will have no longer have an impact on "Bitcoin Core". Thus, even
though this upgrade does not actually increase "scalability" per se, it
may in fact put an end to the scalability debate...forever.

This work includes the relatively new concept of "Blind Merged Mining"
[2] which I developed in January to allow SHA256^2 miners to merge-mine
these "drivechains", even if these miners aren't running the actual
sidechain software. The goal is to prevent sidechains from affecting the
levelness of the mining "playing field". BMM is conceptually similar to
ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
required for drivechain, but it would address some of the last remaining
concerns.


Total Transaction Fees in the Far Future
-----------------------------------------

Some people feel that a maximum blocksize limit is needed to ensure that
future total equilibrium transaction fees are non-negligible. I
presented [4] on why I don't agree, 8 months ago. The reviewers I spoke
to over the last year have stopped bringing this complaint up, but I am
not sure everyone feels that way.


Juxtaposition with a recent "Scaling Compromise"
-------------------------------------------------

Recently, a scalability proposal began to circulate on social media. As
far as I could tell, it goes something like "immediately activate
SegWit, and then HF to double the nonwitness blockspace to 2MB within 12
months". But such a proposal is quite meager, compared to a "LargeBlock
Drivechain". The drivechain is better on both fronts, as it would not
require a hardfork, and could *almost immediately* add _any_ amount of
extra blockspace (specifically, I might expect a BIP101-like LargeBlock
chain that has an 8 MB maxblocksize, which doubles every two years).

In other words, I don't know why anyone would support that proposal over
mine. The only reasons would be either ignorance (ie, unfamiliarity with
drivechain) or because there are still nagging unspoken complaints about
drivechain which I apparently need to hear and address.


Other Thoughts
---------------

Unfortunately, anyone who worked on the "first generation" of sidechain
technology (the skiplist) or the "second generation" (federated /
Liquid), will find that this is very different.

I will admit that I am very pessimistic about any conversation that
involves scalability. It is often said that "talking politics lowers
your IQ by 25 points". Bitcoin scalability conversations seem to drain
50 points. (Instead of conversing, I think people should quietly work on
whatever they are passionate about until their problem either is solved,
or it goes away for some other reason, or until we all agree to just
stop talking about it.)

Cheers,
Paul

[1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
[2] http://www.truthcoin.info/blog/blind-merged-mining/
[3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
[4]
https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote:
> This work includes the relatively new concept of "Blind Merged Mining"
> [2] which I developed in January to allow SHA256^2 miners to merge-mine
> these "drivechains", even if these miners aren't running the actual
> sidechain software. The goal is to prevent sidechains from affecting the
> levelness of the mining "playing field". BMM is conceptually similar to
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
> required for drivechain, but it would address some of the last remaining
> concerns.

Thanks for the credit, although I think the security properties of what you're
proposing are very different - and much weaker - than what I proposed in
Zookeyv.

As you state in [2] "if miners never validate sidechains at all, whoever bids
the most for the chain (on a continuous basis), can spam a 3-month long stream
of invalid headers, and then withdraw all of the coins deposited to the
sidechain." and "Since the mining is blind, and the sidechain-withdrawal
security-level is SPV, miners who remain blind forever have no way of telling
who “should” really get the funds."

Finally, you suggest that in this event, miners *do* have to upgrade to a full
node, an expensive and time-consuming operation (and one that may be impossible
for some miners if necessary data isn't available).

It's unclear to me what the incentive is for miners to do any of this. Could
you explain in more detail what that incentive is?


> [2] http://www.truthcoin.info/blog/blind-merged-mining/
> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[ZmnSCPxj]

[-- Attachment #1: Type: text/plain, Size: 7715 bytes --]

Good morning Paul,

I read only http://www.truthcoin.info/blog/blind-merged-mining/

From just this document, I can't see a good justification for believing that a main->side locking transaction can be safely spent into a side->main unlocking transaction. Do you have a better explanation?

OP_is_h_in_coinbase, as described, does not seem to protect against a sidechain reorg in your next section of the document. If I attempt to spend a main->side locking transaction on the basis of a "mistaken" side block #49, what prevents me from this sequence:

1. Put a side:side->main transaction into a block together with TheDAO's hacked money.
2. Wait for a reorg to revert TheDAO.
3. Spend my now-free-in-the-reorg funds on Lightning Network to get mainchain funds.
4. Create a main:side->main transaction with the side:side->main transaction in the TheDAO-hacked block as witness.
5. Get another set of mainchain funds from the same sidechain funds.

So far, the only good side->main transfer I know of is in Blockstream's original sidechains paper, with the main:side->main transaction spending into a timelocked transaction that may be burned if a reorg proof is submitted (i.e. you try to create a main:side->main transaction with the side:side->main transaction in the mistaken #49 and #50 as your proof, but someone else can come along and show a corrected #49, #50, #51 without your side:side->main transaction and burn your funds). Is your proposal at the technical level actually similar, or does it truly seem to be riskier? It seems to me that your OP_is_h_in_coinbase should scan a series of sidechain block headers backed by mainchain (meaning at the minimum that sidechains should have some common header format prefix), rather than just mainchain depth as your article seems to imply.

Also, blinded merge mining seems strictly inferior to proof-of-burn: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/007012.html

Proof-of-burn integrates a lottery to reduce the ability of a mainchain-rich attacker to reorg the sidechain by burning its greater funds. However it still seems to me that a rich attacker can simply make more bets in that scheme by some trivial modification of the side block. Blind merged mining seems strictly inferior as a rich attacker can simply reorg the sidechain outright without playing such games.

Or is your proposal strictly for centralized sidechains, where only one entity creates side blocks? How does your proposal handle multiple side block creators on the same sidechain, with the possibility that chain splits occur?

Regarding your dig about people who dislike data centers, the main issue with miners blindly accepting sidechain commitments is that it violates "Don't trust, verify", not that allows datacenters to be slightly smaller by not including side:nodes.

Regards,
ZmnSCPxj

Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: [bitcoin-dev] Drivechain -- Request for Discussion
Local Time: May 22, 2017 6:17 AM
UTC Time: May 22, 2017 6:17 AM
From: bitcoin-dev@lists.linuxfoundation.org
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>

Dear list,

I've been working on "drivechain", a sidechain enabling technology, for
some time.

* The technical info site is here: www.drivechain.info
* The changes to Bitcoin are here:
https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
* A Blank sidechain template is here:
https://github.com/drivechain-project/bitcoin/tree/sidechainBMM

As many of you know, I've been seeking feedback in person, at various
conferences and meetups over the past year, most prominently Scaling
Milan. And I intend to continue to seek feedback at Consensus2017 this
week, so if you are in NYC please just walk up and start talking to me!

But I also wanted to ask the list for feedback. Initially, I was
hesitant because I try not to consume reviewers' scarce time until the
author has put in a serious effort. However, I may have waiting too
long, as today it is actually quite close to a working release.

Scaling Implications
---------------------

This upgrade would have significant scaling implications. Since it is
the case that sidechains can be added by soft fork, and since each of
these chains will have its own blockspace, this theoretically removes
the blocksize limit from "the Bitcoin system" (if one includes
sidechains as part of such a system). People who want a LargeBlock
bitcoin can just move their BTC over to such a network [1], and their
txns will have no longer have an impact on "Bitcoin Core". Thus, even
though this upgrade does not actually increase "scalability" per se, it
may in fact put an end to the scalability debate...forever.

This work includes the relatively new concept of "Blind Merged Mining"
[2] which I developed in January to allow SHA256^2 miners to merge-mine
these "drivechains", even if these miners aren't running the actual
sidechain software. The goal is to prevent sidechains from affecting the
levelness of the mining "playing field". BMM is conceptually similar to
ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
required for drivechain, but it would address some of the last remaining
concerns.

Total Transaction Fees in the Far Future
-----------------------------------------

Some people feel that a maximum blocksize limit is needed to ensure that
future total equilibrium transaction fees are non-negligible. I
presented [4] on why I don't agree, 8 months ago. The reviewers I spoke
to over the last year have stopped bringing this complaint up, but I am
not sure everyone feels that way.

Juxtaposition with a recent "Scaling Compromise"
-------------------------------------------------

Recently, a scalability proposal began to circulate on social media. As
far as I could tell, it goes something like "immediately activate
SegWit, and then HF to double the nonwitness blockspace to 2MB within 12
months". But such a proposal is quite meager, compared to a "LargeBlock
Drivechain". The drivechain is better on both fronts, as it would not
require a hardfork, and could *almost immediately* add _any_ amount of
extra blockspace (specifically, I might expect a BIP101-like LargeBlock
chain that has an 8 MB maxblocksize, which doubles every two years).

In other words, I don't know why anyone would support that proposal over
mine. The only reasons would be either ignorance (ie, unfamiliarity with
drivechain) or because there are still nagging unspoken complaints about
drivechain which I apparently need to hear and address.

Other Thoughts
---------------

Unfortunately, anyone who worked on the "first generation" of sidechain
technology (the skiplist) or the "second generation" (federated /
Liquid), will find that this is very different.

I will admit that I am very pessimistic about any conversation that
involves scalability. It is often said that "talking politics lowers
your IQ by 25 points". Bitcoin scalability conversations seem to drain
50 points. (Instead of conversing, I think people should quietly work on
whatever they are passionate about until their problem either is solved,
or it goes away for some other reason, or until we all agree to just
stop talking about it.)

Cheers,
Paul

[1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
[2] http://www.truthcoin.info/blog/blind-merged-mining/
[3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
[4]
https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 10034 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 3749 bytes --]

Charlie, I'll be mostly in the tech track, of course. And I've already
planned to meet RSK guys after their event tomorrow.

Ryan, the more review the better. We aren't in any direct rush, other than
the natural desire to have cool things as early as possible.

Peter, responses below:

On May 22, 2017 9:33 AM, "Peter Todd" <pete@petertodd.org> wrote:

On Mon, May 22, 2017 at 02:17:07AM -0400, Paul Sztorc via bitcoin-dev wrote:
> This work includes the relatively new concept of "Blind Merged Mining"
> [2] which I developed in January to allow SHA256^2 miners to merge-mine
> these "drivechains", even if these miners aren't running the actual
> sidechain software. The goal is to prevent sidechains from affecting the
> levelness of the mining "playing field". BMM is conceptually similar to
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
> required for drivechain, but it would address some of the last remaining
> concerns.

Thanks for the credit, although I think the security properties of what
you're
proposing are very different - and much weaker - than what I proposed in
Zookeyv.


As you state in [2] "if miners never validate sidechains at all, whoever
bids
the most for the chain (on a continuous basis), can spam a 3-month long
stream
of invalid headers, and then withdraw all of the coins deposited to the
sidechain." and "Since the mining is blind, and the sidechain-withdrawal
security-level is SPV, miners who remain blind forever have no way of
telling
who “should” really get the funds."

Finally, you suggest that in this event, miners *do* have to upgrade to a
full
node, an expensive and time-consuming operation (and one that may be
impossible
for some miners if necessary data isn't available).


Surprisingly, this requirement (or, more precisely, this incentive) does
not effect miners relative to each other. The incentive to upgrade is only
for the purpose of preventing a "theft" -- defined as: an improper
withdrawal from a sidechain. It is not about miner revenues or the ability
to mine generally (or conduct BMM specifically). The costs of such a theft
(decrease in market price, decrease in future transaction fee levels) would
be shared collectively by all future miners. Therefore, it would have no
effect on miners relative to each other.

Moreover, miners have other recourse if they are unable to run the node.
They can adopt a policy of simply rejecting ("downvoting") any withdrawals
that they don't understand. This would pause the withdraw process until
enough miners understand enough of what is going on to proceed with it.

Finally, the point in dispute is a single, infrequent, true/false question.
So miners may resort to semi-trusted methods to supplement their decision.
In other words, they can just ask people they trust, if the withdrawal is
correct or not. It is up to users to decide if they are comfortable with
these risks, if/when they decide to deposit to a sidechain.


It's unclear to me what the incentive is for miners to do any of this. Could
you explain in more detail what that incentive is?


It is a matter of comparing the costs and benefits. Ignoring theft, the
costs are near-zero, and the benefits are >0. Specifically, they are: a
higher BTC price and greater transaction fees. Theft is discouraged by
attempting to tie a theft to a loss of confidence in the miners, as
described in the spec/website.
In general the incentives are very similar to those of Bitcoin itself.

Paul



> [2] http://www.truthcoin.info/blog/blind-merged-mining/
> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log

--
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Type: text/html, Size: 5724 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 8214 bytes --]

On May 22, 2017 10:39 AM, "ZmnSCPxj" <ZmnSCPxj@protonmail.com> wrote:

Good morning Paul,

I read only http://www.truthcoin.info/blog/blind-merged-mining/

From just this document, I can't see a good justification for believing
that a main->side locking transaction can be safely spent into a side->main
unlocking transaction.  Do you have a better explanation?


Yes, a better explanation is in the drivechain spec, at:
http://www.truthcoin.info/blog/drivechain/

What you read is only an introduction of BMM. You may also consult the
notes (at the bottom of the BMM post) or the code, although this is time
consuming of course.


If I attempt to spend a main->side locking transaction on the basis of a
"mistaken" side block #49, what prevents me from this sequence:


The literal answer to your question is that mainchain Bitcoin will notice
that, for the second withdrawal, the sum of the inputs is less than the sum
of the outputs and they the transaction is therefore invalid.


1.  Put a side:side->main transaction into a block together with TheDAO's
hacked money.

So far, the only good side->main transfer I know of is in Blockstream's
original sidechains paper, with the main:side->main transaction ... Is your
proposal at the technical level actually similar, or does it truly seem to
be riskier?


I feel that my proposal is more secure, as it can operate healthily and
quickly while using spv proofs which are much slower and much much easier
to audit.


seems to me that your OP_is_h_in_coinbase should scan a series of sidechain
block headers backed by mainchain (meaning at the minimum that sidechains
should have some common header format prefix), rather than just mainchain
depth as your article seems to imply.


How would security be improved as a result? In either case, 51% of hashrate
can cause a reorg. The sidechain software itself does scan block headers,
of course.


Blind merged mining seems strictly inferior ... a rich attacker can simply
reorg the sidechain outright without playing such games.


In the future, when there is no block subsidy, a rich attacker can also do
that in mainchain Bitcoin.


Or is your proposal strictly for centralized sidechains, where only one
entity creates side blocks?


Not at all.

How does your proposal handle multiple side block creators on the same
sidechain, with the possibility that chain splits occur?


The side block is only "mined" if it is committed to in a mainchain Bitcoin
blog, and each mainchain block can only contain one block per sidechain. In
this way, drivechain sidechains are different from classical Namecoin
merged mining (where one _could_ run the entire system, mining included,
without interfacing with Bitcoin at all).


Regarding your dig about people who dislike data centers, the main issue
with miners blindly accepting sidechain commitments is that it violates
"Don't trust, verify", not that allows datacenters to be slightly smaller
by not including side:nodes.


As I explain early on, in earlier rounds of peer review, the focus was on
harms the sidechain technology might do to mainchain Bitcoin, and the
"datacenter point" was specifically the chief objection raised. So I am
afraid you are entirely incorrect.

In point of fact, the transactions *are* validated...by sidechain full
nodes, same as Bitcoin proper.

Paul


Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

-------- Original Message --------
Subject: [bitcoin-dev] Drivechain -- Request for Discussion
Local Time: May 22, 2017 6:17 AM
UTC Time: May 22, 2017 6:17 AM
From: bitcoin-dev@lists.linuxfoundation.org
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>

Dear list,

I've been working on "drivechain", a sidechain enabling technology, for
some time.

* The technical info site is here: www.drivechain.info
* The changes to Bitcoin are here:
https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
* A Blank sidechain template is here:
https://github.com/drivechain-project/bitcoin/tree/sidechainBMM

As many of you know, I've been seeking feedback in person, at various
conferences and meetups over the past year, most prominently Scaling
Milan. And I intend to continue to seek feedback at Consensus2017 this
week, so if you are in NYC please just walk up and start talking to me!

But I also wanted to ask the list for feedback. Initially, I was
hesitant because I try not to consume reviewers' scarce time until the
author has put in a serious effort. However, I may have waiting too
long, as today it is actually quite close to a working release.


Scaling Implications
---------------------

This upgrade would have significant scaling implications. Since it is
the case that sidechains can be added by soft fork, and since each of
these chains will have its own blockspace, this theoretically removes
the blocksize limit from "the Bitcoin system" (if one includes
sidechains as part of such a system). People who want a LargeBlock
bitcoin can just move their BTC over to such a network [1], and their
txns will have no longer have an impact on "Bitcoin Core". Thus, even
though this upgrade does not actually increase "scalability" per se, it
may in fact put an end to the scalability debate...forever.

This work includes the relatively new concept of "Blind Merged Mining"
[2] which I developed in January to allow SHA256^2 miners to merge-mine
these "drivechains", even if these miners aren't running the actual
sidechain software. The goal is to prevent sidechains from affecting the
levelness of the mining "playing field". BMM is conceptually similar to
ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
required for drivechain, but it would address some of the last remaining
concerns.


Total Transaction Fees in the Far Future
-----------------------------------------

Some people feel that a maximum blocksize limit is needed to ensure that
future total equilibrium transaction fees are non-negligible. I
presented [4] on why I don't agree, 8 months ago. The reviewers I spoke
to over the last year have stopped bringing this complaint up, but I am
not sure everyone feels that way.


Juxtaposition with a recent "Scaling Compromise"
-------------------------------------------------

Recently, a scalability proposal began to circulate on social media. As
far as I could tell, it goes something like "immediately activate
SegWit, and then HF to double the nonwitness blockspace to 2MB within 12
months". But such a proposal is quite meager, compared to a "LargeBlock
Drivechain". The drivechain is better on both fronts, as it would not
require a hardfork, and could *almost immediately* add _any_ amount of
extra blockspace (specifically, I might expect a BIP101-like LargeBlock
chain that has an 8 MB maxblocksize, which doubles every two years).

In other words, I don't know why anyone would support that proposal over
mine. The only reasons would be either ignorance (ie, unfamiliarity with
drivechain) or because there are still nagging unspoken complaints about
drivechain which I apparently need to hear and address.


Other Thoughts
---------------

Unfortunately, anyone who worked on the "first generation" of sidechain
technology (the skiplist) or the "second generation" (federated /
Liquid), will find that this is very different.

I will admit that I am very pessimistic about any conversation that
involves scalability. It is often said that "talking politics lowers
your IQ by 25 points". Bitcoin scalability conversations seem to drain
50 points. (Instead of conversing, I think people should quietly work on
whatever they are passionate about until their problem either is solved,
or it goes away for some other reason, or until we all agree to just
stop talking about it.)

Cheers,
Paul

[1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
[2] http://www.truthcoin.info/blog/blind-merged-mining/
[3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
[4]
https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-
6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 14442 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> In the future, when there is no block subsidy, a rich attacker can also do
> that in mainchain Bitcoin.
>

I don't think they are the same.

With Bitcoin, you only get to reverse recent transactions.  If you actually
reversed 2-3 weeks of transactions, then the Bitcoin price would fall,
destroying the value of the additional coins you managed to obtain.  Even
if their was no price fall, you can only get a fraction of the total.

With BMM, you can "buy" the entire reserve of the sidechain by paying
(timeout) * (average tx fees).  If you destroy a side-chain's value, then
that doesn't affect the value of the bitcoins you manage to steal.

The incentive could be eliminated by restricting the amount of coin that
can be transferred from the side chain to the main chain to a fraction of
the transaction fee pay to the bitcoin miners.

If the side chain pays x in fees, then at most x/10 can be transferred from
the side chain to the main chain.  This means that someone who pays for
block creation can only get 10% of that value transferred to the main chain.

Main-chain miners could support fraud proofs.  A pool could easily run an
archive node for the side chain in a different data center.

This wouldn't harm the performance of their main operations, but would
guarantee that the side chain data is available for side chain validators.

The sidechain to main-chain timeout would be more than enough for fraud
proofs to be constructed.

This means that the miners would need to know what the rules are for the
side chain, so that they can process the fraud proofs.  They would also
need to run SPV nodes for the side chain, so they know which sidechain
headers to blacklist.


> In point of fact, the transactions *are* validated...by sidechain full
> nodes, same as Bitcoin proper.
>
>
The big difference is that Bitcoin holds no assets on another chain.  A
side-chain's value is directly linked to the fact that it has 100% reserves
on the Bitcoin main chain.  That can be targeted for theft.


> Paul
>
>
> Regards,
> ZmnSCPxj
>
>

[-- Attachment #2: Type: text/html, Size: 3855 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]

On May 22, 2017 3:13 PM, "Tier Nolan via bitcoin-dev" <bitcoin-dev@lists.
linuxfoundation.org> wrote:

On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> In the future, when there is no block subsidy, a rich attacker can also do
> that in mainchain Bitcoin.
>

I don't think they are the same.

With Bitcoin, you only get to reverse recent transactions.  If you actually
reversed 2-3 weeks of transactions, then the Bitcoin price would fall,
destroying the value of the additional coins you managed to obtain.  Even
if their was no price fall, you can only get a fraction of the total.


I would replace "Bitcoins you manage to steal" with "Bitcoins you manage to
double-spend". Then, it still seems the same to me.


With BMM, you can "buy" the entire reserve of the sidechain by paying
(timeout) * (average tx fees).  If you destroy a side-chain's value, then
that doesn't affect the value of the bitcoins you manage to steal.


It may destroy great value if it shakes confidence in the sidechain
infrastructure. Thus, the value of the stolen BTC may decrease, in addition
to the lost future tx fee revenues of the attacked chain.

http://www.truthcoin.info/blog/drivechain/#drivechains-security

In my view, sidechains should only exist at all if they positively impact
Bitcoin's value. It is therefore desirable for miners to steal from chains
that provide no value-add.




> In point of fact, the transactions *are* validated...by sidechain full
> nodes, same as Bitcoin proper.
>
>
The big difference is that Bitcoin holds no assets on another chain.  A
side-chain's value is directly linked to the fact that it has 100% reserves
on the Bitcoin main chain.  That can be targeted for theft.


Again, I don't really think it is that different. One could interchange
"recent txns" (those which could be double-spent within 2-3 weeks) with
"sidechain deposit tnxs".

[-- Attachment #2: Type: text/html, Size: 4725 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[ZmnSCPxj]

[-- Attachment #1: Type: text/plain, Size: 5447 bytes --]

Good morning,

>What you read is only an introduction of BMM. You may also consult the notes (at the bottom of the BMM post) or the code, although this is time consuming of course.

Looking over the code, I have a question: Is OP_BRIBE supposed to be softforked in, or hardforked? From my understanding, the code as published in your linked github cannot be softforked in, since it is not a softfork-compatible replacement for OP_NOP: it replaces the stack top value with a 0/1 value. Both CLTV and CSV do not touch the stack, only flag an error if they fail.

(What happens if the h* to be put in the coinbase, by chance - even very unlikely chance - is 0? Then <h*> OP_NOP4 is not the same as <h*> OP_BRIBE scripts in result - the former will be rejected by old nodes, the latter will be accepted by new nodes)

Does Drivechain require a hardfork? My understanding is that you want to use some kind of softforked anyone-can-spend transaction to use Drivechain. So I don't quite understand why OP_BRIBE is written the way it is.

Is OP_BRIBE the same as the OP_h_is_in_coinbase operation you described?

How is OP_BRIBE superior to just using a <h*> OP_RETURN script? Cannot a sidechain scan the block for OP_RETURN attesting that the block hash is present in the block? OP_BRIBE encodes <h*> twice (once in the transaction, once in the coinbase), OP_RETURN encodes it once (once in the transaction)

>The literal answer to your question is that mainchain Bitcoin will notice that, for the second withdrawal, the sum of the inputs is less than the sum of the outputs and they the transaction is therefore invalid.

You misunderstand. The first withdrawal was done by double-spending, and exchanging your sidechain funds for mainchain funds using some off-chain method. The second withdrawal is done on-chain.

That said, I confused OP_h_is_in_coinbase as your method of getting out of the sidechain into the mainchain. It seems, OP_h_is_in_coinbase is only for blind mining?

>I feel that my proposal is more secure, as it can operate healthily and quickly while using spv proofs which are much slower and much much easier to audit.

I don't quite understand how Drivechain handles sidechain reorgs, while keeping Bitcoin miners blinded. It seems sidechains need to be known ("seen") by the miner, so I don't see what is being blinded by blinded merge mining.

>>seems to me that your OP_is_h_in_coinbase should scan a series of sidechain block headers backed by mainchain (meaning at the minimum that sidechains should have some common header format prefix), rather than just mainchain depth as your article seems to imply.
>
>How would security be improved as a result? In either case, 51% of hashrate can cause a reorg. The sidechain software itself does scan block headers, of course.

I misunderstand the purpose of your OP_is_h_in_coinbase, sorry.

>>Blind merged mining seems strictly inferior ... a rich attacker can simply reorg the sidechain outright without playing such games.
>
>In the future, when there is no block subsidy, a rich attacker can also do that in mainchain Bitcoin.

I see. However, block subsidies will drop far in the future, do you mean to say, that sidechains will be used only in the far future?

>>How does your proposal handle multiple side block creators on the same sidechain, with the possibility that chain splits occur?
>
>The side block is only "mined" if it is committed to in a mainchain Bitcoin blog, and each mainchain block can only contain one block per sidechain. In this way, drivechain sidechains are different from classical Namecoin merged mining (where one _could_ run the entire system, mining included, without interfacing with Bitcoin at all).

I assume you mean "mainchain Bitcoin block" here.

What mechanism ensures only one mainchain block can contain only one sidechain block? It seems, this isn't implemented by OP_BRIBE yet. Can you elaborate on this mechanism?

>>Regarding your dig about people who dislike data centers, the main issue with miners blindly accepting sidechain commitments is that it violates "Don't trust, verify", not that allows datacenters to be slightly smaller by not including side:nodes.
>
>As I explain early on, in earlier rounds of peer review, the focus was on harms the sidechain technology might do to mainchain Bitcoin, and the "datacenter point" was specifically the chief objection raised. So I am afraid you are entirely incorrect.

I see. It seems, the main problem, is that sidechains can be used to sneak in block size increases. Of course, the advantage of sidechains, is that when it increases block size irresponsibly, only those who participated in the sidechain will suffer.

>In point of fact, the transactions *are* validated...by sidechain full nodes, same as Bitcoin proper.

But from blind merge mining by itself, how would the blinded merge miner know that there exists an actual sidechain full node that actually did validation?

It seems, that the "blinding" in merge mining does not seem to be at all useful without the miner actually seeing the sidechain. If you want miners to upgrade to side:fullnode as well, what would then be the point of blinding? Why not just ordinary merge mining?

Perhaps the datacenter point is simply that your proposal suggests to reduce the size of the datacenter by removing surge suppressors and UPS's, to avoid some definition of "datacenter is a room with >$XXX of equipment".

Regards,
ZmnSCPxj

[-- Attachment #2: Type: text/html, Size: 6646 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 3102 bytes --]

On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc <truthcoin@gmail.com> wrote:

> I would replace "Bitcoins you manage to steal" with "Bitcoins you manage
> to double-spend". Then, it still seems the same to me.
>
>
With double spending, you can only get ownership of coins that you owned at
some point in the past.  Coins that are owned by someone else from coinbase
to their current owners cannot be stolen by a re-org (though they can be
moved around).

With BMM, you can take the entire reserve.  Creating a group of double
spenders can help increase the reward.


>
> It may destroy great value if it shakes confidence in the sidechain
> infrastructure. Thus, the value of the stolen BTC may decrease, in addition
> to the lost future tx fee revenues of the attacked chain.
>
> http://www.truthcoin.info/blog/drivechain/#drivechains-security
>
>
That is a fair point.  If sidechains are how Bitcoin is scaled, then
shaking confidence in a side-chain would shake confidence in Bitcoin's
future.

I wasn't thinking of a direct miner 51% attack.  It is enough to assume
that a majority of the miners go with the highest bidder each time.

If (average fees) * (timeout) is less than the total reserves, then it is
worth it for a 3rd party to just bid for his theft fork.  Miners don't have
to be assumed to be coordinating, they just have to be assumed to take the
highest bid.

Again, I don't really think it is that different. One could interchange
> "recent txns" (those which could be double-spent within 2-3 weeks) with
> "sidechain deposit tnxs".
>

It is not "recent txns", it is recent txns that you (or your group) have
the key for.  No coordination is required to steal the entire reserve from
the sidechain.

Recent txns and money on the sidechain have the property that they are
riskier than money deep on the main chain.  This is the inherent point
about sidechains, so maybe not that big a deal.

My concern is that you could have a situation where an attack is possible
and only need to assume that the miners are indifferent.

If the first attacker who tries it fails (say after creating a fork that is
90% of the length required, so losing a lot of money), then it would
discourage others.   If he succeeds, then it weakens sidechains as a
concept and that creates the incentive for miners to see that he fails.

I wonder how the incentives work out.  If a group had 25% of the money on
the sidechain, they could try to outbid the attacker.

In fact, since the attacker, by definition, creates an illegal fork, the
effect is that he reduces the block rate for the side chain (possibly to
zero, if he wins every auction).  This means that there are more
transactions per block, if there is space, or more fees per transaction, if
the blocks are full.

In both cases, this pushes up the total fees per block, so he has to pay
more per block, weakening his attack.  This is similar to where transaction
spam on Bitcoin is self-correcting by increasing the fees required to keep
the spam going.

Is there a description of the actual implementation you decided to go with,
other than the code?

[-- Attachment #2: Type: text/html, Size: 4489 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc]

On 5/22/2017 8:13 PM, ZmnSCPxj wrote:
> Good morning,
> 
> 
> 
>>What you read is only an introduction of BMM. You may also consult the
> notes (at the bottom of the BMM post) or the code, although this is time
> consuming of course.
> 
> Looking over the code, I have a question: Is OP_BRIBE supposed to be
> softforked in, or hardforked?

Softforked, of course.

  From my understanding, the code as
> published in your linked github cannot be softforked in, since it is not
> a softfork-compatible replacement for OP_NOP: it replaces the stack top
> value with a 0/1 value.  Both CLTV and CSV do not touch the stack, only
> flag an error if they fail.

Your understanding may exceed my own. I don't understand the principle
of your distinction, as it seems to me that one could add a new protocol
rule which says that the block is invalid unless the OP Code does
results in arbitrary-item-x. The intent is to mimic CLTV or CSV
behavior, by causing something that would otherwise succeed, to fail, if
arbitrary new conditions are met.

> 
> (What happens if the h* to be put in the coinbase, by chance - even very
> unlikely chance - is 0?  Then <h*> OP_NOP4 is not the same as <h*>
> OP_BRIBE scripts in result - the former will be rejected by old nodes,
> the latter will be accepted by new nodes)

That would indeed be a bug, if it happened as you described. I will
check when I get the chance, thanks.

> 
> Is OP_BRIBE the same as the OP_h_is_in_coinbase operation you described?

Yes. Sorry if that was confusing.

> 
> How is OP_BRIBE superior to just using a <h*> OP_RETURN script? Cannot
> a sidechain scan the block for OP_RETURN attesting that the block hash
> is present in the block?

The sidechain software can indeed, but the mainchain software cannot
(without making validation of both chains part of the mainchain, which
defeats the original purpose of sidechains).

The purpose of OP_BRIBE is to allow "Sam" (on the sidechain) and "Mary"
(a mainchain miner) to work together. Sam would pay X BTC to Mary, if
Mary could provide Sam with some guarantee that Sam's sidechain block
[defined by h*] would make it into the largest chain.

So, as I see it, this needs to be a mainchain consensus rule, but one
which enforces the bare minimum criteria.


> 
>>The literal answer to your question is that mainchain Bitcoin will
> notice that, for the second withdrawal, the sum of the inputs is less
> than the sum of the outputs and they the transaction is therefore invalid.
> 
> You misunderstand.  The first withdrawal was done by double-spending,
> and exchanging your sidechain funds for mainchain funds using some
> off-chain method.  The second withdrawal is done on-chain.

If A, B, and C are transacting, and each has an account on both chains.
Then your example would be something like:

1. main:A sends 100 to side:A, then transfers 100 to side:B in exchange
for B's good or service (provided on the sidechain)
2. side:B attempts to move side-to-main with the 100 BTC, using the
lightning network. He swaps 100 side:BTC for 100 of C's main:BTC.
3. C attempts to move side-to-main, using the slow, settlement method.
4. C's side-to-main sidechain tx (wt) is bundled with others and becomes
a withdrawal attempt (WT^)
5. The WT^ attempt is initiated on the mainchain.
6. After a waiting period, the WT^ begins to accumulate ACKs or NACKs
(upvotes / downvotes), on the mainchain.
7. The transaction either succeeds or fails.

I'm not sure, but your question seems to concern B, who exploits a reorg
that happens just after step 2. After the reorg, the sidechain chain
history will have a different side-to-main withdrawal in part 3. The
time between each of these step is very long, on the order of weeks
(summing to a length of time totaling months), for exactly this reason
(as well as to encourage people to avoid using this 'formal' method, in
favor of the cooperative LN and Atomic Swaps).

I think that this principle of scale (ie, very VERY slow withdrawals) is
important and actually makes the security categorically different.

For extraordinary DAO-like situations, disinterested mainchain miners
merely need a single bit of information (per sidechain), which is
"distress=true", and indicates to them to temporarily stop ACKing
withdrawals from the sidechain. This alone is enough to give the reorg
an unlimited amount of time to work itself out.


> 
> That said, I confused OP_h_is_in_coinbase as your method of getting out
> of the sidechain into the mainchain.  It seems, OP_h_is_in_coinbase is
> only for blind mining?

Correct

> 
> 
> 
>>I feel that my proposal is more secure, as it can operate healthily and
> quickly while using spv proofs which are much slower and much much
> easier to audit.
> 
> I don't quite understand how Drivechain handles sidechain reorgs, while
> keeping Bitcoin miners blinded.  It seems sidechains need to be known
> ("seen") by the miner, so I don't see what is being blinded by blinded
> merge mining.

Mainchain miners do need to maintain some data about the sidechains, but
this is very minimal, and certainly does not include the transaction
data (or arbitrary messages) of the sidechain.
> 
> 
>>>seems to me that your OP_is_h_in_coinbase should scan a series of
> sidechain block headers backed by mainchain (meaning at the minimum that
> sidechains should have some common header format prefix), rather than
> just mainchain depth as your article seems to imply.
>>
>>How would security be improved as a result? In either case, 51% of
> hashrate can cause a reorg. The sidechain software itself does scan
> block headers, of course. 
> 
> I misunderstand the purpose of your OP_is_h_in_coinbase, sorry.
> 

No problem.

> 
>>>Blind merged mining seems strictly inferior ... a rich attacker can
> simply reorg the sidechain outright without playing such games.
>>
>>In the future, when there is no block subsidy, a rich attacker can also
> do that in mainchain Bitcoin.
> 
> I see.  However, block subsidies will drop far in the future, do you
> mean to say, that sidechains will be used only in the far future?

In one sense, I mean "you have already endorsed this 'fees only will
work' premise, by endorsing Bitcoin".

In another sense I mean "isn't it great that you will get a tiny
preview, today, of future-Bitcoin's behavior?".

> 
>>>How does your proposal handle multiple side block creators on the same
> sidechain, with the possibility that chain splits occur?
>>
>>The side block is only "mined" if it is committed to in a mainchain
> Bitcoin blog, and each mainchain block can only contain one block per
> sidechain. In this way, drivechain sidechains are different from
> classical Namecoin merged mining (where one _could_ run the entire
> system, mining included, without interfacing with Bitcoin at all).
> 
> I assume you mean "mainchain Bitcoin block" here.
> 
> What mechanism ensures only one mainchain block can contain only one
> sidechain block?  It seems, this isn't implemented by OP_BRIBE yet.  Can
> you elaborate on this mechanism?

That mechanism is enforced by drivechain itself, not OP_BRIBE. (OP Bribe
is itself only ~half of BMM. I admit it is getting a little confusing.)

Drivechain requires a soft fork to add each new sidechain. It requires
this literally for a few good reasons...but the best is: there is an
implicit requirement that the miners not steal from the sidechain
anyway. In this way drivechain knows how to keep track of what it should
expect.

> 
> 
>>>Regarding your dig about people who dislike data centers, the main
> issue with miners blindly accepting sidechain commitments is that it
> violates "Don't trust, verify", not that allows datacenters to be
> slightly smaller by not including side:nodes.
>>
>>As I explain early on, in earlier rounds of peer review, the focus was
> on harms the sidechain technology might do to mainchain Bitcoin, and the
> "datacenter point" was specifically the chief objection raised. So I am
> afraid you are entirely incorrect.
> 
> I see.  It seems, the main problem, is that sidechains can be used to
> sneak in block size increases.  Of course, the advantage of sidechains,
> is that when it increases block size irresponsibly, only those who
> participated in the sidechain will suffer.

Precisely.

> 
>>In point of fact, the transactions *are* validated...by sidechain full
> nodes, same as Bitcoin proper.
> 
> But from blind merge mining by itself, how would the blinded merge miner
> know that there exists an actual sidechain full node that actually did
> validation?
> 
> It seems, that the "blinding" in merge mining does not seem to be at all
> useful without the miner actually seeing the sidechain.  If you want
> miners to upgrade to side:fullnode as well, what would then be the point
> of blinding?  Why not just ordinary merge mining?
> 
> Perhaps the datacenter point is simply that your proposal suggests to
> reduce the size of the datacenter by removing surge suppressors and
> UPS's, to avoid some definition of "datacenter is a room with >$XXX of
> equipment".

I hope that my replies above already help with these. If not, let me know.

Thanks for your attention,
Paul

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc]

On 5/23/2017 5:51 AM, Tier Nolan via bitcoin-dev wrote:
> On Mon, May 22, 2017 at 9:00 PM, Paul Sztorc <truthcoin@gmail.com
> <mailto:truthcoin@gmail.com>> wrote:
> 
>     I would replace "Bitcoins you manage to steal" with "Bitcoins you
>     manage to double-spend". Then, it still seems the same to me.
> 
> 
> With double spending, you can only get ownership of coins that you owned
> at some point in the past.  Coins that are owned by someone else from
> coinbase to their current owners cannot be stolen by a re-org (though
> they can be moved around).

I'm not sure it makes much of a difference. First of all, in point of
fact, the miners themselves own the coins from the coinbase. But more
importantly, even if miners did not explicitly own the coins, they might
profit by being bribed -- these bribes would come from people who did
own the coins.

The principle is that value "v' has been taken from A and given to B.
This is effectively coercive activity, and therefore itself has value
proportional to 'v'.

> 
> With BMM, you can take the entire reserve.  Creating a group of double
> spenders can help increase the reward.
>  
> 
> 
>     It may destroy great value if it shakes confidence in the sidechain
>     infrastructure. Thus, the value of the stolen BTC may decrease, in
>     addition to the lost future tx fee revenues of the attacked chain.
> 
>     http://www.truthcoin.info/blog/drivechain/#drivechains-security
>     <http://www.truthcoin.info/blog/drivechain/#drivechains-security>
> 
> 
> That is a fair point.  If sidechains are how Bitcoin is scaled, then
> shaking confidence in a side-chain would shake confidence in Bitcoin's
> future.

Yes. The more value _on_ the sidechain, the more abhorrent the malfeasance.

> 
> I wasn't thinking of a direct miner 51% attack.  It is enough to assume
> that a majority of the miners go with the highest bidder each time.

What do you think of my argument, that we already labor under such an
assumption? An attacker could pay fees today equal to greater than
sum(blockreward_(last N block)). According to you this would force a
reorg, even on mainchain (pre-sidechain) Bitcoin. Yet this has never
happened.

It seems that this argument fully reduces to the "what will happen when
the block subsidy falls to zero" question.

> 
> If (average fees) * (timeout) is less than the total reserves, then it
> is worth it for a 3rd party to just bid for his theft fork.  Miners
> don't have to be assumed to be coordinating, they just have to be
> assumed to take the highest bid.
> 
>     Again, I don't really think it is that different. One could
>     interchange "recent txns" (those which could be double-spent within
>     2-3 weeks) with "sidechain deposit tnxs".
> 
> 
> It is not "recent txns", it is recent txns that you (or your group) have
> the key for.  No coordination is required to steal the entire reserve
> from the sidechain.

See above (?) for why I still feel they are comparable, if not identical.

> 
> Recent txns and money on the sidechain have the property that they are
> riskier than money deep on the main chain.  This is the inherent point
> about sidechains, so maybe not that big a deal. 

Yes. Sidechains have newer, more interesting features, and
simultaneously more risk.


> 
> My concern is that you could have a situation where an attack is
> possible and only need to assume that the miners are indifferent.

Again, I think that we _already_ need to eliminate any assumption of
"charitable miners".

> 
> If the first attacker who tries it fails (say after creating a fork that
> is 90% of the length required, so losing a lot of money), then it would
> discourage others.   If he succeeds, then it weakens sidechains as a
> concept and that creates the incentive for miners to see that he fails.
> 
> I wonder how the incentives work out.  If a group had 25% of the money
> on the sidechain, they could try to outbid the attacker.

Yes, we may see interesting behavior where people buy up these
liabilities using the LN. In my original post, I mention that miners
themselves may purchase these liabilities (at competitive rates, even if
these arent the idealized 1:1). At this point, miners would be paying
themselves and there would be no agency problem.

> 
> In fact, since the attacker, by definition, creates an illegal fork, the
> effect is that he reduces the block rate for the side chain (possibly to
> zero, if he wins every auction).  This means that there are more
> transactions per block, if there is space, or more fees per transaction,
> if the blocks are full. 
> 
> In both cases, this pushes up the total fees per block, so he has to pay
> more per block, weakening his attack.  This is similar to where
> transaction spam on Bitcoin is self-correcting by increasing the fees
> required to keep the spam going.
> 
> Is there a description of the actual implementation you decided to go
> with, other than the code?

If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is
probably the most human-readable description.

Cheers,
Paul

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[ZmnSCPxj]

[-- Attachment #1: Type: text/plain, Size: 8113 bytes --]

Good morning,

>> (What happens if the h* to be put in the coinbase, by chance - even very
>> unlikely chance - is 0? Then <h*> OP_NOP4 is not the same as <h*>
>> OP_BRIBE scripts in result - the former will be rejected by old nodes,
>> the latter will be accepted by new nodes)
>
>That would indeed be a bug, if it happened as you described. I will
>check when I get the chance, thanks.

Indeed, this is the reason why CLTV and CSV do not pop off their parameters when executed, and require a subsequent OP_DROP. I suggest, that OP_BRIBE should not manipulate stack (pop, then push 0/1); my understanding is that this requirement is necessary for compatibility with old nodes, which will not manipulate stack on OP_NOP4. Instead, OP_BRIBE should imitate CLTV and CSV code, and raise an error in script execution if the check fails.

>>
>> How is OP_BRIBE superior to just using a <h*> OP_RETURN script? Cannot
>> a sidechain scan the block for OP_RETURN attesting that the block hash
>> is present in the block?
>
>The sidechain software can indeed, but the mainchain software cannot
>(without making validation of both chains part of the mainchain, which
>defeats the original purpose of sidechains).
>
>The purpose of OP_BRIBE is to allow "Sam" (on the sidechain) and "Mary"
>(a mainchain miner) to work together. Sam would pay X BTC to Mary, if
>Mary could provide Sam with some guarantee that Sam's sidechain block
>[defined by h*] would make it into the largest chain.

Regarding "largest chain", do you mean mainchain or sidechain?

An OP_RETURN is still some guarantee that it will make it into the longest mainchain. If OP_RETURN tx is in a shorter mainchain but not on the longer mainchain, then on the longer mainchain, the utxo's funding the OP_RETURN tx is still unspent and the OP_RETURN tx will still be mineable by any miner following the longer mainchain. The X BTC would be the OP_RETURN transaction's fee, which Mary would still want to mine into the longest mainchain, as it is still money on the table if it is not mined on the longest mainchain.

Or, does OP_BRIBE somehow assure that Sam's block goes onto the longer sidechain? But then, do not side blocks refer to their previous side block to define the sidechain?

>1. main:A sends 100 to side:A, then transfers 100 to side:B in exchange
>for B's good or service (provided on the sidechain)
>2. side:B attempts to move side-to-main with the 100 BTC, using the
>lightning network. He swaps 100 side:BTC for 100 of C's main:BTC.
>3. C attempts to move side-to-main, using the slow, settlement method.
>4. C's side-to-main sidechain tx (wt) is bundled with others and becomes
>a withdrawal attempt (WT^)
>5. The WT^ attempt is initiated on the mainchain.
>6. After a waiting period, the WT^ begins to accumulate ACKs or NACKs
>(upvotes / downvotes), on the mainchain.
>7. The transaction either succeeds or fails.
>
>I'm not sure, but your question seems to concern B, who exploits a reorg
>that happens just after step 2. After the reorg, the sidechain chain
>history will have a different side-to-main withdrawal in part 3. The
>time between each of these step is very long, on the order of weeks
>(summing to a length of time totaling months), for exactly this reason
>(as well as to encourage people to avoid using this 'formal' method, in
>favor of the cooperative LN and Atomic Swaps).
>
>I think that this principle of scale (ie, very VERY slow withdrawals) is
>important and actually makes the security categorically different.

I see.

Is there some predictable schedule for side->main withdrawals? If a withdrawal is imminent, or if some actor can get "insider information" about whether a withdrawal is imminent, cannot some actor induce the above, with potentially shorter time to reach step 3?

From my reading, Blockstream's sidechains proposal supports a reorg proof after a side->main withdrawal on the mainchain side, with a reorg proof burn window after the main:side->main withdrawal, preventing its utxo from being used. If the reorg proof is published and shows that a sidechain reorg invalidates a particular side->main withdrawal, then the main:side->main withdrawal's utxo is burned.

>For extraordinary DAO-like situations, disinterested mainchain miners
>merely need a single bit of information (per sidechain), which is
>"distress=true", and indicates to them to temporarily stop ACKing
>withdrawals from the sidechain. This alone is enough to give the reorg
>an unlimited amount of time to work itself out.

Do you have some document containing these details? I cannot find this in the blog posts I've read so far.

>>>I feel that my proposal is more secure, as it can operate healthily and
>> quickly while using spv proofs which are much slower and much much
>> easier to audit.
>>
>> I don't quite understand how Drivechain handles sidechain reorgs, while
>> keeping Bitcoin miners blinded. It seems sidechains need to be known
>> ("seen") by the miner, so I don't see what is being blinded by blinded
>> merge mining.
>
>Mainchain miners do need to maintain some data about the sidechains, but
>this is very minimal, and certainly does not include the transaction
>data (or arbitrary messages) of the sidechain.

As above, do you have document containing what data mainchain needs to track?

>>>>Blind merged mining seems strictly inferior ... a rich attacker can
>> simply reorg the sidechain outright without playing such games.
>>>
>>>In the future, when there is no block subsidy, a rich attacker can also
>> do that in mainchain Bitcoin.
>>
>> I see. However, block subsidies will drop far in the future, do you
>> mean to say, that sidechains will be used only in the far future?
>
>In one sense, I mean "you have already endorsed this 'fees only will
>work' premise, by endorsing Bitcoin".

I endorse this on the basis of Greg Maxwell's analysis that a block size limit is necessary to have a fee market.

>That mechanism is enforced by drivechain itself, not OP_BRIBE. (OP Bribe
>is itself only ~half of BMM. I admit it is getting a little confusing.)

Can you provide the details of this mechanism? For example, does h* actually include some information identifying the sidechain and OP_BRIBE is supposed to do some additional checking not shown in your current code, or ....?

>Drivechain requires a soft fork to add each new sidechain

Oh.

My understanding is that with Blockstream's zk-SNARKs, a new sidechain would not require a soft fork at all (or even miner voting on the validity of WT^: the validity of side:side->main transactions is assured by proof that the zk-SNARK checking that transaction was executed correctly, and the lack of a reorg proof during the burn window after the main:side->main).

Is your model then, that each sidechain maintainer has to maintain a patchset or some plugin system to Core? And miners who want to support particular sidechains to modify their software, applying the patch for each sidechain they want to support?

It seems this is somewhat brittle and may cause sidechain coding problems to leak into mainchain.

I think, it is much less interesting to have to softfork in every sidechain, rather than to support a general mechanism (zk-SNARK) to allow sidechains to be launched without any modification to Core code.

>. It requires
>this literally for a few good reasons...but the best is: there is an
>implicit requirement that the miners not steal from the sidechain
>anyway. In this way drivechain knows how to keep track of what it should
>expect.

It seems to be, more of "completely sighted merged mining" than "blind merge mining".

>> Perhaps the datacenter point is simply that your proposal suggests to
>> reduce the size of the datacenter by removing surge suppressors and
>> UPS's, to avoid some definition of "datacenter is a room with >$XXX of
>> equipment".
>
>I hope that my replies above already help with these. If not, let me know.

I find this point now moot, as drivechains require a softfork for each sidechain, and the size of the datacenter is pointless if there is some need to softfork in every sidechain.

Regards,
ZmnXCPxj

[-- Attachment #2: Type: text/html, Size: 10691 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]

On Tue, May 23, 2017 at 3:22 PM, Paul Sztorc <truthcoin@gmail.com> wrote:

>
> If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is
> probably the most human-readable description.
>

I guess I was looking for the detail you get in the code, but without
having to read the code.

My quick reading gives that the sidechain codes (critical hashes) are added
when a coinbase is processed.

Any coinbase output that has the form "OP_RETURN <32 byte push>" counts as
a potential critical hash.

When the block is processed, the key value pair (hash, block_height) is
added to a hash map.

The OP_BRIBE opcode checks that the given hash is in the hash map and
replaces the top element on the stack with the pass/fail result.

It doesn't even check that the height matches the current block, though
there is a comment that that is a TODO.

I agree with ZmnSCPxj, when updating a nop, you can't change the stack.  It
has to fail the script or do nothing.

OP_BRIBE_VERIFY would cause the script to fail if the hash wasn't in the
coinbase, or cause a script failure otherwise.

Another concern is that you could have multiple bribes for the same chain
in a single coinbase.  That isn't fair and arguably what the sidechain
miner is paying for is to get his hash exclusively into the block.

I would suggest that the output is

OP_RETURN <sidechain_id> <critical hash>

Then add the rule that only the first hash with a particular sidechain id
actually counts.

This forces the miner to only accept the bribe from 1 miner for each
sidechain for each block.  If he tries to accept 2, then only the first one
counts.

OP_BRIBE_VERIFY could then operate as follows

<block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY

This causes the script to fail if
  <block height> does not match the block height, or
  <critical hash> is not the hash for the sidechain with <sidechain_id>, or
  there is no hash for that sidechain in the block's coinbase

If you want reduce the number of drops, you could serialize the info into a
single push.

This has the advantage that a sidechain miner only has to pay if his block
is accepted in the next bitcoin block.  Since he is the only miner for that
sidechain that gets into the main bitcoin block, he is pretty much
guaranteed to form the longest chain.

Without that rule, sidechain miners could end up having to pay even though
it doesn't make their chain the longest.

How are these transactions propagated over the network?  For relaying, you
could have the rule that the opcode passes as long as <block height> is
near the current block height.  Maybe require that they are in the future.
They should be removed from the memory pool once the block height has
arrived, so losing miners can re-spend those outputs.

This opcode can be validated without needing to look at other blocks, which
is good for validating historical blocks.

I am still looking at the deposit/withdrawal code.

[-- Attachment #2: Type: text/html, Size: 4543 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

On Wed, May 24, 2017 at 9:50 AM, Tier Nolan <tier.nolan@gmail.com> wrote:

> OP_BRIBE_VERIFY could then operate as follows
>
> <block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY
>
> This causes the script to fail if
>   <block height> does not match the block height, or
>   <critical hash> is not the hash for the sidechain with <sidechain_id>, or
>   there is no hash for that sidechain in the block's coinbase
>
>
I was thinking more on the process for these transactions.

I assume that the process is

- sidechain miner broadcasts transaction with OP_BRIBE output
- this transaction ends up in the memory pool of miners
- Miners add the transaction to their next block
- Miners add a transaction which spends the output to one of their own
addresses

I think you need an additional rule that OP_BRIBE checks fails unless the
output is locked 100 or more blocks.

The output script would end up something like

IF
   <block height> <chain_id> <critical hash> OP_BRIBE_VERIFY
ELSE
  <public key> OP_CHECKSIG
ENDIF

This output acts like "anyone can spend" for the one block height.
Otherwise, only the sidechain miner can spend the output.

This allows the sidechain miner to reclaim their coins if the transaction
ends up in a different block.

OP_BRIBE_VERIFY would have an additional rule

The script to fails if
  one or more of the transaction outputs start with something other than
the template
  <block height> does not match the block height, or
  <critical hash> is not the hash for the sidechain with <sidechain_id>, or
  there is no hash for that sidechain in the block's coinbase

The template is
  <100> OP_CHECKSEQUENCE_VERIFY

[-- Attachment #2: Type: text/html, Size: 3092 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[CryptAxe]

[-- Attachment #1: Type: text/plain, Size: 3797 bytes --]

Your assumptions of the bribe process are indeed correct you seem to
have a pretty good handle on all of that.

Hopefully I can clear up a few things. BMM among other things is still a
work in progress so you'll have to wait a
bit longer before any reorg code is on github. The "ratchet" system on
github right now just has the block hash
part of the critical hash script. The completed version needs to check
the sidechain number (ID) and the sidechain
block number in the script. Also the block number can only change by +1
or -1, so when a new h* is added to the
queue it must be compared to the most recent h* in the queue.
std::abs(queue.back().nHeight - ToAdd.nHeight) must equal 1.

Here's what the script looks like on github:
Note that the h* is just a block hash.

script << OP_RETURN << ToByteVector(h*);

Here's what I'm testing right now as I'm working on BMM:

script << OP_RETURN << CScriptNum::serialize(nSidechain) <<
CScriptNum(nSidechainHeight) << ToByteVector(sidechain blinded block
hash h*)

One other thing I want to make sure is clear enough is that the block
number in the critical hash script is
a sidechain block number, not a mainchain block number. That might mess
up the new format you have
suggested for bribes. And the reason a sidechain miner would want to
refund their bribe is if the h* doesn't
end up in a coinbase after a number of blocks, making their blinded
block on the sidechain invalid as tx's
will be spent in other blocks that do get their h* in a coinbase.

We were thinking about making bribe outputs have a maturity period like
generated coins. You
think that they should be locked for >100 blocks by having OP_BRIBE also
check the lock time?

I like all of your suggestions so far, thank you for taking a look!


On 05/24/2017 03:05 AM, Tier Nolan via bitcoin-dev wrote:
> On Wed, May 24, 2017 at 9:50 AM, Tier Nolan <tier.nolan@gmail.com
> <mailto:tier.nolan@gmail.com>> wrote:
>
>     OP_BRIBE_VERIFY could then operate as follows
>
>     <block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY
>
>     This causes the script to fail if
>       <block height> does not match the block height, or
>       <critical hash> is not the hash for the sidechain with
>     <sidechain_id>, or
>       there is no hash for that sidechain in the block's coinbase
>
>
> I was thinking more on the process for these transactions.
>
> I assume that the process is
>
> - sidechain miner broadcasts transaction with OP_BRIBE output
> - this transaction ends up in the memory pool of miners
> - Miners add the transaction to their next block
> - Miners add a transaction which spends the output to one of their own
> addresses
>
> I think you need an additional rule that OP_BRIBE checks fails unless
> the output is locked 100 or more blocks.
>
> The output script would end up something like
>
> IF
>    <block height> <chain_id> <critical hash> OP_BRIBE_VERIFY
> ELSE
>   <public key> OP_CHECKSIG
> ENDIF
>
> This output acts like "anyone can spend" for the one block height. 
> Otherwise, only the sidechain miner can spend the output.
>
> This allows the sidechain miner to reclaim their coins if the
> transaction ends up in a different block.
>
> OP_BRIBE_VERIFY would have an additional rule
>
> The script to fails if
>   one or more of the transaction outputs start with something other
> than the template
>   <block height> does not match the block height, or
>   <critical hash> is not the hash for the sidechain with
> <sidechain_id>, or
>   there is no hash for that sidechain in the block's coinbase
>
> The template is
>   <100> OP_CHECKSEQUENCE_VERIFY
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Type: text/html, Size: 7553 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]

On Wed, May 24, 2017 at 6:32 PM, CryptAxe via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Also the block number can only change by +1 or -1, so when a new h* is
> added to the
> queue it must be compared to the most recent h* in the queue.
> std::abs(queue.back().nHeight - ToAdd.nHeight) must equal 1.
>

I think it is better to have it locked to a particular bitcoin height and
if it doesn't get included in that block, the sidechain miner can re-claim
it.

This could be taken to the extreme where the sidechain miner specifies a
particular parent of the claiming block.

The output should have a standard template, so miners can easily find bids.

The template on my previous post was:

IF
   <block height> <chain_id> <critical hash> OP_BRIBE_VERIFY
ELSE
  <public key> OP_CHECKSIG
ENDIF


If the output is spent by the miner for block <block height>, then the
sidechain miner has spent the funds.

Otherwise, the sidechain miner can use the else branch to reclaim his money.

The sidechain miner could also reclaim his money if the transaction was
included in an earlier block.  That would defeat the purpose of the bribe.
Bitcoin miners would have a (justified) incentive to not allow Bribe
outputs to be spent "early".

The bribe transactions could be created with no fees.  This would mean that
it is pointless for bitcoin miners to include them in blocks unless they
are claiming the outputs.

The relay rules would need to be modified to handle that.  Pools could
allow bids to be made directly, but that is less decentralized.

Here's what I'm testing right now as I'm working on BMM:
>
> script << OP_RETURN << CScriptNum::serialize(nSidechain) <<
> CScriptNum(nSidechainHeight) << ToByteVector(sidechain blinded block hash
> h*)
>

I don't think OP_BRIBE should care about info for the side chain.  The only
thing that is necessary is to indicate which sidechain.

You could just define the critical hash as

Hash( SideChainHeight | blinded h* )

For bribe payout release, it needs to give that particular miner an
advantage over all competitors, so their block forms the longest chain on
the sidechain (assuming their block is actually valid).

> One other thing I want to make sure is clear enough is that the block
> number in the critical hash script is
> a sidechain block number, not a mainchain block number.
>
The sidechain miner is saying that they will pay the bribe but only if
their block is included in the main chain.  The means that main chain
height is important.

They are paying for their block to be placed ahead of all competing blocks
for their chain.

It does mean that the side-chain can have at most the same number of blocks
as bitcoin.

>
> We were thinking about making bribe outputs have a maturity period like
> generated coins. You
> think that they should be locked for >100 blocks by having OP_BRIBE also
> check the lock time?
>

Well, it depends on the exact rules for OP_BRIBE.

The process I see is:

- sidechain miner submits a bribe transaction which pays to op bribe
- bitcoin miner includes that transaction in his block (or it could be
included in a previous block)
- bitcoin miner includes a claim transaction in his block

The claim transaction spends the outputs from the bribe transaction.  If
the claim transaction is block height locked, then it violates the rules
that previous soft-forks have followed.

For previous opcode changes there was a requirement that if a transaction
was accepted into block N, then it must also be acceptable in block (N+1).

The only (unavoidable) exceptions were double spends and coinbases outputs.

This means that the same protection should be added to your claim
transaction.

You could do it by requiring all outputs of the claim transaction to start
with

<100> CHECK_SEQUENCE_VERIFY DROP ...

This is only a few bytes extra at the start of the output script.

This means you can't use witness or P2SH output types for any of the
outputs, but that isn't that important.  The point of the transaction is to
make a payment.

An alternative would be to just add the rule as part of soft-fork
definition.  You could define a claim transaction as one that spends at
least one OP_BRIBE output and therefore, all its outputs have a 100 block
delay.

[-- Attachment #2: Type: text/html, Size: 6133 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3494 bytes --]

On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> Surprisingly, this requirement (or, more precisely, this incentive) does
> not effect miners relative to each other. The incentive to upgrade is only
> for the purpose of preventing a "theft" -- defined as: an improper
> withdrawal from a sidechain. It is not about miner revenues or the ability
> to mine generally (or conduct BMM specifically). The costs of such a theft
> (decrease in market price, decrease in future transaction fee levels) would
> be shared collectively by all future miners. Therefore, it would have no
> effect on miners relative to each other.

That's not at all true. If I'm a miner with a better capability than another
miner to prevent that theft, I have reasons to induce it to happen to give me
political cover to pushing that other miner off the network.

This is a very similar problem to what we had with zeroconf double-spending,
where entities such as Coinbase tried to pay off miners to guarantee something
that wasn't possible in a geninely decrentralized system: safe zeroconf
transactions.

> Moreover, miners have other recourse if they are unable to run the node.
> They can adopt a policy of simply rejecting ("downvoting") any withdrawals
> that they don't understand. This would pause the withdraw process until
> enough miners understand enough of what is going on to proceed with it.

Why are you forcing miners to run this code at all?

Equally, you're opening up miners to huge political risks, as rejecting all
withdrawals is preventing users' from getting their money, which gives other
miners a rational for kicking those miners off of Bitcoin entirely.

> Finally, the point in dispute is a single, infrequent, true/false question.
> So miners may resort to semi-trusted methods to supplement their decision.
> In other words, they can just ask people they trust, if the withdrawal is
> correct or not. It is up to users to decide if they are comfortable with
> these risks, if/when they decide to deposit to a sidechain.

Why do you think this will be infrequent? Miners with a better ability to
validate the drivechain have every reason to make these events more frequent.

> It is a matter of comparing the costs and benefits. Ignoring theft, the
> costs are near-zero, and the benefits are >0. Specifically, they are: a
> higher BTC price and greater transaction fees. Theft is discouraged by
> attempting to tie a theft to a loss of confidence in the miners, as
> described in the spec/website.
> In general the incentives are very similar to those of Bitcoin itself.

This is also a very dubious security model - I would argue that Bitcoin is much
*more* valuable if miners do everything they can to ensure that drivechains
fail, given the huge risks involved. I would also argue that users should do
user-activated-soft-forks to ensure they fail.

By comparison, note Adam Back and my own efforts to ensure miners have a
smaller part in the ecosystem, with things like committed (encrypted)
transactions and my closed-seal-set/truth-list approach(1). We want to involve
miners as little as possible in the consensus, not more.

I have to ask: What use-cases do you actually see for drivechains? Why can't
those use-cases be done in the much safer client-side validation fashion?

1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 3964 bytes --]

Seems to me an obvious use case for drive chains are to have high speed
small transactions on a side chain, eventually cleared to the main chain.

Not sure why miners would want this to fail any more than any other side
chain, like Liquid or lightning.



On May 28, 2017 5:23 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> Surprisingly, this requirement (or, more precisely, this incentive) does
> not effect miners relative to each other. The incentive to upgrade is only
> for the purpose of preventing a "theft" -- defined as: an improper
> withdrawal from a sidechain. It is not about miner revenues or the ability
> to mine generally (or conduct BMM specifically). The costs of such a theft
> (decrease in market price, decrease in future transaction fee levels)
would
> be shared collectively by all future miners. Therefore, it would have no
> effect on miners relative to each other.

That's not at all true. If I'm a miner with a better capability than another
miner to prevent that theft, I have reasons to induce it to happen to give
me
political cover to pushing that other miner off the network.

This is a very similar problem to what we had with zeroconf double-spending,
where entities such as Coinbase tried to pay off miners to guarantee
something
that wasn't possible in a geninely decrentralized system: safe zeroconf
transactions.

> Moreover, miners have other recourse if they are unable to run the node.
> They can adopt a policy of simply rejecting ("downvoting") any withdrawals
> that they don't understand. This would pause the withdraw process until
> enough miners understand enough of what is going on to proceed with it.

Why are you forcing miners to run this code at all?

Equally, you're opening up miners to huge political risks, as rejecting all
withdrawals is preventing users' from getting their money, which gives other
miners a rational for kicking those miners off of Bitcoin entirely.

> Finally, the point in dispute is a single, infrequent, true/false
question.
> So miners may resort to semi-trusted methods to supplement their decision.
> In other words, they can just ask people they trust, if the withdrawal is
> correct or not. It is up to users to decide if they are comfortable with
> these risks, if/when they decide to deposit to a sidechain.

Why do you think this will be infrequent? Miners with a better ability to
validate the drivechain have every reason to make these events more
frequent.

> It is a matter of comparing the costs and benefits. Ignoring theft, the
> costs are near-zero, and the benefits are >0. Specifically, they are: a
> higher BTC price and greater transaction fees. Theft is discouraged by
> attempting to tie a theft to a loss of confidence in the miners, as
> described in the spec/website.
> In general the incentives are very similar to those of Bitcoin itself.

This is also a very dubious security model - I would argue that Bitcoin is
much
*more* valuable if miners do everything they can to ensure that drivechains
fail, given the huge risks involved. I would also argue that users should do
user-activated-soft-forks to ensure they fail.

By comparison, note Adam Back and my own efforts to ensure miners have a
smaller part in the ecosystem, with things like committed (encrypted)
transactions and my closed-seal-set/truth-list approach(1). We want to
involve
miners as little as possible in the consensus, not more.

I have to ask: What use-cases do you actually see for drivechains? Why can't
those use-cases be done in the much safer client-side validation fashion?

1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy

--
https://petertodd.org 'peter'[:-1]@petertodd.org

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 5436 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc]

Hi Peter,

Responses below.

On 5/28/2017 5:07 PM, Peter Todd wrote:
> On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
>> Surprisingly, this requirement (or, more precisely, this incentive) does
>> not effect miners relative to each other. The incentive to upgrade is only
>> for the purpose of preventing a "theft" -- defined as: an improper
>> withdrawal from a sidechain. It is not about miner revenues or the ability
>> to mine generally (or conduct BMM specifically). The costs of such a theft
>> (decrease in market price, decrease in future transaction fee levels) would
>> be shared collectively by all future miners. Therefore, it would have no
>> effect on miners relative to each other.
> 
> That's not at all true. If I'm a miner with a better capability than another
> miner to prevent that theft, I have reasons to induce it to happen to give me
> political cover to pushing that other miner off the network.

Miners can abstain from 'voting', which is politically neutral. Or, if
they wish, smaller miners could acquiesce to the coercion and just copy
the votes of the attacking 51% group. For users who are only running
Bitcoin Core, there is nothing bad about that.

As you say, a 51% group can arbitrarily start orphaning the blocks that
are mined by non-member rivals. This _may_ be a problem, or it may not,
but it is not exacerbated by drivechain.

So, what exactly is "not at all true"?


> 
> This is a very similar problem to what we had with zeroconf double-spending,
> where entities such as Coinbase tried to pay off miners to guarantee something
> that wasn't possible in a geninely decrentralized system: safe zeroconf
> transactions.

I don't see what you mean here. You can't stop Coinbase from donating
BTC to a subset of miners. That will always be possible, and it has
nothing to do with drivechain (as I see it).


> 
>> Moreover, miners have other recourse if they are unable to run the node.
>> They can adopt a policy of simply rejecting ("downvoting") any withdrawals
>> that they don't understand. This would pause the withdraw process until
>> enough miners understand enough of what is going on to proceed with it.
> 
> Why are you forcing miners to run this code at all?

Could we not say the same thing about the code behind CLTV?

The nature of a contract, is that people are happier to be bound by some
rules that they themselves construct (for example, a nuclear
non-proliferation treaty).

In this case, miners prefer sidechains to exist (as existence makes the
BTC they mine more valuable, and provides additional tx fee revenues),
and so they would like to run code which makes them possible.


> 
> Equally, you're opening up miners to huge political risks, as rejecting all
> withdrawals is preventing users' from getting their money, which gives other
> miners a rational for kicking those miners off of Bitcoin entirely.

As I explained above, miners can abstain from voting, which is
politically neutral, or else they can delegate their vote to an
aggressive miner. The "51% can orphan" concern could be raised, even in
a world without drivechain. All that is required, is for the miners to
be anonymous, or in private 'dark' pools (and to thereby escape censure).

But there is a much bigger issue here, which is that our threat models
are different.

As you may know, my threat model [1] does not include miners "pushing
each other off". It only cares about the miner-experience, to the extent
that it impacts the user-experience.

Moreover, I reject [2] the premise that we can even measure "miner
centralization", or even that such a concept exists. If someone has a
definition of this concept, which is both measurable and useful, I would
be interested to read it.

( For what it's worth, Satoshi did not care about this, either. For
example: "If a greedy attacker is able to assemble more CPU power than
all the honest nodes, he...ought to find it more profitable to play by
the rules." which implies robustness to 51% owned by one entity. )

[1] http://www.truthcoin.info/blog/mining-threat-equilibrium/
[2] http://www.truthcoin.info/blog/mirage-miner-centralization/


> 
>> Finally, the point in dispute is a single, infrequent, true/false question.
>> So miners may resort to semi-trusted methods to supplement their decision.
>> In other words, they can just ask people they trust, if the withdrawal is
>> correct or not. It is up to users to decide if they are comfortable with
>> these risks, if/when they decide to deposit to a sidechain.
> 
> Why do you think this will be infrequent? Miners with a better ability to
> validate the drivechain have every reason to make these events more frequent.

It is part of the spec. These timing parameters must be agreed upon when
the sidechain is added, ie _before_ users deposit to the sidechain. Once
the sidechain is created, the timing is enforced by nodes, the same as
with any other protocol rules. Miner-validation-ability has no effect on
the frequency.


> 
>> It is a matter of comparing the costs and benefits. Ignoring theft, the
>> costs are near-zero, and the benefits are >0. Specifically, they are: a
>> higher BTC price and greater transaction fees. Theft is discouraged by
>> attempting to tie a theft to a loss of confidence in the miners, as
>> described in the spec/website.
>> In general the incentives are very similar to those of Bitcoin itself.
> 
> This is also a very dubious security model - I would argue that Bitcoin is much
> *more* valuable if miners do everything they can to ensure that drivechains
> fail, given the huge risks involved.

I don't see how. Users are free to ignore the sidechain, so it can only
benefit them.

Fortunately for you, if that is actually what miners believe, then there
will be no problem, as miners will just filter out drivechains (so that
Bitcoin will be "much *more* valuable"), which they can easily do.


>                                      I would also argue that users should do
> user-activated-soft-forks to ensure they fail.

Again, I don't think that kind of UASF can succeed, because one option
strictly dominates the other. But the users get the final say, of course.

Empirically, I have observed overwhelming support for sidechains among
users, business, and other developers. The btc-investors I spoke to were
all very excited about the prospect of sidechains, even more so than
they were excited about SegWit.


> 
> By comparison, note Adam Back and my own efforts to ensure miners have a
> smaller part in the ecosystem, with things like committed (encrypted)
> transactions and my closed-seal-set/truth-list approach(1). We want to involve
> miners as little as possible in the consensus, not more.

I agree that miners should have as little influence as possible (and
they probably agree, as well). But a 51% group can filter any message
they like from the blockchain. For sidechains, there will need to be two
public networks, so concealment is not an option.

And, I repeat, for regular users of Bitcoin Core, drivechain does not
make a 51% group more dangerous than they already are.

Moreover, there are cases [1] where miner-involvement can make a big
_positive_ impact. Just as it can be beneficial (essential, in fact) for
Bitcoin to filter out harmful interactions among txns (in other words,
good for miners to filter out double spends), I have discovered
situations where it is beneficial and essential for miners to filter out
harmful interactions among multiple chains.

So I think I am actually hitting the "as little as possible" target.

[1] http://www.truthcoin.info/blog/wise-contracts/#wise-contracts


> 
> I have to ask: What use-cases do you actually see for drivechains? Why can't

Here is a tentative project list:
http://www.drivechain.info/projects/index.html

And, as I say on the FAQ, "If each individual user is free to sell
his/her BTC in exchange for an Altcoin (or for fiat), we can hardly deny
users the opportunity to move their money between two sidechains."

So, in a strong way, the entire altcoin market makes the case for a
usefulness of sidechains. Bitcoin is a form of money, and only one form
of money can exist per currency area. So, if Bitcoin is not the winner,
it will eventually cease to exist altogether. Altcoin-competition is an
existential threat to Bitcoin, one which is far more relevant than
anything you've presented so far.

Secondly, one important value of permissionless innovation is that one
doesn't really know, today, what cool ideas other people are going to
come up with tomorrow. If you did, they'd be today's ideas.

Third, Core's review process has two opposite problems: on one hand it
is slow and grueling, and on the other it is fraught with the
possibility of catastrophic error. It would be better, for everyone, to
allow people to try their own (non-aggressive) experiments, and to make
their own mistakes. Already, I have seen the review process abused to
create/maintain fiefdoms of expertise, so that the abusers can extract
money from clients/employers/VCs.

Just think of all of the free time you would have, Peter, if you didn't
have to spend it all reviewing these projects!


> those use-cases be done in the much safer client-side validation fashion?

? How is drivechain _not_ within the category of client-side validation?
With BMM, validation is only performed by those users ("clients") who
opt-in to the new features. The economic model of BMM is directly
comparable to that of Bitcoin's PoW -- the highest-bid chain should be
the healthiest one.

Can you post the Github link for your most up-to-date client-side
validation work so that we can compare the safety and other features?

Thanks,
Paul

> 
> 1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
> 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Sergio Demian Lerner]

[-- Attachment #1: Type: text/plain, Size: 11534 bytes --]

I'm a bit late to this party. I just want to add that there exists an
hybrid model where both a federation and the miners provide acknowledges
(sometimes known as "votes" in drivechain terms and "multi-signatures" in a
federation) of the sidechain state.

My Drivechain proposal (Feb 2016) was tailored to enable this particular
use-case, which I'm not sure Paul's proposal enable.


The proposal is on this list under the following subject: Drivechain
proposal using OP_COUNT_ACKS

BIP (draft):
https://github.com/rootstock/bips/blob/master/BIP-R10.md

Code & Test cases:
https://github.com/rootstock/bitcoin/tree/op-count-acks_devel

In this proposal, the "poll" time is sidechain-configurable, and I proposed
a few days delay was enough.
Some have said that a longer times are needed, such as 2 months.
So if you want to have a 2 month dalay for sidechain->mainchain transfers
in this code, you still can. However a better dynamic cache of acks/nacks
would be needed. However, for the hybrid use-case, one day is more than
enough.

Regards




On Tue, May 30, 2017 at 2:11 AM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Peter,
>
> Responses below.
>
> On 5/28/2017 5:07 PM, Peter Todd wrote:
> > On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> >> Surprisingly, this requirement (or, more precisely, this incentive) does
> >> not effect miners relative to each other. The incentive to upgrade is
> only
> >> for the purpose of preventing a "theft" -- defined as: an improper
> >> withdrawal from a sidechain. It is not about miner revenues or the
> ability
> >> to mine generally (or conduct BMM specifically). The costs of such a
> theft
> >> (decrease in market price, decrease in future transaction fee levels)
> would
> >> be shared collectively by all future miners. Therefore, it would have no
> >> effect on miners relative to each other.
> >
> > That's not at all true. If I'm a miner with a better capability than
> another
> > miner to prevent that theft, I have reasons to induce it to happen to
> give me
> > political cover to pushing that other miner off the network.
>
> Miners can abstain from 'voting', which is politically neutral. Or, if
> they wish, smaller miners could acquiesce to the coercion and just copy
> the votes of the attacking 51% group. For users who are only running
> Bitcoin Core, there is nothing bad about that.
>
> As you say, a 51% group can arbitrarily start orphaning the blocks that
> are mined by non-member rivals. This _may_ be a problem, or it may not,
> but it is not exacerbated by drivechain.
>
> So, what exactly is "not at all true"?
>
>
> >
> > This is a very similar problem to what we had with zeroconf
> double-spending,
> > where entities such as Coinbase tried to pay off miners to guarantee
> something
> > that wasn't possible in a geninely decrentralized system: safe zeroconf
> > transactions.
>
> I don't see what you mean here. You can't stop Coinbase from donating
> BTC to a subset of miners. That will always be possible, and it has
> nothing to do with drivechain (as I see it).
>
>
> >
> >> Moreover, miners have other recourse if they are unable to run the node.
> >> They can adopt a policy of simply rejecting ("downvoting") any
> withdrawals
> >> that they don't understand. This would pause the withdraw process until
> >> enough miners understand enough of what is going on to proceed with it.
> >
> > Why are you forcing miners to run this code at all?
>
> Could we not say the same thing about the code behind CLTV?
>
> The nature of a contract, is that people are happier to be bound by some
> rules that they themselves construct (for example, a nuclear
> non-proliferation treaty).
>
> In this case, miners prefer sidechains to exist (as existence makes the
> BTC they mine more valuable, and provides additional tx fee revenues),
> and so they would like to run code which makes them possible.
>
>
> >
> > Equally, you're opening up miners to huge political risks, as rejecting
> all
> > withdrawals is preventing users' from getting their money, which gives
> other
> > miners a rational for kicking those miners off of Bitcoin entirely.
>
> As I explained above, miners can abstain from voting, which is
> politically neutral, or else they can delegate their vote to an
> aggressive miner. The "51% can orphan" concern could be raised, even in
> a world without drivechain. All that is required, is for the miners to
> be anonymous, or in private 'dark' pools (and to thereby escape censure).
>
> But there is a much bigger issue here, which is that our threat models
> are different.
>
> As you may know, my threat model [1] does not include miners "pushing
> each other off". It only cares about the miner-experience, to the extent
> that it impacts the user-experience.
>
> Moreover, I reject [2] the premise that we can even measure "miner
> centralization", or even that such a concept exists. If someone has a
> definition of this concept, which is both measurable and useful, I would
> be interested to read it.
>
> ( For what it's worth, Satoshi did not care about this, either. For
> example: "If a greedy attacker is able to assemble more CPU power than
> all the honest nodes, he...ought to find it more profitable to play by
> the rules." which implies robustness to 51% owned by one entity. )
>
> [1] http://www.truthcoin.info/blog/mining-threat-equilibrium/
> [2] http://www.truthcoin.info/blog/mirage-miner-centralization/
>
>
> >
> >> Finally, the point in dispute is a single, infrequent, true/false
> question.
> >> So miners may resort to semi-trusted methods to supplement their
> decision.
> >> In other words, they can just ask people they trust, if the withdrawal
> is
> >> correct or not. It is up to users to decide if they are comfortable with
> >> these risks, if/when they decide to deposit to a sidechain.
> >
> > Why do you think this will be infrequent? Miners with a better ability to
> > validate the drivechain have every reason to make these events more
> frequent.
>
> It is part of the spec. These timing parameters must be agreed upon when
> the sidechain is added, ie _before_ users deposit to the sidechain. Once
> the sidechain is created, the timing is enforced by nodes, the same as
> with any other protocol rules. Miner-validation-ability has no effect on
> the frequency.
>
>
> >
> >> It is a matter of comparing the costs and benefits. Ignoring theft, the
> >> costs are near-zero, and the benefits are >0. Specifically, they are: a
> >> higher BTC price and greater transaction fees. Theft is discouraged by
> >> attempting to tie a theft to a loss of confidence in the miners, as
> >> described in the spec/website.
> >> In general the incentives are very similar to those of Bitcoin itself.
> >
> > This is also a very dubious security model - I would argue that Bitcoin
> is much
> > *more* valuable if miners do everything they can to ensure that
> drivechains
> > fail, given the huge risks involved.
>
> I don't see how. Users are free to ignore the sidechain, so it can only
> benefit them.
>
> Fortunately for you, if that is actually what miners believe, then there
> will be no problem, as miners will just filter out drivechains (so that
> Bitcoin will be "much *more* valuable"), which they can easily do.
>
>
> >                                      I would also argue that users
> should do
> > user-activated-soft-forks to ensure they fail.
>
> Again, I don't think that kind of UASF can succeed, because one option
> strictly dominates the other. But the users get the final say, of course.
>
> Empirically, I have observed overwhelming support for sidechains among
> users, business, and other developers. The btc-investors I spoke to were
> all very excited about the prospect of sidechains, even more so than
> they were excited about SegWit.
>
>
> >
> > By comparison, note Adam Back and my own efforts to ensure miners have a
> > smaller part in the ecosystem, with things like committed (encrypted)
> > transactions and my closed-seal-set/truth-list approach(1). We want to
> involve
> > miners as little as possible in the consensus, not more.
>
> I agree that miners should have as little influence as possible (and
> they probably agree, as well). But a 51% group can filter any message
> they like from the blockchain. For sidechains, there will need to be two
> public networks, so concealment is not an option.
>
> And, I repeat, for regular users of Bitcoin Core, drivechain does not
> make a 51% group more dangerous than they already are.
>
> Moreover, there are cases [1] where miner-involvement can make a big
> _positive_ impact. Just as it can be beneficial (essential, in fact) for
> Bitcoin to filter out harmful interactions among txns (in other words,
> good for miners to filter out double spends), I have discovered
> situations where it is beneficial and essential for miners to filter out
> harmful interactions among multiple chains.
>
> So I think I am actually hitting the "as little as possible" target.
>
> [1] http://www.truthcoin.info/blog/wise-contracts/#wise-contracts
>
>
> >
> > I have to ask: What use-cases do you actually see for drivechains? Why
> can't
>
> Here is a tentative project list:
> http://www.drivechain.info/projects/index.html
>
> And, as I say on the FAQ, "If each individual user is free to sell
> his/her BTC in exchange for an Altcoin (or for fiat), we can hardly deny
> users the opportunity to move their money between two sidechains."
>
> So, in a strong way, the entire altcoin market makes the case for a
> usefulness of sidechains. Bitcoin is a form of money, and only one form
> of money can exist per currency area. So, if Bitcoin is not the winner,
> it will eventually cease to exist altogether. Altcoin-competition is an
> existential threat to Bitcoin, one which is far more relevant than
> anything you've presented so far.
>
> Secondly, one important value of permissionless innovation is that one
> doesn't really know, today, what cool ideas other people are going to
> come up with tomorrow. If you did, they'd be today's ideas.
>
> Third, Core's review process has two opposite problems: on one hand it
> is slow and grueling, and on the other it is fraught with the
> possibility of catastrophic error. It would be better, for everyone, to
> allow people to try their own (non-aggressive) experiments, and to make
> their own mistakes. Already, I have seen the review process abused to
> create/maintain fiefdoms of expertise, so that the abusers can extract
> money from clients/employers/VCs.
>
> Just think of all of the free time you would have, Peter, if you didn't
> have to spend it all reviewing these projects!
>
>
> > those use-cases be done in the much safer client-side validation fashion?
>
> ? How is drivechain _not_ within the category of client-side validation?
> With BMM, validation is only performed by those users ("clients") who
> opt-in to the new features. The economic model of BMM is directly
> comparable to that of Bitcoin's PoW -- the highest-bid chain should be
> the healthiest one.
>
> Can you post the Github link for your most up-to-date client-side
> validation work so that we can compare the safety and other features?
>
> Thanks,
> Paul
>
> >
> > 1) https://petertodd.org/2016/closed-seal-sets-and-truth-
> lists-for-privacy
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 14824 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Paul Sztorc]

Hi Sergio / everyone,

As some of you may know, Sergio and I each did an implementation of
drivechain. I started working on mine, and he started working on his,
and then I didn't hear from him for awhile about what he was doing.

Anyways, with two versions, we each have an opportunity to double-check
our work. For example, this already happened wrt the "ACK size". Let me
share from his linked BIP:

    "By allowing miners to refer to transaction candidates by
transaction id prefixes, the space consumption for a single ack can be
as low as 2 bytes."

Sergio shared this with me last October at Scaling Milan. After
listening to him, we saw an opportunity to improve our design: now, our
miners can conjecture that miners will grant ACKs in a few simple ways
[always honest, honest+ignore some, ignore all], and it will precompute
these possibilities (guessing what rival miners will do, even before
they find and broadcast a new block). Therefore, in all honest cases,
our ACK-counting now requires zero (0) bytes to be sent over the
network. In dishonest cases it requires only a few bits per sidechain,
because we also maintain a deterministically ordered list, both of
sidechains and withdrawal attempts -- therefore it can just be a string
of binary information. This is not part of consensus, and so can be
further improved over time.

I'm sure there are still a few opportunities for mutual improvements
going forward.

In general, Sergio and I disagree over the withdrawal-frequency. a major
difference of opinion is over the withdrawal-frequency. I view
infrequent withdrawal as essential to the security model, but Sergio
does not. In both our designs, the withdrawal-time is configurable, but
Sergio's design seems to be optimized for cases with frequent withdrawal
attempts, whereas mine is optimized for cases with very infrequent
withdrawal attempts.

Another difference is that, as a direct result of earlier peer review, I
have been integrating 'blind merged mining' into my version. It may be
easy for Sergio to add BMM to his version, or it may not.

It is true that I am not interested in the hybrid model. I would not
make use of the multisig / centralized part, and so for me it
complicates the security properties for no benefit. I see why some
people are interested in it, though.

Paul



On 6/9/2017 5:54 PM, Sergio Demian Lerner wrote:
> I'm a bit late to this party. I just want to add that there exists an
> hybrid model where both a federation and the miners provide acknowledges
> (sometimes known as "votes" in drivechain terms and "multi-signatures"
> in a federation) of the sidechain state.
> 
> My Drivechain proposal (Feb 2016) was tailored to enable this particular
> use-case, which I'm not sure Paul's proposal enable.
> 
> 
> The proposal is on this list under the following subject: Drivechain
> proposal using OP_COUNT_ACKS
> 
> BIP (draft):
> https://github.com/rootstock/bips/blob/master/BIP-R10.md
> <https://github.com/rootstock/bips/blob/master/BIP-R10.md>
> 
> Code & Test cases:
> https://github.com/rootstock/bitcoin/tree/op-count-acks_devel
> <https://github.com/rootstock/bitcoin/tree/op-count-acks_devel>
> 
> In this proposal, the "poll" time is sidechain-configurable, and I
> proposed a few days delay was enough. 
> Some have said that a longer times are needed, such as 2 months.  
> So if you want to have a 2 month dalay for sidechain->mainchain
> transfers in this code, you still can. However a better dynamic cache of
> acks/nacks would be needed. However, for the hybrid use-case, one day is
> more than enough.
> 
> Regards
> 
> 
> 
> 
> On Tue, May 30, 2017 at 2:11 AM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
>     Hi Peter,
> 
>     Responses below.
> 
>     On 5/28/2017 5:07 PM, Peter Todd wrote:
>     > On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
>     >> Surprisingly, this requirement (or, more precisely, this incentive) does
>     >> not effect miners relative to each other. The incentive to upgrade is only
>     >> for the purpose of preventing a "theft" -- defined as: an improper
>     >> withdrawal from a sidechain. It is not about miner revenues or the ability
>     >> to mine generally (or conduct BMM specifically). The costs of such a theft
>     >> (decrease in market price, decrease in future transaction fee levels) would
>     >> be shared collectively by all future miners. Therefore, it would have no
>     >> effect on miners relative to each other.
>     >
>     > That's not at all true. If I'm a miner with a better capability than another
>     > miner to prevent that theft, I have reasons to induce it to happen to give me
>     > political cover to pushing that other miner off the network.
> 
>     Miners can abstain from 'voting', which is politically neutral. Or, if
>     they wish, smaller miners could acquiesce to the coercion and just copy
>     the votes of the attacking 51% group. For users who are only running
>     Bitcoin Core, there is nothing bad about that.
> 
>     As you say, a 51% group can arbitrarily start orphaning the blocks that
>     are mined by non-member rivals. This _may_ be a problem, or it may not,
>     but it is not exacerbated by drivechain.
> 
>     So, what exactly is "not at all true"?
> 
> 
>     >
>     > This is a very similar problem to what we had with zeroconf double-spending,
>     > where entities such as Coinbase tried to pay off miners to guarantee something
>     > that wasn't possible in a geninely decrentralized system: safe zeroconf
>     > transactions.
> 
>     I don't see what you mean here. You can't stop Coinbase from donating
>     BTC to a subset of miners. That will always be possible, and it has
>     nothing to do with drivechain (as I see it).
> 
> 
>     >
>     >> Moreover, miners have other recourse if they are unable to run the node.
>     >> They can adopt a policy of simply rejecting ("downvoting") any withdrawals
>     >> that they don't understand. This would pause the withdraw process until
>     >> enough miners understand enough of what is going on to proceed with it.
>     >
>     > Why are you forcing miners to run this code at all?
> 
>     Could we not say the same thing about the code behind CLTV?
> 
>     The nature of a contract, is that people are happier to be bound by some
>     rules that they themselves construct (for example, a nuclear
>     non-proliferation treaty).
> 
>     In this case, miners prefer sidechains to exist (as existence makes the
>     BTC they mine more valuable, and provides additional tx fee revenues),
>     and so they would like to run code which makes them possible.
> 
> 
>     >
>     > Equally, you're opening up miners to huge political risks, as rejecting all
>     > withdrawals is preventing users' from getting their money, which gives other
>     > miners a rational for kicking those miners off of Bitcoin entirely.
> 
>     As I explained above, miners can abstain from voting, which is
>     politically neutral, or else they can delegate their vote to an
>     aggressive miner. The "51% can orphan" concern could be raised, even in
>     a world without drivechain. All that is required, is for the miners to
>     be anonymous, or in private 'dark' pools (and to thereby escape
>     censure).
> 
>     But there is a much bigger issue here, which is that our threat models
>     are different.
> 
>     As you may know, my threat model [1] does not include miners "pushing
>     each other off". It only cares about the miner-experience, to the extent
>     that it impacts the user-experience.
> 
>     Moreover, I reject [2] the premise that we can even measure "miner
>     centralization", or even that such a concept exists. If someone has a
>     definition of this concept, which is both measurable and useful, I would
>     be interested to read it.
> 
>     ( For what it's worth, Satoshi did not care about this, either. For
>     example: "If a greedy attacker is able to assemble more CPU power than
>     all the honest nodes, he...ought to find it more profitable to play by
>     the rules." which implies robustness to 51% owned by one entity. )
> 
>     [1] http://www.truthcoin.info/blog/mining-threat-equilibrium/
>     <http://www.truthcoin.info/blog/mining-threat-equilibrium/>
>     [2] http://www.truthcoin.info/blog/mirage-miner-centralization/
>     <http://www.truthcoin.info/blog/mirage-miner-centralization/>
> 
> 
>     >
>     >> Finally, the point in dispute is a single, infrequent, true/false question.
>     >> So miners may resort to semi-trusted methods to supplement their decision.
>     >> In other words, they can just ask people they trust, if the withdrawal is
>     >> correct or not. It is up to users to decide if they are comfortable with
>     >> these risks, if/when they decide to deposit to a sidechain.
>     >
>     > Why do you think this will be infrequent? Miners with a better ability to
>     > validate the drivechain have every reason to make these events more frequent.
> 
>     It is part of the spec. These timing parameters must be agreed upon when
>     the sidechain is added, ie _before_ users deposit to the sidechain. Once
>     the sidechain is created, the timing is enforced by nodes, the same as
>     with any other protocol rules. Miner-validation-ability has no effect on
>     the frequency.
> 
> 
>     >
>     >> It is a matter of comparing the costs and benefits. Ignoring theft, the
>     >> costs are near-zero, and the benefits are >0. Specifically, they are: a
>     >> higher BTC price and greater transaction fees. Theft is discouraged by
>     >> attempting to tie a theft to a loss of confidence in the miners, as
>     >> described in the spec/website.
>     >> In general the incentives are very similar to those of Bitcoin itself.
>     >
>     > This is also a very dubious security model - I would argue that Bitcoin is much
>     > *more* valuable if miners do everything they can to ensure that drivechains
>     > fail, given the huge risks involved.
> 
>     I don't see how. Users are free to ignore the sidechain, so it can only
>     benefit them.
> 
>     Fortunately for you, if that is actually what miners believe, then there
>     will be no problem, as miners will just filter out drivechains (so that
>     Bitcoin will be "much *more* valuable"), which they can easily do.
> 
> 
>     >                                      I would also argue that users should do
>     > user-activated-soft-forks to ensure they fail.
> 
>     Again, I don't think that kind of UASF can succeed, because one option
>     strictly dominates the other. But the users get the final say, of
>     course.
> 
>     Empirically, I have observed overwhelming support for sidechains among
>     users, business, and other developers. The btc-investors I spoke to were
>     all very excited about the prospect of sidechains, even more so than
>     they were excited about SegWit.
> 
> 
>     >
>     > By comparison, note Adam Back and my own efforts to ensure miners have a
>     > smaller part in the ecosystem, with things like committed (encrypted)
>     > transactions and my closed-seal-set/truth-list approach(1). We want to involve
>     > miners as little as possible in the consensus, not more.
> 
>     I agree that miners should have as little influence as possible (and
>     they probably agree, as well). But a 51% group can filter any message
>     they like from the blockchain. For sidechains, there will need to be two
>     public networks, so concealment is not an option.
> 
>     And, I repeat, for regular users of Bitcoin Core, drivechain does not
>     make a 51% group more dangerous than they already are.
> 
>     Moreover, there are cases [1] where miner-involvement can make a big
>     _positive_ impact. Just as it can be beneficial (essential, in fact) for
>     Bitcoin to filter out harmful interactions among txns (in other words,
>     good for miners to filter out double spends), I have discovered
>     situations where it is beneficial and essential for miners to filter out
>     harmful interactions among multiple chains.
> 
>     So I think I am actually hitting the "as little as possible" target.
> 
>     [1] http://www.truthcoin.info/blog/wise-contracts/#wise-contracts
>     <http://www.truthcoin.info/blog/wise-contracts/#wise-contracts>
> 
> 
>     >
>     > I have to ask: What use-cases do you actually see for drivechains? Why can't
> 
>     Here is a tentative project list:
>     http://www.drivechain.info/projects/index.html
>     <http://www.drivechain.info/projects/index.html>
> 
>     And, as I say on the FAQ, "If each individual user is free to sell
>     his/her BTC in exchange for an Altcoin (or for fiat), we can hardly deny
>     users the opportunity to move their money between two sidechains."
> 
>     So, in a strong way, the entire altcoin market makes the case for a
>     usefulness of sidechains. Bitcoin is a form of money, and only one form
>     of money can exist per currency area. So, if Bitcoin is not the winner,
>     it will eventually cease to exist altogether. Altcoin-competition is an
>     existential threat to Bitcoin, one which is far more relevant than
>     anything you've presented so far.
> 
>     Secondly, one important value of permissionless innovation is that one
>     doesn't really know, today, what cool ideas other people are going to
>     come up with tomorrow. If you did, they'd be today's ideas.
> 
>     Third, Core's review process has two opposite problems: on one hand it
>     is slow and grueling, and on the other it is fraught with the
>     possibility of catastrophic error. It would be better, for everyone, to
>     allow people to try their own (non-aggressive) experiments, and to make
>     their own mistakes. Already, I have seen the review process abused to
>     create/maintain fiefdoms of expertise, so that the abusers can extract
>     money from clients/employers/VCs.
> 
>     Just think of all of the free time you would have, Peter, if you didn't
>     have to spend it all reviewing these projects!
> 
> 
>     > those use-cases be done in the much safer client-side validation fashion?
> 
>     ? How is drivechain _not_ within the category of client-side validation?
>     With BMM, validation is only performed by those users ("clients") who
>     opt-in to the new features. The economic model of BMM is directly
>     comparable to that of Bitcoin's PoW -- the highest-bid chain should be
>     the healthiest one.
> 
>     Can you post the Github link for your most up-to-date client-side
>     validation work so that we can compare the safety and other features?
> 
>     Thanks,
>     Paul
> 
>     >
>     > 1)
>     https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
>     <https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy>
>     >
>     _______________________________________________
>     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>
> 
> 

[bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc]

Hi everyone,

It has been 3 weeks -- responses so far have been really helpful. People
jumped right in, and identified unfinished or missing parts much faster
than I thought they would (ie, ~two days). Very impressive.

Currently, we are working on the sidechain side of blind merged mining.
As you know, most of the Bitcoin cryptosystem is about finding the
longest chain, and displaying information about this chain. CryptAxe is
editing the sidechain code to handle reorganizations in a new way (an
even bigger departure than Namecoin's, imho).

I believe that I have responded to all the on-list objections that were
raised. I will 1st summarize the on-list objections, and 2nd summarize
the off-list discussion (focusing on three key themes).


On-List Objection Summary
---------------------------

In general, they were:

* Peter complained about the resources required for the BMM 'crisis
audit', I pointed out that it is actually optional (and, therefore,
free), and that it doesn't affect miners relative to each other, and
that it can be done in an ultra-cheap semi-trusted way with high
reliability.
* Peter also asked about miner incentives, I replied that it is profit
maximizing to BMM sidechains, because the equation (Tx Fees - Zero Cost)
is always positive.
* ZmnSCPxj asked a long series of clarifying questions, and I responded.
* Tier Nolan complained about my equivocation of the "Bitcoin: no block
subsidy" case and the "sidechain" case. He cites the asymmetry I point
out below (in #2). I replied, and I give an answer below.
* ZmnSCPxj pointed out an error in our OP Code (that we will fix).
* ZmnSCPxj also asked a number of new questions, I responded. Then he
responded again, in general he seemed to raise many of the points
addressed in #1 (below).
* ZmnSCPxj wanted reorg proofs, to punish reorgers, but I pointed out
that if 51% can reorg, they can also filter out the reorg proof. We are
at their mercy in all cases (for better or worse).
* ZmnSCPxj also brought up the fact that a block size limit is necessary
for a fee market, I pointed out that this limit does not need to be
imposed on miners by nodes...miners would be willing-and-able to
self-impose such a limit, as it maximizes their revenues.
* ZmnSCPxj also protested the need to soft fork in each individual
sidechain, I pointed out my strong disagreement ("Unrestrained smart
contract execution will be the death of most of the interesting
applications...[could] destabilize Bitcoin itself") and introduced my
prion metaphor.
* ZmnSCPxj and Tier Nolan both identified the problem solved by our
'ratchet' concept. I explained it to ZmnSCPxj in my reply. We had not
coded it at the time, but there is code for it now [1]. Tier proposed a
rachet design, but I think ours is better (Tier did not find ours at
all, because it is buried in obscure notes, because I didn't think
anyone would make it this far so quickly).
* Tier also advised us on how to fix the problem that ZmnSCPxj had
identified with our NOP earlier.
* Tier also had a number of suggestions about the real-time negotiation
of the OP Bribe amount between nodes and miners. I'm afraid I mostly
ignored these for now, as we aren't there yet.
* Peter complained that ACKing the sidechain could be exploited for
political reasons, and I responded that in such a case, miners are free
to simply avoid ACKing, or to acquiesce to political pressure. Neither
affect the mainchain.
* Peter complained that sidechains might provide some miners with the
opportunity to create a pretext to kick other miners off the network. I
replied that it would not, and I also brought up the fact that my
Bitcoin security model was indifferent to which people happened to be
mining at any given time. I continue to believe that "mining
centralization" does not have a useful definition.
* Peter questioned whether or not sidechains would be useful. I stated
my belief that they would be useful, and linked to my site
(drivechain.info/projects) which contains a number of sidechain
use-cases, and cited my personal anecdotal experiences.
* Peter wanted to involve miners "as little as possible", I pointed out
that I felt that I had indeed done this minimization. My view is that
Peter felt erroneously that it was possible to involve miners less,
because he neglected [1] that a 51% miner group is already involved
maximally, as they can create most messages and filter any message, and
[2] that there are cases where we need miners to filter out harmful
interactions among multiple chains (just as they filter out harmful
interactions among multiple txns [ie, "double spends"]). Peter has not
yet responded to this rebuttal.
* Peter also suggested client-side validation as "safer", and I pointed
out that sidechains+BMM _is_ client-side validation. I asked Peter for
CS-V code, so that we can compare the safety and other features.
* Sergio reminded us of his version of drivechain. Sergio and I disagree
over the emphasis on frequency/speed of withdrawals. Also Sergio
emphasizes a hybrid model, which does not interest me.

If I missed any objections, I hope someone will point them out.


Off-List / Three Points of Ongoing Confusion
---------------------------------------------

Off list, I have repeated the a similar conversation perhaps 6-10 times
over the past week. There is a cluster of remaining objections which
centers around three topics -- speed, theft, and antifragility. I will
reply here, and add the answers to my FAQ (drivechain.info/faq).

1. Speed

This objection is voiced after I point out that side-to-main transfers
("withdrawals") will probably take a long time, for example 5 months
each ( these are customizable parameters, and open for debate -- but if
withdrawals are every x=3 months, and only x=1 withdrawal can make
forward progress [on the mainchain] at a time, and only x=1 prospective
withdrawal can be assembled [by the sidechain] at a time, then we can
expect total withdrawal time to average 4.5 months [(.5)*3+3] ). The
response is something like "won't such a system be too slow, and
therefore unusable?".

Imho, replies of this kind disregard the effect of atomic cross-chain
swaps, which are instant.

( In addition, while side-to-main transfers are slow, main-to-side
transfers are quite fast, x~=10 confirmations. I would go as far as to
say that, just as the Lightning Network is enabled by SegWit and CSV,
Drivechain is enabled by the atomic swaps and of Counterparty-like
embedded consensus. )

Thanks to atomic swaps, someone can act as an investment banker or
custodian, and purchase side:BTC at a (tiny, competitive discount) and
then transfer those side-to-main at a minimal inconvenience (comparable
to that of someone who buys a bank CD). Through market activities, the
_entire system_ becomes exactly as patient as its most-patient members.
As icing on the cake, people who aren't planning on using their BTC
anytime soon (ie "the patient") can even get a tiny investment yield, in
return for providing this service.


2. Security

This objection usually says something like "Aren't you worried that 51%
[hashrate] will steal the coins, given that mining is so centralized
these days?"

The logic of drivechain is to take a known fact -- that miners do not
steal from exchanges (by coordinating to doublespend deposits to those
exchanges) -- and generalize it to a new situation -- that [hopefully]
miners will not steal from sidechains (by coordinating to make 'invalid'
withdrawals from them).

My generalization is slightly problematic, because "a large mainchain
reorg today" would hit the entire Bitcoin system and de-confirm *all* of
the network's transactions, whereas a sidechain-theft would hit only a
small portion of the system. This asymmetry is a problem because of the
1:1 peg, which is explicitly symmetrical -- the thief makes off coins
that are worth _just as much_ as those coins that he did _not_ attack.
The side:BTC are therefore relatively more vulnerable to theft, which
harms the generalization.

As I've just explained, to correct this relative deficiency, we add
extra inconvenience for any sidechain thievery, which is in this case
the long long withdrawal time of several months. (Which is also the main
distinction between DC and extension blocks).

I cannot realistically imagine an erroneous withdrawal persisting for
several weeks, let alone several months. First, over a timeframe of this
duration, there can be no pretense of 'we made an innocent mistake', nor
one that 'it is too inconvenient for us to fix this problem'. This
requires the attacker to be part of an explicitly malicious conspiracy.
Even in the conspiring case, I do not understand how miners would
coordinate the distribution of the eventual "theft" payout, ~3 months
from now -- if new hashrate comes online between now and then, does it
get a portion? -- if today's hashrate closes down, does it get a reduced
portion? -- who decides? I don't think that an algorithm can decide
(without creating a new mechanism, which -I believe- would have to be
powered by ongoing sustainable theft [which is impossible]), because the
withdrawal (ie the "theft") has to be initiated, with a known
destination, *before* it accumulates 3 months worth of acknowledgement.

Even if hashrate were controlled exclusively by one person, such a theft
would obliterate the sidechain-tx-fee revenue from all sidechains, for a
start. It would also greatly reduce the market price of [mainchain] BTC,
I feel, as it ends the sidechain experiment more-or-less permanently.

And even _that_ dire situation can be defeated by UASF-style maneuvers,
such as checkpointing. Even the threat of such maneuvers can be
persuasive enough for them never to be needed (especially over long
timeframes, which make these maneuvers convenient).

A slightly more realistic worst-case scenario is that a monopolist
imposes large fees on side-to-main transfers (which he contrives so that
only he can provide). Unless the monopoly is permanent, market forces
(atomic swaps) will still lower the fee to ultra-competitive levels,
making this mostly pointless.


3. Antifragility

There is an absolutely crucial distinction of "layers", which is often
overlooked. Which is a shame, because its importance really cannot be
understated.

Taleb's concept of antifragility is explicitly fractal -- it has layers,
and an upper layer can only be antifragile if it is composed of
individual members of a lower layer who are each *fragile*. In one of my
videos I give the example of NYC food providers -- it is _because_ the
competition is so brutal, and because each individual NYC
restaurant/supermarket/food-truck is so likely to fail, (and because
there is no safety net to catch them if they do fail), that the
consumer's experience is so positive (in NYC, you can find almost any
kind of food, at any hour of the day, at any price, despite the fact
that a staggering ~15 million people will be eating there each day).

By this, I mean there is an absolutely crucial distinction between:

1. A problem with a sidechain that negatively impacts its parent chain.
2. A problem with a sidechain that only impacts the sidechain users.

The first type of problem is unacceptable, but the second type of
problem is actually _desirable_.

If we wanted to have the best BTC currency unit possible, we would want
everyone to try all kinds of things out, _especially_ the things that we
think are terrible. We'd want lots of things to be tried, and for the
losers to "fail fast".

In practice I highly doubt the sidechain ecosystem would be anywhere
near as dynamic as NYC or Silicon Valley. But certain questions, such as
"What if a sidechain breaks / has DAO-like problems?"; "What if the
sidechain has only a few nodes? Who will run them?"; "Who will maintain
these projects?"; -- really just miss the point, I think.

Ultimately, users can vote with their feet -- if the benefits of a
sidechain outweigh its risks, some users will send some BTC there. It is
a strict improvement over the current situation, where users would need
to use an Altcoin to achieve as much. Users who aren't comfortable with
the risks of new chains / new features, can simply decline to use them.


Another Objection
------------------

Finally, two people raised an objection which I will call the "too
popular" objection or "too big to fail (tbtf)". Something like "what if
a *majority* of BTC is moved to one sidechain, and then that sidechain
has some kind of problem?".

One simple step would be to cap the quantity of BTC that can be moved to
each sidechain, (at x=10% ? aka 210,000).

Other than that, I would point out that Bitcoin has always been the
"money of principle", and that we survived the MtGox announcement (in
which ~850,000/12,400,000 = 6.85% of the total BTC were assumed to be
stolen).

I look forward to the continued feedback! Thank you all very much!

Paul

[1]
https://github.com/drivechain-project/bitcoin/commit/c4beef5c2aa8e52d2c1e11de7c044528bbde6c60


On 5/22/2017 2:17 AM, Paul Sztorc wrote:
> Dear list,
> 
> I've been working on "drivechain", a sidechain enabling technology, for
> some time.
> 
> * The technical info site is here: www.drivechain.info
> * The changes to Bitcoin are here:
> https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
> * A Blank sidechain template is here:
> https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
> 
> As many of you know, I've been seeking feedback in person, at various
> conferences and meetups over the past year, most prominently Scaling
> Milan. And I intend to continue to seek feedback at Consensus2017 this
> week, so if you are in NYC please just walk up and start talking to me!
> 
> But I also wanted to ask the list for feedback. Initially, I was
> hesitant because I try not to consume reviewers' scarce time until the
> author has put in a serious effort. However, I may have waiting too
> long, as today it is actually quite close to a working release.
> 
> 
> Scaling Implications
> ---------------------
> 
> This upgrade would have significant scaling implications. Since it is
> the case that sidechains can be added by soft fork, and since each of
> these chains will have its own blockspace, this theoretically removes
> the blocksize limit from "the Bitcoin system" (if one includes
> sidechains as part of such a system). People who want a LargeBlock
> bitcoin can just move their BTC over to such a network [1], and their
> txns will have no longer have an impact on "Bitcoin Core". Thus, even
> though this upgrade does not actually increase "scalability" per se, it
> may in fact put an end to the scalability debate...forever.
> 
> This work includes the relatively new concept of "Blind Merged Mining"
> [2] which I developed in January to allow SHA256^2 miners to merge-mine
> these "drivechains", even if these miners aren't running the actual
> sidechain software. The goal is to prevent sidechains from affecting the
> levelness of the mining "playing field". BMM is conceptually similar to
> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
> required for drivechain, but it would address some of the last remaining
> concerns.
> 
> 
> Total Transaction Fees in the Far Future
> -----------------------------------------
> 
> Some people feel that a maximum blocksize limit is needed to ensure that
> future total equilibrium transaction fees are non-negligible. I
> presented [4] on why I don't agree, 8 months ago. The reviewers I spoke
> to over the last year have stopped bringing this complaint up, but I am
> not sure everyone feels that way.
> 
> 
> Juxtaposition with a recent "Scaling Compromise"
> -------------------------------------------------
> 
> Recently, a scalability proposal began to circulate on social media. As
> far as I could tell, it goes something like "immediately activate
> SegWit, and then HF to double the nonwitness blockspace to 2MB within 12
> months". But such a proposal is quite meager, compared to a "LargeBlock
> Drivechain". The drivechain is better on both fronts, as it would not
> require a hardfork, and could *almost immediately* add _any_ amount of
> extra blockspace (specifically, I might expect a BIP101-like LargeBlock
> chain that has an 8 MB maxblocksize, which doubles every two years).
> 
> In other words, I don't know why anyone would support that proposal over
> mine. The only reasons would be either ignorance (ie, unfamiliarity with
> drivechain) or because there are still nagging unspoken complaints about
> drivechain which I apparently need to hear and address.
> 
> 
> Other Thoughts
> ---------------
> 
> Unfortunately, anyone who worked on the "first generation" of sidechain
> technology (the skiplist) or the "second generation" (federated /
> Liquid), will find that this is very different.
> 
> I will admit that I am very pessimistic about any conversation that
> involves scalability. It is often said that "talking politics lowers
> your IQ by 25 points". Bitcoin scalability conversations seem to drain
> 50 points. (Instead of conversing, I think people should quietly work on
> whatever they are passionate about until their problem either is solved,
> or it goes away for some other reason, or until we all agree to just
> stop talking about it.)
> 
> Cheers,
> Paul
> 
> [1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
> [2] http://www.truthcoin.info/blog/blind-merged-mining/
> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
> [4]
> https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4
> 

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Chris Stewart]

[-- Attachment #1: Type: text/plain, Size: 4981 bytes --]

>OP_RETURN <sidechain_id> <critical hash>

I think it is redundant here to have the <sidechain id>, we can implicitly
assume what the sidechain_id is since we have a fixed set of drivechains.
I.e. mining reward is index 0, mimblewimble sidechain is index 1, etc.
CryptAxe has specific indexes defined already in his implementation:
https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/sidechain.h#L26-L30
.

I think it would be wise to include a version byte to allow us to upgrade
this commitment structure in the future. Similar to how witness program's
are now versioned.

><block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY

If <block height> is an argument that OP_BRIBE_VERIFY takes, doesn't that
mean the mainchain miner has to validate this *is* the actual block height
on the sidechain? Does that take the 'blindness' away from BMM?

Overall, I think we need to work on the commitment structure to the
coinbase tx. If I understand the current implementation correctly we can
have up to 256 OP_RETURNs embedded in the coinbase tx signifying new blocks
mined on drivechains.. this seems less than ideal. It might be prudent to
make these outputs ANYONECANSPEND, and then have miners spending these
outputs to themselves for every block mined.. maybe this doesn't have a
benefit over using OP_RETURNs though?

The structure could be something like:
<version> <critical hash>

and then in a subsequent block the miner spends that output to themselves.
I will admit I'm not super familiar with how OP_RETURNs work with the UTXO
set -- maybe this scheme doesn't have any benefit.

-Chris

On Wed, May 24, 2017 at 3:50 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, May 23, 2017 at 3:22 PM, Paul Sztorc <truthcoin@gmail.com> wrote:
>
>>
>> If you haven't seen http://www.truthcoin.info/blog/drivechain/ , that is
>> probably the most human-readable description.
>>
>
> I guess I was looking for the detail you get in the code, but without
> having to read the code.
>
> My quick reading gives that the sidechain codes (critical hashes) are
> added when a coinbase is processed.
>
> Any coinbase output that has the form "OP_RETURN <32 byte push>" counts as
> a potential critical hash.
>
> When the block is processed, the key value pair (hash, block_height) is
> added to a hash map.
>
> The OP_BRIBE opcode checks that the given hash is in the hash map and
> replaces the top element on the stack with the pass/fail result.
>
> It doesn't even check that the height matches the current block, though
> there is a comment that that is a TODO.
>
> I agree with ZmnSCPxj, when updating a nop, you can't change the stack.
> It has to fail the script or do nothing.
>
> OP_BRIBE_VERIFY would cause the script to fail if the hash wasn't in the
> coinbase, or cause a script failure otherwise.
>
> Another concern is that you could have multiple bribes for the same chain
> in a single coinbase.  That isn't fair and arguably what the sidechain
> miner is paying for is to get his hash exclusively into the block.
>
> I would suggest that the output is
>
> OP_RETURN <sidechain_id> <critical hash>
>
> Then add the rule that only the first hash with a particular sidechain id
> actually counts.
>
> This forces the miner to only accept the bribe from 1 miner for each
> sidechain for each block.  If he tries to accept 2, then only the first one
> counts.
>
> OP_BRIBE_VERIFY could then operate as follows
>
> <block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY
>
> This causes the script to fail if
>   <block height> does not match the block height, or
>   <critical hash> is not the hash for the sidechain with <sidechain_id>, or
>   there is no hash for that sidechain in the block's coinbase
>
> If you want reduce the number of drops, you could serialize the info into
> a single push.
>
> This has the advantage that a sidechain miner only has to pay if his block
> is accepted in the next bitcoin block.  Since he is the only miner for that
> sidechain that gets into the main bitcoin block, he is pretty much
> guaranteed to form the longest chain.
>
> Without that rule, sidechain miners could end up having to pay even though
> it doesn't make their chain the longest.
>
> How are these transactions propagated over the network?  For relaying, you
> could have the rule that the opcode passes as long as <block height> is
> near the current block height.  Maybe require that they are in the future.
> They should be removed from the memory pool once the block height has
> arrived, so losing miners can re-spend those outputs.
>
> This opcode can be validated without needing to look at other blocks,
> which is good for validating historical blocks.
>
> I am still looking at the deposit/withdrawal code.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 7372 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[CryptAxe]

> >OP_RETURN <sidechain_id> <critical hash>
>
> I think it is redundant here to have the <sidechain id>, we can
> implicitly assume what the sidechain_id is since we have a fixed set
> of drivechains. I.e. mining reward is index 0, mimblewimble sidechain
> is index 1, etc. CryptAxe has specific indexes defined already in his
> implementation: 
> https://github.com/drivechain-project/bitcoin/blob/mainchainBMM/src/sidechain.h#L26-L30.
>

Since the sidechain has the sidechain BMM headers that they want the LD
(bribe) data for, I think that they could specifically request LD data
relevant only to that sidechain by providing a list of hashes to the
mainchain, and the mainchain can return a list of boolean values telling
the sidechain if the LD data exists. That way the data never even has to
go over the network, just a verification that it exists on the mainchain
and we can drop the sidechain_id from the script.


> I think it would be wise to include a version byte to allow us to
> upgrade this commitment structure in the future. Similar to how
> witness program's are now versioned.

Agreed, we need that.


>
> ><block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY
>
> If <block height> is an argument that OP_BRIBE_VERIFY takes, doesn't
> that mean the mainchain miner has to validate this *is* the actual
> block height on the sidechain? Does that take the 'blindness' away
> from BMM?

No, OP_BRIBE (the old version) didn't care about the block height. Where
the blockheight was relevant is when bribe data is added to LD. In order
to be added to LD, the bribe needed to either be a fork (block height
less than the sidechain tip height) or extending the current side-chain
(block height = sidechain tip height + 1). The goal of this was to allow
for reorgs, and also make it so that people cannot skip forward (which
would never be valid so it's a waste of time and space) so that the
sidechain makes progress. With the new design that we have been talking
about, I think that we will need to drop this requirement from the
mainchain, and have the sidechain handle filtering out invalid LD data /
only requesting the verification of LD data that they know to be valid
as far as chain order goes.


>
> Overall, I think we need to work on the commitment structure to the
> coinbase tx.

Agreed. It might be helpful if you outlined the idea you had on IRC to
the mailing list.


> If I understand the current implementation correctly we can have up to
> 256 OP_RETURNs embedded in the coinbase tx signifying new blocks mined
> on drivechains.. this seems less than ideal. It might be prudent to
> make these outputs ANYONECANSPEND, and then have miners spending these
> outputs to themselves for every block mined.. maybe this doesn't have
> a benefit over using OP_RETURNs though?
>
> The structure could be something like:
> <version> <critical hash>
>
> and then in a subsequent block the miner spends that output to
> themselves. I will admit I'm not super familiar with how OP_RETURNs
> work with the UTXO set -- maybe this scheme doesn't have any benefit.
>
> -Chris

I might be wrong but I thought that OP_RETURN outputs do not go into the
UTXO set. Anyone else want to chime in?

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Tao Effect]

[-- Attachment #1.1: Type: text/plain, Size: 22361 bytes --]

In Drivechain, 51% of miners have total control and ownership over all of the sidechain coins. The vision of Drivechain is to have many blockchains "plugged in" to the main chain.

Today, well over 51% of miners are under the jurisdiction of a single government.

Thus the effect of Drivechain appears to be the creation of a new kind of digital border imposed onto the network where everyone hands over ownership of their Bitcoins to a /single/ mining cartel when they wish to interact with /any/ sidechain.

Drivechain would be a reasonable idea if that weren't the case, but since it is, Drivechain now introduces a very real possible future where Bitcoins can be confiscated by the Chinese government in exactly the same manner that the Chinese government today confiscates financial assets in other financial networks within China.

One argument is that the psuedo-anonymity granted by Bitcoin addresses could theoretically make this less likely to happen, and while that is true, it is also true that every day Bitcoin becomes less and less psuedo-anonymous as governments invest in blockchain analysis tech [1].

How many high-profile confiscations — now via the Bitcoin-blockchain itself (no longer being able to blame a 3rd-party exchange) — is Bitcoin willing to tolerate and open itself up to?

In a world before Drivechain: the worst that a 51% coalition can do is prevent you from spending your coins (censorship).

In a world with Drivechain three things become true:

1. The Bitcoin network centralizes more, because more power (both financial power and power in terms of capability/control) is granted to miners. This is likely to have secondary consequences on the main-chain network as well (in terms of its price and ability to evolve).

2. A 51% coalition — and/or the government behind it — is now able to financially profit by confiscating coins. No longer is it just censorship, "asset forfeiture" — theft — becomes a real possibility for day-to-day Bitcoin users.

3. Drivechain limits user's existing choice when it comes to who is acting as custodian of their Bitcoins, from any trustworthy exchange, down to a single mining cartel under the control of a single set of laws.

The argument given to this is that a UASF could be initiated to wrest control away from this cartel. I do not believe this addresses the concern at all.

A UASF is a very big deal and extremely difficult to pull off correctly. Even when you have users behind you, it *requires* significant support from the miners themselves [2]. Therefore, I do not believe a UASF is a realistic possibility for recovery.

I would only support Drivechain if all of these issue were addressed.

Kind regards,
Greg Slepak

[1] EU Commits €5 Million to Fund Blockchain Surveillance Research — http://www.coindesk.com/eu-commits-e5-million-fund-blockchain-surveillance-research/ <http://www.coindesk.com/eu-commits-e5-million-fund-blockchain-surveillance-research/>

[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014497.html>

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

> On Jun 10, 2017, at 10:04 AM, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> Hi everyone,
> 
> It has been 3 weeks -- responses so far have been really helpful. People
> jumped right in, and identified unfinished or missing parts much faster
> than I thought they would (ie, ~two days). Very impressive.
> 
> Currently, we are working on the sidechain side of blind merged mining.
> As you know, most of the Bitcoin cryptosystem is about finding the
> longest chain, and displaying information about this chain. CryptAxe is
> editing the sidechain code to handle reorganizations in a new way (an
> even bigger departure than Namecoin's, imho).
> 
> I believe that I have responded to all the on-list objections that were
> raised. I will 1st summarize the on-list objections, and 2nd summarize
> the off-list discussion (focusing on three key themes).
> 
> 
> On-List Objection Summary
> ---------------------------
> 
> In general, they were:
> 
> * Peter complained about the resources required for the BMM 'crisis
> audit', I pointed out that it is actually optional (and, therefore,
> free), and that it doesn't affect miners relative to each other, and
> that it can be done in an ultra-cheap semi-trusted way with high
> reliability.
> * Peter also asked about miner incentives, I replied that it is profit
> maximizing to BMM sidechains, because the equation (Tx Fees - Zero Cost)
> is always positive.
> * ZmnSCPxj asked a long series of clarifying questions, and I responded.
> * Tier Nolan complained about my equivocation of the "Bitcoin: no block
> subsidy" case and the "sidechain" case. He cites the asymmetry I point
> out below (in #2). I replied, and I give an answer below.
> * ZmnSCPxj pointed out an error in our OP Code (that we will fix).
> * ZmnSCPxj also asked a number of new questions, I responded. Then he
> responded again, in general he seemed to raise many of the points
> addressed in #1 (below).
> * ZmnSCPxj wanted reorg proofs, to punish reorgers, but I pointed out
> that if 51% can reorg, they can also filter out the reorg proof. We are
> at their mercy in all cases (for better or worse).
> * ZmnSCPxj also brought up the fact that a block size limit is necessary
> for a fee market, I pointed out that this limit does not need to be
> imposed on miners by nodes...miners would be willing-and-able to
> self-impose such a limit, as it maximizes their revenues.
> * ZmnSCPxj also protested the need to soft fork in each individual
> sidechain, I pointed out my strong disagreement ("Unrestrained smart
> contract execution will be the death of most of the interesting
> applications...[could] destabilize Bitcoin itself") and introduced my
> prion metaphor.
> * ZmnSCPxj and Tier Nolan both identified the problem solved by our
> 'ratchet' concept. I explained it to ZmnSCPxj in my reply. We had not
> coded it at the time, but there is code for it now [1]. Tier proposed a
> rachet design, but I think ours is better (Tier did not find ours at
> all, because it is buried in obscure notes, because I didn't think
> anyone would make it this far so quickly).
> * Tier also advised us on how to fix the problem that ZmnSCPxj had
> identified with our NOP earlier.
> * Tier also had a number of suggestions about the real-time negotiation
> of the OP Bribe amount between nodes and miners. I'm afraid I mostly
> ignored these for now, as we aren't there yet.
> * Peter complained that ACKing the sidechain could be exploited for
> political reasons, and I responded that in such a case, miners are free
> to simply avoid ACKing, or to acquiesce to political pressure. Neither
> affect the mainchain.
> * Peter complained that sidechains might provide some miners with the
> opportunity to create a pretext to kick other miners off the network. I
> replied that it would not, and I also brought up the fact that my
> Bitcoin security model was indifferent to which people happened to be
> mining at any given time. I continue to believe that "mining
> centralization" does not have a useful definition.
> * Peter questioned whether or not sidechains would be useful. I stated
> my belief that they would be useful, and linked to my site
> (drivechain.info/projects <http://drivechain.info/projects>) which contains a number of sidechain
> use-cases, and cited my personal anecdotal experiences.
> * Peter wanted to involve miners "as little as possible", I pointed out
> that I felt that I had indeed done this minimization. My view is that
> Peter felt erroneously that it was possible to involve miners less,
> because he neglected [1] that a 51% miner group is already involved
> maximally, as they can create most messages and filter any message, and
> [2] that there are cases where we need miners to filter out harmful
> interactions among multiple chains (just as they filter out harmful
> interactions among multiple txns [ie, "double spends"]). Peter has not
> yet responded to this rebuttal.
> * Peter also suggested client-side validation as "safer", and I pointed
> out that sidechains+BMM _is_ client-side validation. I asked Peter for
> CS-V code, so that we can compare the safety and other features.
> * Sergio reminded us of his version of drivechain. Sergio and I disagree
> over the emphasis on frequency/speed of withdrawals. Also Sergio
> emphasizes a hybrid model, which does not interest me.
> 
> If I missed any objections, I hope someone will point them out.
> 
> 
> Off-List / Three Points of Ongoing Confusion
> ---------------------------------------------
> 
> Off list, I have repeated the a similar conversation perhaps 6-10 times
> over the past week. There is a cluster of remaining objections which
> centers around three topics -- speed, theft, and antifragility. I will
> reply here, and add the answers to my FAQ (drivechain.info/faq <http://drivechain.info/faq>).
> 
> 1. Speed
> 
> This objection is voiced after I point out that side-to-main transfers
> ("withdrawals") will probably take a long time, for example 5 months
> each ( these are customizable parameters, and open for debate -- but if
> withdrawals are every x=3 months, and only x=1 withdrawal can make
> forward progress [on the mainchain] at a time, and only x=1 prospective
> withdrawal can be assembled [by the sidechain] at a time, then we can
> expect total withdrawal time to average 4.5 months [(.5)*3+3] ). The
> response is something like "won't such a system be too slow, and
> therefore unusable?".
> 
> Imho, replies of this kind disregard the effect of atomic cross-chain
> swaps, which are instant.
> 
> ( In addition, while side-to-main transfers are slow, main-to-side
> transfers are quite fast, x~=10 confirmations. I would go as far as to
> say that, just as the Lightning Network is enabled by SegWit and CSV,
> Drivechain is enabled by the atomic swaps and of Counterparty-like
> embedded consensus. )
> 
> Thanks to atomic swaps, someone can act as an investment banker or
> custodian, and purchase side:BTC at a (tiny, competitive discount) and
> then transfer those side-to-main at a minimal inconvenience (comparable
> to that of someone who buys a bank CD). Through market activities, the
> _entire system_ becomes exactly as patient as its most-patient members.
> As icing on the cake, people who aren't planning on using their BTC
> anytime soon (ie "the patient") can even get a tiny investment yield, in
> return for providing this service.
> 
> 
> 2. Security
> 
> This objection usually says something like "Aren't you worried that 51%
> [hashrate] will steal the coins, given that mining is so centralized
> these days?"
> 
> The logic of drivechain is to take a known fact -- that miners do not
> steal from exchanges (by coordinating to doublespend deposits to those
> exchanges) -- and generalize it to a new situation -- that [hopefully]
> miners will not steal from sidechains (by coordinating to make 'invalid'
> withdrawals from them).
> 
> My generalization is slightly problematic, because "a large mainchain
> reorg today" would hit the entire Bitcoin system and de-confirm *all* of
> the network's transactions, whereas a sidechain-theft would hit only a
> small portion of the system. This asymmetry is a problem because of the
> 1:1 peg, which is explicitly symmetrical -- the thief makes off coins
> that are worth _just as much_ as those coins that he did _not_ attack.
> The side:BTC are therefore relatively more vulnerable to theft, which
> harms the generalization.
> 
> As I've just explained, to correct this relative deficiency, we add
> extra inconvenience for any sidechain thievery, which is in this case
> the long long withdrawal time of several months. (Which is also the main
> distinction between DC and extension blocks).
> 
> I cannot realistically imagine an erroneous withdrawal persisting for
> several weeks, let alone several months. First, over a timeframe of this
> duration, there can be no pretense of 'we made an innocent mistake', nor
> one that 'it is too inconvenient for us to fix this problem'. This
> requires the attacker to be part of an explicitly malicious conspiracy.
> Even in the conspiring case, I do not understand how miners would
> coordinate the distribution of the eventual "theft" payout, ~3 months
> from now -- if new hashrate comes online between now and then, does it
> get a portion? -- if today's hashrate closes down, does it get a reduced
> portion? -- who decides? I don't think that an algorithm can decide
> (without creating a new mechanism, which -I believe- would have to be
> powered by ongoing sustainable theft [which is impossible]), because the
> withdrawal (ie the "theft") has to be initiated, with a known
> destination, *before* it accumulates 3 months worth of acknowledgement.
> 
> Even if hashrate were controlled exclusively by one person, such a theft
> would obliterate the sidechain-tx-fee revenue from all sidechains, for a
> start. It would also greatly reduce the market price of [mainchain] BTC,
> I feel, as it ends the sidechain experiment more-or-less permanently.
> 
> And even _that_ dire situation can be defeated by UASF-style maneuvers,
> such as checkpointing. Even the threat of such maneuvers can be
> persuasive enough for them never to be needed (especially over long
> timeframes, which make these maneuvers convenient).
> 
> A slightly more realistic worst-case scenario is that a monopolist
> imposes large fees on side-to-main transfers (which he contrives so that
> only he can provide). Unless the monopoly is permanent, market forces
> (atomic swaps) will still lower the fee to ultra-competitive levels,
> making this mostly pointless.
> 
> 
> 3. Antifragility
> 
> There is an absolutely crucial distinction of "layers", which is often
> overlooked. Which is a shame, because its importance really cannot be
> understated.
> 
> Taleb's concept of antifragility is explicitly fractal -- it has layers,
> and an upper layer can only be antifragile if it is composed of
> individual members of a lower layer who are each *fragile*. In one of my
> videos I give the example of NYC food providers -- it is _because_ the
> competition is so brutal, and because each individual NYC
> restaurant/supermarket/food-truck is so likely to fail, (and because
> there is no safety net to catch them if they do fail), that the
> consumer's experience is so positive (in NYC, you can find almost any
> kind of food, at any hour of the day, at any price, despite the fact
> that a staggering ~15 million people will be eating there each day).
> 
> By this, I mean there is an absolutely crucial distinction between:
> 
> 1. A problem with a sidechain that negatively impacts its parent chain.
> 2. A problem with a sidechain that only impacts the sidechain users.
> 
> The first type of problem is unacceptable, but the second type of
> problem is actually _desirable_.
> 
> If we wanted to have the best BTC currency unit possible, we would want
> everyone to try all kinds of things out, _especially_ the things that we
> think are terrible. We'd want lots of things to be tried, and for the
> losers to "fail fast".
> 
> In practice I highly doubt the sidechain ecosystem would be anywhere
> near as dynamic as NYC or Silicon Valley. But certain questions, such as
> "What if a sidechain breaks / has DAO-like problems?"; "What if the
> sidechain has only a few nodes? Who will run them?"; "Who will maintain
> these projects?"; -- really just miss the point, I think.
> 
> Ultimately, users can vote with their feet -- if the benefits of a
> sidechain outweigh its risks, some users will send some BTC there. It is
> a strict improvement over the current situation, where users would need
> to use an Altcoin to achieve as much. Users who aren't comfortable with
> the risks of new chains / new features, can simply decline to use them.
> 
> 
> Another Objection
> ------------------
> 
> Finally, two people raised an objection which I will call the "too
> popular" objection or "too big to fail (tbtf)". Something like "what if
> a *majority* of BTC is moved to one sidechain, and then that sidechain
> has some kind of problem?".
> 
> One simple step would be to cap the quantity of BTC that can be moved to
> each sidechain, (at x=10% ? aka 210,000).
> 
> Other than that, I would point out that Bitcoin has always been the
> "money of principle", and that we survived the MtGox announcement (in
> which ~850,000/12,400,000 = 6.85% of the total BTC were assumed to be
> stolen).
> 
> I look forward to the continued feedback! Thank you all very much!
> 
> Paul
> 
> [1]
> https://github.com/drivechain-project/bitcoin/commit/c4beef5c2aa8e52d2c1e11de7c044528bbde6c60 <https://github.com/drivechain-project/bitcoin/commit/c4beef5c2aa8e52d2c1e11de7c044528bbde6c60>
> 
> 
> On 5/22/2017 2:17 AM, Paul Sztorc wrote:
>> Dear list,
>> 
>> I've been working on "drivechain", a sidechain enabling technology, for
>> some time.
>> 
>> * The technical info site is here: www.drivechain.info
>> * The changes to Bitcoin are here:
>> https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
>> * A Blank sidechain template is here:
>> https://github.com/drivechain-project/bitcoin/tree/sidechainBMM
>> 
>> As many of you know, I've been seeking feedback in person, at various
>> conferences and meetups over the past year, most prominently Scaling
>> Milan. And I intend to continue to seek feedback at Consensus2017 this
>> week, so if you are in NYC please just walk up and start talking to me!
>> 
>> But I also wanted to ask the list for feedback. Initially, I was
>> hesitant because I try not to consume reviewers' scarce time until the
>> author has put in a serious effort. However, I may have waiting too
>> long, as today it is actually quite close to a working release.
>> 
>> 
>> Scaling Implications
>> ---------------------
>> 
>> This upgrade would have significant scaling implications. Since it is
>> the case that sidechains can be added by soft fork, and since each of
>> these chains will have its own blockspace, this theoretically removes
>> the blocksize limit from "the Bitcoin system" (if one includes
>> sidechains as part of such a system). People who want a LargeBlock
>> bitcoin can just move their BTC over to such a network [1], and their
>> txns will have no longer have an impact on "Bitcoin Core". Thus, even
>> though this upgrade does not actually increase "scalability" per se, it
>> may in fact put an end to the scalability debate...forever.
>> 
>> This work includes the relatively new concept of "Blind Merged Mining"
>> [2] which I developed in January to allow SHA256^2 miners to merge-mine
>> these "drivechains", even if these miners aren't running the actual
>> sidechain software. The goal is to prevent sidechains from affecting the
>> levelness of the mining "playing field". BMM is conceptually similar to
>> ZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is not
>> required for drivechain, but it would address some of the last remaining
>> concerns.
>> 
>> 
>> Total Transaction Fees in the Far Future
>> -----------------------------------------
>> 
>> Some people feel that a maximum blocksize limit is needed to ensure that
>> future total equilibrium transaction fees are non-negligible. I
>> presented [4] on why I don't agree, 8 months ago. The reviewers I spoke
>> to over the last year have stopped bringing this complaint up, but I am
>> not sure everyone feels that way.
>> 
>> 
>> Juxtaposition with a recent "Scaling Compromise"
>> -------------------------------------------------
>> 
>> Recently, a scalability proposal began to circulate on social media. As
>> far as I could tell, it goes something like "immediately activate
>> SegWit, and then HF to double the nonwitness blockspace to 2MB within 12
>> months". But such a proposal is quite meager, compared to a "LargeBlock
>> Drivechain". The drivechain is better on both fronts, as it would not
>> require a hardfork, and could *almost immediately* add _any_ amount of
>> extra blockspace (specifically, I might expect a BIP101-like LargeBlock
>> chain that has an 8 MB maxblocksize, which doubles every two years).
>> 
>> In other words, I don't know why anyone would support that proposal over
>> mine. The only reasons would be either ignorance (ie, unfamiliarity with
>> drivechain) or because there are still nagging unspoken complaints about
>> drivechain which I apparently need to hear and address.
>> 
>> 
>> Other Thoughts
>> ---------------
>> 
>> Unfortunately, anyone who worked on the "first generation" of sidechain
>> technology (the skiplist) or the "second generation" (federated /
>> Liquid), will find that this is very different.
>> 
>> I will admit that I am very pessimistic about any conversation that
>> involves scalability. It is often said that "talking politics lowers
>> your IQ by 25 points". Bitcoin scalability conversations seem to drain
>> 50 points. (Instead of conversing, I think people should quietly work on
>> whatever they are passionate about until their problem either is solved,
>> or it goes away for some other reason, or until we all agree to just
>> stop talking about it.)
>> 
>> Cheers,
>> Paul
>> 
>> [1] http://www.drivechain.info/faq/#can-sidechains-really-help-with-scaling
>> [2] http://www.truthcoin.info/blog/blind-merged-mining/
>> [3] https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log
>> [4]
>> https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4
>> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #1.2: Type: text/html, Size: 29311 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [bitcoin-dev] Drivechain -- Request for Discussion

[Chris Stewart]

[-- Attachment #1: Type: text/plain, Size: 8787 bytes --]

>
> Since the sidechain has the sidechain BMM headers that they want the LD
> (bribe) data for, I think that they could specifically request LD data
> relevant only to that sidechain by providing a list of hashes to the
> mainchain, and the mainchain can return a list of boolean values telling
> the sidechain if the LD data exists. That way the data never even has to
> go over the network, just a verification that it exists on the mainchain
> and
>

Since you seem to be talking about the initial block download process for
the drivechain. It seems that we might as well request the set of *valid*
blocks from a bitcoin peer first, since at the end of the day they are in
control of the mining process on the sidechain. Here is what I envision:

   1. Request all hashes for sidechain from a bitcoin peer
   2. Request all sidechain block header's for the hashes the bitcoin peer
   gave us
   3. Order the set of sidechain block headers by looking at hashPrevBlock.
   4. Request full sidechain blocks and start validating against the
   consensus rule set of the sidechain


we can drop the sidechain_id from the script.

I agree the 'sidechain_id' is unneeded in the coinbase tx output. We should
just fix these based on index. This should be reflected in my latest commit
if we are talking about the same thing:
https://github.com/Christewart/bitcoin/blob/c355e39fbe2ea48856ea86b25cb8a97710feb032/src/script/script.cpp#L254


and have the sidechain handle filtering out invalid LD data /
> only requesting the verification of LD data that they know to be valid
> as far as chain order goes.
>

 I agree, the whole point of BMM is to have bitcoin miners indifferent to
what happens in the sidechain (although Paul argues in a wonky way they do
care sort of). If there is an invalid (in the sense the block it represents
does *not* follow the sidechain's consensus rule set) OP_BRIBEVERIFY that
pays *more* money than a valid OP_BRIBEVERIFY output, we need to assume
that a 'blind' bitcoin miner will choose the one that pays them the most
money.

>I might be wrong but I thought that OP_RETURN outputs do not go into the
UTXO set. Anyone else want to chime in?

I'm fairly certain you are right. It just feels like we should be able to
exploit the fact that *only* miners can claim these OP_BRIBEVERIFY outputs.
I'll have to think about this more, maybe some one else can come up with
something clever that exploits that fact.

On Mon, Jun 19, 2017 at 10:24 AM, Chris Stewart <stewart.chris1234@gmail.com
> wrote:

> Since the sidechain has the sidechain BMM headers that they want the LD
>> (bribe) data for, I think that they could specifically request LD data
>> relevant only to that sidechain by providing a list of hashes to the
>> mainchain, and the mainchain can return a list of boolean values telling
>> the sidechain if the LD data exists. That way the data never even has to
>> go over the network, just a verification that it exists on the mainchain
>> and
>>
>
> Since you seem to be talking about the initial block download process for
> the drivechain. It seems that we might as well request the set of *valid*
> blocks from a bitcoin peer first, since at the end of the day they are in
> control of the mining process on the sidechain. Here is what I envision:
>
>    1. Request all hashes for sidechain from a bitcoin peer
>    2. Request all sidechain block header's for the hashes the bitcoin
>    peer gave us
>    3. Order the set of sidechain block headers by looking at
>    hashPrevBlock.
>    4. Request full sidechain blocks and start validating against the
>    consensus rule set of the sidechain
>
>
> we can drop the sidechain_id from the script.
>
> I agree the 'sidechain_id' is unneeded in the coinbase tx output. We
> should just fix these based on index. This should be reflected in my latest
> commit if we are talking about the same thing: https://github.com/
> Christewart/bitcoin/blob/c355e39fbe2ea48856ea86b25cb8a9
> 7710feb032/src/script/script.cpp#L254
>
>
> and have the sidechain handle filtering out invalid LD data /
>> only requesting the verification of LD data that they know to be valid
>> as far as chain order goes.
>>
>
>  I agree, the whole point of BMM is to have bitcoin miners indifferent to
> what happens in the sidechain (although Paul argues in a wonky way they do
> care sort of). If there is an invalid (in the sense the block it represents
> does *not* follow the sidechain's consensus rule set) OP_BRIBEVERIFY that
> pays *more* money than a valid OP_BRIBEVERIFY output, we need to assume
> that a 'blind' bitcoin miner will choose the one that pays them the most
> money.
>
> >I might be wrong but I thought that OP_RETURN outputs do not go into the
> UTXO set. Anyone else want to chime in?
>
> I'm fairly certain you are right. It just feels like we should be able to
> exploit the fact that *only* miners can claim these OP_BRIBEVERIFY outputs.
> I'll have to think about this more, maybe some one else can come up with
> something clever that exploits that fact.
>
> On Sun, Jun 18, 2017 at 4:27 PM, CryptAxe via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> > >OP_RETURN <sidechain_id> <critical hash>
>> >
>> > I think it is redundant here to have the <sidechain id>, we can
>> > implicitly assume what the sidechain_id is since we have a fixed set
>> > of drivechains. I.e. mining reward is index 0, mimblewimble sidechain
>> > is index 1, etc. CryptAxe has specific indexes defined already in his
>> > implementation:
>> > https://github.com/drivechain-project/bitcoin/blob/mainchain
>> BMM/src/sidechain.h#L26-L30.
>> >
>>
>> Since the sidechain has the sidechain BMM headers that they want the LD
>> (bribe) data for, I think that they could specifically request LD data
>> relevant only to that sidechain by providing a list of hashes to the
>> mainchain, and the mainchain can return a list of boolean values telling
>> the sidechain if the LD data exists. That way the data never even has to
>> go over the network, just a verification that it exists on the mainchain
>> and we can drop the sidechain_id from the script.
>>
>>
>> > I think it would be wise to include a version byte to allow us to
>> > upgrade this commitment structure in the future. Similar to how
>> > witness program's are now versioned.
>>
>> Agreed, we need that.
>>
>>
>> >
>> > ><block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFY
>> >
>> > If <block height> is an argument that OP_BRIBE_VERIFY takes, doesn't
>> > that mean the mainchain miner has to validate this *is* the actual
>> > block height on the sidechain? Does that take the 'blindness' away
>> > from BMM?
>>
>> No, OP_BRIBE (the old version) didn't care about the block height. Where
>> the blockheight was relevant is when bribe data is added to LD. In order
>> to be added to LD, the bribe needed to either be a fork (block height
>> less than the sidechain tip height) or extending the current side-chain
>> (block height = sidechain tip height + 1). The goal of this was to allow
>> for reorgs, and also make it so that people cannot skip forward (which
>> would never be valid so it's a waste of time and space) so that the
>> sidechain makes progress. With the new design that we have been talking
>> about, I think that we will need to drop this requirement from the
>> mainchain, and have the sidechain handle filtering out invalid LD data /
>> only requesting the verification of LD data that they know to be valid
>> as far as chain order goes.
>>
>>
>> >
>> > Overall, I think we need to work on the commitment structure to the
>> > coinbase tx.
>>
>> Agreed. It might be helpful if you outlined the idea you had on IRC to
>> the mailing list.
>>
>>
>> > If I understand the current implementation correctly we can have up to
>> > 256 OP_RETURNs embedded in the coinbase tx signifying new blocks mined
>> > on drivechains.. this seems less than ideal. It might be prudent to
>> > make these outputs ANYONECANSPEND, and then have miners spending these
>> > outputs to themselves for every block mined.. maybe this doesn't have
>> > a benefit over using OP_RETURNs though?
>> >
>> > The structure could be something like:
>> > <version> <critical hash>
>> >
>> > and then in a subsequent block the miner spends that output to
>> > themselves. I will admit I'm not super familiar with how OP_RETURNs
>> > work with the UTXO set -- maybe this scheme doesn't have any benefit.
>> >
>> > -Chris
>>
>> I might be wrong but I thought that OP_RETURN outputs do not go into the
>> UTXO set. Anyone else want to chime in?
>>
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>

[-- Attachment #2: Type: text/html, Size: 11848 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc]

Hi Greg,

Responses below:

On 6/18/2017 5:30 PM, Tao Effect wrote:
> In Drivechain, 51% of miners have total control and ownership over all
> of the sidechain coins.

It would not be accurate to say that miners have "total" control. Miners
do control the destination of withdrawals, but they do not control the
withdrawal-duration nor the withdrawal-frequency.

So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
theft, but they can not change the fact that their malfeasance will be
[a] obvious, and [b] on display for a long period of time.

We might draw a comparison between:

1. Classic Theft   -- A majority hashrate reorganizes the main Bitcoin
chain to double-spend funds (or coordinate with someone who is
double-spending). This is prevented/discouraged by waiting for many
confirmations.
2. Channel Theft -- A majority hashrate assists a Lightning-Network
thief, by censoring the punitive audit txn (possibly by exploiting some
excuse regarding fullness of blocks, or possibly induced to do so by the
thief provably splitting the proceeds with miners). This is
prevented/discouraged by using lengthy custodial periods, paying high
fees with your attacker's money, and using fungibility/non-communication
to interact with miners as little as possible (so as to frame LN-theft
as undermining the entire LN system, and not merely a single tragedy).
3. Drivechain Theft -- A majority hashrate initiates an unrepresentative
withdrawal from some sidechain. This is prevented/discouraged by only
using 'popular' sidechains (those that [a] increase the usefulness
("market price") of bitcoin, and [b] generate tx fees for miners). It is
also discouraged by the fact that egregious theft would probably end the
sidechain experiment, meaning that all present and future sidechains
would be forever unavailable (and unable to buoy the price or the tx
revenues).

I do not think that any of the three stands out as being categorically
worse than the others, especially when we consider the heterogeneity of
use-cases and preferences. As Luke-Jr has been pointing out on social
media recently, the very group which is more associated with miners (and
explicitly more willing to trust them, ie Bitcoin Unlimited et al),
happens to be the same group that would be expected to make use of a
LargeBlock drivechain. Some can argue that one type of security is more
"cryptographic" than others, but I think this is misguided (how many
'bits' of security does each have?) -- imho, all three security models
are 'game theoretic' (neither computer scientific, nor cryptographic).

More importantly, before a miner has any "control" over the sidechain
coins, users must voluntarily agree to subject themselves to these new
rules. This is similar to how an arbitrary piece of (open source)
software can have "total" control over your computer...if you choose to
install it.

> Thus the effect of Drivechain appears to be the creation of a new kind
> of digital border imposed onto the network ...

I'm not sure it would "create a border", given that sidechains are
currently not accessible at all. If anything drivechain cuts a door into
an existing impassible border.

>  ... where everyone hands over ownership of their Bitcoins to a
> /single/ mining cartel when they wish to interact with /any/ sidechain.

The qualifier "/any/ sidechain" would seem to imply that there is a way
to do sidechains that does not involve handing over some control to 51%
hashrate...I think this is false (even in the fabled case of ZK-SNARKS).
The first thing I do in the drivechain spec (
truthcoin.info/blog/drivechain ) is explain why.

> Drivechain would be a reasonable idea if that weren't the case, but
> since it is, Drivechain now introduces a very real possible future
> where Bitcoins can be confiscated by the Chinese government in exactly
> the same manner that the Chinese government today confiscates
> financial assets in other financial networks within China.

Yes, but money could also be confiscated from _any_ Bitcoin users
(Chinese or otherwise) using any of the three methods I mentioned above.
And confiscation could strike Chinese Bitcoin users if they decided to
sell their Bitcoin for Chinese Yuan, which they then deposited in a
Chinese bank. Or if they sold their Bitcoin for an Altcoin controlled by
the Chinese govt in some other way.

It is not up to the members of this list to decide, USSR style, what
other people are allowed to do with their own money.

The exceptions to this rule would be (ie, "bitcoin-dev should care about
what users are doing when..."):

1. [Unreasonable use of Reviewer Time]  The user's use-case is either
nonexistent (ie "no one wants that"), or totally unachievable ("we can't
do that") thus rendering the conversation a complete waste of time /
reviewer attention.
2. [Harmful Interference] The user's use-case would impose harm on some
existing use-case(s).

No reasonable person will claim the first, given today's scaling debate
(not to mention today's 'bitcoin dominance index'). Therefore, critics
must claim the second (as, for example, Peter Todd has been doing on
this list).

Which is why I narrowly focus on inter-chain harms [1], leading
ultimately to a focus on the mining ecosystem [2,3] and the development
of Blind Merged Mining [4].

[1]
https://www.youtube.com/watch?v=0goYH2sDw0w&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=1
[2] http://www.truthcoin.info/blog/mirage-miner-centralization/
[3] http://www.truthcoin.info/blog/mining-threat-equilibrium/
[4] http://www.truthcoin.info/blog/blind-merged-mining/
[5] http://www.truthcoin.info/blog/measuring-decentralization/

> 1. The Bitcoin network centralizes more, because more power (both
> financial power and power in terms of capability/control) is granted
> to miners.

I think that one has some duty to very clearly define something (like
"mining centralization" [2] or "centralization" [5]) before complaining
about it. I feel that people will occasionally use selfless complaints
to accomplish a selfish goal...especially when the artificial selfless
part is hard to discuss by virtue of its being poorly defined
(especially vague or abstract items like "the company", "our country",
etc). For example, those who take it upon themselves to "defend" "the
Bitcoin community" may have exactly that in mind as their primary
goal...but they may also end up with more visibility (and with it: more
influence, more job offers, more conference invites, more friends, etc)
and they may also end up with a megaphone for which to broadcast their
other views, or just a defend-able excuse for bragging loudly about how
great cypherpunks are and/or how devoted they-in-particular are to the
cypherpunk tribe, et cetera. To avoid this problem in my own technical
discourse, I try to avoid abstractions like "centralization" until I
have defined them [2,5].

You have defined centralization above, but the definition is itself
vague to the point where I do not think even you actually endorse it.
For example, you would need to say that Bitcoin centralizes whenever the
exchange rate increases (as this grants additional financial power to
miners) or when any new user joins Bitcoin, or when tx fee revenues
increase for any reason. You might also be forced to say that LN
centralizes Bitcoin (as LN grants new capability/control to miners), and
probably even that Bitcoin becomes more centralized when developers
release new software (as this grants new capability to miners,
specifically the ability to deny upgrades). This probably isn't what you
meant, but since you did not clearly explain what you meant we have no
way of knowing for sure.

It seems to me that you reject the premise that BMM [4] addresses these
issues. This is probably because BMM only addresses miner's interactions
with each other, and it does not address miner abilities as a group in
relation to other groups (for example, vs. users, developers,
investors). But, as I consistently emphasize, these groups of people are
free to ignore any sidechains that they do not like. In law there is a
saying 'volenti non fit injuria' which I would translate as "he who
volunteers cannot claim later to have been injured". This is a legal
theory, because otherwise everyone would be arbitrarily liable for
choices beyond their control (ie, responsible for decisions of other
unrelated people), which would be nonsense.

> 3. Drivechain limits user's existing choice when it comes to who is
> acting as custodian of their Bitcoins, from any trustworthy exchange,
> down to a single mining cartel under the control of a single set of laws.

Currently no (P2P) sidechains exist, and therefore the set of choices
today would seem to be more "limited" than in a post-sidechain future.
(The set of options may decrease later, for ecological reasons, if and
only if 'exchanges' are a strictly inferior option to 'sidechains' for
some reason...I don't see why this would be the case. I also don't
understand the emphasis on "exchanges" [SCs are much more like Altcoins,
than exchanges] in the first place, nor the dubious qualifier
"trustworthy".)

--Paul

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 12948 bytes --]

Hi Erik,

As you know:

1. If a sidechain is merged mined it basically grows out of the existing
Bitcoin mining network. If it has a different PoW algorithm it is a new
mining network.
2. The security (ie, hashrate) of any mining network would be determined
by the total economic value of the block. In Bitcoin this is
(subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens
it would only be (tx_fees)*price.

Unfortunately the two have a nasty correlation which can lead to a
disastrous self-fulfilling prophecy: users will avoid a network that is
too insecure; and if users avoid using a network, they will stop paying
txn fees and so the quantity (tx_fees)*price falls toward zero, erasing
the network's security. So it is quite problematic and I recommend just
biting the bullet and going with merged mining instead.

And, the point may be moot. Bitcoin miners may decide that, given their
expertise in seeking out cheap sources of power/cooling, they might as
well mine both/all chains. So your suggestion may not achieve your
desired result (and would, meanwhile, consume more of the economy's
resources -- some of these would not contribute even to a higher hashrate).

Paul



On 6/19/2017 1:11 PM, Erik Aronesty wrote:
> It would be nice to be able to enforce that a drivechain *not* have
> the same POW as bitcoin.
>
> I suspect this is the only way to be sure that a drivechain doesn't
> destabilize the main chain and push more power to miners that already
> have too much power.
>
>
> On Mon, Jun 19, 2017 at 12:04 PM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     Hi Greg,
>
>     Responses below:
>
>     On 6/18/2017 5:30 PM, Tao Effect wrote:
>     > In Drivechain, 51% of miners have total control and ownership
>     over all
>     > of the sidechain coins.
>
>     It would not be accurate to say that miners have "total" control.
>     Miners
>     do control the destination of withdrawals, but they do not control the
>     withdrawal-duration nor the withdrawal-frequency.
>
>     So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
>     theft, but they can not change the fact that their malfeasance will be
>     [a] obvious, and [b] on display for a long period of time.
>
>     We might draw a comparison between:
>
>     1. Classic Theft   -- A majority hashrate reorganizes the main Bitcoin
>     chain to double-spend funds (or coordinate with someone who is
>     double-spending). This is prevented/discouraged by waiting for many
>     confirmations.
>     2. Channel Theft -- A majority hashrate assists a Lightning-Network
>     thief, by censoring the punitive audit txn (possibly by exploiting
>     some
>     excuse regarding fullness of blocks, or possibly induced to do so
>     by the
>     thief provably splitting the proceeds with miners). This is
>     prevented/discouraged by using lengthy custodial periods, paying high
>     fees with your attacker's money, and using
>     fungibility/non-communication
>     to interact with miners as little as possible (so as to frame LN-theft
>     as undermining the entire LN system, and not merely a single tragedy).
>     3. Drivechain Theft -- A majority hashrate initiates an
>     unrepresentative
>     withdrawal from some sidechain. This is prevented/discouraged by only
>     using 'popular' sidechains (those that [a] increase the usefulness
>     ("market price") of bitcoin, and [b] generate tx fees for miners).
>     It is
>     also discouraged by the fact that egregious theft would probably
>     end the
>     sidechain experiment, meaning that all present and future sidechains
>     would be forever unavailable (and unable to buoy the price or the tx
>     revenues).
>
>     I do not think that any of the three stands out as being categorically
>     worse than the others, especially when we consider the
>     heterogeneity of
>     use-cases and preferences. As Luke-Jr has been pointing out on social
>     media recently, the very group which is more associated with
>     miners (and
>     explicitly more willing to trust them, ie Bitcoin Unlimited et al),
>     happens to be the same group that would be expected to make use of a
>     LargeBlock drivechain. Some can argue that one type of security is
>     more
>     "cryptographic" than others, but I think this is misguided (how many
>     'bits' of security does each have?) -- imho, all three security models
>     are 'game theoretic' (neither computer scientific, nor cryptographic).
>
>     More importantly, before a miner has any "control" over the sidechain
>     coins, users must voluntarily agree to subject themselves to these new
>     rules. This is similar to how an arbitrary piece of (open source)
>     software can have "total" control over your computer...if you
>     choose to
>     install it.
>
>     > Thus the effect of Drivechain appears to be the creation of a
>     new kind
>     > of digital border imposed onto the network ...
>
>     I'm not sure it would "create a border", given that sidechains are
>     currently not accessible at all. If anything drivechain cuts a
>     door into
>     an existing impassible border.
>
>     >  ... where everyone hands over ownership of their Bitcoins to a
>     > /single/ mining cartel when they wish to interact with /any/ sidechain.
>
>     The qualifier "/any/ sidechain" would seem to imply that there is
>     a way
>     to do sidechains that does not involve handing over some control
>     to 51%
>     hashrate...I think this is false (even in the fabled case of
>     ZK-SNARKS).
>     The first thing I do in the drivechain spec (
>     truthcoin.info/blog/drivechain
>     <http://truthcoin.info/blog/drivechain> ) is explain why.
>
>     > Drivechain would be a reasonable idea if that weren't the case, but
>     > since it is, Drivechain now introduces a very real possible future
>     > where Bitcoins can be confiscated by the Chinese government in
>     exactly
>     > the same manner that the Chinese government today confiscates
>     > financial assets in other financial networks within China.
>
>     Yes, but money could also be confiscated from _any_ Bitcoin users
>     (Chinese or otherwise) using any of the three methods I mentioned
>     above.
>     And confiscation could strike Chinese Bitcoin users if they decided to
>     sell their Bitcoin for Chinese Yuan, which they then deposited in a
>     Chinese bank. Or if they sold their Bitcoin for an Altcoin
>     controlled by
>     the Chinese govt in some other way.
>
>     It is not up to the members of this list to decide, USSR style, what
>     other people are allowed to do with their own money.
>
>     The exceptions to this rule would be (ie, "bitcoin-dev should care
>     about
>     what users are doing when..."):
>
>     1. [Unreasonable use of Reviewer Time]  The user's use-case is either
>     nonexistent (ie "no one wants that"), or totally unachievable ("we
>     can't
>     do that") thus rendering the conversation a complete waste of time /
>     reviewer attention.
>     2. [Harmful Interference] The user's use-case would impose harm on
>     some
>     existing use-case(s).
>
>     No reasonable person will claim the first, given today's scaling
>     debate
>     (not to mention today's 'bitcoin dominance index'). Therefore, critics
>     must claim the second (as, for example, Peter Todd has been doing on
>     this list).
>
>     Which is why I narrowly focus on inter-chain harms [1], leading
>     ultimately to a focus on the mining ecosystem [2,3] and the
>     development
>     of Blind Merged Mining [4].
>
>     [1]
>     https://www.youtube.com/watch?v=0goYH2sDw0w&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=1
>     <https://www.youtube.com/watch?v=0goYH2sDw0w&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=1>
>     [2] http://www.truthcoin.info/blog/mirage-miner-centralization/
>     <http://www.truthcoin.info/blog/mirage-miner-centralization/>
>     [3] http://www.truthcoin.info/blog/mining-threat-equilibrium/
>     <http://www.truthcoin.info/blog/mining-threat-equilibrium/>
>     [4] http://www.truthcoin.info/blog/blind-merged-mining/
>     <http://www.truthcoin.info/blog/blind-merged-mining/>
>     [5] http://www.truthcoin.info/blog/measuring-decentralization/
>     <http://www.truthcoin.info/blog/measuring-decentralization/>
>
>     > 1. The Bitcoin network centralizes more, because more power (both
>     > financial power and power in terms of capability/control) is granted
>     > to miners.
>
>     I think that one has some duty to very clearly define something (like
>     "mining centralization" [2] or "centralization" [5]) before
>     complaining
>     about it. I feel that people will occasionally use selfless complaints
>     to accomplish a selfish goal...especially when the artificial selfless
>     part is hard to discuss by virtue of its being poorly defined
>     (especially vague or abstract items like "the company", "our country",
>     etc). For example, those who take it upon themselves to "defend" "the
>     Bitcoin community" may have exactly that in mind as their primary
>     goal...but they may also end up with more visibility (and with it:
>     more
>     influence, more job offers, more conference invites, more friends,
>     etc)
>     and they may also end up with a megaphone for which to broadcast their
>     other views, or just a defend-able excuse for bragging loudly
>     about how
>     great cypherpunks are and/or how devoted they-in-particular are to the
>     cypherpunk tribe, et cetera. To avoid this problem in my own technical
>     discourse, I try to avoid abstractions like "centralization" until I
>     have defined them [2,5].
>
>     You have defined centralization above, but the definition is itself
>     vague to the point where I do not think even you actually endorse it.
>     For example, you would need to say that Bitcoin centralizes
>     whenever the
>     exchange rate increases (as this grants additional financial power to
>     miners) or when any new user joins Bitcoin, or when tx fee revenues
>     increase for any reason. You might also be forced to say that LN
>     centralizes Bitcoin (as LN grants new capability/control to
>     miners), and
>     probably even that Bitcoin becomes more centralized when developers
>     release new software (as this grants new capability to miners,
>     specifically the ability to deny upgrades). This probably isn't
>     what you
>     meant, but since you did not clearly explain what you meant we have no
>     way of knowing for sure.
>
>     It seems to me that you reject the premise that BMM [4] addresses
>     these
>     issues. This is probably because BMM only addresses miner's
>     interactions
>     with each other, and it does not address miner abilities as a group in
>     relation to other groups (for example, vs. users, developers,
>     investors). But, as I consistently emphasize, these groups of
>     people are
>     free to ignore any sidechains that they do not like. In law there is a
>     saying 'volenti non fit injuria' which I would translate as "he who
>     volunteers cannot claim later to have been injured". This is a legal
>     theory, because otherwise everyone would be arbitrarily liable for
>     choices beyond their control (ie, responsible for decisions of other
>     unrelated people), which would be nonsense.
>
>     > 3. Drivechain limits user's existing choice when it comes to who is
>     > acting as custodian of their Bitcoins, from any trustworthy
>     exchange,
>     > down to a single mining cartel under the control of a single set
>     of laws.
>
>     Currently no (P2P) sidechains exist, and therefore the set of choices
>     today would seem to be more "limited" than in a post-sidechain future.
>     (The set of options may decrease later, for ecological reasons, if and
>     only if 'exchanges' are a strictly inferior option to 'sidechains' for
>     some reason...I don't see why this would be the case. I also don't
>     understand the emphasis on "exchanges" [SCs are much more like
>     Altcoins,
>     than exchanges] in the first place, nor the dubious qualifier
>     "trustworthy".)
>
>     --Paul
>
>     _______________________________________________
>     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: 18050 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 12510 bytes --]

- a proof-of-burn sidechain is the ultimate two-way peg.   you have to burn
bitcoin *or* side-chain tokens to mine the side chain.   the size of the
burn is the degree of security.    i actually wrote code to do randomized
blind burns where you have a poisson distribution (non-deterministic
selected burn).    there is no way to game it... it's very similar to
algorand - but it uses burns instead of staking

- you can then have a secure sidechain that issues a mining reward in
sidechain tokens, which can be aggrregated and redeemed for bitcoins.   the
result of this is that any bitcoins held in the sidechain depreciate in
value at a rate of X% per year.   this deflation rate pays for increased
security

- logically this functions like an alt coin, with high inflation and cheap
transactions.   but the altcoin is pegged to bitcoin's price because of the
pool of unredeemed bitcoins held within the side chain.



On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc <truthcoin@gmail.com> wrote:

> Hi Erik,
>
> As you know:
>
> 1. If a sidechain is merged mined it basically grows out of the existing
> Bitcoin mining network. If it has a different PoW algorithm it is a new
> mining network.
> 2. The security (ie, hashrate) of any mining network would be determined
> by the total economic value of the block. In Bitcoin this is
> (subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens it
> would only be (tx_fees)*price.
>
> Unfortunately the two have a nasty correlation which can lead to a
> disastrous self-fulfilling prophecy: users will avoid a network that is too
> insecure; and if users avoid using a network, they will stop paying txn
> fees and so the quantity (tx_fees)*price falls toward zero, erasing the
> network's security. So it is quite problematic and I recommend just biting
> the bullet and going with merged mining instead.
>
> And, the point may be moot. Bitcoin miners may decide that, given their
> expertise in seeking out cheap sources of power/cooling, they might as well
> mine both/all chains. So your suggestion may not achieve your desired
> result (and would, meanwhile, consume more of the economy's resources --
> some of these would not contribute even to a higher hashrate).
>
> Paul
>
>
>
>
> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>
> It would be nice to be able to enforce that a drivechain *not* have the
> same POW as bitcoin.
>
> I suspect this is the only way to be sure that a drivechain doesn't
> destabilize the main chain and push more power to miners that already have
> too much power.
>
>
> On Mon, Jun 19, 2017 at 12:04 PM, Paul Sztorc via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi Greg,
>>
>> Responses below:
>>
>> On 6/18/2017 5:30 PM, Tao Effect wrote:
>> > In Drivechain, 51% of miners have total control and ownership over all
>> > of the sidechain coins.
>>
>> It would not be accurate to say that miners have "total" control. Miners
>> do control the destination of withdrawals, but they do not control the
>> withdrawal-duration nor the withdrawal-frequency.
>>
>> So, if miners wish to 'steal' from a sidechain, they _can_ initiate a
>> theft, but they can not change the fact that their malfeasance will be
>> [a] obvious, and [b] on display for a long period of time.
>>
>> We might draw a comparison between:
>>
>> 1. Classic Theft   -- A majority hashrate reorganizes the main Bitcoin
>> chain to double-spend funds (or coordinate with someone who is
>> double-spending). This is prevented/discouraged by waiting for many
>> confirmations.
>> 2. Channel Theft -- A majority hashrate assists a Lightning-Network
>> thief, by censoring the punitive audit txn (possibly by exploiting some
>> excuse regarding fullness of blocks, or possibly induced to do so by the
>> thief provably splitting the proceeds with miners). This is
>> prevented/discouraged by using lengthy custodial periods, paying high
>> fees with your attacker's money, and using fungibility/non-communication
>> to interact with miners as little as possible (so as to frame LN-theft
>> as undermining the entire LN system, and not merely a single tragedy).
>> 3. Drivechain Theft -- A majority hashrate initiates an unrepresentative
>> withdrawal from some sidechain. This is prevented/discouraged by only
>> using 'popular' sidechains (those that [a] increase the usefulness
>> ("market price") of bitcoin, and [b] generate tx fees for miners). It is
>> also discouraged by the fact that egregious theft would probably end the
>> sidechain experiment, meaning that all present and future sidechains
>> would be forever unavailable (and unable to buoy the price or the tx
>> revenues).
>>
>> I do not think that any of the three stands out as being categorically
>> worse than the others, especially when we consider the heterogeneity of
>> use-cases and preferences. As Luke-Jr has been pointing out on social
>> media recently, the very group which is more associated with miners (and
>> explicitly more willing to trust them, ie Bitcoin Unlimited et al),
>> happens to be the same group that would be expected to make use of a
>> LargeBlock drivechain. Some can argue that one type of security is more
>> "cryptographic" than others, but I think this is misguided (how many
>> 'bits' of security does each have?) -- imho, all three security models
>> are 'game theoretic' (neither computer scientific, nor cryptographic).
>>
>> More importantly, before a miner has any "control" over the sidechain
>> coins, users must voluntarily agree to subject themselves to these new
>> rules. This is similar to how an arbitrary piece of (open source)
>> software can have "total" control over your computer...if you choose to
>> install it.
>>
>> > Thus the effect of Drivechain appears to be the creation of a new kind
>> > of digital border imposed onto the network ...
>>
>> I'm not sure it would "create a border", given that sidechains are
>> currently not accessible at all. If anything drivechain cuts a door into
>> an existing impassible border.
>>
>> >  ... where everyone hands over ownership of their Bitcoins to a
>> > /single/ mining cartel when they wish to interact with /any/ sidechain.
>>
>> The qualifier "/any/ sidechain" would seem to imply that there is a way
>> to do sidechains that does not involve handing over some control to 51%
>> hashrate...I think this is false (even in the fabled case of ZK-SNARKS).
>> The first thing I do in the drivechain spec (
>> truthcoin.info/blog/drivechain ) is explain why.
>>
>> > Drivechain would be a reasonable idea if that weren't the case, but
>> > since it is, Drivechain now introduces a very real possible future
>> > where Bitcoins can be confiscated by the Chinese government in exactly
>> > the same manner that the Chinese government today confiscates
>> > financial assets in other financial networks within China.
>>
>> Yes, but money could also be confiscated from _any_ Bitcoin users
>> (Chinese or otherwise) using any of the three methods I mentioned above.
>> And confiscation could strike Chinese Bitcoin users if they decided to
>> sell their Bitcoin for Chinese Yuan, which they then deposited in a
>> Chinese bank. Or if they sold their Bitcoin for an Altcoin controlled by
>> the Chinese govt in some other way.
>>
>> It is not up to the members of this list to decide, USSR style, what
>> other people are allowed to do with their own money.
>>
>> The exceptions to this rule would be (ie, "bitcoin-dev should care about
>> what users are doing when..."):
>>
>> 1. [Unreasonable use of Reviewer Time]  The user's use-case is either
>> nonexistent (ie "no one wants that"), or totally unachievable ("we can't
>> do that") thus rendering the conversation a complete waste of time /
>> reviewer attention.
>> 2. [Harmful Interference] The user's use-case would impose harm on some
>> existing use-case(s).
>>
>> No reasonable person will claim the first, given today's scaling debate
>> (not to mention today's 'bitcoin dominance index'). Therefore, critics
>> must claim the second (as, for example, Peter Todd has been doing on
>> this list).
>>
>> Which is why I narrowly focus on inter-chain harms [1], leading
>> ultimately to a focus on the mining ecosystem [2,3] and the development
>> of Blind Merged Mining [4].
>>
>> [1]
>> https://www.youtube.com/watch?v=0goYH2sDw0w&list=PLw8-6ARlyV
>> ciNjgS_NFhAu-qt7HPf_dtg&index=1
>> [2] http://www.truthcoin.info/blog/mirage-miner-centralization/
>> [3] http://www.truthcoin.info/blog/mining-threat-equilibrium/
>> [4] http://www.truthcoin.info/blog/blind-merged-mining/
>> [5] http://www.truthcoin.info/blog/measuring-decentralization/
>>
>> > 1. The Bitcoin network centralizes more, because more power (both
>> > financial power and power in terms of capability/control) is granted
>> > to miners.
>>
>> I think that one has some duty to very clearly define something (like
>> "mining centralization" [2] or "centralization" [5]) before complaining
>> about it. I feel that people will occasionally use selfless complaints
>> to accomplish a selfish goal...especially when the artificial selfless
>> part is hard to discuss by virtue of its being poorly defined
>> (especially vague or abstract items like "the company", "our country",
>> etc). For example, those who take it upon themselves to "defend" "the
>> Bitcoin community" may have exactly that in mind as their primary
>> goal...but they may also end up with more visibility (and with it: more
>> influence, more job offers, more conference invites, more friends, etc)
>> and they may also end up with a megaphone for which to broadcast their
>> other views, or just a defend-able excuse for bragging loudly about how
>> great cypherpunks are and/or how devoted they-in-particular are to the
>> cypherpunk tribe, et cetera. To avoid this problem in my own technical
>> discourse, I try to avoid abstractions like "centralization" until I
>> have defined them [2,5].
>>
>> You have defined centralization above, but the definition is itself
>> vague to the point where I do not think even you actually endorse it.
>> For example, you would need to say that Bitcoin centralizes whenever the
>> exchange rate increases (as this grants additional financial power to
>> miners) or when any new user joins Bitcoin, or when tx fee revenues
>> increase for any reason. You might also be forced to say that LN
>> centralizes Bitcoin (as LN grants new capability/control to miners), and
>> probably even that Bitcoin becomes more centralized when developers
>> release new software (as this grants new capability to miners,
>> specifically the ability to deny upgrades). This probably isn't what you
>> meant, but since you did not clearly explain what you meant we have no
>> way of knowing for sure.
>>
>> It seems to me that you reject the premise that BMM [4] addresses these
>> issues. This is probably because BMM only addresses miner's interactions
>> with each other, and it does not address miner abilities as a group in
>> relation to other groups (for example, vs. users, developers,
>> investors). But, as I consistently emphasize, these groups of people are
>> free to ignore any sidechains that they do not like. In law there is a
>> saying 'volenti non fit injuria' which I would translate as "he who
>> volunteers cannot claim later to have been injured". This is a legal
>> theory, because otherwise everyone would be arbitrarily liable for
>> choices beyond their control (ie, responsible for decisions of other
>> unrelated people), which would be nonsense.
>>
>> > 3. Drivechain limits user's existing choice when it comes to who is
>> > acting as custodian of their Bitcoins, from any trustworthy exchange,
>> > down to a single mining cartel under the control of a single set of
>> laws.
>>
>> Currently no (P2P) sidechains exist, and therefore the set of choices
>> today would seem to be more "limited" than in a post-sidechain future.
>> (The set of options may decrease later, for ecological reasons, if and
>> only if 'exchanges' are a strictly inferior option to 'sidechains' for
>> some reason...I don't see why this would be the case. I also don't
>> understand the emphasis on "exchanges" [SCs are much more like Altcoins,
>> than exchanges] in the first place, nor the dubious qualifier
>> "trustworthy".)
>>
>> --Paul
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>

[-- Attachment #2: Type: text/html, Size: 19667 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]

Hi Erik,

I don't think that your design is competitive. Why would users tolerate
a depreciation of X% per year, when there are alternatives which do not
require such depreciation? It seems to me that none would.

Paul

On 6/20/2017 9:38 AM, Erik Aronesty wrote:
> - a proof-of-burn sidechain is the ultimate two-way peg.   you have to
> burn bitcoin *or* side-chain tokens to mine the side chain.   the size
> of the burn is the degree of security.    i actually wrote code to do
> randomized blind burns where you have a poisson distribution
> (non-deterministic selected burn).    there is no way to game it...
> it's very similar to algorand - but it uses burns instead of staking
>
> - you can then have a secure sidechain that issues a mining reward in
> sidechain tokens, which can be aggrregated and redeemed for bitcoins.
>   the result of this is that any bitcoins held in the sidechain
> depreciate in value at a rate of X% per year.   this deflation rate
> pays for increased security
>
> - logically this functions like an alt coin, with high inflation and
> cheap transactions.   but the altcoin is pegged to bitcoin's price
> because of the pool of unredeemed bitcoins held within the side chain.
>
>
>
> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc <truthcoin@gmail.com
> <mailto:truthcoin@gmail.com>> wrote:
>
>     Hi Erik,
>
>     As you know:
>
>     1. If a sidechain is merged mined it basically grows out of the
>     existing Bitcoin mining network. If it has a different PoW
>     algorithm it is a new mining network.
>     2. The security (ie, hashrate) of any mining network would be
>     determined by the total economic value of the block. In Bitcoin
>     this is (subsidy+tx_fees)*price, but since a sidechain cannot
>     issue new tokens it would only be (tx_fees)*price.
>
>     Unfortunately the two have a nasty correlation which can lead to a
>     disastrous self-fulfilling prophecy: users will avoid a network
>     that is too insecure; and if users avoid using a network, they
>     will stop paying txn fees and so the quantity (tx_fees)*price
>     falls toward zero, erasing the network's security. So it is quite
>     problematic and I recommend just biting the bullet and going with
>     merged mining instead.
>
>     And, the point may be moot. Bitcoin miners may decide that, given
>     their expertise in seeking out cheap sources of power/cooling,
>     they might as well mine both/all chains. So your suggestion may
>     not achieve your desired result (and would, meanwhile, consume
>     more of the economy's resources -- some of these would not
>     contribute even to a higher hashrate).
>
>     Paul
>
>
>
>
>     On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>>     It would be nice to be able to enforce that a drivechain *not*
>>     have the same POW as bitcoin.
>>
>>     I suspect this is the only way to be sure that a drivechain
>>     doesn't destabilize the main chain and push more power to miners
>>     that already have too much power.
>>
>>
>
>


[-- Attachment #2: Type: text/html, Size: 5585 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 3544 bytes --]

Users would tolerate depreciation because the intention is to have a cheap
way of transacting using a two-way pegged chain that isn't controlled by
miners.   Who cares about some minor depreciation when the purpose of the
chain is to do cheap secure transactions forever?

Add in UTXO commitments and you've got a system that is cheap and
secure-enough for transfer. storage and accumulation of a ledger... before
moving in to the main chain.

Seems better to me than messing with the main chain's incentive structure
via merged mining.


On Thu, Jun 22, 2017 at 9:27 AM, Paul Sztorc <truthcoin@gmail.com> wrote:

> Hi Erik,
>
> I don't think that your design is competitive. Why would users tolerate a
> depreciation of X% per year, when there are alternatives which do not
> require such depreciation? It seems to me that none would.
>
> Paul
>
> On 6/20/2017 9:38 AM, Erik Aronesty wrote:
>
> - a proof-of-burn sidechain is the ultimate two-way peg.   you have to
> burn bitcoin *or* side-chain tokens to mine the side chain.   the size of
> the burn is the degree of security.    i actually wrote code to do
> randomized blind burns where you have a poisson distribution
> (non-deterministic selected burn).    there is no way to game it... it's
> very similar to algorand - but it uses burns instead of staking
>
> - you can then have a secure sidechain that issues a mining reward in
> sidechain tokens, which can be aggrregated and redeemed for bitcoins.   the
> result of this is that any bitcoins held in the sidechain depreciate in
> value at a rate of X% per year.   this deflation rate pays for increased
> security
>
> - logically this functions like an alt coin, with high inflation and cheap
> transactions.   but the altcoin is pegged to bitcoin's price because of the
> pool of unredeemed bitcoins held within the side chain.
>
>
>
> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc <truthcoin@gmail.com> wrote:
>
>> Hi Erik,
>>
>> As you know:
>>
>> 1. If a sidechain is merged mined it basically grows out of the existing
>> Bitcoin mining network. If it has a different PoW algorithm it is a new
>> mining network.
>> 2. The security (ie, hashrate) of any mining network would be determined
>> by the total economic value of the block. In Bitcoin this is
>> (subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens it
>> would only be (tx_fees)*price.
>>
>> Unfortunately the two have a nasty correlation which can lead to a
>> disastrous self-fulfilling prophecy: users will avoid a network that is too
>> insecure; and if users avoid using a network, they will stop paying txn
>> fees and so the quantity (tx_fees)*price falls toward zero, erasing the
>> network's security. So it is quite problematic and I recommend just biting
>> the bullet and going with merged mining instead.
>>
>> And, the point may be moot. Bitcoin miners may decide that, given their
>> expertise in seeking out cheap sources of power/cooling, they might as well
>> mine both/all chains. So your suggestion may not achieve your desired
>> result (and would, meanwhile, consume more of the economy's resources --
>> some of these would not contribute even to a higher hashrate).
>>
>> Paul
>>
>>
>>
>>
>> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>>
>> It would be nice to be able to enforce that a drivechain *not* have the
>> same POW as bitcoin.
>>
>> I suspect this is the only way to be sure that a drivechain doesn't
>> destabilize the main chain and push more power to miners that already have
>> too much power.
>>
>>
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 6670 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 5034 bytes --]

Responses inline.

On 6/22/2017 9:45 AM, Erik Aronesty wrote:
> Users would tolerate depreciation because the intention is to have a
> cheap way of transacting using a two-way pegged chain that isn't
> controlled by miners.  Who cares about some minor depreciation when
> the purpose of the chain is to do cheap secure transactions forever?

Thus far you've claimed that these transactions would be "cheap", "[not]
controlled by miners", and "secure".

They would certainly not be cheap, because they are relatively more
expensive due to the extra depreciation cost.

I also doubt that they would be free of control by miners. 51% hashrate
can always filter out any message they want from anywhere.

For the same reason, I don't understand why they would be any more or
less secure.

So I think your way is just a more expensive way of accomplishing
basically the same result.

>
> Add in UTXO commitments and you've got a system that is cheap and
> secure-enough for transfer. storage and accumulation of a ledger...
> before moving in to the main chain.

As I posted to bitcoin-discuss last week, I support UTXO commitments for
sidechains.

> Seems better to me than messing with the main chain's incentive
> structure via merged mining.

I don't think that blind merged mining messes with the main chain's
incentive structure. Miners are free to ignore the sidechain (and yet
still get paid the same as other miners), as are all mainchain users.

Paul
>
> On Thu, Jun 22, 2017 at 9:27 AM, Paul Sztorc <truthcoin@gmail.com
> <mailto:truthcoin@gmail.com>> wrote:
>
>     Hi Erik,
>
>     I don't think that your design is competitive. Why would users
>     tolerate a depreciation of X% per year, when there are
>     alternatives which do not require such depreciation? It seems to
>     me that none would.
>
>     Paul
>
>     On 6/20/2017 9:38 AM, Erik Aronesty wrote:
>>     - a proof-of-burn sidechain is the ultimate two-way peg.   you
>>     have to burn bitcoin *or* side-chain tokens to mine the side
>>     chain.   the size of the burn is the degree of security.    i
>>     actually wrote code to do randomized blind burns where you have a
>>     poisson distribution (non-deterministic selected burn).    there
>>     is no way to game it... it's very similar to algorand - but it
>>     uses burns instead of staking
>>
>>     - you can then have a secure sidechain that issues a mining
>>     reward in sidechain tokens, which can be aggrregated and redeemed
>>     for bitcoins.   the result of this is that any bitcoins held in
>>     the sidechain depreciate in value at a rate of X% per year.  
>>     this deflation rate pays for increased security
>>
>>     - logically this functions like an alt coin, with high inflation
>>     and cheap transactions.   but the altcoin is pegged to bitcoin's
>>     price because of the pool of unredeemed bitcoins held within the
>>     side chain.
>>
>>
>>
>>     On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc <truthcoin@gmail.com
>>     <mailto:truthcoin@gmail.com>> wrote:
>>
>>         Hi Erik,
>>
>>         As you know:
>>
>>         1. If a sidechain is merged mined it basically grows out of
>>         the existing Bitcoin mining network. If it has a different
>>         PoW algorithm it is a new mining network.
>>         2. The security (ie, hashrate) of any mining network would be
>>         determined by the total economic value of the block. In
>>         Bitcoin this is (subsidy+tx_fees)*price, but since a
>>         sidechain cannot issue new tokens it would only be
>>         (tx_fees)*price.
>>
>>         Unfortunately the two have a nasty correlation which can lead
>>         to a disastrous self-fulfilling prophecy: users will avoid a
>>         network that is too insecure; and if users avoid using a
>>         network, they will stop paying txn fees and so the quantity
>>         (tx_fees)*price falls toward zero, erasing the network's
>>         security. So it is quite problematic and I recommend just
>>         biting the bullet and going with merged mining instead.
>>
>>         And, the point may be moot. Bitcoin miners may decide that,
>>         given their expertise in seeking out cheap sources of
>>         power/cooling, they might as well mine both/all chains. So
>>         your suggestion may not achieve your desired result (and
>>         would, meanwhile, consume more of the economy's resources --
>>         some of these would not contribute even to a higher hashrate).
>>
>>         Paul
>>
>>
>>
>>
>>         On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>>>         It would be nice to be able to enforce that a drivechain
>>>         *not* have the same POW as bitcoin.
>>>
>>>         I suspect this is the only way to be sure that a drivechain
>>>         doesn't destabilize the main chain and push more power to
>>>         miners that already have too much power.
>>>
>>>
>>
>>
>
>


[-- Attachment #2: Type: text/html, Size: 10669 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Erik Aronesty]

[-- Attachment #1: Type: text/plain, Size: 6945 bytes --]

> They would certainly not be cheap, because they are relatively more
expensive due to the extra depreciation cost.

This depends on how long you expect to keep money on a side chain and how
many transactions you plan on doing.   Inflation is a great way of paying
PoS / PoB  miners - that cannot introduce issues with consolidation.   If
you design the inflation schedule correctly, it should be balance
transaction costs *precisely*.   Indeed, you can calculate the exact amount
of inflation needed to guarantee that a side chain is always exactly 10
times cheaper than bitcoin.

>As I posted to bitcoin-discuss last week, I support UTXO commitments for
sidechains.

Indeed, I think side chain nodes should always be fast-synced from 6 month
old commitments and thus be ephemeral, cheap, and *never *appropriate for
long term storage.  This would provide the best possible incentive
structure to keep the main chain secure, paid for with high clearing fees,
etc.

> I don't think that blind merged mining messes with the main chain's
incentive structure

The critical issue is that we cannot introduce protocol changes that
*further *incentivize geographical and institutional consolidation.  Miners
who are able to deal with the bandwidth caused by drivechain coffee
transactions will profit from these transactions, whereas smaller and more
geographically distributed miners will not.   Those miners will, in turn,
build faster ASICs and buy more electricity and drive out smaller players.
  I think this is *abundantly *clear, and is the primary motivation behind
preserving block size limits.

If this premise is false (which it may be), or is skewed so as to damage
bitcoin as a whole (could be as well), then that needs to be demonstrated
*first*.

The lightning model does the opposite of this.   Miners watch fees increase
and coming from an *orthoganal* protocol that cannot cause further
centralization.

One problem is that the main chain also *must* grow in response to
bandwidth, or the disadvantages of using the main chain will weaken
financial support and hashrate securing it.   I believe this is also true,
and that a "balancing act" will be Bitcoin's norm until we adopt something
like BIP103 - which provides a steady and appropriate growth.





On Thu, Jun 22, 2017 at 4:30 PM, Paul Sztorc <truthcoin@gmail.com> wrote:

> Responses inline.
>
> On 6/22/2017 9:45 AM, Erik Aronesty wrote:
>
> Users would tolerate depreciation because the intention is to have a cheap
> way of transacting using a two-way pegged chain that isn't controlled by
> miners.  Who cares about some minor depreciation when the purpose of the
> chain is to do cheap secure transactions forever?
>
>
> Thus far you've claimed that these transactions would be "cheap", "[not]
> controlled by miners", and "secure".
>
> They would certainly not be cheap, because they are relatively more
> expensive due to the extra depreciation cost.
>
> I also doubt that they would be free of control by miners. 51% hashrate
> can always filter out any message they want from anywhere.
>
> For the same reason, I don't understand why they would be any more or less
> secure.
>
> So I think your way is just a more expensive way of accomplishing
> basically the same result.
>
>
> Add in UTXO commitments and you've got a system that is cheap and
> secure-enough for transfer. storage and accumulation of a ledger... before
> moving in to the main chain.
>
>
> As I posted to bitcoin-discuss last week, I support UTXO commitments for
> sidechains.
>
> Seems better to me than messing with the main chain's incentive structure
> via merged mining.
>
>
> I don't think that blind merged mining messes with the main chain's
> incentive structure. Miners are free to ignore the sidechain (and yet still
> get paid the same as other miners), as are all mainchain users.
>
> Paul
>
>
> On Thu, Jun 22, 2017 at 9:27 AM, Paul Sztorc <truthcoin@gmail.com> wrote:
>
>> Hi Erik,
>>
>> I don't think that your design is competitive. Why would users tolerate a
>> depreciation of X% per year, when there are alternatives which do not
>> require such depreciation? It seems to me that none would.
>>
>> Paul
>>
>> On 6/20/2017 9:38 AM, Erik Aronesty wrote:
>>
>> - a proof-of-burn sidechain is the ultimate two-way peg.   you have to
>> burn bitcoin *or* side-chain tokens to mine the side chain.   the size of
>> the burn is the degree of security.    i actually wrote code to do
>> randomized blind burns where you have a poisson distribution
>> (non-deterministic selected burn).    there is no way to game it... it's
>> very similar to algorand - but it uses burns instead of staking
>>
>> - you can then have a secure sidechain that issues a mining reward in
>> sidechain tokens, which can be aggrregated and redeemed for bitcoins.   the
>> result of this is that any bitcoins held in the sidechain depreciate in
>> value at a rate of X% per year.   this deflation rate pays for increased
>> security
>>
>> - logically this functions like an alt coin, with high inflation and
>> cheap transactions.   but the altcoin is pegged to bitcoin's price because
>> of the pool of unredeemed bitcoins held within the side chain.
>>
>>
>>
>> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc <truthcoin@gmail.com> wrote:
>>
>>> Hi Erik,
>>>
>>> As you know:
>>>
>>> 1. If a sidechain is merged mined it basically grows out of the existing
>>> Bitcoin mining network. If it has a different PoW algorithm it is a new
>>> mining network.
>>> 2. The security (ie, hashrate) of any mining network would be determined
>>> by the total economic value of the block. In Bitcoin this is
>>> (subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens it
>>> would only be (tx_fees)*price.
>>>
>>> Unfortunately the two have a nasty correlation which can lead to a
>>> disastrous self-fulfilling prophecy: users will avoid a network that is too
>>> insecure; and if users avoid using a network, they will stop paying txn
>>> fees and so the quantity (tx_fees)*price falls toward zero, erasing the
>>> network's security. So it is quite problematic and I recommend just biting
>>> the bullet and going with merged mining instead.
>>>
>>> And, the point may be moot. Bitcoin miners may decide that, given their
>>> expertise in seeking out cheap sources of power/cooling, they might as well
>>> mine both/all chains. So your suggestion may not achieve your desired
>>> result (and would, meanwhile, consume more of the economy's resources --
>>> some of these would not contribute even to a higher hashrate).
>>>
>>> Paul
>>>
>>>
>>>
>>>
>>> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>>>
>>> It would be nice to be able to enforce that a drivechain *not* have the
>>> same POW as bitcoin.
>>>
>>> I suspect this is the only way to be sure that a drivechain doesn't
>>> destabilize the main chain and push more power to miners that already have
>>> too much power.
>>>
>>>
>>>
>>>
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 13550 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Moral Agent]

[-- Attachment #1: Type: text/plain, Size: 8718 bytes --]

>Miners who are able to deal with the bandwidth caused by drivechain coffee
transactions will profit from these transactions, whereas smaller and more
geographically distributed miners will not.   Those miners will, in turn,
build faster ASICs and buy more electricity and drive out smaller players.

I think you are conflating 3 different (though overlapping) groups:

1. Block header generators. These need 'good internet' meaning very low
latency, reasonable bandwidth, good place in network (e.g. FIBRE or mining
backbone). They need reliable computers with enough RAM and CPU to validate
prior blocks promptly and immediately assemble new blocks.

2. Hashers. These need cheap electricity, access to economical uses of
waste heat, cheap mining hardware. e.g. IOT electric water heater.

3. ASIC manufacturers. These need lots of capital, etc.

It might be helpful to keep these three groups distinct in your mind and
conversation, and to use the protocol as a crowbar to pry them into
separate people, or at a minimum make it economically possible to
participate in one role without needing to participate in the other two. If
different, geographically and politically dispersed groups are helping
perform these functions, it aids decentralization.

On Fri, Jun 23, 2017 at 10:19 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > They would certainly not be cheap, because they are relatively more
> expensive due to the extra depreciation cost.
>
> This depends on how long you expect to keep money on a side chain and how
> many transactions you plan on doing.   Inflation is a great way of paying
> PoS / PoB  miners - that cannot introduce issues with consolidation.   If
> you design the inflation schedule correctly, it should be balance
> transaction costs *precisely*.   Indeed, you can calculate the exact amount
> of inflation needed to guarantee that a side chain is always exactly 10
> times cheaper than bitcoin.
>
> >As I posted to bitcoin-discuss last week, I support UTXO commitments for
> sidechains.
>
> Indeed, I think side chain nodes should always be fast-synced from 6 month
> old commitments and thus be ephemeral, cheap, and *never *appropriate for
> long term storage.  This would provide the best possible incentive
> structure to keep the main chain secure, paid for with high clearing fees,
> etc.
>
> > I don't think that blind merged mining messes with the main chain's
> incentive structure
>
> The critical issue is that we cannot introduce protocol changes that
> *further *incentivize geographical and institutional consolidation.
> Miners who are able to deal with the bandwidth caused by drivechain coffee
> transactions will profit from these transactions, whereas smaller and more
> geographically distributed miners will not.   Those miners will, in turn,
> build faster ASICs and buy more electricity and drive out smaller players.
>   I think this is *abundantly *clear, and is the primary motivation
> behind preserving block size limits.
>
> If this premise is false (which it may be), or is skewed so as to damage
> bitcoin as a whole (could be as well), then that needs to be demonstrated
> *first*.
>
> The lightning model does the opposite of this.   Miners watch fees
> increase and coming from an *orthoganal* protocol that cannot cause further
> centralization.
>
> One problem is that the main chain also *must* grow in response to
> bandwidth, or the disadvantages of using the main chain will weaken
> financial support and hashrate securing it.   I believe this is also true,
> and that a "balancing act" will be Bitcoin's norm until we adopt something
> like BIP103 - which provides a steady and appropriate growth.
>
>
>
>
>
> On Thu, Jun 22, 2017 at 4:30 PM, Paul Sztorc <truthcoin@gmail.com> wrote:
>
>> Responses inline.
>>
>> On 6/22/2017 9:45 AM, Erik Aronesty wrote:
>>
>> Users would tolerate depreciation because the intention is to have a
>> cheap way of transacting using a two-way pegged chain that isn't controlled
>> by miners.  Who cares about some minor depreciation when the purpose of the
>> chain is to do cheap secure transactions forever?
>>
>>
>> Thus far you've claimed that these transactions would be "cheap", "[not]
>> controlled by miners", and "secure".
>>
>> They would certainly not be cheap, because they are relatively more
>> expensive due to the extra depreciation cost.
>>
>> I also doubt that they would be free of control by miners. 51% hashrate
>> can always filter out any message they want from anywhere.
>>
>> For the same reason, I don't understand why they would be any more or
>> less secure.
>>
>> So I think your way is just a more expensive way of accomplishing
>> basically the same result.
>>
>>
>> Add in UTXO commitments and you've got a system that is cheap and
>> secure-enough for transfer. storage and accumulation of a ledger... before
>> moving in to the main chain.
>>
>>
>> As I posted to bitcoin-discuss last week, I support UTXO commitments for
>> sidechains.
>>
>> Seems better to me than messing with the main chain's incentive structure
>> via merged mining.
>>
>>
>> I don't think that blind merged mining messes with the main chain's
>> incentive structure. Miners are free to ignore the sidechain (and yet still
>> get paid the same as other miners), as are all mainchain users.
>>
>> Paul
>>
>>
>> On Thu, Jun 22, 2017 at 9:27 AM, Paul Sztorc <truthcoin@gmail.com> wrote:
>>
>>> Hi Erik,
>>>
>>> I don't think that your design is competitive. Why would users tolerate
>>> a depreciation of X% per year, when there are alternatives which do not
>>> require such depreciation? It seems to me that none would.
>>>
>>> Paul
>>>
>>> On 6/20/2017 9:38 AM, Erik Aronesty wrote:
>>>
>>> - a proof-of-burn sidechain is the ultimate two-way peg.   you have to
>>> burn bitcoin *or* side-chain tokens to mine the side chain.   the size of
>>> the burn is the degree of security.    i actually wrote code to do
>>> randomized blind burns where you have a poisson distribution
>>> (non-deterministic selected burn).    there is no way to game it... it's
>>> very similar to algorand - but it uses burns instead of staking
>>>
>>> - you can then have a secure sidechain that issues a mining reward in
>>> sidechain tokens, which can be aggrregated and redeemed for bitcoins.   the
>>> result of this is that any bitcoins held in the sidechain depreciate in
>>> value at a rate of X% per year.   this deflation rate pays for increased
>>> security
>>>
>>> - logically this functions like an alt coin, with high inflation and
>>> cheap transactions.   but the altcoin is pegged to bitcoin's price because
>>> of the pool of unredeemed bitcoins held within the side chain.
>>>
>>>
>>>
>>> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc <truthcoin@gmail.com>
>>> wrote:
>>>
>>>> Hi Erik,
>>>>
>>>> As you know:
>>>>
>>>> 1. If a sidechain is merged mined it basically grows out of the
>>>> existing Bitcoin mining network. If it has a different PoW algorithm it is
>>>> a new mining network.
>>>> 2. The security (ie, hashrate) of any mining network would be
>>>> determined by the total economic value of the block. In Bitcoin this is
>>>> (subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens it
>>>> would only be (tx_fees)*price.
>>>>
>>>> Unfortunately the two have a nasty correlation which can lead to a
>>>> disastrous self-fulfilling prophecy: users will avoid a network that is too
>>>> insecure; and if users avoid using a network, they will stop paying txn
>>>> fees and so the quantity (tx_fees)*price falls toward zero, erasing the
>>>> network's security. So it is quite problematic and I recommend just biting
>>>> the bullet and going with merged mining instead.
>>>>
>>>> And, the point may be moot. Bitcoin miners may decide that, given their
>>>> expertise in seeking out cheap sources of power/cooling, they might as well
>>>> mine both/all chains. So your suggestion may not achieve your desired
>>>> result (and would, meanwhile, consume more of the economy's resources --
>>>> some of these would not contribute even to a higher hashrate).
>>>>
>>>> Paul
>>>>
>>>>
>>>>
>>>>
>>>> On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>>>>
>>>> It would be nice to be able to enforce that a drivechain *not* have the
>>>> same POW as bitcoin.
>>>>
>>>> I suspect this is the only way to be sure that a drivechain doesn't
>>>> destabilize the main chain and push more power to miners that already have
>>>> too much power.
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 16476 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 6488 bytes --]

On 6/23/2017 10:19 AM, Erik Aronesty wrote:
> > They would certainly not be cheap, because they are relatively more expensive due to the
> extra depreciation cost.
>
> If you design the inflation schedule correctly, it should be balance
> transaction costs *precisely*.

You have not explained how your scheme would cause a relative decrease
in transaction costs. The way I see it, tx costs would be exactly the
same, so it would in fact be impossible to design an inflation schedule
to "balance" these costs (other than inflation of zero as I suggest).

>
> > I don't think that blind merged mining messes with the main chain's
> incentive structure 
>
> Miners who are able to deal with the bandwidth caused by drivechain
> coffee transactions
There is no additional bandwidth requirement. That is the point of BMM.
They do not even need to run a sidechain node (to be paid just as much
as if they had).

--Paul



>
> On Thu, Jun 22, 2017 at 4:30 PM, Paul Sztorc <truthcoin@gmail.com
> <mailto:truthcoin@gmail.com>> wrote:
>
>     Responses inline.
>
>     On 6/22/2017 9:45 AM, Erik Aronesty wrote:
>>     Users would tolerate depreciation because the intention is to
>>     have a cheap way of transacting using a two-way pegged chain that
>>     isn't controlled by miners.  Who cares about some minor
>>     depreciation when the purpose of the chain is to do cheap secure
>>     transactions forever?
>
>     Thus far you've claimed that these transactions would be "cheap",
>     "[not] controlled by miners", and "secure".
>
>     They would certainly not be cheap, because they are relatively
>     more expensive due to the extra depreciation cost.
>
>     I also doubt that they would be free of control by miners. 51%
>     hashrate can always filter out any message they want from anywhere.
>
>     For the same reason, I don't understand why they would be any more
>     or less secure.
>
>     So I think your way is just a more expensive way of accomplishing
>     basically the same result.
>
>>
>>     Add in UTXO commitments and you've got a system that is cheap and
>>     secure-enough for transfer. storage and accumulation of a
>>     ledger... before moving in to the main chain.
>
>     As I posted to bitcoin-discuss last week, I support UTXO
>     commitments for sidechains.
>
>>     Seems better to me than messing with the main chain's incentive
>>     structure via merged mining.
>
>     I don't think that blind merged mining messes with the main
>     chain's incentive structure. Miners are free to ignore the
>     sidechain (and yet still get paid the same as other miners), as
>     are all mainchain users.
>
>     Paul
>>
>>     On Thu, Jun 22, 2017 at 9:27 AM, Paul Sztorc <truthcoin@gmail.com
>>     <mailto:truthcoin@gmail.com>> wrote:
>>
>>         Hi Erik,
>>
>>         I don't think that your design is competitive. Why would
>>         users tolerate a depreciation of X% per year, when there are
>>         alternatives which do not require such depreciation? It seems
>>         to me that none would.
>>
>>         Paul
>>
>>         On 6/20/2017 9:38 AM, Erik Aronesty wrote:
>>>         - a proof-of-burn sidechain is the ultimate two-way peg.  
>>>         you have to burn bitcoin *or* side-chain tokens to mine the
>>>         side chain.   the size of the burn is the degree of
>>>         security.    i actually wrote code to do randomized blind
>>>         burns where you have a poisson distribution
>>>         (non-deterministic selected burn).    there is no way to
>>>         game it... it's very similar to algorand - but it uses burns
>>>         instead of staking
>>>
>>>         - you can then have a secure sidechain that issues a mining
>>>         reward in sidechain tokens, which can be aggrregated and
>>>         redeemed for bitcoins.   the result of this is that any
>>>         bitcoins held in the sidechain depreciate in value at a rate
>>>         of X% per year.   this deflation rate pays for increased
>>>         security
>>>
>>>         - logically this functions like an alt coin, with high
>>>         inflation and cheap transactions.   but the altcoin is
>>>         pegged to bitcoin's price because of the pool of unredeemed
>>>         bitcoins held within the side chain.
>>>
>>>
>>>
>>>         On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc
>>>         <truthcoin@gmail.com <mailto:truthcoin@gmail.com>> wrote:
>>>
>>>             Hi Erik,
>>>
>>>             As you know:
>>>
>>>             1. If a sidechain is merged mined it basically grows out
>>>             of the existing Bitcoin mining network. If it has a
>>>             different PoW algorithm it is a new mining network.
>>>             2. The security (ie, hashrate) of any mining network
>>>             would be determined by the total economic value of the
>>>             block. In Bitcoin this is (subsidy+tx_fees)*price, but
>>>             since a sidechain cannot issue new tokens it would only
>>>             be (tx_fees)*price.
>>>
>>>             Unfortunately the two have a nasty correlation which can
>>>             lead to a disastrous self-fulfilling prophecy: users
>>>             will avoid a network that is too insecure; and if users
>>>             avoid using a network, they will stop paying txn fees
>>>             and so the quantity (tx_fees)*price falls toward zero,
>>>             erasing the network's security. So it is quite
>>>             problematic and I recommend just biting the bullet and
>>>             going with merged mining instead.
>>>
>>>             And, the point may be moot. Bitcoin miners may decide
>>>             that, given their expertise in seeking out cheap sources
>>>             of power/cooling, they might as well mine both/all
>>>             chains. So your suggestion may not achieve your desired
>>>             result (and would, meanwhile, consume more of the
>>>             economy's resources -- some of these would not
>>>             contribute even to a higher hashrate).
>>>
>>>             Paul
>>>
>>>
>>>
>>>
>>>             On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>>>>             It would be nice to be able to enforce that a
>>>>             drivechain *not* have the same POW as bitcoin.
>>>>
>>>>             I suspect this is the only way to be sure that a
>>>>             drivechain doesn't destabilize the main chain and push
>>>>             more power to miners that already have too much power.
>>>>
>>>>
>>>
>>>
>>
>>
>
>


[-- Attachment #2: Type: text/html, Size: 17036 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Tao Effect]

[-- Attachment #1.1: Type: text/plain, Size: 3742 bytes --]

Paul,

I'm assuming it's OK with you that I pick up from where we left off in the "Scaling Roadmap" thread [1], so as to be on-topic per your request. (For others reading, part of my reply to the previous email in this thread is here [2]).

For reference, I said:

> Isn't it different in the case of P2SH and SegWit, don't full nodes validate the script?
> 
> In other words, miners don't have complete control over the coins, full nodes keep a check on them.
> 
> At least that was my understanding, and if that's not the case then it doesn't make sense to me why Pieter would earlier in this thread object to Drivechain on the grounds that it's a different security model.


CryptAxe's response was in part:
> You guys are both right that it is a different security model, with the important distinction that it is opt-in. What I disagree with about what you said is only that we are encouraging more risky behavior by adding consensus rules via softfork. There are additional risks with drivechains, but not because of how the new consensus rules would be added (it would be the same risk as the P2SH softfork).


I am now looking closer again at step number 4 in the Drivechain specification [2]:

4. Everyone waits for a period of, say, 3 days. This gives everyone an opportunity to make sure the same WT^ is in both the Bitcoin coinbase and the Sidechain header. If they’re different, everyone has plenty of time to contact each other, figure out what is going on, and restart the process until its right.


It seems to me that where our disagreement lies is in this point.

The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH (and in later emails you reference SegWit as well). Is this really true?

The following suggests to me it isn't:

1. Pieter Wuille's email suggests he disagrees [4]

2. Per the question in [1], it's my understanding that P2SH transactions contain all of the information within themselves for full nodes to act as a check on miners mishandling the anyone-can-spend nature of P2SH transactions. However, that does not seem to be the case with WT^ transactions.


In P2SH txns, there is no need for anyone to, as the Drivechain spec says, "to contact each other, figure out what is going on". Everything just automatically works.


If the security of WT^ transactions could be brought up to actually be in line with the security of P2SH and SegWit transactions, then I would have far less to object to.

Kind regards,
Greg Slepak


[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014763.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014763.html>
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014745.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014745.html>
[3] http://www.truthcoin.info/blog/drivechain/ <http://www.truthcoin.info/blog/drivechain/>
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014721.html <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014721.html>

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

> On Jun 19, 2017, at 9:04 AM, Paul Sztorc <truthcoin@gmail.com <mailto:truthcoin@gmail.com>> wrote:
> 
> Hi Greg,
> 
> Responses below:
> 
> On 6/18/2017 5:30 PM, Tao Effect wrote:
>> In Drivechain, 51% of miners have total control and ownership over all
>> of the sidechain coins.
> 
> It would not be accurate to say that miners have "total" control. Miners
> do control the destination of withdrawals, but they do not control the
> withdrawal-duration nor the withdrawal-frequency.
> 

[ ...snip.. ]


[-- Attachment #1.2: Type: text/html, Size: 8221 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 3301 bytes --]

The confusion below stems from his conflation of several different ideas.

I will try to explicitly clarify a distinction between several types of
user (or, "modes" of use if you prefer):

[DC#0] -- Someone who does not upgrade their Bitcoin software (and is
running, say, 0.13). However, they experience the effects of the new
rules which miners add (as per the soft fork[s] to add drivechain
functionality and individual drivechains).
[DC#1] -- Someone who always upgrades to the latest version of the
Bitcoin software, but otherwise has no interest in running/using sidechains.
[DC#2] -- Someone who upgrades to the latest Bitcoin version, and
decides to also become a full node of one or more sidechains, but who
ever actually uses the sidechains.
[DC#3] -- Someone who upgrades their software, runs sidechain full
nodes, and actively moves money to and from these.


On 7/12/2017 6:43 PM, Tao Effect wrote:
>
> I am now looking closer again at step number 4 in the Drivechain
> specification [2]:
>
>     4. Everyone waits for a period of, say, 3 days. This gives
>     everyone an opportunity to make sure the same WT^ is in both the
>     Bitcoin coinbase and the Sidechain header. If they’re different,
>     everyone has plenty of time to contact each other, figure out what
>     is going on, and restart the process until its right.
>
> It seems to me that where our disagreement lies is in this point.
> The Drivechain spec seems to claim that its use of anyone-can-pay is
> the same as P2SH (and in later emails you reference SegWit as well).
> Is this really true?
FYI that document is nearly two years old, and although it is still
overwhelmingly accurate, new optimizations allow us (I think) to push
the waiting period to several weeks and the total ACK counting period up
to several months.

[DC#0] Yes
[DC#1] Yes
[DC#2] Yes
[DC#3] Yes

Because if a node doesn't have the sidechain's information, it will just
assume every withdrawal is valid. This is comparable to someone who
still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].

(And this is the main advantage of DC over extension blocks).


> 2. Per the question in [1], it's my understanding that P2SH
> transactions contain all of the information within themselves for full
> nodes to act as a check on miners mishandling the anyone-can-spend
> nature of P2SH transactions. However, that does not seem to be the
> case with WT^ transactions.
[DC#0] They do.
[DC#1] They do.
[DC#2] They do.
[DC#3] They do.

Again, from the perspective of a mainchain user, every withdrawal is valid.


> In P2SH txns, there is no need for anyone to, as the Drivechain spec
> says, "to contact each other, figure out what is going on". Everything
> just automatically works.
There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].

[DC#2] and [DC#3] would certainly have an interest in understanding what
is going on, but that has absolutely nothing whatsoever to do with
Bitcoin Core and so is off-topic for this mailing list.


> If the security of WT^ transactions could be brought up to actually be
> in line with the security of P2SH and SegWit transactions, then I
> would have far less to object to.
Somehow I doubt it.


Paul

[-- Attachment #2: Type: text/html, Size: 4978 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Tao Effect]

[-- Attachment #1.1: Type: text/plain, Size: 5410 bytes --]

Paul,

> The confusion below stems from his conflation of several different ideas.

I'm right here, are you having a conversation with me or are you on a stage talking to an audience?

> FYI that document is nearly two years old, and although it is still overwhelmingly accurate, new optimizations allow us (I think) to push the waiting period to several weeks and the total ACK counting period up to several months.

What does that have to do with my question? The counting period, if I understood correctly, is something miners do, not full nodes.

Also, if the document is old and/or outdated, do you happen to have a link to a more update-to-date version of the spec? It would be helpful for review.

> Because if a node doesn't have the sidechain's information, it will just assume every withdrawal is valid. This is comparable to someone who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].

Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as "Yes" without substantiating why you did so.

> Again, from the perspective of a mainchain user, every withdrawal is valid.

And that is not how P2SH works.

> [DC#2] and [DC#3] would certainly have an interest in understanding what is going on, but that has absolutely nothing whatsoever to do with Bitcoin Core and so is off-topic for this mailing list.

How is that an answer to my question?

What does "[DC#2] and [DC#3] would certainly have an interest in understanding what is going on" mean?

In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.

What exactly would [DC#2] and [DC#3] nodes do when faced with an invalid WT^ transaction — invalid in the sense that it contains funds which miners are stealing?

Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.

Kind regards,
Greg Slepak

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

> On Jul 12, 2017, at 5:26 PM, Paul Sztorc <truthcoin@gmail.com <mailto:truthcoin@gmail.com>> wrote:
> 
> The confusion below stems from his conflation of several different ideas.
> 
> I will try to explicitly clarify a distinction between several types of user (or, "modes" of use if you prefer):
> 
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is running, say, 0.13). However, they experience the effects of the new rules which miners add (as per the soft fork[s] to add drivechain functionality and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides to also become a full node of one or more sidechains, but who ever actually uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes, and actively moves money to and from these.
> 
> 
> On 7/12/2017 6:43 PM, Tao Effect wrote:
>> 
>> I am now looking closer again at step number 4 in the Drivechain specification [2]:
>> 
>> 4. Everyone waits for a period of, say, 3 days. This gives everyone an opportunity to make sure the same WT^ is in both the Bitcoin coinbase and the Sidechain header. If they’re different, everyone has plenty of time to contact each other, figure out what is going on, and restart the process until its right.
>> It seems to me that where our disagreement lies is in this point.
>> The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH (and in later emails you reference SegWit as well). Is this really true?
> FYI that document is nearly two years old, and although it is still overwhelmingly accurate, new optimizations allow us (I think) to push the waiting period to several weeks and the total ACK counting period up to several months.
> 
> [DC#0] Yes
> [DC#1] Yes
> [DC#2] Yes
> [DC#3] Yes
> 
> Because if a node doesn't have the sidechain's information, it will just assume every withdrawal is valid. This is comparable to someone who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
> 
> (And this is the main advantage of DC over extension blocks).
> 
> 
>> 2. Per the question in [1], it's my understanding that P2SH transactions contain all of the information within themselves for full nodes to act as a check on miners mishandling the anyone-can-spend nature of P2SH transactions. However, that does not seem to be the case with WT^ transactions.
> [DC#0] They do.
> [DC#1] They do.
> [DC#2] They do.
> [DC#3] They do.
> 
> Again, from the perspective of a mainchain user, every withdrawal is valid.
> 
> 
>> In P2SH txns, there is no need for anyone to, as the Drivechain spec says, "to contact each other, figure out what is going on". Everything just automatically works.
> There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].
> 
> [DC#2] and [DC#3] would certainly have an interest in understanding what is going on, but that has absolutely nothing whatsoever to do with Bitcoin Core and so is off-topic for this mailing list.
> 
> 
>> If the security of WT^ transactions could be brought up to actually be in line with the security of P2SH and SegWit transactions, then I would have far less to object to.
> Somehow I doubt it.
> 
> 
> Paul


[-- Attachment #1.2: Type: text/html, Size: 11403 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 9708 bytes --]

I will repeat that Drivechain can sometimes be confusing because it is
different things to different people.

Here is my attempt to break it down into different modes:

[DC#0] -- Someone who does not upgrade their Bitcoin software (and is
running, say, 0.13). However, they experience the effects of the new
rules which miners add (as per the soft fork[s] to add drivechain
functionality and individual drivechains).
[DC#1] -- Someone who always upgrades to the latest version of the
Bitcoin software, but otherwise has no interest in running/using sidechains.
[DC#2] -- Someone who upgrades to the latest Bitcoin version, and
decides to also become a full node of one or more sidechains, but who
ever actually uses the sidechains.
[DC#3] -- Someone who upgrades their software, runs sidechain full
nodes, and actively moves money to and from these.

Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he
equivocates on the team "steal", using it to mean two different things:
[a] spending an invalid transaction, and [b] a withdrawal that would not
match the report given by a sidechain node.

The two are quite different, see my comments below:


On 7/12/2017 9:15 PM, Tao Effect wrote:
>> FYI that document is nearly two years old, and although it is still
>> overwhelmingly accurate, new optimizations allow us (I think) to push
>> the waiting period to several weeks and the total ACK counting period
>> up to several months.
> What does that have to do with my question? The counting period, if I
> understood correctly, is something miners do, not full nodes.

Greg quoted a passage that contained an older parameter estimate of "a
few days", and I thought it would be helpful and informative if I
clarified that the parameter estimate had been updated to a new (more
secure) value.

In point of fact, he is wrong, because nodes do the counting. When
miners find a block, they can choose to move the counter up, down, or
not at all. But nodes do the counting.


> Also, if the document is old and/or outdated, do you happen to have a
> link to a more update-to-date version of the spec? It would be helpful
> for review.

As I stated above, the document is mostly accurate. There is no other
more up to date version.


>> Because if a node doesn't have the sidechain's information, it will
>> just assume every withdrawal is valid. This is comparable to someone
>> who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it
> as "Yes" without substantiating why you did so.


Above, Greg omitted his original question. For reference, it was:

>  The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH

The answer is that both DC and P2SH use transactions which are 'always
valid' to some group of people (un-upgraded users) but which are
sometimes invalid to new users. So the only difference would be for
[DC#0] vs other versions, but this difference is trivial as miners will
censor invalid txns.

It is your classic soft fork situation.


>> Again, from the perspective of a mainchain user, every withdrawal is
>> valid.
> And that is not how P2SH works.

Again, keep in mind that Greg continually conflates two different things:
1. Whether the soft fork rules have been followed, and
2. Whether the WT^ submitted by a majority hashrate matches the one
calculated by sidechain nodes.

The first case is exactly equal to P2SH. Just as old nodes accept every
P2SH transaction, so too will [DC#0] users accept every WT^ transaction.

In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would
also accept any WT^ *that followed the Drivechain rules*, even if they
did not like the outcome (because the outcome in question was
arbitrarily designated as a "theft" of funds -- again, see the second
case in the list above). In this way, it is exactly similar to P2SH
because nodes will accept *any* p2sh txn **that follows the p2sh
rules**, even if they don't "like" the specific script contained within
(for example, because it is a theft of "their" BitFinex funds, or a
donation to a political candidate they dislike, etc).


>> [DC#2] and [DC#3] would certainly have an interest in understanding
>> what is going on, but that has absolutely nothing whatsoever to do
>> with Bitcoin Core and so is off-topic for this mailing list.
> How is that an answer to my question?

Greg is, of course, not entitled to an answer to irrelevant questions --
just as he would not be entitled to an answer if he asked for my
favorite color or my home address. And such answers would needlessly
consume the mailing list's scarce time.


> What does "[DC#2] and [DC#3] would certainly have an interest in
> understanding what is going on" mean?

It is clear to me that, if we are not clear on the basics first, we
cannot hope to tackle anything intermediate. We will come back to this
after clearing up soft fork part.


> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.

In DC, all upgraded nodes will reject invalid DC transactions, period.


> What exactly would [DC#2] and [DC#3] nodes do when faced with an
> invalid WT^ transaction — invalid in the sense that it contains funds
> which miners are stealing?

The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1]
nodes do. This is what I mean by "every withdrawal is valid".


> Again, in P2SH miners cannot steal funds, because all full nodes have
> a fully automatic enforcement policy.

In DC, miners cannot steal funds, because all full nodes have a fully
automatic enforcement policy.

However, DC *allows* users to choose to place some of their BTC at the
relative mercy of the miners in creative ways, if they wish (as does
P2SH -- someone could write a script which donates funds to miners, and
then fund it... "paying" to that script). This is another example of
conflating [DC#1] and [DC#3].

Paul



>> On Jul 12, 2017, at 5:26 PM, Paul Sztorc <truthcoin@gmail.com
>> <mailto:truthcoin@gmail.com>> wrote:
>>
>> The confusion below stems from his conflation of several different ideas.
>>
>> I will try to explicitly clarify a distinction between several types
>> of user (or, "modes" of use if you prefer):
>>
>> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is
>> running, say, 0.13). However, they experience the effects of the new
>> rules which miners add (as per the soft fork[s] to add drivechain
>> functionality and individual drivechains).
>> [DC#1] -- Someone who always upgrades to the latest version of the
>> Bitcoin software, but otherwise has no interest in running/using
>> sidechains.
>> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and
>> decides to also become a full node of one or more sidechains, but who
>> ever actually uses the sidechains.
>> [DC#3] -- Someone who upgrades their software, runs sidechain full
>> nodes, and actively moves money to and from these.
>>
>>
>> On 7/12/2017 6:43 PM, Tao Effect wrote:
>>>
>>> I am now looking closer again at step number 4 in the Drivechain
>>> specification [2]:
>>>
>>>     4. Everyone waits for a period of, say, 3 days. This gives
>>>     everyone an opportunity to make sure the same WT^ is in both the
>>>     Bitcoin coinbase and the Sidechain header. If they’re different,
>>>     everyone has plenty of time to contact each other, figure out
>>>     what is going on, and restart the process until its right.
>>>
>>> It seems to me that where our disagreement lies is in this point.
>>> The Drivechain spec seems to claim that its use of anyone-can-pay is
>>> the same as P2SH (and in later emails you reference SegWit as well).
>>> Is this really true?
>> FYI that document is nearly two years old, and although it is still
>> overwhelmingly accurate, new optimizations allow us (I think) to push
>> the waiting period to several weeks and the total ACK counting period
>> up to several months.
>>
>> [DC#0] Yes
>> [DC#1] Yes
>> [DC#2] Yes
>> [DC#3] Yes
>>
>> Because if a node doesn't have the sidechain's information, it will
>> just assume every withdrawal is valid. This is comparable to someone
>> who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>>
>> (And this is the main advantage of DC over extension blocks).
>>
>>
>>> 2. Per the question in [1], it's my understanding that P2SH
>>> transactions contain all of the information within themselves for
>>> full nodes to act as a check on miners mishandling the
>>> anyone-can-spend nature of P2SH transactions. However, that does not
>>> seem to be the case with WT^ transactions.
>> [DC#0] They do.
>> [DC#1] They do.
>> [DC#2] They do.
>> [DC#3] They do.
>>
>> Again, from the perspective of a mainchain user, every withdrawal is
>> valid.
>>
>>
>>> In P2SH txns, there is no need for anyone to, as the Drivechain spec
>>> says, "to contact each other, figure out what is going on".
>>> Everything just automatically works.
>> There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].
>>
>> [DC#2] and [DC#3] would certainly have an interest in understanding
>> what is going on, but that has absolutely nothing whatsoever to do
>> with Bitcoin Core and so is off-topic for this mailing list.
>>
>>
>>> If the security of WT^ transactions could be brought up to actually
>>> be in line with the security of P2SH and SegWit transactions, then I
>>> would have far less to object to.
>> Somehow I doubt it.
>>
>>
>> Paul
>


[-- Attachment #2: Type: text/html, Size: 17864 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Tao Effect]

[-- Attachment #1.1: Type: text/plain, Size: 10033 bytes --]

Dear Paul,

> In point of fact, he is wrong, because nodes do the counting. When miners find a block, they can choose to move the counter up, down, or not at all. But nodes do the counting.

I may very well have confused who counts what, but for this discussion on *theft* it's irrelevant, so I won't push further on this.

Let's move on to the theft.

> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes.
> 
> The first case is exactly equal to P2SH. Just as old nodes accept every P2SH transaction, so too will [DC#0] users accept every WT^ transaction.

To be crystal clear: I am entirely uninterested in the un-upgraded nodes, what you call [DC#0].

They are irrelevant to my argument.

> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would also accept any WT^ *that followed the Drivechain rules*, even if they did not like the outcome (because the outcome in question was arbitrarily designated as a "theft" of funds -- again, see the second case in the list above). In this way, it is exactly similar to P2SH because nodes will accept *any* p2sh txn **that follows the p2sh rules**, even if they don't "like" the specific script contained within (for example, because it is a theft of "their" BitFinex funds, or a donation to a political candidate they dislike, etc).

This is false.

For miners to steal P2SH funds, the P2SH script would have to be coded to explicitly allow them to do it.

How many P2SH scripts are you aware of that are used for the purpose of facilitating such theft?

I know of none, and I bet there are none.

Whereas in DC, every single usage of DC allows miners to steal funds.

>> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
> 
> In DC, all upgraded nodes will reject invalid DC transactions, period.

It appears you are playing games with the meaning of "invalid" here, so that sentence is invalid.

I was very clear what I meant by "invalid" in my email: WT^ transactions that represent miners stealing funds. Please stick to that and do not play word games.

> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1] nodes do. This is what I mean by "every withdrawal is valid".

So, here you are again re-affirming that WT^ transactions representing stolen funds are allowed in DC, and by tying them all together you are also affirming that the SPV proofs mentioned in DC are completely irrelevant / pointless / unused.

>> Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
> 
> In DC, miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
> 
> However, DC *allows* users to choose to place some of their BTC at the relative mercy of the miners in creative ways, if they wish (as does P2SH -- someone could write a script which donates funds to miners, and then fund it... "paying" to that script). This is another example of conflating [DC#1] and [DC#3].

So in the first sentence you say they "cannot steal funds", but everything else you've said, including the following paragraph, and your specification, indicates they can.

I've finally collected all my thoughts / concerns and have also summarized them in this document:

https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9 <https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9>

Kind regards,
Greg Slepak

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

> On Jul 12, 2017, at 7:58 PM, Paul Sztorc via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> 
> I will repeat that Drivechain can sometimes be confusing because it is different things to different people.
> 
> Here is my attempt to break it down into different modes:
> 
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is running, say, 0.13). However, they experience the effects of the new rules which miners add (as per the soft fork[s] to add drivechain functionality and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides to also become a full node of one or more sidechains, but who ever actually uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes, and actively moves money to and from these.
> 
> Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he equivocates on the team "steal", using it to mean two different things: [a] spending an invalid transaction, and [b] a withdrawal that would not match the report given by a sidechain node.
> 
> The two are quite different, see my comments below:
> 
> 
> On 7/12/2017 9:15 PM, Tao Effect wrote:
>>> FYI that document is nearly two years old, and although it is still overwhelmingly accurate, new optimizations allow us (I think) to push the waiting period to several weeks and the total ACK counting period up to several months.
>> 
>> What does that have to do with my question? The counting period, if I understood correctly, is something miners do, not full nodes.
> 
> Greg quoted a passage that contained an older parameter estimate of "a few days", and I thought it would be helpful and informative if I clarified that the parameter estimate had been updated to a new (more secure) value.
> 
> In point of fact, he is wrong, because nodes do the counting. When miners find a block, they can choose to move the counter up, down, or not at all. But nodes do the counting.
> 
> 
>> Also, if the document is old and/or outdated, do you happen to have a link to a more update-to-date version of the spec? It would be helpful for review.
> 
> As I stated above, the document is mostly accurate. There is no other more up to date version.
> 
> 
>>> Because if a node doesn't have the sidechain's information, it will just assume every withdrawal is valid. This is comparable to someone who still hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>> 
>> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as "Yes" without substantiating why you did so.
> 
> 
> Above, Greg omitted his original question. For reference, it was:
> 
>>  The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH
> 
> The answer is that both DC and P2SH use transactions which are 'always valid' to some group of people (un-upgraded users) but which are sometimes invalid to new users. So the only difference would be for [DC#0] vs other versions, but this difference is trivial as miners will censor invalid txns.
> 
> It is your classic soft fork situation.
> 
> 
>>> Again, from the perspective of a mainchain user, every withdrawal is valid.
>> 
>> And that is not how P2SH works.
> 
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes.
> 
> The first case is exactly equal to P2SH. Just as old nodes accept every P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
> 
> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would also accept any WT^ *that followed the Drivechain rules*, even if they did not like the outcome (because the outcome in question was arbitrarily designated as a "theft" of funds -- again, see the second case in the list above). In this way, it is exactly similar to P2SH because nodes will accept *any* p2sh txn **that follows the p2sh rules**, even if they don't "like" the specific script contained within (for example, because it is a theft of "their" BitFinex funds, or a donation to a political candidate they dislike, etc).
> 
> 
>>> [DC#2] and [DC#3] would certainly have an interest in understanding what is going on, but that has absolutely nothing whatsoever to do with Bitcoin Core and so is off-topic for this mailing list.
>> 
>> How is that an answer to my question?
> 
> Greg is, of course, not entitled to an answer to irrelevant questions -- just as he would not be entitled to an answer if he asked for my favorite color or my home address. And such answers would needlessly consume the mailing list's scarce time.
> 
> 
>> What does "[DC#2] and [DC#3] would certainly have an interest in understanding what is going on" mean?
> 
> It is clear to me that, if we are not clear on the basics first, we cannot hope to tackle anything intermediate. We will come back to this after clearing up soft fork part.
> 
> 
>> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
> 
> In DC, all upgraded nodes will reject invalid DC transactions, period.
> 
> 
>> What exactly would [DC#2] and [DC#3] nodes do when faced with an invalid WT^ transaction — invalid in the sense that it contains funds which miners are stealing?
> 
> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1] nodes do. This is what I mean by "every withdrawal is valid".
> 
> 
>> Again, in P2SH miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
> 
> In DC, miners cannot steal funds, because all full nodes have a fully automatic enforcement policy.
> 
> However, DC *allows* users to choose to place some of their BTC at the relative mercy of the miners in creative ways, if they wish (as does P2SH -- someone could write a script which donates funds to miners, and then fund it... "paying" to that script). This is another example of conflating [DC#1] and [DC#3].
> 
> Paul


[-- Attachment #1.2: Type: text/html, Size: 45345 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Hampus Sjöberg]

[-- Attachment #1: Type: text/plain, Size: 11339 bytes --]

In softforks, I would argue that 100% of all nodes and miners need to
upgrade to the new rules.
This makes sure that trying to incorrectly spend an "AnyOneCanSpend" will
result in a hardfork, instead of a temporary (or permanent) chainsplit.

With drivechains, it seems like the current plan is to only let the nodes
that are interested in the drivechain validate the other chain, and not
necessarily 100% of the network.
I guess this could be any percentage of the network, which could lead to a
temporary/permanent chainsplit depending on how many percentage of the
miners are also validating the other chain (am I missing something here?).

I have no way to evaluate if this is an okay trade-off.
It seems like major disruption could very likely happen if say only 5% of
all fullnodes validate the drivechain.

To be fully secure, it seems like 100% of all nodes should also have a
fullnode for the drivechain as well...
This is one of the reasons I don't advocate sidechains/drivechains as a
scaling solution, it looks like it would have to the same outcome as a
blocksize increase on the mainchain, but with more complexity.
I think sidechains/drivechains could be useful for other things though.


Thanks for all your work so far Paul.
Hampus

2017-07-13 4:58 GMT+02:00 Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> I will repeat that Drivechain can sometimes be confusing because it is
> different things to different people.
>
> Here is my attempt to break it down into different modes:
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is
> running, say, 0.13). However, they experience the effects of the new rules
> which miners add (as per the soft fork[s] to add drivechain functionality
> and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin
> software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides
> to also become a full node of one or more sidechains, but who ever actually
> uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes,
> and actively moves money to and from these.
>
> Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he
> equivocates on the team "steal", using it to mean two different things: [a]
> spending an invalid transaction, and [b] a withdrawal that would not match
> the report given by a sidechain node.
>
> The two are quite different, see my comments below:
>
>
> On 7/12/2017 9:15 PM, Tao Effect wrote:
>
> FYI that document is nearly two years old, and although it is still
> overwhelmingly accurate, new optimizations allow us (I think) to push the
> waiting period to several weeks and the total ACK counting period up to
> several months.
>
> What does that have to do with my question? The counting period, if I
> understood correctly, is something miners do, not full nodes.
>
>
> Greg quoted a passage that contained an older parameter estimate of "a few
> days", and I thought it would be helpful and informative if I clarified
> that the parameter estimate had been updated to a new (more secure) value.
>
> In point of fact, he is wrong, because nodes do the counting. When miners
> find a block, they can choose to move the counter up, down, or not at all.
> But nodes do the counting.
>
>
> Also, if the document is old and/or outdated, do you happen to have a link
> to a more update-to-date version of the spec? It would be helpful for
> review.
>
>
> As I stated above, the document is mostly accurate. There is no other more
> up to date version.
>
>
> Because if a node doesn't have the sidechain's information, it will just
> assume every withdrawal is valid. This is comparable to someone who still
> hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
>
> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as
> "Yes" without substantiating why you did so.
>
>
>
> Above, Greg omitted his original question. For reference, it was:
>
>  The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH
>
>
> The answer is that both DC and P2SH use transactions which are 'always
> valid' to some group of people (un-upgraded users) but which are sometimes
> invalid to new users. So the only difference would be for [DC#0] vs other
> versions, but this difference is trivial as miners will censor invalid txns.
>
> It is your classic soft fork situation.
>
>
> Again, from the perspective of a mainchain user, every withdrawal is valid.
>
> And that is not how P2SH works.
>
>
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one
> calculated by sidechain nodes.
>
> The first case is exactly equal to P2SH. Just as old nodes accept every
> P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
>
> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would
> also accept any WT^ *that followed the Drivechain rules*, even if they did
> not like the outcome (because the outcome in question was arbitrarily
> designated as a "theft" of funds -- again, see the second case in the list
> above). In this way, it is exactly similar to P2SH because nodes will
> accept *any* p2sh txn **that follows the p2sh rules**, even if they don't
> "like" the specific script contained within (for example, because it is a
> theft of "their" BitFinex funds, or a donation to a political candidate
> they dislike, etc).
>
>
> [DC#2] and [DC#3] would certainly have an interest in understanding what
> is going on, but that has absolutely nothing whatsoever to do with Bitcoin
> Core and so is off-topic for this mailing list.
>
> How is that an answer to my question?
>
>
> Greg is, of course, not entitled to an answer to irrelevant questions --
> just as he would not be entitled to an answer if he asked for my favorite
> color or my home address. And such answers would needlessly consume the
> mailing list's scarce time.
>
>
> What does "[DC#2] and [DC#3] would certainly have an interest in
> understanding what is going on" mean?
>
>
> It is clear to me that, if we are not clear on the basics first, we cannot
> hope to tackle anything intermediate. We will come back to this after
> clearing up soft fork part.
>
>
> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
>
>
> In DC, all upgraded nodes will reject invalid DC transactions, period.
>
>
> What exactly would [DC#2] and [DC#3] nodes do when faced with an invalid
> WT^ transaction — invalid in the sense that it contains funds which miners
> are stealing?
>
>
> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1]
> nodes do. This is what I mean by "every withdrawal is valid".
>
>
> Again, in P2SH miners cannot steal funds, because all full nodes have a
> fully automatic enforcement policy.
>
>
> In DC, miners cannot steal funds, because all full nodes have a fully
> automatic enforcement policy.
>
> However, DC *allows* users to choose to place some of their BTC at the
> relative mercy of the miners in creative ways, if they wish (as does P2SH
> -- someone could write a script which donates funds to miners, and then
> fund it... "paying" to that script). This is another example of conflating
> [DC#1] and [DC#3].
>
> Paul
>
>
>
>
> On Jul 12, 2017, at 5:26 PM, Paul Sztorc <truthcoin@gmail.com> wrote:
>
> The confusion below stems from his conflation of several different ideas.
>
> I will try to explicitly clarify a distinction between several types of
> user (or, "modes" of use if you prefer):
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is
> running, say, 0.13). However, they experience the effects of the new rules
> which miners add (as per the soft fork[s] to add drivechain functionality
> and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin
> software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides
> to also become a full node of one or more sidechains, but who ever actually
> uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes,
> and actively moves money to and from these.
>
>
> On 7/12/2017 6:43 PM, Tao Effect wrote:
>
>
> I am now looking closer again at step number 4 in the Drivechain
> specification [2]:
>
> 4. Everyone waits for a period of, say, 3 days. This gives everyone an
> opportunity to make sure the same WT^ is in both the Bitcoin coinbase and
> the Sidechain header. If they’re different, everyone has plenty of time to
> contact each other, figure out what is going on, and restart the process
> until its right.
>
> It seems to me that where our disagreement lies is in this point.
> The Drivechain spec seems to claim that its use of anyone-can-pay is the
> same as P2SH (and in later emails you reference SegWit as well). Is this
> really true?
>
> FYI that document is nearly two years old, and although it is still
> overwhelmingly accurate, new optimizations allow us (I think) to push the
> waiting period to several weeks and the total ACK counting period up to
> several months.
>
> [DC#0] Yes
> [DC#1] Yes
> [DC#2] Yes
> [DC#3] Yes
>
> Because if a node doesn't have the sidechain's information, it will just
> assume every withdrawal is valid. This is comparable to someone who still
> hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
> (And this is the main advantage of DC over extension blocks).
>
>
> 2. Per the question in [1], it's my understanding that P2SH transactions
> contain all of the information within themselves for full nodes to act as a
> check on miners mishandling the anyone-can-spend nature of P2SH
> transactions. However, that does not seem to be the case with WT^
> transactions.
>
> [DC#0] They do.
> [DC#1] They do.
> [DC#2] They do.
> [DC#3] They do.
>
> Again, from the perspective of a mainchain user, every withdrawal is valid.
>
>
> In P2SH txns, there is no need for anyone to, as the Drivechain spec says,
> "to contact each other, figure out what is going on". Everything just
> automatically works.
>
> There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].
>
> [DC#2] and [DC#3] would certainly have an interest in understanding what
> is going on, but that has absolutely nothing whatsoever to do with Bitcoin
> Core and so is off-topic for this mailing list.
>
>
> If the security of WT^ transactions could be brought up to actually be in
> line with the security of P2SH and SegWit transactions, then I would have
> far less to object to.
>
> Somehow I doubt it.
>
>
> Paul
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 18339 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc]

[-- Attachment #1: Type: text/plain, Size: 6908 bytes --]

Greg is still conflating two different usages of the word "theft":
1. Whether the soft fork rules have been followed, and
2. Whether the WT^ submitted by a majority hashrate matches the one
calculated by sidechain nodes.

In his message he claims to uniquely adopt definition #2, saying
(emphasis added):

> I was very clear what I meant by "invalid" in my email: WT^
> transactions that represent miners stealing funds. **Please stick to
> that** and do not play word games.

...however, he revokes that commitment below when it suits his purposes.

Since Greg's message is probably too confusing to be helpful, I will
first clarify both cases:

Case 1 -- soft fork rules -- all "invalid_1" txns are regarded as
"theft_1" and are rejected.
Case 2 -- sidechain's unique consensus rules -- all WT^ are accepted (if
these WT^ are valid_1 under the Case 1 rules), whether they match the
sidechain's reported WT^ or not (in other words, whether they are
valid_2 or not).

In Case 2, the mainchain accepts all WT^ transactions as "valid", in
that they can be included in a block, whether or not they are
"valid_2".  By design, sidechains make no effort to validate the rules
specific to each sidechain, just as they make no effort to validate the
rules of Altcoins. In this way, a WT^ transaction is comparable to
someone who is selling an Altcoin to purchase some Bitcoin -- Bitcoin
doesn't care how they got the Altcoin.


On 7/12/2017 11:24 PM, Tao Effect wrote:
> Dear Paul,
>
>> In point of fact, he is wrong, because nodes do the counting. When
>> miners find a block, they can choose to move the counter up, down, or
>> not at all. But nodes do the counting.
>
> I may very well have confused who counts what

To be clear: yes, Greg did get it confused.

And it is very important, because a neglect of the node-enforced rules
is a neglect of **both** theft_1 and theft_2 simultaneously, making it
easier to conflate the both of them as Greg is still doing.


>> In the second case, it so happens that [DC#1], [DC#2], and [DC#3]
>> would also accept any WT^ *that followed the Drivechain rules*, even
>> if they did not like the outcome (because the outcome in question was
>> arbitrarily designated as a "theft" of funds -- again, see the second
>> case in the list above). In this way, it is exactly similar to P2SH
>> because nodes will accept *any* p2sh txn **that follows the p2sh
>> rules**, even if they don't "like" the specific script contained
>> within (for example, because it is a theft of "their" BitFinex funds,
>> or a donation to a political candidate they dislike, etc).
>
> This is false.
>
> For miners to steal P2SH funds, the P2SH script would have to be coded
> to explicitly allow them to do it.
>
> How many P2SH scripts are you aware of that are used for the purpose
> of facilitating such theft?
>
> I know of none, and I bet there are none.


This is the instance I mentioned above -- despite committing to only
discussing theft_2, Greg has secretly switched back to theft_1, when he
talks about a "P2SH script...used for the purpose of facilitating theft".

Under theft_2, there is no way to infer the theft-ness of the
transaction from the script itself. For example, if someone made a
2-of-3 multisig with a third party escrow , and these funds were
"stolen", this would be an example of funds "stolen" from a P2SH under
"theft_2".

At which point Greg would angrily say that whoever wrote P2SH was
reckless and...allowed Bitcoins to be "stolen". Or perhaps he would
switch definitions yet again, and say that "that doesn't count as
theft". blah blah blah yada yada yada

It is true that moving from pre-P2SH to post-P2SH has not --yet--
enabled any theft_2 as a result. But P2SH has also failed to enable
sidechains. Sidechains logically must open the door to theft_2, else
they will regress to the undesirable cases of hard/evil fork (as I
explain in the spec). Empirically, we do not know how much theft_2 will
be enabled by drivechain. Theoretically, it is possible that there will
never be a theft_2 on drivechain.


>> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and
>> [DC#1] nodes do. This is what I mean by "every withdrawal is valid".
>
> So, here you are again re-affirming that WT^ transactions representing
> stolen funds are allowed in DC, and by tying them all together you are
> also affirming that the SPV proofs mentioned in DC are completely
> irrelevant / pointless / unused.

I do not affirm the latter. The SPV proofs in DC are very important, as
they are what allow nodes to enforce the delayed withdrawal upon miners.
In fact, this is exactly what Greg admits to being confused about above.
He is correct that he is confused.

Experts including Adam Back (co-author of original sidechains paper, CEO
of Blockstream which started the sidechains conversation) have publicly
stated that they share my belief that this delayed withdrawal technique
is likely to mitigate the threat of theft_2. Greg S is free to hold a
different opinion.


>>> Again, in P2SH miners cannot steal funds, because all full nodes
>>> have a fully automatic enforcement policy.
>>
>> In DC, miners cannot steal funds, because all full nodes have a fully
>> automatic enforcement policy.
>>
>> However, DC *allows* users to choose to place some of their BTC at
>> the relative mercy of the miners in creative ways, if they wish (as
>> does P2SH -- someone could write a script which donates funds to
>> miners, and then fund it... "paying" to that script). This is another
>> example of conflating [DC#1] and [DC#3].
>
> So in the first sentence you say they "cannot steal funds", but
> everything else you've said, including the following paragraph, and
> your specification, indicates they can.

Greg did not specify which theft so I had to guess in the above case. 
Above, I refer to "theft_1", the [DC#0] style theft. As always, no one
can "steal_1" funds in that case.

The reason I assumed Greg was talking about theft_1 and not theft_2, is
because he mentioned P2SH and the fact that full nodes automatically
enforce the network's rules. Drivechain's rules impose a new format,
like P2SH, and have new rules which are automatically enforced by nodes.

Greg's style is basically to confuse two things, ask unclear questions
about them, and then try to discover "contradictions" in the mess that
follows. But it is all a function of his conflation of terminology and
nothing else.


> I've finally collected all my thoughts / concerns and have also
> summarized them in this document:
>
> https://gist.github.com/taoeffect/9ff64cf78cf1408ec29f13ed39e534c9

Given how little Greg understands, even after being hand-fed by me for
days and weeks, I admit a totally nonexistent interest in reading it.

Paul

[-- Attachment #2: Type: text/html, Size: 11922 bytes --]

Re: [bitcoin-dev] Drivechain RfD -- Follow Up

[Paul Sztorc]

Hello,


On 7/13/2017 9:17 AM, Hampus Sjöberg wrote:
> In softforks, I would argue that 100% of all nodes and miners need to
> upgrade to the new rules.
> This makes sure that trying to incorrectly spend an "AnyOneCanSpend"
> will result in a hardfork, instead of a temporary (or permanent)
> chainsplit.
>
> With drivechains, it seems like the current plan is to only let the
> nodes that are interested in the drivechain validate the other chain,
> and not necessarily 100% of the network.

Correct.


> I guess this could be any percentage of the network, which could lead
> to a temporary/permanent chainsplit depending on how many percentage
> of the miners are also validating the other chain (am I missing
> something here?).
> I have no way to evaluate if this is an okay trade-off.
> It seems like major disruption could very likely happen if say only 5%
> of all fullnodes validate the drivechain.


You are correct that some % of the network would be validating both
chains. However, if miners improperly withdraw from a sidechain, it --by
design-- does not lead to any chainsplit of any kind. Instead, the
sidechain in question just dies a painful death (notice that, if any
withdrawals are improper, it is quite as bad as if all of the sidechain
funds were withdrawn improperly -- this is because the sidechain would
instantly have a bunch of problems, including that it would be
something-like 'fractional reserve' which would lead to an immediate
bank run of withdrawals [none of which could have any real expectation
of success, in my view]).

In practice, a concern of mine is that people *would* try to turn a
sidechain-theft even into some kind of grand UASF-style campaign. I
would prefer for people not to do this. Then again, I do not hold this
preference unconditionally -- I see it as comparable to Bitcoin's
commitment to "the code is the spec". Which is to say that this
commitment is overwhelmingly held, but not dogmatically as in
exceptional cases such as theValue overflow incident [1].

I think that in such ambiguous cases, we must rely on [a] the miner's
desire to maximize the purchasing power of each Bitcoin, and [b] the
technical wisdom of Bitcoin's future leaders in helping miners to
achieve this goal.

[1] https://en.bitcoin.it/wiki/Value_overflow_incident


> To be fully secure, it seems like 100% of all nodes should also have a
> fullnode for the drivechain as well...

Perhaps, but this is exactly what I am trying to avoid. The design goal,
in some sense, is to have "half security", ie <100%. This is because the
only way to achieve "full" 100% security is with full enforcement of all
rules. Full enforcement of the rules, in turn, means either that we are
exactly where we are right now (where we only add compatible rules, aka
the traditional "soft fork") or we are [also] exactly where we are right
now (in that if we add an incompatible rule, it results in a "hard
fork"). I would like to build something new, which trades off on the
qualities of each, and therefore lies (intentionally) somewhere in between.


> This is one of the reasons I don't advocate sidechains/drivechains as
> a scaling solution, it looks like it would have to the same outcome as
> a blocksize increase on the mainchain, but with more complexity.

Keep in mind that, if some people leave the small chain (what you might
call the "Core" chain, although some disagree with summarizing it this
way) for some other chain, it does free up more space on this chain.

I'm not really sure the extent to which that "counts" as increasing
capacity.

Also, I agree that sc/dc do not help with "scalability", if that problem
is defined as "better technology" or as "how to do more with less".

Actually my full view is a little nuanced and it is here:
http://www.drivechain.info/faq/index.html#can-sidechains-really-help-with-scaling


> Thanks for all your work so far Paul.

You're welcome!

Paul