public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil•org>
To: Monarch <monarch@cock•li>,
	bitcoin-dev@lists•linuxfoundation.org,
	 libbitcoin@lists•dyne.org
Subject: Re: [bitcoin-dev] Your Gmaxwell exchange
Date: Tue, 01 Sep 2015 11:37:18 -0700	[thread overview]
Message-ID: <55E5F05E.9060409@voskuil.org> (raw)
In-Reply-To: <67820b46cdcb549aac36b9496b19b6b0@cock.li>

[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

On 09/01/2015 09:51 AM, Monarch via bitcoin-dev wrote:
> On 2015-09-01 15:59, Dave Collins via bitcoin-dev wrote:
>> I'd be interested to know about these supposed btcd mainnet forks that
>> have occurred due to a consensus failure since it came out of alpha.
>> I'll go ahead and save you some research time - there hasn't been one.
>> I'm not claiming there will never be one as that would be just as
>> foolish as claiming Bitcoin Core won't have any more either.
>
> For the purposes of the conversation this was only brought up to re-
> enforce my claim that this is outrageously difficult software
> development, irrespective of the quality of the code being produced in
> alternate implementations.  Sorry if that came across as an attack
> against your software in particular, it wasn't intended.

Whether intended or otherwise this is an attack on the idea of
decentralized bitcoin development. The option to fork or roll your own
is open source, not decentralization. Decentralization requires
*actually doing so*. One step down that path, even for a fork, is a
major commitment.

Common consensus check code is now available in several bitcoin
implementations. The claim that this is outrageously difficult is
misleading. It's just engineering work that needs to get done if Bitcoin
is to survive.

>> On the other hand, Bitcoin Core has had actual forks on mainnet during
>> the same period.  I'm not casting stones at Bitcoin Core here, because
>> as I've said many times, none of us are perfect.  No matter how careful
>> everyone is, it is bound to happen from time to time.
> 
> The point I was trying to make is that this is simply a hard
> development situation to be working in, we don't know what behavior is
> inferred by the use of CPP and even more so OpenSSL (as the DER
> encoding consensus failure made abundantly clear).  There's almost
> certainly more problems lying around given how generally dusty a lot
> of the transaction environment is, it's very easy to get off the
> beaten track with Bitcoin script.

These are issues that affect the satoshi client as much as other
implementations, and therefore don't support your premise.

e


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2015-09-01 18:37 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-31 20:06 Monarch
2015-08-31 20:27 ` Justus Ranvier
2015-08-31 20:48   ` Monarch
2015-08-31 21:24     ` Allen Piscitello
2015-08-31 21:42       ` Monarch
2015-08-31 21:54         ` Justus Ranvier
2015-08-31 22:53           ` Monarch
2015-08-31 23:24             ` Justus Ranvier
2015-09-01  0:02             ` Milly Bitcoin
2015-09-01  9:25           ` Jorge Timón
2015-08-31 23:32       ` Peter R
2015-08-31 23:47         ` s7r
2015-09-01  2:16           ` [bitcoin-dev] Let's kill Bitcoin Core and allow the green shoots of a garden of new implementations to grow from its fertile ashes Peter R
2015-09-01  2:25             ` Gregory Maxwell
2015-09-01  8:42             ` Adam Back
2015-09-01 10:16               ` Chris D'Costa
2015-09-01 11:20                 ` Monarch
2015-09-01 12:24             ` Wladimir
2015-09-01 22:06             ` s7r
2015-09-01 11:44           ` [bitcoin-dev] Your Gmaxwell exchange Monarch
2015-09-01 11:11         ` Monarch
2015-09-01 15:59           ` Dave Collins
2015-09-01 16:51             ` Monarch
2015-09-01 18:37               ` Eric Voskuil [this message]
2015-09-01 20:08                 ` Monarch
     [not found] <CAEgR2PFB3h_8fr=d8HegRSD0XdooimhFKtLR4vKr2QXv+EwBfQ@mail.gmail.com>
     [not found] ` <AD284610-4F40-445C-A074-CC94EDFFCBA8@gmx.com>
2015-08-30  3:25   ` Gregory Maxwell
2015-08-30  4:13     ` Peter R
2015-08-30  4:57       ` Gregory Maxwell
2015-08-30  6:38         ` Adam Ritter
2015-08-31 18:55           ` Justus Ranvier
2015-08-31 19:11             ` Mike Hearn
2015-09-01 20:29             ` Wladimir J. van der Laan
2015-09-02 18:51               ` Justus Ranvier
2015-09-01  2:30           ` Oliver Petruzel
2015-08-30  7:41         ` Peter R

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55E5F05E.9060409@voskuil.org \
    --to=eric@voskuil$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=libbitcoin@lists$(echo .)dyne.org \
    --cc=monarch@cock$(echo .)li \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox