Author: Jeff Garzik 2013-09-08 04:13:48
Published on: 2013-09-08T04:13:48+00:00
The email thread discusses the concept of trust-free solutions in Bitcoin. The sender argues that balance-at-point-in-time can solve the issue of being completely trust-free and reduce storage requirements. However, Jeff Garzik points out that it still requires bootstrapping into trust by an earlier dataset, creating a chain that is not entirely trust-free. There are discussions on UTXO snapshotting, which is somewhat like balance-at-point-in-time but not deemed trust-free.To have a completely trust-free solution, one must verify all data from genesis through $now. However, it's not necessary for all Bitcoin wallets to download and verify all those gigabytes of data because SPV mode serves that purpose. The discussion also covers the need for Bitcoin to grow beyond an interesting experiment into global everyday use, taking the average punter into account. The sender suggests that the current concept of Bitcoin addresses as single-use destinations doesn't fit with people's mindset. People perceive addresses as the equivalent of jars where they can store their coins. Wallets, on the other hand, are like boxes where people keep some of their jars in, and only the person with the right key can open the jar and take its contents. The sender suggests that having the ability to specify the address to send from is essential and a missing feature of the QT client. Intra-wallet transfers with an "also discard the sending address" would be a way of stopping any further use of that address. When balance-at-point-in-time is implemented, this could shrink the storage for all other Bitcoin users who choose not to have a full transaction set. The sender also touches upon the need to verify the ability to send Bitcoin using balance-at-point-in-time efficiently. To do so, it's only necessary to know that the sender has the specified amount of Bitcoin, not all previous transactions that led to that state. This will increase efficiency as Bitcoin grows. The email thread ends with Jeff Garzik's signature.
Updated on: 2023-06-07T16:42:40.677250+00:00