Topic: Proposal: Bitcoin Preauths & IOUs (Read 1463 times)

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:

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):
It seems that even if nLockTime is larger than some value, the transaction will still be final if all the txins have the normal sequence number. The sequence number seems to have no other effect on execution at the moment as replacement is disabled and so can be set to any other value to produce a "LockTime" transaction.

ByteCoin

I don't believe LockTime is disabled. Replacement is disabled, but LockTime is still enforced and "standard".

Settlement in Bitcoin takes a few minutes. With debit/credit cards it takes a few days.

Yes!! This. Thank you!! I was unaware the idea already existed under another name, and could not find it using any search term guesses.

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.

I believe that what you describe is nearly identical to what is proposed by hashcoin in this thread 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

You seem to have mistyped seconds. And I don't understand why 10 seconds is too high; a debit card swipe takes that long.

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.

Update: It appears this idea already exists under another name. Thanks to etotheipi for pointing it out.

I'm proposing an idea to help strengthen three of Bitcoin's weak spots:

• Off-network transactions are impossible.
• Transaction delay is on the order of 10 minutes - much too high for real-time payment verification.
• The network cannot handle a high volume of nanotransactions (such as having millions of internet users each spending 3/40th of a cent each time they visit their favorite websites - see example, below).

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 "tab" "preauth") that says N Bitcoins will be held at a newly-generated Bitcoin address (the "preauth address") for some length of time. The network will not allow the customer to spend the Bitcoins associated with the preauth address until the preauth expires. However, the customer can send off-network (directly to the merchant), signed IOUs valued at less than the preauth amount and associated with the merchant address agreed upon in the preauth. The merchant can then redeem those IOUs on the network at any time prior to the preauth expiration. After the preauth expires, the customer is free to repurpose any remaining preauth balance, and any unredeemed IOUs are worthless. Accounting is thus the responsibility of the merchant and the customer, and they must keep track and ensure the sum of the IOUs is less than the reserved balance, since the network cannot and will not pay more than was reserved in the original preauth. Lastly, since some use-cases may involve thousands of small-valued IOUs billed against each preauth, the merchant can request that the customer bundle previous IOUs by asking that they send a special "bundled" IOU (BIOU) for the sum of previous IOUs. This BIOU, if redeemed, effectively voids the previous IOUs, since the network will not allow an amount greater than the BIOU to be redeemed from any IOUs or BIOUs timestamped before it. The purpose of BIOUs is to avoid overwhelming the Bitcoin network with IOU redemptions.

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?