< NicolasDorier>
sipa: Nothing prevent me of signing a snapshot every day. But what would be the danger of me doing so? They would trust my repository, but they still have a way to check the utxoset is correct once it is fully sync.
< NicolasDorier>
@harding not mentioning SPV put all the bruden of handling P2P from untrusted source.
< NicolasDorier>
on my own code
< NicolasDorier>
Strictly better to use Bitcoin Core to filter the traffic for me
< sipa>
NicolasDorier: i see
< sipa>
that's a fair point
< NicolasDorier>
harding: Also, I don't like the fact that then the availability of your service would depends on the remote node
< NicolasDorier>
Verifying consensus rules are not that heavy for the CPU once the sync is done.
< NicolasDorier>
Using SPV instead of full validation seems harder and put again risks of miners having leverage on individuals
< NicolasDorier>
Sorry, this conversation might be better on bitcoin-dev than on bitcoin-core-dev.
< NicolasDorier>
I initially just wanted to propose the idea of including such utxo set snapshot hash in a text file in Bitcoin Core releases as part of the release process. So people trusting the gitian sigs, can also trust the snapshot hash. It would be one UTXO set snapshot at every core release, which is more than enough.
< NicolasDorier>
quite easy to verify for contributors
< NicolasDorier>
No need of any additional tool, or any rpc or nothing, just a pure text file with the utxo set hash in every release that gitian signers would check as part of the release process.
< gmaxwell>
But what would be the danger of me doing so? -- because it makes your actions effectively unreviewable
< gmaxwell>
" but they still have a way to check the utxoset is correct once it is fully sync." -- and as you've admitted, essentially no one will.
< bitcoin-git>
[bitcoin] Empact opened pull request #14855: test: Correct ineffectual WithOrVersion from transactions_tests (master...with-or-version-test) https://github.com/bitcoin/bitcoin/pull/14855
< dongcarl>
Can someone remove #8708 from p2p refactor project?
< meshcollider>
Or rather, I moved it from "in progress" to "done"
< dongcarl>
Yeah thanks dude
< NicolasDorier>
gmaxwell: The people who would not check the utxo set, would also never check the bitcoin core binaries via gitian and just download them from the website.
< NicolasDorier>
At least, if the utxo set hash is part of the release, they don't have to trust an additional party for the utxo set snapshot.
< bitcoin-git>
[bitcoin] dongcarl opened pull request #14856: [rebase] net: remove more CConnman globals (master...2018-12-more-connman-params) https://github.com/bitcoin/bitcoin/pull/14856
< bitcoin-git>
[bitcoin] instagibbs opened pull request #14857: wallet_keypool_topup.py: Test for all keypool address types (master...keypool_topup_addresstype) https://github.com/bitcoin/bitcoin/pull/14857
< amaclin>
may I propose Bitcoin client feature here?
< molz>
amaclin, you can do it in channel #bitcoin or #bitcoin-dev
< instagibbs>
amaclin, if it's a feature for bitcoin core, opening an issue as feature request is definitely appropriate
< harding>
NicolasDorier: I didn't suggest using SPV with a changing set of random peers the way some wallets do. That indeed requires miner trust. I suggested connecting over SPV to a single node that the user trusted. If the user operated the node themselves, then their security is the same as bootstrapping their own node specifically for BTCPay. If the user uses your node, then this is probably no worse than them trusting your UTXO
< harding>
snapshot. The advantage is that they can switch from trusting you during initial setup to trusting themselves after their node has synced, allowing you to have the advantage of minimum setup delay for a nice UX but also, after a time, strong security without trust in you.