Pieter Wuille [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-15 📝 Original message:On Mon, Jun 15, 2015 at ...
📅 Original date posted:2015-06-15
📝 Original message:On Mon, Jun 15, 2015 at 11:27 AM, Mike Hearn <mike at plan99.net> wrote:
> I persevered for several months to add a very small "API" I needed for my
> app to Bitcoin Core, and it was in the end a waste of time. There are no
> actionable items left for the getutxo patch, regardless, I had to fork
> Bitcoin to get it out there. It would have been *much* easier to just
> say, fuck it, I'll use blockchain.info and in fact some in this community
> told me to do exactly that. But, the approach I chose has been working fine
> for months now.
>
Since you keep bringing this up, I'll try to clarify this once again.
Since your patch was to enable querying spentness of particular outputs,
which is fundamentally unprovable data in Bitcoin as is (even your proposed
protocol that verifies scripts with amounts under sighash only proves
correctness of the txout data, not its spentness), I indeed don't see why
you would want anything else than querying such a service. I wish it were
different, but the choice is between querying a central service, or
trusting something a random peer on the internet tells you. At least with
the central service you can use an authenticated protocol with known keys
to detect MITM, and have someone to point to when they lie.
Not decentralized you say? Absolutely. But why do we want decentralization
in the first place? To remove central points of failure, and to reduce
trust. Bitcoin gets away with decentralization because it can validate (to
more or lesser extent) the data it received from its identityless peers. 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...
Do you want actually trustless querying of spentness in the future? Help
working on one of the several TXO commitment ideas to get them implemented.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/d1788c2e/attachment.html>;
📝 Original message:On Mon, Jun 15, 2015 at 11:27 AM, Mike Hearn <mike at plan99.net> wrote:
> I persevered for several months to add a very small "API" I needed for my
> app to Bitcoin Core, and it was in the end a waste of time. There are no
> actionable items left for the getutxo patch, regardless, I had to fork
> Bitcoin to get it out there. It would have been *much* easier to just
> say, fuck it, I'll use blockchain.info and in fact some in this community
> told me to do exactly that. But, the approach I chose has been working fine
> for months now.
>
Since you keep bringing this up, I'll try to clarify this once again.
Since your patch was to enable querying spentness of particular outputs,
which is fundamentally unprovable data in Bitcoin as is (even your proposed
protocol that verifies scripts with amounts under sighash only proves
correctness of the txout data, not its spentness), I indeed don't see why
you would want anything else than querying such a service. I wish it were
different, but the choice is between querying a central service, or
trusting something a random peer on the internet tells you. At least with
the central service you can use an authenticated protocol with known keys
to detect MITM, and have someone to point to when they lie.
Not decentralized you say? Absolutely. But why do we want decentralization
in the first place? To remove central points of failure, and to reduce
trust. Bitcoin gets away with decentralization because it can validate (to
more or lesser extent) the data it received from its identityless peers. 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...
Do you want actually trustless querying of spentness in the future? Help
working on one of the several TXO commitment ideas to get them implemented.
--
Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/d1788c2e/attachment.html>;