Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 30/04/14 00:26, Mike Hearn wrote: These parties wouldn't generally consider themselves attackers Of course not, attackers rarely do :) If Bitcoin works correctly nobody should have to care if they consider themselves attackers, defenders, or little green men from Mars. There are simply nodes that follow the protocol, and nodes that do not. The fact that you even need to think about who should and should not be considered an attacker, in the context of your proposed change, should be ringing alarm bells :) What do you think miners exist for? Ordering transactions. signature.asc Description: OpenPGP digital signature -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 30/04/14 00:13, Mike Hearn wrote: I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. I haven't seen anybody arguing that it is. Bitcoin is the elegant embodiment of /artificially contrived/ mathematical rules, which just so happen to be very useful in their current configuration :-P Nobody is saying those rules are immutable. Just that it isn't sensible to undermine them by introducing imprecise and unpredictable elements like human politics. Every time miners and nodes ignore a block that creates formula() coins that's a majority vote on a controversial political matter No it isn't. That's the node enforcing the protocol. It isn't a matter of opinion, and it isn't a vote. The protocol is clearly defined: you either follow it or you're not running a Bitcoin node. If 51% don't follow it tomorrow /they're/ not running Bitcoin. Contrast with your vote to reinterpret the meaning of arbitrary blocks mechaism - you're free to vote either way while remaining within the protocol. That's a /real/ vote - majority decides what the Bitcoin protocol /and every node that follows it/ will recognise as valid. Nothing like that currently exists. Thank $deity. signature.asc Description: OpenPGP digital signature -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
I think we're going around in circles here so this will be my last message on the thread unless someone comes up with something new. On Wed, Apr 30, 2014 at 3:12 PM, Gareth Williams gac...@gmail.com wrote: If Bitcoin works correctly nobody should have to care if they consider themselves attackers, defenders, or little green men from Mars. One last time, I request that people read the white paper from 2008 before making statements like this. If the notion of attacker was irrelevant to Bitcoin, it would not be mentioned in the abstract, would it? -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 30/04/14 00:13, Mike Hearn wrote: Every time miners and nodes ignore a block that creates formula() coins that's a majority vote on a controversial political matter Actually, there's one more thing I'd like to add. Apologies to the list, but it bears repeating: * rejecting a block at validation Is /very different/ from: * reinterpreting a block that has already passed validation Nodes ignoring a block that creates formula() coins is rejection at block *validation*. That's the protocol working as it is supposed to. It's deliberately an all-or-nothing mechanism; you can't pick and choose which blocks you like. If 51% of the network say your block is invalid, they're now on a different fork. The consequences are this drastic on purpose, for stability. Nodes reinterpreting a block that has already passed validation is almost the polar opposite of this. They're /ignoring the protocol/ and making up their own meaning for stuff. Sidestepping the mechanism in the paragraph above. I would hope it'd be self evident that this is dangerous. Adam Back is arguing practicality in this thread. I'm arguing fundamental principle. (And, er, someone else is randomly throwing around ad hominems, which we'll politely ignore; Mike could work for Lucifer himself and his good ideas would still be good, and his bad ideas would still be bad, so let's just stick to the ideas eh.) So, fundamental principle: don't reinterpret history! We have validation for a very good reason. Undermine it and you might as well have an unvalidated system like Counterparty, which I wouldn't ever trust with more than the value of a small hamburger. If the economic majority starts reinterpreting history (through whatever voting mechanism / side-channel you like) that completely undermines Bitcoin's validation, and its PoW. It's worse than 51% of miners deciding to rewrite history. signature.asc Description: OpenPGP digital signature -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 30/04/14 23:55, Mike Hearn wrote: If Bitcoin works correctly nobody should have to care if they consider themselves attackers, defenders, or little green men from Mars. One last time, I request that people read the white paper from 2008 before making statements like this. If the notion of attacker was irrelevant to Bitcoin, it would not be mentioned in the abstract, would it? I've read it :) The notion of an attacker is obviously relevant to someone designing the system. It should not be relevant to someone running a node. I'll retire from posting on this too, I've posted way too much. Our fundamental disagreement is simply that you think Bitcoin is, or should be, a /democratic/ system. I think Bitcoin is, and should be, a /trustless/ system. If we're going to resort to appeal to authority, I'll point to the words Electronic Cash System in the title of Satoshi's whitepaper :-P He intended to create ecash; that's widely understood to mean trustless. If there was this magic computer up in the sky somewhere, free from human influence, that would run Satoshi's code for him in perpetuity (let's overlook the initial upload please, bear with me), then I believe Satoshi would've built his perfectly trustless ecash to run on that. For lack of such a magic masterless computer he had to approximate one, ingeniously using distributed consensus to achieve it. That's his real invention - the magic masterless computer simulator, and the incentive scheme to get the world to run it for him. (We'll see more of what it can do if Ethereum ever gets off the ground.) But for Pete's sake, Bitcoin is trustless. Just because the infrastructure it sits atop is democratic (because there was no other way to implement it,) doesn't mean you suddenly have to start voting on everything. signature.asc Description: OpenPGP digital signature -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wed, Apr 30, 2014 at 11:00:06PM +1000, Gareth Williams wrote: On 30/04/14 00:13, Mike Hearn wrote: I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. I haven't seen anybody arguing that it is. Bitcoin is the elegant embodiment of /artificially contrived/ mathematical rules, which just so happen to be very useful in their current configuration :-P Nobody is saying those rules are immutable. Just that it isn't sensible to undermine them by introducing imprecise and unpredictable elements like human politics. As an end-user of Bitcoin, the whole possible value of a set of mathematical rules has become completely trashed by the imprecise and unpredictable behavior of buyers and sellers. If the rules are not responsive to real human needs, bitcoin is worthless as a long-term store of value because **my idea of value** changes over time. This implies, in my mind, an absolutely requirement to attempt to gather some useful signal from the human political noise. How do you determine what that signal is, so you can **change the rules** and the mathematics so it makes more sense? You've got to deal with politics, one way or another. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Perhaps I missed it somewhere, but I don't recall it ever being a goal of Bitcoin to act as a stable long-term store of value. - Jameson On 04/30/2014 01:06 PM, Troy Benjegerdes wrote: On Wed, Apr 30, 2014 at 11:00:06PM +1000, Gareth Williams wrote: On 30/04/14 00:13, Mike Hearn wrote: I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. I haven't seen anybody arguing that it is. Bitcoin is the elegant embodiment of /artificially contrived/ mathematical rules, which just so happen to be very useful in their current configuration :-P Nobody is saying those rules are immutable. Just that it isn't sensible to undermine them by introducing imprecise and unpredictable elements like human politics. As an end-user of Bitcoin, the whole possible value of a set of mathematical rules has become completely trashed by the imprecise and unpredictable behavior of buyers and sellers. If the rules are not responsive to real human needs, bitcoin is worthless as a long-term store of value because **my idea of value** changes over time. This implies, in my mind, an absolutely requirement to attempt to gather some useful signal from the human political noise. How do you determine what that signal is, so you can **change the rules** and the mathematics so it makes more sense? You've got to deal with politics, one way or another. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. Every time miners and nodes ignore a block that creates formula() coins that's a majority vote on a controversial political matter, as evidenced by the disagreement with mainstream economics and that it's one of the most common things for alt coins to change. Indeed Satoshi's chosen inflation formula is a highly political statement on the value of inflation - he could have programmed Bitcoin to inflate forever and avoided a whole area of politics, but he chose not to. So please, let's agree to accept that Bitcoin is ultimately just a piece of software that encodes rules helping us run our little community in some specific ways. It's not physics and we should believe our own hype by pretending it is. On Mon, Apr 28, 2014 at 11:41 PM, Adam Back a...@cypherspace.org wrote: I think the reason that it would likely work out badly is that its not provable, and so no consensus rule can be constructed requiring proof, so then it risks devolving to a political decision. It's the other way around. If miners decide to fork the chain then that leaves no proof (beyond the old blocks, which could have been a natural fork - there's no way to know - and nodes don't want to keep them around anyway). If they explicitly vote to get the same effect but without actually forking, it leaves a proof in the form of the votes in the coinbase that can be seen afterwards. Step 3: Finney attackers vote down other pools to make the point. It only works if the majority of hashpower is controlled by attackers, in which case Bitcoin is already doomed. So it doesn't matter at that point. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Tue, Apr 29, 2014 at 7:13 AM, Mike Hearn m...@plan99.net wrote: It only works if the majority of hashpower is controlled by attackers, in which case Bitcoin is already doomed. So it doesn't matter at that point. These parties wouldn't generally consider themselves attackers— nor would many users (presumably everyone who mines on ghash.io, for example)— rather they'd they may consider someone using hashpower voting to reassign coins to be an attacker, and reassigning their coins instead to be a morally justified and pragmatic response. I think we're capable here of discussing the specifics without needing to use generalizations which invite definitional arguments... I don't think that bombastic language like doomed helps the dialog. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
These parties wouldn't generally consider themselves attackers Of course not, attackers rarely do :) But they are miners who are taking part in malicious double spending. That makes them attackers. If miners don't exist to stop double spending, what do they exist for? I mean, this is fundamental. What do you think miners exist for? -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/29/2014 02:13 PM, Mike Hearn wrote: I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. I think everybody understands that Bitcoin has a positive net present value exactly because it, unlike every other digital currency which came before, does not include a feature that allows for balances to be confiscated. Implementing any such feature, to any degree at all, would render Bitcoin completely valueless. There are two possibilities here: If you understand this, then your proposal is a malicious attempt to undermine Bitcoin. If you don't understand this then you suffer from a very serious case of economic illiteracy, a case so bad that your continued participation in Bitcoin represents a clear and present danger to all Bitcoin users. If you can't even get the easy questions right, then god help us all if you're ever faced with a difficult one. I don't have enough evidence to distinguish between the incompetence hypothesis and the malice hypothesis, but it doesn't matter. Regardless of your abilities or motives your proposal is unacceptable. If you want a currency where miners can vote to steal from other miners then implement it in Hearncoin and leave Bitcoin alone. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTX/2dAAoJECoisBQbQ4v0jAoH/R1oNZ1tVp6DJ5BuPg0ZTav0 Dvzq8EfX/uRbRgmxotCHMwY6FJCoXqJTLyOnl2p670t7l5ZXqd91MdKKP2z7jYPY GsVbqfGreF0dWKCd0mKTG5DM8pxndNWteGIsw9/sYvY/3p2Vopzp6N7fpl8TEf6p 2nyIzEqTD4aK5QkhM+sNnP1Cyh/l5AjJTES23GqSQIMG6vzLgqE8kyze+ANFVg1U yka6bz4DX7DO7meyJyyOFaMJu6mgY+m6dSVaR7j/QmQMu22SwlSiPgqe6iO//os3 zcmwe/x4+5CmqJOO/PL5Or28iw/Qdf6vNePiaEIFtBzoKnHBhS2nAtL6jnOL928= =4yIu -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 27/04/14 11:42, Christophe Biocca wrote: This seems like splitting hairs, no? A block isn't a guarantee (it can get orphaned). And as a user of bitcoin (as opposed to a miner), this change cannot affect any payment you ever receive. Disagree. Maybe we just have a fundamental disagreement about what Bitcoin is? :) Bitcoin is this perfect /trustless/ mathematical machine, built - most unfortunately - upon a foundation of mushy humans. We depend specifically upon these three assumptions: 1. 50% of hashpower will not cooperate to rewrite history 2. the economic majority will not cooperate to reinterpret history 3. enough people believe in the illusion of artificial scarcity to give it real value Given that the above hold, from there up the system operates completely trustlessly, with predictable security parameters. (Of course a block isn't a guarantee of anything, but I know the probability that you can cause a re-org from depth N with X% hashpower, which allows me to reason about security.) Now, some people on this thread might point to the above 3 points and say that isn't really a trustless system, it's a democratic system. And then advocate that we can do without assumption 2, replacing it with: 2. the economic majority will not cooperate to reinterpret history against any good guys, only against bad guys; please trust their good judgement. That moves us away from a pure trustless system built upon a small democratic foundation (as something of a necessary evil in an imperfect world where humans run our computers and use our system) and toward a democratic system. You don't have to agree, but I hope you can understand the point I'm making :-) It's a fundamental shift in the nature of the system, and to some people a violation of the social contract. Definitely not splitting hairs. I feel I've now consumed rather more bytes of everyone's inboxes than I ought to have with this topic. I appreciate you and Mike taking the time to reply to a newbie/lurker. -Gareth signature.asc Description: OpenPGP digital signature -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
That moves us away from a pure trustless system built upon a small democratic foundation (as something of a necessary evil in an imperfect world where humans run our computers and use our system) and toward a democratic system. You don't have to agree, but I hope you can understand the point I'm making :-) Yep, your point is well made. I don't have much more to say about this proposal specifically, but I think this whole question of what changes are OK and what would be a violation of the social contract will get discussed endlessly over the coming years. Put another way, what do Bitcoin's users expect and want - a system that evolves or a system that remains exactly as they found it? There will be good arguments on both sides, and the answer will probably be different on a case by case basis. But personally I'm skeptical of any argument that argues against change for its own sake. It has to be an argument rooted in a careful analysis of costs and benefits. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Agreed. I'm a pragmatist, certainly not anti-change (or even anti-zero-conf.) Useful and non-controversial hard forks don't keep me awake at night :) I support your general position on zero-conf payments (that they're useful and we should make them as reliable as practical.) But the very essence of Bitcoin, to me, is trustlessness. Satoshi's great invention isn't just another payment network - it's /ecash/. Bearer-negotiable, whoever-controls-the-private-keys-owns-it, **ecash**. If not that, what do you think it is? :-) I like trustless systems for purely pragmatic, cost-benefit reasons. They allow us to avoid all the costs associated with imperfect humans, while reaping the benefits of reliability and predictability :P On 28 April 2014 12:31:05 AM AEST, Mike Hearn m...@plan99.net wrote: That moves us away from a pure trustless system built upon a small democratic foundation (as something of a necessary evil in an imperfect world where humans run our computers and use our system) and toward a democratic system. You don't have to agree, but I hope you can understand the point I'm making :-) Yep, your point is well made. I don't have much more to say about this proposal specifically, but I think this whole question of what changes are OK and what would be a violation of the social contract will get discussed endlessly over the coming years. Put another way, what do Bitcoin's users expect and want - a system that evolves or a system that remains exactly as they found it? There will be good arguments on both sides, and the answer will probably be different on a case by case basis. But personally I'm skeptical of any argument that argues against change for its own sake. It has to be an argument rooted in a careful analysis of costs and benefits. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 26/04/14 01:28, Mike Hearn wrote: When you have a *bitcoin* TXn buried under 100 blocks you can be damn sure that money is yours - but only because the rules for interpreting data in the blockchain are publicly documented and (hopefully) immutable. If they're mutable then the PoW alone gives me no confidence that the money is really mine, and we're left with a much less useful system. This should be more sacred than the 21m limit. Well, I think we should avoid the term sacred - nothing is sacred because we're not building a religion here, we're engineering a tool. Are you sure there isn't room for just a touch of religion? :) As you state below, all that protects my money from confiscation is strong group consensus that it's mine - a social rule, not a mathematical one. Everything ultimately balances on that. People being a little bit religious about following the protocol faithfully are the linchpin of Bitcoin security, not PoW. Consider a world in which 1 satoshi is too valuable to represent some kinds of transactions, so those transactions stop happening even though we all agree they're useful. The obvious solution is to change the rules so there can be 210 million coins and 10x everyones UTXOs at some pre-agreed flag day. We probably wouldn't phrase it like that, it's easier for people to imagine what's happening if it's phrased as adding more places after the decimal point or something, but at the protocol level coins are represented using integers, so it'd have to be implemented as a multiply. Agree. Would this be a violation of the social contract? A violation of all that is sacred? I don't think so, it'd just be sensible engineering and there'd be strong consensus for that exactly because 21 million /is/ so arbitrary. If all balances and prices multiply 100-fold overnight, no wealth is reallocated which would be the /actual/ violation of the social contract: we just get more resolution for setting prices. Wholeheartedly agree. 21 million is just shorthand for the preservation of artificial scarcity. No rational person could argue that what you described violates the social contract. I do see what you're driving at - that there exists a situation where it would be justified to change the interpretation of data in existing blocks. But, please consider: if I controlled a single UTXO worth 1% of the total money supply before your change, the network would still recognise that I control a single UTXO worth 1% of the total money supply after your change. So you haven't really changed the interpretation of existing blocks at all there. It's just semantics :) Contrast this with invalidating a coinbase before maturity, which clearly has a very real impact. At the point the vote passes, you're *** sidestepping the PoW mechanism and rewriting the meaning of an existing, validated block ***. So. The thing that protects your money from confiscation is not proof of work. PoW is just a database synchronisation mechanism. The thing that protects your money from confiscation is a strong group consensus that theft is bad. But that's a social rule, not a mathematical rule. Agree. That's my whole point :) I recognise my security is in the hands of the users (the economic majority.) Tomorrow they could all decide to patch their nodes to reallocate my UTXOs, and there's not a damn thing I could do about it, PoW and private keys notwithstanding. I must simply trust that they will not do this. So we can have: 1. Neutral Bitcoin, where everyone is committed to prevention of theft by following a simple set of mathematical rules which treat all validated blocks as equal. Or: 2. Political Bitcoin, where everyone is committed to prevention of theft based on human judgements, and the contents of some validated blocks are more equal than others. I recognise that the latter allows for a lot of flexibility in combating fraud, but with (substantial) due respect, it isn't Bitcoin. -Gareth signature.asc Description: OpenPGP digital signature -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
This seems like splitting hairs, no? A block isn't a guarantee (it can get orphaned). And as a user of bitcoin (as opposed to a miner), this change cannot affect any payment you ever receive. Some of the interpretation is already different for coinbase UTXO's (need a valid height, locked for 100 blocks). Anyone expecting them to behave like any other UTXO will get bitten by one of those subtleties (MtGox's withdrawals had issues with exactly this, IIRC). On Sat, Apr 26, 2014 at 8:15 AM, Gareth Williams gac...@gmail.com wrote: On 26/04/14 01:28, Mike Hearn wrote: When you have a *bitcoin* TXn buried under 100 blocks you can be damn sure that money is yours - but only because the rules for interpreting data in the blockchain are publicly documented and (hopefully) immutable. If they're mutable then the PoW alone gives me no confidence that the money is really mine, and we're left with a much less useful system. This should be more sacred than the 21m limit. Well, I think we should avoid the term sacred - nothing is sacred because we're not building a religion here, we're engineering a tool. Are you sure there isn't room for just a touch of religion? :) As you state below, all that protects my money from confiscation is strong group consensus that it's mine - a social rule, not a mathematical one. Everything ultimately balances on that. People being a little bit religious about following the protocol faithfully are the linchpin of Bitcoin security, not PoW. Consider a world in which 1 satoshi is too valuable to represent some kinds of transactions, so those transactions stop happening even though we all agree they're useful. The obvious solution is to change the rules so there can be 210 million coins and 10x everyones UTXOs at some pre-agreed flag day. We probably wouldn't phrase it like that, it's easier for people to imagine what's happening if it's phrased as adding more places after the decimal point or something, but at the protocol level coins are represented using integers, so it'd have to be implemented as a multiply. Agree. Would this be a violation of the social contract? A violation of all that is sacred? I don't think so, it'd just be sensible engineering and there'd be strong consensus for that exactly because 21 million /is/ so arbitrary. If all balances and prices multiply 100-fold overnight, no wealth is reallocated which would be the /actual/ violation of the social contract: we just get more resolution for setting prices. Wholeheartedly agree. 21 million is just shorthand for the preservation of artificial scarcity. No rational person could argue that what you described violates the social contract. I do see what you're driving at - that there exists a situation where it would be justified to change the interpretation of data in existing blocks. But, please consider: if I controlled a single UTXO worth 1% of the total money supply before your change, the network would still recognise that I control a single UTXO worth 1% of the total money supply after your change. So you haven't really changed the interpretation of existing blocks at all there. It's just semantics :) Contrast this with invalidating a coinbase before maturity, which clearly has a very real impact. At the point the vote passes, you're *** sidestepping the PoW mechanism and rewriting the meaning of an existing, validated block ***. So. The thing that protects your money from confiscation is not proof of work. PoW is just a database synchronisation mechanism. The thing that protects your money from confiscation is a strong group consensus that theft is bad. But that's a social rule, not a mathematical rule. Agree. That's my whole point :) I recognise my security is in the hands of the users (the economic majority.) Tomorrow they could all decide to patch their nodes to reallocate my UTXOs, and there's not a damn thing I could do about it, PoW and private keys notwithstanding. I must simply trust that they will not do this. So we can have: 1. Neutral Bitcoin, where everyone is committed to prevention of theft by following a simple set of mathematical rules which treat all validated blocks as equal. Or: 2. Political Bitcoin, where everyone is committed to prevention of theft based on human judgements, and the contents of some validated blocks are more equal than others. I recognise that the latter allows for a lot of flexibility in combating fraud, but with (substantial) due respect, it isn't Bitcoin. -Gareth -- 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
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Proving that you can convince the economic majority that the interpretation of existing blocks is in any way up for grabs would set a dangerous precedent, and shake some people's faith in Bitcoin's overall robustness and security (well, mine anyway.) Hmm, then I think your faith needs to be shaken. Bitcoin is money, and money is a purely artificial social construct. The interpretation of what a bitcoin means, or what a dollar means, has always been and always will be a human decision taken in order to achieve some socially useful goal. How could it be any other way? Do you want humanity to be enslaved by its own money? This notion that the block chain encodes some kind of natural, immovable law that's above human judgement is a very strange one to me - I guess it comes from the fact that encryption *is* based on some kind of natural law. Without the key you can't decrypt a message no matter how strong the consensus is. But Bitcoin doesn't use encryption anywhere, just digital signatures. The only thing approaching natural law, that stops majority consensus controlling everything, is lack of information. Hence all the discussion around privacy and anonymity that goes on all the time. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 25/04/14 20:17, Mike Hearn wrote: Proving that you can convince the economic majority that the interpretation of existing blocks is in any way up for grabs would set a dangerous precedent, and shake some people's faith in Bitcoin's overall robustness and security (well, mine anyway.) Hmm, then I think your faith needs to be shaken. Bitcoin is money, and money is a purely artificial social construct. The interpretation of what a bitcoin means, or what a dollar means, has always been and always will be a human decision taken in order to achieve some socially useful goal. My argument does not concern what a bitcoin means, just what data in the blockchain means. People are free to value an individual bitcoin however they like. But it's useful if we all agree on a standard that defines who owns them - ie. the protocol as described in Satoshi's whitepaper. I recognise that your ability to provide a valid scriptSig for /any existing UTXO in the blockchain/ as proof of your ownership of the corresponding bitcoin. You want to pick and choose which UTXO (well, coinbase; same diff) you consider valid and spendable /after they've become part of the blockchain/, regardless of the fact they're buried under PoW. As an illustration, consider Counterparty - an altcoin whose TXns are embedded as unvalidated data in the bitcoin blockchain. A lot of people imagine that an XCP transaction buried under 100 blocks and a BTC transaction buried under the same 100 blocks are equally secure. You tell me: are they? It's the same PoW chain after all. Hell no they're not! The way Counterparty interprets that data in the blockchain is anything but stable or well documented. On more than one occasion they've gone whoops, found a bug that caused some transactions to occur that we don't consider valid - we'll just fix that. A suddenly the reference client doesn't consider the XCP in your wallet valid anymore - they just magically disappear - because the parent of the TXn that paid you was actually invalid. Nobody rewrote history via PoW; they simply tweaked their interpretation of the existing history. When you have a *bitcoin* TXn buried under 100 blocks you can be damn sure that money is yours - but only because the rules for interpreting data in the blockchain are publicly documented and (hopefully) immutable. If they're mutable then the PoW alone gives me no confidence that the money is really mine, and we're left with a much less useful system. This should be more sacred than the 21m limit. signature.asc Description: OpenPGP digital signature -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
When you have a *bitcoin* TXn buried under 100 blocks you can be damn sure that money is yours - but only because the rules for interpreting data in the blockchain are publicly documented and (hopefully) immutable. If they're mutable then the PoW alone gives me no confidence that the money is really mine, and we're left with a much less useful system. This should be more sacred than the 21m limit. Well, I think we should avoid the term sacred - nothing is sacred because we're not building a religion here, we're engineering a tool. Consider a world in which 1 satoshi is too valuable to represent some kinds of transactions, so those transactions stop happening even though we all agree they're useful. The obvious solution is to change the rules so there can be 210 million coins and 10x everyones UTXOs at some pre-agreed flag day. We probably wouldn't phrase it like that, it's easier for people to imagine what's happening if it's phrased as adding more places after the decimal point or something, but at the protocol level coins are represented using integers, so it'd have to be implemented as a multiply. Would this be a violation of the social contract? A violation of all that is sacred? I don't think so, it'd just be sensible engineering and there'd be strong consensus for that exactly because 21 million *is* so arbitrary. If all balances and prices multiply 100-fold overnight, no wealth is reallocated which would be the *actual* violation of the social contract: we just get more resolution for setting prices. So. The thing that protects your money from confiscation is not proof of work. PoW is just a database synchronisation mechanism. The thing that protects your money from confiscation is a strong group consensus that theft is bad. But that's a social rule, not a mathematical rule. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Thu, Apr 24, 2014 at 12:58 AM, Mike Hearn m...@plan99.net wrote: The complexity overhead is trivial - we already used coinbase scriptSigs for voting on P2SH, I'm sure it'll be used for voting on other things in future too. We use coinbase sigs to gauge the safety of enforcing a soft fork several times and not just for P2SH, to determine when enforcement of it will be decisive and not result in risking a partition in the network that might permit transaction reversals. This is not voting. As a feature decision mechanism his is a rather coercive thing because it gives the highest hash-power bidders control even when their interests may be rather thoroughly unaligned with population that owns and uses bitcoin in general, but as a plain indicator of when its safe to enforce a new rule (same mechanism, different motivation— though a point is that safe usage means using much more than 50% as the threshold) it works pretty well. that's hugely complex and messy. Yes, making really distributed systems that work in a complex world is hard. It certantly would be /easier/ to just declare miners trusted parties and require them to always collude to produce a single consensus view of the world that is always honest and never contradictory, except that it doesn't work. Because they aren't individually trusted or even trustworthy. Why? Remember deleting coinbases with nothing more than a simple majority is already possible in the existing protocol and always has been. Temporarily censoring transactions by orphaning otherwise valid blocks that contain them for as long as you retain a majority is possible and impossible to prevent in this architecture. This isn't the same as deleting. Deleting suggests the common misconception that a majority of miners can do anything they want. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Thu, Apr 24, 2014 at 10:19 AM, Gregory Maxwell gmaxw...@gmail.comwrote: This is not voting. It absolutely is! It was widely discussed as such at the time, here is a thread where people ask how to vote and the operator of Eclipse said he was removing his vote for P2SH: https://bitcointalk.org/index.php?topic=60937.0 You might not feel it's a particularly fair or representative vote, but it's still miners saying I support enforcement of this new rule or I do not support this where the majority of cast votes wins. Some miners have more votes than others, but it's still a vote. Yes, making really distributed systems that work in a complex world is hard. It certantly would be /easier/ to just declare miners trusted parties Miners *are* trusted parties, they are just not all trusted simultaneously. Bitcoin can tolerate a small number of dishonest miners whilst producing a degraded service. It cannot work if all miners are dishonest or decide to deviate from their intended operation, like if they all produce empty blocks. The white paper made this clear from the start, and it's also common sense. Allowing the majority of honest miners to keep the dishonest ones in check is what Bitcoin is all about. I don't understand this view that a very small change to the existing protocol is somehow terrible or impossible, but expecting everyone to simply build an entirely new system from scratch is easy and inevitable. I'd much prefer to just keep the existing system working as well as it has so far, and I think that is true of most users too. Temporarily censoring transactions by orphaning otherwise valid blocks that contain them for as long as you retain a majority is possible No, coinbases are deletable. If some miners fork the chain and build a longer one, the others will all switch to it and the coinbases blocks they previously mined will never become spendable (effectively they were deleted before maturity). Only if the other miners also blacklist the majorities fork and never join it, then the majority for some reason gives up and rejoins the minority, is what you described correct. But why would they do that? If they're the majority then all the other nodes will follow them. They have no incentive to throw away their fork and rejoin the minority chain ever again. I think the root of this disagreement is whether the block chain algorithm left by Satoshi is somehow immutable and itself the end, or whether it's (as I see it) just a means to an end and therefore an algorithm that can be tweaked and improved, to get us closer to the goal. If the end is a useful payments system, as decentralised as possible, that prevents double spending, then this proposal is a simple enhancement of the current system that ensures corrupt miners don't get paid by honest users for services they didn't provide, thus discouraging a particular kind of attack. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wednesday 23 April 2014 15:31:38 Mike Hearn wrote: There _are_ consequences though: 95% of the time, you end up buying something and paying for it. Yeah, I was imagining a situation in which people who use Bitcoin regularly do buy things they actually want, but wouldn't say no to occasionally getting them for free (think coffees at starbucks etc). So if their double spend fails, no big deal, they're no worse off than if they didn't try. Again true enough; but then we're back to evenly distributed dishonesty, and so you still don't get the potential 5% scam being used at 100% capacity. Andy -- Dr Andy Parkins andypark...@gmail.com -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Thu, Apr 24, 2014 at 1:39 AM, Mike Hearn m...@plan99.net wrote: It absolutely is! https://bitcointalk.org/index.php?topic=60937.0 May I direct your attention to the third post in that thread? Luke attempting to ret-con the enforcement flag into a vote didn't make it one, and certantly wouldn't make it a fair, just, or sane method of one. And so much for the effectiveness— you didn't implement it for years even after it was deployed. And yes, you can take any decision system and draw comparisons to voting and call it a vote but that doesn't mean is serves the same role or was intended for that purpose. No, coinbases are deletable. If some miners fork the chain and build a longer one, the others will all switch to it and the coinbases blocks they Yes, you can reorg out the blocks and actually remove them, but I understood that you were _not_ proposing that quite specifically. But instead proposed without reorging taking txouts that were previously assigned to one party and simply assigning them to others. I think the root of this disagreement is whether the block chain algorithm left by Satoshi is somehow immutable and itself the end, or whether it's (as I see it) just a means to an end and therefore an algorithm that can be tweaked and improved, to get us closer to the goal. I don't think thats the root of the the disagreement at all. I think all sorts of changes are interesting, especially ones that increase flexibility or fix bugs but less so ones that would impose significant changes on parties without their consent especially things that look like taking someone's coins and assigning them to someone else. I think the root is that you believe that the miners are, should be, or even could be trustworthy in ways that I do not, and as a result you expect to be able to extract the performance of a trusted centralized system out of them that I do not. Bitcoin is a system where the incentives are well enough aligned that you appear to only need a small amount of altruism to make it reliable. ... and even summoning that altruism is a challenge— as miners hand over control of their hash-power to centralized pools (some known to have behaved poorly in the past), etc. I would like that performance if it came at no cost: But proposals that miners conspiring to blacklist transactions/blocks produced by other people is something with a risk of a worse violation of the system's promises than some disagreement of the ordering of unconfirmed transactions. Pretty much immediately after your post Peter Todd— in his trouble making manner— went and posted on reddit proposing the mechanism be used to claw back mining income from a hardware vendor accused of violating its agreements on the amount of self mining / mining on customers hardware. While Peter's suggestion was no doubt intentionally trouble making— I'm not clear on where the line is here: Harm from reordering pretty much non-existent currently and is highly speculative, while the harm to miners by hardware vendors who've promised to not compete with their own customers or use their equipment is not at all speculative and very salient to miners. This especially in light of the fact that the system already has an equitable method to decide what order transactions should be in... but instead you propose an additional complex heuristic system where based on some unspecified collusion some majority of miners take a minorities coins and assign them to themselves. Unlike reorginization this form of wealth transferal has no collateral damage meaning that a majority cabal can use it to deprive a minority outsider of some or all income without risking disrupting the network, it would also lay the groundwork for additional forms of censorship which I believe would be at odds with the purpose and architecture of the system... and, as I noted above, it wouldn't actually prevent theft, it would just mean that no single block could make its theft services available to all comers (or even any of the public at all). The simple mechenism of allowing only only a small number of paid reordering transactions per block would prevent forming a quorum on the decision to revoke the coinbase, and you'd even get additional income from the probe transactions without even helping any real double spends at all. The incentives seem very hard to analyze. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Yes, you can reorg out the blocks and actually remove them, but I understood that you were _not_ proposing that quite specifically. But instead proposed without reorging taking txouts that were previously assigned to one party and simply assigning them to others. Well, my original thought was just to delete the coinbases. But then some people don't like the idea of destroying money (equivalently, reducing the system's resolution) so I proposed reallocating it instead. I'm not sure which is better though. Deletion is closer to what the existing system allows, for sure. Would you feel differently if the consequence was UTXO deletion rather than reallocation? I think the difference makes no impact to the goal of discouraging double spending. ... proposing the mechanism be used to claw back mining income from a hardware vendor accused of violating its agreements on the amount of self mining / mining on customers hardware. I think this would not be doable in practice, unless there was a way to identify that a block was mined with pre-sold equipment. Peter points out that the pool in question is marking their blocks by reusing addresses - ditto for the double spending against dice sites - but that's a trivial thing for them to fix. Then it'd be difficult (impossible?) for miners to identify KnC blocks even if there was a strong majority consensus to delete their coinbases. The reason I think this particular change is doable is that it should be possible to quite reliably identify blocks that are Finney attacking for profit. That doesn't generalise to any policy though. Blocks are intended to be structurally identical to each other if best practices are followed and even with the dire pool situation a big chunk of mining hash power today is effectively anonymous. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 4/23/14, Mike Hearn m...@plan99.net wrote: I guess word honest might have different meanings, that can be a source of confusing. 1. Honest -- not trying to destroy bitcoin 2. Honest -- following rules which are not required by the protocol 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. I thought the mechanism they used to prevent double-spends was proof of work. Therefore dishonest miners where only those who mine on top of a block which is not the longest valid chain they've seen. To distinguish this definition from your own honest miners are those who decide on double-spends by mining the transaction they saw first definition I propose to give another new name to the later, instead of changing the definition of the former. So inside the group of honest miners we have some that decide on transactions based on reception times and others that simply maximize their revenue while respecting the protocol rules. I suggest stupid miners and smart miners respectively as more clear terms for what we're talking about here. Miners that are deliberately trying to double spend are worse than useless. I completely disagree. Miner's proof of work makes transactions irreversible. Even if zero confirmation transactions weren't possible in a replace-by-fee environment, that's very useful. Even if you always had to wait for transactions to be confirmed with some irreversible proof of work (as described in Satoshi's whitepaper), it doesn't follow that automatically resolves the Bitcoin experiment as a failure. I don't understand how can you conclude that. But in fact 0 conf txs are possible *precisely* using replace-by-fee, as described in the 0 confirmation txs using replace-by-fee and game theory thread. So that conclusion is definitely wrong. On your concrete proposal, it seems to me that you're trying to prevent double-spending without relying on proof of work, which I think it impossible in the context of a truly p2p system. I don't think your current proposal is secure and I fear that at best you will end up with an invite only transaction processing network like Ripple.com has with their consensus algorithm and Unique Node Lists: that's not really p2p. -- Jorge Timón http://freico.in/ -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Thu, Apr 24, 2014 at 1:22 PM, Jorge Timón jti...@monetize.io wrote: 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. I thought the mechanism they used to prevent double-spends was proof of work. Therefore dishonest miners where only those who mine on top of a block which is not the longest valid chain they've seen. No! This is a misunderstanding. The mechanism they use to prevent double spends is to *ignore double spends*. The blocks they created indicate the ordering of transactions they saw and proof of work is used to arrive at a shared consensus ordering given the possibility that transactions arrived at different times. I'm continually amazed at how many people seem to see the current algorithm as the goal in and of itself, instead of an imperfect but workable means of achieving the actual goal. To distinguish this definition from your own honest miners are those who decide on double-spends by mining the transaction they saw first This definition of honesty is not my own, the one Bitcoin has always used. Obviously if Satoshi had wanted transactions to be double spendable by fee in the mempool he would have made Bitcoin work that way, instead of coming up with the nSequence based replacement scheme instead. First-seen *is* a protocol rule, as much as Set-Cookie storing data in a browser is an HTTP protocol rule. The fact that auditing compliance with it is harder to do than some others does not make it less of a rule. I completely disagree. Miner's proof of work makes transactions irreversible. Again you are hopelessly confused. Miners that are trying to double spend are *by definition* not making transactions irreversible, they are trying to make transactions reversible. Look at it this way. There is no inherent reason BitUndo has to undo only Finney attacks. If it gets sufficient hash power it could offer undoing of 1-confirm transactions too, right? Sure it'll mostly fail but that's already a part of its business model. Sometimes it'll get two blocks in a row and succeed. It's a very minor tweak to what they're doing. Would you argue these miners are still useful? After all, it's impossible to be certain after the fact that miners built on top of the wrong block because forks occur naturally. Even if you always had to wait for transactions to be confirmed with some irreversible proof of work (as described in Satoshi's whitepaper), it doesn't follow that automatically resolves the Bitcoin experiment as a failure. I don't understand how can you conclude that. What I said is, if you believe all miners are willing to double spend for a fee then this resolves the experiment as a failure. This is also obvious - if you can pay miners to go back and rewrite the chain at will, Bitcoin doesn't work. Consider the incentives. Let's say all miners are smart in your estimation and are willing to double spend transactions for higher fees. Because all miners follow this ridiculous policy, they should be willing to fork the chain at any point to claim the higher fee on the new tx. After all, although they will throw away the work they did on the previous chain, if the fee on the new tx is high enough to balance this then it can be profitable for them to do it. Because a double spender can afford to give nearly all of his new tx away in fees, this means even txns well buried in the chain can be profitably double spent: even if the double spender gets back only 10% of the transferred amount, if it was a big transfer for some expensive object, they still win! They got object + 10% Do you see now why your definition of honesty is completely broken? -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Thu, Apr 24, 2014 at 11:56:23AM +0200, Mike Hearn wrote: ... proposing the mechanism be used to claw back mining income from a hardware vendor accused of violating its agreements on the amount of self mining / mining on customers hardware. I think this would not be doable in practice, unless there was a way to identify that a block was mined with pre-sold equipment. Peter points out that the pool in question is marking their blocks by reusing addresses - ditto for the double spending against dice sites - but that's a trivial thing for them to fix. Then it'd be difficult (impossible?) for miners to identify KnC blocks even if there was a strong majority consensus to delete their coinbases. Like I said before, that leads to the obvious next step of deleting/stealing their coinbases if they don't identify themselves. Another likely outcome would be for coinbase blacklisting to be used as a way to force a minority of miners to adopt a transaction blacklist that the majority of miners had adopted. Any block containing transactions spending coins on the txout blacklist would itself be punished by having the block reward either blacklisted or taken. The reason I think this particular change is doable is that it should be possible to quite reliably identify blocks that are Finney attacking for profit. That doesn't generalise to any policy though. It's not possible to produce a cryptographic proof that a given block engaged in a Finney attack. You're proposed coinbase blacklisting/reallocation mechanism is simply a way of voting on what coinbases to either blacklist or reallocation, nothing more. -- 'peter'[:-1]@petertodd.org 3d5f2a2a68690093cd99f8af1bc8395061251017019cc30a signature.asc Description: Digital signature -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 4/24/14, Mike Hearn m...@plan99.net wrote: No! This is a misunderstanding. The mechanism they use to prevent double spends is to *ignore double spends*. The blocks they created indicate the ordering of transactions they saw and proof of work is used to arrive at a shared consensus ordering given the possibility that transactions arrived at different times. I'm continually amazed at how many people seem to see the current algorithm as the goal in and of itself, instead of an imperfect but workable means of achieving the actual goal. I'm not saying proof of work is the goal, the goal is still p2p transaction serialization. And that's achieved through proof of work, not through miner's honesty. This definition of honesty is not my own, the one Bitcoin has always used. Whatever, let's keep calling stupid miners honest miners, smart miners dishonest-by-replace-by fee miners and miners that do replace by fee and also hash on top of old blocks utterly dishonest miners. Obviously if Satoshi had wanted transactions to be double spendable by fee in the mempool he would have made Bitcoin work that way, instead of coming up with the nSequence based replacement scheme instead. Maybe Satoshi hadn't thought in depth about replace-by-fee when he wrote the code. Why should we care? If nSequence was a design mistake Satoshi did, should we maintain it to somehow honor him? Maybe the payment protocol shouldn't have been developed because he had some weird ideas about paying to ips? Maybe we shouldn't write any tests because he didn't do so? This persistent argument from authority is annoying. First-seen *is* a protocol rule, as much as Set-Cookie storing data in a browser is an HTTP protocol rule. The fact that auditing compliance with it is harder to do than some others does not make it less of a rule. It is not a protocol rule that validators can use to discriminate the longest valid chain and therefore is not enforceable. Not even through a softfork because miners can't know which transactions other miners saw first. So if it is a protocol rule, I think it shouldn't be. Again you are hopelessly confused. Miners that are trying to double spend are *by definition* not making transactions irreversible, they are trying to make transactions reversible. Miners that mine on top of the longest valid chain are helping in making transactions irreversible whether they implement a first-saw or a replace-by-fee policy. Look at it this way. There is no inherent reason BitUndo has to undo only Finney attacks. If it gets sufficient hash power it could offer undoing of 1-confirm transactions too, right? Sure it'll mostly fail but that's already a part of its business model. Sometimes it'll get two blocks in a row and succeed. It's a very minor tweak to what they're doing. Would you argue these miners are still useful? After all, it's impossible to be certain after the fact that miners built on top of the wrong block because forks occur naturally. That's not what I'm saying. Miners that don't mine on top of the longest chain are dishonest by my own definition as well. You want to equate replace-by-fee dishonesty with trying-to-rewrite-history dishonesty by saying that the transactions that have been seen in the network are already history and that's where we disagree. I think only what's in the chain is history and I also think that's the whole point of proof of work. And I also disagree that all the people who think this way are hopelessly confused. We may be confused, but I think there's always hope for removing confusions provided that there's will to learn, which I think it is at least my case. What I said is, if you believe all miners are willing to double spend for a fee then this resolves the experiment as a failure. This is also obvious - if you can pay miners to go back and rewrite the chain at will, Bitcoin doesn't work. This is in fact quite polemic and thus obviously not obvious. Bitcoin works because rewriting the chain gets exponentially more expensive as time passes. Because all miners follow this ridiculous policy, they should be willing to fork the chain at any point to claim the higher fee on the new tx. After ... Do you see now why your definition of honesty is completely broken? I see now that I may have not properly expressed myself in the earlier post since you clearly misunderstood what I meant by smart miners. By that I mean miners implementing replace-by-fee and child-pays-for-parent policies Not miners trying to rewrite history, which I agree is about as smart as mining on top of orphan blocks. -- 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
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Like I said before, that leads to the obvious next step of deleting/stealing their coinbases if they don't identify themselves. And as I said before, that's a huge leap. A majority of miners deciding double spending needs tougher enforcement doesn't imply they also think all miners should identify themselves. Those are unrelated things. This kind of totally unsupported obvious next step argument can be applied to any proposal in any walk of life. We developed SPV clients? The obvious next step is that miners have to stop being anonymous. We developed floating fees? The obvious next step is that miners have to stop being anonymous. The prior arguments sound absurd exactly because they're not obvious or even logical - same as this. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
And that's achieved through proof of work, not through miner's honesty. You can't disentangle the two. Proof of work just makes a block chain hard to tamper with. What it contains is arbitrary. Honest miners build a block chain that's intended to stop double spending. Dishonest miners don't. They're both engaging in proof of work, to different ends. Whatever, let's keep calling stupid miners honest miners No, let's not. Your definition of smart miner is one I'd called stupid miner (or possibly short bitcoin miner). They are miners who would reduce the value of their coins, by making their own system less useful. That's not smart, that's simply short termism taken to an extreme, sort of like a business owner who puts so much pressure on his employees they all quit. He might have gained a bit more profit in the short term, but only at the cost of destroying his business that would have given lower but sustainable returns over the long term. This persistent argument from authority is annoying. Peter always says this too, but it's again an incorrect position. This is not an argument from authority. Why are we here? We are here because we were brought together by shared goals. What are those goals? They were defined at the start of the project by the creator of the project. Why do we issue 21 million coins and not 42? Because 21 million is the goal everyone signed up for. Why did everyone sign up for 21 million coins? Because that's what Satoshi picked. If someone asked us to change from 21 to 42 million coins, we'd probably say no and the justification would be that this is the number we started with. That's not argument from authority, it's just recognition that the parameters of a shared project has to be defined somehow, and for Bitcoin it was defined at the start. Now the argument Gregory makes is that changing the block chain algorithm in this way would be a violation of the social contract. This is a generic outcome to be legitimately worried about - we don't want to change what Bitcoin is in ways that would dismay its users. That just leads to a fork. I argue that this isn't such a change because it makes nothing possible that was previously impossible, it just makes it less disruptive, and the *actual* shared goal of Bitcoin is not preserve the block chain algorithm exactly as found in v0.1 but rather stop double spending. You are arguing elsewhere that Bitcoin should allow double spending for a fee. That *would* be a clear violation of the social contract! That's not what I'm saying. Miners that don't mine on top of the longest chain are dishonest by my own definition as well. Right, but I don't accept this definition of honesty. That's not a definition any man on the street would use: If you pay for something with forged bank notes and walk out immediately, you are honest. But if you pay for something with forged bank notes and hang around for longer than 10 minutes, you are dishonest That would sound silly to anyone because what's so special about 10 minutes? It's the act of passing counterfeit money and stealing from the merchant that's the dishonest act, how long it takes is irrelevant. In Bitcoin, the dishonest act by the user is signing for the same output twice (ignoring special protocols here), and the dishonest act by the miner is deviating from normal behaviour for a fee to try and trick the recipient into believing they have been paid. The exact details are something computer scientists care about, but the average Bitcoin user would not. And I also disagree that all the people who think this way are hopelessly confused. We may be confused, but I think there's always hope for removing confusions provided that there's will to learn, which I think it is at least my case. Indeed and that's why we have these threads! These are fundamental issues that simply must be debated. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote: Actually Peter, coinbase confiscations are a much worse mechanism for enforcement of widespread censorship rules than simple orphaning. They lose their power when the transaction miners are punished for can build up over time without losing their usefulness: snip Of course, in such a dystopian future, orphaning would be the enforcement mechanism. It would be stupid to rely on coinbase reallocation/burning to do this task when the existing tools work so much better. I don't disagree with you at an end stage, but the thing with coinbase blacklists/confiscation is because it's a voting mechanism the initial stages of enforcing widespread censorship rules with it are much easier. For instance, if a 10% pool that has been forced/wants to blacklist certain transactions can do so, and then vote to blacklist blocks that do not abide by that blacklist. Casting that vote does them no harm. Every time another pool joins the blacklist, there's no harm to them to doing so. At some point they will reach a majority, which causes the blacklist to actually apply. The whole process happens smoothly, letting the blacklist be applied safely and easily. With orphaning/reorging on the other hand you just can't be sure that the other miners will actually adopt it, making adoption risky. Of course, that's above and beyond the fact that you can't prove a Finney attack happened to a third-party, making it easy to attack smaller miners with Sybil attacks, get them creating blocks with double-spends in them, and using that as an excuse to punish them. What's interesting is that this mechanism is especially tailored to blocking time sensitive transactions (that need to be confirmed now/soon, or are worthless), such that their total out-of-band fees can't build up over time. Double spending is one such category. I'm at a loss to come up with something else, but maybe someone has a good example? Decentralized markets are a great example: the bids and orders they depend on are time-senstive and become much less valuable if they get delayed greatly. -- 'peter'[:-1]@petertodd.org 091ae589c034bc0466e2feca51dc018bb2c3303e8ab8648b signature.asc Description: Digital signature -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 23/04/2014 05:51 p.m., Mike Hearn wrote: On Wed, Apr 23, 2014 at 10:44 PM, Adam Ritter arit...@gmail.com mailto:arit...@gmail.com wrote: Isn't a faster blockchain for transactions (maybe as a sidechain) solving the problem? If there would be a safe way for 0-confirmation transactions, the Bitcoin blockchain wouldn't even be needed. The 10 minute average comes from a desire to balance wasted work due to natural chain splits with latency. With a very fast block interval you end up with lots of forks and things take longer to converge, also, it can make attacks easier because an attacker is building on his own blocks so he doesn't suffer propagation delays and the attendant splits. It's not clear you can just make a faster block chain. 10 minutes is somewhat arbitrary, it could be 5 minutes and the system would still work, but it probably can't be 5 seconds. 5 seconds block interval is possible. I've simulate it with great success and I encourage anyone to repeat or check my simulations. There are a very few protocol modifications that are required to allow 5 seconds block, and most of them have already been discussed in the forums. For more information you can check my post: http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/ Also NimbleCoin is a new alt-coin that uses 5-sec block intervals, allows 100 tps and it's based on BitcoinJ (NimbleCoinJ now). So not only it is possible, but it was coded by Mike itself. Important note: the 5-sec block interval method probably requires a block reward forever. It doesn't work well if there is no block reward at all. Unfortunately for best physical-world usability you really need very fast payments. A few seconds is competitive with modern credit cards. Another solution to achieve 5 secs block intervals is this: http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/ So the problem with 0-confirmations is solely of Bitcoin and other alt-coins, new alt-coins may achieve instant transactions and no not have to rely on 0-confirmations. Best regards, Sergio. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Thanks Sergio! On Thu, Apr 24, 2014 at 5:13 PM, Sergio Lerner sergioler...@certimix.comwrote: For more information you can check my post: http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/ Also NimbleCoin is a new alt-coin that uses 5-sec block intervals, allows 100 tps and it's based on BitcoinJ (NimbleCoinJ now). So not only it is possible, but it was coded by Mike itself. Fascinating! I think that's the first time I heard of an alt coin entirely based on bitcoinj as its core implementation. Looking forward to your release. My understanding is that dogecoin suffers somewhat from having so many headers. SPV clients have to download them all in sequence so the more blocks you have, the more data they must download and thus the slower they sync. Sync times for SPV wallets today are fast enough that unless you spend six months in the jungle with your phone switched off, you probably won't notice. With 5 second block times unless there's some other solution you'd have much worse UX. BTW, Pieter experimented with relaying blocks as hash lists (actually merkleblocks) and I believe he found that it could often fail and be slower if the mempools were not quite synced. At any rate, it was apparently more complicated than it looked. That may be a side effect of trying to reuse the Bloom filtering code however. Another solution to achieve 5 secs block intervals is this: http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/ MinCen looks like a rather interesting idea. I will read the paper. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 4/24/14, Mike Hearn m...@plan99.net wrote: You can't disentangle the two. Proof of work just makes a block chain hard to tamper with. What it contains is arbitrary. Honest miners build a block chain that's intended to stop double spending. Dishonest miners don't. They're both engaging in proof of work, to different ends. Yes, you can disentangle replace-by-fee policies from rewriting history attacks. That's exactly what I'm saying. Proof of work is the most important thing that makes the blockchain hard to tamper with. Whatever, let's keep calling stupid miners honest miners No, let's not. Your definition of smart miner is one I'd called stupid miner (or possibly short bitcoin miner). They are miners who would reduce the value of their coins, by making their own system less useful. That's not smart, that's simply short termism taken to an extreme, sort of like a business owner who puts so much pressure on his employees they all quit. He might have gained a bit more profit in the short term, but only at the cost of destroying his business that would have given lower but sustainable returns over the long term. Whatever, pick the terms yourself but let's just stick to the same ones, please. I've read this argument before, but I simply don't buy it because I disagree with the premise that replace-by-fee reduces the value of the coins (not to mention we shouldn't assume miners stock coins for long). I think replace-by-fee policies are actually an improvement over first-saw-first-included policies. This persistent argument from authority is annoying. Peter always says this too, but it's again an incorrect position. This is not an argument from authority. I don't know about other occasions with other people but what you just used with me was an argument from authority fallacy. Now you're using a false analogy to try to convince us you didn't. If I was saying we should change the maximum from 21 M to 100 M because mining subsidies could continue for longer. Mining subsidies aren't necessarily a good thing or That's no justification for a hardfork or That could destroy people's confidence in the currency would be logical arguments. No, because Satoshi picked 21 M would be an argument from authority fallacy. That's not what I'm saying. Miners that don't mine on top of the longest chain are dishonest by my own definition as well. Right, but I don't accept this definition of honesty. That's not a definition any man on the street would use: Whatever let's use whatever definitions you want, if I don't like your definition of honesty I will just invent a new term to define my own. If you pay for something with forged bank notes and walk out immediately, you are honest. But if you pay for something with forged bank notes and hang around for longer than 10 minutes, you are dishonest Sorry, I don't see the analogy. That would sound silly to anyone because what's so special about 10 minutes? It's the act of passing counterfeit money and stealing from the merchant that's the dishonest act, how long it takes is irrelevant. 10 minutes is what Satoshi picked. Just kidding... In Bitcoin, the dishonest act by the user is signing for the same output twice (ignoring special protocols here), and the dishonest act by the miner is deviating from normal behaviour for a fee to try and trick the recipient into believing they have been paid. The exact details are something computer scientists care about, but the average Bitcoin user would not. People need to understand that Bitcoin transactions are not instant. For instants transactions you need to rely somehow on trust, use some trust-less offchain mechanism or use a payment protocol that would make double-spending irrational (like the one described in the other thread that uses replace-by-fee). So I think miner's default behavior should be replace-by-fee. But that doesn't imply that I want miners to rewrite pow-validated history. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Casting that vote does them no harm. Every time another pool joins the blacklist, there's no harm to them to doing so. I actually agree that this is a problem, but that's actually not inherent in the proposed enforcement mechanism (just the current voting rules). Here's an alternate: - To start a vote, you set aside a part of your coinbase with amount X = their entire coinbase amount. - Then you need 51 blocks with a yes vote before the coinbase maturity of the target for the vote to be considered a success. - Success means target coinbase has X coins reallocated/burned. - Failure means vote-initiating coinbase has X coins reallocated/burned. The incentives for voting miners are to vote yes if and only if they dislike the targeted miner more than the initiator (all other monetary effects are identical). That isn't a bulletproof way to force miners to only punish double spenders (rather than anything they dislike in general), but it removes the risk free nature of trying to take away another miner's coinbase. It means that you'll need a high level of confidence other miners are on your side before taking a risk, but, because you've got a much longer time frame than 10 minutes, you can get manual confirmation from other miners. On Thu, Apr 24, 2014 at 11:03 AM, Peter Todd p...@petertodd.org wrote: On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote: Actually Peter, coinbase confiscations are a much worse mechanism for enforcement of widespread censorship rules than simple orphaning. They lose their power when the transaction miners are punished for can build up over time without losing their usefulness: snip Of course, in such a dystopian future, orphaning would be the enforcement mechanism. It would be stupid to rely on coinbase reallocation/burning to do this task when the existing tools work so much better. I don't disagree with you at an end stage, but the thing with coinbase blacklists/confiscation is because it's a voting mechanism the initial stages of enforcing widespread censorship rules with it are much easier. For instance, if a 10% pool that has been forced/wants to blacklist certain transactions can do so, and then vote to blacklist blocks that do not abide by that blacklist. Casting that vote does them no harm. Every time another pool joins the blacklist, there's no harm to them to doing so. At some point they will reach a majority, which causes the blacklist to actually apply. The whole process happens smoothly, letting the blacklist be applied safely and easily. With orphaning/reorging on the other hand you just can't be sure that the other miners will actually adopt it, making adoption risky. Of course, that's above and beyond the fact that you can't prove a Finney attack happened to a third-party, making it easy to attack smaller miners with Sybil attacks, get them creating blocks with double-spends in them, and using that as an excuse to punish them. What's interesting is that this mechanism is especially tailored to blocking time sensitive transactions (that need to be confirmed now/soon, or are worthless), such that their total out-of-band fees can't build up over time. Double spending is one such category. I'm at a loss to come up with something else, but maybe someone has a good example? Decentralized markets are a great example: the bids and orders they depend on are time-senstive and become much less valuable if they get delayed greatly. -- 'peter'[:-1]@petertodd.org 091ae589c034bc0466e2feca51dc018bb2c3303e8ab8648b -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Casting that vote does them no harm. Every time another pool joins the blacklist, there's no harm to them to doing so. At some point they will reach a majority These statements do not follow from each other. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2014 03:37 PM, Jorge Timón wrote: The 21 million bitcoin limit is not important because of its exact value, nor is it important because Satoshi picked it. The 21 million limit is important because users hold bitcoin based on the promise that the block reward will never be adjusted ex post facto. The behavior users are relying on is The bitcoins you hold are forever a calculable fraction of all the bitcoins that will ever be issued. That's what bitcoin holders agreed to, and that's what can never be changed. The fact that the number is arbitrary is not relevant. We can agree to meet for lunch at some arbitrarily chosen time, and the fact that the time was chosen arbitrary in no way means that one party arbitrarily choosing not to show up doesn't break the agreement. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWUTWAAoJECoisBQbQ4v0JiwIALQtf4GrNaIdEidJr+f3z8G3 smDgU5xXhN4+1Eo5xU/ZmQy03tU5E00/PRiMTHz1RNXeO+w/iu4PlAJN7pk5oy75 QzDtaCzDjKMCN+1PCQ5VNCL04ws8JifU6QLxSgXgsShBnv19FlxiejgvjNWg+Lzc uHxyP0PlvfF5BWTiEV68KYcfQPbamOH7Vb8v4tQ4/j/ioA7mYso+Q0jX0Y4ae1FN XNs4KnTsIFTsXWzBIYFlFPwQ5d+mdG84W7FpmwwcXaRWQxMwdJq8QjlUuFng439B 6OgQqtq4wmvwoPjKS5nOesfdrdH9Scx2zg6uwhaY0zKMtPW/CEzzLFUfq+cZ6q0= =r+t0 -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 25/04/14 00:28, Mike Hearn wrote: Why are we here? We are here because we were brought together by shared goals. What are those goals? They were defined at the start of the project by the creator of the project. Why do we issue 21 million coins and not 42? Because 21 million is the goal everyone signed up for. Mike: the blockchain is a public document, with a very public and well defined interpretation, which we've all signed up for too. What's the point of piling PoW on top of some data to make it difficult to modify if the interpretation itself is open to modification? There is an important distinction to draw between a hard fork via a change in block validation rules, and a hard fork via a change in the /interpretation of the blockchain itself/. Bitcoin validates data /before/ it makes it into a block; we can all be confident that, short of a reorg, /if it's in a block, it's the law/. As much as the 21m cap is the law anyway. Proving that you can convince the economic majority that the interpretation of existing blocks is in any way up for grabs would set a dangerous precedent, and shake some people's faith in Bitcoin's overall robustness and security (well, mine anyway.) My 2 bits. -Gareth signature.asc Description: OpenPGP digital signature -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Lately someone launched Finney attacks as a service (BitUndo). As a reminder for newcomers, Finney attacks are where a miner secretly works on a block containing a double spend. When they eventually find a block, they run to the merchant and pay, then broadcast the block. In a simpler variant of this attack you make purchases as normal with a modified wallet that always submits a double spend to the service, and then N% of the time where N is the percentage of overall hash power the dishonest miners have, you get your money back minus their fee. N does not need to be very high to render Bitcoin much less useful. Real time transactions are very important. Although I never expected it when I first started using Bitcoin, nowadays most of my purchases with it are for food and drink. If Bitcoin could not support such purchases, I would use it much less. Even with their woeful security many merchants see 1-2% credit card chargeback rates, and chargebacks can be disputed. In fact merchants win about 40% of chargeback disputes. So if N was only, say, 5%, and there was a large enough population of users who were systematically trying to defraud merchants, we'd already be having worse security than magstripe credit cards. EMV transactions have loss rates in the noise, so for merchants who take those Bitcoin would be dramatically less secure. The idea of discouraging blocks that perform Finney attacks by having honest miners refuse to build on them has been proposed. But it has a couple of problems: 1. It's hard to automatically detect Finney attacks. Looking for blocks that contain unseen transactions that override the mempool doesn't work - the dishonest users could broadcast all their double spends once a Finney block was found and then broadcast the block immediately afterwards, thus making the block look like any other would in the presence of double spends. 2. If they could be automatically identified, it possibly could be converted into a DoS on the network by broadcasting double spends in such a way that the system races, and every miner produces a block that looks like a Finney attack to some of the others. The chain would stop advancing. 3. Miners who want to vote no on a block take a big risk, they could be on the losing side of the fork and end up wasting their work. We can resolve these problems with a couple of tweaks: 1. Dishonest blocks can be identified out of band, by having honest miners submit double spends against themselves to the service anonymously using a separate tool. When their own double spend appears they know the block is bad. 2. Miners can vote to reallocate the coinbase value of bad blocks before they mature. If a majority of blocks leading up to maturity vote for reallocation, the value goes into a pot that subsequent blocks are allowed to claim for themselves. Thus there is no risk to voting no on a block, the work done by the Finney attacker is not wasted, and users do not have to suffer through huge reorgs. This may seem a radical suggestion, but I think it's much less radical than some of the others being thrown around. The above approach works as long as the majority of hashpower is honest, defined to mean, working to stop double spending. This is the same security property as described in the white paper, thus this introduces no new security assumptions. Note that assuming *all* miners are dishonest and are willing to double spend automatically resolves the Bitcoin experiment as a failure, because that would invalidate the entire theory upon which the system is built. That doesn't mean the assumption is wrong! It may be that an entirely unregulated market for double spending prevention cannot work and the participants eventually all end up trashing the commons - but the hope is that smart incentives can replace the traditional reliance on law and regulation to avoid this. The voting mechanism would only apply to coinbases, not arbitrary transactions, thus it cannot be used to steal arbitrary users bitcoins. A majority of miners can already reallocate coinbases by forking them out, but this wastes energy and work presenting a significant discouragement to vote unless you already know via some out of band mechanism that you have a solid majority. Placing votes into the coinbase scriptSig as is done with other things avoids that problem. The identification of Finney blocks relies on miners to take explicit action, like downloading and running a tool that submits votes via RPC. It can be expected that double spending services would try to identify and block the sentinel transactions, which is why it's better to have the code that fights this arms race be out of process and developed externally to Bitcoin Core itself, which should ultimately just enforce the new (forking) rule change. -- Start Your Social Network Today - Download eXo
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wednesday 23 Apr 2014 08:55:30 Mike Hearn wrote: Even with their woeful security many merchants see 1-2% credit card chargeback rates, and chargebacks can be disputed. In fact merchants win about 40% of chargeback disputes. So if N was only, say, 5%, and there was a large enough population of users who were systematically trying to defraud merchants, we'd already be having worse security than magstripe credit cards. EMV transactions have loss rates in the noise, so for merchants who take those Bitcoin would be dramatically less secure. Just pedantry: 100% of credit card transactions _can_ be fradulantly charged back but arent. In fact, only 2% are ever attempted. If N was 5%, then only 5% of bitcoin transactions _could_ be fraudulantly charged back; so then why wouldn't only 2% of those bitcoin transactions be fraudulant too, just as in the CC case? The comparison would then be 2% chargebacks for credit cards, equivalent to 0.1% (5%*2%) for bitcoin. Not that I think that makes anything else you say invalid. Andy -- Dr Andy Parkins andypark...@gmail.com -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Just a few issues with the idea as it currently stands: 1. This provides a very strong incentive to always vote for reallocating a block if it isn't yours, regardless of whether it's bad or not (there's a positive expected return to voting to reallocate coinbases from other miners). The incentive is bigger the more hash power you have. You can partially address this by: a) Requiring supermajorities b) Requiring a vote to include proof of a double spend (that's not a very strong safeguard, since anyone can create them after the fact if one of their own transactions has been included). c) Burning, rather than reallocating, the coins. Miners' immediate incentive to attack honest pools is much reduced. 2. BitUndo gets paid using additional txouts in the double-spend transaction, no by miner's fees. This means that the coinbase transaction will represent a smaller and smaller share of their revenues over time (however if the total honest transaction fees they get in their block are high enough, the risk of losing those might still be enough). On Wed, Apr 23, 2014 at 3:55 AM, Mike Hearn m...@plan99.net wrote: Lately someone launched Finney attacks as a service (BitUndo). As a reminder for newcomers, Finney attacks are where a miner secretly works on a block containing a double spend. When they eventually find a block, they run to the merchant and pay, then broadcast the block. In a simpler variant of this attack you make purchases as normal with a modified wallet that always submits a double spend to the service, and then N% of the time where N is the percentage of overall hash power the dishonest miners have, you get your money back minus their fee. N does not need to be very high to render Bitcoin much less useful. Real time transactions are very important. Although I never expected it when I first started using Bitcoin, nowadays most of my purchases with it are for food and drink. If Bitcoin could not support such purchases, I would use it much less. Even with their woeful security many merchants see 1-2% credit card chargeback rates, and chargebacks can be disputed. In fact merchants win about 40% of chargeback disputes. So if N was only, say, 5%, and there was a large enough population of users who were systematically trying to defraud merchants, we'd already be having worse security than magstripe credit cards. EMV transactions have loss rates in the noise, so for merchants who take those Bitcoin would be dramatically less secure. The idea of discouraging blocks that perform Finney attacks by having honest miners refuse to build on them has been proposed. But it has a couple of problems: It's hard to automatically detect Finney attacks. Looking for blocks that contain unseen transactions that override the mempool doesn't work - the dishonest users could broadcast all their double spends once a Finney block was found and then broadcast the block immediately afterwards, thus making the block look like any other would in the presence of double spends. If they could be automatically identified, it possibly could be converted into a DoS on the network by broadcasting double spends in such a way that the system races, and every miner produces a block that looks like a Finney attack to some of the others. The chain would stop advancing. Miners who want to vote no on a block take a big risk, they could be on the losing side of the fork and end up wasting their work. We can resolve these problems with a couple of tweaks: Dishonest blocks can be identified out of band, by having honest miners submit double spends against themselves to the service anonymously using a separate tool. When their own double spend appears they know the block is bad. Miners can vote to reallocate the coinbase value of bad blocks before they mature. If a majority of blocks leading up to maturity vote for reallocation, the value goes into a pot that subsequent blocks are allowed to claim for themselves. Thus there is no risk to voting no on a block, the work done by the Finney attacker is not wasted, and users do not have to suffer through huge reorgs. This may seem a radical suggestion, but I think it's much less radical than some of the others being thrown around. The above approach works as long as the majority of hashpower is honest, defined to mean, working to stop double spending. This is the same security property as described in the white paper, thus this introduces no new security assumptions. Note that assuming all miners are dishonest and are willing to double spend automatically resolves the Bitcoin experiment as a failure, because that would invalidate the entire theory upon which the system is built. That doesn't mean the assumption is wrong! It may be that an entirely unregulated market for double spending prevention cannot work and the participants eventually all end up trashing the commons - but the hope is that smart incentives can replace
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wednesday 23 Apr 2014 12:45:34 Mike Hearn wrote: OK, sure, let's say most Bitcoin users will be honest (we hope). But unfortunately in a situation where fraud is possible users wouldn't necessarily distribute evenly over transactions. That's true, but even in the worst that that 5% hashing power attack means that 95% of the time, your attack fails. That means you end up paying for what you bought. Also, you're again changing the comparison basis -- your CC figures were for the entire industry, not the most badly affected merchant. You can't say one particular bitcoin merchant suffers 5% fraud, therefore that's worse than the 2% fraud averaged across all CC merchants. If a merchant is selling something of value repeatedly, then a small number of scammers can go back and try their luck over and over. I'm not sure how many trades fall into such an exploitable category, though. Also, there's the philosophical question of how honest people really are when there's no consequences to their actions. For instance, if most There _are_ consequences though: 95% of the time, you end up buying something and paying for it. Viewed another way, if I buy something repeatedly from an at risk merchant (and there won't be many; as you pointed out, mail order is completely unaffected as you can simply wait for your confirmations) that costs, say 0.01 BTC per item, then I have to buy 100 of them to get 5 of them for free. Do I really want 100 of them? Even if I do want them, then I've had to supply capital of 1 BTC to earn 0.05 BTC in kind. If what I'm buying is another form of money (as with exchanges, or perhaps casinos) when that in kind is just as liquid as the BTC, then fair enough, there is a risk, but that just incentivises the merchant in those cases to not allow withdrawal/deposit until 6 confirmations have been received. Those merchants then move from at risk to not at risk. I'm still struggling to see how bitcoin could ever be as bad as CC fraud. Andy -- Dr Andy Parkins andypark...@gmail.com -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 07:55 AM, Mike Hearn wrote: 2. Miners can vote to reallocate the coinbase value of bad blocks before they mature. If a majority of blocks leading up to maturity vote for reallocation, the value goes into a pot that subsequent blocks are allowed to claim for themselves. Thus there is no risk to voting no on a block, the work done by the Finney attacker is not wasted, and users do not have to suffer through huge reorgs. If enough miners don't like a block that has been mined, they can all work to orphan it without any change to the protocol whatsoever. Why are proposing this a change to the network that allows miners to vote to disregard output scripts, instead of creating an out of band network via which miners can coordinate actions using the capabilities the protocol already allows? Once you've changed the network such that it is no longer a machine that faithfully processes scripts, and instead is a machine via which a set of controllers can decide which valid scripts will be honored and which ones will not, what will be the next proposed condition under which the miners can confiscate and redistribute balances? - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTV9OUAAoJECoisBQbQ4v0XE8H+QGcOc3JiYsS2/xoR8SqpyEx gDChDFvhaao9qMPhfxBG0bso+4ITZ5c3mJawkqdBm3ZZPeygt1fLqvxe4c1AWocH YCf9CyZJlm8KsDJOqorja5o/6oXjH5xiGgVi042Jhb9wj/aGNPFvL9X6DGhEeFKQ uXFN4wTSPViEOryVqo3vEFh3md9Y1AIqcvc/b5M+EAtvaAD33/ALnzY9CNKymQZE o0JGLEfwamKkZ+QA0mTfeDheJe9kj0KOQhXqOG/x3NlKCFVpmGz3daWZHJCFMDb4 +RmDwoxOKvXxgveXu9w4d3bc3SQZ75hygmeMvVQwZggia31wqrHtsWLqIiFhVnU= =hpdg -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
This is outright ridiculous. Zero-confirmation double-spending is a small problem, and possible solutions are known. (E.g. trusted third party + multi-sig addresses for small-value transactions.) On the other hand, protocol changes like described above might have game-theoretical implications which are non-trivial and hard to understand. The above approach works as long as the majority of hashpower is honest, defined to mean, working to stop double spending. This is the same security property as described in the white paper, thus this introduces no new security assumptions. No. Bitcoin should work if miners are merely individually rational, i.e. they try to maximize their pay-offs without colluding with others. I guess word honest might have different meanings, that can be a source of confusing. 1. Honest -- not trying to destroy bitcoin 2. Honest -- following rules which are not required by the protocol -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wed, Apr 23, 2014 at 5:34 PM, Kevin kevinsisco61...@gmail.com wrote: I have some questions: 1. How can we work towards solving the double-spending problem? We have this awesome technology that solves the double-spending problem. It's called a blockchain. Of course, it only works when transactions are actually in a block. This issue is about double-spending preventing before they're confirmed. This is (and has always been) just a best-effort mechanism in the network. 2. Is it possible to scan for double-spending and correct it? That is what is being proposed here, by introducing a mechanism where miners can vote to penalize other miners if they seem to allow (too many?) double spends. 3. Is the network at large not secure enough? Not very relevant. -- Pieter -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wed, Apr 23, 2014 at 05:41:26PM +0200, Pieter Wuille wrote: On Wed, Apr 23, 2014 at 5:34 PM, Kevin kevinsisco61...@gmail.com wrote: I have some questions: 1. How can we work towards solving the double-spending problem? We have this awesome technology that solves the double-spending problem. It's called a blockchain. Of course, it only works when transactions are actually in a block. This issue is about double-spending preventing before they're confirmed. This is (and has always been) just a best-effort mechanism in the network. 2. Is it possible to scan for double-spending and correct it? That is what is being proposed here, by introducing a mechanism where miners can vote to penalize other miners if they seem to allow (too many?) double spends. Worse, it's a mechanism where miners can vote to penalize other miners for any reason at all. Nothing in the mechanism requires any proof that a double-spend happened, nor can it. Even if you require the simple two signatures for same output mechanism, that just proves the existance of a second signature, and says nothing at all about whether or not that signature was ever broadcast on any network. -- 'peter'[:-1]@petertodd.org 278031f86c71265f6eaf1fe9ce6cc831dc4f956676a7a7f7 signature.asc Description: Digital signature -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
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.mizr...@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
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.bio...@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.mizr...@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@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 4/23/2014 12:04 PM, Christophe Biocca 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.mizr...@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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development This all sounds verry restrictive. Is it possible to do a sweep in order to clean up double spending? Why punish miners for the sake of punishing them? -- Kevin -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 03:07 PM, Mike Hearn wrote: On Wed, Apr 23, 2014 at 4:52 PM, Justus Ranvier justusranv...@gmail.comwrote: If enough miners don't like a block that has been mined, they can all work to orphan it without any change to the protocol whatsoever. As was already pointed out, yes. However this requires them to immediate establish a majority consensus and be absolutely sure it really is the majority. You suggest an out of band mechanism for that, but why is this better than using the actual consensus mechanism you're trying to measure? Once you've changed the network such that it is no longer a machine that faithfully processes scripts Bitcoin imposes far more rules than just execution of the scripting language, many of which are entirely arbitrary and the result of (controversial) human judgement, like the inflation schedule. You can't claim Bitcoin implements only some kind of natural law. I've formulated my replies to you and this proposal in a more public venue, where such discussions of existential changes to the protocol more rightfully belong: http://bitcoinism.blogspot.com/2014/04/dirty-deals-in-smoke-filled-rooms.html - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTV/Y0AAoJECoisBQbQ4v08NcH/RfkaBAcS5eAKmwePqFuqIUN xJKyIWo+tyY1vPYgArCVNsYr3YM8Wc5fkpqLNxCaM7S0/UmO8YaOdiD7XJyl7bF9 xAveyRt1mfHhx9x6hnPLYbe8WKqtjssSt6MglN8OXtf0EDO+eIxPj6Ya8OZ5YJrL N8SMHaDs2J+qy3Qfec9keE5dyhYLNRC6PjYPVvrRAyqFSjt/8r4Z2a4r0oqvv3Yt mYU1Tx+WoXMKXWY/Dwql1NLbuspZsOhPx/ncROZ5KVryCdrcW/GEIEQ6P0AIdHvT TKYJzh1bdRDYDmVS5z8nUG6waxJwuWPStQo7UYdg26daRUw5qPzjO9SMLLFZPCU= =OOck -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
I've formulated my replies to you and this proposal in a more public venue, where such discussions of existential changes to the protocol more rightfully belong I strongly disagree. It makes perfect sense to discuss changes here, first, where there are lots of people who understand how the system works at a very detailed level. And why do you think your blog is more public than this open, publicly archived mailing list??? -- -- Gavin Andresen -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 05:47 PM, Gavin Andresen wrote: And why do you think your blog is more public than this open, publicly archived mailing list??? Non-developers are more comfortable using social media tools. Blog posts can be shared, Tweeted, and commented upon using nothing more than a web browser. The barrier to participation on a mailing list is higher, and the visibility is lower. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTV/0yAAoJECoisBQbQ4v0Fm8H/j0fG7s/iEQUDlV2+5mxeiBO eoPY2gwuDSTjXc74/3olPHrL/BTGtGg90zwFmlwruUJOaW2m3xvbTD78S8e3HmCC fqqFKQLg+gOQYud2oiHVNW6H++QqKgSJXu4Lr87ZTkpiRGTgr5PWyhe+4sLeXxam InqcFmtTHiUMKlmiPj/FUaPHxYT+n+FaPuiZRUYt0Wfxcc9b1n6gEpV7r36Wh8gl e3rMeDwTfsj/0R4+E+oFEgPl7XBGIJWAf4Nzebuog4ABlqzm4B/RlclZ/5N3W2zZ 6ym6dGpFwN+RuDY2/S2kah6dAeKyk2mAsAChoSOj+vfhCW9wKzclVyM2FNV6lwE= =djWj -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Non-developers are more comfortable using social media tools. Blog posts can be shared, Tweeted, and commented upon using nothing more than a web browser. I don't think Twitter is an appropriate medium for discussing the details of byzantine consensus algorithms. I'm not going to bother arguing in replies to a blog post. Suffice it to say, miners are already handsomely compensated via both inflation and fees for doing their job of preventing double spends. Your suggestion is people should pay them EVEN MORE for simply not being corrupt. My proposal is simpler - how about we find the ones that are claiming people's money via coinbases yet not doing their jobs correctly, and take the money back (or destroy it). I think I prefer that one. Miners that are maliciously double spending cannot justify their existence, they offer no useful service and do not deserve compensation as a result. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 06:37 PM, Mike Hearn wrote: If you want to try and argue that the development list is the wrong place to discuss development, please do so on another thread (or your blog). Let's keep this thread for discussion of the original proposal - ideally, discussed with the dryness that a topic as nerdy as distributed consensus algorithms deserves ;) Is that what you say to yourself to quiet your conscience at night (assuming you're one of the non-sociopathic humans who does indeed have one)? It's just a nerdy distributed consensus problem? The things you're talking about fucking around with have real life implications for quite a few people and your casual dismissal of this is precisely why I responded in the way that I did. What you're doing is reckless endangerment and you're not got to get away with brushing it off as a mere technical detail. Sunlight is the best disinfectant, and this episode is demonstrating to the world exactly how averse you are do that kind of transparency. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWAsmAAoJECoisBQbQ4v0XTcIAL70+EAkSMUgvGeTN+mROkkd 3ap5NhUYehfW33gEEEyO3a6ofrb6k1a8EbHlzDyq7qPZ925kdvbnwqXDQm7auAh1 V8IPAwp+JfCgVDVAxtHuUBUvTuuCn1Mrxnf6ppwzFywBxU6l6KYK9zac1HoX3EVY QxME15zrBmtJfo9/ed9yWz8ZXl6nsx47D3r0VE8FiENJRgxLfZ7Odsr/sGvgL71N aYPv7vMxRBNXDvrMhEuYKa3L83W5kv4JJxzueUyO/0bww/aaeZMZr850u/hUjMgU ui37M+kiFHug3semWGKs1yJiKsEPsEPaU4j6WSDrd0bNbc73bBjvHm9SGYRHzDQ= =L5nX -END PGP SIGNATURE- 0x1B438BF4.asc Description: application/pgp-keys -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wed, Apr 23, 2014 at 12:55 AM, Mike Hearn m...@plan99.net wrote: Lately someone launched Finney attacks as a service (BitUndo). As a reminder for newcomers, Finney attacks are where a miner secretly works on a block containing a double spend. Hm? I didn't think this is at all what they did. What they claim to do is to prioritize transactions in their mempool from people who pay them, potentially over and above other transactions which they may or may not have received first. This may still be bad news for someone taking an irreversible action in response to an unconfirmed payment and it may or may not be really ill advised in general, but I think it's less sinister than it sounds in your posts. Is there some reason to believe it isn't what it claims to be? I think we have very clear evidence that the Bitcoin community doesn't care if miners reorder transactions in their mempool to profitable ends: In https://bitcointalk.org/index.php?topic=327767.0 it's demonstrated that GHash.IO, currently the largest publicly identified pool was used to rip off Betcoin dice via double-spends. first started using Bitcoin, nowadays most of my purchases with it are for food and drink. If Bitcoin could not support such purchases, I would use it much less. Accepting zero-conf inherently has some risk (well, so does all business, but there is substantially more in a zero-conf payment). Even in a spherical-cow Bitcoin absent anything like Bitundo someone can just give a double spend to a large miner and currently give the whole rest of the network the one paying the merchant. They will, with high success rate be successful. Worse, it may _appear_ to the network that the miner was a bitundo but they really were not. The blockchain exists to establish consensus ordering, prior to the blockchain there is no order, and so it is not easy to really say which transaction came first in any meaningful sense. But in business we balance risks and the risk that sometimes a transaction will be reversed exists in every electronic payment system available today, in most of them the risk persists for _months_ rather than minutes. Businesses can still operate in the face of these risks. More importantly, it's possible to deploy technological approaches to make zero-conf very secure against reversal: Things like performing multi-sig with a anti-double-spending system, or using an external federated payment network... but this stuff requires substantial development work— though it's not work thats likely to happen if people are still confused about the level of security that zero-conf has. Miners can vote to reallocate the coinbase value of bad blocks before they mature. I think miners 'voting' to reallocate coins, even if they're thoroughly convinced that the owner of the coins is a nasty party, is a much greater violation of the Bitcoin social contract than some twiddling with the unspecified unconfirmed transaction ordering. Doubly so because a 'nasty' party with non-trivial hash-power can doublespend their own transactions with a pretty good success rate (as was the case for the GHash.io betcoin spends) including not-just zero-conf (though with obviously reduced effectiveness), and all of your reliable detection depends on it being a public service. A much better defense is having the control of hash power very well distributed and so there isn't any central point that excerts enough influence to change the risk statistics much. Giving miners the ability to steal each others payments is, if anything, a force away from that decentralization. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Cut it out with the ad hominem attacks please. If you cant be civil, please go away until you learn some manners. I think the issue being discussed is do you orphan an entire block causing distress to users as well, or try to just cause distress just to the evil miner? This discussion is about exploring the ramifications of all these options. I think you are also forgetting that, miners can implement their own filters and behaviours without anyone's consent. So having an open discussion and exploring all possibilities can only be a good thing before someone goes off an implements a change without taking into account other points of view they may not have considered yet. On 23 Apr 2014 19:51, Justus Ranvier justusranv...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 06:37 PM, Mike Hearn wrote: If you want to try and argue that the development list is the wrong place to discuss development, please do so on another thread (or your blog). Let's keep this thread for discussion of the original proposal - ideally, discussed with the dryness that a topic as nerdy as distributed consensus algorithms deserves ;) Is that what you say to yourself to quiet your conscience at night (assuming you're one of the non-sociopathic humans who does indeed have one)? It's just a nerdy distributed consensus problem? The things you're talking about fucking around with have real life implications for quite a few people and your casual dismissal of this is precisely why I responded in the way that I did. What you're doing is reckless endangerment and you're not got to get away with brushing it off as a mere technical detail. Sunlight is the best disinfectant, and this episode is demonstrating to the world exactly how averse you are do that kind of transparency. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWAsmAAoJECoisBQbQ4v0XTcIAL70+EAkSMUgvGeTN+mROkkd 3ap5NhUYehfW33gEEEyO3a6ofrb6k1a8EbHlzDyq7qPZ925kdvbnwqXDQm7auAh1 V8IPAwp+JfCgVDVAxtHuUBUvTuuCn1Mrxnf6ppwzFywBxU6l6KYK9zac1HoX3EVY QxME15zrBmtJfo9/ed9yWz8ZXl6nsx47D3r0VE8FiENJRgxLfZ7Odsr/sGvgL71N aYPv7vMxRBNXDvrMhEuYKa3L83W5kv4JJxzueUyO/0bww/aaeZMZr850u/hUjMgU ui37M+kiFHug3semWGKs1yJiKsEPsEPaU4j6WSDrd0bNbc73bBjvHm9SGYRHzDQ= =L5nX -END PGP SIGNATURE- -- 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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wed, Apr 23, 2014 at 8:57 PM, Gregory Maxwell gmaxw...@gmail.com wrote: Hm? I didn't think this is at all what they did. What they claim to do is to prioritize transactions in their mempool from people who pay them That's the definition of a Finney attack, right? A tx is broadcast and nodes normally take the first one they saw, allowing you to measure propagation and use double spend alerts to get pretty good confidence, pretty quick. A Finney attacker doesn't do that and includes a double spend, so the one in the mempool gets overridden. I mean, I hope that's the definition of a Finney attack, given that I coined the term :) I think we have very clear evidence that the Bitcoin community doesn't care if miners reorder transactions in their mempool to profitable ends: In https://bitcointalk.org/index.php?topic=327767.0 it's demonstrated that GHash.IO, currently the largest publicly identified pool was used to rip off Betcoin dice via double-spends. Yes, very disappointing. Though I'd hope that if this sort of thing was sustained over months and merchants started dropping Bitcoin as a result, miners would pay more attention. Right now I suspect miners don't pay attention to anything other than hardware builds though. Yes, Bitcoin is imperfect at stopping double spends today. It can certainly be improved! There are plenty of oft-discussed measures like double spend alerts and discouraging Finney-attack blocks as was debated extensively in 2011. This thread is just a third such proposal. More importantly, it's possible to deploy technological approaches to make zero-conf very secure against reversal: Things like performing multi-sig with a anti-double-spending system These sorts of proposals are all just ways of saying block chains kind of suck and we should go back to using trusted third parties. That may well be how the Bitcoin experiment ends, but I think we all agree here that block chains and decentralised consensus are quite spiffy and we should try hard to make them work as well as possible before just shrugging and say find a trusted third party. Otherwise why not just go back to using MasterCard? Any TTP that enforces anti double spending rules will be a lot more centralised than miners, given the difficulty of finding them, their need for a strong brand/reputation, and the difficulty of getting everyone to agree on them. Not to mention that this solution makes Bitcoin sound like a joke currency. It's a super duper low fee totally decentralised financial system . unless you want to buy something in, you know, a shop. And walk out. Then you need to sign up with this company that looks suspiciously like a bank, and pay their fees, and yeah there's like 3 to pick from. Totally decentralised! Doubly so because a 'nasty' party with non-trivial hash-power can doublespend their own transactions If a miner is vertically integrated and defrauding merchants themselves, with no service component, pretty quickly people would talk to each other, notice this pattern and stop trading with them, making their coins rather useless. Also if their real identity is ever revealed they could be liable and there'd be a lot of people wanting to sue them. So I think the ability to resell double spending to lots of different people around the world seems important to practicality. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks]
(this e-mail is cc to the bitcoin-research list) Hi everyone from the bitcoin-development mailing list! I decided to join this legendary list because it seems that all the research fun is taking place in here, and I don't want to miss the research party. Regarding the discussion about BitUndo, a year ago I posted about an attack (which I called the the Bitcoin Eternal Choice for the Dark Side Attack or ECDSA) that tries to erode the confidence in Bitcoin by offering double-spends as a service. I think it's related to the last post from Peter Todd about the problems with BitUndo. Here is the link if anyone is interested in reading about it... http://bitslog.wordpress.com/2013/06/26/the-bitcoin-eternal-choice-for-the-dark-side-attack-ecdsa/ Sergio D. Lerner. On 23/04/2014 12:29 p.m., Peter Todd wrote: Interesting discussion re: incentive compatibility happening on the bitcoin-development email list: - Forwarded message from Mike Hearn m...@plan99.net - Date: Wed, 23 Apr 2014 09:55:30 +0200 From: Mike Hearn m...@plan99.net To: Bitcoin Dev bitcoin-development@lists.sourceforge.net Subject: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks Lately someone launched Finney attacks as a service (BitUndo). As a reminder for newcomers, Finney attacks are where a miner secretly works on a block containing a double spend. When they eventually find a block, they run to the merchant and pay, then broadcast the block. In a simpler variant of this attack you make purchases as normal with a modified wallet that always submits a double spend to the service, and then N% of the time where N is the percentage of overall hash power the dishonest miners have, you get your money back minus their fee. N does not need to be very high to render Bitcoin much less useful. Real time transactions are very important. Although I never expected it when I first started using Bitcoin, nowadays most of my purchases with it are for food and drink. If Bitcoin could not support such purchases, I would use it much less. Even with their woeful security many merchants see 1-2% credit card chargeback rates, and chargebacks can be disputed. In fact merchants win about 40% of chargeback disputes. So if N was only, say, 5%, and there was a large enough population of users who were systematically trying to defraud merchants, we'd already be having worse security than magstripe credit cards. EMV transactions have loss rates in the noise, so for merchants who take those Bitcoin would be dramatically less secure. The idea of discouraging blocks that perform Finney attacks by having honest miners refuse to build on them has been proposed. But it has a couple of problems: 1. It's hard to automatically detect Finney attacks. Looking for blocks that contain unseen transactions that override the mempool doesn't work - the dishonest users could broadcast all their double spends once a Finney block was found and then broadcast the block immediately afterwards, thus making the block look like any other would in the presence of double spends. 2. If they could be automatically identified, it possibly could be converted into a DoS on the network by broadcasting double spends in such a way that the system races, and every miner produces a block that looks like a Finney attack to some of the others. The chain would stop advancing. 3. Miners who want to vote no on a block take a big risk, they could be on the losing side of the fork and end up wasting their work. We can resolve these problems with a couple of tweaks: 1. Dishonest blocks can be identified out of band, by having honest miners submit double spends against themselves to the service anonymously using a separate tool. When their own double spend appears they know the block is bad. 2. Miners can vote to reallocate the coinbase value of bad blocks before they mature. If a majority of blocks leading up to maturity vote for reallocation, the value goes into a pot that subsequent blocks are allowed to claim for themselves. Thus there is no risk to voting no on a block, the work done by the Finney attacker is not wasted, and users do not have to suffer through huge reorgs. This may seem a radical suggestion, but I think it's much less radical than some of the others being thrown around. The above approach works as long as the majority of hashpower is honest, defined to mean, working to stop double spending. This is the same security property as described in the white paper, thus this introduces no new security assumptions. Note that assuming *all* miners are dishonest and are willing to double spend automatically resolves the Bitcoin experiment as a failure, because that would invalidate the entire theory upon which the system is built. That doesn't mean the assumption is wrong! It may be that an entirely unregulated market for double
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell gmaxw...@gmail.comwrote: Right, this works in the Bitcoin network today absent any collusion by the miners. You give one miner a transaction and you give every other node you can reach another transaction. Yes, but that can be fixed with double spend alerts. Someone you ask to not double spend is an entirely separate matter. They aren't self-selecting: you select who you trust to not make double spends and there is no need for this trust to be globally consistent. No? It's not just your decision that matters, the receiver also has to trust them. They're like a dispute mediator in this regard. You can pick whoever you want, but that doesn't matter if the receiver doesn't recognise them or trust them. You have to find an overlap to make an instant trade. In practice if people have to think about this, evaluate brands etc then you'd get a very small number of parties because the value of global agreement is so high. Then it becomes hard to remove ones that have a lot of momentum. The censorship resistance of the block chain doesn't matter if your double spending partners refuse to help you spend your money (because they're being coerced). The censorship can just happen at a different place. To stop GHash.io we would have to take away their hardware or change the Bitcoin protocol to make their hardware useless . or, have a majority decide to zero out their coinbase rewards for blocks that double spent against dice sites. That wouldn't undo the double spend, but you can't do that with the multisig scheme either. All you can do is punish the corrupted party post-hoc, either by not using them again, or by unpaying them for the service they did not provide. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Isn't a faster blockchain for transactions (maybe as a sidechain) solving the problem? If there would be a safe way for 0-confirmation transactions, the Bitcoin blockchain wouldn't even be needed. On Wed, Apr 23, 2014 at 10:37 PM, Mike Hearn m...@plan99.net wrote: On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell gmaxw...@gmail.comwrote: Right, this works in the Bitcoin network today absent any collusion by the miners. You give one miner a transaction and you give every other node you can reach another transaction. Yes, but that can be fixed with double spend alerts. Someone you ask to not double spend is an entirely separate matter. They aren't self-selecting: you select who you trust to not make double spends and there is no need for this trust to be globally consistent. No? It's not just your decision that matters, the receiver also has to trust them. They're like a dispute mediator in this regard. You can pick whoever you want, but that doesn't matter if the receiver doesn't recognise them or trust them. You have to find an overlap to make an instant trade. In practice if people have to think about this, evaluate brands etc then you'd get a very small number of parties because the value of global agreement is so high. Then it becomes hard to remove ones that have a lot of momentum. The censorship resistance of the block chain doesn't matter if your double spending partners refuse to help you spend your money (because they're being coerced). The censorship can just happen at a different place. To stop GHash.io we would have to take away their hardware or change the Bitcoin protocol to make their hardware useless . or, have a majority decide to zero out their coinbase rewards for blocks that double spent against dice sites. That wouldn't undo the double spend, but you can't do that with the multisig scheme either. All you can do is punish the corrupted party post-hoc, either by not using them again, or by unpaying them for the service they did not provide. -- 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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter arit...@gmail.com wrote: Isn't a faster blockchain for transactions (maybe as a sidechain) solving the problem? If there would be a safe way for 0-confirmation transactions, the Bitcoin blockchain wouldn't even be needed. Large scale consensus can't generally provide instantly irreversible transactions directly: Increasing the block speed can't help past the point where the time starts getting close to the network diameter... you simply can't tell what a consensus of a group of nodes is until several times the light cone that includes all of them. And if you start getting close to the limit you dilute the power working on the consensus and potentially make life easier for a large attacker. Maybe other chains with different parameters could achieve a different tradeoff which was better suited to low value retail transactions (e.g. where you want a soft confirmation fast). A choice of tradeoffs could be very useful, and maybe you can practically get close enough (e.g. would knowing you lost a zero-conf double spend within 30 seconds 90% of the time be good enough?)... but I'm not aware of any silver bullet there which gives you something identical to what a centralized service can give you without invoking at least a little bit of centralization. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
The memory pool is just talk. There is no expectation that the memory pool has to satisfy some standard as to what will eventually exist in the block chain, and there are any number of ways that people could communicate transactions to one another without putting them in the memory pool. The memory pool can't be treated like a contract because there is no cryptography to enforce it--there is no contract until the transactions appear in the block chain, inherently. Mike Hearn's proposal is nonsense because it requires miners to develop a concensus on which blocks in the block chain are dishonest. There is no way to prove cryptographically that a block is dishonest because the block chain itself is the concensus system--before there is concensus, there is no concept of dishonesty, at least as far as double-spending goes. In order to decide that a block is dishonest and reallocate the coinbase, a prior consensus mechanism would be required. Of course, such a consensus mechanism would also be subject to attacks just like the block chain. Maxwell's proposal is very good. One only trusts the oscar not to double spend, which is perfectly reasonable if oscar is a well-known service. Normal everyday wallets for immediate payments would simply require a little more infrastructure. Daniel Krawisz On Wed, Apr 23, 2014 at 2:59 PM, Mike Hearn m...@plan99.net wrote: What you're talking about is just disagreement about the content of the memory pool That's the same thing. Whilst you're mining your double spend tx, it's in your mempool but you don't broadcast it as per normal. Then when you find the block you broadcast it to override everyone elses mempool. So yours and theirs were inconsistent. The only slight way BitUndo differs is, they provide it as a service, and I don't know if they inform you when they found a block (probably not), so you have to do the purchase and then hope BitUndo finds the next block. Otherwise the purchase clears. But they could certainly add a pre-notification before they broadcast to get back to the exact scheme originally described, they have everything else in place. Oscar himself can be implemented as a majority M parties to further increase confidence This just brings us back to square one. Who are these parties and what if I pay them to be corrupt? What if they offer to be corrupt as a service? Let's say I succeed in finding some parties who are incorruptible no matter how large of a percentage I offer them. At this point, why bother with miners at all? Why pay for double spend protection twice, once to a group of Oscar's who are trustworthy and once to a group of miners who are not? The point of the broadcast network and mining is so there can be lots of Oscar's and I don't have to know who they are or sign up with them or put any effort into evaluating their reputation. value retail transactions— the fact that any cheating by oscar is cryptographically provable (just show them the double signatures) maybe be strong enough alone. But as you point out, cheating my GHash.io did not result in any obvious negative consequence to them, despite that preventing double spending is their sole task. Why would Oscar be different to GHash.io? Trying to solve the problem of dishonest miners is effectively trying to solve the automatically find trusted third parties problem at scale. -- 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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
An interesting experiment would be a transaction proof of publication chain. Each transaction would be added to that chain when it is received. It could be merge mined with the main chain. If the size was limited, then it doesn't even require spam protection. Blocks could be discouraged if they have transactions which violate the ordering in that chain. Miners could still decide which transactions they include, but couldn't include transactions which are double spends. The locktime/final field could be used for transactions which want to be replaceable. The chain could use some of the fast block proposals. For example, it could include orphans of a block when computing the block's POW. On Wed, Apr 23, 2014 at 9:53 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter arit...@gmail.com wrote: Isn't a faster blockchain for transactions (maybe as a sidechain) solving the problem? If there would be a safe way for 0-confirmation transactions, the Bitcoin blockchain wouldn't even be needed. Large scale consensus can't generally provide instantly irreversible transactions directly: Increasing the block speed can't help past the point where the time starts getting close to the network diameter... you simply can't tell what a consensus of a group of nodes is until several times the light cone that includes all of them. And if you start getting close to the limit you dilute the power working on the consensus and potentially make life easier for a large attacker. Maybe other chains with different parameters could achieve a different tradeoff which was better suited to low value retail transactions (e.g. where you want a soft confirmation fast). A choice of tradeoffs could be very useful, and maybe you can practically get close enough (e.g. would knowing you lost a zero-conf double spend within 30 seconds 90% of the time be good enough?)... but I'm not aware of any silver bullet there which gives you something identical to what a centralized service can give you without invoking at least a little bit of centralization. -- 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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wed, Apr 23, 2014 at 2:23 PM, Tier Nolan tier.no...@gmail.com wrote: An interesting experiment would be a transaction proof of publication chain. Each transaction would be added to that chain when it is received. It could be merge mined with the main chain. If the size was limited, then it doesn't even require spam protection. Blocks could be discouraged if they have transactions which violate the ordering in that chain. Miners could still decide which transactions they include, but couldn't include transactions which are double spends. The locktime/final field could be used for transactions which want to be replaceable. The chain could use some of the fast block proposals. For example, it could include orphans of a block when computing the block's POW. You can see me proposing this kind of thing in a number of places (e.g. http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt p2pool only forces the subsidy today, but the same mechnism could instead force transactions.. e.g. to get you fast confirmation., or previously on BCT for the last couple years) but there are still limits here: If you don't follow the fast-confirmation share chain you cannot mine third party transactions because you'll be at risk of mining a double spend that gets you orphaned, or building on a prior block that other miners have decided is bad. This means that if the latency or data rate requirements of the share chain are too large relative to ordinary mining it may create some centralization pressure. That said, I think using a fast confirmation share-chain is much better than decreasing block times and could be a very useful tool if we believe that there are many applications which could be improved with e.g. a 30 second or 1 minute interblock time. Mostly my thinking has been that these retail applications really want sub-second confirmation, which can't reasonably be provided in this manner so I didn't mention it in this thread. One of the neat things about this is that you can introduce it totally separately from Bitcoin without any consensus or approval from anyone else— E.g. P2pool builds such a chain today though it doesn't enforce transactions. It would immediately provide the useful service of demonstrating that some chunk of hashpower was currently working on including a particular set of transactions. Once the details were worked out it could be added as a soft-forking requirement to the commonly run system. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
These sorts of proposals are all just ways of saying block chains kind of suck and we should go back to using trusted third parties. No. Different approaches have different trade-offs, and thus different areas of applicability. Proof-of-work's inherent disadvantage is that it takes some time until transaction becomes practically irreversible. On the other hand, it has advantages like neutrality, censorship-resistance, high degree of security, etc. TTP can be very efficient, but doesn't have advantages mentioned above. It is possible to combine several different approaches into one hybrid systems. For example, classic Bitcoin PoW blockchain can be used for settlements, large transactions, savings and so on. While TTP-based payment system will be used for small-value transaction like buying coffee. In this case you get benefits of both approaches. Censorship-resistance is irrelevant when one buys a cup of coffee with his pocket money, isn't it? For some reason, instead of considering these hybrid solutions (which can also address scalability problems), you want to make PoW-based system more complex to be applicable for real-time transaction too. This will, likely, weaken advantages provided by PoW, and also it won't provide any hard guarantees, and, if implemented, will undermine development of alternative solutions. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@gmail.comwrote: You can see me proposing this kind of thing in a number of places (e.g. http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt p2pool only forces the subsidy today, but the same mechnism could instead force transactions.. Interesting. You set the share-block size to 16kB and set the share POW to 1/64 of the main target. Each share-block would be allowed to append up to 16kB on the previous share-block. This would keep the bandwidth the same, but on average blocks would be only 512kB. e.g. to get you fast confirmation., or previously on BCT for the last couple years) but there are still limits here: If you don't follow the fast-confirmation share chain you cannot mine third party transactions because you'll be at risk of mining a double spend that gets you orphaned, or building on a prior block that other miners have decided is bad. This means that if the latency or data rate requirements of the share chain are too large relative to ordinary mining it may create some centralization pressure. This effect could be reduced by having colours for blocks and transactions. The block colour would be a loop based on block height. You could have 16 transaction colours based on the lowest 4 bits in the txId. A transaction is only valid if all inputs into the transaction are the correct colour for that block. This allows blocks to be created in advance. If you are processing colour 7 at the moment, you can have a colour 8 block ready. 16 colours is probably to many. It would only be necessary for things like 1 second block rates. The disadvantage is that wallets would have to make sure that they have coins for each of the 16 colours. If you spend the wrong colour, you add 16 block times of latency. That said, I think using a fast confirmation share-chain is much better than decreasing block times and could be a very useful tool if we believe that there are many applications which could be improved with e.g. a 30 second or 1 minute interblock time. Mostly my thinking has been that these retail applications really want sub-second confirmation, which can't reasonably be provided in this manner so I didn't mention it in this thread. In a shop setting, you could set it up so that the person scans a QR-code to setup a channel with the shop. They can then scan all their stuff and by the time they have done that, the channel would be ready. If there was a queue, it could be done when the person enters the queue. In fact, there could be QR-codes at multiple locations. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 4/23/2014 2:23 PM, Tier Nolan wrote: An interesting experiment would be a transaction proof of publication chain. What if a transaction could simply point back to an earlier transaction, forming a chain? Not a separately mined blockchain, just a way to establish an official publication (execution) order. Double spends would be immediately actionable with such a sequence. Transactions in a block could eventually be required to be connected in such a chain. Miners would have to keep or reject a whole mempool chain, since they lack the keys to change the sequence. They would have to prune a whole tx subchain to insert a double spend (and this would still require private keys to the double spend utxo's). This idea seemed promising, until I realized that with the collision rebasing required, it would barely scale to today's transaction rate. Something that scales to 10,000's of transactions per second, and really without limit, is needed. Anyway, I wrote it up here: https://github.com/dgenr8/out-there/blob/master/tx-chains.md -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
