Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Sat, Feb 14, 2015 at 11:04:49AM -0800, Adam Back wrote: Strongly with Peter on this. That its highly complex to maintain strict consensus between bitcoin versions, does not justify consensus rewrite experiments; it tells you that the risk is exponentially worse and people should use and rally around libconsensus. It's worth remembering that one of the goals in writing - or to be more precise, separating - libconsensus from the Bitcoin Core codebase is to make it easier to maintain strict consensus between Bitcoin Core versions. I would advise any bitcoin ecosystem part, wallet, user to not use software with consensus protocol rw-writes nor variants, you WILL lose money. You could view bitcoin as a digital signature algorithm speculatively tinkering with the algo is highly prone to binary failure mode and unbounded funds loss. Want to be clear this is not a political nor emotive issue. It is a critical technical requirement for security if users of software people write. The necessity of it isn't a political or emotive issue, but the consequences are definitely political. Just not in the way that most of the ecosystem appears to think. -- 'peter'[:-1]@petertodd.org 16b6444e463c7d92da1579360c5f71d4fbd3dab45d13990a signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Sun, Feb 15, 2015 at 06:13:06PM +0100, Tamas Blummer wrote: On Feb 15, 2015, at 6:02 PM, Peter Todd p...@petertodd.org wrote: Yes you are dicking around. I thought I was clear, that I am using Bitcoin Core as border router talking to its P2P interface. Ah, sorry, that wasn't clear to me. The reimplementation of consensus code helped me to deeply understand the protocol, aids debugging and now comes handy to create a side chain. Indeed, which is why I've done a lot of work on a reimplementation of the Bitcoin scripting system as well: https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/core/scripteval.py Which has this cheery warning at the top: Script evaluation Be warned that there are highly likely to be consensus bugs in this code; it is unlikely to match Satoshi Bitcoin exactly. Think carefully before using this module. I'll be adding a FFI interface to libconsensus in the future... and I probably should make that warning scarier... -- 'peter'[:-1]@petertodd.org 00ffb7a576b7aa5236c53f51ec07ccf174067beed3398056 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Sat, Feb 14, 2015 at 03:23:47PM +0100, Tamas Blummer wrote: Peter, You did not address me but libbitcoin. Since our story and your evaluation is probably similar, I chime in. On Feb 14, 2015, at 2:13 PM, Peter Todd p...@petertodd.org wrote: So stop wasting your time. Help get the consensus critical code out of Bitcoin Core and into a stand-alone libconsensus library, We have seen that the consensus critical code practically extends to Berkley DB limits or OpenSSL laxness, therefore it is inconceivable that a consensus library is not the same as Bitcoin Core, less its P2P service rules, wallet and RPC server. Wallet and RPC server are definitely not consensus critical code. P2P service rules are weakly consensus critical, in that a failure to relay valid blocks can in practice cause a loss of consensus. But relaying valid blocks is very easy, and you only need sone relay mechanism out of many to work for consensus to be maintained. OpenSSL is getting replaced by libsecp256k1, a library designed for consensus-critical applications. As for databases, look at the good #bitcoin-wizards discussion yesterday for strategies to make databases less relevant to consensus. On Feb 14, 2015, at 2:13 PM, Peter Todd p...@petertodd.org wrote: Or you can be stereotypical programmers and dick around on github for the next ten years chasing stupid consensus bugs in code no-one uses. The Core code base is unfriendly to feature extensions because of its criticality, legacy design and ancient technology. It is also a commodity that the ecosystem takes for granted and free. Are you referring to feature extensions to consensus critical code - like my own CHECKLOCKTIMEVERIFY? - or extensions to code that isn't consensus critical? I honestly admire the core team that works and progresses within these limits and perception. I am not willing to work within the core’s legacy technology limits. Does it mean I am dicking around? I think not. It was my way to go down the rabbit hole by re-digging it and I created successful commercial products on the way. Yes you are dicking around. The effort you're going to spend recreating the core consensus code and getting it right is orders of magnitude more work than figuring out how to use the foreign function interface in your chosen language, or at worse, just running Bitcoin Core to do validation and using RPC or the p2p protocol locally to track that state. Don't assume your prior experience with other commercial projects has any bearing on Bitcoin: consensus-critical crypto is a brand new field within software engineering with very unique requirements, pioneered by Bitcoin itself. -- 'peter'[:-1]@petertodd.org 0a37c901cf2ae6c281f47b237e9bf1d7268fb561b4332345 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)
On Feb 15, 2015, at 6:02 PM, Peter Todd p...@petertodd.org wrote: Yes you are dicking around. I thought I was clear, that I am using Bitcoin Core as border router talking to its P2P interface. The reimplementation of consensus code helped me to deeply understand the protocol, aids debugging and now comes handy to create a side chain. Don't assume your prior experience with other commercial projects Acquire some before you claim its useless. Tamas Blummer signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] P2P tests: peers.dat's requested
Hi All, I am currently running some tests on the peering system in Bitcoind for a research paper. We hope to develop improvements which we can share with the community. A wide diversity of real peers.dat files would be very helpful. If you are willing, please email me your peers.dat. Thanks, -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 10:27:53AM -0500, Jeff Garzik wrote: Repeating past statements, it is acknowledged that Peter's scorched earth replace-by-fee proposal is aptly named, and would be widely anti-social on the current network. At a high level, we can see that this thread is contentious because this covers _what we want bitcoin to be_, and that is an opinion (versus engineering fact), and it varies from person to person. I find Peter's proposal relatively mild. I'd prefer that instead of exchanges going bankrupt, that there be direct blockchain support for key revocation and 'burning' stolen coins, and an economic ecosystem that supports insurance underwriters that pay out when someone inevitably gets hacked. This would definitely be 'scorched earth' at one level, but I think would make for a far more transparent and friendly system. However, hope is the denial of reality...instead we should walk forward with our eyes open[1]. My interest in bitcoin originates from the science fiction concept of credits[2], a universal money that transcends national borders and even planets. That is what I hoped bitcoin would be. universal payments is both a laudable goal and a shopworn bitcoin marketing slogan. The fundamental engineering truths diverge from that misty goal: Bitcoin is a settlement system, by design. Most money/payment systems include some method to reverse or undo payments made in error. In these systems, the longer settlement times you mention below are a feature, not a bug, and give more time for a human to react to errors and system failures. The process of consensus settles upon a timeline of transactions, and this process -- by design -- is necessarily far from instant. Alt-coins that madly attempt 10-second block times etc. are simply a vain attempt to paper over this fundamental design attribute: consensus takes time. As such, the blockchain can never support All The Transactions, even if block size increases beyond 20MB. Further layers are -- by design -- necessary if we want to achieve the goal of a decentralized payment network capable of supporting full global traffic. Bitcoin payments are like IP packets -- one way, irreversible. For larger value transfers this attaches attendent risk of loss -- as we've seen in the field time again. The world's citizens en masse will not speak to each other with bitcoin (IP packets), but rather with multiple layers (HTTP/TCP/IP) that enable safe and secure value transfer or added features such as instant transactions. I see a world in which we have many blockchains, along with not-quite blockchain things like ripple that approximate that vision you have of 'credits'. But we cannot have one chain to rule them all, for there are inherent engineering trade-offs that one chain can never resolve. There appear to be some things we will never come to a consensus on, such as transaction reversibility, or what the optimal money supply algorithm is. However we might learn a great deal from sharing code and ideas. So in that line, see my thoughts on reversibility [3][4] This opinion is not a conspiracy to put the bankers back in charge -- it is a simple acknowledgement of bitcoin's design. The consensus system settles on a timeline. Bitcoin transactions are, by definition, not instant. Zero confirmation transactions are, by definition, not secure. Proposals such as Oleg's are _necessary_ to fully build out the bitcoin system. Avoid short-sighted, short-term thinking that views the lowest layer (one-way value xfer) at the most optimal layer at which free persons will transact freely instantly across planet Earth. It is foolish to think the entire world will connect directly to the P2P block network and broadcast all the morning coffees to all the miners. That's not how the system works. It is a settlement layer. We _must_ build decentralized layered solutions on top of bitcoin, rather than stuffing everything into bitcoin itself. I'll say the same about not stuffing everthing on top of the same blockchain. We might very well have coffee shops that take coffecoin. But Bitcoin will never be able to scale out horizontally like altcoins can. [1] http://www.goodreads.com/quotes/35199-hope-is-the-denial-of-reality-it-is-the-carrot [2] http://garzikrants.blogspot.com/2013/06/shadowrun-and-bitcoins-roots.html [3] https://bitbucket.org/tmagik/catoshi/issue/24 [4] https://bitbucket.org/tmagik/catoshi/issue/27 On Thu, Feb 12, 2015 at 6:58 AM, Mike Hearn m...@plan99.net wrote: I know you will ignore this as usual, but the entire replace-by-fee folly is based on your fundamental misunderstanding of miner incentives. Miners are not incentivised to earn the most money in the next block possible. They are incentivised to maximise their return on investment. Making Bitcoin much less useful reduces demand for the bitcoins they are mining, reducing coinbase and fee income in
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote: On Feb 12, 2015, at 9:16 AM, Alex Mizrahi alex.mizr...@gmail.com wrote: Why don't you use getrawmempool RPC call to synchronize mempool contents? Since RPC interface does not scale to serve a multi user service. In absence of better alternative, the interfaces used by a proprietary extension are usually the same as in P2P consensus. POW is used to figure the longest chain and until now broadcasted transactions were assumed the one and only. These simple rules ensure a consensus between the proprietary stack and the border router, and that is the consensus I referred to. If a proprietary stack has problems with replace-by-fee then it's probably succeptible to malicious attack because an attacker could just broadcast one transaction to the network and then replace it when they are able to mine a block themselves. On Feb 12, 2015, at 8:45 AM, Peter Todd p...@petertodd.org wrote: IOW, assume every transaction your border router gives you is now the one and only true transaction, and everything conflicting with it must go. You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic . -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development