Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

2021-08-16 Thread Zac Greenwood via bitcoin-dev
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  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 

Re: [bitcoin-dev] Exploring: limiting transaction output amount as a function of total input value

2021-08-16 Thread ZmnSCPxj via bitcoin-dev
Good morning Zac,

> 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.

Correct, that is indeed a weakness.

It is helpful to see https://zmnscpxj.github.io/bitcoin/unchained.html
Basically: any quorum of signers can impose any rules that are not 
implementable on the base layer, including the rules you desire.
That quorum is the "offline keyset" in my proposal.

>
> 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.

No.
Remember, the output is a simple 1-of-1 or k-of-n of the online keyset.
The online keyset can spend that wherever and however, including paying it out 
to N parties, or paying part of the limit to 1 party and then paying the 
remainder back to the same onchain keyset so it can access the funds in the 
future.
Both cases are also available in your proposal, and the latter case (pay out 
part of the limit to a single output, then keep the rest back to the same 
onchain keyset) can be used to add an indefinite number of transactions per 
window.

>
> Number of windows: limited in your proposal, unlimited in mine.

Correct, though you can always have a fairly large number of windows ("640kB 
ought to be enough for anybody").

>
> There are probably additional gaps that I am currently not technically able 
> to recognize.

It requires a fair amount of storage for the signatures at minimum, though that 
may be as small as 64 bytes per window.
1Mb of storage for signatures would allow 16,384 windows, assuming you use 
1-day windows that is about 44.88 years, probably more than enough that a 
one-time onlining of the offline keys (or just print out the signatures on 
paper or display as a QR code, whatever) is acceptable.

> 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.

See above, particularly the gap that does not, in fact, exist.

>
> 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.

You can also look into the "covenant" opcodes (`OP_CHECKSIGFROMSTACK`, 
`OP_CHECKTEMPLATEVERIFY`, etc.), I think JeremyRubin has a bunch of them listed 
somewhere, which may be used to implement something similar without requiring 
presigning.

Since the basic "just use `nSequence`" scheme already implements what you need, 
what the covenant opcodes buy you is that you do not need the offline keyset to 
be onlined and there is no need to keep signatures, removing the remaining gaps 
you identified.
With a proper looping covenant opcode, there is also no limit on the number of 
windows.

The issue with the covenant opcodes is that there are several proposals with 
overlapping abilities and different tradeoffs.
This is the sort of thing that invites bikeshed-painting.

I suggest looking into the covenant opcodes and supporting those instead of 
your own proposal, as your application is very close to one of the motivating 
examples for covenants in the first place.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

2021-08-16 Thread ZmnSCPxj via bitcoin-dev
Good morning TS,

> Entering a BTC address for a transaction can pose a risk of error (human or 
> technical). While
> there is a checksum integrated in BTC addresses already, this is used only at 
> a technical
> level and does not avoid entering a valid but otherwise wrong address. 
> Moreover, it does not
> improve the overall user experience.
>
> In case this hasn't been discussed before, I propose to implement a 3 or 4 
> digit code (lets
> call it 4DC for this text), generated as checksum from the address. This 4DC 
> should be shown
> in all wallets next to the receiving address. When entering a new address to 
> send BTC, the
> sending wallet should also show the 4DC next to the entered address. This 
> way, the sending
> person can easily verify that the resulting 4DC matches the one from the 
> receiving address.
>
> This would mean that a receiver would not only send his public address to the 
> sender, but also
> the 4DC. A minor disadvantage since a) it is not mandatory and b) it is very 
> easy to do.
> However, it would greatly reduce the probability of performing transactions 
> to a wrong address.
>
> Technically, this is very easy to implement. The only effort needed is 
> agreeing on a checksum
> standard to generate the code. Once the standard is established, all wallet 
> and exchange
> developers can start implementing this.

I think the "only" effort here is going to be the main bulk of the effort, and 
it will still take years of agreement (or sipa doing it, because every review 
is "either sipa made it, or we have to check *everything* in detail for several 
months to make sure it is correct").

In any case --- the last 5 characters of a bech32 string are already a 
human-readable 5-digit code, with fairly good properties, why is it not usable 
for this case?

On the other side of the coin, if you say "the existing bech32 checksum is 
automatically checked by the software", why is forcing something to be manually 
checked by a human better than leaving the checking to software?


Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

2021-08-16 Thread ts via bitcoin-dev
Entering a BTC address for a transaction can pose a risk of error (human or technical). While 
there is a checksum integrated in BTC addresses already, this is used only at a technical 
level and does not avoid entering a valid but otherwise wrong address. Moreover, it does not 
improve the overall user experience.


In case this hasn't been discussed before, I propose to implement a 3 or 4 digit code (lets 
call it 4DC for this text), generated as checksum from the address. This 4DC should be shown 
in all wallets next to the receiving address. When entering a new address to send BTC, the 
sending wallet should also show the 4DC next to the entered address. This way, the sending 
person can easily verify that the resulting 4DC matches the one from the receiving address.


This would mean that a receiver would not only send his public address to the sender, but also 
the 4DC. A minor disadvantage since a) it is not mandatory and b) it is very easy to do. 
However, it would greatly reduce the probability of performing transactions to a wrong address.


Technically, this is very easy to implement. The only effort needed is agreeing on a checksum 
standard to generate the code. Once the standard is established, all wallet and exchange 
developers can start implementing this.


Agreeing on a good name for this code would be helpful for a fast adoption (human readable 
checksum, verification code or 4DC are just examples).


Obviously, this solution could be used for all other coins/networks. But ideally, each of them 
should have its own checksum algorithm, in order to further avoid sending funds to the wrong 
network. Especially when the address standard is the same like it is the case with BTC and BCH.


Hopefully, Bitcoin can implement this first and serve as example-to-follow to other 
coins/networks.


Cheers,
TS
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev