Topic: Yet another solution for instant payments (Constructive centralization) (Read 2238 times)

I'd like to see this principle applied at more basic level through the entire bitcoin network. If bitcoins reside on the same address for more than, say 50 or 75 years without being moved, they should be presumed lost by the original owner. Miners should be allowed to re-mine/recover such bitcoins and recycle them back into the bitcoin network. Bitcoins will always stay 21 million and avoid danger of deflation because many people will inevitably lose their coins in one way or another. So, creating time-to-live and subsequent recovery mechanism is very important.

Thanks to #bitcoin-dev I think I found something. Apparently you can prepare transactions which become valid in the future with a "lock time".

What this means (apparently) is that you could send coins to an address which requires two signatures for further transactions to be valid... Let's say the address is made with A and B. B can make a transaction with a some lock time and sign it. This transaction is pre-signed by B and accepted by A as being signed. The transaction sends the coins back to A and is only valid when A signs it.

That makes sense to me. A needs to sign the transaction so A can receive the bitcoins back. When the transaction is signed by A and the date has been reached (As signed by B already) it is then accepted by the bitcoin network.

Alternatively, I suppose, A and B can sign this transaction when it is made and A volunteers to broadcast it at the later date. If the money is expected at the lock time, A could broadcast it immediately, I assume, and the network will process it when it becomes valid after the lock time is reached.

What this means is that the private key for B doesn't expire but rather B signs the future transaction immediately giving A the ability to use it at a later date when it is valid.

