[IDEA] Distributed Anonymous Green Addresses

[jonwaller]

Problem: Instant payments with Bitcoin
Using Bitcoin in a real-world shop, or at a ticket gate is impossible because you have to wait for confirmations for the transaction to be complete. (A few minutes)

Current solution: Green addresses
A few services have green addresses, but let's look at MtGox.
When you make a payment from MtGox, you can select a "green address". This means that your bitcoins are sent first to a special MtGox address that other services know they can trust to not double-spend. They trust MtGox, so they trust that specified address. This means that as soon as other services see an unconfirmed transaction from this special address, they can be sure that they will get their money.

Problems with green addresses:

• The green address needs to trust you not to double spend. Usually this means you need to use the service that owns the green address you want to use. You can't send from your own client.
• (And often) The owner of the green address is known. An attack could shut down the owner, and break instant payments.

Proposed solution: A "pre-chargable" autonomous anonymous agent which forwards transactions.
You have a software agent, sitting on some server on the Tor network, with its own wallet.

Explanation:

Vendor address: A
Robot (agent) address: B
Customer address: C

1) You pre-fund the agent by sending it bitcoins from the address C
2) Wait for the transaction to be complete, the agent is now funded. (This becomes your transaction forwarding limit)
3) When you wish to pay a vendor, send a single transaction:
C --> 1 satoshi --> A
C --> [Item cost] --> B
4) The bot, already funded at least up to the item cost, will see the transaction, and send on the correct amount to the specified address. Instant payment.

If the user attempts to double-spend, so the bot doesn't receive the money it needs from the payment, it doesn't lose any money as it can draw from the prefunded amount. The bot would need to reject payments if the pending transaction values were over the pre-charged amount.

To stop using the agent, and withdraw your funds, you would send a specified amount which was marked as meaning withdraw:
C --> 2 satoshi --> A


Advantages:

• Agents can be completely anonymous, and hidden behind Tor.
• Agents don't need to be owned by the same service that sends the payments. (MtGox -> MtGox green address)
• Agents can be watched to see that they follow the rules.
• Agents can take commission on transfers, and make a large profit by becoming trusted.
• Instant payments.
• Anyone can set up an agent.

Disadvantages:

• The long con. Agents could perform for years, becoming more trusted, then just run away with the stored money.
  Mitigation: Agents would make a small commission (drawn from the prefund) on each transaction. It would be financially worthwhile to become a trusted node and not run off with the money.
• Agents could be dishonest on a low percentage of transactions, and not forward the money on when asked to.
  Mitigation: You can track the agent through the blockchain, and blacklist them if they don't follow the rules. (I'm making a site to do this)
• Someone needs to initially trust the agent. But once it starts forwarding payments, you can keep an eye on it though the blockchain.

Feedback:

Good idea? Bad idea? Feedback/criticism very welcome. Thanks.

[1714612575]

1714612575

[1714612575]

1714612575

[cbeast]

One day large miners may offer subscriptions for access to their nodes. They will include the transaction for a fee and will stamp their brand on the block in which it is included. These miners (let's call them MasterPay and AliCharge) can offer these escrow services without being behind TOR.

[BlackPrapor]

You basically want to replace a remote wallet, stored on well known and trusted host by an anonymous, hidden and untrusted host to store your money, so you can do just the same instant transaction. Not so smart. But the idea that the trusted entity holding green addresses should be decentralised is a good move. They just need to find a safe and effective way to do that.

[kangasbros]

Good idea. I have been actually thinking about lots of applications for autonomous agents.

However the first problem is that you should program an anonymous autonomous agent framework. AFAIK that is VERY difficult problem. Requires quite an infrastructure.

The first problem that I see, is that we need good (probably decentralized?) marketplace for VPSs/dedicated hosting. So that the autonomous agent could live there and replicate.

[killerstorm]

Eh, why not use multi-sig? Requires much less trust.

[edmundedgar]

If you've got to have this agent that the payee has to trust you probably don't need to keep recycling money through the agent. It would be enough just to leave enough money deposited with the agent to guarantee as much money as you needed in flight in unconfirmed transactions at any given time.

There may be better ways to do this involving multisig stuff, but I'd imagine something like (assuming all communication happens through the Bitcoin network, although it doesn't have to):

1) You deposit 1 BTC with the agent address B from customer address C. (Assume it has more than 1 BTC in it.)
2) You make the payment (say 0.5 BTC) direct to the vendor address A from address C.
3) The agent sees that a payment has been made from address C, and allocates 0.5 BTC to it from the 1 BTC you deposited.
4) The agent sends a message in the form of a 1 Satoshi payment from its trusted address A to the vendor address B.
5) The vendor sees the agent's payment and your original unconfirmed payment, accepts that you're good for the payment and gives you your stuff.
6) You now have 0.5 BTC of your 1 BTC locked up with the agent, so you can spend another 0.5 BTC on something else, but no more than that.
7) Either:
 a) The payment is confirmed, the agent notices that it no longer needs to stand behind that transaction and frees up the 0.5 BTC for the next transaction you might want to make, or for withdrawal if you want to withdraw it.
 or...
 b) The payment doesn't confirm within a reasonable time (or the money gets double-spent so you know it will never confirm) and the agent pays the money to the vendor.

There are a bunch of variations on this to prevent you needing to trust the agent as much. For example, you might want to lock the customer's money that the agent is looking after in a multi-sig transaction, which can only be released by the customer and the agent both signing. Since the agent can't spend the money unilaterally there's still a possibility that the vendor will get screwed, but at least there's no incentive for the customer to screw them. This also makes the agent much less of a hacking target, because it couldn't steal your money even if it wanted to (although I suppose it could try to ransom it back to you...)