[Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
There's been a lot of recent hoopla over proof-of-publication, with the OP_RETURN data length getting reduced to a rather useless 40 bytes at the last minute prior to the 0.9 release. Secondly I noticed a overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken into account, making it possible to broadcast unminable transactions and bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG outputs given that the sigops limit and the way they use up a fixed 20 sigops per op makes them hard to do fee calculations for. They also make it easy to bloat the UTXO set, potentially a bad thing. This would of course require things using them to change. Currently that's just Counterparty, so I gave them the heads up in my email. To make a long story short, it was soon suggested that Bitcoin Core be forked - the software, not the protocol - and miners encouraged to support it. This isn't actually as trivial as it sounds, as you need to add some anti-DoS stuff to deal with the fact that the hashing power mining the transations you are relaying may be quite small. The second issue is you need to add preferential peering, so the nodes in the network with a broader idea of what is a allowed transaction can find each other. (likely with a new service flag) It'd be a good time to implement replace-by-fee, partly for its anti-DoS properties. Which leaves us with a practical question: How do you gracefully handle a switchover? First of all I suggest that proof-of-publication applications adopt format flexibility, similar to how Mastercoin can encode its data in pay-to-pubkeyhash, bare multisig, or op_return outputs. Given the possibility of bare multisig going away, I'd suggest that P2SH multisig scriptSig encoding be added as well. Note that a really good implementation of all this is actually format agnostic, and will let PUSHDATA's used for encoding data be specified arbitrarily. I wrote up some code to do so awhile back as an experiment. It used the LSB's of the nValue field in the txouts to specify what was and wasn't data, along with some stenographic encryption of data and nValue. I'd be happy to dig that up if anyone is interested. All these methods have some overhead compared to just using OP_RETURN and thus cost more. So I suggest you have your software simultaneously double-spend the inputs to any proof-of-publication transaction with a second transaction that just makes use of efficient OP_RETURN. That second one can go to more enlightened miners. Only one or the other will get mined of course and the cost to publish data will be proportional to the relative % of hashing power in the two camps. Finally I'll be writing something more detailed soon about why proof-of-publication is essential and miners would be smart to support it. But the tl;dr: of it is if you need proof-of-publication for what your system does you're much more secure if you're embedded within Bitcoin rather than alongside of it. There's a lot of very bad advise getting thrown around lately for things like Mastercoin, Counterparty, and for that matter, Colored Coins, to use a separate PoW blockchain or a merge-mined one. The fact is if you go with pure PoW, you risk getting attacked while your still growing, and if you go for merge-mined PoW, the attacker can do so for free. We've got a real-world example of the former with Twister, among many others, usually resulting in a switch to a centralized checkpointing scheme. For the latter we have Coiledcoin, an alt that made the mistake of using SHA256 merge-mining and got killed off early at birth with a zero-cost 51% attack. There is of course a censorship risk to going the embedded route, but at least we know that for the forseeable future doing so will require explicit blacklists, something most people here are against. To MSC, XCP and others: Now I'm not going to say you shouldn't take advice from people who call your finance 2.0 systems scams, or maybe if they're nice, indistinguishable from a scam. But when you do, you should think for yourself before just trusting that some authority figure has your best interests in mind. 1) Yes, this was responsibly disclosed to the security mailing list. It was revealed to the public a few hours later on the -dev IRC channel without a fix. -- 'peter'[:-1]@petertodd.org 9065ab15f4a036e9ec13d2e788e0ede69472e0ec396b097f signature.asc Description: Digital signature -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
On 3/22/14, Peter Todd p...@petertodd.org wrote: There's been a lot of recent hoopla over proof-of-publication, with the OP_RETURN data length getting reduced to a rather useless 40 bytes at the last minute prior to the 0.9 release. I'm not against about miners accepting transactions that have longer data in non-utxo polluting OP_RETURN than whatever is specified as standard by the reference implementation, maybe it should be risen in standard but I think it was assumed that the most common case would be to include the root hash of some merklized structure. My only argument against non-validated proof of publication is that in the long run it will be very expensive since they will have to compete with transactions that actually use the utxo, a feature that is more valuable. But that's mostly speculation and doesn't imply the need for any action against it. I would strongly opposed to against a limitation on OP_RETURN at the protocol level (other than the block size limit itself, that is) and wouldn't mind if they're removed from isStandard. I didn't payed much attention to that and honestly I don't care enough. Maybe this encourages miners to adopt their own policies, which could be good for things like replace-by-fee, the rational policy for miners, which I strongly support (combined with game theory can provide instant transactions as you pointed out in another thread). Maybe the right approach to keep improving modularity and implement different and configurable mining policies. All these methods have some overhead compared to just using OP_RETURN and thus cost more. I thought the consensus was that op_return was the right way to put non-validated data in the chain, but limiting it in standard policies doesn't seem consistent with that. Finally I'll be writing something more detailed soon about why proof-of-publication is essential and miners would be smart to support it. But the tl;dr: of it is if you need proof-of-publication for what your system does you're much more secure if you're embedded within Bitcoin rather than alongside of it. There's a lot of very bad advise getting thrown around lately for things like Mastercoin, Counterparty, and for that matter, Colored Coins, to use a separate PoW blockchain or a merge-mined one. The fact is if you go with pure PoW, you risk getting attacked while your still growing, and if you go for merge-mined PoW, the attacker can do so for free. We've got a real-world example of the former with Twister, among many others, usually resulting in a switch to a centralized checkpointing scheme. For the latter we have Coiledcoin, an alt that made the mistake of using SHA256 merge-mining and got killed off early at birth with a zero-cost 51% attack. There is of course a censorship risk to going the embedded route, but at least we know that for the forseeable future doing so will require explicit blacklists, something most people here are against. The proof of publication vs separate chain discussion is orthogonal to the merged mining vs independent chain one. If I remember correctly, last time you admitted after my example that merged mining was comparatively better than a separate chain, that it was economically harder to attack. I guess ecological arguments won't help here, but you're confusing people developing independent chains and thus pushing them to a less secure (apart from more wasteful setup) system design. Coiledcoin just proofs that merged mining may not be the best way to bootstrap a currency, but you can also start separated and then switch to merged mining once you have sufficient independent support. As far as I can tell twister doesn't have a realistic reward mechanism for miners so the incentives are broken before considering merged mining. Proof of work is irreversible and it's a good thing to share it. Thanks Satoshi for proposing this great idea of merged mining and thanks vinced for a first implementation with a data structure that can be improved. Peter Todd, I don't think you're being responsible or wise saying nonsense like merged mined chains can be attacked for free and I suggest that you prove your claims by attacking namecoin for free, please, enlighten us, how that's done? It should be easier with the scamcoin ixcoin, with a much lower subsidy to miners so I don't feel bad about the suggestion if your free attack somehow works (certainly using some magic I don't know about). -- Jorge Timón http://freico.in/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote: There's been a lot of recent hoopla over proof-of-publication, with the OP_RETURN data length getting reduced to a rather useless 40 bytes at the last minute prior to the 0.9 release. Secondly I noticed a overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken into account, making it possible to broadcast unminable transactions and bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG outputs given that the sigops limit and the way they use up a fixed 20 sigops per op makes them hard to do fee calculations for. They also make it easy to bloat the UTXO set, potentially a bad thing. This would of course require things using them to change. Currently that's just Counterparty, so I gave them the heads up in my email. I've spend some time looking at the Datacoin code, and I've come to the conclusion the next copycatcoin I release will have an explicit 'data' field with something like 169 bytes (a bakers dozen squared), which will add 1 byte to each transaction if unused, and provide a small, but usable data field for proof of publication. As a new coin, I can also do a hardfork that increases the data size limit much easier if there is a compelling reason to make it bigger. I think this will prove to be a much more reliable infrastructure for proof of publication than various hacks to overcome 40 byte limits with Bitcoin. I am disclosing this here so the bitcoin 1% has plenty of time to evaluate the market risk they face from the 40 byte limit, and put some pressure to implement some of the alternatives Todd proposes. -- 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 -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Let's not pull out silly examples. Of course you can find locations that lack Internet. Those locations are completely unsuitable to bitcoin transactions, since the receiver cannot verify double-spending or anything else about the transaction. On Fri, Mar 21, 2014 at 9:59 AM, Alex Kotenko alexy...@gmail.com wrote: 2014-03-21 10:28 GMT+00:00 Andreas Schildbach andr...@schildbach.de: On 03/20/2014 06:31 PM, Jeff Garzik wrote: Afaik, BIP73 needs an external server (the web server). Yes. Internet connectivity is not a rarity these days. Near-field web servers also work fine. Unfortunately it still is. At least here in Germany. Yes, it is a problem. Even in the middle of London you often can get into situation when cellphone network connectivity is not good enough for quick and reliable payment. Basement pubs, old buildings with thick walls, overcrowded places with overloaded radio environment. We should not rely on mobile connectivity in things like making payments. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Those locations are completely unsuitable to bitcoin transactions, since the receiver cannot verify double-spending or anything else about the transaction. The usual issue is that they lack internet *for some customers*. The place may well have private wifi or hardwired connections that work. Even mobile networks may vary so some customers will have mobile connectivity and others won't. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fake PGP key for Gavin
In case you didn't see this yet, http://gavintech.blogspot.ch/2014/03/it-aint-me-ive-got-pgp-imposter.html If you're using PGP to verify Bitcoin downloads, it's very important that you check you are using the right key. Someone seems to be creating fake PGP keys that are used to sign popular pieces of crypto software, probably to make a MITM attack (e.g. from an intelligence agency) seem more legitimate. I think the Mac DMG's of Core are signed for Gatekeeper, but do we codesign the Windows binaries? If not it'd be a good idea, if only because AV scanners learn key reputations to reduce false positives. Of course this is not a panacea, and Linux unfortunately does not support X.509 code signing, but having extra signing can't really hurt. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
Please, by all means: ignore our well-reasoned arguments about externalized storage and validation cost and alternative solutions. Please re-discover how proof of publication doesn't require burdening the network with silly extra data that must be transmitted, kept, and validated from now until the heat death of the universe. Your failure will make my meager bitcoin holdings all the more valuable! As despite persistent assertions to the contrary, making quality software freely available at zero cost does not pay well, even in finance. You will not find core developers in the Bitcoin 1%. Please feel free to flame me back, but off-list. This is for *bitcoin* development. On 03/22/2014 08:08 AM, Troy Benjegerdes wrote: On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote: There's been a lot of recent hoopla over proof-of-publication, with the OP_RETURN data length getting reduced to a rather useless 40 bytes at the last minute prior to the 0.9 release. Secondly I noticed a overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken into account, making it possible to broadcast unminable transactions and bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG outputs given that the sigops limit and the way they use up a fixed 20 sigops per op makes them hard to do fee calculations for. They also make it easy to bloat the UTXO set, potentially a bad thing. This would of course require things using them to change. Currently that's just Counterparty, so I gave them the heads up in my email. I've spend some time looking at the Datacoin code, and I've come to the conclusion the next copycatcoin I release will have an explicit 'data' field with something like 169 bytes (a bakers dozen squared), which will add 1 byte to each transaction if unused, and provide a small, but usable data field for proof of publication. As a new coin, I can also do a hardfork that increases the data size limit much easier if there is a compelling reason to make it bigger. I think this will prove to be a much more reliable infrastructure for proof of publication than various hacks to overcome 40 byte limits with Bitcoin. I am disclosing this here so the bitcoin 1% has plenty of time to evaluate the market risk they face from the 40 byte limit, and put some pressure to implement some of the alternatives Todd proposes. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Jeff, there are *plenty* of places that lack local Internet access for one or both participants. Obviously making the case where both participants lack access to the bitcoin network is difficult to secure, but not impossible (e.g. use a telephany-based system to connect to a centralized double-spend database, as VISA does). I expect the case where one participant has Internet access (the merchant) and the other does not to be very, very common. The majority of transactions I do on a daily basis are like this, and I live in Silicon Valley! On 03/22/2014 09:35 AM, Jeff Garzik wrote: Let's not pull out silly examples. Of course you can find locations that lack Internet. Those locations are completely unsuitable to bitcoin transactions, since the receiver cannot verify double-spending or anything else about the transaction. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
One participant, yes. Two participants lacking net would require a serious revisit of BIP 70's security assumptions and some design, at a minimum. On Sat, Mar 22, 2014 at 12:55 PM, Mark Friedenbach m...@monetize.io wrote: Jeff, there are *plenty* of places that lack local Internet access for one or both participants. Obviously making the case where both participants lack access to the bitcoin network is difficult to secure, but not impossible (e.g. use a telephany-based system to connect to a centralized double-spend database, as VISA does). I expect the case where one participant has Internet access (the merchant) and the other does not to be very, very common. The majority of transactions I do on a daily basis are like this, and I live in Silicon Valley! On 03/22/2014 09:35 AM, Jeff Garzik wrote: Let's not pull out silly examples. Of course you can find locations that lack Internet. Those locations are completely unsuitable to bitcoin transactions, since the receiver cannot verify double-spending or anything else about the transaction. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
I think it's mostly a UI issue. The recipient needs to understand that what he received is nothing more than an IOU that can be revoked at any time. If the UI makes it clear and the user trusts the sender, no problem. BIP70 would work as before. On Sat, Mar 22, 2014 at 6:24 PM, Jeff Garzik jgar...@bitpay.com wrote: One participant, yes. Two participants lacking net would require a serious revisit of BIP 70's security assumptions and some design, at a minimum. On Sat, Mar 22, 2014 at 12:55 PM, Mark Friedenbach m...@monetize.io wrote: Jeff, there are *plenty* of places that lack local Internet access for one or both participants. Obviously making the case where both participants lack access to the bitcoin network is difficult to secure, but not impossible (e.g. use a telephany-based system to connect to a centralized double-spend database, as VISA does). I expect the case where one participant has Internet access (the merchant) and the other does not to be very, very common. The majority of transactions I do on a daily basis are like this, and I live in Silicon Valley! On 03/22/2014 09:35 AM, Jeff Garzik wrote: Let's not pull out silly examples. Of course you can find locations that lack Internet. Those locations are completely unsuitable to bitcoin transactions, since the receiver cannot verify double-spending or anything else about the transaction. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fake PGP key for Gavin
On Sat, Mar 22, 2014 at 1:03 PM, Mike Hearn m...@plan99.net wrote: do we codesign the Windows binaries? Yes, the -setup.exe installers are Authenticode (or whatever Microsoft is calling that these days) code-signed. -- -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fake PGP key for Gavin
On Sat, Mar 22, 2014 at 06:03:03PM +0100, Mike Hearn wrote: In case you didn't see this yet, http://gavintech.blogspot.ch/2014/03/it-aint-me-ive-got-pgp-imposter.html If you're using PGP to verify Bitcoin downloads, it's very important that you check you are using the right key. Someone seems to be creating fake PGP keys that are used to sign popular pieces of crypto software, probably to make a MITM attack (e.g. from an intelligence agency) seem more legitimate. Note that Bitcoin source and binary downloads are protected by both the PGP WoT and the certificate authority PKI system. The binaries are hosted on bitcoin.org, which is https and protected by a the PKI system, and the source code is hosted on github, again, https protected. A MITM attack would need to compromise the PKI system as well, at least provided users aren't fooled into downloading over http. -- 'peter'[:-1]@petertodd.org 657de91df7a64d25adfd3ff117bc30d00f5aa3065894f4a5 signature.asc Description: Digital signature -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
On Sat, Mar 22, 2014 at 10:08:36AM -0500, Troy Benjegerdes wrote: On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote: There's been a lot of recent hoopla over proof-of-publication, with the OP_RETURN data length getting reduced to a rather useless 40 bytes at the last minute prior to the 0.9 release. Secondly I noticed a overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken into account, making it possible to broadcast unminable transactions and bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG outputs given that the sigops limit and the way they use up a fixed 20 sigops per op makes them hard to do fee calculations for. They also make it easy to bloat the UTXO set, potentially a bad thing. This would of course require things using them to change. Currently that's just Counterparty, so I gave them the heads up in my email. I've spend some time looking at the Datacoin code, and I've come to the conclusion the next copycatcoin I release will have an explicit 'data' field with something like 169 bytes (a bakers dozen squared), which will add 1 byte to each transaction if unused, and provide a small, but usable data field for proof of publication. As a new coin, I can also do a hardfork that increases the data size limit much easier if there is a compelling reason to make it bigger. I think this will prove to be a much more reliable infrastructure for proof of publication than various hacks to overcome 40 byte limits with Bitcoin. I am disclosing this here so the bitcoin 1% has plenty of time to evaluate the market risk they face from the 40 byte limit, and put some pressure to implement some of the alternatives Todd proposes. Lol! Granted, I guess I should disclose that I'm working on tree chains, which just improve the scalability of blockchains directly. I'm think tree-chains could be implemented as a soft-fork; if applied to Bitcoin the datacoin 1% might face market risk. :P -- 'peter'[:-1]@petertodd.org bbcc531d48bea8d67597e275b5abcff18e18f46266723e91 signature.asc Description: Digital signature -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
On Sat, Mar 22, 2014 at 02:53:41PM +0100, Jorge Timón wrote: On 3/22/14, Peter Todd p...@petertodd.org wrote: There's been a lot of recent hoopla over proof-of-publication, with the OP_RETURN data length getting reduced to a rather useless 40 bytes at the last minute prior to the 0.9 release. I'm not against about miners accepting transactions that have longer data in non-utxo polluting OP_RETURN than whatever is specified as standard by the reference implementation, maybe it should be risen in standard but I think it was assumed that the most common case would be to include the root hash of some merklized structure. My only argument against non-validated proof of publication is that in the long run it will be very expensive since they will have to compete with transactions that actually use the utxo, a feature that is more valuable. But that's mostly speculation and doesn't imply the need for Well remember that my thinking re: UTXO is that we need to move to a system like TXO commitments where storing the entirety of the UTXO set for all eternity is *not* required. Of course, that doesn't necessarily mean you can't have the advantages of UTXO commitments, but they need to be limited in some reasonable way so that long-term storage requirements do not grow without bound unreasonably. For example, having TXO commitments with a bounded size committed UTXO set seems reasonable; old UTXO's can be dropped from the bounded sized set, but can still be spent via the underlying TXO commitment mechanism. any action against it. I would strongly opposed to against a limitation on OP_RETURN at the protocol level (other than the block size limit itself, that is) and wouldn't mind if they're removed from isStandard. I didn't payed much attention to that and honestly I don't care enough. Maybe this encourages miners to adopt their own policies, which could be good for things like replace-by-fee, the rational policy for miners, which I strongly support (combined with game theory can provide instant transactions as you pointed out in another thread). Maybe the right approach to keep improving modularity and implement different and configurable mining policies. Like I said the real issue is making it easy to get those !IsStandard() transactions to the miners who are interested in them. The service bit flag I proposed + preferential peering - reserve, say, 50% of your peering slots for nodes advertising non-std tx relaying - is simple enough, but it is vulnerable to sybil attacks if done naively. All these methods have some overhead compared to just using OP_RETURN and thus cost more. I thought the consensus was that op_return was the right way to put non-validated data in the chain, but limiting it in standard policies doesn't seem consistent with that. Right, but there's also a lot of the community who thinks proof-of-publication applications are bad and should be discouraged. I argued before that the way OP_RETURN was being deployed didn't actually give any reason to use it vs. other data encoding methods. Unfortunately underlying all this is a real ignorance about how Bitcoin actually works and what proof-of-publication actually is: 14-03-20.log:12:47 gavinandresen jgarzik: RE: mastercoin/OP_RETURN: what's the current thinking on Best Way To Do It? Seems if I was to do it I'd just embed 20-byte RIPEMD160 hashes in OP_RETURN, and fetch the real data from a DHT or website (or any-of-several websites). Blockchain as reference ledger, not as data storage. Peter Todd, I don't think you're being responsible or wise saying nonsense like merged mined chains can be attacked for free and I suggest that you prove your claims by attacking namecoin for free, please, enlighten us, how that's done? I think we're just going to have to agree to disagree on our interpretations of the economics with regard to attacking merge-mined chains. Myself, I'm very, very wary of systems that have poor security against economically irrational attackers regardless of how good the security is, in theory, against economically rational ones. Again, what it comes down to in the end is that when I'm advising Mastercoin, Counterparty, Colored Coins, etc. on how they should design their systems I know that if they do proof-of-publication on the Bitcoin blockchain, it may cost a bit more money than possible alternatives per transaction, but the security is very well understood and robust. Fact is, these applications can certainly afford to pay the higher transaction fees - they're far from the least economically valuable use of Blockchain space. Meanwhile the alternatives have, at best, much more dubious security properties and at worse no security at all. (announce/commit sacrifices is a great example of this, and very easy to understand) -- 'peter'[:-1]@petertodd.org bbcc531d48bea8d67597e275b5abcff18e18f46266723e91 signature.asc Description: Digital signature
Re: [Bitcoin-development] Fake PGP key for Gavin
Am 22.03.2014 18:03, schrieb Mike Hearn: In case you didn't see this yet, http://gavintech.blogspot.ch/2014/03/it-aint-me-ive-got-pgp-imposter.html If you're using PGP to verify Bitcoin downloads, it's very important that you check you are using the right key. Someone seems to be creating fake PGP keys that are used to sign popular pieces of crypto software, probably to make a MITM attack (e.g. from an intelligence agency) seem more legitimate. From the user's perspective: In the beginning I found it difficult to find the keys. At last I have made this side for documentation: https://www.olivere.de/blog/archives/2013/06/02/install_bitcoin_client/ Okay, is outdated meanwhile ... Normally people fetch the keys by key-id from a well known key server. Not because they are paranoid, but because it is the most convenient method under Linux. A Google search for Gavin+Andresen+gpg brings me herein: http://sourceforge.net/p/bitcoin/mailman/message/30551147/ Key-Id? Nevertheless, I'm glad that you guys signed anything. That makes me sleep better. I really check this. - oliver GPG: https://olivere.de/gpg -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
I know that general approach to interaction design in Bitcoin assumes minimal to no difference between payer and payee, and generally I agree with this approach. However, for the sake of my PoS development this assumption is wrong by default, as PoS is a specialized hardware, and one who cared to buy and install it is probably not in the same situation as the other party that didn't care to by anything dedicated. In short - from PoS point of view there is a customer and a merchant. And my goal is to make thing work in assumption of fast and reliable connection on merchant side and no connection requirement at all from customer side. I didn't put a silly example, as of my experience there are really a lot of places where cellphone connection isn't good enough for reliable Bitcoin operation. However, if we're talking about merchant establishments - we can hope for private local WiFi or wired connection on PoS side, so PoS internet connection shouldn't be an issue. So this is the use case I'm designing around and this is why bluetooth based BIP70 implementation is important for me. I partly agree with Mike on user interface and IOU idea, but I have no intention to implement anything like that right now. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
