[Bitcoin-development] Near-zero fee transactions with hub-and-spoke micropayments
From the So-Obvious-No-one-Has-Bothered-to-Write-It-Down-Department: tl;dr: Micropayment channels can be extended to arbitrary numbers of parties using a nearly completley untrusted hub, greatly decreasing transaction fees and greatly increasing the maximum number of financial transactions per second that Bitcoin can support. So a micropayment channel enables a payor to incrementally pay a payee by first locking a deposit of Bitcoins in a scriptPubKey of the following form: IF CHECKLOCKTIMEVERIFY OP_DROP ELSE CHECKSIGVERIFY ENDIF CHECKSIGVERIFY (obviously many other forms are possible, e.g. multisig) Once the funds are confirmed, creating txout1, the payor creates transactions spending txout1 sending some fraction of the txout value to the payee and gives that half-signed transaction to the payee. Each time the payor wants to send more money to the payee they sign a new half-signed transaction double-spending the previous one. When the payee is satisfied they can close the channel by signing the most recent, highest value, tx with their key, thus making it valid. If the payee vanishes the payor can get all the funds back once the timeout is reached using just their key. Since confirmation is controlled by the payee once the initial deposit confirms subsequent increases in funds sent happen instantly in that the payor can not double-spend the input until the timeout is reached. (there's another formulation from Jeremy Spilman that can be almost implemented right now using a signed refund transaction, however it is vulnerable to transaction mutability) Hub-and-Spoke Payments == Using a nearly completely untrusted hub we can allow any number of parties to mutually send and receive Bitcoins instantly with near-zero transaction fees. Each participant creates one or two micropayment channels with the hub; for Alice to send Bob some funds Alice first sends the funds to the hub in some small increment, the hub sends the funds to Bob, and finally the hub gives proof of that send to Alice. The incremental amount of Bitcoins sent can be set arbitrarily low, limited only by bandwidth and CPU time, and Bob does not necessarily need to actually be online. The worst that the hub can do is leave user's funds locked until the timeout expires. Multiple Hubs = Of course, hubs can in turn send to each other, again in a trustless manner; multiple hops could act as a onion-style privacy scheme. The micropayments could also use an additional chaum token layer for privacy, although note that the k-anonymity set involves a trade-off between privacy and total # of Bitcoins that could be stolen by the hub. Of course, in general the micropayment hub breaks the linkage between payor and payee, with respect to the data available from the blockchain. Capital Requirements A business disadvantage with a hub-and-spoke system is that it ties up capital, creating a tradeoff between fees saved and Bitcoins tied up. How exactly to handle this is a business decision - for instance opening the micropayment channel could involve a small initial payment to account fo rthe time-value-of-money. Embedded consensus/Colored coins Note how many embedded consensus schemes like colored coins are compatible with micropayment channels. (though have fun figuring out who deserves the dividends!) -- 'peter'[:-1]@petertodd.org 12367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622 signature.asc Description: Digital signature -- 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
Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
> I think what Gareth was getting at was that with client-side validation > there can be no concept of a soft-fork. And how certain are you that the > consensus rules will never change? > Yes, it is true that you can't do a soft-fork, but you can do a hard-fork. Using scheduled updates: client simply stops working at a certain block, and user is required to download an update. In Bitcoin we can operate with some assurance that hard-forks will almost > never happen, exactly because extensions are more likely to occur via > soft-fork mechanisms. In such a case, old non-updated clients will still > generate a correct view of the ledger state. But this is not so with client > side validation! > You assume that an ability to operate with zero maintenance is very important, but is this a case? There was a plenty of critical bugs in bitcoind, and in many cases people were strongly encouraged to upgrade to a new version. So, you urge people to keep their clients up-to-date, but at the same time claim that keeping very old versions is critically important. How does this make sense? Is this an exercise at double-think? An alternative to this is to make updates mandatory. You will no longer need to maintain compatibility with version 0.1 (which is impossible) and you can also evolve consensus rules over time. It looks like people make a cargo cult out of Bitcoin's emergent properties. -- 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
Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
> > "Secure" and "client side validation" don't really belong in the same > sentence, do they? > Well, client-side validation is mathematically secure, while SPV is economically secure. I.e. it is secure if you make several assumptions about economics of the whole thing. In my opinion the former is transfinitely more secure than the later. But it's more of a philosophical question, sure. The good thing about PoW-based consensus is that it is robust against version inconsistencies and various accidents of this nature up to a certain degree. But you hardly can depend on that: You know, The Great Fork of 2013 was resolved through human intervention, Bitcoin nodes were not smart enough to detect that something is going awry on their own. Naive proof-of-publication is very fragile in that respect, but you can easily bring back robustness. -- 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
Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/12/2014 01:41 PM, odinn wrote: > I think the Mastercoin devs are doing fine work I wonder if all the Mastercoin devs would agree with that statement. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUivkLAAoJEMP3uyY4RQ21r5cIANvabja0i5j79a6KSkKOgEyR LhBz4mugzTc8Zej2NBeyEtv0pzO4fs5wvQo4N/1BW7aHXuFJsgJpGlV8thkuFhek UhoPC23i7u3jCPQ30PintqvCBCimse+PJa60KE2QL2DZn7WgRGKrEuo41AROxeit vfVMcFULc6bB9hxIEBpcU4RuwKJHVgzSHMkO75/uHHtPLJ9TbCfqcxT146cZvSjc Tc62ukuX1xBj5PhQM8GaUGzkQcfcZ+7d3DD1X22Gk1U6w+zat52dapy/qYgn9oA5 ubk/p/7Kywd8D44rPsr/pbdlDZxG0w77yRJIMboXhFMV7rY3sMRHHQmAUz+I8FY= =R4pR -END PGP SIGNATURE- 0x38450DB5.asc Description: application/pgp-keys -- 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
Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
-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 > >
Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
On 12/12/14 20:05, Peter Todd wrote: > 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. "Secure" and "client side validation" don't really belong in the same sentence, do they? If I am to accept a transaction with any assurance of security at all, the important question to ask is not: "does my client consider this valid?" but: "does the rest of the world consider this valid?" Validated data in the blockchain is far more useful for this purpose than unvalidated data with a mere proof of publication in the blockchain, precisely because it records what /everybody else/ considers valid history (and very likely will continue to consider valid history in future.) Pegged sidechains have their challenges, but at least they provide distributed consensus on transaction history. Proof-of-publication systems like Counterparty and Mastercoin require me to trust, with zero evidence, that everybody else's client has the exact same interpretation of transaction history as mine, and will continue to have for the indefinite future. How is that not a horribly broken security model? I'd use a sidechain - with reasonable parameters that disincentivise peg theft as much as practical - over that any day. signature.asc Description: OpenPGP digital signature -- 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
[Bitcoin-development] Setting the record straight on Proof-of-Publication
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
