I've been working on "drivechain", a sidechain enabling technology, forsome 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 variousconferences and meetups over the past year, most prominently ScalingMilan. And I intend to continue to seek feedback at Consensus2017 thisweek, 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 washesitant because I try not to consume reviewers' scarce time until theauthor has put in a serious effort. However, I may have waiting toolong, as today it is actually quite close to a working release.

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

This upgrade would have significant scaling implications. Since it isthe case that sidechains can be added by soft fork, and since each ofthese chains will have its own blockspace, this theoretically removesthe blocksize limit from "the Bitcoin system" (if one includessidechains as part of such a system). People who want a LargeBlockbitcoin can just move their BTC over to such a network [1], and theirtxns will have no longer have an impact on "Bitcoin Core". Thus, eventhough this upgrade does not actually increase "scalability" per se, itmay 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-minethese "drivechains", even if these miners aren't running the actualsidechain software. The goal is to prevent sidechains from affecting thelevelness of the mining "playing field". BMM is conceptually similar toZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is notrequired for drivechain, but it would address some of the last remainingconcerns.

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

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

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

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

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

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

Unfortunately, anyone who worked on the "first generation" of sidechaintechnology (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 thatinvolves scalability. It is often said that "talking politics lowersyour IQ by 25 points". Bitcoin scalability conversations seem to drain50 points. (Instead of conversing, I think people should quietly work onwhatever they are passionate about until their problem either is solved,or it goes away for some other reason, or until we all agree to juststop talking about it.)

Post by Paul Sztorc via bitcoin-devThis work includes the relatively new concept of "Blind Merged Mining"[2] which I developed in January to allow SHA256^2 miners to merge-minethese "drivechains", even if these miners aren't running the actualsidechain software. The goal is to prevent sidechains from affecting thelevelness of the mining "playing field". BMM is conceptually similar toZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is notrequired for drivechain, but it would address some of the last remainingconcerns.

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

As you state in [2] "if miners never validate sidechains at all, whoever bidsthe most for the chain (on a continuous basis), can spam a 3-month long streamof invalid headers, and then withdraw all of the coins deposited to thesidechain." and "Since the mining is blind, and the sidechain-withdrawalsecurity-level is SPV, miners who remain blind forever have no way of tellingwho âshouldâ really get the funds."

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

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

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

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

Post by Paul Sztorc via bitcoin-devThis work includes the relatively new concept of "Blind Merged Mining"[2] which I developed in January to allow SHA256^2 miners to merge-minethese "drivechains", even if these miners aren't running the actualsidechain software. The goal is to prevent sidechains from affecting thelevelness of the mining "playing field". BMM is conceptually similar toZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is notrequired for drivechain, but it would address some of the last remainingconcerns.

Thanks for the credit, although I think the security properties of whatyou'reproposing are very different - and much weaker - than what I proposed inZookeyv.

As you state in [2] "if miners never validate sidechains at all, whoeverbidsthe most for the chain (on a continuous basis), can spam a 3-month longstreamof invalid headers, and then withdraw all of the coins deposited to thesidechain." and "Since the mining is blind, and the sidechain-withdrawalsecurity-level is SPV, miners who remain blind forever have no way oftellingwho âshouldâ really get the funds."

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

Surprisingly, this requirement (or, more precisely, this incentive) doesnot effect miners relative to each other. The incentive to upgrade is onlyfor the purpose of preventing a "theft" -- defined as: an improperwithdrawal from a sidechain. It is not about miner revenues or the abilityto mine generally (or conduct BMM specifically). The costs of such a theft(decrease in market price, decrease in future transaction fee levels) wouldbe shared collectively by all future miners. Therefore, it would have noeffect 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 withdrawalsthat they don't understand. This would pause the withdraw process untilenough 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 iscorrect or not. It is up to users to decide if they are comfortable withthese 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. Couldyou explain in more detail what that incentive is?

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

Post by Paul Sztorc via bitcoin-devSurprisingly, this requirement (or, more precisely, this incentive) doesnot effect miners relative to each other. The incentive to upgrade is onlyfor the purpose of preventing a "theft" -- defined as: an improperwithdrawal from a sidechain. It is not about miner revenues or the abilityto mine generally (or conduct BMM specifically). The costs of such a theft(decrease in market price, decrease in future transaction fee levels) wouldbe shared collectively by all future miners. Therefore, it would have noeffect on miners relative to each other.

That's not at all true. If I'm a miner with a better capability than anotherminer to prevent that theft, I have reasons to induce it to happen to give mepolitical 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 somethingthat wasn't possible in a geninely decrentralized system: safe zeroconftransactions.

Post by Paul Sztorc via bitcoin-devMoreover, miners have other recourse if they are unable to run the node.They can adopt a policy of simply rejecting ("downvoting") any withdrawalsthat they don't understand. This would pause the withdraw process untilenough 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 allwithdrawals is preventing users' from getting their money, which gives otherminers a rational for kicking those miners off of Bitcoin entirely.

Post by Paul Sztorc via bitcoin-devFinally, 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 iscorrect or not. It is up to users to decide if they are comfortable withthese risks, if/when they decide to deposit to a sidechain.

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

Post by Paul Sztorc via bitcoin-devIt is a matter of comparing the costs and benefits. Ignoring theft, thecosts are near-zero, and the benefits are >0. Specifically, they are: ahigher BTC price and greater transaction fees. Theft is discouraged byattempting to tie a theft to a loss of confidence in the miners, asdescribed 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 drivechainsfail, given the huge risks involved. I would also argue that users should douser-activated-soft-forks to ensure they fail.

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

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

Seems to me an obvious use case for drive chains are to have high speedsmall 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 sidechain, like Liquid or lightning.

On May 28, 2017 5:23 PM, "Peter Todd via bitcoin-dev" <

Post by Paul Sztorc via bitcoin-devSurprisingly, this requirement (or, more precisely, this incentive) doesnot effect miners relative to each other. The incentive to upgrade is onlyfor the purpose of preventing a "theft" -- defined as: an improperwithdrawal from a sidechain. It is not about miner revenues or the abilityto mine generally (or conduct BMM specifically). The costs of such a theft(decrease in market price, decrease in future transaction fee levels) wouldbe shared collectively by all future miners. Therefore, it would have noeffect on miners relative to each other.

That's not at all true. If I'm a miner with a better capability than anotherminer to prevent that theft, I have reasons to induce it to happen to givemepolitical 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 guaranteesomethingthat wasn't possible in a geninely decrentralized system: safe zeroconftransactions.

Post by Paul Sztorc via bitcoin-devMoreover, miners have other recourse if they are unable to run the node.They can adopt a policy of simply rejecting ("downvoting") any withdrawalsthat they don't understand. This would pause the withdraw process untilenough 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 allwithdrawals is preventing users' from getting their money, which gives otherminers a rational for kicking those miners off of Bitcoin entirely.

Post by Paul Sztorc via bitcoin-devFinally, 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 iscorrect or not. It is up to users to decide if they are comfortable withthese risks, if/when they decide to deposit to a sidechain.

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

Post by Paul Sztorc via bitcoin-devIt is a matter of comparing the costs and benefits. Ignoring theft, thecosts are near-zero, and the benefits are >0. Specifically, they are: ahigher BTC price and greater transaction fees. Theft is discouraged byattempting to tie a theft to a loss of confidence in the miners, asdescribed 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 ismuch*more* valuable if miners do everything they can to ensure that drivechainsfail, given the huge risks involved. I would also argue that users should douser-activated-soft-forks to ensure they fail.

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

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

Post by Paul Sztorc via bitcoin-devSurprisingly, this requirement (or, more precisely, this incentive) doesnot effect miners relative to each other. The incentive to upgrade is onlyfor the purpose of preventing a "theft" -- defined as: an improperwithdrawal from a sidechain. It is not about miner revenues or the abilityto mine generally (or conduct BMM specifically). The costs of such a theft(decrease in market price, decrease in future transaction fee levels) wouldbe shared collectively by all future miners. Therefore, it would have noeffect on miners relative to each other.

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

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

As you say, a 51% group can arbitrarily start orphaning the blocks thatare 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-devThis 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 somethingthat wasn't possible in a geninely decrentralized system: safe zeroconftransactions.

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

Post by Paul Sztorc via bitcoin-devMoreover, miners have other recourse if they are unable to run the node.They can adopt a policy of simply rejecting ("downvoting") any withdrawalsthat they don't understand. This would pause the withdraw process untilenough 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 somerules that they themselves construct (for example, a nuclearnon-proliferation treaty).

In this case, miners prefer sidechains to exist (as existence makes theBTC 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-devEqually, you're opening up miners to huge political risks, as rejecting allwithdrawals is preventing users' from getting their money, which gives otherminers a rational for kicking those miners off of Bitcoin entirely.

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

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

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

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

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

Post by Paul Sztorc via bitcoin-devFinally, 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 iscorrect or not. It is up to users to decide if they are comfortable withthese risks, if/when they decide to deposit to a sidechain.

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

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

Post by Paul Sztorc via bitcoin-devIt is a matter of comparing the costs and benefits. Ignoring theft, thecosts are near-zero, and the benefits are >0. Specifically, they are: ahigher BTC price and greater transaction fees. Theft is discouraged byattempting to tie a theft to a loss of confidence in the miners, asdescribed 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 drivechainsfail, given the huge risks involved.

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

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

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

Empirically, I have observed overwhelming support for sidechains amongusers, business, and other developers. The btc-investors I spoke to wereall very excited about the prospect of sidechains, even more so thanthey were excited about SegWit.

Post by Peter Todd via bitcoin-devBy comparison, note Adam Back and my own efforts to ensure miners have asmaller part in the ecosystem, with things like committed (encrypted)transactions and my closed-seal-set/truth-list approach(1). We want to involveminers as little as possible in the consensus, not more.

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

And, I repeat, for regular users of Bitcoin Core, drivechain does notmake 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) forBitcoin to filter out harmful interactions among txns (in other words,good for miners to filter out double spends), I have discoveredsituations where it is beneficial and essential for miners to filter outharmful interactions among multiple chains.

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 sellhis/her BTC in exchange for an Altcoin (or for fiat), we can hardly denyusers the opportunity to move their money between two sidechains."

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

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

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

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

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

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

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

In this proposal, the "poll" time is sidechain-configurable, and I proposeda 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 transfersin this code, you still can. However a better dynamic cache of acks/nackswould be needed. However, for the hybrid use-case, one day is more thanenough.

Miners can abstain from 'voting', which is politically neutral. Or, ifthey wish, smaller miners could acquiesce to the coercion and just copythe votes of the attacking 51% group. For users who are only runningBitcoin Core, there is nothing bad about that.As you say, a 51% group can arbitrarily start orphaning the blocks thatare 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 Paul Sztorc via bitcoin-devthat they don't understand. This would pause the withdraw process untilenough 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 somerules that they themselves construct (for example, a nuclearnon-proliferation treaty).In this case, miners prefer sidechains to exist (as existence makes theBTC 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 ispolitically neutral, or else they can delegate their vote to anaggressive miner. The "51% can orphan" concern could be raised, even ina world without drivechain. All that is required, is for the miners tobe anonymous, or in private 'dark' pools (and to thereby escape censure).But there is a much bigger issue here, which is that our threat modelsare different.As you may know, my threat model [1] does not include miners "pushingeach other off". It only cares about the miner-experience, to the extentthat it impacts the user-experience.Moreover, I reject [2] the premise that we can even measure "minercentralization", or even that such a concept exists. If someone has adefinition of this concept, which is both measurable and useful, I wouldbe interested to read it.( For what it's worth, Satoshi did not care about this, either. Forexample: "If a greedy attacker is able to assemble more CPU power thanall the honest nodes, he...ought to find it more profitable to play bythe 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 tovalidate the drivechain have every reason to make these events more

frequent.It is part of the spec. These timing parameters must be agreed upon whenthe sidechain is added, ie _before_ users deposit to the sidechain. Oncethe sidechain is created, the timing is enforced by nodes, the same aswith any other protocol rules. Miner-validation-ability has no effect onthe frequency.

Post by Paul Sztorc via bitcoin-devIt is a matter of comparing the costs and benefits. Ignoring theft, thecosts are near-zero, and the benefits are >0. Specifically, they are: ahigher BTC price and greater transaction fees. Theft is discouraged byattempting to tie a theft to a loss of confidence in the miners, asdescribed 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

I don't see how. Users are free to ignore the sidechain, so it can onlybenefit them.Fortunately for you, if that is actually what miners believe, then therewill be no problem, as miners will just filter out drivechains (so thatBitcoin will be "much *more* valuable"), which they can easily do.

Again, I don't think that kind of UASF can succeed, because one optionstrictly dominates the other. But the users get the final say, of course.Empirically, I have observed overwhelming support for sidechains amongusers, business, and other developers. The btc-investors I spoke to wereall very excited about the prospect of sidechains, even more so thanthey were excited about SegWit.

Post by Peter Todd via bitcoin-devBy comparison, note Adam Back and my own efforts to ensure miners have asmaller part in the ecosystem, with things like committed (encrypted)transactions and my closed-seal-set/truth-list approach(1). We want to

I agree that miners should have as little influence as possible (andthey probably agree, as well). But a 51% group can filter any messagethey like from the blockchain. For sidechains, there will need to be twopublic networks, so concealment is not an option.And, I repeat, for regular users of Bitcoin Core, drivechain does notmake 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) forBitcoin to filter out harmful interactions among txns (in other words,good for miners to filter out double spends), I have discoveredsituations where it is beneficial and essential for miners to filter outharmful 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

can'thttp://www.drivechain.info/projects/index.htmlAnd, as I say on the FAQ, "If each individual user is free to sellhis/her BTC in exchange for an Altcoin (or for fiat), we can hardly denyusers the opportunity to move their money between two sidechains."So, in a strong way, the entire altcoin market makes the case for ausefulness of sidechains. Bitcoin is a form of money, and only one formof money can exist per currency area. So, if Bitcoin is not the winner,it will eventually cease to exist altogether. Altcoin-competition is anexistential threat to Bitcoin, one which is far more relevant thananything you've presented so far.Secondly, one important value of permissionless innovation is that onedoesn't really know, today, what cool ideas other people are going tocome up with tomorrow. If you did, they'd be today's ideas.Third, Core's review process has two opposite problems: on one hand itis slow and grueling, and on the other it is fraught with thepossibility of catastrophic error. It would be better, for everyone, toallow people to try their own (non-aggressive) experiments, and to maketheir own mistakes. Already, I have seen the review process abused tocreate/maintain fiefdoms of expertise, so that the abusers can extractmoney from clients/employers/VCs.Just think of all of the free time you would have, Peter, if you didn'thave to spend it all reviewing these projects!

? How is drivechain _not_ within the category of client-side validation?With BMM, validation is only performed by those users ("clients") whoopt-in to the new features. The economic model of BMM is directlycomparable to that of Bitcoin's PoW -- the highest-bid chain should bethe healthiest one.Can you post the Github link for your most up-to-date client-sidevalidation work so that we can compare the safety and other features?Thanks,Paul

As some of you may know, Sergio and I each did an implementation ofdrivechain. 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-checkour work. For example, this already happened wrt the "ACK size". Let meshare from his linked BIP:

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

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

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

In general, Sergio and I disagree over the withdrawal-frequency. a majordifference of opinion is over the withdrawal-frequency. I viewinfrequent withdrawal as essential to the security model, but Sergiodoes not. In both our designs, the withdrawal-time is configurable, butSergio's design seems to be optimized for cases with frequent withdrawalattempts, whereas mine is optimized for cases with very infrequentwithdrawal attempts.

Another difference is that, as a direct result of earlier peer review, Ihave been integrating 'blind merged mining' into my version. It may beeasy 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 notmake use of the multisig / centralized part, and so for me itcomplicates the security properties for no benefit. I see why somepeople are interested in it, though.

Paul

Post by Sergio Demian Lerner via bitcoin-devI'm a bit late to this party. I just want to add that there exists anhybrid 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 particularuse-case, which I'm not sure Paul's proposal enable.The proposal is on this list under the following subject: Drivechainproposal using OP_COUNT_ACKShttps://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 Iproposed 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->mainchaintransfers in this code, you still can. However a better dynamic cache ofacks/nacks would be needed. However, for the hybrid use-case, one day ismore than enough.RegardsOn Tue, May 30, 2017 at 2:11 AM, Paul Sztorc via bitcoin-devHi Peter,Responses below.

Post by Paul Sztorc via bitcoin-devSurprisingly, this requirement (or, more precisely, this incentive) doesnot effect miners relative to each other. The incentive to upgrade is onlyfor the purpose of preventing a "theft" -- defined as: an improperwithdrawal from a sidechain. It is not about miner revenues or the abilityto mine generally (or conduct BMM specifically). The costs of such a theft(decrease in market price, decrease in future transaction fee levels) wouldbe shared collectively by all future miners. Therefore, it would have noeffect on miners relative to each other.

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

Miners can abstain from 'voting', which is politically neutral. Or, ifthey wish, smaller miners could acquiesce to the coercion and just copythe votes of the attacking 51% group. For users who are only runningBitcoin Core, there is nothing bad about that.As you say, a 51% group can arbitrarily start orphaning the blocks thatare 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-devThis 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 somethingthat wasn't possible in a geninely decrentralized system: safe zeroconftransactions.

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

Post by Paul Sztorc via bitcoin-devMoreover, miners have other recourse if they are unable to run the node.They can adopt a policy of simply rejecting ("downvoting") any withdrawalsthat they don't understand. This would pause the withdraw process untilenough 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 somerules that they themselves construct (for example, a nuclearnon-proliferation treaty).In this case, miners prefer sidechains to exist (as existence makes theBTC 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-devEqually, you're opening up miners to huge political risks, as rejecting allwithdrawals is preventing users' from getting their money, which gives otherminers a rational for kicking those miners off of Bitcoin entirely.

As I explained above, miners can abstain from voting, which ispolitically neutral, or else they can delegate their vote to anaggressive miner. The "51% can orphan" concern could be raised, even ina world without drivechain. All that is required, is for the miners tobe anonymous, or in private 'dark' pools (and to thereby escape censure).But there is a much bigger issue here, which is that our threat modelsare different.As you may know, my threat model [1] does not include miners "pushingeach other off". It only cares about the miner-experience, to the extentthat it impacts the user-experience.Moreover, I reject [2] the premise that we can even measure "minercentralization", or even that such a concept exists. If someone has adefinition of this concept, which is both measurable and useful, I wouldbe interested to read it.( For what it's worth, Satoshi did not care about this, either. Forexample: "If a greedy attacker is able to assemble more CPU power thanall the honest nodes, he...ought to find it more profitable to play bythe 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/>

Post by Paul Sztorc via bitcoin-devFinally, 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 iscorrect or not. It is up to users to decide if they are comfortable withthese risks, if/when they decide to deposit to a sidechain.

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

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

Post by Paul Sztorc via bitcoin-devIt is a matter of comparing the costs and benefits. Ignoring theft, thecosts are near-zero, and the benefits are >0. Specifically, they are: ahigher BTC price and greater transaction fees. Theft is discouraged byattempting to tie a theft to a loss of confidence in the miners, asdescribed 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 drivechainsfail, given the huge risks involved.

I don't see how. Users are free to ignore the sidechain, so it can onlybenefit them.Fortunately for you, if that is actually what miners believe, then therewill be no problem, as miners will just filter out drivechains (so thatBitcoin will be "much *more* valuable"), which they can easily do.

Again, I don't think that kind of UASF can succeed, because one optionstrictly dominates the other. But the users get the final say, of course.Empirically, I have observed overwhelming support for sidechains amongusers, business, and other developers. The btc-investors I spoke to wereall very excited about the prospect of sidechains, even more so thanthey were excited about SegWit.

Post by Peter Todd via bitcoin-devBy comparison, note Adam Back and my own efforts to ensure miners have asmaller part in the ecosystem, with things like committed (encrypted)transactions and my closed-seal-set/truth-list approach(1). We want to involveminers as little as possible in the consensus, not more.

I agree that miners should have as little influence as possible (andthey probably agree, as well). But a 51% group can filter any messagethey like from the blockchain. For sidechains, there will need to be twopublic networks, so concealment is not an option.And, I repeat, for regular users of Bitcoin Core, drivechain does notmake 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) forBitcoin to filter out harmful interactions among txns (in other words,good for miners to filter out double spends), I have discoveredsituations where it is beneficial and essential for miners to filter outharmful 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>

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 sellhis/her BTC in exchange for an Altcoin (or for fiat), we can hardly denyusers the opportunity to move their money between two sidechains."So, in a strong way, the entire altcoin market makes the case for ausefulness of sidechains. Bitcoin is a form of money, and only one formof money can exist per currency area. So, if Bitcoin is not the winner,it will eventually cease to exist altogether. Altcoin-competition is anexistential threat to Bitcoin, one which is far more relevant thananything you've presented so far.Secondly, one important value of permissionless innovation is that onedoesn't really know, today, what cool ideas other people are going tocome up with tomorrow. If you did, they'd be today's ideas.Third, Core's review process has two opposite problems: on one hand itis slow and grueling, and on the other it is fraught with thepossibility of catastrophic error. It would be better, for everyone, toallow people to try their own (non-aggressive) experiments, and to maketheir own mistakes. Already, I have seen the review process abused tocreate/maintain fiefdoms of expertise, so that the abusers can extractmoney from clients/employers/VCs.Just think of all of the free time you would have, Peter, if you didn'thave to spend it all reviewing these projects!

? How is drivechain _not_ within the category of client-side validation?With BMM, validation is only performed by those users ("clients") whoopt-in to the new features. The economic model of BMM is directlycomparable to that of Bitcoin's PoW -- the highest-bid chain should bethe healthiest one.Can you post the Github link for your most up-to-date client-sidevalidation work so that we can compare the safety and other features?Thanks,Paul

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.

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.

I've been working on "drivechain", a sidechain enabling technology, forsome 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 variousconferences and meetups over the past year, most prominently ScalingMilan. And I intend to continue to seek feedback at Consensus2017 thisweek, 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 washesitant because I try not to consume reviewers' scarce time until theauthor has put in a serious effort. However, I may have waiting toolong, as today it is actually quite close to a working release.

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

This upgrade would have significant scaling implications. Since it isthe case that sidechains can be added by soft fork, and since each ofthese chains will have its own blockspace, this theoretically removesthe blocksize limit from "the Bitcoin system" (if one includessidechains as part of such a system). People who want a LargeBlockbitcoin can just move their BTC over to such a network [1], and theirtxns will have no longer have an impact on "Bitcoin Core". Thus, eventhough this upgrade does not actually increase "scalability" per se, itmay 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-minethese "drivechains", even if these miners aren't running the actualsidechain software. The goal is to prevent sidechains from affecting thelevelness of the mining "playing field". BMM is conceptually similar toZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is notrequired for drivechain, but it would address some of the last remainingconcerns.

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

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

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

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

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

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

