Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-14 Thread Ross Nicoll

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Arriving slightly late to the discussion, apologies.

Personally I wouldn't have written that patch, but I know development of
hostile patches happens out of sight, and if it can be written, we have
to presume it will be written eventually. I'd have preferred a patch
that only replaced non-final txes, which is the use-case I have for
transaction replacement, but that's easy to add back in.

I'm certainly not terribly convinced of the security of vanilla
zero-confirmation transactions myself, for reasons including but not
limited to this case. I also think it's important to understand that
people do make irrational decisions, and trusting network security on
everyone behaving perfectly rationally is not a workable model either.

TLDR; me too

Ross

On 12/02/15 20:36, Allen Piscitello wrote:
 You keep making moral judgements.  Reality is, if you live in a world with
 arsonists, you need to have a building that won't catch on fire, or has
 fire extinguishers in place.  Do not depend on arsonists ignoring you
 forever as your security model.  Penetration testing to know what
 weaknesses exist, what limitations exist, and what can be improved is
 essential.  Keeping your head in the sand and hoping people choose to do
 the right thing only ends one way.

 On Thu, Feb 12, 2015 at 1:52 PM, Justus Ranvier justusranv...@riseup.net
 wrote:

 On 02/12/2015 07:47 PM, Allen Piscitello wrote:
  Nothing will stop that.  Bitcoin needs to deal with those issues,
  not stick our heads in the sand and pretend they don't exist out of
  benevolence. This isn't a pet solution, but the rules of the
  protocol and what is realistically possible given the nature of
  distributed consensus.  Relying on altruism is a recipe for
  failure.

 If there's a risk of fire burning down wooden buildings, pass out fire
 extinguishers and smoke detectors, not matches.

 The latter makes one an arsonist.




--
 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






--
 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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJU31/yAAoJEJFC5fflM8475YIIAI7nxgxUdkKiMePMqtvPOi25
U+WCxjvIK0ZRTAV30POC7fKLT2mK0gPusSS7LtNJpPKvpC98VcSD5HWE49K80Yo9
9+QI7X7xBau1jjLo+27uOex0bJ6JwP1DSMpC12AQbMmi4FnyG+M5FMkr5/OnSxeF
cd4lT2UF7yTJPRy0+A9LwertL5Sv1yeOJJ9jtWuXgixapmHN+1Zm2VkGnur55V64
vnonlixlUMwnZNxDVoRhjTWm1P/lmCejvmvTRvcBomUlAEgRQF4TtF4YMBYXS97S
5WYrxOHLgTfTWr3FJuOnd+CVBRgZGw3u30ktaSErelyMG19lJOusBPdHTQFkV30=
=eWPj
-END PGP 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-14 Thread Tamas Blummer
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.


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. 

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.

It is entirely rational for me to focus on innovation that uses the core as a 
border router for this block chain. 

I am rather thankful for the ideas of the side chains, that enable innovation 
that is no longer measured on unapologetic compatibility with a given code 
base, but its services to end user.

Tamas Blummer
Bits of Proof



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] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-14 Thread Peter Todd
I haven't bothered reading the thread, but I'll put this out there:

The consensus critical Satoshi-derived sourcecode is a protocol
*specification* that happens to also be machine readable and executable.
Rewriting it is just as silly as as taking RFC 791 and rewriting it
because you wanted to decentralize control over the internet

My replace-by-fee fork of Bitcoin Core is a perfect case in point: it
implements different non-consensus-critical policy than Bitcoin Core
does, while adhering to the same Bitcoin protocol by virtue of being the
same sourcecode - the same protocol specification. When I went to miners
asking them to implement it, the biggest concern for them is Will it
stay in consensus with other miners? If I had rewritten the whole thing
from scratch the fact is the honest answer to them would be no way in
hell - reimplementing Bitcoin and getting it right is software
engineering's Apollo Project and none of us have the resources to pull
that off. But I didn't, which means we might soon have a significant
chunk of hashing power implementing a completely different mining policy
than what is promoted by the Bitcoin Core maintainers.

