Bitcoin Forum
May 12, 2024, 01:32:42 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Development & Technical Discussion / Re: Transaction pruning details on: May 31, 2011, 09:19:03 AM
Code:
Tx0
  -> 50 to A [0]

Tx1
  <- import 50 from Tx0:0
  -> 1 to B [0]
  -> 49 to A [1]

Tx2
  <- import 1 from Tx1:0
  -> 1 to C [0]

Tx3
  <- import 1 from Tx2:0
  -> 1 to D [0]

I agree that when C would send 1 bitcoin to D in transaction 3, transaction 2 could be pruned.

I have to correct myself here, Tx2 cannot be pruned before Tx1 is pruned.
2  Bitcoin / Development & Technical Discussion / Re: Transaction pruning details on: May 31, 2011, 07:42:21 AM
Thanks a lot for the very detailed explanation. I think I completely get it.

Storage size magnitude will not be in the order of total past transactions, but in the order of total (non-empty) accounts (or addresses).

One final question, a bit off-topic: Would it be necessary to treat coinbase transactions differently? Couldn't they just be pruned like normal transactions?

 
3  Bitcoin / Development & Technical Discussion / Re: Transaction pruning details on: May 31, 2011, 07:06:41 AM
My point is to try and find out how efficiently previous transactions can be pruned.

Transaction 0 can be pruned, but it's information (and stored data) is effectively moved to transaction 1.

Transaction 1 also contains the data of A transferring a coin to B. I expected this data to be prunable after transaction 2. But transaction 1 can only be pruned when A has spent its remaining 49 bitcoins, which might take a long time.

I agree that when C would send 1 bitcoin to D in transaction 3, transaction 2 could be pruned.

Or, if A would send 1 bitcoin to D in transaction 3, transaction 3 would take transaction 1 as referenced transaction, send 1 bitcoin to D and 48 back to A. After this, transaction 1 could then also be pruned. This need not take so long.

Could you confirm I am thinking correctly here?
4  Bitcoin / Development & Technical Discussion / Re: Transaction pruning details on: May 31, 2011, 06:07:28 AM
It is possible. If someone rebroadcasts the same transaction, it will be rejected because you don't have its previous transaction.

Let me restate my example to be more in accordance with the specification.

Say at some point A, B and C own 0 bitcoins.

In transaction 0, 50 bitcoins are sent to A (A just found a block).

A sends 1 bitcoin to B in transaction 1. I read in the forum (http://forum.bitcoin.org/index.php?topic=8689.msg125994#msg125994) that the current client will 'use up' all of the money from transaction 0 and send the change to a new address (or back to A I presume). I think that is why you say the previous transaction doesn't exist?

Then B sends 1 bitcoin to C in transaction 2. Now transaction 0 can be safely forgotten, but the amount of data to be stored hasn't really decreased, since the complete transaction 1 (containing 2 tx_outs) is to be stored. Am I right here?
5  Bitcoin / Development & Technical Discussion / Re: Transaction pruning details on: May 30, 2011, 09:07:35 PM
No, transaction inputs are specified in terms of txhash:output_index pairs, not addresses. You don't import value from an address, you literally import it from a particular transaction.

The pruning process isn't implemented today, but when it is there are a few possibilities. One is that the tx won't be completely deleted, the hash of it will still stick around in the database. It's 32 bytes instead of several hundred, so it's still a big win. Another possibility is that some nodes will keep the whole chain and if a tx input isn't known, pruning nodes can contact archival nodes and ask them for the tx. If they don't have it, it's an orphan transaction. If they do, it means the connected tx was pruned and thus it's a double spent.

You're saying that the option that the tx won't be completely deleted is just one of the possibilities. What I am very interested in, is whether there is a possibility that previous transactions can be completely deleted, as is claimed in Nakamoto's paper.

After studying the protocol, for now my conclusion is that this is not the case. Referencing a former transaction instead of an account unfortunately doesn't make a difference. Could anyone please invalidate my conclusion?

Honestly, I'm skeptical pruning will ever really be needed. Assuming continued growth, disk storage is so cheap that the cost of keeping the old parts of the chain around will be dwarfed by the costs of keeping up with the head.

Whether pruning is necessary or not is another question, but I'm glad you brought it up. Assuming only the transaction hash sticks around like you say and 2000 transactions per second as mentioned on the scalability page, this means a storage need of 32 * 2000 * 3600 =5529600000  bytes = 5.5 Gb per day. Not to mention that this must be stored in such a way that it is searchable quickly, which will likely increase storage needs.

All and all, quite a lot more than the 'best cast' of 80 bytes per block (or 1.16 MB / day) that is mentioned on the scalability page. I hope you understand why I'm so damned curious about this.

6  Bitcoin / Development & Technical Discussion / Re: Transaction pruning details on: May 30, 2011, 05:32:23 PM
The first one can be forgotten (assuming it only has one output). It will never again be needed for verifying other transactions, since it can't be redeemed again.

Thank you, in yours and Mike's answer I read the same, transaction 1 can be forgotten. But, what happens then if B keeps a copy of the transaction and after a while resends it to the network? My guess is that, if the original transaction 1 was pruned, another 1 bitcoin is transferred from A to B?
7  Bitcoin / Development & Technical Discussion / Transaction pruning details on: May 30, 2011, 05:01:38 PM
Having studied Bitcoin in quite some depth (the 'scalibility page', Nakamoto's paper and some forum questions), I cannot find an answer to the question:

How is it that old transactions can be pruned from the ledger that the blockchain is.

Simple example:

Say at some point A owns 10 bitcoins, B and C own 0 bitcoins.

A transfers 1 bitcoin to B (transaction 1), after which B transfers 1 bitcoin to C (transaction 2).

Forget for a while about transaction fees, but can one of these transactions be pruned (after being confirmed by enough blocks in the longest chain)?

If not, can someone please give me a typical example in which a transaction can be pruned?
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!