> From: sadiq Ismail
Hi sadiq,
> I am from a place with metered and slow bandwidth, so assuming U.S.
> internet bandwidth and speed specifications for IBD is incorrect and ignores
> that not everyone shares the same reality.
No such assumption has been made. My post specifically addressed the performance *trend*, which contrary to common assumptions, is improving (everywhere) and will eventually render this question moot.
> I will share mine.
No number of performance anecdotes can address the outstanding critiques, but I'm happy to cover the other issues.
> I can use wallets to receive Bitcoin as an SPV
Okay, which is far better than a trusting wallet.
> but once you want to sync the and have a node synced to the tip,
> I face a significant bottleneck.
Why are you syncing the node? Presumably you want a fully validated node - for better than SPV security. You cannot get that from assuming it. You should sync and validate a node and then just connect your SPV wallet to it. This transitions you to actual full node security from SPV security, once that full node security actually exists.
> I think if a less-trusted setup were provided, like assumeutxo
Assuming is not "less trusted", it's fully trusted. I think you meant "less trustworthy".
> with p2p sharing, Since my use case is data analysis, not receiving payments,
> I would not face this bottleneck and would definitely use it.
It's not clear why you would want a less trustworthy (fully trusted) wallet when you can use a far more trustworthy SPV wallet. And you can transition that same wallet to zero trust once your node is validated, by just pointing your SPV wallet to the node. Furthermore you are not providing any justification for moving this into P2P, the trusted node feature you want already exists.
> As a real example of the point Fabian made about using worse alternatives: I
> also travelled hundreds of kilometres to a different city to assumeDatadir by
> copying the datadir from a trusted friend.
Incorporating Core's trusted utxo system into the P2P network does not change this at all. You could have just downloaded it from your friend, or anyone else you trust to provided it. Certainly that's better than downloading it from randos on the P2P network. And you would have the same download cost either way.
> The risk of the chain growing so large that syncing takes a long time is real
The opposite is happening. This is why I pointed out the declining cost trend. That applies everywhere, not just in the US. And in any case, trust would not be a solution. That's the problem Bitcoin exists to eliminate.
> AssumeUTXO helps eliminate that, because at least you are not trusting one
> person but a group of contributors committing to a hash
Who is the "group of contributors" that we are assuming has become the central authority on what is valid? I do not see this listed in the BIP. Is there to be a public key provided somehow so that we can all be assured that we are trusting the right authority? If only someone could devise a solution to this problem.
> with headers-first sync and other safeguards assumeUTXO provides.
There are no such other "safeguards". Headers first is DoS protection. This is not an SPV implementation.
> AssumeUTXO is, in my opinion, a lesser evil than, for example, assumeDatadir.
This is a false dichotomy. Using an SPV wallet while syncing your node is a far more secure and more efficient existing alternative. And it has the actual security that people seem to be assuming this has (see your headers comment above). There is no reason to choose any evil, and certainly no reason to impose it on the P2P network.
Best,
Eric
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/c92abfec-e3af-42bc-b371-36e209f1727en%40googlegroups.com.