[bitcoin-dev] Drivechain -- Request for Discussion

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
[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

Paul Sztorc via bitcoin-dev

2017-05-22 15:30:46 UTC

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.

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

Post by Paul Sztorc via bitcoin-dev
[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

Peter Todd via bitcoin-dev

2017-05-28 21:07:57 UTC

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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

Erik Aronesty via bitcoin-dev

2017-05-29 05:54:34 UTC

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

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.

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.

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

Paul Sztorc via bitcoin-dev

2017-05-30 05:11:51 UTC

Hi Peter,

Responses below.

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

Post by Peter Todd via bitcoin-dev
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).

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.

Post by Peter Todd via bitcoin-dev
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/

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.

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.

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
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!

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
1) https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy

Sergio Demian Lerner via bitcoin-dev

2017-06-09 21:54:00 UTC

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 <

Post by Paul Sztorc via bitcoin-dev
Hi Peter,
Responses below.

Post by Paul Sztorc via bitcoin-dev
Surprisingly, this requirement (or, more precisely, this incentive) does
not effect miners relative to each other. The incentive to upgrade is

only

Post by Paul Sztorc via bitcoin-dev
for the purpose of preventing a "theft" -- defined as: an improper
withdrawal from a sidechain. It is not about miner revenues or the

ability

Post by Paul Sztorc via bitcoin-dev
to mine generally (or conduct BMM specifically). The costs of such a

theft

Post by Paul Sztorc via bitcoin-dev
(decrease in market price, decrease in future transaction fee levels)

would

Post by Paul Sztorc via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
miner to prevent that theft, I have reasons to induce it to happen to

give me

Post by Peter Todd via bitcoin-dev
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"?

Post by Peter Todd via bitcoin-dev
This is a very similar problem to what we had with zeroconf

double-spending,

Post by Peter Todd via bitcoin-dev
where entities such as Coinbase tried to pay off miners to guarantee

something

Post by Peter Todd via bitcoin-dev
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).

Post by Paul Sztorc via bitcoin-dev
Moreover, miners have other recourse if they are unable to run the node.
They can adopt a policy of simply rejecting ("downvoting") any

withdrawals

Post by Paul Sztorc via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
Equally, you're opening up miners to huge political risks, as rejecting

all

Post by Peter Todd via bitcoin-dev
withdrawals is preventing users' from getting their money, which gives

other

Post by Peter Todd via bitcoin-dev
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/

Post by Paul Sztorc via bitcoin-dev
Finally, the point in dispute is a single, infrequent, true/false

question.

Post by Paul Sztorc via bitcoin-dev
So miners may resort to semi-trusted methods to supplement their

decision.

Post by Paul Sztorc via bitcoin-dev
In other words, they can just ask people they trust, if the withdrawal

Post by Paul Sztorc via bitcoin-dev
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.

This is also a very dubious security model - I would argue that Bitcoin

is much

Post by Peter Todd via bitcoin-dev
*more* valuable if miners do everything they can to ensure that

drivechains

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
I would also argue that users

should do

Post by Peter Todd via bitcoin-dev
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.

involve

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
I have to ask: What use-cases do you actually see for drivechains? Why

can't
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!

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
1) https://petertodd.org/2016/closed-seal-sets-and-truth-

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

Paul Sztorc via bitcoin-dev

2017-06-10 16:28:09 UTC

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

Post by Sergio Demian Lerner via bitcoin-dev
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
https://github.com/rootstock/bips/blob/master/BIP-R10.md
<https://github.com/rootstock/bips/blob/master/BIP-R10.md>
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
Hi Peter,
Responses below.

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

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

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.

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

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.

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.

Post by Peter Todd via bitcoin-dev
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.

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>

Post by Peter Todd via bitcoin-dev
I have to ask: What use-cases do you actually see for drivechains? Why can't

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!

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

ZmnSCPxj via bitcoin-dev

2017-05-22 14:39:19 UTC

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-***@lists.linuxfoundation.org
To: Bitcoin Dev <bitcoin-***@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]
http://youtu.be/YErLEuOi3xU

Paul Sztorc via bitcoin-dev

2017-05-22 16:19:14 UTC

On May 22, 2017 10:39 AM, "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-***@lists.linuxfoundation.org
To: Bitcoin Dev <bitcoin-***@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]
http://youtu.be/YErLEuOi3xU
6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4

Tier Nolan via bitcoin-dev

2017-05-22 19:12:54 UTC

On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev <

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
In point of fact, the transactions *are* validated...by sidechain full
nodes, same as Bitcoin proper.

Post by Paul Sztorc via bitcoin-dev
Paul
Regards,
ZmnSCPxj

Paul Sztorc via bitcoin-dev

2017-05-22 20:00:19 UTC

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

On Mon, May 22, 2017 at 5:19 PM, Paul Sztorc via bitcoin-dev <

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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".

Tier Nolan via bitcoin-dev

2017-05-23 09:51:26 UTC

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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

Post by Paul Sztorc via bitcoin-dev
"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?

Paul Sztorc via bitcoin-dev

2017-05-23 14:22:43 UTC

Post by Paul Sztorc via bitcoin-dev
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'.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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".

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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

Chris Stewart via bitcoin-dev

2017-06-18 14:36:24 UTC

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 <

Post by Paul Sztorc via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

CryptAxe via bitcoin-dev

2017-06-18 21:27:52 UTC

OP_RETURN <sidechain_id> <critical hash>

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.

Post by Chris Stewart via bitcoin-dev
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

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.

Post by Chris Stewart via bitcoin-dev
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.

Post by Chris Stewart via bitcoin-dev
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?
<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?

Chris Stewart via bitcoin-dev

2017-06-19 15:41:01 UTC

Post by CryptAxe via bitcoin-dev

Post by CryptAxe via bitcoin-dev
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 /

Post by CryptAxe via bitcoin-dev
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.

Post by CryptAxe via bitcoin-dev
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.

Post by CryptAxe via bitcoin-dev
Since the sidechain has the sidechain BMM headers that they want the LD

Post by CryptAxe via bitcoin-dev
(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
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 /

Post by CryptAxe via bitcoin-dev
only requesting the verification of LD data that they know to be valid
as far as chain order goes.

Post by CryptAxe via bitcoin-dev
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 <

OP_RETURN <sidechain_id> <critical hash>

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.

Agreed, we need that.

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

Post by Chris Stewart via bitcoin-dev
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.

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

ZmnSCPxj via bitcoin-dev

2017-05-23 00:13:55 UTC

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.

Post by ZmnSCPxj via bitcoin-dev
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.

Post by ZmnSCPxj via bitcoin-dev
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?

Post by ZmnSCPxj via bitcoin-dev
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?

Post by ZmnSCPxj via bitcoin-dev
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

Paul Sztorc via bitcoin-dev

2017-05-23 14:12:24 UTC

Post by ZmnSCPxj via bitcoin-dev
Good morning,

Post by Paul Sztorc via bitcoin-dev
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

Post by ZmnSCPxj via bitcoin-dev
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.

Post by ZmnSCPxj via bitcoin-dev
(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.

Post by ZmnSCPxj via bitcoin-dev
Is OP_BRIBE the same as the OP_h_is_in_coinbase operation you described?

Yes. Sorry if that was confusing.

Post by ZmnSCPxj via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by ZmnSCPxj via bitcoin-dev
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

Post by Paul Sztorc via bitcoin-dev
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.

Post by ZmnSCPxj via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by ZmnSCPxj via bitcoin-dev
Blind merged mining seems strictly inferior ... a rich attacker can

simply reorg the sidechain outright without playing such games.

Post by Paul Sztorc via bitcoin-dev
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?".

Post by ZmnSCPxj via bitcoin-dev
How does your proposal handle multiple side block creators on the same

sidechain, with the possibility that chain splits occur?

Post by Paul Sztorc via bitcoin-dev
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.

Post by ZmnSCPxj via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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

Paul Sztorc via bitcoin-dev

2017-06-10 17:04:10 UTC

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

Post by Paul Sztorc via bitcoin-dev
Dear list,
I've been working on "drivechain", a sidechain enabling technology, for
some time.
* The technical info site is here: www.drivechain.info
https://github.com/drivechain-project/bitcoin/tree/mainchainBMM
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]
http://youtu.be/YErLEuOi3xU

Tao Effect via bitcoin-dev

2017-06-18 21:30:51 UTC

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.

Post by Paul Sztorc via bitcoin-dev
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
---------------------------
* 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).
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>

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

Paul Sztorc via bitcoin-dev

2017-06-19 16:04:33 UTC

Hi Greg,

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
... 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.

Post by Tao Effect via bitcoin-dev
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]

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

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
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

Paul Sztorc via bitcoin-dev

2017-06-20 11:54:52 UTC

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

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
Hi Greg,

Post by Tao Effect via bitcoin-dev
In Drivechain, 51% of miners have total control and ownership

over all

Post by Tao Effect via bitcoin-dev
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.
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.

Post by Tao Effect via bitcoin-dev
Thus the effect of Drivechain appears to be the creation of a

new kind

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
... where everyone hands over ownership of their Bitcoins to a
/single/ mining cartel when they wish to interact with /any/ sidechain.

exactly

