Christian Decker [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-06 📝 Original message: Gert-Jaap Glasbergen ...
📅 Original date posted:2018-11-06
📝 Original message:
Gert-Jaap Glasbergen <gertjaap at gertjaap.nl> writes:
> Op 1 nov. 2018 om 03:38 heeft Rusty Russell <rusty at rustcorp.com.au<mailto:rusty at rustcorp.com.au>> het volgende geschreven:
>> I believe this would render you inoperable in practice; fees are
>> frequently sub-satoshi, so you would fail everything. The entire
>> network would have to drop millisatoshis, and the bitcoin maximalist in
>> me thinks that's unwise :)
>
> I can see how not wanting to use millisatoshis makes you less compatible
> with other people that do prefer using that unit of account. But in this
> case I think it's important to allow the freedom to choose.
>
> I essentially feel we should be allowed to respect the confines of the layer
> we're building upon. There's already a lot of benefits to achieve from second
> layer scaling whilst still respecting the limits of the base layer. Staying
> within those limits means optimally benefit form the security it offers.
>
> Essentially by allowing to keep satoshi as the smallest fraction, you ensure
> that everything you do off-chain is also valid and enforced by the chain when
> you need it to. It comes at trade offs though: it would mean that if someone
> routes your payment, you can only pay fees in whole satoshis - essentially
> meaning if someone wants to charge a (small) fee, you will be overpaying to
> stay within your chosen security parameters. Which is a consequence of your
> choice.
It should be pointed out here that the dust rules actually prevent us
from creating an output that is smaller than the dust limit (546
satoshis on Bitcoin). By the same logic we would be forced to treat the
dust limit as our atomic unit, and have transferred values and fees
always be multiples of that dust limit.
546 satoshis is by no means a tiny amount anymore, i.e., 546'000 times
the current minimum fee and value transferred. I think we will have to
deal with values that are not representable / enforceable on-chain
anyway, so we might as well make things more flexible by keeping
msatoshis.
> I would be happy to make a further analysis on what consequences allowing this
> choice would have for the specification, and come up with a proposal on how to
> add support for this. But I guess this discussion is meant to "test the waters"
> to see how much potential such a proposal would have to eventually be included.
>
> I guess what I'm searching for is a way to achieve the freedom of choice,
> without negatively impacting other clients or users that decide to accept some
> level of trust. In my view, this would be possible - but I think working it out
> in a concrete proposal/RFC to the spec would be a logical next step.
With a lot of choice comes great power, with great power comes great
responsibility... uh I mean complexity :-) I'm all for giving users the
freedom to chose what they feel comfortable with, but this freedom comes
at a high cost and the protocol is very complex as it is. So we need to
find the right configuration options, and I think not too many users
will care about their unit of transfer, especially when it's handled
automatically for them.
Cheers,
Christian
📝 Original message:
Gert-Jaap Glasbergen <gertjaap at gertjaap.nl> writes:
> Op 1 nov. 2018 om 03:38 heeft Rusty Russell <rusty at rustcorp.com.au<mailto:rusty at rustcorp.com.au>> het volgende geschreven:
>> I believe this would render you inoperable in practice; fees are
>> frequently sub-satoshi, so you would fail everything. The entire
>> network would have to drop millisatoshis, and the bitcoin maximalist in
>> me thinks that's unwise :)
>
> I can see how not wanting to use millisatoshis makes you less compatible
> with other people that do prefer using that unit of account. But in this
> case I think it's important to allow the freedom to choose.
>
> I essentially feel we should be allowed to respect the confines of the layer
> we're building upon. There's already a lot of benefits to achieve from second
> layer scaling whilst still respecting the limits of the base layer. Staying
> within those limits means optimally benefit form the security it offers.
>
> Essentially by allowing to keep satoshi as the smallest fraction, you ensure
> that everything you do off-chain is also valid and enforced by the chain when
> you need it to. It comes at trade offs though: it would mean that if someone
> routes your payment, you can only pay fees in whole satoshis - essentially
> meaning if someone wants to charge a (small) fee, you will be overpaying to
> stay within your chosen security parameters. Which is a consequence of your
> choice.
It should be pointed out here that the dust rules actually prevent us
from creating an output that is smaller than the dust limit (546
satoshis on Bitcoin). By the same logic we would be forced to treat the
dust limit as our atomic unit, and have transferred values and fees
always be multiples of that dust limit.
546 satoshis is by no means a tiny amount anymore, i.e., 546'000 times
the current minimum fee and value transferred. I think we will have to
deal with values that are not representable / enforceable on-chain
anyway, so we might as well make things more flexible by keeping
msatoshis.
> I would be happy to make a further analysis on what consequences allowing this
> choice would have for the specification, and come up with a proposal on how to
> add support for this. But I guess this discussion is meant to "test the waters"
> to see how much potential such a proposal would have to eventually be included.
>
> I guess what I'm searching for is a way to achieve the freedom of choice,
> without negatively impacting other clients or users that decide to accept some
> level of trust. In my view, this would be possible - but I think working it out
> in a concrete proposal/RFC to the spec would be a logical next step.
With a lot of choice comes great power, with great power comes great
responsibility... uh I mean complexity :-) I'm all for giving users the
freedom to chose what they feel comfortable with, but this freedom comes
at a high cost and the protocol is very complex as it is. So we need to
find the right configuration options, and I think not too many users
will care about their unit of transfer, especially when it's handled
automatically for them.
Cheers,
Christian