Announced Locking of coins - Possible economic implications

[blogospheroid]

Hi All,

I'm returning to the bitcoin forums after a long time. So, please refer me to the correct thread if this topic/concept has been discussed.

There is only one source of price rise in a scenario where a deflationary P2P currency rules. That source is people with a large amount of coins spending it suddenly, without warning.

There are 2 advantages that someone who holds many coins has

1. The general rise in price of the coin itself
2. The ability to spend it any time they feel right

This possibility of a sudden spend/sale from people with huge balances is what might scare adopters of any cryptocurrency, who might like a steady price rise instead of shocks.

The concept I would like to discuss is that the protocol be modified to allow for users to publicly lock their coins and render them unspendable until blocknumber X, where X is a value somewhere in the future. This might allow for cold storage of coins in the open.

This will provide minor holders of the currency a slight assurance that the big users cannot dispose off their coins at a short notice.
Maybe this is an unfair imposition on the major stakeholders of the currency. Maybe it may need to be compensated by extra coins. (in which case, this could be a feature in some altcoin, not bitcoin) I'm not sure. I' just want to discuss the possibilities.

[tutkarz]

Markets that operate bitcoin trade like mtgox dont even need to have bitcoins to make big sale. Im not saying they are doing it. But you never know. And i dont think so any regulation is possible to avoid volatility.

[benjamindees]

Not only is this already possible, but I've demonstrated a proof-of-concept of doing exactly this, for the exact same reason.

http://blockchain.info/tx/69d771de96b5e0b7e66bc47f13eeedb96c45636bb3853637852b536b8959026a
http://blockchain.info/tx/b0fa60f601d5fe6fb1501aa614503b9af688492f68bcf8268d7cdb30f3534079

http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/09/11
http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/09/16

Here's somebody who found them:
https://bitcointalk.org/index.php?topic=131443.0

[veteranBtc]

I think, If the number of bitcoins drop, the value of bitcoins will rise.

We will have a strong market.

People with many bitcoins will win, they can spend or sell.

[blogospheroid]

Hi All,

Thanks for the comments.
benjamindees, thanks for the comments. I didn't understand everything from the links you sent.

Is my following understanding correct?

- Locking of transactions can be done
- It is possible to spend the coins  you have locked, but it will result in your previously locked transaction being invalidated, for double spending reasons
- a procedure called "isfinal" in the bitcoin code is broken

-----

Since this is the economics thread, I would mention that point 2 is really not the feature I would like to see. If those coins can be spent, then that undoes the point of the locking, right?

If my understanding is wrong and this feature is an available feature, then concerns by other posters about the vulnerability of bitcoin to being crashed by sudden spends is actually a very valid one. People with large balances, if they want the cryptocurrency to succeed, should be placing their coins in cold storage in this manner. There should be a way to scan how many coins are placed in dealyed transaction mode and upto what block height have they been locked. If this is a shaky feature, I understand them not wanting to do that.

Bitcoin allows people to know the overall monetary supply. Knowing the number of current, "available to spend in the next 10 minutes" coins will provide a greater sense of the actual money supply that can be deployed, and thus a greater sense of stability.

Infact, unencumbered by the present bitcoin legacy, an altcoin could have delayed transaction acceptance as a feature of allocating coins as well, moving more coins to those who are willing to spend them later.

[benjamindees]

- Locking of transactions can be done

Yes, with some caveats.  One of the caveats is that the mechanism (nLockTime) was not designed for the application you have in mind.  Even the terminology is backwards.  In the documentation of the original feature, which was meant to enable multi-party contracts, a "locked" transaction is one that can be included in the blockchain (and therefore re-spent).  Whereas you are obviously interested in "locking" Bitcoins to prevent them from being spent.

Another caveat is that "locked" Bitcoin transactions are stored in the memory pool, which is not exactly the most reliable place.

- It is possible to spend the coins  you have locked, but it will result in your previously locked transaction being invalidated, for double spending reasons

This is another caveat.  It is possible to spend "locked" coins by creating a replacement TX and mining it yourself:

nodes will accept them and hold them in their memory pool (and thus drop conflicting transactions)
...
If you want to replace a time-locked transaction, you're going to have to mine it yourself, or go find a miner to agree to help you.  Once a replacement is mined (or even just a regular transaction spending one of the inputs), all nodes holding the time-locked tx will see the conflict and drop the one in their memory pool.

The easy way to avoid this is to set the sequence number to the maximum value and prevent replacements, BUT you can't do that because:

if all the inputs have a UINT_MAX sequence number then lockTime is ignored.

The hard way to work around this limitation is to create a transaction with multiple inputs from different parties, such that they would have to collude in order to replace the transaction and spend the "locked" coins.

- a procedure called "isfinal" in the bitcoin code is broken

For the purpose of this application, yeah basically.  But it's not clear that it's possible to "fix" it without breaking the original purpose of nLockTime.  So, we're limited to the work-around mentioned.

This bug report was opened because I neglected to set the sequence number on the first test transaction and created some confusion when it didn't work the way I expected.  But that's the code in question.

[blogospheroid]

benjamindees,

You have understood my requirement correctly. Are you aware of any place where such an idea was discussed?

Everyone else,

Any thoughts on the idea? Can this be done within the ambit of the present protocol or needs something new?