rich1.0npub1jp0jnnq2jxcjy76nrt5dssvmpynt4f9psdelp3vxj0y0xtpxl7jqhkn8jwhttps://nostr.ae/npub1jp0jnnq2jxcjy76nrt5dssvmpynt4f9psdelp3vxj0y0xtpxl7jqhkn8jwnjumphttps://nostr.ae📅 Original date posted:2014-04-23 📝 Original message:What is the advantage of this proposal over just orphaning the block with double spends? There's currently a set of rules which government what constitutes a valid block. Miners don't build on blocks that don't accord with those rules out of fear that a major won't follow and they will waste hashing power. If there was a rule supported by the majority that considered blocks with double spends (defined in some fashion) as invalid miners wouldn't build on them for the same reason they wouldn't build on a block with a coinbase over 25 btc, say. It seems that would accomplish the same without the other issues. On Apr 23, 2014 12:04 PM, "Christophe Biocca" <christophe.biocca at gmail.com> wrote: > It's not necessary that this "coinbase retribution" be either > profitable or risk-free for this scheme to work. I think we should > separate out the different layers of the proposal: > > 1. Attacking the coinbase instead of orphaning allows for 100 blocks' > time for a consensus to be reached, rather than 10 minutes. This > allows for human verification/intervention if needed (orphaning > decisions would almost always need to be automated, due to the short > timeframe). This is a useful insight, and I don't think it's been > brought up before. > > 2. The original specification of how it's done (redistribution, no > cost to voting) does seem exploitable. This can be fixed by reducing > the incentive (burning instead of redistributing) and/or adding a risk > to the orphaning attempts (a vote that fails destroys X bitcoins' > worth from each voting block's own coinbase). The incentives can be > tailored to mirror those of orphaning a block, to reduce the risk of > abuse. Then the only difference from orphaning are 1) More limited > rewriting of history (only the coinbase, vs all transactions in the > block), and 2) More time to coordinate a response. > > 3. This proposal may be used for things other than punishing > double-spend pools. In fact it might be used to punish miners for > doing anything a significant percentage of hashpower dislikes (large > OP_RETURNs, large blocks, gambling transactions, transactions banned > by a government). But we can make the threshold higher than 51%, so > that this doesn't turn into a significant risk (if 75% of hashpower is > willing to enforce a rule, we're already likely to see it enforced > through orphaning). > > On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi <alex.mizrahi at gmail.com> > wrote: > > > >> > >> And it still would. Non-collusive miners cast votes based on the outcome > >> of their own attempts to double spend. > > > > > > Individually rational strategy is to vote for coinbase reallocation on > every > > block. > > > > Yes, in that case nobody will get reward. It is similar to prisoner's > > dilemma: equilibrium has worst pay-off. > > In practice that would mean that simple game-theoretic models are no > longer > > applicable, as they lead to absurd results. > > > >> > >> I'm using it in the same sense Satoshi used it. Honest miners work to > >> prevent double spends. That's the entire justification for their > existence. > >> Miners that are deliberately trying to double spend are worse than > useless. > > > > > > Miners work to get rewards. > > It absolutely doesn't matter whether they are deliberately trying to > > double-spend or not: they won't be able to double-spend without a > collusion. > > > > > ------------------------------------------------------------------------------ > > Start Your Social Network Today - Download eXo Platform > > Build your Enterprise Intranet with eXo Platform Software > > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > > Get Started Now And Turn Your Intranet Into A Collaboration Platform > > http://p.sf.net/sfu/ExoPlatform > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development at lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > ------------------------------------------------------------------------------ > Start Your Social Network Today - Download eXo Platform > Build your Enterprise Intranet with eXo Platform Software > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > Get Started Now And Turn Your Intranet Into A Collaboration Platform > http://p.sf.net/sfu/ExoPlatform > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/48d8a89a/attachment.html>