By reimplementing consensus code - rewriting the protocol spec - you
drop out of the political process that is Bitcoin development. You're
not decentralizing Bitcoin at all - you're contributing to its
centralization by not participating, leaving behind a smaller and more
centralized development process. Fact is, what you've implemented in
libbitcoin just isn't the Bitcoin protocol and isn't going to get
adopted by miners nor used by serious merchants and exchanges - the
sources of real political power.


Right now we could live in a world where a dozen different groups
maintain Bitcoin implementations that are actually used by miners. We
could have genuine innovation on the p2p networking layer, encryption,
better privacy for SPV clients, better resistance to DoS attacks. We
could have diverse tx acceptance policies rather than wasting hundreds
of man hours bitching about how many bytes OP_RETURN should allow. We
could have voices from multiple groups at the table when the community
discusses how to scale Bitcoin up.

Instead we have a world with a half dozen teams wasting hundreds if not
thousands of of man hours dicking around trying to rewrite consensus
critical *specifications* because they happen to be perfectly good
executable code, and the first thing a programmer thinks when they see
perfectly good battle-hardened code is Hey! Let's rewrite that from
scratch!


You know you does have significant political power over the development
of the Bitcoin protocol *other* than the Bitcoin Foundation?

Luke Dashjr.

Because he maintains the Eligius fork of Bitcoin Core that something
like %30 of the hashing power run. It Actually Works because it uses the
Actual Protocol Specification, and miners know if they run it they
aren't going to lose tens of thousands of dollars. It's why it's easy to
get transactiosn mined that don't meet the Bitcoin Core's IsStandard()
rules: they aren't part of the protocol spec, and Luke-Jr has different
views on what transactions should and should not be allowed into the
blockchain.

And when Gavin Andresen starts negotiating with alt-implementations to
get his bloat coin proposals implemented, you know who's going to be at
the table? Luke-Jr again! Oh sure, the likes of btcd, libbitcoin, toshi,
etc. will get invited, but no-one's going to really care what they say.
Because at best only a tiny - and foolish - sliver of hashing power will
be using their implementations of Something Almost But Not Quite
Bitcoin™, and any sane merchant or exchange will be running at least one
or two Bitcoin Foundation Genuine Bitcoin Core™ nodes in front of any
from-scratch alt-implementation.


So stop wasting your time. Help get the consensus critical code out of
Bitcoin Core and into a stand-alone libconsensus library, wrap it in the
mempool policy, p2p networking code, and whatever else you feel like,
and convince some hashing power to adopt it. Then enjoy the fruits of
your efforts when the next time we decide to soft-fork Bitcoin the
process isn't some secretive IRC discussion by a half-dozen core
developers - and one guy who finds the term hilarious - but a full on
DIRECT DEMOCRACY OCCUPY WALL STREEET MODIFIED CONSENSUS POW-WOW,
complete with twinkle fingers. A pow-wow that you'll be an equal part
of, and your opinions will matter.

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 choice is yours.


On Sat, Feb 14, 2015 at 03:16:16AM -0800, Eric Voskuil wrote:
 On 02/14/2015 01:51 AM, Jorge Timón wrote:
  I agree that this conversation is not being productive anymore. I'm
  doing my best to understand you but I just happen to disagree with
  many of your arguments.
  I doubt it makes you feel better but it's being tedious and
  frustrating for me as 

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

2015-02-14 Thread Adam Back
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.

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.

Please promote this meme.

Adam
On Feb 14, 2015 6:24 AM, Tamas Blummer ta...@bitsofproof.com 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.


 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.

 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.

 It is entirely rational for me to focus on innovation that uses the core
 as a border router for this block chain.

 I am rather thankful for the ideas of the side chains, that enable
 innovation that is no longer measured on unapologetic compatibility with a
 given code base, but its services to end user.

 Tamas Blummer
 Bits of Proof



 --
 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