Of course the transactions should be recognized by the Bitcoin network, otherwise there's no point. I'm not completely sure of the existing and planned possibilities, but I think referring to time (or at least block #) being at least some value is a planned feature which opens a whole range of applications.

When everything is normal coins are spent by signing a transaction with both the server's and the client's key. Only in case the service provider goes belly up clients need to wait for its key to expire, and instead of "year" it can be any other time. But clients will need to make sure to extend the expiration (by moving to a new address with a different target time) when the target time is reached. The coins are still (relatively) safe even if the server's key expires, it only means transactions aren't instantly verified.

Every transaction output specifies a script to be executed in order to validate spending this output. Currently everyone just uses the script "supply a signature with a private key whose public key's hash it address X" - this is what the "OP_DUP OP_HASH160 2799cee55ec84f57ee76b27f4e0aa9e64cad533b OP_EQUALVERIFY OP_CHECKSIG" bit you can see in blockexplorer means. But they could just as easily specify "supply two signatures, one for address X and one for address Y". With OP_EVAL that's even simpler - everyone will just use the script "supply a script whose hash is address X, and data which makes it return true", and then when spending the coins the script that requires two signatures will be specified (though it has to be known a priori to come up with the address). With the date the supplied script will be "supply two signatures, or just one signature if time is > October 2012".

So do you make these transactions completely incompatible with the current bitcoin software or can the current software use date information within a condition using the bitcoin script? In other words you can program a transaction to be acceptable by the current bitcoin software with the date condition?

I thought the bitcoin scripting thing was more primitive but I don't actually understand it, so please put me on the right track!

But people don't want to wait a year and the bitcoins have to be resent to an address using a new secondary key, right? So each year the coins will have to go through the transaction process since the previous transaction no longer has the valid third party key component?

Hold on, how are the bitcoins that enter the joint wallet described onh te block chain so that clients understand that the verification is required by both parties, otherwise the consumers could send coinds with no third part signage and repeat it with the third party signage. The bitcoin client needs to know that the bitcoins require double signing (It doesn't technically it just needs to know the result of the double signing produces the right one,right?). How does the date thing come into this?

I addressed this in my comment.
Coins will be spendable if ( (server sig and client sig) or (client sig and time > October 2012) ). If the server vanishes, clients will wait a year and then be able to reclaim their coins. Server unreliability can still be a nuisance though.

@zhoutong: How can the keys expire? That makes no sense to me. If the consumers don't have the private keys then they can't do the transaction as it will not be approved into the block chain unless it is signed by both parties, no?

Also your branding is terrible. "CentralCoin" is not good.

Any client that supports this will need to have a protocol in place to accept different services. This way consumers can choose which third party to verify the transactions. It ultimately is reliant on merchant trust as well.

Consumers do have to trust it if they need to rely upon a server to complete their transactions. If the server is unreliable they will take their coins out, if the server dies and the business goes into the dark and never releases the private keys, then the bitcoins are lost along with the private keys.

I'm sure such a service might have some usefulness in bitcoin's future though.


Okay, so some shared wallet?


What is this for?

Gavin has plans to implement multiple private keys transactions before version 1.0.  There will be multiple transaction types, not just A and B signing.

Once these new transactions are available new services such as escrow will be available in the bitcoin API.  Bitcoin's features will rock finance, escrow, banking, contracts, etc.

Initial support for multisignature transactions

This adds initial support for three new types of transactions:
(a and b)
(a or b)
(a and b) or c

Here is the design discussion: https://gist.github.com/39158239e36f6af69d6f

The servers are not hackable. So it's almost risk-free to run the service.

If people trust green address, they should trust CentralCoin. Consumers don't have to trust it, no one holds the money.

The private keys can be set to expire after a particular block, so that no matter what happens, the users can always unlock their wallets.

It's better than green address, and its better than ewallet.

You'd need a client that allowed people to create a dual wallet but continue using a single wallet. People need to choose services they can trust to reliably process the transactions. You will need to get consumers and merchants to trust it. If the business that runs the service goes out of business, it needs to publicise the private keys so people can unlock their bitcoins.

It's not complex at all. So users can just download CentralCoin client instead of Bitcoin client, and start using in the same way. No block downloading is required, just generate Bitcoin address and be ready to receive.

100% compatible with Bitcoin. Sending to anyone is instant. Receiving from another CentralCoin client is instant.

I heard about this on the #bitcoin IRC channel. Upon thinking about it, such a service would be used rarely. A merchant would likely trust a 0 confirmation transaction in face to face small transactions. I'm not sure how much this would be in demand. For digital purchases there maybe some use for it but it makes bitcoin a lot more complex in nature...

But how does it address the instant payment problem?

It's just a secure substitute for e-wallets, but nothing better than that.

Old... https://github.com/bitcoinjs/bitcoinjs-lib - client side transaction signing... say bye bye to instant wallets FOREVER

The improvement is perfect for this idea. I don't really know too much about the protocol details of Bitcoin, so I didn't think about this possibility.

The owners of the server will have no way to take any coins anymore, other than collusive double spending. (The server may still authorize double spending transactions from the clients.)

At least, I would say CentralCoin is an extension of green address to everyone. As long as the server is up and running, there's no difference between CentralCoin client and Bitcoin client, except that downloading the initial blocks is no longer required for a new CentralCoin because the server can provide everything.

Great idea. A few improvements though:

There's no reason the client should send the private key to the server. You can make bitcoins that are spendable only with digital signatures from two private keys (and with OP_EVAL, you can do it transparently as a normal Bitcoin address). So the client only needs to send a digital signature for the requested transactions. This eliminates any risk of the server stealing coins.

I think you can also make it so that the coins are spendable with just the client's key after a specified time. So even if the server loses his key, the clients can reclaim the coins after this time. If everything is fine, the time arrives and the clients wish to continue using the service, they move the coins to a new address with an updated time.

Yet more proof that all the supposed "problems" with Bitcoin are solvable with its incredibly powerful and flexible architecture.

I hope no one else has posted the same ideas before. Let me just explain my thoughts.

We can design a centralized system for Bitcoin transactions. (Let's call it CentralCoin.) The difference between this system and eWallets is that CentralCoin requires two private keys to sign a transaction. (Basically it's just another layer of encryption.) The clients hold the wallets and a private key, and server holds the other key.

Since two private keys are required to sign a transaction, neither the client nor the server has the power to spend Bitcoins without the other party's agreement. The transaction starts with the client sending its private key to the server to "unlock" the wallet. (I will talk about trust issues later.) The server can easily prevent double spending from happening because it has knowledge every single transaction. Within the CentralCoin network itself, the payments are instant.

CentralCoin can be made 100% compatible with Bitcoin clients. So that CentralCoin clients can still generate addresses and send/receive payments from Bitcoin users. CentralCoin's client private key can be copied to multiple devices because it can be used to authenticate to the server, then cloud-based payments will be possible.

Another advantage is that Bitcoin users can enjoy instant payments as well. If Bitcoin users trust CentralCoin, they can verify whether a transaction comes from CentralCoin. If yes, then they can be sure that the transaction will be confirmed.

Trust issues: This requires clients to trust the server not to record down the private keys. But it's at least better than eWallets, who have ultimate control over everything, even if the eWallet owners don't want to control. (This is not worse than our eWallet.)

Security issues: If the server is not recording down the private keys anywhere, centralized hacking is impossible. The server-side private key has no use without the client-side private keys. The clients will still control the money. The client-side private key is the only hackable component because the server will sign every single transaction that is not double spending. (This is not worse than our Bitcoin client.)

Single-point-of-failure: The server can distribute all the combined private keys to CentralCoin's client. If the owner of the CentralCoin network is honest, even if there's a data loss or security attacks, he can simply disclose the server-side private key and users will be able to "unlock" their wallets themselves. Their CentralCoin wallets will be automatically converted to Bitcoin wallets with no loss of funds. (This is not worse than our eWallet.)

In the end, consumers and merchants share all the benefits, and the solution is at least not worse than our existing ones.