diff options
author | Pieter Wuille <pieter.wuille@gmail.com> | 2013-03-13 19:38:25 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2013-03-13 18:38:32 +0000 |
commit | 19ae0c39c678622811533b1c4bd26ca20d270906 (patch) | |
tree | 1fc1a193cd6e3206f8e2852bcc5f6e8fbacd9384 | |
parent | bbbd3b7290c0a39d1c93aa670e9e6b02c517176b (diff) | |
download | pi-bitcoindev-19ae0c39c678622811533b1c4bd26ca20d270906.tar.gz pi-bitcoindev-19ae0c39c678622811533b1c4bd26ca20d270906.zip |
Re: [Bitcoin-development] 0.8.1 ideas
-rw-r--r-- | cb/4f7b61af569d3ac266a641b8826b07c0a1b361 | 81 |
1 files changed, 81 insertions, 0 deletions
diff --git a/cb/4f7b61af569d3ac266a641b8826b07c0a1b361 b/cb/4f7b61af569d3ac266a641b8826b07c0a1b361 new file mode 100644 index 000000000..8bb72d098 --- /dev/null +++ b/cb/4f7b61af569d3ac266a641b8826b07c0a1b361 @@ -0,0 +1,81 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pw@vps7135.xlshosting.net>) id 1UFqZM-0000oV-OE + for bitcoin-development@lists.sourceforge.net; + Wed, 13 Mar 2013 18:38:32 +0000 +X-ACL-Warn: +Received: from vps7135.xlshosting.net ([178.18.90.41]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1UFqZL-0005hU-UO for bitcoin-development@lists.sourceforge.net; + Wed, 13 Mar 2013 18:38:32 +0000 +Received: by vps7135.xlshosting.net (Postfix, from userid 1000) + id A3CD133C896; Wed, 13 Mar 2013 19:38:25 +0100 (CET) +Date: Wed, 13 Mar 2013 19:38:25 +0100 +From: Pieter Wuille <pieter.wuille@gmail.com> +To: Mark Friedenbach <mark@monetize.io> +Message-ID: <20130313183824.GB7921@vps7135.xlshosting.net> +References: <201303131256.30144.luke@dashjr.org> + <CACh7GpE09hqCPL6rtdC6EZzohM5QHb+0SdFoD8MzPSqf7=6hOA@mail.gmail.com> + <20130313175825.GA21242@vps7135.xlshosting.net> + <CACh7GpG_4uLUUiwJyZO0FtV2_UHMN-HnJsZZXWpC2jQvzb-jMQ@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <CACh7GpG_4uLUUiwJyZO0FtV2_UHMN-HnJsZZXWpC2jQvzb-jMQ@mail.gmail.com> +X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc +User-Agent: Mutt/1.5.21 (2010-09-15) +X-Spam-Score: -1.2 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (pieter.wuille[at]gmail.com) + 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is + CUSTOM_MED + -2.4 RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, + and not from a mailing list +X-Headers-End: 1UFqZL-0005hU-UO +Cc: "bitcoin-development@lists.sourceforge.net" + <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] 0.8.1 ideas +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Wed, 13 Mar 2013 18:38:32 -0000 + +On Wed, Mar 13, 2013 at 11:27:13AM -0700, Mark Friedenbach wrote: +> I know there's people here who will jump in saying that the bitcoin +> protocol is the behavior of the Satoshi client, period. But which Satoshi +> client? 0.7 or 0.8? + +The protocol is whatever the network enforces - and that is some mix of versions of the +reference client right now, but doesn't need to remain that way. + +I would very much like to have a text book of rules that is authorative, and every client +that follows it would be correct. Unfortunately, that is not how a consensus system works. +All (full) clients validate all rules, and all must independently come to the same +solution. Consensus is of utmost importance, more than some theoretical "correctness". +If we'd have a specification document, and it was discovered that a lot of +nodes on the network were doing something different than the document, those nodes would +be buggy, but it would be the specification that is wrong. + +That is what happened: 0.7 and before had a bug, but 0.8 was wrong for not following the +rules of the network (which I hate to say, as I'm responsible for many changes in 0.8). + +As said in another thread, the problem in the old versions needs fixing (this would even +be the case if no 0.8 existed at all, and no fork risk existed at all). But let's please +do it in a way we can all agree about, in a controlled fashion. + +-- +Pieter + + |