Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-15 Thread Peter Todd
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?)

2015-02-15 Thread Peter Todd
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?)

2015-02-15 Thread Peter Todd
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?)

2015-02-15 Thread Tamas Blummer

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

2015-02-15 Thread Ethan Heilman
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

2015-02-15 Thread Troy Benjegerdes
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

2015-02-15 Thread Troy Benjegerdes
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