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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