Unfortunately, anyone who worked on the "first generation" of sidechaintechnology (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 thatinvolves scalability. It is often said that "talking politics lowersyour IQ by 25 points". Bitcoin scalability conversations seem to drain50 points. (Instead of conversing, I think people should quietly work onwhatever they are passionate about until their problem either is solved,or it goes away for some other reason, or until we all agree to juststop talking about it.)

From just this document, I can't see a good justification for believingthat a main->side locking transaction can be safely spent into a side->mainunlocking 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 thenotes (at the bottom of the BMM post) or the code, although this is timeconsuming 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 noticethat, for the second withdrawal, the sum of the inputs is less than the sumof the outputs and they the transaction is therefore invalid.

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

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

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

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

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

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

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

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

Not at all.

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

The side block is only "mined" if it is committed to in a mainchain Bitcoinblog, and each mainchain block can only contain one block per sidechain. Inthis way, drivechain sidechains are different from classical Namecoinmerged 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 issuewith miners blindly accepting sidechain commitments is that it violates"Don't trust, verify", not that allows datacenters to be slightly smallerby not including side:nodes.

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

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

I've been working on "drivechain", a sidechain enabling technology, forsome 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 variousconferences and meetups over the past year, most prominently ScalingMilan. And I intend to continue to seek feedback at Consensus2017 thisweek, 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 washesitant because I try not to consume reviewers' scarce time until theauthor has put in a serious effort. However, I may have waiting toolong, as today it is actually quite close to a working release.

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

This upgrade would have significant scaling implications. Since it isthe case that sidechains can be added by soft fork, and since each ofthese chains will have its own blockspace, this theoretically removesthe blocksize limit from "the Bitcoin system" (if one includessidechains as part of such a system). People who want a LargeBlockbitcoin can just move their BTC over to such a network [1], and theirtxns will have no longer have an impact on "Bitcoin Core". Thus, eventhough this upgrade does not actually increase "scalability" per se, itmay 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-minethese "drivechains", even if these miners aren't running the actualsidechain software. The goal is to prevent sidechains from affecting thelevelness of the mining "playing field". BMM is conceptually similar toZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is notrequired for drivechain, but it would address some of the last remainingconcerns.

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

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

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

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

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

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

Unfortunately, anyone who worked on the "first generation" of sidechaintechnology (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 thatinvolves scalability. It is often said that "talking politics lowersyour IQ by 25 points". Bitcoin scalability conversations seem to drain50 points. (Instead of conversing, I think people should quietly work onwhatever they are passionate about until their problem either is solved,or it goes away for some other reason, or until we all agree to juststop talking about it.)

With Bitcoin, you only get to reverse recent transactions. If you actuallyreversed 2-3 weeks of transactions, then the Bitcoin price would fall,destroying the value of the additional coins you managed to obtain. Evenif 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, thenthat doesn't affect the value of the bitcoins you manage to steal.

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

If the side chain pays x in fees, then at most x/10 can be transferred fromthe side chain to the main chain. This means that someone who pays forblock 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 anarchive node for the side chain in a different data center.

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

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

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

The big difference is that Bitcoin holds no assets on another chain. Aside-chain's value is directly linked to the fact that it has 100% reserveson the Bitcoin main chain. That can be targeted for theft.

With Bitcoin, you only get to reverse recent transactions. If you actuallyreversed 2-3 weeks of transactions, then the Bitcoin price would fall,destroying the value of the additional coins you managed to obtain. Evenif 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 todouble-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, thenthat doesn't affect the value of the bitcoins you manage to steal.

It may destroy great value if it shakes confidence in the sidechaininfrastructure. Thus, the value of the stolen BTC may decrease, in additionto 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 impactBitcoin's value. It is therefore desirable for miners to steal from chainsthat provide no value-add.

The big difference is that Bitcoin holds no assets on another chain. Aside-chain's value is directly linked to the fact that it has 100% reserveson 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".

With double spending, you can only get ownership of coins that you owned atsome point in the past. Coins that are owned by someone else from coinbaseto their current owners cannot be stolen by a re-org (though they can bemoved around).

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

Post by Paul Sztorc via bitcoin-devIt may destroy great value if it shakes confidence in the sidechaininfrastructure. Thus, the value of the stolen BTC may decrease, in additionto 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, thenshaking confidence in a side-chain would shake confidence in Bitcoin'sfuture.

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

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

Again, I don't really think it is that different. One could interchange

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

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

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

If the first attacker who tries it fails (say after creating a fork that is90% of the length required, so losing a lot of money), then it woulddiscourage others. If he succeeds, then it weakens sidechains as aconcept 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 onthe sidechain, they could try to outbid the attacker.

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

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

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

Post by Paul Sztorc via bitcoin-devI would replace "Bitcoins you manage to steal" with "Bitcoins youmanage to double-spend". Then, it still seems the same to me.With double spending, you can only get ownership of coins that you ownedat some point in the past. Coins that are owned by someone else fromcoinbase to their current owners cannot be stolen by a re-org (thoughthey can be moved around).

I'm not sure it makes much of a difference. First of all, in point offact, the miners themselves own the coins from the coinbase. But moreimportantly, even if miners did not explicitly own the coins, they mightprofit by being bribed -- these bribes would come from people who didown 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 valueproportional to 'v'.

Post by Paul Sztorc via bitcoin-devWith BMM, you can take the entire reserve. Creating a group of doublespenders can help increase the reward.It may destroy great value if it shakes confidence in the sidechaininfrastructure. Thus, the value of the stolen BTC may decrease, inaddition 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, thenshaking confidence in a side-chain would shake confidence in Bitcoin'sfuture.

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

What do you think of my argument, that we already labor under such anassumption? An attacker could pay fees today equal to greater thansum(blockreward_(last N block)). According to you this would force areorg, even on mainchain (pre-sidechain) Bitcoin. Yet this has neverhappened.

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

Post by Paul Sztorc via bitcoin-devIf (average fees) * (timeout) is less than the total reserves, then itis worth it for a 3rd party to just bid for his theft fork. Minersdon't have to be assumed to be coordinating, they just have to beassumed to take the highest bid.Again, I don't really think it is that different. One couldinterchange "recent txns" (those which could be double-spent within2-3 weeks) with "sidechain deposit tnxs".It is not "recent txns", it is recent txns that you (or your group) havethe key for. No coordination is required to steal the entire reservefrom the sidechain.

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

Post by Paul Sztorc via bitcoin-devRecent txns and money on the sidechain have the property that they areriskier than money deep on the main chain. This is the inherent pointabout sidechains, so maybe not that big a deal.

Yes. Sidechains have newer, more interesting features, andsimultaneously more risk.

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

Post by Paul Sztorc via bitcoin-devIf the first attacker who tries it fails (say after creating a fork thatis 90% of the length required, so losing a lot of money), then it woulddiscourage others. If he succeeds, then it weakens sidechains as aconcept 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 moneyon the sidechain, they could try to outbid the attacker.

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

Post by Paul Sztorc via bitcoin-devIn fact, since the attacker, by definition, creates an illegal fork, theeffect is that he reduces the block rate for the side chain (possibly tozero, if he wins every auction). This means that there are moretransactions 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 paymore per block, weakening his attack. This is similar to wheretransaction spam on Bitcoin is self-correcting by increasing the feesrequired to keep the spam going.Is there a description of the actual implementation you decided to gowith, other than the code?

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

I think it is redundant here to have the <sidechain id>, we can implicitlyassume 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 upgradethis commitment structure in the future. Similar to how witness program'sare now versioned.

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

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

Overall, I think we need to work on the commitment structure to thecoinbase tx. If I understand the current implementation correctly we canhave up to 256 OP_RETURNs embedded in the coinbase tx signifying new blocksmined on drivechains.. this seems less than ideal. It might be prudent tomake these outputs ANYONECANSPEND, and then have miners spending theseoutputs to themselves for every block mined.. maybe this doesn't have abenefit 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 UTXOset -- maybe this scheme doesn't have any benefit.

I guess I was looking for the detail you get in the code, but withouthaving to read the code.My quick reading gives that the sidechain codes (critical hashes) areadded when a coinbase is processed.Any coinbase output that has the form "OP_RETURN <32 byte push>" counts asa potential critical hash.When the block is processed, the key value pair (hash, block_height) isadded to a hash map.The OP_BRIBE opcode checks that the given hash is in the hash map andreplaces the top element on the stack with the pass/fail result.It doesn't even check that the height matches the current block, thoughthere 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 thecoinbase, or cause a script failure otherwise.Another concern is that you could have multiple bribes for the same chainin a single coinbase. That isn't fair and arguably what the sidechainminer is paying for is to get his hash exclusively into the block.I would suggest that the output isOP_RETURN <sidechain_id> <critical hash>Then add the rule that only the first hash with a particular sidechain idactually counts.This forces the miner to only accept the bribe from 1 miner for eachsidechain for each block. If he tries to accept 2, then only the first onecounts.OP_BRIBE_VERIFY could then operate as follows<block height> <sidechain_id> <critical hash> OP_BRIBE_VERIFYThis 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>, orthere is no hash for that sidechain in the block's coinbaseIf you want reduce the number of drops, you could serialize the info intoa single push.This has the advantage that a sidechain miner only has to pay if his blockis accepted in the next bitcoin block. Since he is the only miner for thatsidechain that gets into the main bitcoin block, he is pretty muchguaranteed to form the longest chain.Without that rule, sidechain miners could end up having to pay even thoughit doesn't make their chain the longest.How are these transactions propagated over the network? For relaying, youcould have the rule that the opcode passes as long as <block height> isnear the current block height. Maybe require that they are in the future.They should be removed from the memory pool once the block height hasarrived, 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 listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

Post by Chris Stewart via bitcoin-devI think it would be wise to include a version byte to allow us toupgrade this commitment structure in the future. Similar to howwitness program's are now versioned.

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

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

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

Post by Chris Stewart via bitcoin-devIf I understand the current implementation correctly we can have up to256 OP_RETURNs embedded in the coinbase tx signifying new blocks minedon drivechains.. this seems less than ideal. It might be prudent tomake these outputs ANYONECANSPEND, and then have miners spending theseoutputs to themselves for every block mined.. maybe this doesn't havea benefit over using OP_RETURNs though?<version> <critical hash>and then in a subsequent block the miner spends that output tothemselves. I will admit I'm not super familiar with how OP_RETURNswork 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 theUTXO set. Anyone else want to chime in?

Post by CryptAxe via bitcoin-devSince the sidechain has the sidechain BMM headers that they want the LD(bribe) data for, I think that they could specifically request LD datarelevant only to that sidechain by providing a list of hashes to themainchain, and the mainchain can return a list of boolean values tellingthe sidechain if the LD data exists. That way the data never even has togo over the network, just a verification that it exists on the mainchainand

Since you seem to be talking about the initial block download process forthe 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 incontrol of the mining process on the sidechain. Here is what I envision:

1. Request all hashes for sidechain from a bitcoin peer2. Request all sidechain block header's for the hashes the bitcoin peergave us3. Order the set of sidechain block headers by looking at hashPrevBlock.4. Request full sidechain blocks and start validating against theconsensus 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 shouldjust fix these based on index. This should be reflected in my latest commitif we are talking about the same thing:https://github.com/Christewart/bitcoin/blob/c355e39fbe2ea48856ea86b25cb8a97710feb032/src/script/script.cpp#L254

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

I'm fairly certain you are right. It just feels like we should be able toexploit 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 withsomething clever that exploits that fact.

Post by CryptAxe via bitcoin-dev(bribe) data for, I think that they could specifically request LD datarelevant only to that sidechain by providing a list of hashes to themainchain, and the mainchain can return a list of boolean values tellingthe sidechain if the LD data exists. That way the data never even has togo over the network, just a verification that it exists on the mainchainand

Since you seem to be talking about the initial block download process forthe 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 in1. Request all hashes for sidechain from a bitcoin peer2. Request all sidechain block header's for the hashes the bitcoinpeer gave us3. Order the set of sidechain block headers by looking athashPrevBlock.4. Request full sidechain blocks and start validating against theconsensus rule set of the sidechainwe can drop the sidechain_id from the script.I agree the 'sidechain_id' is unneeded in the coinbase tx output. Weshould just fix these based on index. This should be reflected in my latestcommit if we are talking about the same thing: https://github.com/Christewart/bitcoin/blob/c355e39fbe2ea48856ea86b25cb8a97710feb032/src/script/script.cpp#L254and have the sidechain handle filtering out invalid LD data /

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

UTXO set. Anyone else want to chime in?I'm fairly certain you are right. It just feels like we should be able toexploit 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 withsomething clever that exploits that fact.On Sun, Jun 18, 2017 at 4:27 PM, CryptAxe via bitcoin-dev <

I think it is redundant here to have the <sidechain id>, we canimplicitly assume what the sidechain_id is since we have a fixed setof drivechains. I.e. mining reward is index 0, mimblewimble sidechainis index 1, etc. CryptAxe has specific indexes defined already in hishttps://github.com/drivechain-project/bitcoin/blob/mainchain

BMM/src/sidechain.h#L26-L30.Since the sidechain has the sidechain BMM headers that they want the LD(bribe) data for, I think that they could specifically request LD datarelevant only to that sidechain by providing a list of hashes to themainchain, and the mainchain can return a list of boolean values tellingthe sidechain if the LD data exists. That way the data never even has togo over the network, just a verification that it exists on the mainchainand we can drop the sidechain_id from the script.

Post by Chris Stewart via bitcoin-devI think it would be wise to include a version byte to allow us toupgrade this commitment structure in the future. Similar to howwitness program's are now versioned.

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

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

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

Post by Chris Stewart via bitcoin-devIf I understand the current implementation correctly we can have up to256 OP_RETURNs embedded in the coinbase tx signifying new blocks minedon drivechains.. this seems less than ideal. It might be prudent tomake these outputs ANYONECANSPEND, and then have miners spending theseoutputs to themselves for every block mined.. maybe this doesn't havea benefit over using OP_RETURNs though?<version> <critical hash>and then in a subsequent block the miner spends that output tothemselves. I will admit I'm not super familiar with how OP_RETURNswork 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 theUTXO set. Anyone else want to chime in?_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/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? 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-devseems 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.

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

notes (at the bottom of the BMM post) or the code, although this is timeconsuming of course.Looking over the code, I have a question: Is OP_BRIBE supposed to besoftforked in, or hardforked?

Softforked, of course.

From my understanding, the code as

Post by ZmnSCPxj via bitcoin-devpublished in your linked github cannot be softforked in, since it is nota softfork-compatible replacement for OP_NOP: it replaces the stack topvalue with a 0/1 value. Both CLTV and CSV do not touch the stack, onlyflag an error if they fail.

Your understanding may exceed my own. I don't understand the principleof your distinction, as it seems to me that one could add a new protocolrule which says that the block is invalid unless the OP Code doesresults in arbitrary-item-x. The intent is to mimic CLTV or CSVbehavior, by causing something that would otherwise succeed, to fail, ifarbitrary new conditions are met.

Post by ZmnSCPxj via bitcoin-dev(What happens if the h* to be put in the coinbase, by chance - even veryunlikely 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 willcheck when I get the chance, thanks.

Post by ZmnSCPxj via bitcoin-devHow is OP_BRIBE superior to just using a <h*> OP_RETURN script? Cannota sidechain scan the block for OP_RETURN attesting that the block hashis present in the block?

The sidechain software can indeed, but the mainchain software cannot(without making validation of both chains part of the mainchain, whichdefeats 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, ifMary 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 onewhich enforces the bare minimum criteria.

notice that, for the second withdrawal, the sum of the inputs is lessthan 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 someoff-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 exchangefor B's good or service (provided on the sidechain)2. side:B attempts to move side-to-main with the 100 BTC, using thelightning 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 becomesa 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 reorgthat happens just after step 2. After the reorg, the sidechain chainhistory will have a different side-to-main withdrawal in part 3. Thetime 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, infavor of the cooperative LN and Atomic Swaps).

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

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

Post by ZmnSCPxj via bitcoin-devThat said, I confused OP_h_is_in_coinbase as your method of getting outof the sidechain into the mainchain. It seems, OP_h_is_in_coinbase isonly for blind mining?

quickly while using spv proofs which are much slower and much mucheasier to audit.I don't quite understand how Drivechain handles sidechain reorgs, whilekeeping Bitcoin miners blinded. It seems sidechains need to be known("seen") by the miner, so I don't see what is being blinded by blindedmerge mining.

Mainchain miners do need to maintain some data about the sidechains, butthis is very minimal, and certainly does not include the transactiondata (or arbitrary messages) of the sidechain.

Bitcoin blog, and each mainchain block can only contain one block persidechain. In this way, drivechain sidechains are different fromclassical Namecoin merged mining (where one _could_ run the entiresystem, 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 onesidechain block? It seems, this isn't implemented by OP_BRIBE yet. Canyou elaborate on this mechanism?

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

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

on harms the sidechain technology might do to mainchain Bitcoin, and the"datacenter point" was specifically the chief objection raised. So I amafraid you are entirely incorrect.I see. It seems, the main problem, is that sidechains can be used tosneak in block size increases. Of course, the advantage of sidechains,is that when it increases block size irresponsibly, only those whoparticipated in the sidechain will suffer.

nodes, same as Bitcoin proper.But from blind merge mining by itself, how would the blinded merge minerknow that there exists an actual sidechain full node that actually didvalidation?It seems, that the "blinding" in merge mining does not seem to be at alluseful without the miner actually seeing the sidechain. If you wantminers to upgrade to side:fullnode as well, what would then be the pointof blinding? Why not just ordinary merge mining?Perhaps the datacenter point is simply that your proposal suggests toreduce the size of the datacenter by removing surge suppressors andUPS's, to avoid some definition of "datacenter is a room with >$XXX ofequipment".

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

It has been 3 weeks -- responses so far have been really helpful. Peoplejumped right in, and identified unfinished or missing parts much fasterthan 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 thelongest chain, and displaying information about this chain. CryptAxe isediting the sidechain code to handle reorganizations in a new way (aneven bigger departure than Namecoin's, imho).

I believe that I have responded to all the on-list objections that wereraised. I will 1st summarize the on-list objections, and 2nd summarizethe 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 'crisisaudit', I pointed out that it is actually optional (and, therefore,free), and that it doesn't affect miners relative to each other, andthat it can be done in an ultra-cheap semi-trusted way with highreliability.* Peter also asked about miner incentives, I replied that it is profitmaximizing 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 blocksubsidy" case and the "sidechain" case. He cites the asymmetry I pointout 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 heresponded again, in general he seemed to raise many of the pointsaddressed in #1 (below).* ZmnSCPxj wanted reorg proofs, to punish reorgers, but I pointed outthat if 51% can reorg, they can also filter out the reorg proof. We areat their mercy in all cases (for better or worse).* ZmnSCPxj also brought up the fact that a block size limit is necessaryfor a fee market, I pointed out that this limit does not need to beimposed on miners by nodes...miners would be willing-and-able toself-impose such a limit, as it maximizes their revenues.* ZmnSCPxj also protested the need to soft fork in each individualsidechain, I pointed out my strong disagreement ("Unrestrained smartcontract execution will be the death of most of the interestingapplications...[could] destabilize Bitcoin itself") and introduced myprion metaphor.* ZmnSCPxj and Tier Nolan both identified the problem solved by our'ratchet' concept. I explained it to ZmnSCPxj in my reply. We had notcoded it at the time, but there is code for it now [1]. Tier proposed arachet design, but I think ours is better (Tier did not find ours atall, because it is buried in obscure notes, because I didn't thinkanyone would make it this far so quickly).* Tier also advised us on how to fix the problem that ZmnSCPxj hadidentified with our NOP earlier.* Tier also had a number of suggestions about the real-time negotiationof the OP Bribe amount between nodes and miners. I'm afraid I mostlyignored these for now, as we aren't there yet.* Peter complained that ACKing the sidechain could be exploited forpolitical reasons, and I responded that in such a case, miners are freeto simply avoid ACKing, or to acquiesce to political pressure. Neitheraffect the mainchain.* Peter complained that sidechains might provide some miners with theopportunity to create a pretext to kick other miners off the network. Ireplied that it would not, and I also brought up the fact that myBitcoin security model was indifferent to which people happened to bemining at any given time. I continue to believe that "miningcentralization" does not have a useful definition.* Peter questioned whether or not sidechains would be useful. I statedmy belief that they would be useful, and linked to my site(drivechain.info/projects) which contains a number of sidechainuse-cases, and cited my personal anecdotal experiences.* Peter wanted to involve miners "as little as possible", I pointed outthat I felt that I had indeed done this minimization. My view is thatPeter felt erroneously that it was possible to involve miners less,because he neglected [1] that a 51% miner group is already involvedmaximally, as they can create most messages and filter any message, and[2] that there are cases where we need miners to filter out harmfulinteractions among multiple chains (just as they filter out harmfulinteractions among multiple txns [ie, "double spends"]). Peter has notyet responded to this rebuttal.* Peter also suggested client-side validation as "safer", and I pointedout that sidechains+BMM _is_ client-side validation. I asked Peter forCS-V code, so that we can compare the safety and other features.* Sergio reminded us of his version of drivechain. Sergio and I disagreeover the emphasis on frequency/speed of withdrawals. Also Sergioemphasizes a hybrid model, which does not interest me.

Off list, I have repeated the a similar conversation perhaps 6-10 timesover the past week. There is a cluster of remaining objections whichcenters around three topics -- speed, theft, and antifragility. I willreply 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 monthseach ( these are customizable parameters, and open for debate -- but ifwithdrawals are every x=3 months, and only x=1 withdrawal can makeforward progress [on the mainchain] at a time, and only x=1 prospectivewithdrawal can be assembled [by the sidechain] at a time, then we canexpect total withdrawal time to average 4.5 months [(.5)*3+3] ). Theresponse is something like "won't such a system be too slow, andtherefore unusable?".

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

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

Thanks to atomic swaps, someone can act as an investment banker orcustodian, and purchase side:BTC at a (tiny, competitive discount) andthen transfer those side-to-main at a minimal inconvenience (comparableto 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 BTCanytime soon (ie "the patient") can even get a tiny investment yield, inreturn 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 centralizedthese days?"

The logic of drivechain is to take a known fact -- that miners do notsteal from exchanges (by coordinating to doublespend deposits to thoseexchanges) -- 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 mainchainreorg today" would hit the entire Bitcoin system and de-confirm *all* ofthe network's transactions, whereas a sidechain-theft would hit only asmall portion of the system. This asymmetry is a problem because of the1:1 peg, which is explicitly symmetrical -- the thief makes off coinsthat are worth _just as much_ as those coins that he did _not_ attack.The side:BTC are therefore relatively more vulnerable to theft, whichharms the generalization.

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

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

Even if hashrate were controlled exclusively by one person, such a theftwould obliterate the sidechain-tx-fee revenue from all sidechains, for astart. 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 bepersuasive enough for them never to be needed (especially over longtimeframes, which make these maneuvers convenient).

A slightly more realistic worst-case scenario is that a monopolistimposes large fees on side-to-main transfers (which he contrives so thatonly 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 oftenoverlooked. Which is a shame, because its importance really cannot beunderstated.

Taleb's concept of antifragility is explicitly fractal -- it has layers,and an upper layer can only be antifragile if it is composed ofindividual members of a lower layer who are each *fragile*. In one of myvideos I give the example of NYC food providers -- it is _because_ thecompetition is so brutal, and because each individual NYCrestaurant/supermarket/food-truck is so likely to fail, (and becausethere is no safety net to catch them if they do fail), that theconsumer's experience is so positive (in NYC, you can find almost anykind of food, at any hour of the day, at any price, despite the factthat 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 ofproblem is actually _desirable_.

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

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

Ultimately, users can vote with their feet -- if the benefits of asidechain outweigh its risks, some users will send some BTC there. It isa strict improvement over the current situation, where users would needto use an Altcoin to achieve as much. Users who aren't comfortable withthe 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 "toopopular" objection or "too big to fail (tbtf)". Something like "what ifa *majority* of BTC is moved to one sidechain, and then that sidechainhas some kind of problem?".

One simple step would be to cap the quantity of BTC that can be moved toeach 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 (inwhich ~850,000/12,400,000 = 6.85% of the total BTC were assumed to bestolen).

Post by Paul Sztorc via bitcoin-devDear list,I've been working on "drivechain", a sidechain enabling technology, forsome time.* The technical info site is here: www.drivechain.infohttps://github.com/drivechain-project/bitcoin/tree/mainchainBMMhttps://github.com/drivechain-project/bitcoin/tree/sidechainBMMAs many of you know, I've been seeking feedback in person, at variousconferences and meetups over the past year, most prominently ScalingMilan. And I intend to continue to seek feedback at Consensus2017 thisweek, 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 washesitant because I try not to consume reviewers' scarce time until theauthor has put in a serious effort. However, I may have waiting toolong, as today it is actually quite close to a working release.Scaling Implications---------------------This upgrade would have significant scaling implications. Since it isthe case that sidechains can be added by soft fork, and since each ofthese chains will have its own blockspace, this theoretically removesthe blocksize limit from "the Bitcoin system" (if one includessidechains as part of such a system). People who want a LargeBlockbitcoin can just move their BTC over to such a network [1], and theirtxns will have no longer have an impact on "Bitcoin Core". Thus, eventhough this upgrade does not actually increase "scalability" per se, itmay 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-minethese "drivechains", even if these miners aren't running the actualsidechain software. The goal is to prevent sidechains from affecting thelevelness of the mining "playing field". BMM is conceptually similar toZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is notrequired for drivechain, but it would address some of the last remainingconcerns.Total Transaction Fees in the Far Future-----------------------------------------Some people feel that a maximum blocksize limit is needed to ensure thatfuture total equilibrium transaction fees are non-negligible. Ipresented [4] on why I don't agree, 8 months ago. The reviewers I spoketo over the last year have stopped bringing this complaint up, but I amnot sure everyone feels that way.Juxtaposition with a recent "Scaling Compromise"-------------------------------------------------Recently, a scalability proposal began to circulate on social media. Asfar as I could tell, it goes something like "immediately activateSegWit, and then HF to double the nonwitness blockspace to 2MB within 12months". But such a proposal is quite meager, compared to a "LargeBlockDrivechain". The drivechain is better on both fronts, as it would notrequire a hardfork, and could *almost immediately* add _any_ amount ofextra blockspace (specifically, I might expect a BIP101-like LargeBlockchain that has an 8 MB maxblocksize, which doubles every two years).In other words, I don't know why anyone would support that proposal overmine. The only reasons would be either ignorance (ie, unfamiliarity withdrivechain) or because there are still nagging unspoken complaints aboutdrivechain which I apparently need to hear and address.Other Thoughts---------------Unfortunately, anyone who worked on the "first generation" of sidechaintechnology (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 thatinvolves scalability. It is often said that "talking politics lowersyour IQ by 25 points". Bitcoin scalability conversations seem to drain50 points. (Instead of conversing, I think people should quietly work onwhatever they are passionate about until their problem either is solved,or it goes away for some other reason, or until we all agree to juststop 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

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.

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

Post by Paul Sztorc via bitcoin-devHi everyone,It has been 3 weeks -- responses so far have been really helpful. Peoplejumped right in, and identified unfinished or missing parts much fasterthan 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 thelongest chain, and displaying information about this chain. CryptAxe isediting the sidechain code to handle reorganizations in a new way (aneven bigger departure than Namecoin's, imho).I believe that I have responded to all the on-list objections that wereraised. I will 1st summarize the on-list objections, and 2nd summarizethe off-list discussion (focusing on three key themes).On-List Objection Summary---------------------------* Peter complained about the resources required for the BMM 'crisisaudit', I pointed out that it is actually optional (and, therefore,free), and that it doesn't affect miners relative to each other, andthat it can be done in an ultra-cheap semi-trusted way with highreliability.* Peter also asked about miner incentives, I replied that it is profitmaximizing 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 blocksubsidy" case and the "sidechain" case. He cites the asymmetry I pointout 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 heresponded again, in general he seemed to raise many of the pointsaddressed in #1 (below).* ZmnSCPxj wanted reorg proofs, to punish reorgers, but I pointed outthat if 51% can reorg, they can also filter out the reorg proof. We areat their mercy in all cases (for better or worse).* ZmnSCPxj also brought up the fact that a block size limit is necessaryfor a fee market, I pointed out that this limit does not need to beimposed on miners by nodes...miners would be willing-and-able toself-impose such a limit, as it maximizes their revenues.* ZmnSCPxj also protested the need to soft fork in each individualsidechain, I pointed out my strong disagreement ("Unrestrained smartcontract execution will be the death of most of the interestingapplications...[could] destabilize Bitcoin itself") and introduced myprion metaphor.* ZmnSCPxj and Tier Nolan both identified the problem solved by our'ratchet' concept. I explained it to ZmnSCPxj in my reply. We had notcoded it at the time, but there is code for it now [1]. Tier proposed arachet design, but I think ours is better (Tier did not find ours atall, because it is buried in obscure notes, because I didn't thinkanyone would make it this far so quickly).* Tier also advised us on how to fix the problem that ZmnSCPxj hadidentified with our NOP earlier.* Tier also had a number of suggestions about the real-time negotiationof the OP Bribe amount between nodes and miners. I'm afraid I mostlyignored these for now, as we aren't there yet.* Peter complained that ACKing the sidechain could be exploited forpolitical reasons, and I responded that in such a case, miners are freeto simply avoid ACKing, or to acquiesce to political pressure. Neitheraffect the mainchain.* Peter complained that sidechains might provide some miners with theopportunity to create a pretext to kick other miners off the network. Ireplied that it would not, and I also brought up the fact that myBitcoin security model was indifferent to which people happened to bemining at any given time. I continue to believe that "miningcentralization" does not have a useful definition.* Peter questioned whether or not sidechains would be useful. I statedmy belief that they would be useful, and linked to my site(drivechain.info/projects <http://drivechain.info/projects>) which contains a number of sidechainuse-cases, and cited my personal anecdotal experiences.* Peter wanted to involve miners "as little as possible", I pointed outthat I felt that I had indeed done this minimization. My view is thatPeter felt erroneously that it was possible to involve miners less,because he neglected [1] that a 51% miner group is already involvedmaximally, as they can create most messages and filter any message, and[2] that there are cases where we need miners to filter out harmfulinteractions among multiple chains (just as they filter out harmfulinteractions among multiple txns [ie, "double spends"]). Peter has notyet responded to this rebuttal.* Peter also suggested client-side validation as "safer", and I pointedout that sidechains+BMM _is_ client-side validation. I asked Peter forCS-V code, so that we can compare the safety and other features.* Sergio reminded us of his version of drivechain. Sergio and I disagreeover the emphasis on frequency/speed of withdrawals. Also Sergioemphasizes 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 timesover the past week. There is a cluster of remaining objections whichcenters around three topics -- speed, theft, and antifragility. I willreply here, and add the answers to my FAQ (drivechain.info/faq <http://drivechain.info/faq>).1. SpeedThis objection is voiced after I point out that side-to-main transfers("withdrawals") will probably take a long time, for example 5 monthseach ( these are customizable parameters, and open for debate -- but ifwithdrawals are every x=3 months, and only x=1 withdrawal can makeforward progress [on the mainchain] at a time, and only x=1 prospectivewithdrawal can be assembled [by the sidechain] at a time, then we canexpect total withdrawal time to average 4.5 months [(.5)*3+3] ). Theresponse is something like "won't such a system be too slow, andtherefore unusable?".Imho, replies of this kind disregard the effect of atomic cross-chainswaps, which are instant.( In addition, while side-to-main transfers are slow, main-to-sidetransfers are quite fast, x~=10 confirmations. I would go as far as tosay that, just as the Lightning Network is enabled by SegWit and CSV,Drivechain is enabled by the atomic swaps and of Counterparty-likeembedded consensus. )Thanks to atomic swaps, someone can act as an investment banker orcustodian, and purchase side:BTC at a (tiny, competitive discount) andthen transfer those side-to-main at a minimal inconvenience (comparableto 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 BTCanytime soon (ie "the patient") can even get a tiny investment yield, inreturn for providing this service.2. SecurityThis objection usually says something like "Aren't you worried that 51%[hashrate] will steal the coins, given that mining is so centralizedthese days?"The logic of drivechain is to take a known fact -- that miners do notsteal from exchanges (by coordinating to doublespend deposits to thoseexchanges) -- 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 mainchainreorg today" would hit the entire Bitcoin system and de-confirm *all* ofthe network's transactions, whereas a sidechain-theft would hit only asmall portion of the system. This asymmetry is a problem because of the1:1 peg, which is explicitly symmetrical -- the thief makes off coinsthat are worth _just as much_ as those coins that he did _not_ attack.The side:BTC are therefore relatively more vulnerable to theft, whichharms the generalization.As I've just explained, to correct this relative deficiency, we addextra inconvenience for any sidechain thievery, which is in this casethe long long withdrawal time of several months. (Which is also the maindistinction between DC and extension blocks).I cannot realistically imagine an erroneous withdrawal persisting forseveral weeks, let alone several months. First, over a timeframe of thisduration, there can be no pretense of 'we made an innocent mistake', norone that 'it is too inconvenient for us to fix this problem'. Thisrequires the attacker to be part of an explicitly malicious conspiracy.Even in the conspiring case, I do not understand how miners wouldcoordinate the distribution of the eventual "theft" payout, ~3 monthsfrom now -- if new hashrate comes online between now and then, does itget a portion? -- if today's hashrate closes down, does it get a reducedportion? -- who decides? I don't think that an algorithm can decide(without creating a new mechanism, which -I believe- would have to bepowered by ongoing sustainable theft [which is impossible]), because thewithdrawal (ie the "theft") has to be initiated, with a knowndestination, *before* it accumulates 3 months worth of acknowledgement.Even if hashrate were controlled exclusively by one person, such a theftwould obliterate the sidechain-tx-fee revenue from all sidechains, for astart. 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 bepersuasive enough for them never to be needed (especially over longtimeframes, which make these maneuvers convenient).A slightly more realistic worst-case scenario is that a monopolistimposes large fees on side-to-main transfers (which he contrives so thatonly 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. AntifragilityThere is an absolutely crucial distinction of "layers", which is oftenoverlooked. Which is a shame, because its importance really cannot beunderstated.Taleb's concept of antifragility is explicitly fractal -- it has layers,and an upper layer can only be antifragile if it is composed ofindividual members of a lower layer who are each *fragile*. In one of myvideos I give the example of NYC food providers -- it is _because_ thecompetition is so brutal, and because each individual NYCrestaurant/supermarket/food-truck is so likely to fail, (and becausethere is no safety net to catch them if they do fail), that theconsumer's experience is so positive (in NYC, you can find almost anykind of food, at any hour of the day, at any price, despite the factthat 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 ofproblem is actually _desirable_.If we wanted to have the best BTC currency unit possible, we would wanteveryone to try all kinds of things out, _especially_ the things that wethink are terrible. We'd want lots of things to be tried, and for thelosers to "fail fast".In practice I highly doubt the sidechain ecosystem would be anywherenear as dynamic as NYC or Silicon Valley. But certain questions, such as"What if a sidechain breaks / has DAO-like problems?"; "What if thesidechain has only a few nodes? Who will run them?"; "Who will maintainthese projects?"; -- really just miss the point, I think.Ultimately, users can vote with their feet -- if the benefits of asidechain outweigh its risks, some users will send some BTC there. It isa strict improvement over the current situation, where users would needto use an Altcoin to achieve as much. Users who aren't comfortable withthe 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 "toopopular" objection or "too big to fail (tbtf)". Something like "what ifa *majority* of BTC is moved to one sidechain, and then that sidechainhas some kind of problem?".One simple step would be to cap the quantity of BTC that can be moved toeach 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 (inwhich ~850,000/12,400,000 = 6.85% of the total BTC were assumed to bestolen).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>

Post by Paul Sztorc via bitcoin-devDear list,I've been working on "drivechain", a sidechain enabling technology, forsome time.* The technical info site is here: www.drivechain.infohttps://github.com/drivechain-project/bitcoin/tree/mainchainBMMhttps://github.com/drivechain-project/bitcoin/tree/sidechainBMMAs many of you know, I've been seeking feedback in person, at variousconferences and meetups over the past year, most prominently ScalingMilan. And I intend to continue to seek feedback at Consensus2017 thisweek, 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 washesitant because I try not to consume reviewers' scarce time until theauthor has put in a serious effort. However, I may have waiting toolong, as today it is actually quite close to a working release.Scaling Implications---------------------This upgrade would have significant scaling implications. Since it isthe case that sidechains can be added by soft fork, and since each ofthese chains will have its own blockspace, this theoretically removesthe blocksize limit from "the Bitcoin system" (if one includessidechains as part of such a system). People who want a LargeBlockbitcoin can just move their BTC over to such a network [1], and theirtxns will have no longer have an impact on "Bitcoin Core". Thus, eventhough this upgrade does not actually increase "scalability" per se, itmay 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-minethese "drivechains", even if these miners aren't running the actualsidechain software. The goal is to prevent sidechains from affecting thelevelness of the mining "playing field". BMM is conceptually similar toZooKeeV [3] which Peter Todd sketched out in mid-2013. BMM is notrequired for drivechain, but it would address some of the last remainingconcerns.Total Transaction Fees in the Far Future-----------------------------------------Some people feel that a maximum blocksize limit is needed to ensure thatfuture total equilibrium transaction fees are non-negligible. Ipresented [4] on why I don't agree, 8 months ago. The reviewers I spoketo over the last year have stopped bringing this complaint up, but I amnot sure everyone feels that way.Juxtaposition with a recent "Scaling Compromise"-------------------------------------------------Recently, a scalability proposal began to circulate on social media. Asfar as I could tell, it goes something like "immediately activateSegWit, and then HF to double the nonwitness blockspace to 2MB within 12months". But such a proposal is quite meager, compared to a "LargeBlockDrivechain". The drivechain is better on both fronts, as it would notrequire a hardfork, and could *almost immediately* add _any_ amount ofextra blockspace (specifically, I might expect a BIP101-like LargeBlockchain that has an 8 MB maxblocksize, which doubles every two years).In other words, I don't know why anyone would support that proposal overmine. The only reasons would be either ignorance (ie, unfamiliarity withdrivechain) or because there are still nagging unspoken complaints aboutdrivechain which I apparently need to hear and address.Other Thoughts---------------Unfortunately, anyone who worked on the "first generation" of sidechaintechnology (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 thatinvolves scalability. It is often said that "talking politics lowersyour IQ by 25 points". Bitcoin scalability conversations seem to drain50 points. (Instead of conversing, I think people should quietly work onwhatever they are passionate about until their problem either is solved,or it goes away for some other reason, or until we all agree to juststop 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

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

So, if miners wish to 'steal' from a sidechain, they _can_ initiate atheft, 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 Bitcoinchain to double-spend funds (or coordinate with someone who isdouble-spending). This is prevented/discouraged by waiting for manyconfirmations.2. Channel Theft -- A majority hashrate assists a Lightning-Networkthief, by censoring the punitive audit txn (possibly by exploiting someexcuse regarding fullness of blocks, or possibly induced to do so by thethief provably splitting the proceeds with miners). This isprevented/discouraged by using lengthy custodial periods, paying highfees with your attacker's money, and using fungibility/non-communicationto interact with miners as little as possible (so as to frame LN-theftas undermining the entire LN system, and not merely a single tragedy).3. Drivechain Theft -- A majority hashrate initiates an unrepresentativewithdrawal from some sidechain. This is prevented/discouraged by onlyusing 'popular' sidechains (those that [a] increase the usefulness("market price") of bitcoin, and [b] generate tx fees for miners). It isalso discouraged by the fact that egregious theft would probably end thesidechain experiment, meaning that all present and future sidechainswould be forever unavailable (and unable to buoy the price or the txrevenues).

I do not think that any of the three stands out as being categoricallyworse than the others, especially when we consider the heterogeneity ofuse-cases and preferences. As Luke-Jr has been pointing out on socialmedia recently, the very group which is more associated with miners (andexplicitly more willing to trust them, ie Bitcoin Unlimited et al),happens to be the same group that would be expected to make use of aLargeBlock 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 modelsare 'game theoretic' (neither computer scientific, nor cryptographic).

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

The qualifier "/any/ sidechain" would seem to imply that there is a wayto 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-devDrivechain would be a reasonable idea if that weren't the case, butsince it is, Drivechain now introduces a very real possible futurewhere Bitcoins can be confiscated by the Chinese government in exactlythe same manner that the Chinese government today confiscatesfinancial 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 tosell their Bitcoin for Chinese Yuan, which they then deposited in aChinese bank. Or if they sold their Bitcoin for an Altcoin controlled bythe Chinese govt in some other way.

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

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

Post by Tao Effect via bitcoin-dev1. The Bitcoin network centralizes more, because more power (bothfinancial power and power in terms of capability/control) is grantedto miners.

I think that one has some duty to very clearly define something (like"mining centralization" [2] or "centralization" [5]) before complainingabout it. I feel that people will occasionally use selfless complaintsto accomplish a selfish goal...especially when the artificial selflesspart 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" "theBitcoin community" may have exactly that in mind as their primarygoal...but they may also end up with more visibility (and with it: moreinfluence, more job offers, more conference invites, more friends, etc)and they may also end up with a megaphone for which to broadcast theirother views, or just a defend-able excuse for bragging loudly about howgreat cypherpunks are and/or how devoted they-in-particular are to thecypherpunk tribe, et cetera. To avoid this problem in my own technicaldiscourse, I try to avoid abstractions like "centralization" until Ihave defined them [2,5].

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

It seems to me that you reject the premise that BMM [4] addresses theseissues. This is probably because BMM only addresses miner's interactionswith each other, and it does not address miner abilities as a group inrelation to other groups (for example, vs. users, developers,investors). But, as I consistently emphasize, these groups of people arefree to ignore any sidechains that they do not like. In law there is asaying 'volenti non fit injuria' which I would translate as "he whovolunteers cannot claim later to have been injured". This is a legaltheory, because otherwise everyone would be arbitrarily liable forchoices beyond their control (ie, responsible for decisions of otherunrelated people), which would be nonsense.

Post by Tao Effect via bitcoin-dev3. Drivechain limits user's existing choice when it comes to who isacting 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 choicestoday would seem to be more "limited" than in a post-sidechain future.(The set of options may decrease later, for ecological reasons, if andonly if 'exchanges' are a strictly inferior option to 'sidechains' forsome reason...I don't see why this would be the case. I also don'tunderstand the emphasis on "exchanges" [SCs are much more like Altcoins,than exchanges] in the first place, nor the dubious qualifier"trustworthy".)

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

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

And, the point may be moot. Bitcoin miners may decide that, given theirexpertise in seeking out cheap sources of power/cooling, they might aswell mine both/all chains. So your suggestion may not achieve yourdesired result (and would, meanwhile, consume more of the economy'sresources -- 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* havethe same POW as bitcoin.I suspect this is the only way to be sure that a drivechain doesn'tdestabilize the main chain and push more power to miners that alreadyhave too much power.On Mon, Jun 19, 2017 at 12:04 PM, Paul Sztorc via bitcoin-devHi Greg,

It would not be accurate to say that miners have "total" control. Minersdo control the destination of withdrawals, but they do not control thewithdrawal-duration nor the withdrawal-frequency.So, if miners wish to 'steal' from a sidechain, they _can_ initiate atheft, 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 Bitcoinchain to double-spend funds (or coordinate with someone who isdouble-spending). This is prevented/discouraged by waiting for manyconfirmations.2. Channel Theft -- A majority hashrate assists a Lightning-Networkthief, by censoring the punitive audit txn (possibly by exploiting someexcuse regarding fullness of blocks, or possibly induced to do so by thethief provably splitting the proceeds with miners). This isprevented/discouraged by using lengthy custodial periods, paying highfees with your attacker's money, and usingfungibility/non-communicationto interact with miners as little as possible (so as to frame LN-theftas undermining the entire LN system, and not merely a single tragedy).3. Drivechain Theft -- A majority hashrate initiates anunrepresentativewithdrawal from some sidechain. This is prevented/discouraged by onlyusing 'popular' sidechains (those that [a] increase the usefulness("market price") of bitcoin, and [b] generate tx fees for miners). It isalso discouraged by the fact that egregious theft would probably end thesidechain experiment, meaning that all present and future sidechainswould be forever unavailable (and unable to buoy the price or the txrevenues).I do not think that any of the three stands out as being categoricallyworse than the others, especially when we consider theheterogeneity ofuse-cases and preferences. As Luke-Jr has been pointing out on socialmedia recently, the very group which is more associated with miners (andexplicitly more willing to trust them, ie Bitcoin Unlimited et al),happens to be the same group that would be expected to make use of aLargeBlock 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 modelsare 'game theoretic' (neither computer scientific, nor cryptographic).More importantly, before a miner has any "control" over the sidechaincoins, users must voluntarily agree to subject themselves to these newrules. This is similar to how an arbitrary piece of (open source)software can have "total" control over your computer...if you choose toinstall it.

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

Post by Tao Effect via bitcoin-devDrivechain would be a reasonable idea if that weren't the case, butsince it is, Drivechain now introduces a very real possible futurewhere Bitcoins can be confiscated by the Chinese government in

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 tosell their Bitcoin for Chinese Yuan, which they then deposited in aChinese bank. Or if they sold their Bitcoin for an Altcoincontrolled bythe Chinese govt in some other way.It is not up to the members of this list to decide, USSR style, whatother people are allowed to do with their own money.The exceptions to this rule would be (ie, "bitcoin-dev should care about1. [Unreasonable use of Reviewer Time] The user's use-case is eithernonexistent (ie "no one wants that"), or totally unachievable ("we can'tdo that") thus rendering the conversation a complete waste of time /reviewer attention.2. [Harmful Interference] The user's use-case would impose harm on someexisting use-case(s).No reasonable person will claim the first, given today's scaling debate(not to mention today's 'bitcoin dominance index'). Therefore, criticsmust claim the second (as, for example, Peter Todd has been doing onthis list).Which is why I narrowly focus on inter-chain harms [1], leadingultimately to a focus on the mining ecosystem [2,3] and the developmentof Blind Merged Mining [4].[1]http://youtu.be/0goYH2sDw0whttp://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-dev1. The Bitcoin network centralizes more, because more power (bothfinancial power and power in terms of capability/control) is grantedto miners.

I think that one has some duty to very clearly define something (like"mining centralization" [2] or "centralization" [5]) before complainingabout it. I feel that people will occasionally use selfless complaintsto accomplish a selfish goal...especially when the artificial selflesspart 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" "theBitcoin community" may have exactly that in mind as their primarygoal...but they may also end up with more visibility (and with it: moreinfluence, more job offers, more conference invites, more friends, etc)and they may also end up with a megaphone for which to broadcast theirother views, or just a defend-able excuse for bragging loudly about howgreat cypherpunks are and/or how devoted they-in-particular are to thecypherpunk tribe, et cetera. To avoid this problem in my own technicaldiscourse, I try to avoid abstractions like "centralization" until Ihave defined them [2,5].You have defined centralization above, but the definition is itselfvague to the point where I do not think even you actually endorse it.For example, you would need to say that Bitcoin centralizes whenever theexchange rate increases (as this grants additional financial power tominers) or when any new user joins Bitcoin, or when tx fee revenuesincrease for any reason. You might also be forced to say that LNcentralizes Bitcoin (as LN grants new capability/control to miners), andprobably even that Bitcoin becomes more centralized when developersrelease new software (as this grants new capability to miners,specifically the ability to deny upgrades). This probably isn't what youmeant, but since you did not clearly explain what you meant we have noway of knowing for sure.It seems to me that you reject the premise that BMM [4] addresses theseissues. This is probably because BMM only addresses miner's interactionswith each other, and it does not address miner abilities as a group inrelation to other groups (for example, vs. users, developers,investors). But, as I consistently emphasize, these groups of people arefree to ignore any sidechains that they do not like. In law there is asaying 'volenti non fit injuria' which I would translate as "he whovolunteers cannot claim later to have been injured". This is a legaltheory, because otherwise everyone would be arbitrarily liable forchoices beyond their control (ie, responsible for decisions of otherunrelated people), which would be nonsense.

of laws.Currently no (P2P) sidechains exist, and therefore the set of choicestoday would seem to be more "limited" than in a post-sidechain future.(The set of options may decrease later, for ecological reasons, if andonly if 'exchanges' are a strictly inferior option to 'sidechains' forsome reason...I don't see why this would be the case. I also don'tunderstand 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 listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

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

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

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

Post by Paul Sztorc via bitcoin-devHi Erik,1. If a sidechain is merged mined it basically grows out of the existingBitcoin mining network. If it has a different PoW algorithm it is a newmining network.2. The security (ie, hashrate) of any mining network would be determinedby the total economic value of the block. In Bitcoin this is(subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens itwould only be (tx_fees)*price.Unfortunately the two have a nasty correlation which can lead to adisastrous self-fulfilling prophecy: users will avoid a network that is tooinsecure; and if users avoid using a network, they will stop paying txnfees and so the quantity (tx_fees)*price falls toward zero, erasing thenetwork's security. So it is quite problematic and I recommend just bitingthe bullet and going with merged mining instead.And, the point may be moot. Bitcoin miners may decide that, given theirexpertise in seeking out cheap sources of power/cooling, they might as wellmine both/all chains. So your suggestion may not achieve your desiredresult (and would, meanwhile, consume more of the economy's resources --some of these would not contribute even to a higher hashrate).PaulIt would be nice to be able to enforce that a drivechain *not* have thesame POW as bitcoin.I suspect this is the only way to be sure that a drivechain doesn'tdestabilize the main chain and push more power to miners that already havetoo much power.On Mon, Jun 19, 2017 at 12:04 PM, Paul Sztorc via bitcoin-dev <

It would not be accurate to say that miners have "total" control. Minersdo control the destination of withdrawals, but they do not control thewithdrawal-duration nor the withdrawal-frequency.So, if miners wish to 'steal' from a sidechain, they _can_ initiate atheft, 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 Bitcoinchain to double-spend funds (or coordinate with someone who isdouble-spending). This is prevented/discouraged by waiting for manyconfirmations.2. Channel Theft -- A majority hashrate assists a Lightning-Networkthief, by censoring the punitive audit txn (possibly by exploiting someexcuse regarding fullness of blocks, or possibly induced to do so by thethief provably splitting the proceeds with miners). This isprevented/discouraged by using lengthy custodial periods, paying highfees with your attacker's money, and using fungibility/non-communicationto interact with miners as little as possible (so as to frame LN-theftas undermining the entire LN system, and not merely a single tragedy).3. Drivechain Theft -- A majority hashrate initiates an unrepresentativewithdrawal from some sidechain. This is prevented/discouraged by onlyusing 'popular' sidechains (those that [a] increase the usefulness("market price") of bitcoin, and [b] generate tx fees for miners). It isalso discouraged by the fact that egregious theft would probably end thesidechain experiment, meaning that all present and future sidechainswould be forever unavailable (and unable to buoy the price or the txrevenues).I do not think that any of the three stands out as being categoricallyworse than the others, especially when we consider the heterogeneity ofuse-cases and preferences. As Luke-Jr has been pointing out on socialmedia recently, the very group which is more associated with miners (andexplicitly more willing to trust them, ie Bitcoin Unlimited et al),happens to be the same group that would be expected to make use of aLargeBlock 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 modelsare 'game theoretic' (neither computer scientific, nor cryptographic).More importantly, before a miner has any "control" over the sidechaincoins, users must voluntarily agree to subject themselves to these newrules. This is similar to how an arbitrary piece of (open source)software can have "total" control over your computer...if you choose toinstall it.

The qualifier "/any/ sidechain" would seem to imply that there is a wayto 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-devDrivechain would be a reasonable idea if that weren't the case, butsince it is, Drivechain now introduces a very real possible futurewhere Bitcoins can be confiscated by the Chinese government in exactlythe same manner that the Chinese government today confiscatesfinancial 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 tosell their Bitcoin for Chinese Yuan, which they then deposited in aChinese bank. Or if they sold their Bitcoin for an Altcoin controlled bythe Chinese govt in some other way.It is not up to the members of this list to decide, USSR style, whatother people are allowed to do with their own money.The exceptions to this rule would be (ie, "bitcoin-dev should care about1. [Unreasonable use of Reviewer Time] The user's use-case is eithernonexistent (ie "no one wants that"), or totally unachievable ("we can'tdo that") thus rendering the conversation a complete waste of time /reviewer attention.2. [Harmful Interference] The user's use-case would impose harm on someexisting use-case(s).No reasonable person will claim the first, given today's scaling debate(not to mention today's 'bitcoin dominance index'). Therefore, criticsmust claim the second (as, for example, Peter Todd has been doing onthis list).Which is why I narrowly focus on inter-chain harms [1], leadingultimately to a focus on the mining ecosystem [2,3] and the developmentof Blind Merged Mining [4].[1]http://youtu.be/0goYH2sDw0wciNjgS_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-dev1. The Bitcoin network centralizes more, because more power (bothfinancial power and power in terms of capability/control) is grantedto miners.

I think that one has some duty to very clearly define something (like"mining centralization" [2] or "centralization" [5]) before complainingabout it. I feel that people will occasionally use selfless complaintsto accomplish a selfish goal...especially when the artificial selflesspart 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" "theBitcoin community" may have exactly that in mind as their primarygoal...but they may also end up with more visibility (and with it: moreinfluence, more job offers, more conference invites, more friends, etc)and they may also end up with a megaphone for which to broadcast theirother views, or just a defend-able excuse for bragging loudly about howgreat cypherpunks are and/or how devoted they-in-particular are to thecypherpunk tribe, et cetera. To avoid this problem in my own technicaldiscourse, I try to avoid abstractions like "centralization" until Ihave defined them [2,5].You have defined centralization above, but the definition is itselfvague to the point where I do not think even you actually endorse it.For example, you would need to say that Bitcoin centralizes whenever theexchange rate increases (as this grants additional financial power tominers) or when any new user joins Bitcoin, or when tx fee revenuesincrease for any reason. You might also be forced to say that LNcentralizes Bitcoin (as LN grants new capability/control to miners), andprobably even that Bitcoin becomes more centralized when developersrelease new software (as this grants new capability to miners,specifically the ability to deny upgrades). This probably isn't what youmeant, but since you did not clearly explain what you meant we have noway of knowing for sure.It seems to me that you reject the premise that BMM [4] addresses theseissues. This is probably because BMM only addresses miner's interactionswith each other, and it does not address miner abilities as a group inrelation to other groups (for example, vs. users, developers,investors). But, as I consistently emphasize, these groups of people arefree to ignore any sidechains that they do not like. In law there is asaying 'volenti non fit injuria' which I would translate as "he whovolunteers cannot claim later to have been injured". This is a legaltheory, because otherwise everyone would be arbitrarily liable forchoices beyond their control (ie, responsible for decisions of otherunrelated people), which would be nonsense.

Post by Tao Effect via bitcoin-dev3. Drivechain limits user's existing choice when it comes to who isacting 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 choicestoday would seem to be more "limited" than in a post-sidechain future.(The set of options may decrease later, for ecological reasons, if andonly if 'exchanges' are a strictly inferior option to 'sidechains' forsome reason...I don't see why this would be the case. I also don'tunderstand 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 listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

I don't think that your design is competitive. Why would users toleratea depreciation of X% per year, when there are alternatives which do notrequire 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 toburn bitcoin *or* side-chain tokens to mine the side chain. the sizeof the burn is the degree of security. i actually wrote code to dorandomized 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 insidechain tokens, which can be aggrregated and redeemed for bitcoins.the result of this is that any bitcoins held in the sidechaindepreciate in value at a rate of X% per year. this deflation ratepays for increased security- logically this functions like an alt coin, with high inflation andcheap transactions. but the altcoin is pegged to bitcoin's pricebecause 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 theexisting Bitcoin mining network. If it has a different PoWalgorithm it is a new mining network.2. The security (ie, hashrate) of any mining network would bedetermined by the total economic value of the block. In Bitcointhis is (subsidy+tx_fees)*price, but since a sidechain cannotissue new tokens it would only be (tx_fees)*price.Unfortunately the two have a nasty correlation which can lead to adisastrous self-fulfilling prophecy: users will avoid a networkthat is too insecure; and if users avoid using a network, theywill stop paying txn fees and so the quantity (tx_fees)*pricefalls toward zero, erasing the network's security. So it is quiteproblematic and I recommend just biting the bullet and going withmerged mining instead.And, the point may be moot. Bitcoin miners may decide that, giventheir expertise in seeking out cheap sources of power/cooling,they might as well mine both/all chains. So your suggestion maynot achieve your desired result (and would, meanwhile, consumemore of the economy's resources -- some of these would notcontribute 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 drivechaindoesn't destabilize the main chain and push more power to minersthat already have too much power.

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

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

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

Post by Paul Sztorc via bitcoin-devHi Erik,I don't think that your design is competitive. Why would users tolerate adepreciation of X% per year, when there are alternatives which do notrequire such depreciation? It seems to me that none would.Paul- a proof-of-burn sidechain is the ultimate two-way peg. you have toburn bitcoin *or* side-chain tokens to mine the side chain. the size ofthe burn is the degree of security. i actually wrote code to dorandomized blind burns where you have a poisson distribution(non-deterministic selected burn). there is no way to game it... it'svery similar to algorand - but it uses burns instead of staking- you can then have a secure sidechain that issues a mining reward insidechain tokens, which can be aggrregated and redeemed for bitcoins. theresult of this is that any bitcoins held in the sidechain depreciate invalue at a rate of X% per year. this deflation rate pays for increasedsecurity- logically this functions like an alt coin, with high inflation and cheaptransactions. but the altcoin is pegged to bitcoin's price because of thepool of unredeemed bitcoins held within the side chain.

Post by Paul Sztorc via bitcoin-devHi Erik,1. If a sidechain is merged mined it basically grows out of the existingBitcoin mining network. If it has a different PoW algorithm it is a newmining network.2. The security (ie, hashrate) of any mining network would be determinedby the total economic value of the block. In Bitcoin this is(subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens itwould only be (tx_fees)*price.Unfortunately the two have a nasty correlation which can lead to adisastrous self-fulfilling prophecy: users will avoid a network that is tooinsecure; and if users avoid using a network, they will stop paying txnfees and so the quantity (tx_fees)*price falls toward zero, erasing thenetwork's security. So it is quite problematic and I recommend just bitingthe bullet and going with merged mining instead.And, the point may be moot. Bitcoin miners may decide that, given theirexpertise in seeking out cheap sources of power/cooling, they might as wellmine both/all chains. So your suggestion may not achieve your desiredresult (and would, meanwhile, consume more of the economy's resources --some of these would not contribute even to a higher hashrate).PaulIt would be nice to be able to enforce that a drivechain *not* have thesame POW as bitcoin.I suspect this is the only way to be sure that a drivechain doesn'tdestabilize the main chain and push more power to miners that already havetoo much power.

Post by Erik Aronesty via bitcoin-devUsers would tolerate depreciation because the intention is to have acheap way of transacting using a two-way pegged chain that isn'tcontrolled by miners. Who cares about some minor depreciation whenthe 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 moreexpensive due to the extra depreciation cost.

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

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

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

Post by Erik Aronesty via bitcoin-devAdd in UTXO commitments and you've got a system that is cheap andsecure-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 forsidechains.

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

Paul

Post by Erik Aronesty via bitcoin-devHi Erik,I don't think that your design is competitive. Why would userstolerate a depreciation of X% per year, when there arealternatives which do not require such depreciation? It seems tome that none would.Paul

Post by Erik Aronesty via bitcoin-dev- a proof-of-burn sidechain is the ultimate two-way peg. youhave to burn bitcoin *or* side-chain tokens to mine the sidechain. the size of the burn is the degree of security. iactually wrote code to do randomized blind burns where you have apoisson distribution (non-deterministic selected burn). thereis no way to game it... it's very similar to algorand - but ituses burns instead of staking- you can then have a secure sidechain that issues a miningreward in sidechain tokens, which can be aggrregated and redeemedfor bitcoins. the result of this is that any bitcoins held inthe 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 inflationand cheap transactions. but the altcoin is pegged to bitcoin'sprice because of the pool of unredeemed bitcoins held within theside chain.Hi Erik,1. If a sidechain is merged mined it basically grows out ofthe existing Bitcoin mining network. If it has a differentPoW algorithm it is a new mining network.2. The security (ie, hashrate) of any mining network would bedetermined by the total economic value of the block. InBitcoin this is (subsidy+tx_fees)*price, but since asidechain cannot issue new tokens it would only be(tx_fees)*price.Unfortunately the two have a nasty correlation which can leadto a disastrous self-fulfilling prophecy: users will avoid anetwork that is too insecure; and if users avoid using anetwork, they will stop paying txn fees and so the quantity(tx_fees)*price falls toward zero, erasing the network'ssecurity. So it is quite problematic and I recommend justbiting 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 ofpower/cooling, they might as well mine both/all chains. Soyour suggestion may not achieve your desired result (andwould, 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 drivechaindoesn't destabilize the main chain and push more power tominers that already have too much power.

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

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

The critical issue is that we cannot introduce protocol changes that*further *incentivize geographical and institutional consolidation. Minerswho are able to deal with the bandwidth caused by drivechain coffeetransactions will profit from these transactions, whereas smaller and moregeographically 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 behindpreserving block size limits.

If this premise is false (which it may be), or is skewed so as to damagebitcoin 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 increaseand coming from an *orthoganal* protocol that cannot cause furthercentralization.

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

Post by Paul Sztorc via bitcoin-devResponses inline.Users would tolerate depreciation because the intention is to have a cheapway of transacting using a two-way pegged chain that isn't controlled byminers. Who cares about some minor depreciation when the purpose of thechain 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 moreexpensive due to the extra depreciation cost.I also doubt that they would be free of control by miners. 51% hashratecan always filter out any message they want from anywhere.For the same reason, I don't understand why they would be any more or lesssecure.So I think your way is just a more expensive way of accomplishingbasically the same result.Add in UTXO commitments and you've got a system that is cheap andsecure-enough for transfer. storage and accumulation of a ledger... beforemoving in to the main chain.As I posted to bitcoin-discuss last week, I support UTXO commitments forsidechains.Seems better to me than messing with the main chain's incentive structurevia merged mining.I don't think that blind merged mining messes with the main chain'sincentive structure. Miners are free to ignore the sidechain (and yet stillget paid the same as other miners), as are all mainchain users.Paul

Post by Paul Sztorc via bitcoin-devHi Erik,I don't think that your design is competitive. Why would users tolerate adepreciation of X% per year, when there are alternatives which do notrequire such depreciation? It seems to me that none would.Paul- a proof-of-burn sidechain is the ultimate two-way peg. you have toburn bitcoin *or* side-chain tokens to mine the side chain. the size ofthe burn is the degree of security. i actually wrote code to dorandomized blind burns where you have a poisson distribution(non-deterministic selected burn). there is no way to game it... it'svery similar to algorand - but it uses burns instead of staking- you can then have a secure sidechain that issues a mining reward insidechain tokens, which can be aggrregated and redeemed for bitcoins. theresult of this is that any bitcoins held in the sidechain depreciate invalue at a rate of X% per year. this deflation rate pays for increasedsecurity- logically this functions like an alt coin, with high inflation andcheap transactions. but the altcoin is pegged to bitcoin's price becauseof the pool of unredeemed bitcoins held within the side chain.

Post by Paul Sztorc via bitcoin-devHi Erik,1. If a sidechain is merged mined it basically grows out of the existingBitcoin mining network. If it has a different PoW algorithm it is a newmining network.2. The security (ie, hashrate) of any mining network would be determinedby the total economic value of the block. In Bitcoin this is(subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens itwould only be (tx_fees)*price.Unfortunately the two have a nasty correlation which can lead to adisastrous self-fulfilling prophecy: users will avoid a network that is tooinsecure; and if users avoid using a network, they will stop paying txnfees and so the quantity (tx_fees)*price falls toward zero, erasing thenetwork's security. So it is quite problematic and I recommend just bitingthe bullet and going with merged mining instead.And, the point may be moot. Bitcoin miners may decide that, given theirexpertise in seeking out cheap sources of power/cooling, they might as wellmine both/all chains. So your suggestion may not achieve your desiredresult (and would, meanwhile, consume more of the economy's resources --some of these would not contribute even to a higher hashrate).PaulIt would be nice to be able to enforce that a drivechain *not* have thesame POW as bitcoin.I suspect this is the only way to be sure that a drivechain doesn'tdestabilize the main chain and push more power to miners that already havetoo much power.

Miners who are able to deal with the bandwidth caused by drivechain coffee

transactions will profit from these transactions, whereas smaller and moregeographically 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 lowlatency, reasonable bandwidth, good place in network (e.g. FIBRE or miningbackbone). They need reliable computers with enough RAM and CPU to validateprior blocks promptly and immediately assemble new blocks.

It might be helpful to keep these three groups distinct in your mind andconversation, and to use the protocol as a crowbar to pry them intoseparate people, or at a minimum make it economically possible toparticipate in one role without needing to participate in the other two. Ifdifferent, geographically and politically dispersed groups are helpingperform these functions, it aids decentralization.

expensive due to the extra depreciation cost.This depends on how long you expect to keep money on a side chain and howmany transactions you plan on doing. Inflation is a great way of payingPoS / PoB miners - that cannot introduce issues with consolidation. Ifyou design the inflation schedule correctly, it should be balancetransaction costs *precisely*. Indeed, you can calculate the exact amountof inflation needed to guarantee that a side chain is always exactly 10times cheaper than bitcoin.

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

incentive structureThe 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 coffeetransactions will profit from these transactions, whereas smaller and moregeographically 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 motivationbehind preserving block size limits.If this premise is false (which it may be), or is skewed so as to damagebitcoin as a whole (could be as well), then that needs to be demonstrated*first*.The lightning model does the opposite of this. Miners watch feesincrease and coming from an *orthoganal* protocol that cannot cause furthercentralization.One problem is that the main chain also *must* grow in response tobandwidth, or the disadvantages of using the main chain will weakenfinancial support and hashrate securing it. I believe this is also true,and that a "balancing act" will be Bitcoin's norm until we adopt somethinglike BIP103 - which provides a steady and appropriate growth.

Post by Paul Sztorc via bitcoin-devResponses inline.Users would tolerate depreciation because the intention is to have acheap way of transacting using a two-way pegged chain that isn't controlledby miners. Who cares about some minor depreciation when the purpose of thechain 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 moreexpensive due to the extra depreciation cost.I also doubt that they would be free of control by miners. 51% hashratecan always filter out any message they want from anywhere.For the same reason, I don't understand why they would be any more orless secure.So I think your way is just a more expensive way of accomplishingbasically the same result.Add in UTXO commitments and you've got a system that is cheap andsecure-enough for transfer. storage and accumulation of a ledger... beforemoving in to the main chain.As I posted to bitcoin-discuss last week, I support UTXO commitments forsidechains.Seems better to me than messing with the main chain's incentive structurevia merged mining.I don't think that blind merged mining messes with the main chain'sincentive structure. Miners are free to ignore the sidechain (and yet stillget paid the same as other miners), as are all mainchain users.Paul

Post by Paul Sztorc via bitcoin-devHi Erik,I don't think that your design is competitive. Why would users toleratea depreciation of X% per year, when there are alternatives which do notrequire such depreciation? It seems to me that none would.Paul- a proof-of-burn sidechain is the ultimate two-way peg. you have toburn bitcoin *or* side-chain tokens to mine the side chain. the size ofthe burn is the degree of security. i actually wrote code to dorandomized blind burns where you have a poisson distribution(non-deterministic selected burn). there is no way to game it... it'svery similar to algorand - but it uses burns instead of staking- you can then have a secure sidechain that issues a mining reward insidechain tokens, which can be aggrregated and redeemed for bitcoins. theresult of this is that any bitcoins held in the sidechain depreciate invalue at a rate of X% per year. this deflation rate pays for increasedsecurity- logically this functions like an alt coin, with high inflation andcheap transactions. but the altcoin is pegged to bitcoin's price becauseof the pool of unredeemed bitcoins held within the side chain.

Post by Paul Sztorc via bitcoin-devHi Erik,1. If a sidechain is merged mined it basically grows out of theexisting Bitcoin mining network. If it has a different PoW algorithm it isa new mining network.2. The security (ie, hashrate) of any mining network would bedetermined by the total economic value of the block. In Bitcoin this is(subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens itwould only be (tx_fees)*price.Unfortunately the two have a nasty correlation which can lead to adisastrous self-fulfilling prophecy: users will avoid a network that is tooinsecure; and if users avoid using a network, they will stop paying txnfees and so the quantity (tx_fees)*price falls toward zero, erasing thenetwork's security. So it is quite problematic and I recommend just bitingthe bullet and going with merged mining instead.And, the point may be moot. Bitcoin miners may decide that, given theirexpertise in seeking out cheap sources of power/cooling, they might as wellmine both/all chains. So your suggestion may not achieve your desiredresult (and would, meanwhile, consume more of the economy's resources --some of these would not contribute even to a higher hashrate).PaulIt would be nice to be able to enforce that a drivechain *not* have thesame POW as bitcoin.I suspect this is the only way to be sure that a drivechain doesn'tdestabilize the main chain and push more power to miners that already havetoo much power.

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 balancetransaction costs *precisely*.

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

Users would tolerate depreciation because the intention is tohave a cheap way of transacting using a two-way pegged chain thatisn't controlled by miners. Who cares about some minordepreciation when the purpose of the chain is to do cheap securetransactions 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 relativelymore 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 moreor less secure.So I think your way is just a more expensive way of accomplishingbasically the same result.

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

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

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

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

Hi Erik,I don't think that your design is competitive. Why wouldusers tolerate a depreciation of X% per year, when there arealternatives which do not require such depreciation? It seemsto 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 theside chain. the size of the burn is the degree ofsecurity. i actually wrote code to do randomized blindburns where you have a poisson distribution(non-deterministic selected burn). there is no way togame it... it's very similar to algorand - but it uses burnsinstead of staking- you can then have a secure sidechain that issues a miningreward in sidechain tokens, which can be aggrregated andredeemed for bitcoins. the result of this is that anybitcoins held in the sidechain depreciate in value at a rateof X% per year. this deflation rate pays for increasedsecurity- logically this functions like an alt coin, with highinflation and cheap transactions. but the altcoin ispegged to bitcoin's price because of the pool of unredeemedbitcoins held within the side chain.On Tue, Jun 20, 2017 at 7:54 AM, Paul SztorcHi Erik,1. If a sidechain is merged mined it basically grows outof the existing Bitcoin mining network. If it has adifferent PoW algorithm it is a new mining network.2. The security (ie, hashrate) of any mining networkwould be determined by the total economic value of theblock. In Bitcoin this is (subsidy+tx_fees)*price, butsince a sidechain cannot issue new tokens it would onlybe (tx_fees)*price.Unfortunately the two have a nasty correlation which canlead to a disastrous self-fulfilling prophecy: userswill avoid a network that is too insecure; and if usersavoid using a network, they will stop paying txn feesand so the quantity (tx_fees)*price falls toward zero,erasing the network's security. So it is quiteproblematic and I recommend just biting the bullet andgoing with merged mining instead.And, the point may be moot. Bitcoin miners may decidethat, given their expertise in seeking out cheap sourcesof power/cooling, they might as well mine both/allchains. So your suggestion may not achieve your desiredresult (and would, meanwhile, consume more of theeconomy's resources -- some of these would notcontribute even to a higher hashrate).Paul

It would be nice to be able to enforce that adrivechain *not* have the same POW as bitcoin.I suspect this is the only way to be sure that adrivechain doesn't destabilize the main chain and pushmore power to miners that already have too much power.

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.

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

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

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

Post by Tao Effect via bitcoin-dev4. Everyone waits for a period of, say, 3 days. This giveseveryone an opportunity to make sure the same WT^ is in both theBitcoin coinbase and the Sidechain header. If theyâre different,everyone has plenty of time to contact each other, figure out whatis 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 isthe 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 stilloverwhelmingly accurate, new optimizations allow us (I think) to pushthe waiting period to several weeks and the total ACK counting period upto 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 justassume every withdrawal is valid. This is comparable to someone whostill 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-dev2. Per the question in [1], it's my understanding that P2SHtransactions contain all of the information within themselves for fullnodes to act as a check on miners mishandling the anyone-can-spendnature of P2SH transactions. However, that does not seem to be thecase 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-devIn P2SH txns, there is no need for anyone to, as the Drivechain specsays, "to contact each other, figure out what is going on". Everythingjust 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 whatis going on, but that has absolutely nothing whatsoever to do withBitcoin Core and so is off-topic for this mailing list.

Post by Tao Effect via bitcoin-devIf the security of WT^ transactions could be brought up to actually bein line with the security of P2SH and SegWit transactions, then Iwould have far less to object to.

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-devFYI 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-devBecause 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[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?

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-devThe 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-dev4. 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] YesBecause 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-dev2. 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-devIn 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-devIf 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.

I will repeat that Drivechain can sometimes be confusing because it isdifferent 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 isrunning, say, 0.13). However, they experience the effects of the newrules which miners add (as per the soft fork[s] to add drivechainfunctionality and individual drivechains).[DC#1] -- Someone who always upgrades to the latest version of theBitcoin software, but otherwise has no interest in running/using sidechains.[DC#2] -- Someone who upgrades to the latest Bitcoin version, anddecides to also become a full node of one or more sidechains, but whoever actually uses the sidechains.[DC#3] -- Someone who upgrades their software, runs sidechain fullnodes, and actively moves money to and from these.

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

Post by Paul Sztorc via bitcoin-devFYI that document is nearly two years old, and although it is stilloverwhelmingly accurate, new optimizations allow us (I think) to pushthe waiting period to several weeks and the total ACK counting periodup to several months.

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

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

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

Post by Tao Effect via bitcoin-devAlso, if the document is old and/or outdated, do you happen to have alink to a more update-to-date version of the spec? It would be helpfulfor review.

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

Post by Paul Sztorc via bitcoin-devBecause if a node doesn't have the sidechain's information, it willjust assume every withdrawal is valid. This is comparable to someonewho 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 itas "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 'alwaysvalid' to some group of people (un-upgraded users) but which aresometimes invalid to new users. So the only difference would be for[DC#0] vs other versions, but this difference is trivial as miners willcensor invalid txns.

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

The first case is exactly equal to P2SH. Just as old nodes accept everyP2SH 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] wouldalso accept any WT^ *that followed the Drivechain rules*, even if theydid not like the outcome (because the outcome in question wasarbitrarily designated as a "theft" of funds -- again, see the secondcase in the list above). In this way, it is exactly similar to P2SHbecause nodes will accept *any* p2sh txn **that follows the p2shrules**, even if they don't "like" the specific script contained within(for example, because it is a theft of "their" BitFinex funds, or adonation 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 understandingwhat is going on, but that has absolutely nothing whatsoever to dowith 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 myfavorite color or my home address. And such answers would needlesslyconsume the mailing list's scarce time.

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

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

Post by Paul Sztorc via bitcoin-devThe 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 isrunning, say, 0.13). However, they experience the effects of the newrules which miners add (as per the soft fork[s] to add drivechainfunctionality and individual drivechains).[DC#1] -- Someone who always upgrades to the latest version of theBitcoin software, but otherwise has no interest in running/using sidechains.[DC#2] -- Someone who upgrades to the latest Bitcoin version, anddecides to also become a full node of one or more sidechains, but whoever actually uses the sidechains.[DC#3] -- Someone who upgrades their software, runs sidechain fullnodes, and actively moves money to and from these.

Post by Tao Effect via bitcoin-dev4. Everyone waits for a period of, say, 3 days. This giveseveryone an opportunity to make sure the same WT^ is in both theBitcoin coinbase and the Sidechain header. If theyâre different,everyone has plenty of time to contact each other, figure outwhat 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 isthe 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 stilloverwhelmingly accurate, new optimizations allow us (I think) to pushthe waiting period to several weeks and the total ACK counting periodup to several months.[DC#0] Yes[DC#1] Yes[DC#2] Yes[DC#3] YesBecause if a node doesn't have the sidechain's information, it willjust assume every withdrawal is valid. This is comparable to someonewho 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-dev2. Per the question in [1], it's my understanding that P2SHtransactions contain all of the information within themselves forfull nodes to act as a check on miners mishandling theanyone-can-spend nature of P2SH transactions. However, that does notseem 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-devIn P2SH txns, there is no need for anyone to, as the Drivechain specsays, "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 understandingwhat is going on, but that has absolutely nothing whatsoever to dowith Bitcoin Core and so is off-topic for this mailing list.

Post by Tao Effect via bitcoin-devIf the security of WT^ transactions could be brought up to actuallybe in line with the security of P2SH and SegWit transactions, then Iwould have far less to object to.

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.

1. Whether the soft fork rules have been followed, and2. Whether the WT^ submitted by a majority hashrate matches the one calculated by sidechain nodes.The first case is exactly equal to P2SH. Just as old nodes accept every P2SH transaction, so too will [DC#0] users accept every WT^ transaction.

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

They are irrelevant to my argument.

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

This is false.

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

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

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.

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:

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

Post by Paul Sztorc via bitcoin-devFYI 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-devAlso, 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-devBecause 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.

1. Whether the soft fork rules have been followed, and2. 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.

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

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

In his message he claims to uniquely adopt definition #2, saying

Post by Tao Effect via bitcoin-devI was very clear what I meant by "invalid" in my email: WT^transactions that represent miners stealing funds. **Please stick tothat** 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 willfirst clarify both cases:

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

Post by Paul Sztorc via bitcoin-devIn point of fact, he is wrong, because nodes do the counting. Whenminers find a block, they can choose to move the counter up, down, ornot 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 rulesis a neglect of **both** theft_1 and theft_2 simultaneously, making iteasier to conflate the both of them as Greg is still doing.

Post by Paul Sztorc via bitcoin-devIn the second case, it so happens that [DC#1], [DC#2], and [DC#3]would also accept any WT^ *that followed the Drivechain rules*, evenif they did not like the outcome (because the outcome in question wasarbitrarily designated as a "theft" of funds -- again, see the secondcase in the list above). In this way, it is exactly similar to P2SHbecause nodes will accept *any* p2sh txn **that follows the p2shrules**, even if they don't "like" the specific script containedwithin (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 codedto explicitly allow them to do it.How many P2SH scripts are you aware of that are used for the purposeof facilitating such theft?I know of none, and I bet there are none.

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

Under theft_2, there is no way to infer the theft-ness of thetransaction from the script itself. For example, if someone made a2-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 wasreckless and...allowed Bitcoins to be "stolen". Or perhaps he wouldswitch definitions yet again, and say that "that doesn't count astheft". 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 enablesidechains. Sidechains logically must open the door to theft_2, elsethey will regress to the undesirable cases of hard/evil fork (as Iexplain in the spec). Empirically, we do not know how much theft_2 willbe enabled by drivechain. Theoretically, it is possible that there willnever be a theft_2 on drivechain.

So, here you are again re-affirming that WT^ transactions representingstolen funds are allowed in DC, and by tying them all together you arealso affirming that the SPV proofs mentioned in DC are completelyirrelevant / pointless / unused.

I do not affirm the latter. The SPV proofs in DC are very important, asthey 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, CEOof Blockstream which started the sidechains conversation) have publiclystated that they share my belief that this delayed withdrawal techniqueis likely to mitigate the threat of theft_2. Greg S is free to hold adifferent opinion.

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

So in the first sentence you say they "cannot steal funds", buteverything else you've said, including the following paragraph, andyour 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 onecan "steal_1" funds in that case.

The reason I assumed Greg was talking about theft_1 and not theft_2, isbecause he mentioned P2SH and the fact that full nodes automaticallyenforce 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 questionsabout them, and then try to discover "contradictions" in the mess thatfollows. But it is all a function of his conflation of terminology andnothing else.

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

With drivechains, it seems like the current plan is to only let the nodesthat are interested in the drivechain validate the other chain, and notnecessarily 100% of the network.I guess this could be any percentage of the network, which could lead to atemporary/permanent chainsplit depending on how many percentage of theminers 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% ofall fullnodes validate the drivechain.

To be fully secure, it seems like 100% of all nodes should also have afullnode for the drivechain as well...This is one of the reasons I don't advocate sidechains/drivechains as ascaling solution, it looks like it would have to the same outcome as ablocksize 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-devI will repeat that Drivechain can sometimes be confusing because it isdifferent things to different people.[DC#0] -- Someone who does not upgrade their Bitcoin software (and isrunning, say, 0.13). However, they experience the effects of the new ruleswhich miners add (as per the soft fork[s] to add drivechain functionalityand individual drivechains).[DC#1] -- Someone who always upgrades to the latest version of the Bitcoinsoftware, but otherwise has no interest in running/using sidechains.[DC#2] -- Someone who upgrades to the latest Bitcoin version, and decidesto also become a full node of one or more sidechains, but who ever actuallyuses 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, heequivocates on the team "steal", using it to mean two different things: [a]spending an invalid transaction, and [b] a withdrawal that would not matchthe report given by a sidechain node.FYI that document is nearly two years old, and although it is stilloverwhelmingly accurate, new optimizations allow us (I think) to push thewaiting period to several weeks and the total ACK counting period up toseveral months.What does that have to do with my question? The counting period, if Iunderstood correctly, is something miners do, not full nodes.Greg quoted a passage that contained an older parameter estimate of "a fewdays", and I thought it would be helpful and informative if I clarifiedthat 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 minersfind 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 linkto a more update-to-date version of the spec? It would be helpful forreview.As I stated above, the document is mostly accurate. There is no other moreup to date version.Because if a node doesn't have the sidechain's information, it will justassume every withdrawal is valid. This is comparable to someone who stillhasn'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 P2SHThe answer is that both DC and P2SH use transactions which are 'alwaysvalid' to some group of people (un-upgraded users) but which are sometimesinvalid to new users. So the only difference would be for [DC#0] vs otherversions, 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, and2. Whether the WT^ submitted by a majority hashrate matches the onecalculated by sidechain nodes.The first case is exactly equal to P2SH. Just as old nodes accept everyP2SH 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] wouldalso accept any WT^ *that followed the Drivechain rules*, even if they didnot like the outcome (because the outcome in question was arbitrarilydesignated as a "theft" of funds -- again, see the second case in the listabove). In this way, it is exactly similar to P2SH because nodes willaccept *any* p2sh txn **that follows the p2sh rules**, even if they don't"like" the specific script contained within (for example, because it is atheft of "their" BitFinex funds, or a donation to a political candidatethey dislike, etc).[DC#2] and [DC#3] would certainly have an interest in understanding whatis going on, but that has absolutely nothing whatsoever to do with BitcoinCore 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 favoritecolor or my home address. And such answers would needlessly consume themailing list's scarce time.What does "[DC#2] and [DC#3] would certainly have an interest inunderstanding what is going on" mean?It is clear to me that, if we are not clear on the basics first, we cannothope to tackle anything intermediate. We will come back to this afterclearing 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 invalidWT^ transaction â invalid in the sense that it contains funds which minersare 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 afully automatic enforcement policy.In DC, miners cannot steal funds, because all full nodes have a fullyautomatic enforcement policy.However, DC *allows* users to choose to place some of their BTC at therelative mercy of the miners in creative ways, if they wish (as does P2SH-- someone could write a script which donates funds to miners, and thenfund it... "paying" to that script). This is another example of conflating[DC#1] and [DC#3].PaulThe 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 isrunning, say, 0.13). However, they experience the effects of the new ruleswhich miners add (as per the soft fork[s] to add drivechain functionalityand individual drivechains).[DC#1] -- Someone who always upgrades to the latest version of the Bitcoinsoftware, but otherwise has no interest in running/using sidechains.[DC#2] -- Someone who upgrades to the latest Bitcoin version, and decidesto also become a full node of one or more sidechains, but who ever actuallyuses 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 anopportunity to make sure the same WT^ is in both the Bitcoin coinbase andthe Sidechain header. If theyâre different, everyone has plenty of time tocontact each other, figure out what is going on, and restart the processuntil 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 thesame as P2SH (and in later emails you reference SegWit as well). Is thisreally true?FYI that document is nearly two years old, and although it is stilloverwhelmingly accurate, new optimizations allow us (I think) to push thewaiting period to several weeks and the total ACK counting period up toseveral months.[DC#0] Yes[DC#1] Yes[DC#2] Yes[DC#3] YesBecause if a node doesn't have the sidechain's information, it will justassume every withdrawal is valid. This is comparable to someone who stillhasn'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 transactionscontain all of the information within themselves for full nodes to act as acheck on miners mishandling the anyone-can-spend nature of P2SHtransactions. 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 justautomatically 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 whatis going on, but that has absolutely nothing whatsoever to do with BitcoinCore and so is off-topic for this mailing list.If the security of WT^ transactions could be brought up to actually be inline with the security of P2SH and SegWit transactions, then I would havefar less to object to.Somehow I doubt it.Paul_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Post by Hampus SjÃ¶berg via bitcoin-devIn softforks, I would argue that 100% of all nodes and miners need toupgrade 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 thenodes that are interested in the drivechain validate the other chain,and not necessarily 100% of the network.

Correct.

Post by Hampus SjÃ¶berg via bitcoin-devI guess this could be any percentage of the network, which could leadto a temporary/permanent chainsplit depending on how many percentageof the miners are also validating the other chain (am I missingsomething here?).I have no way to evaluate if this is an okay trade-off.It seems like major disruption could very likely happen if say only 5%of all fullnodes validate the drivechain.

You are correct that some % of the network would be validating bothchains. However, if miners improperly withdraw from a sidechain, it --bydesign-- does not lead to any chainsplit of any kind. Instead, thesidechain in question just dies a painful death (notice that, if anywithdrawals are improper, it is quite as bad as if all of the sidechainfunds were withdrawn improperly -- this is because the sidechain wouldinstantly have a bunch of problems, including that it would besomething-like 'fractional reserve' which would lead to an immediatebank run of withdrawals [none of which could have any real expectationof success, in my view]).

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

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

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

Post by Hampus SjÃ¶berg via bitcoin-devThis is one of the reasons I don't advocate sidechains/drivechains asa scaling solution, it looks like it would have to the same outcome asa blocksize increase on the mainchain, but with more complexity.

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

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

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

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