Post by Tao Effect via bitcoin-dev
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
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]
http://youtu.be/0goYH2sDw0w
http://youtu.be/0goYH2sDw0w
[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/>

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
3. Drivechain limits user's existing choice when it comes to who is
acting as custodian of their Bitcoins, from any trustworthy

exchange,

Post by Tao Effect via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

Erik Aronesty via bitcoin-dev

2017-06-20 13:38:59 UTC

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

Post by Paul Sztorc via bitcoin-dev
Hi Erik,
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
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 <

Post by Paul Sztorc via bitcoin-dev
Hi Greg,

Post by Tao Effect via bitcoin-dev
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.
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.

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
... where everyone hands over ownership of their Bitcoins to a
/single/ mining cartel when they wish to interact with /any/ sidechain.

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
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]
http://youtu.be/0goYH2sDw0w
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/

Post by Tao Effect via bitcoin-dev
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.

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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Paul Sztorc via bitcoin-dev

2017-06-22 13:27:25 UTC

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

Post by Erik Aronesty via bitcoin-dev
- 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.
Hi Erik,
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

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.

Erik Aronesty via bitcoin-dev

2017-06-22 13:45:33 UTC

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.

Post by Paul Sztorc via bitcoin-dev
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
- 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.

Paul Sztorc via bitcoin-dev

2017-06-22 20:30:39 UTC

Responses inline.

Post by Erik Aronesty via bitcoin-dev
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.

Post by Erik Aronesty via bitcoin-dev
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.

Post by Erik Aronesty via bitcoin-dev
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

Post by Erik Aronesty via bitcoin-dev
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

Post by Erik Aronesty via bitcoin-dev
- 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.
Hi Erik,
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

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.

Erik Aronesty via bitcoin-dev

2017-06-23 14:19:18 UTC

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
Responses inline.
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

Post by Paul Sztorc via bitcoin-dev
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
- 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.

Moral Agent via bitcoin-dev

2017-06-23 14:51:20 UTC

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 <

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
Responses inline.
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

Post by Paul Sztorc via bitcoin-dev
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
- 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.

Post by Paul Sztorc via bitcoin-dev
Hi Erik,
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Paul Sztorc via bitcoin-dev

2017-06-23 18:11:26 UTC

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

Post by Paul Sztorc via bitcoin-dev
Responses inline.

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

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

Post by Erik Aronesty via bitcoin-dev
- 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
Hi Erik,
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

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.

Tao Effect via bitcoin-dev

2017-07-12 22:43:31 UTC

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]).

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

Hi Greg,

Post by Tao Effect via bitcoin-dev
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.. ]

Paul Sztorc via bitcoin-dev

2017-07-13 00:26:56 UTC

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.

Post by Tao Effect via bitcoin-dev
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).

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
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

Tao Effect via bitcoin-dev

2017-07-13 01:15:46 UTC

Paul,

Post by Paul Sztorc via bitcoin-dev
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?

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
Again, from the perspective of a mainchain user, every withdrawal is valid.

And that is not how P2SH works.

Post by Paul Sztorc via bitcoin-dev
[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.

Post by Paul Sztorc via bitcoin-dev
The confusion below stems from his conflation of several different ideas.
[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.

Post by Tao Effect via bitcoin-dev
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).

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
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

Paul Sztorc via bitcoin-dev

2017-07-13 02:58:48 UTC

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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.
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.

Post by Paul Sztorc via bitcoin-dev
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).

Post by Paul Sztorc via bitcoin-dev
[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.

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.

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

Post by Tao Effect via bitcoin-dev
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".

Post by Tao Effect via bitcoin-dev
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

Post by Paul Sztorc via bitcoin-dev
The confusion below stems from his conflation of several different ideas.
I will try to explicitly clarify a distinction between several types
[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.

Post by Tao Effect via bitcoin-dev
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).

Post by Tao Effect via bitcoin-dev
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.

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.

Post by Tao Effect via bitcoin-dev
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

Tao Effect via bitcoin-dev

2017-07-13 03:24:10 UTC

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.

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.

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
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.

I will repeat that Drivechain can sometimes be confusing because it is different things to different people.
[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.

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.

Post by Tao Effect via bitcoin-dev
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.

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

Post by Paul Sztorc via bitcoin-dev
Again, from the perspective of a mainchain user, every withdrawal is valid.

And that is not how P2SH works.

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

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.

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.

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

Post by Tao Effect via bitcoin-dev
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".

Post by Tao Effect via bitcoin-dev
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

Paul Sztorc via bitcoin-dev

2017-07-13 15:39:00 UTC

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

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
Dear Paul,

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Paul Sztorc via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
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.

Post by Tao Effect via bitcoin-dev
I've finally collected all my thoughts / concerns and have also
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

Hampus Sjöberg via bitcoin-dev

2017-07-13 13:17:13 UTC

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 <

Post by Paul Sztorc via bitcoin-dev
I will repeat that Drivechain can sometimes be confusing because it is
different things to different people.
[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.
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.
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.
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
The confusion below stems from his conflation of several different ideas.
I will try to explicitly clarify a distinction between several types of
[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.
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Paul Sztorc via bitcoin-dev

2017-07-13 17:04:01 UTC