Re: [bitcoin-dev] assumeutxo and UTXO snapshots

Good morning all, Over the past weeks I've had a number of conversations with a few frequent contributors about this idea. I've condensed these discussions into a proposal document which you can view here: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal The document is s

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

No piece of data that does have significance to the Bitcoin consensus can be memorable because it occurs (about) every ten minutes. In order to get something memorable to provide sanity (let's say, anti-sybil-attack) checking, it has to be rare, but recurrent. The opportunity is actually already t

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

This sounds really promising to me, I think it could seriously improve the current SPV trust model. In abstract these are the possible setups today: Full node: All history, 100% monetary sovereignty. SPV: fancy term to Electrum trust model, random selection of nodes, with full delegation of mone

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

On Wed, Apr 03, 2019 at 02:39:32PM -0700, Dave Scotese via bitcoin-dev wrote: > Every block's hash is smaller than the difficulty at that time. Block > 569927's hash was VERY small (started with 21 zeros). The ratio of block > hash to difficulty requirement (0x - difficulty, I think) coul

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

I recommend that anyone following this thread read through the recent IRC exchange between Greg Maxwell and Luke Dashjr: http://www.erisian.com.au/bitcoin-core-dev/log-2019-04-04.html The conversation starts on line 205 at 2019-04-0

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

gt; > >> > There are several other more minor advantages such a feature would have, >> > including: >> > - Lower fees for exchanges (which could be passed onto customers), by >> > reducing a transaction step out of the deposit-to-withdrawal flow. >> >

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

> > Learning C++ is something within everyone's capability. Even people who do > not > wish to learn it can hire someone to perform review for them. > Anyone with enough knowledge of C++ to audit the entire the Bitcoin Core codebase is more than capable of running it with assumeutxo disabled and c

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

> This is exactly the danger. UTXO snapshots are NOT an alternative to a real IBD. There are HUGE security implications for this. This is a perfect example of what I am talking about when I say that people do not appear to notice that there is no important security implication to be found here. I

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

On Wednesday 03 April 2019 21:39:32 Dave Scotese via bitcoin-dev wrote: > Luke's comment that it could "lead to users trusting third parties (like > developers) way too much" is pertinent too, but I think an honest abatement > of that concern is impossible without teaching everyone C++. Learning C

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

On Wednesday 03 April 2019 15:39:29 Ethan Scruples via bitcoin-dev wrote: > If we can get mandatory UTXO commitments soft forked into Bitcoin, we get > the advantage of a non-growing IBD, No, we don't. This is exactly the danger. UTXO snapshots are NOT an alternative to a real IBD. There are HUGE

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

Big Concept ACK. I think this would be one of the biggest usability improvements for Bitcoin and I see no security issues with the assumevalid approach. I also agree that it's important to start work on this even before the ultimate, perfect accumulator has been designed/tested and the commitment s

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

Every block's hash is smaller than the difficulty at that time. Block 569927's hash was VERY small (started with 21 zeros). The ratio of block hash to difficulty requirement (0x - difficulty, I think) could be used to identify blocks as "special," thus providing the opportunity to popular

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

Thanks for the reply, Jonas. I should've figured someone had hit the mailing list with this one before! In hindsight, I may have overemphasized the use of this for low-powered mobile devices. Indeed I think this may also be a worthwhile optimization for common hardware too. On the margin, if a us

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

Jonas, If we can get mandatory UTXO commitments soft forked into Bitcoin, we get the advantage of a non-growing IBD, which I think everyone would agree is a benefit that, uh, grows over time. The thing I do not see people noticing is that we actually pay little to no security price for this benefi

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

This would lead to users trusting third parties (like developers) way too much. Furthermore, removing the ability for users to easily set it removes the one reasonable use case: where the user has already verified the state at some point previously, and saved the hash (ie, as backup of the UTXO

[bitcoin-dev] assumeutxo and UTXO snapshots

s > together with some kind of hex or other value, allowing users to choose the > amount they wish to deposit themselves, but ensuring their deposits are > uniquely trackable. > > > > I'm not sure if some kind of functionality already exists in BTC, as I > haven't been able to find it.

Re: [bitcoin-dev] assumeutxo and UTXO snapshots

Thanks James for the post. I proposed a similar idea [1] back in 2016 with the difference of signing the UTXO-set hash in a gitian-ish way. While the idea of UTXO-set-syncs are attractive, there are probably still significant downsides in usability (compared to models with less security), main

[bitcoin-dev] assumeutxo and UTXO snapshots

Hi, I'd like to discuss assumeutxo, which is an appealing and simple optimization in the spirit of assumevalid[0]. # Motivation To start a fully validating bitcoin client from scratch, that client currently needs to perform an initial block download. To the surprise of no one, IBD takes a linear