Topic: Instant payments concept... (Read 1038 times)

Yes, you're right. Risk assessment can be done on merchant side and incorporate everything you mentioned and more.

bueadept: Theres no need to time-limit trusted adresses.
Instead this responsibility lies on the merchant.

To get a realistic trust, the merchant needs to take the rate that was set on the date where the trust in the adress was purchased, and then convert back using today's rate.

For example, if a BTC today is 10$, and in 6 years, 1 BTC is 500 000 $.

Lets say I purchase a adress for 10 BTC (worth 100$). I save the adress in 6 years, and then wants to purchase something instant.

Merchant now does this:
Look up the exchange rate for 1 BTC for when the adress was purchased 6 years ago:
We get Rate = 10$

Look up the exchange rate for 1 BTC today.
We get Rate = 500 000 $

Now we take the TODAY rate divided by OLD rate:

500 000 / 10 = 50 000.

This is the trust reduction index. Now we take the trusted amount, (10 BTC) and divide by the trust reduction index: 10 / 50 000 = 0,0002

This means the trust in the adress is currently: 0,0002 BTC

*********
Lets back-calculate: TODAYs rate * Trustvalue in BTC = 500 000 * 0,0002 = 100$, which is the real value.
*********



This means the adresses will always bear the correct trust regardless of deflation, without them expiring completely, which would be devasting to users that really have purchased a trust in a adress.

I don't think an increase in value is a problem. The thing you are giving up by double spending is very valuable to replace, the fact that you used to be able to get it at a discount doesn't matter.

It probably does make sense for a merchant to have an absolute cap on the amount they'll accept instantly too and that can be dropped any time it is necessary.

This is actually pretty brilliant.  It's a dynamic green address scheme using "proof of cost."  I believe you're right, the extra step of broadcasting the transaction to the network isn't 100% necessary assuming the merchant actually wants her money and/or the sender keeps track of spent outputs in his wallet in order to prevent unintentional double-spends.  The extra check should be to see if the OP_DROP-based transaction actually contains double-spent outputs.  That way, both versions of the transaction make it into the blockchain.  If there's no double-spend but an OP_DROP-based transaction makes it into the blockchain, then you know the merchant is malicious because there's no double spend and she can actually spend that transaction at any time.

A potential problem involves the expected price deflation of Bitcoin.  Imaging I have a stash of a few dozen BTC.  They're cheap now; about $4.  Imagine I buy about 10 of them, and "proof of cost" 10 different sending addresses.  It costs me $40 total.  Now, in 6 years, one BTC is trading for about a million dollars.  I can double-spend myself almost 40 pounds of gold bars (at today's rates; maybe as little as 20 by then but still far more than $4 worth) per address.

A potential solution would be time-limiting the life of the proof-of-cost trusted address.  This way, with the expected price deflation, the cost of the double-spend would still be closer to the maximum value of the double-spend.  If I spend $4 today and it's good for a year, I can't necessarily expect to get a million for it at the end of the year.

This is a great way to buy reputation for a mobile wallet that you carry around to retail stores, vending machines, tollbooths, etc.  I wouldn't use it on a major savings wallet, obviously.

Edit:  This may be completely unnecessary, though.  The reason BitInstant charges the rates they do is due to the interface with the traditional banking systems.  When Bitcoin is in wider use and the traditional banking systems are obviated, intermediary payment systems built on top of Bitcoin should be expected to charge far less.

http://vermorel.com/process/CreateJournalEntryComment?moduleId=5042156&entryId=14193327&finalize=true

This is interesting, although I believe that it's impossible for a malicious merchant to discredit a trusted address, because they wouldn't be able to sign the transaction properly.  However, this brings up another idea, rather than encode the evidence of a double spend into the blockchain; why not a side-channel method of submitting the offending address and proof of a double spend attempt to a dedicated server for the purpose.  Since a double spend transaction doesn't propogate across the entire network, a side-channel method is necessary.  Perhaps a second, dedicated IRC channel.  Or better yet, a flag that permits the victim to send the evidence across the network already tagged as proof.  In this way, clients that receive the proof can check the proof themselves and compare it to their own blockchain to decide if the expensive address can no longer be trusted.  In this way, a database of 'burned' addresses can be compiled and shared with new clients in like manner.