Benjamin [ARCHIVE] on Nostr: š Original date posted:2015-10-27 š Original message: To make myself more ...
š
Original date posted:2015-10-27
š Original message:
To make myself more clear. If I assume (roughly based on BCI data):
1000 tx / block
1 BTC volume per tx
300$ BTC/USD
=> 300.000$ of dollar volume moved per block
=> 36B$ dollar volume capacity per year
One of the key aspects of scaling would be to move low value transactions
to a 2nd layer, and leave high value transactions for the most secure
mechanism. Assume for instance that Bitcoin only processes transactions
which have a dollar nominal value of say 100$ and everything else is
handled by 2nd layer. I don't know the statistical distribution, but I
assume this would cut e.g. 95% of transaction volume and brings the average
to 100 BTC. Then the total dollar volume capacity increases by a factor of
100, that is 3600B$ with the same 1 MB blocksize. The key to scaling in my
opinion is to figure out some way to make this split work based on nominal
value of the transaction. That's already how the financial system is
organised. Banks make huge transaction volumes on closed systems. Hubs in
Lightning and banks in the fiat money system would be very similar things.
On Tue, Oct 27, 2015 at 10:46 AM, Benjamin <benjamin.l.cordes at gmail.com>
wrote:
> >> But I think it's actually a tractable question, so we can probably actually
> work out numbers!
>
> The whole point of a market would be that you get users to work out "the
> numbers". If Bitcoin would have a market then capacity would be set by its
> use and more demand would trigger supply, and vice versa. Fixing that in
> code is inevitably going to lead to bad results. So these discussions about
> blocksize and capacity went fundamentally going in the wrong direction.
> There is no sensible algorithm to determining prices of anything without
> using the input of people in the market. Its not really clear Bitcoin could
> build in a mechanism to handle that.
>
> It would be advantageous if fees would be variable by transaction size.
> Bitcoin should handle large nominal volumes and low transaction volumes and
> a possible second layer handle low nominal values and high transaction
> volumes. So it's good to consider BTC amount transferred per bytes. The
> higher that number the better for Bitcoin's capacity.
>
> On Tue, Oct 27, 2015 at 10:38 AM, Pierre <pm+lists at acinq.fr> wrote:
>
>> Hello aj,
>>
>> This is very interesting, thanks!
>>
>> You seem to be considering that bitcoin tx and lightning tx are
>> completely independent, which is not entirely true because of anchor
>> transactions. While this is certainly a valid assumption, maybe it would be
>> worth stating it explicitely ?
>>
>> Cheers,
>>
>> Pierre
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151027/806adb1d/attachment.html>;
š Original message:
To make myself more clear. If I assume (roughly based on BCI data):
1000 tx / block
1 BTC volume per tx
300$ BTC/USD
=> 300.000$ of dollar volume moved per block
=> 36B$ dollar volume capacity per year
One of the key aspects of scaling would be to move low value transactions
to a 2nd layer, and leave high value transactions for the most secure
mechanism. Assume for instance that Bitcoin only processes transactions
which have a dollar nominal value of say 100$ and everything else is
handled by 2nd layer. I don't know the statistical distribution, but I
assume this would cut e.g. 95% of transaction volume and brings the average
to 100 BTC. Then the total dollar volume capacity increases by a factor of
100, that is 3600B$ with the same 1 MB blocksize. The key to scaling in my
opinion is to figure out some way to make this split work based on nominal
value of the transaction. That's already how the financial system is
organised. Banks make huge transaction volumes on closed systems. Hubs in
Lightning and banks in the fiat money system would be very similar things.
On Tue, Oct 27, 2015 at 10:46 AM, Benjamin <benjamin.l.cordes at gmail.com>
wrote:
> >> But I think it's actually a tractable question, so we can probably actually
> work out numbers!
>
> The whole point of a market would be that you get users to work out "the
> numbers". If Bitcoin would have a market then capacity would be set by its
> use and more demand would trigger supply, and vice versa. Fixing that in
> code is inevitably going to lead to bad results. So these discussions about
> blocksize and capacity went fundamentally going in the wrong direction.
> There is no sensible algorithm to determining prices of anything without
> using the input of people in the market. Its not really clear Bitcoin could
> build in a mechanism to handle that.
>
> It would be advantageous if fees would be variable by transaction size.
> Bitcoin should handle large nominal volumes and low transaction volumes and
> a possible second layer handle low nominal values and high transaction
> volumes. So it's good to consider BTC amount transferred per bytes. The
> higher that number the better for Bitcoin's capacity.
>
> On Tue, Oct 27, 2015 at 10:38 AM, Pierre <pm+lists at acinq.fr> wrote:
>
>> Hello aj,
>>
>> This is very interesting, thanks!
>>
>> You seem to be considering that bitcoin tx and lightning tx are
>> completely independent, which is not entirely true because of anchor
>> transactions. While this is certainly a valid assumption, maybe it would be
>> worth stating it explicitely ?
>>
>> Cheers,
>>
>> Pierre
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151027/806adb1d/attachment.html>;