diff options
author | Jeremy Spilman <jeremy@taplink.co> | 2013-12-19 22:48:53 -0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2013-12-20 08:01:32 +0000 |
commit | f2934e08ba75470862be3300185fb86cc7125ebb (patch) | |
tree | 1d062f0e1565ebeaaa955a51ea5f64a6de29e2a8 | |
parent | 5076e61eecf0eecf54359b208c601d6e1ff684f9 (diff) | |
download | pi-bitcoindev-f2934e08ba75470862be3300185fb86cc7125ebb.tar.gz pi-bitcoindev-f2934e08ba75470862be3300185fb86cc7125ebb.zip |
Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees
-rw-r--r-- | cd/3fccaf010a118127b1f5763137143cf3f2629e | 80 |
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. + + + + |