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