From: Matthew Mitchell <matthewmitchell@godofgod•co.uk>
To: Gregory Maxwell <gmaxwell@gmail•com>,
"bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
Date: Tue, 11 Sep 2012 22:48:43 +0100 [thread overview]
Message-ID: <19ED4257-0BCA-41C5-A533-B0AB9B500181@godofgod.co.uk> (raw)
In-Reply-To: <CAAS2fgSymOJ=cQnNwK9+nvRYszHHH4vtUpoQYWNNYoVaYB5Gpg@mail.gmail.com>
On 11 Sep 2012, at 20:42, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> Someone can do that just by pipelining the one at a time requests.
> How much bandwidth do you think you could save over that?
You wouldn't need to pipeline the requests, just place more than one inventory vector in get data, right? Well my messages would save the space of those inventory vectors. Instead of needing 36 byte inventory vectors for each transaction and a var int, you would need two var ints only. And then the transaction responses only need one header, so you save 24 bytes for each transaction after the first. You could say that is a small benefit.
> I don't see what value this provides. For protecting against the
> future you might as well suggest uploading x86 code which gets
> executed to select transactions. "Protects against the future". Can
> you clarify some more about exactly how you think it would help?
Well it depends on wether you seriously think bitcoin blocks should be limited at a million bytes or not.
> it's not clear to me how your proposal is really all that useful for
> very large blocks: I looks like it would lot of bytes sending
> redundant tree data.
Look at bittorrent. With bittorrent you don't download files from a single peer all at once.
> Bitcoin gets its value through scarcity. There are two kinds of
> scarcity that are economically important, scarcity of the coins— there
> will never be more than 21 million— and scarcity of the block space
> which, as the protocol is defined and enforced by every node can not
> be more than 1MB. The latter scarcity is what makes the security model
> economically sane.
Why wouldn't requesting minimum fees in the software work as is done currently?
> Fortunately, its perfectly possible to make transactions denominated
> in bitcoin outside of the blockchain, and in a secure and distributed
> manner that respects the principles that make bitcoin attractive, but
> with information hiding that improves privacy, transaction speed, and
> scalability. See, e.g. the good work being done by Open transactions
> to create distributed cryptographic banks. So blockchain scarcity
> itself doesn't prevent Bitcoin from being a one world currency
> (something which isn't at all sane no matter how big you make the
> blocks if you don't allow for other modes of transaction processing—
> who the heck wants to possibly wait an hour to get a 1 confirm
> sodapop??).
So what you essentially suggest is having bitcoin banks that maintain trust through Open Transaction contracts which contains proof of agreement, providing some legal protection? One wonders why have bitcoin at all then? Why not have an elaborate e-money system between several banks using Open Transactions? Bitcoin doesn't just contain proof of if something was done right or not, it contains actual certainty that it will be done right. And how does Open Transactions prevent fractional reserve fraud?
I suppose when people consider bitcoin banks, they will consider bitcoin being useless.
> but I know that changing it is precisely as
> technically difficult as changing the 21 million limit
Set the change to occur at some block in the future leaving time for people to upgrade. Send out alert messages to notify users to upgrade. Issue is, some people might not like the change for whatever reasons.
As far as I see it, if bitcoin won't scale, then it's worth looking at something different to bitcoin that will scale.
next prev parent reply other threads:[~2012-09-11 21:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-11 19:07 Matthew Mitchell
2012-09-11 19:42 ` Gregory Maxwell
2012-09-11 21:48 ` Matthew Mitchell [this message]
2012-09-11 23:22 ` Gregory Maxwell
2012-09-13 8:42 ` Mike Hearn
2012-09-13 14:05 ` Matthew Mitchell
2012-09-13 15:16 ` Gregory Maxwell
[not found] ` <2B95CF41-4304-4D2A-9ABF-198D97B7449B@godofgod.co.uk>
2012-09-13 15:46 ` Matthew Mitchell
[not found] ` <CAAS2fgQi8QFwU2M=wLiDodt3SmO48vUV5Sp3YCb1OmGJ5m=E7Q@mail.gmail.com>
2012-09-13 17:49 ` Matthew Mitchell
2012-09-13 18:59 ` Pieter Wuille
2012-09-13 20:24 ` Matthew Mitchell
-- strict thread matches above, loose matches on Subject: below --
2012-09-10 15:07 Matthew Mitchell
2012-09-10 15:14 ` Gregory Maxwell
2012-09-10 16:29 ` Matt Corallo
2012-09-10 18:59 ` Luke-Jr
2012-09-10 19:34 ` Matthew Mitchell
2012-09-10 19:53 ` Matt Corallo
2012-09-10 20:00 ` Gregory Maxwell
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=19ED4257-0BCA-41C5-A533-B0AB9B500181@godofgod.co.uk \
--to=matthewmitchell@godofgod$(echo .)co.uk \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@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