Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
On Mon, Dec 15, 2014 at 3:52 PM, Peter Todd p...@petertodd.org wrote: Comparisons with the SPV security of sidechains are fallacious. The alternative to a proof-of-publication system reliant on client-side validation is a blockchain. The question of whether the token used on said blockchain should be two-way-pegged to BTC is completely orthogonal. (ie. yes, sidechains are economically secure, in that you're reduced to balancing economic incentives to avoid peg theft. But sidechains also give us something unique in return - the ability to innovate without needing to start new artificial scarcity races. Nothing else can do that.) I covered this in my original post: 1-way-pegs allow the creation of new valuable tokens without those tokens being useful for speculation. I stand corrected. A permanent 1-way-peg is sufficient to preserve scarcity; nothing else can do that WRT 2-way-pegs was overreaching. I still don't see what 2-way-peg vs. 1-way-peg has to do with embedded consensus vs. blockchain consensus though, and feel it disingenious to conflate them. Blockchain consensus (eg. sidechains) can utilise either mechanism, 1-way-peg or 2-way-peg. Arguments in favour of 1-way-peg are interesting, but they're ultimatley just arguments in favour of one type of sidechain over another. Arguments in favour of embedded consensus - and I feel I'm being generous with the term consensus here - should surely stand on their own merit against blockchain consensus, if they're to be convincing. Of course even without 1-way-pegs there's a much more important issue with your objection: worrying about creating new artificial scarcity races while innovating is fundementally a *moralistic* and *regulatory* concern that has no little if any bearing on whether or not the systems created are useful and secure. It's also an objection that raises serious questions about conflicts of interest between giving accurate and honest technical advice and promoting ways of using Bitcoin that will drive the price up. IMO the question of whether scarcity can be preserved while enabling innovation bears heavily on the liklihood of longterm viability of said innovations - and perhaps of Bitcoin itself. FWIW I'll happily declare that I hold a modest amount of BTC and have an interest in the price appreciating. I'm sure you'll admit you're hardly an impartial party in this discussion yourself Peter :) But it really shouldn't matter. I'm not here today to make it, but I think the argument for preservation of scarcity stands quite well on its own merits - as rightly it should, regardless of anybody's interests. A number of mechanisms for detecting divergence are possible in embedded consensus systems, some of them even natural outcomes. For instance transactions can contain a hash of the previous consensus state, thereby creating an indicator of consensus measured in terms of economic stake. Extending that idea many anti-censorship proposals are to use such state hashes as encryption keys - if you are out of consensus you won't even see the transaction. (and you can't be double-spent either if implemented correctly; see my other reply to this thread today) snip Indeed I did, which is why I worked out a better way to do upgrades almost a year ago: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06578.html snip The quality of Counterparty's software engineering has no bearing on whether or not the underlying idea is a good one; you wouldn't say ring signatures are an inherently bad idea just because the CryptoNote implementation of them is atrocious. Very interesting. I admit I hadn't come across these ideas before; I really must search the archive before posting :) They certainly offer a measure of robustness over the naive approach. I'm not sure they address my primary concerns however, WRT how consensus is demonstrated and incentivised. I know what my own node considers valid transaction history; how can I be confident that everyone else takes the same view? For contrast, with blockchain consensus, I can be confident that there is consensus on the longest chain observed. If I receive a new transaction, simply waiting for it to be buried under N blocks of PoW provides a high level of confidence that everyone else considers it valid. The obvious embedded consensus answer of wait until N other transactions have occurred that include a hash of system state that includes your transaction doesn't provide me with any confidence; it could be simulated with a Sybil attack. snip I prefer to make robust arguments; if I can start with accepting that 95% of what my opponents say is true, yet still end up being correct, all the better! Indeed :) To avoid wasting time it's only ever worth arguing against the strongest opposing position you're aware of (whether your opponent is aware of it or not.) https://en.wikipedia.org/wiki/Principle_of_charity
Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
On 13/12/14 04:04, Alex Mizrahi wrote: Well, client-side validation is mathematically secure, while SPV is economically secure. I.e. it is secure if you make several assumptions about economics of the whole thing. Comparisons with the SPV security of sidechains are fallacious. The alternative to a proof-of-publication system reliant on client-side validation is a blockchain. The question of whether the token used on said blockchain should be two-way-pegged to BTC is completely orthogonal. (ie. yes, sidechains are economically secure, in that you're reduced to balancing economic incentives to avoid peg theft. But sidechains also give us something unique in return - the ability to innovate without needing to start new artificial scarcity races. Nothing else can do that.) snip You know, The Great Fork of 2013 was resolved through human intervention, Bitcoin nodes were not smart enough to detect that something is going awry on their own. I hate to think what the outcome would've been on a proof-of-publication system. You don't even have a fork. You just have a whole bunch of nodes who sort-of-mostly agree on a shared history, except where they don't. Maybe they just disagree on the validity of a single transaction. They'll slowly diverge over time (as bad transactions are used as input to other transactions.) You have no reliable way to detect this lapse in consensus, nor any mechanism to incentivse convergence. Indeed, you have no consensus mechanism in the first place. Bitcoin is where it is today because of Satoshi's elegant solution to exactly such problems. Which some people now appear to be in a hurry to discard :) Alex Mizrahi wrote: Using scheduled updates: client simply stops working at a certain block, and user is required to download an update. snip An alternative to this is to make updates mandatory. You will no longer need to maintain compatibility with version 0.1 (which is impossible) and you can also evolve consensus rules over time. Peter Todd might disagree with the wisdom of that :) He wrote an excellent email to this list not long ago warning of the dangers of centralisation. IIRC one point he made was that scheduled, regular hardforks were a real threat - if a single entity (eg. the Bitcoin Foundation) were to become politically established as the coordinator of such forks, they would have de-facto control over the protocol. Even in that dark scenario, I would feel a measure of confidence that past transactions I had received could not be tampered with. The fact that those transactions happened, and that there was (and is) consensus they were valid, is publicly documented in the blockchain. I trust any reasonable person would not accept a client that ignored validated data in the blockchain as Bitcoin any more. Your proof-of-publication system with mandatory updates is another matter entirely. No public record of transactions I have received with that system exists, anywhere. If tomorrow's mandatory update has the effect of zeroing my account balance (by happening to now interpret one or more transactions I received, or their inputs, as invalid) then I have no recourse. I won't find sympathy with the majority of users, who are unaffected and just accept the update. In short, what you describe doesn't sound very decentralised :) Do you want transactions you receive validated by distributed consensus and burried under PoW, or validated by some guy's mandatory-updating python script? (Also worth noting: all such systems are effectively mandatory updating due to the risk of subtle consensus bugs of the type I described above. Your only assurance that your view of the world is the same as everyone elses' is that you're running the exact same software. I played with Counterparty a while ago and quickly learned - the hard way - to do a 'git pull' before any important operation.) signature.asc Description: OpenPGP digital signature -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
On 12/12/14 20:05, Peter Todd wrote: Secondly using a limited-supply token in a proof-of-publicaton system is what lets you have secure client side validation rather than the alternative of 2-way-pegging that requires users to trust miners not to steal the pegged funds. Secure and client side validation don't really belong in the same sentence, do they? If I am to accept a transaction with any assurance of security at all, the important question to ask is not: does my client consider this valid? but: does the rest of the world consider this valid? Validated data in the blockchain is far more useful for this purpose than unvalidated data with a mere proof of publication in the blockchain, precisely because it records what /everybody else/ considers valid history (and very likely will continue to consider valid history in future.) Pegged sidechains have their challenges, but at least they provide distributed consensus on transaction history. Proof-of-publication systems like Counterparty and Mastercoin require me to trust, with zero evidence, that everybody else's client has the exact same interpretation of transaction history as mine, and will continue to have for the indefinite future. How is that not a horribly broken security model? I'd use a sidechain - with reasonable parameters that disincentivise peg theft as much as practical - over that any day. signature.asc Description: OpenPGP digital signature -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ 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: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
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 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
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] Proof-of-Stake branch?
What about using fraud proofs? Your coinbase only matures if nobody publishes proof that you signed a competing block. Then something is at least at stake. When it's your chance to sign a block, attempting to sign and publish more than one at the same height reliably punishes you (you effectively waste your chance and receive no reward.) I can't remember who I saw discussing this idea. Might have been Vitalik Buterin? On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach m...@monetize.io wrote: There's no need to be confrontational. I don't think anyone here objects to the basic concept of proof-of-stake. Some people, myself included, have proposed protocols which involve some sort of proof of stake mechanism, and the idea itself originated as a mechanism for eliminating checkpoints, something which is very much on topic and of concern to many here. The problems come when one tries to *replace* proof-of-work mining with proof-of-stake mining. You encounter problems related to the fact that with proof-of-stake nothing is actually at stake. You are free to sign as many different forks as you wish, and worse have incentive to do so, because whatever fork does win, you want it to be yours. In the worst case this results in double-spends at will, and in the best case with any of the various proposed protections deployed, it merely reduces to proof-of-work as miners grind blocks until they find one that names them or one of their sock puppets as the signer of the next block. I sincerely doubt you will find a solution to this, as it appears to be a fundamental issue with proof-of-stake, in that it must leverage an existing mechanism for enforced scarcity (e.g. proof-of-work) in order to work in a consensus algorithm. Is there some solution that you have in mind for this? Mark On 04/25/2014 12:33 AM, Troy Benjegerdes wrote: Do it. Someone will scream harm. The loudest voices screaming how it would be harmful are doing the most harm. The only way to know is build it, and test it. If the network breaks, then it is better we find out sooner rather than later. My only suggestion is call it 'bitstake' or something to clearly differentiate it from Bitcoin. This also might be an interesting application of the side chains concept Peter Todd has discussed. On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote: Hello all. I understand that Proof-of-Stake as a replacement for Proof-of-Work is a prohibited yet disputed change to Bitcoin Core. I would like to create a Bitcoin branch that provides a sandboxed testbed for researching the best PoS implementations. In the years to come, perhaps circumstances might arise, such as shifting of user opinion as to whether PoS should be moved from the prohibited list to the hard-fork list. - A poll I conducted today on bitcointalk, https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing title suggests some minority support for Bitcoin Proof-of-Stake. I invite any of you to critically comment on that thread. Annual 10% bitcoin dividends can be ours if Proof-of-Stake full nodes outnumber existing Proof-of-Work full nodes by three-to-one. What is your choice? I do not care or do not know enough. - 5 (16.1%) I would download and run the existing Proof-of-Work program to fight the change. - 14 (45.2%) I would download and run the new Proof-of-Stake program to favor the change. - 12 (38.7%) Total Voters: 31 - Before I branch the source code and learn the proper way of doing things in this community, I ask you simply if creating the branch is harmful? My goal is to develop, test and document PoS, while exploring its vulnerabilities and fixing them in a transparent fashion. Thanks for taking a bit of your time to read this message. -- 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 -- 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] Proof-of-Stake branch?
Who said anything about a re-org? The original block remains valid, your block reward is just zero, upon maturity, in light of a valid fraud proof. ie. the coinbase confiscation that I was just arguing against in another thread :P but of course here based on cryptographic proof, not human judgement. On 27 April 2014 11:22:07 AM AEST, Mark Friedenbach m...@monetize.io wrote: That makes double-spends trivially easy: sign two blocks, withholding one. Then at a later point in time reveal the second signed block (demonstrating your own fraud) and force a reorg. On 04/26/2014 04:44 PM, Gareth Williams wrote: What about using fraud proofs? Your coinbase only matures if nobody publishes proof that you signed a competing block. Then something is at least at stake. When it's your chance to sign a block, attempting to sign and publish more than one at the same height reliably punishes you (you effectively waste your chance and receive no reward.) I can't remember who I saw discussing this idea. Might have been Vitalik Buterin? On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach m...@monetize.io wrote: There's no need to be confrontational. I don't think anyone here objects to the basic concept of proof-of-stake. Some people, myself included, have proposed protocols which involve some sort of proof of stake mechanism, and the idea itself originated as a mechanism for eliminating checkpoints, something which is very much on topic and of concern to many here. The problems come when one tries to *replace* proof-of-work mining with proof-of-stake mining. You encounter problems related to the fact that with proof-of-stake nothing is actually at stake. You are free to sign as many different forks as you wish, and worse have incentive to do so, because whatever fork does win, you want it to be yours. In the worst case this results in double-spends at will, and in the best case with any of the various proposed protections deployed, it merely reduces to proof-of-work as miners grind blocks until they find one that names them or one of their sock puppets as the signer of the next block. I sincerely doubt you will find a solution to this, as it appears to be a fundamental issue with proof-of-stake, in that it must leverage an existing mechanism for enforced scarcity (e.g. proof-of-work) in order to work in a consensus algorithm. Is there some solution that you have in mind for this? Mark On 04/25/2014 12:33 AM, Troy Benjegerdes wrote: Do it. Someone will scream harm. The loudest voices screaming how it would be harmful are doing the most harm. The only way to know is build it, and test it. If the network breaks, then it is better we find out sooner rather than later. My only suggestion is call it 'bitstake' or something to clearly differentiate it from Bitcoin. This also might be an interesting application of the side chains concept Peter Todd has discussed. On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote: Hello all. I understand that Proof-of-Stake as a replacement for Proof-of-Work is a prohibited yet disputed change to Bitcoin Core. I would like to create a Bitcoin branch that provides a sandboxed testbed for researching the best PoS implementations. In the years to come, perhaps circumstances might arise, such as shifting of user opinion as to whether PoS should be moved from the prohibited list to the hard-fork list. - A poll I conducted today on bitcointalk, https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing title suggests some minority support for Bitcoin Proof-of-Stake. I invite any of you to critically comment on that thread. Annual 10% bitcoin dividends can be ours if Proof-of-Stake full nodes outnumber existing Proof-of-Work full nodes by three-to-one. What is your choice? I do not care or do not know enough. - 5 (16.1%) I would download and run the existing Proof-of-Work program to fight the change. - 14 (45.2%) I would download and run the new Proof-of-Stake program to favor the change. - 12 (38.7%) Total Voters: 31 - Before I branch the source code and learn the proper way of doing things in this community, I ask you simply if creating the branch is harmful? My goal is to develop, test and document PoS, while exploring its vulnerabilities and fixing them in a transparent fashion. Thanks for taking a bit of your time to read this message. -- 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
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] 0 confirmation txs using replace-by-fee and game theory
On 25/04/14 20:19, Mike Hearn wrote: You don't get any money back, but you do get an angry shopkeeper chasing you down the street / calling the police / blacklisting you from the store. If they could do that they'd just take the stolen property back and you would have failed to spend your money twice. So this is by definition, not a successful double spend. We are worried about the cases when you could successfully double spend, and the only thing stopping you is Bitcoin. You might not succeed in catching them, but however small the risk of getting caught is, they're taking that risk for an assured zero gain. Any rational attacker would therefore not bother. I think it's a very elegant solution to the typical broadcast double spend attack. Of course it unfortunately does nothing to stop a dishonest mining pool from secretly working on your double spend for a fee. But that breaks down to: * trade first and hope the dishonest pool finds the next block * the dishonest pool finds and withholds the block while you trade We can discount the second one entirely - the orphan risk makes it very expensive to execute, and people are typically accepting zero-conf for low value items like cups of coffee. For high value items it is probably reasonable (and hopefully common practice?) to wait for a block. So we're left with the first situation. As others have noted, given a dishonest pool with 5% total hashrate, a dedicated attack is out (unless you want to end up actually buying goods to 20x the value of the attack in the process.) That leaves the opportunists, who press the attempt to take-back 70% of this transaction (remember the pool gets their cut) every time they buy a coffee and very occasionally get lucky. They're the only unsolvable problem I can see here. It remains to be seen how many such opportunists we'll end up with, or how much hashrate the dishonest pool can actually attract. 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
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
Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory
On 24/04/14 22:07, Chris Pacia wrote: It would work but it's an ugly hack IMO. What do people do if they don't have extra to pay when making a purchase? I have 200 mbtc and want to buy a 200 mbtc phone but I can't because I need 400 mbtc. Sucks for me. I don't see why it couldn't work with just 200mBTC. * you sign a 200mBTC TX to me, walk out of my shop with the phone * you immediately sign broadcast a double-spend TX with higher fee * my POS computer (or BitPay's) sees the double spend, immediately spends the initial TX to fees, and sounds the shoplifting alarm. You don't get any money back, but you do get an angry shopkeeper chasing you down the street / calling the police / blacklisting you from the store. Assuming my POS computer's behaviour was completely automated and widespread - and therefore predictable on your part - why would you ever try this? The number of people irrational enough to try this /knowing it never works/ is likely to be way lower than the number who just stuff the phone in their pocket and shoplift the old fashioned way. So I'd be comfortable without the extra 200mBTC collateral :-) 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
