summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJeremy Spilman <jeremy@taplink.co>2013-12-19 22:48:53 -0800
committerbitcoindev <bitcoindev@gnusha.org>2013-12-20 08:01:32 +0000
commitf2934e08ba75470862be3300185fb86cc7125ebb (patch)
tree1d062f0e1565ebeaaa955a51ea5f64a6de29e2a8
parent5076e61eecf0eecf54359b208c601d6e1ff684f9 (diff)
downloadpi-bitcoindev-f2934e08ba75470862be3300185fb86cc7125ebb.tar.gz
pi-bitcoindev-f2934e08ba75470862be3300185fb86cc7125ebb.zip
Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees
-rw-r--r--cd/3fccaf010a118127b1f5763137143cf3f2629e80
1 files changed, 80 insertions, 0 deletions
diff --git a/cd/3fccaf010a118127b1f5763137143cf3f2629e b/cd/3fccaf010a118127b1f5763137143cf3f2629e
new file mode 100644
index 000000000..9517b8218
--- /dev/null
+++ b/cd/3fccaf010a118127b1f5763137143cf3f2629e
@@ -0,0 +1,80 @@
+Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
+ helo=mx.sourceforge.net)
+ by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
+ (envelope-from <jeremy@taplink.co>) id 1Vtv1Y-0005rG-Pf
+ for bitcoin-development@lists.sourceforge.net;
+ Fri, 20 Dec 2013 08:01:32 +0000
+Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of taplink.co
+ designates 50.117.27.232 as permitted sender)
+ client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
+ helo=mail.taplink.co;
+Received: from mail.taplink.co ([50.117.27.232])
+ by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76)
+ id 1Vtv1W-0001Z8-VQ for bitcoin-development@lists.sourceforge.net;
+ Fri, 20 Dec 2013 08:01:32 +0000
+Received: from laptop-air.hsd1.ca.comcast.net ([192.168.168.135]) by
+ mail.taplink.co ; Thu, 19 Dec 2013 22:49:02 -0800
+Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
+To: "Bitcoin Dev" <bitcoin-development@lists.sourceforge.net>
+References: <52B3A1C8.5000005@monetize.io>
+Date: Thu, 19 Dec 2013 22:48:53 -0800
+MIME-Version: 1.0
+Content-Transfer-Encoding: 7bit
+From: "Jeremy Spilman" <jeremy@taplink.co>
+Organization: TapLink
+Message-ID: <op.w8do7rg9yldrnw@laptop-air.hsd1.ca.comcast.net>
+In-Reply-To: <52B3A1C8.5000005@monetize.io>
+User-Agent: Opera Mail/1.0 (Win32)
+oclient: 192.168.168.135#jeremy@taplink.co#465
+X-Spam-Score: -2.1 (--)
+X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
+ See http://spamassassin.org/tag/ for more details.
+ -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
+ sender-domain
+ -0.0 SPF_PASS SPF: sender matches SPF record
+ -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
+ domain
+ -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
+ author's domain
+ 0.1 DKIM_SIGNED Message has a DKIM or DK signature,
+ not necessarily valid
+ -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
+ 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
+ See
+ http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
+ for more information. [URIs: taplink.co]
+X-Headers-End: 1Vtv1W-0001Z8-VQ
+Subject: Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees
+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: Fri, 20 Dec 2013 08:01:33 -0000
+
+Wow there's a lot here to think about. I'm pretty sure I haven't grasped
+the full implications yet.
+
+I see it proposes to also introduce additional BIPs describing the use of
+the data stucture for stateless validation & mining, the UBC address index
+for "SPV+" operating modes, document timestamping and merged mining.
+
+Can the BIP stand alone as a BIP without some specific changes to the
+protocol or end-user accessible features defined within it? It seems like
+an extremely useful data stucture, but as I understand it the purpose of
+BIPS is defining interoperability points, not implementation details?
+
+Unless the tree itself is becoming part of the protocol, seems like its
+spec, test vectors, and reference implementation can live elsewhere, but I
+would love to read about BIPS which use this tree to accomplish some
+amazing scalability or security benefits.
+
+
+
+