summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPieter Wuille <pieter.wuille@gmail.com>2013-03-13 19:38:25 +0100
committerbitcoindev <bitcoindev@gnusha.org>2013-03-13 18:38:32 +0000
commit19ae0c39c678622811533b1c4bd26ca20d270906 (patch)
tree1fc1a193cd6e3206f8e2852bcc5f6e8fbacd9384
parentbbbd3b7290c0a39d1c93aa670e9e6b02c517176b (diff)
downloadpi-bitcoindev-19ae0c39c678622811533b1c4bd26ca20d270906.tar.gz
pi-bitcoindev-19ae0c39c678622811533b1c4bd26ca20d270906.zip
Re: [Bitcoin-development] 0.8.1 ideas
-rw-r--r--cb/4f7b61af569d3ac266a641b8826b07c0a1b36181
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
+
+