Matthew Mitchell [ARCHIVE] on Nostr: đź“… Original date posted:2012-09-11 đź“ť Original message:On 11 Sep 2012, at 20:42, ...
đź“… Original date posted:2012-09-11
đź“ť Original message:On 11 Sep 2012, at 20:42, Gregory Maxwell <gmaxwell at 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.
đź“ť Original message:On 11 Sep 2012, at 20:42, Gregory Maxwell <gmaxwell at 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.