Title: Proposal: Bitcoin Preauths & IOUs Post by: dibbs on August 19, 2011, 05:13:18 AM Update: It appears this idea already exists under another name (https://bitcointalk.org/index.php?topic=25786.0). Thanks to etotheipi for pointing it out.
I'm proposing an idea to help strengthen three of Bitcoin's weak spots:
These problems can all be at least partially solved with the same extension to Bitcoin. Basically, the solution would allow two parties, a customer and a merchant, each represented by a Bitcoin address, to sign an agreement (call it a I haven't rigorously analyzed the technical or cryptographic requirements of this idea, but I feel like it's pretty straightforward, anyway. The preauths and IOUs are signed with the same private keys used to sign any other transaction. Redeeming the same IOU multiple times is prevented by including timestamps. Because of these things, the whole preauth/IOU scheme doesn't require trust or third parties. The customer doesn't need to prepay for service (which would require trusting the merchant), and the merchant doesn't have to wait 'til the end of a billing cycle to collect payment (which would require trusting the customer to pay their bill). Example: I believe this solution, if truly feasible, opens up a new, niche market for Bitcoin. Imagine ad companies which allow you to make automatic nanopayments (say, 3/40th of a cent per visit or pageview) with certain, quality websites you've whitelisted, instead of viewing ads. On sites you've never visited before, a Bitcoin browser plugin might show a notification telling you that the site uses XYZ ad company (with whom you've already signed a preauth for the next month), and asking whether you want to whitelist the site for per-visit Bitcoin payments through XYZ. Alternatively, if the site was big enough, and popular enough, you might sign a new preauth directly with it. In this way, Bitcoin gets into the hands of the internet's content producers (who better to promote Bitcoin?), and becomes desireable to anyone willing to pay fractions of a penny never to see ads again, while still remaining anonymous. Thoughts? Have better solutions already been proposed? Would the above example be worth it? Are there other niche markets that might open up because of this? Title: Re: Proposal: Bitcoin Tabs & IOUs Post by: dibbs on October 09, 2011, 02:42:46 PM FYI - after further discussion on the SC forums, someone mentioned a better name might be "preauths" rather than "tabs," since you're basically preauthorizing the redemption of any IOUs, so the person redeeming them knows instantly that they're good.
Title: Re: Proposal: Bitcoin Preauths & IOUs Post by: error on October 09, 2011, 03:46:25 PM
You seem to have mistyped seconds. And I don't understand why 10 seconds is too high; a debit card swipe takes that long. Title: Re: Proposal: Bitcoin Preauths & IOUs Post by: etotheipi on October 09, 2011, 04:42:27 PM I believe that what you describe is nearly identical to what is proposed by hashcoin in this thread (https://bitcointalk.org/index.php?topic=25786.0) using nLockTime.
Two parties establish two transactions, one from A to B for X BTC and one for the same amount from B to A using the outputs of the first transaction. The second transaction has a lock time in the future. Both tx are broadcast. If no one does anything, the locktime reaches maturity and it looks like a round-trip of X BTC between the two parties with no balances having changed. But, when A wants to give B money, he provides him a signed Tx2 replacement that is for X minus payment amount. Party B can, at any time, broadcast this replacement to reduce the change paid back to A. Any time A wants to give more money to B, they just send another signed Tx2 with even less change back to themself. When locktime is approaching, party B broadcasts the replacement Tx, and the network sees A transfer X BTC to B, and B transfer X-minus-balance to A. Since the original non-locked transaction entered the blockchain days before, all these transactions are guaranteed to be final and confirmed instantly, because the original two transactions were already confirmed by the network, just the amounts are changing. P.S. -- nLockTime is currently disabled in the network right now, but there is a push to have it implemented, partly based on this proposal by hashcoin -- it "solves" all the problems you mentioned in your original post -- replacement Tx's are transferred off-network, accepted instantly, and don't pollute the blockchain Title: Re: Proposal: Bitcoin Preauths & IOUs Post by: dibbs on October 09, 2011, 05:14:09 PM Quote You seem to have mistyped seconds. And I don't understand why 10 seconds is too high; a debit card swipe takes that long. No; I'm pretty sure it still takes at least a few minutes for verification. I'm not talking about the time it takes for it to show up. But also, even 10 seconds is much too long for the nanotransactions I mentioned. Basically, a website using an IOU-based subscription service needs the transaction to be confirmed before it even sends the response to a user's browser, since it needs to decide whether and how to display various kinds of information, including ads.Title: Re: Proposal: Bitcoin Preauths & IOUs Post by: dibbs on October 09, 2011, 05:17:40 PM I believe that what you describe is nearly identical to what is proposed by hashcoin in this thread (https://bitcointalk.org/index.php?topic=25786.0) using nLockTime. Two parties establish two transactions, one from A to B for X BTC and one for the same amount from B to A using the outputs of the first transaction. The second transaction has a lock time in the future. Both tx are broadcast. If no one does anything, the locktime reaches maturity and it looks like a round-trip of X BTC between the two parties with no balances having changed. But, when A wants to give B money, he provides him a signed Tx2 replacement that is for X minus payment amount. Party B can, at any time, broadcast this replacement to reduce the change paid back to A. Any time A wants to give more money to B, they just send another signed Tx2 with even less change back to themself. When locktime is approaching, party B broadcasts the replacement Tx, and the network sees A transfer X BTC to B, and B transfer X-minus-balance to A. Since the original non-locked transaction entered the blockchain days before, all these transactions are guaranteed to be final and confirmed instantly, because the original two transactions were already confirmed by the network, just the amounts are changing. P.S. -- nLockTime is currently disabled in the network right now, but there is a push to have it implemented, partly based on this proposal by hashcoin -- it "solves" all the problems you mentioned in your original post -- replacement Tx's are transferred off-network, accepted instantly, and don't pollute the blockchain Yes!! This. Thank you!! I was unaware the idea already existed under another name, and could not find it using any search term guesses. Title: Re: Proposal: Bitcoin Preauths & IOUs Post by: error on October 09, 2011, 06:20:23 PM Quote You seem to have mistyped seconds. And I don't understand why 10 seconds is too high; a debit card swipe takes that long. No; I'm pretty sure it still takes at least a few minutes for verification. I'm not talking about the time it takes for it to show up. But also, even 10 seconds is much too long for the nanotransactions I mentioned. Basically, a website using an IOU-based subscription service needs the transaction to be confirmed before it even sends the response to a user's browser, since it needs to decide whether and how to display various kinds of information, including ads.Settlement in Bitcoin takes a few minutes. With debit/credit cards it takes a few days. Title: Re: Proposal: Bitcoin Preauths & IOUs Post by: theymos on October 09, 2011, 07:24:08 PM nLockTime is currently disabled in the network right now I don't believe LockTime is disabled. Replacement is disabled, but LockTime is still enforced and "standard". Title: Re: Proposal: Bitcoin Preauths & IOUs Post by: ByteCoin on October 10, 2011, 12:31:43 AM Interestingly, in order to use LockTime, you have to give at least one of your TxIns a non-standard sequence number. If I recall correctly, there is at least one transaction in the block chain with an unusual sequence number.
nLockTime affects the flow of execution is in the transaction IsFinal function, which contains the following code (tweaked by me): Code: bool IsFinal(int nBlockHeight=0, int64 nBlockTime=0) const ByteCoin Title: Re: Proposal: Bitcoin Preauths & IOUs Post by: dibbs on October 17, 2011, 10:12:14 PM Unfortunately, I am not familiar with the code at all, just the theory, so I can't meaningfully comment on the above, but I think now would be a great time to implement whatever's required to get PreAuths working. Bitcoin's in a bit of a slump, and, to quote the other thread:
Quote To get an idea of how powerful this is, with this kind of scheme you could include a payment on every packet going over the internet, or all kinds of extreme micro-payments. |