rich1.0npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8njumphttps://nostr.ae📅 Original date posted:2015-09-18 📝 Original message:s/move the genesis block forward/move your genesis checkpoint forward/ On Sep 18, 2015 4:37 PM, "Jorge Timón" <jtimon at jtimon.cc> wrote: > Well, with utxo commitments at some point maybe is enough to validate the > full headers history but only the last 5 years of ttansaction history > (assuming utxo commitments are buried 5 years worth of blocks in the past). > This scales much better than validating the full history and if we get a 5 > year reorg something is going really wrong anyway... > Maybe after validating the last 5 years you also want to validate the rest > of the history backards to get the "fully-full node" security. > Of course 5 years it's just an arbitrary number: 2 or maybe even 1 would > probably be secure enough for most people. I've referred to this idea as > "hard checkpoints" or "moving the genesis block forward" in the past. > On Sep 18, 2015 4:18 PM, "Rune Kjær Svendsen" < > bitcoin-dev at lists.linuxfoundation.org> wrote: > >> There are a couple of points I’d like to address. >> >> Firstly, yes, >50% attacks are a problem for Bitcoin. Bitcoin does not >> function if the majority of mining power is dishonest. There is no way >> around that. It’s how proof-of-work functions. And if we lose >> proof-of-work, we lose Bitcoin. >> >> Secondly, I’m not suggesting that UTXO set hashes *replace* block hashes, >> or even that it should be in the block header (probably in the coinbase >> somewhere). I suggest it as an *addition* to the existing consensus rules. >> Full nodes can still verify the chain with the added step of hashing the >> UTXO set for every block. Of course, this can easily be deferred to after >> proof-of-work has been verified already, such that no work is wasted. >> Unless a 51% attack is in effect. But I argue that this is a moot point, >> since Bitcoin is useless anyway under such circumstances. >> >> Lastly, I’m not suggesting miners discard the blockchain history. A miner >> has an incentive to be absolutely sure that the chain he’s building on is >> the right one. If he’s wrong, he loses money/income. There’s simply no >> reason for a professional miner *not* to do the full initial sync, which >> only needs to be done once. Non-miners, who just want to check the balance >> of their wallet, however, really don’t need to retrieve information about >> Hal Finney sending bitcoins to Satoshi in 2010. In any case, this practice >> isn’t sustainable. >> >> In the end, it isn’t possible to control whether a miner verifies the >> entire blockchain anyway (anyone can send the UTXO set over the wire). Not >> letting the proof-of-work cover the UTXO hash doesn’t solve this problem, >> it only makes it impossible to know whether a given UTXO set is the one >> that the majority is mining on without retrieving the entire blockchain, >> and doing the verification yourself. People can choose to skip that >> regardless of what we do. >> >> Furthermore, all nodes have the option of deciding which level of >> security they want. We’re not lessening security of the protocol, we’re >> strengthening the security of something that’s already possible to do >> (build on top of an unverified blockchain), but we’d rather want that >> people not do. >> >> /Rune >> >> >> > On 18 Sep 2015, at 21:43, Patrick Strateman via bitcoin-dev < >> bitcoin-dev at lists.linuxfoundation.org> wrote: >> > >> > Full nodes using UTXO set commitments is a change to the bitcoin >> > security model. >> > >> > Currently an attacker with >50% of the network hashrate can rewrite >> history. >> > >> > If full nodes rely on UTXO set commitments such an attacker could create >> > an infinite number of bitcoins (as in many times more than the current >> > 21 million bitcoin limit). >> > >> > Before we consider mechanisms for UTXO set commitments, we should >> > seriously discuss whether the security model reduction is reasonable. >> > >> > On 09/18/2015 12:05 PM, Rune Kjær Svendsen via bitcoin-dev wrote: >> >> Currently, when a new node wants to join the network, it needs to >> retrieve the entire blockchain history, starting from January 2009 and up >> until now, in order to derive a UTXO set that it can verify new >> blocks/transactions against. With a blockchain size of 40GB and a UTXO size >> of around 1GB, the extra bandwidth required is significant, and will keep >> increasing indefinitely. If a newly mined block were to include the UTXO >> set hash of the chain up until the previous block — the hash of the UTXO >> set on top of which this block builds — then new nodes, who want to know >> whether a transaction is valid, would be able to acquire the UTXO set in a >> trustless manner, by only verifying proof-of-work headers, and knowing that >> a block with an invalid UTXO set hash would be rejected. >> >> >> >> I’m not talking about calculating a complicated tree structure from >> the UTXO set, which would put further burden on already burdened Bitcoin >> Core nodes. We simply include the hash of the current UTXO set in a newly >> created block, such that the transactions in the new block build *on top* >> of the UTXO set whose hash is specified. This actually alleviates Bitcoin >> Core nodes, as it will now become possible for nodes without the entire >> blockchain to answer SPV queries (by retrieving the UTXO set trustlessly >> and using this to answer queries). It also saves bandwidth for Bitcore Core >> nodes, who only need to send roughly 1GB of data, in order to synchronise a >> node, rather than 40GB+. I will continue to run a full Bitcoin Core node, >> saving the entire blockchain history, but it shouldn’t be a requirement to >> hold the entire transaction history in order to start verifying new >> transactions. >> >> >> >> As far as I can see, this also forces miners to actually maintain an >> UTXO set, rather than just build on top of the chain with the most >> proof-of-work. Producing a UTXO set and verifying a block against a chain >> is the same thing, so by including the hash of the UTXO set we force miners >> to verify the block that they want to build on top of. >> >> >> >> Am I missing something obvious, because as far as I can see, this >> solves the problem of quadratic time complexity for initial sync: >> http://www.youtube.com/watch?v=TgjrS-BPWDQ&t=2h02m12s >> >> >> >> The only added step to verifying a block is to hash the UTXO set. So >> it does require additional computation, but most modern CPUs have a SHA256 >> throughput of around 500 MB/s, which means it takes only two seconds to >> hash the UTXO set. And this can be improved further (GPUs can do 2-3 GB/s). >> A small sacrifice for the added ease of initial syncing, in my opinion. >> >> >> >> /Rune >> >> _______________________________________________ >> >> bitcoin-dev mailing list >> >> bitcoin-dev at lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > >> > >> > _______________________________________________ >> > bitcoin-dev mailing list >> > bitcoin-dev at lists.linuxfoundation.org >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/45701f72/attachment.html>