Zac Greenwood [ARCHIVE] on Nostr: đź“… Original date posted:2021-08-16 đź“ť Original message:Hi ZmnSCPxj, Thank you for ...
đź“… Original date posted:2021-08-16
đź“ť Original message:Hi ZmnSCPxj,
Thank you for your counterproposal. I fully agree that as a first step we
must establish whether the proposed functionality can be implemented
without making any changes to consensus.
Your counterproposal is understandably more technical in nature because it
explores an implementation on top of Bitcoin as-is. However I feel that for
a fair comparison of the functionality of both proposals a purely
functional description of your proposal is essential.
If I understand your proposal correctly, then I believe there are some
major gaps between yours and mine:
Keys for unrestricted spending: in my proposal, they never have to come
online unless spending more than the limit is desired. In your proposal,
these keys are required to come online in several situations.
Presigning transactions: not required in my proposal. Wouldn’t such
presigning requirement be detrimental for the usability of your proposal?
Does it mean that for instance the amount and window in which the
transaction can be spent is determined at the time of signing? In my
proposal, there is no limit in the number of transactions per window.
Number of windows: limited in your proposal, unlimited in mine.
There are probably additional gaps that I am currently not technically able
to recognize.
I feel that the above gaps are significant enough to state that your
proposal does not meet the basic requirements of my proposal.
Next to consider is whether the gap is acceptable, weighing the effort to
implement the required consensus changes against the effort and feasibility
of implementing your counterproposal.
I feel that your counterproposal has little chance of being implemented
because of the still considerable effort required and the poor result in
functional terms. I also wonder if your proposal is feasible considering
wallet operability.
Considering all the above, I believe that implementing consensus changes in
order to support the proposed functionality would preferable over your
counterproposal.
I acknowledge that a consensus change takes years and is difficult to
achieve, but that should not be any reason to stop exploring the appetite
for the proposed functionality and perhaps start looking at possible
technical solutions.
Zac
On Sat, 14 Aug 2021 at 03:50, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Zac,
>
>
> > Hi ZmnSCPxj,
> >
> > Thank you for your insightful response.
> >
> > Perhaps I should take a step back and take a strictly functional angle.
> Perhaps the list could help me to establish whether the proposed
> functionality is:
> >
> > Desirable;
> > Not already possible;
> > Feasible to implement.
> >
> > The proposed functionality is as follows:
> >
> > The ability to control some coin with two private keys (or two sets of
> private keys) such that spending is limited over time for one private key
> (i.e., it is for instance not possible to spend all coin in a single
> transaction) while spending is unrestricted for the other private key (no
> limits apply). No limits must apply to coin transacted to a third party.
> >
> > Also, it must be possible never having to bring the unrestricted private
> key online unless more than the limit imposed on the restrictive private
> key is desired to be spent.
> >
> > Less generally, taking the perspective of a hodler: the user must be
> able to keep one key offline and one key online. The offline key allows
> unrestricted spending, the online key is limited in how much it is allowed
> to spend over time.
> >
> > Furthermore, the spending limit must be intuitive. Best candidate I
> believe would be a maximum spend per some fixed number of blocks. For
> instance, the restrictive key may allow a maximum of 100k sats per any
> window of 144 blocks. Ofcourse the user must be able to set these
> parameters freely.
>
> My proposal does not *quite* implement a window.
> However, that is because it uses `nLockTime`.
>
> With the use of `nSequence` in relative-locktime mode, however, it *does*
> implement a window, sort of.
> More specifically, it implements a timeout on spending --- if you spend
> using a presigned transaction (which creates an unencumbered
> specific-valued TXO that can be arbitrarily spent with your online keyset)
> then you cannot get another "batch" of funds until the `nSequence` relative
> locktime passes.
> However, this *does* implement a window that limits a maximum value
> spendable per any window of the relative timelock you select.
>
> The disadvantage is that `nSequence` use is a lot more obvious and
> discernible than `nLockTime` use.
> Many wallets today use non-zero `nLockTime` for anti-fee-sniping, and that
> is a good cover for `nLockTime` transactions.
> I believe Dave Harding proposed that wallets should also use, at random,
> (say 50-50) `nSequence`-in-relative-locktime-mode as an alternate
> anti-fee-sniping mechanism.
> This alternate anti-fee-sniping would help cover `nSequence` use.
>
> Note that my proposal does impose a maximum limit on the number of windows.
> With `nSequence`-in-relative-locktime-mode the limit is the number of
> times that the online keyset can spend.
> After spending that many windows, the offline keyset has to be put back
> online to generate a new set of transactions.
>
> It has the massive massive advantage that you can implement it today
> without any consensus change, and I think you can expect that consensus
> change will take a LONG time (xref SegWit, Taproot).
>
> Certainly the functionality is desirable.
> But it seems it can be implemented with Bitcoin today.
>
> Regards,
> ZmnSCPxj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210816/298ee64f/attachment.html>;
đź“ť Original message:Hi ZmnSCPxj,
Thank you for your counterproposal. I fully agree that as a first step we
must establish whether the proposed functionality can be implemented
without making any changes to consensus.
Your counterproposal is understandably more technical in nature because it
explores an implementation on top of Bitcoin as-is. However I feel that for
a fair comparison of the functionality of both proposals a purely
functional description of your proposal is essential.
If I understand your proposal correctly, then I believe there are some
major gaps between yours and mine:
Keys for unrestricted spending: in my proposal, they never have to come
online unless spending more than the limit is desired. In your proposal,
these keys are required to come online in several situations.
Presigning transactions: not required in my proposal. Wouldn’t such
presigning requirement be detrimental for the usability of your proposal?
Does it mean that for instance the amount and window in which the
transaction can be spent is determined at the time of signing? In my
proposal, there is no limit in the number of transactions per window.
Number of windows: limited in your proposal, unlimited in mine.
There are probably additional gaps that I am currently not technically able
to recognize.
I feel that the above gaps are significant enough to state that your
proposal does not meet the basic requirements of my proposal.
Next to consider is whether the gap is acceptable, weighing the effort to
implement the required consensus changes against the effort and feasibility
of implementing your counterproposal.
I feel that your counterproposal has little chance of being implemented
because of the still considerable effort required and the poor result in
functional terms. I also wonder if your proposal is feasible considering
wallet operability.
Considering all the above, I believe that implementing consensus changes in
order to support the proposed functionality would preferable over your
counterproposal.
I acknowledge that a consensus change takes years and is difficult to
achieve, but that should not be any reason to stop exploring the appetite
for the proposed functionality and perhaps start looking at possible
technical solutions.
Zac
On Sat, 14 Aug 2021 at 03:50, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Zac,
>
>
> > Hi ZmnSCPxj,
> >
> > Thank you for your insightful response.
> >
> > Perhaps I should take a step back and take a strictly functional angle.
> Perhaps the list could help me to establish whether the proposed
> functionality is:
> >
> > Desirable;
> > Not already possible;
> > Feasible to implement.
> >
> > The proposed functionality is as follows:
> >
> > The ability to control some coin with two private keys (or two sets of
> private keys) such that spending is limited over time for one private key
> (i.e., it is for instance not possible to spend all coin in a single
> transaction) while spending is unrestricted for the other private key (no
> limits apply). No limits must apply to coin transacted to a third party.
> >
> > Also, it must be possible never having to bring the unrestricted private
> key online unless more than the limit imposed on the restrictive private
> key is desired to be spent.
> >
> > Less generally, taking the perspective of a hodler: the user must be
> able to keep one key offline and one key online. The offline key allows
> unrestricted spending, the online key is limited in how much it is allowed
> to spend over time.
> >
> > Furthermore, the spending limit must be intuitive. Best candidate I
> believe would be a maximum spend per some fixed number of blocks. For
> instance, the restrictive key may allow a maximum of 100k sats per any
> window of 144 blocks. Ofcourse the user must be able to set these
> parameters freely.
>
> My proposal does not *quite* implement a window.
> However, that is because it uses `nLockTime`.
>
> With the use of `nSequence` in relative-locktime mode, however, it *does*
> implement a window, sort of.
> More specifically, it implements a timeout on spending --- if you spend
> using a presigned transaction (which creates an unencumbered
> specific-valued TXO that can be arbitrarily spent with your online keyset)
> then you cannot get another "batch" of funds until the `nSequence` relative
> locktime passes.
> However, this *does* implement a window that limits a maximum value
> spendable per any window of the relative timelock you select.
>
> The disadvantage is that `nSequence` use is a lot more obvious and
> discernible than `nLockTime` use.
> Many wallets today use non-zero `nLockTime` for anti-fee-sniping, and that
> is a good cover for `nLockTime` transactions.
> I believe Dave Harding proposed that wallets should also use, at random,
> (say 50-50) `nSequence`-in-relative-locktime-mode as an alternate
> anti-fee-sniping mechanism.
> This alternate anti-fee-sniping would help cover `nSequence` use.
>
> Note that my proposal does impose a maximum limit on the number of windows.
> With `nSequence`-in-relative-locktime-mode the limit is the number of
> times that the online keyset can spend.
> After spending that many windows, the offline keyset has to be put back
> online to generate a new set of transactions.
>
> It has the massive massive advantage that you can implement it today
> without any consensus change, and I think you can expect that consensus
> change will take a LONG time (xref SegWit, Taproot).
>
> Certainly the functionality is desirable.
> But it seems it can be implemented with Bitcoin today.
>
> Regards,
> ZmnSCPxj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210816/298ee64f/attachment.html>;