From: Mike Hearn <mike@plan99•net>
To: Matt Corallo <bitcoin-list@bluematt•me>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Near-term scalability
Date: Fri, 15 Jun 2012 15:34:19 +0200 [thread overview]
Message-ID: <CANEZrP2rZEwQqkceTN3yOqx_Mo_8gyRyBUgv8NnfKd8ZWGYzww@mail.gmail.com> (raw)
In-Reply-To: <1339765735.31489.40.camel@bmthinkpad>
> The idea can be more generalized in that there are many cases where the
> generator of a transaction doesn't care about confirmation times, and
> would really be willing to make their transaction lower priority than
> other 0-fee transactions.
Just to be clear, I think this solution is a hack and don't support it
because it's yet another change of network rules. Some random people
will get whacked because of a heuristic "rule of thumb".
If it's implemented, SD could/would switch to fresh addresses and
nothing would have been achieved except making an already complex
system more complex.
I disagree with the notion that you need "less important than free".
If you care about the confirmation time of a transaction that was sent
to you and you need space in a limited resource, you can pay for it.
It's an auction like any other. Besides, the idea that transactions
are free today is just a psychological trick befitting governments but
not us - transactions are funded by aggressive hyperinflation. I would
never describe Bitcoin as a free system and I suggest nobody else does
either.
If grouped fee calculations are implemented, we can keep the nice
property that the person who cares about double spending risk pays the
fees, and if you assume most transactions are hub-and-spoke from
buyers to merchants, rather than a pure p2p graph, in practice it'll
work out to seeming free most of the time even if seen globally it
doesn't make much difference.
> My point was that the easiest way to do it would be to ship a pruned
> snapshot with Bitcoin, and such a system, while verifiable, would
> increase Bitocin's centralization.
I'm not sure why. If you want to audit everything from scratch, after
checking the code you could just blow away the included files and then
"-connect=archive.bitcoin.org" or something like that. After
rebuilding the chain from scratch, check the databases for consistency
with the included data.
It reduces the number of nodes with full copies of the block chain,
yes, but as long as there's at least one copy of the old data in an
accessible location new nodes can still bootstrap just fine.
I'm sure we can find organizations willing to host full chains for
people who want to rebuild their databases from scratch, given how
cheap disk space is.
> connect to, possibly complicating using Bitcoin for clients that either
> wish to run a full IBD or older clients which need a non-fClient node
Yes, but old nodes probably have a copy of the chain already, so it
wouldn't affect them. New blocks would still be fully distributed,
right?
The only case where it'd cause issues is if you install a fresh copy
of a very old node. Not a common occurrence, and those nodes will have
to wait until they find an archival node announcing itself. Those
nodes could be made to announce more frequently than normal, if need
be.
next prev parent reply other threads:[~2012-06-15 13:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-15 11:29 Mike Hearn
2012-06-15 13:08 ` Matt Corallo
2012-06-15 13:34 ` Mike Hearn [this message]
2012-06-15 16:18 ` Matt Corallo
[not found] ` <CAAS2fgTJ0UH0Gr6gVMNZwOiv41WzZVesyvNCULj8UfCPPGxQrw@mail.gmail.com>
2012-06-15 16:53 ` Gregory Maxwell
2012-06-15 16:56 ` Stefan Thomas
2012-06-15 17:37 ` Mike Koss
2012-06-15 18:38 ` Amir Taaki
[not found] ` <CAAS2fgSVbYFkkhP_0Ny5ULB-DJKN-3hZLkqWukrGL80-UenMwQ@mail.gmail.com>
2012-06-15 18:50 ` Amir Taaki
2012-06-15 18:55 ` Gregory Maxwell
2012-06-15 20:56 ` Gavin Andresen
2012-06-16 7:55 ` Mike Hearn
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=CANEZrP2rZEwQqkceTN3yOqx_Mo_8gyRyBUgv8NnfKd8ZWGYzww@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=bitcoin-list@bluematt$(echo .)me \
/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