diff options
| author | odinn <odinn.cyberguerrilla@riseup.net> | 2014-12-12 13:41:34 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-12-12 13:41:57 +0000 |
| commit | 5b387e3a4cb8d6840d45a66d1d82f7154c676f42 (patch) | |
| tree | 8ba3e708221a3f9b6f5b1b3284fe5a951ae12420 | |
| parent | 0e9c898d60ab72664e38d34bb4b39b18e7309003 (diff) | |
| download | pi-bitcoindev-5b387e3a4cb8d6840d45a66d1d82f7154c676f42.tar.gz pi-bitcoindev-5b387e3a4cb8d6840d45a66d1d82f7154c676f42.zip | |
Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
| -rw-r--r-- | bf/45d8cdc8d1d536792974a326e095eedde61eac | 482 |
1 files changed, 482 insertions, 0 deletions
diff --git a/bf/45d8cdc8d1d536792974a326e095eedde61eac b/bf/45d8cdc8d1d536792974a326e095eedde61eac new file mode 100644 index 000000000..65683865f --- /dev/null +++ b/bf/45d8cdc8d1d536792974a326e095eedde61eac @@ -0,0 +1,482 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <odinn.cyberguerrilla@riseup.net>) id 1XzQTh-0007Xi-1y + for bitcoin-development@lists.sourceforge.net; + Fri, 12 Dec 2014 13:41:57 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of riseup.net + designates 198.252.153.129 as permitted sender) + client-ip=198.252.153.129; + envelope-from=odinn.cyberguerrilla@riseup.net; + helo=mx1.riseup.net; +Received: from mx1.riseup.net ([198.252.153.129]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) + (Exim 4.76) id 1XzQTe-0004w2-Mr + for bitcoin-development@lists.sourceforge.net; + Fri, 12 Dec 2014 13:41:52 +0000 +Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) + (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) + (Client CN "*.riseup.net", + Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) + by mx1.riseup.net (Postfix) with ESMTPS id B5C9B40CDA + for <bitcoin-development@lists.sourceforge.net>; + Fri, 12 Dec 2014 13:41:43 +0000 (UTC) +Received: from [127.0.0.1] (localhost [127.0.0.1]) + (Authenticated sender: odinn.cyberguerrilla) + with ESMTPSA id 33D0A42798 +Message-ID: <548AF08E.6080408@riseup.net> +Date: Fri, 12 Dec 2014 13:41:34 +0000 +From: odinn <odinn.cyberguerrilla@riseup.net> +MIME-Version: 1.0 +To: bitcoin-development@lists.sourceforge.net +References: <20141212090551.GA8259@muck> +In-Reply-To: <20141212090551.GA8259@muck> +Content-Type: text/plain; charset=windows-1252 +Content-Transfer-Encoding: 7bit +X-Virus-Scanned: clamav-milter 0.98.4 at mx1 +X-Virus-Status: Clean +X-Spam-Score: -1.6 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, + no trust [198.252.153.129 listed in list.dnswl.org] + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + -0.0 SPF_HELO_PASS SPF: HELO matches SPF record + -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay + domain + -0.0 SPF_PASS SPF: sender matches SPF record + -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 UNPARSEABLE_RELAY Informational: message has unparseable relay + lines +X-Headers-End: 1XzQTe-0004w2-Mr +Subject: Re: [Bitcoin-development] Setting the record straight on + Proof-of-Publication +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, 12 Dec 2014 13:42:10 -0000 + +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA512 + +Peter... It kind of sounds to me that (as fine of a position paper as +this is) on _certain_ points, you're falling prey to the "but it's +inefficient, but it's a scamcoin, but luke-jr told me so" argument... + +I think the Mastercoin devs are doing fine work and I consider the +zerocash devs to have developed (in v2, mint and pour) to have +developed something that will really turn the world on its ear, but +what do I know? Nothing. Nothing at all. + +gmorning + +Peter Todd: +> Introduction ============ +> +> While not a new concept proof-of-publication is receiving a +> significant amount of attention right now both as an idea, with +> regard to the embedded consensus systems that make use of it, and +> in regard to the sidechains model proposed by Blockstream that +> rejects it. Here we give a clear definition of proof-of-publication +> and its weaker predecessor timestamping, describe some usecases for +> it, and finally dispel some of the common myths about it. +> +> +> What is timestamping? ===================== +> +> A cryptographic timestamp proves that message m existed prior to +> some time t. +> +> This is the cryptographic equivalent of mailing yourself a +> patentable idea in a sealed envelope to establish the date at which +> the idea existed on paper. +> +> Traditionally this has been done with one or more trusted third +> parties who attest to the fact that they saw m prior to the time t. +> More recently blockchains have been used for this purpose, +> particularly the Bitcoin blockchain, as block headers include a +> block time which is verified by the consensus algorithm. +> +> +> What is proof-of-publication? ============================= +> +> Proof-of-publication is what solves the double-spend problem. +> +> Cryptographic proof-of-publication actually refers to a few +> closely related proofs, and practical uses of it will generally +> make use of more than one proof. +> +> +> Proof-of-receipt ---------------- +> +> Prove that every member p in of audience P has received message m. +> A real world analogy is a legal notice being published in a major +> newspaper - we can assume any subscriber received the message and +> had a chance to read it. +> +> +> Proof-of-non-publication ------------------------ +> +> Prove that message m has *not* been published. Extending the above +> real world analogy the court can easily determine that a legal +> notice was not published when it should have been by examining +> newspaper archives. (or equally, *because* the notice had not been +> published, some action a litigant had taken was permissable) +> +> +> Proof-of-membership ------------------- +> +> A proof-of-non-publication isn't very useful if you can't prove +> that some member q is in the audience P. In particular, if you are +> to evaluate a proof-of-membership, q is yourself, and you want +> assurance you are in that audience. In the case of our newspaper +> analogy because we know what today's date is, and we trust the +> newspaper never to publish two different editions with the same +> date we can be certain we have searched all possible issues where +> the legal notice may have been published. +> +> +> Real-world proof-of-publication: The Torrens Title System +> --------------------------------------------------------- +> +> Land titles are a real-world example, dating back centuries, with +> remarkable simularities to the Bitcoin blockchain. Prior to the +> torrens system land was transferred between owners through a chain +> of valid title deeds going back to some "genesis" event +> establishing rightful ownership independently of prior history. As +> with the blockchain the title deed system has two main problems: +> establishing that each title deed in the chain is valid in +> isolation, and establishing that no other valid title deeds exist. +> While the analogy isn't exact - establishing the validity of title +> deeds isn't as crisp a process as simple checking a cryptographic +> signature - these two basic problems are closely related to the +> actions of checking a transaction's signatures in isolation, and +> ensuring it hasn't been double-spent. +> +> To solve these problems the Torrens title system was developed, +> first in Australia and later Canada, to establish a singular +> central registry of deeds, or property transfers. Simplifying a bit +> we can say inclusion - publication - in the official registery is a +> necessary pre-condition to a given property transfer being valid. +> Multiple competing transfers are made obvious, and the true valid +> transfer can be determined by whichever transfer happened first. +> +> Similarly in places where the Torrens title system has not been +> adopted, almost always a small number of title insurance providers +> have taken on the same role. The title insurance provider maintains +> a database of all known title deeds, and in practice if a given +> title deed isn't published in the database it's not considered +> valid. +> +> +> Common myths ============ +> +> Proof-of-publication is the same as timestamping +> ------------------------------------------------ +> +> No. Timestamping is a significantly weaker primitive than +> proof-of-publication. This myth seems to persist because +> unfortunately many members of the Bitcoin development and theory +> community - and even members of the Blockstream project - have +> frequently used the term "timestamping" for applications that need +> proof-of-publication. +> +> +> Publication means publishing meaningful data to the whole world +> --------------------------------------------------------------- +> +> No. The data to be published can often be an otherwise meaningless +> nonce, indistinguishable from any other random value. (e.g. an ECC +> pubkey) +> +> For example colored coins can be implemented by committing the hash +> of the map of colored inputs to outputs inside a transaction. These +> maps can be passed from payee to payor to prove that a given output +> is colored with a set of recursive proofs, as is done in the +> author's Smartcolors library. The commitment itself can be a simple +> hash, or even a pay-to-contract style derived pubkey. +> +> A second example is Zerocash, which depends on global consensus of +> a set of revealed serial numbers. As this set can include +> "false-positives" - false revealed serial numbers that do not +> actually correspond to a real Zerocash transaction - the blockchain +> itself can be that set. The Zerocash transactions themselves - and +> associated proofs - can then be passed around via a p2p network +> separate from the blockchain itself. Each Zerocash Pour proof then +> simply needs to specify what set of priorly evaluated proofs makes +> up its particular commitment merkle tree and the proofs are then +> evaluated against that proof-specific tree. (in practice likely +> some kind of DAG-like structure) (note that there is a sybil attack +> risk here: a sybil attack reduces your k-anonymity set by the +> number of transactions you were prevented from seeing; a weaker +> proof-of-publication mechanism may be appropriate to prevent that +> sybil attack). +> +> The published data may also not be meaningful because it is +> encrypted. Only a small community may need to come to consensus +> about it; everyone else can ignore it. For instance +> proof-of-publication for decentralized asset exchange is an +> application where you need publication to be timely, however the +> audience may still be small. That audience can share an encryption +> key. +> +> +> Proof-of-publication is always easy to censor +> --------------------------------------------- +> +> No, with some precautions. This myth is closely related to the +> above idea that the data must be globally meaningful to be useful. +> The colored coin and Zerocash examples above are cases where +> censoring the publication is obviously impossible as it can be made +> prior to giving anyone at all sufficient info to determine if the +> publicaiton has been made; the data itself is just nonces. +> +> In the case of encrypted data the encryption key can also often be +> revealed well after the publication has been made. For instance in +> a Certificate Transparency scheme the certificate authority (CA) +> may use proof-of-publication to prove that a certificate was in a +> set of certificates. If that set of certificates is hashed into a +> merkelized binary prefix tree indexed by domain name the correct +> certificate for a given domain name - or lack thereof - is easily +> proven. Changes to that set can be published on the blockchain by +> publishing successive prefix tree commitments. +> +> If these commitments are encrypted, each commitment C_i can also +> commit to the encryption key to be used for C_{i+1}. That key need +> not be revealed until the commitment is published; validitity is +> assured as every client knows that only one C_{i+1} is possible, so +> any malfeasance is guaranteed to be revealed when C_{i+2} is +> published. +> +> Secondly the published data can be timelock encrypted with +> timelocks that take more than the average block interval to +> decrypt. This puts would-be censoring miners into a position of +> either delaying all transactions, or accepting that they will end +> up mining publication proofs. The only way to circumvent this is +> highly restrictive whitelisting. +> +> +> Proof-of-publication is easier to censor than (merge)-mined +> sidechains +> ---------------------------------------------------------------------- +> +> False under all circumstances. Even if the publications use no +> anti-censorship techniques to succesfully censor a +> proof-of-publication system at least 51% of the total hashing power +> must decide to censor it, and they must do so by attacking the +> other 49% of hashing power - specifically rejecting their blocks. +> This is true no matter how "niche" the proof-of-publication system +> is - whether it is used by two people or two million people it has +> the same security. +> +> On the other hand a (merge)-mined sidechain with x% of the total +> hashing power supporting it can be attacked at by anyone with >x% +> hashing power. In the case of a merge-mined sidechain this cost +> will often be near zero - only by providing miners with a +> significant and ongoing reward can the marginal cost be made high. +> In the case of sidechains with niche audiences this is particularly +> true - sidechain advocates have often advocated that sidechains be +> initially protected by centralized checkpoints until they become +> popular enough to begin to be secure. +> +> Secondly sidechains can't make use of anti-censorship techniques +> the way proof-of-publication systems can: they inherently must be +> public for miners to be able to mine them in a decentralized +> fashion. Of course, users of them may use anti-censorship +> techniques, but that leads to a simple security-vs-cost tradeoff +> between using the Bitcoin blockchain and a sidechain. (note the +> simularity to the author's treechains proposal!) +> +> +> Proof-of-publication can be made expensive +> ------------------------------------------ +> +> True, in some cases! By tightly constraining the Bitcoin scripting +> system the available bytes for stenographic embedment can be +> reduced. For instance P2SH^2 requires an brute force exponentially +> increasing amount of hashes-per-byte-per-pushdata. However this is +> still ineffective against publishing hashes, and to fully implement +> it - scriptSigs included - would require highly invasive changes to +> the entire scripting system that would greatly limit its value. +> +> +> Proof-of-publication can be outsourced to untrusted third-parties +> ----------------------------------------------------------------- +> +> Timestamping yes, but proof-of-publication no. +> +> We're talking about systems that attempt to publish multiple pieces +> of data from multiple parties with a single hash in the Bitcoin +> blockchain, such as Factom. Essentially this works by having a +> "child" blockchain, and the hash of that child blockchain is +> published in the master Bitcoin blockchain. To prove publicaiton +> you prove that your message is in that child chain, and the child +> chain is itself published in the Bitcoin blockchain. Proving +> membership is possible for yourself by determining if you have the +> contents corresponding to the most recent child-chain hash. +> +> The problem is proving non-publication. The set of all *potential* +> child-chain hashes must be possible to obtain by scanning the +> Bitcoin blockchain. As a hash is meaningless by itself, these +> hashes must be signed. That introduces a trusted third-party who +> can also sign an invalid hash that does not correspond to a block +> and publish it in the blockchain. This in turn makes it impossible +> for anyone using the child blockchain to prove non-publication - +> they can't prove they did not publish a message because the content +> of *all* child blockchains is now unknown. +> +> In short, Factom and systems like it rely on trusted third parties +> who can put you in a position where you can't prove you did not +> commit fraud. +> +> +> Proof-of-publication "bloats" the blockchain +> -------------------------------------------- +> +> Depends on your perspective. +> +> Systems that do not make use of the UTXO are no different +> technically than any other transaction: they pay fees to publish +> messages to the Bitcoin blockchain with no amortized increase in +> the UTXO set. Some systems do grow the UTXO set - a potential +> scaling problem as currently that all full nodes must have the +> entire UTXO set - although there are a number of existing +> mechanisms and proposals to mitigate this issue such as the +> (crippled) OP_RETURN scriptPubKey format, the dust rule, the +> authors TXO commitments, UTXO expiry etc. +> +> From an economic point of view proof-of-publication systems compete +> with other uses of the blockchain as they pay fees; supply of +> blockchain space is fixed so the increased demand must result in a +> higher per-transaction price in fees. On the other hand this is +> true of *all* uses of the blockchain, which collectively share the +> limited transaction capacity. For instance Satoshidice and similar +> sites have been widely condemned for doing conventional +> transactions on Bitcoin when they could have potentially used +> off-chain transactions. +> +> It's unknown what the effect on the Bitcoin price will actually be. +> Some proof-of-publication uses have nothing to do with money at all +> - e.g. certificate transparency. Others are only indirectly +> related, such as securing financial audit logs such as +> merkle-sum-trees of total Bitcoins held by exchanges. Others in +> effect add new features to Bitcoin, such as how colored coins +> allows the trade of assets on the blockchain, or how Zerocash makes +> Bitcoin transactions anonymous. The sum total of all these effects +> on the Bitcoin price is difficult to predict. +> +> The authors belief is that even if proof-of-publication is a +> net-negative to Bitcoin as it is significantly more secure than +> the alternatives and can't be effectively censored people will use +> it regardless of effects to discourage them through social +> pressure. Thus Bitcoin must make technical improvements to +> scalability that negate these potentially harmful effects. +> +> +> Proof-of-publication systems are inefficient +> -------------------------------------------- +> +> If you're talking about inefficient from the perspective of a +> full-node that does full validation, they are no different than +> (merge)-mined sidechain and altcoin alternatives. If you're talking +> about efficiency from the perspective of a SPV client, then yes, +> proof-of-publication systems will often require more resources than +> mining-based alternatives. +> +> However it must be remembered that the cost of mining is the +> introduction of a trusted third party - miners. Of course, mined +> proof-of-publication has miners already, but trusting those miners +> to determine the meaning of that data places significantly more +> trust in them than mearly trusting them to create consensus on the +> order in which data is published. +> +> Many usecases involve trusted third-parties anyway - the role of +> proof-of-publication is to hold those third-parties to account and +> keep them honest. For these use-cases - certificate transparency, +> audit logs, financial assets - mined alternatives simply add new +> trusted third parties and points of failure rather than remove +> them. +> +> Of course, global consensus is inefficient - Bitcoin itself is +> inefficient. But this is a fundemental problem to Bitcoin's +> architecture that applies to all uses of it, a problem that should +> be solved in general. +> +> +> Proof-of-publication needs "scamcoins" like Mastercoin and +> Counterparty +> ----------------------------------------------------------------------- +> +> First of all, whether or not a limited-supply token is a "scam" is +> not a technical question. However some types of embedded consensus +> systems, a specific use-case for proof-of-publication, do require +> limited-supply tokens within the system for technical reasons, for +> instance to support bid orders functionality in decentralized +> marketplaces. +> +> Secondly using a limited-supply token in a proof-of-publicaton +> system is what lets you have secure client side validation rather +> than the alternative of 2-way-pegging that requires users to trust +> miners not to steal the pegged funds. Tokens also do not need to +> be, economically speaking, assets that can appreciate in value +> relative to Bitcoin; one-way-pegs where Bitcoins can always be +> turned into the token in conjunction with decentralized exchange to +> buy and sell tokens for Bitcoins ensure the token value will always +> closely approximate the Bitcoin value as long as the protocol +> itself is considered valuable. +> +> Finally only a subset of proof-of-publication use-cases involve +> tokens at all - many like colored coins transact directly to and +> from Bitcoin, while other use-cases don't even involve finance at +> all. +> +> +> +> ------------------------------------------------------------------------------ +> +> +Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server +> from Actuate! Instantly Supercharge Your Business Reports and +> Dashboards with Interactivity, Sharing, Native Excel Exports, App +> Integration & more Get technology previously reserved for +> billion-dollar corporations, FREE +> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk +> +> +> +> +> _______________________________________________ Bitcoin-development +> mailing list Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> + +- -- +http://abis.io ~ +"a protocol concept to enable decentralization +and expansion of a giving economy, and a new social good" +https://keybase.io/odinn +-----BEGIN PGP SIGNATURE----- + +iQEcBAEBCgAGBQJUivCNAAoJEGxwq/inSG8ChVUH/26zj2pj7AF+oa2RDkPZN980 +qFTY7x2s9w97bEuCiFfFpYjIP26mY4+snuoTWBa8yCp7gLVVsk9JKkN0dmXIboXf +ocoJY9s/wT7QLqJMRRwWb/8XPKwjXB10PNawCRoUk++8E0Y+W6mxiH5Gs1UnYKwI +2DHHh/hTh35mR5burwdLGEMLaVtK4BFLJTZwW+4xlWESsoWeQnxEuty799HldOaN ++wms8dvtZlzJElLUPjBGBZT6DRTaPsvqSvQ0CnHI84LYwuUObMcV89mkBcfTHlMt +MczwaO7CCc/jmoOoQKDyIVuW1eJeXggln+LOS34qwH8rCgjdOZeT3y4PgUTZ+AM= +=Sm96 +-----END PGP SIGNATURE----- + + |