Bitcoin Forum
March 28, 2024, 02:21:41 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Handling "old" coins  (Read 711 times)
TierNolan (OP)
Legendary
*
Offline Offline

Activity: 1232
Merit: 1077


View Profile
April 12, 2013, 10:26:24 PM
 #1

Unspendable coins, or just coins that the owner is holding for a long time have to be held in the unspent transaction output set.

This set is held in RAM and thus, as the blockchain gets longer, the RAM requirements will increase.  Outputs that are provably unspendable can be pruned.

What about a network rule that coins that haven't moved within the last N blocks can only be spent in blocks that have a height that is divisible by 16 (or some other number).  This would allow clients to only store UTXOs for the last N blocks in RAM.

This allows a light client to do a fair amount of verification of the chain.  It would still have to trust the rest of the network for the blocks that are divisible by 16.

The numbers could be tweaked and maybe even track general network operation.

The disadvantage is that users would need to wait for 8 blocks (1 hour 20 mins) on average to spent old coins.  However, those would be coins in long term storage.

This wouldn't even be a hard fork.

If a hard fork was being considered, then you could have a system where "old coin" transactions could be provisionally included and similar to a coinbase tx would be unspendable for a while.  Proof that they are invalid could be included in a later block.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
1711635701
Hero Member
*
Offline Offline

Posts: 1711635701

View Profile Personal Message (Offline)

Ignore
1711635701
Reply with quote  #2

1711635701
Report to moderator
1711635701
Hero Member
*
Offline Offline

Posts: 1711635701

View Profile Personal Message (Offline)

Ignore
1711635701
Reply with quote  #2

1711635701
Report to moderator
Even if you use Bitcoin through Tor, the way transactions are handled by the network makes anonymity difficult to achieve. Do not expect your transactions to be anonymous unless you really know what you're doing.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711635701
Hero Member
*
Offline Offline

Posts: 1711635701

View Profile Personal Message (Offline)

Ignore
1711635701
Reply with quote  #2

1711635701
Report to moderator
1711635701
Hero Member
*
Offline Offline

Posts: 1711635701

View Profile Personal Message (Offline)

Ignore
1711635701
Reply with quote  #2

1711635701
Report to moderator
1711635701
Hero Member
*
Offline Offline

Posts: 1711635701

View Profile Personal Message (Offline)

Ignore
1711635701
Reply with quote  #2

1711635701
Report to moderator
pc
Sr. Member
****
Offline Offline

Activity: 253
Merit: 250


View Profile
April 13, 2013, 01:09:31 AM
 #2

I think that the problems you're trying to solve can be solved better without a network rule. If the problem is RAM, why not just page out the transactions that are old to disk? You can have a special database just for old on-disk transactions, and check it only when a block gets created that references it. If most nodes aren't relaying old transactions because they only look at the current set in their RAM, then the spender may need to send the transaction directly to a miner, but I think that might be an easier problem to solve.

I know that with the price skyrocketing I wanted to sell some of my reserve coins somewhat quickly, since I had suddenly a lot more value invested in Bitcoin than I was comfortable with. I would have been pretty annoying to need to wait 16 blocks (although perhaps the price would have moved in my favor, but perhaps not).

And if nodes need to load up the full unspent set every 16 blocks, they need to keeping referenced transactions in RAM for that time… I think you just end up with the same problem, but in a more complicated way.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!