--
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-14 Thread Bryan Bishop
On Sat, Feb 14, 2015 at 1:04 PM, Adam Back a...@cypherspace.org wrote:

 That its highly complex to maintain strict consensus between bitcoin
 versions, does not justify consensus rewrite experiments


Correct. However, those maintenance costs absolutely do justify working
towards formal proofs of correctness for the existing implementation. These
plans are no secret and are publicly discussed, but I think it would be
instrumental to outsiders if the correctness plans and ongoing progress
could be mentioned whenever a warning is made about unjustified and
dangerous Bitcoin consensus rewrite attempts.

- Bryan
http://heybryan.org/
1 512 203 0507
--
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-14 Thread Jorge Timón
On Sat, Feb 14, 2015 at 3:23 PM, Tamas Blummer ta...@bitsofproof.com wrote:
 Peter,
 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.

Right now libconsensus' only dependency is openSSL. Most of the
testing in libsecp256k1 has been in signing rather than verifying
signatures (please, anyone with more knowledge in the library don't
hesitate to correct me or clarify things). But eventually openSSL will
be completely replaced by libsecp256k1.
It does not store anything, 0.1 is just a dynamic library with a c API
to a single function: VerifyScript().
This function saves the hassle of reimplementing signature checking
(which is a really hard part) and reimplementing an interpreter that
must function in exactly the same way in many as many other nodes with
different software and/or hardware.
Guido van Rossum can say some behaviours in python the language are
not specified, so it is ok if cpython and pypy do different things,
they're still both running python which is more abstract than any of
its implementation.
But a consensus system like bitcoin doesn't have the luxury of leaving
consensus rules unspecified. And the simplest way to fully specify a
language interpreter is by implementing it.
But coupling the consensus rules specification with a bigger project
like bitcoin core can result in implementation details of that bigger
project accidentally and unexpectedly becoming consensus rules. This
is what happened with bdb and nobody wants that to happen again,
that's the whole point.
Note that many parts of the bitcoin protocol (like the p2p messages)
are NOT part of the consensus rules.
You can have a look at
https://github.com/jtimon/bitcoin/commits/consensus2 and maybe you
would be surprised about how small they actually are. This branch is
incomplete and still a mess that needs to be cleaned up. And none of
that is included in libconsensus yet.
I was planning on writing a post here asking for feedback on the
interfaces for these higher level checks. I'm just putting the code
together in the same module, but obviously class CCoinsViewCache
cannot be an argument in functions of a c API.

 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.

 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.

Nobody is attacking alternative implementations. This tool was created
mostly with alternative implementations in mind.
So input from them it's very welcomed on how to continue libconsensus
(or of course correct any flaws in verifyScript if there's any).
I just wanted to wait to have some more code to make things easier to
explain (and have a clearer idea of it myself).
There's a more limited branch on next steps for libconsensus in #5669.

 It is entirely rational for me to focus on innovation that uses the core as
 a border router for this block chain.

Sure, I think he is complaining that at the moment that's probably the
only safe way to operate with alternative implementations and still
have full node guarantees.

 I am rather thankful for the ideas of the side chains, that enable
 innovation that is no longer measured on unapologetic compatibility with a
 given code base, but its services to end user.

Sidechains are completely orthogonal to this discussion and, in fact,
it would be good to have libconsensuses for sidechains too, since
their nodes also need to come to consensus.

--
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-14 Thread Luke Dashjr
On Saturday, February 14, 2015 2:23:47 PM Tamas Blummer wrote:
 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.

You can describe 'A' from a group of A, B, C, D, E as the group minus B, C, 
D, E, sure - but I don't see how this is relevant?

UTXO storage is indeed consensus critical, as you say, but it is a lot simpler 
to get right than the rest combined. Thus, the end goal is to have a 
libbitcoinconsensus with the rest, and a (as of yet named) 
libbitcoincompleteconsensus that ties in the canonical UTXO storage. Ideally, 
software should use the latter when it is available, but if there is a strong 
reason to change UTXO storage, one can remain mostly-safe with just the 
former. I'm not sure why this topic is of relevance, though...

Luke

--
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