Bitcoin Forum
October 23, 2018, 07:49:16 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Is the feature "reclaiming disk space" really implemented in Bitcoin Core?  (Read 2062 times)
bomberb17
Hero Member
*****
Offline Offline

Activity: 579
Merit: 500


View Profile
October 22, 2017, 01:34:21 AM
 #21

You can do that locally once you have downloaded and verified the blockchain. You cannot do that to the blockchain as a whole because I don't know whether the transaction "Bob->Charlie (25BTC)" is actually legitimate when I am syncing a new node. For me to check that it is legit, I need to know where Bob got the output to spend. Just because a transaction is in a block with a valid proof of work does not automatically mean that all transactions in the block are valid; that's not how Bitcoin works.

You can certainly do this locally as that is basically what Satoshi suggests in the whitepaper. But as gmaxwell pointed out above, what we do now for pruning locally is way more efficient than what Satoshi suggests. Satoshi suggests that we throw away parts of blocks as UTXOs are spent. But what we do is that we maintain a separate database with our UTXOs and chainstate data so we don't actually need to have the blocks themselves. So we just throw away old blocks entirely because we have validated them and taken the things from them that we need and stored them elsewhere in a more compact form.


Why would you need where Bob got the output? If that transaction is included in a verified block, it means that it is valid. And if that block is like 1000 blocks behind the current block, it's impossible to change it.
(I am not talking about how the current bitcoin protocol works).
I was thinking of something like transaction cut-through https://bitcointalk.org/index.php?topic=281848.0 which is already being implemented in mimble wimble.
1540324156
Hero Member
*
Offline Offline

Posts: 1540324156

View Profile Personal Message (Offline)

Ignore
1540324156
Reply with quote  #2

1540324156
Report to moderator
1540324156
Hero Member
*
Offline Offline

Posts: 1540324156

View Profile Personal Message (Offline)

Ignore
1540324156
Reply with quote  #2

1540324156
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1554
Merit: 1706


3F1Y9yquzvY6RWvKbw2n2zeo9V5mvBhADU


View Profile WWW
October 22, 2017, 07:32:55 PM
 #22

Why would you need where Bob got the output? If that transaction is included in a verified block, it means that it is valid. And if that block is like 1000 blocks behind the current block, it's impossible to change it.
(I am not talking about how the current bitcoin protocol works).
I was thinking of something like transaction cut-through https://bitcointalk.org/index.php?topic=281848.0 which is already being implemented in mimble wimble.
You need to either know where Bob got the output to verify that the block is valid or you need to have some other way to prove that a block is valid. You can't just assume a block is valid even if it is deep in the blockchain, that's not the security model of Bitcoin.

bomberb17
Hero Member
*****
Offline Offline

Activity: 579
Merit: 500


View Profile
October 24, 2017, 02:43:00 AM
 #23

You need to either know where Bob got the output to verify that the block is valid or you need to have some other way to prove that a block is valid. You can't just assume a block is valid even if it is deep in the blockchain, that's not the security model of Bitcoin.

Ok let me rephrase my question: Suppose we change the security model of bitcoin, and enforce transaction pruning at the blockchain level (not at the client level) in a fashion described above, for blocks that their height is < (H - N), where H is the current block height and N is a set constant. Would that model be insecure? If not, why?
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1554
Merit: 1706


3F1Y9yquzvY6RWvKbw2n2zeo9V5mvBhADU


View Profile WWW
October 24, 2017, 03:50:25 AM
 #24

Ok let me rephrase my question: Suppose we change the security model of bitcoin, and enforce transaction pruning at the blockchain level (not at the client level) in a fashion described above, for blocks that their height is < (H - N), where H is the current block height and N is a set constant. Would that model be insecure? If not, why?
It is still insecure.

The case that you must consider is a new full node that is just coming online and is syncing the blockchain. It has to download it from its peers. So how does it know that a peer didn't just prune a bunch of transactions that have unspent output that are a couple thousand blocks deep and relay that version of the blockchain to them?

bomberb17
Hero Member
*****
Offline Offline

Activity: 579
Merit: 500


View Profile
October 24, 2017, 05:39:16 AM
 #25

I get your point.
By using my first example, if e.g. a malicious node pruned the tx "Bob->Charlie (25BTC)", then the tx "coinbase -> Alice (50BTC)" would be partially orphaned, since it was originally linked to the tx "Alice->Bob (25BTC)" and then became linked to "Bob->Charlie (25BTC)". Alice would effectively get all the coins back from charlie.
So the only solution would be to enforce CoinJoin as gmaxwell suggested, however these coinjoin transactions are interactive and optional.
Maybe an incentive to the users to use such transactions (zero tx fees?) would help, which would in turn enable pruning the intermediate coinjoin transactions safely.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!