From: Mike Hearn <mike@plan99•net>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
Date: Mon, 15 Jun 2015 12:36:35 +0200 [thread overview]
Message-ID: <CANEZrP0eGDTafK+ZUBNcQBOe2JU_PqZVXMt0Ds-b8Ley7kbGrA@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBgc0i-XsN=g0V4Y0bko-Xb1AT5x=UWDa+opL3eFbBmJfA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]
>
> Since you keep bringing this up, I'll try to clarify this once again.
>
I understand the arguments against it. And I think you are agreeing with me
- Adam is bemoaning the way developers outsource stuff to third party
services, and suggesting it is relevant to the block size debate. And we
are saying, no, it's happening because it's easier than doing things in a
decentralised way.
> If you can't do that, and are just aiming for removing central points of
> failure, run a bunch of servers yourself, and let others run their own.
> That sounds remarkably close to what you actually did, actually...
>
Right. There's a deeper issue here. The sort of 'trustless' querying of the
UTXO set that was demanded from me is impossible even with commitments,
because the answer can change the moment you receive it. All it takes is a
new block or new transaction to be broadcast a split second after you
download and use the data, and suddenly what you did is incorrect no matter
how many proofs you verified!
The only way to know this has happened is to be a full node and download
all transactions yourself ... and even then, you are trusting your peers to
actually relay you all transactions and not a subset. So in the end you can
never achieve perfection, only get closer to it.
But that situation is *fine* for many use cases, like showing someone a
snapshot of their crowdfund in a user interface. We just accept that what
we see on the screen may lag behind reality. It happens all the time with
all kinds of non-Bitcoin apps. We accept that there may be cases where the
answer we get is wrong. The software can nevertheless still be useful.
So Lighthouse compromises. It queries multiple peers and cross-references
their answers. If their answers don't match it shows an error on the screen
and won't show the user any status for their crowdfund at all. This error
has never occurred. Maybe one day it will. So the app gets more
decentralisation, more robustness, and accepts that the user interface
might one day show a wrong answer if the P2P network starts lying (or your
internet connection is hacked, but the right fix for that is P2P
encryption).
Unfortunately this sort of balance-of-risks approach is considered a
non-starter in Bitcoin Core. So why would developers even try? The message
sent was clear: even if you have an approach you think will work, don't
bother.
Much easier to just outsource to a trusted service indeed.
[-- Attachment #2: Type: text/html, Size: 3189 bytes --]
next prev parent reply other threads:[~2015-06-15 10:36 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-14 21:23 Adam Back
2015-06-14 22:23 ` Mike Hearn
2015-06-14 23:58 ` Adam Back
2015-06-15 0:53 ` Eric Lombrozo
2015-06-15 0:55 ` Eric Lombrozo
2015-06-15 4:11 ` Peter Todd
2015-06-15 4:43 ` Eric Lombrozo
2015-06-15 9:27 ` Mike Hearn
2015-06-15 9:39 ` Eric Lombrozo
2015-06-15 10:24 ` Pieter Wuille
2015-06-15 10:36 ` Mike Hearn [this message]
2015-06-15 10:40 ` Pieter Wuille
2015-06-15 10:50 ` Mike Hearn
2015-06-15 11:16 ` Rebroad (sourceforge)
2015-06-15 17:53 ` Raystonn .
2015-06-15 18:14 ` Adam Back
2015-06-15 18:57 ` [Bitcoin-development] The Bitcoin Node Market Raystonn .
2015-06-15 19:18 ` sickpig
2015-06-15 19:36 ` Raystonn .
2015-06-15 20:12 ` sickpig
2015-06-16 3:30 ` Kevin Greene
2015-06-16 3:41 ` Luke Dashjr
2015-06-16 3:49 ` Kevin Greene
2015-06-16 4:05 ` Kevin Greene
2015-06-16 4:12 ` Aaron Voisine
2015-06-16 5:28 ` justusranvier
2015-06-16 5:30 ` Potter QQ
2015-06-16 7:55 ` Aaron Voisine
2015-06-16 13:32 ` justusranvier
2015-06-16 17:04 ` Aaron Voisine
2015-06-16 17:22 ` Aaron Voisine
2015-06-16 15:52 ` devrandom
2015-06-15 4:43 ` [Bitcoin-development] comments on BIP 100 Peter Todd
2015-06-15 9:06 ` Mike Hearn
2015-06-15 2:28 ` Jeff Garzik
2015-06-15 2:44 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANEZrP0eGDTafK+ZUBNcQBOe2JU_PqZVXMt0Ds-b8Ley7kbGrA@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox