From: Gregory Maxwell <gmaxwell@gmail•com>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Enforcing inflation rules for SPV clients
Date: Sun, 24 Jun 2012 14:03:10 -0400 [thread overview]
Message-ID: <CAAS2fgSWb2v6F2xbK0ZFNPz5cwgf6zwB8QbRYgyS1u8xmgAUTQ@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP0nagdAXyMEY5yxyXBjdo78YC16mjUG9=b0AMe4qOS=fA@mail.gmail.com>
On Sun, Jun 24, 2012 at 8:45 AM, Mike Hearn <mike@plan99•net> wrote:
> d'aniel made a good proposal - having good nodes broadcast
> announcements when they detect a rule that breaks the rules, along
> with a proof that it did so. Checking the proof might be very
Link?
I also proposed this on this list (see the response in the tree
datastructures thread) along with more elaboration on IRC. If multiple
people are coming up with it thats a good sign that it it might
actually be viable. :)
I was going for a slightly different angle and pointing out that the
proofs would mean that a node doing validation with TxOUT tree which
hasn't personally wittnessed the complete history of Bitcoin actually
has basically the same security— including resistance to miners
creating fake coin in the past— as a full node today because in order
to get away with a lie every single node must conspire: It's adequate
that only one honest node wittness the lie because once it has the
proof information is hard to suppress.
To save people from having to dig through the public IRC logs for what
I wrote there:
--- Day changed Thu Jun 21 2012
15:10 < gmaxwell> etotheipi_: amiller: an interesting point with all
this txout tree stuff is that if you join the network late and just
trust that the history is correct based on the headers, any other node
who has witnessed a rule violation in the past can prepare a small
message which you would take to be conclusive proof of a rule
violation and then ignore that chain.
15:11 < gmaxwell> e.g. if someone doublespends I just take the
conflicting transactions out and the segments connecting them to the
chain... and show them to you. And without trusting me you can now
ignore the entire child chain past that point.
15:13 < gmaxwell> This fits nicely with the Satoshi comment "It takes
advantage of the nature of information being easy to spread but hard
to stifle" ... it would be safe to late-join a txout tree chain,
because if there is only a single other honest node in the world who
was around long enough to wittness the cheating, he could still tell
you and it would be as good as if you saw it yourself.
15:17 < gmaxwell> (this is akin to the provable doublespend alert
stuff we talked about before, but applied to blocks)
next prev parent reply other threads:[~2012-06-24 18:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-24 12:45 Mike Hearn
2012-06-24 16:51 ` Stefan Thomas
2012-06-25 8:44 ` Mike Hearn
2012-06-24 18:03 ` Gregory Maxwell [this message]
2012-06-25 8:42 ` Mike Hearn
2012-06-25 23:21 Daniel Lidstrom
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=CAAS2fgSWb2v6F2xbK0ZFNPz5cwgf6zwB8QbRYgyS1u8xmgAUTQ@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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