Re: [bitcoin-dev] Future of the bitcoin-dev mailing list

[Ali Sherief via bitcoin-dev]

I find Google Groups especially repugnant not not only because what has already 
been mentioned, but Google Groups has a quite clunky and annoying user 
interface that makes it difficult for me to find anything or interest in there.

Usenet was migrated to Google Groups for some reason, and it's very difficult 
to search for anything of particular interest using that site.

Not to mention that Google Groups also contains a larger amount of spam (w.r.t 
value), so arguably the moderation burden will be higher.

It is necessary to try to find a way to keep the discussion on a mail server, 
since a migration off of it will render many users' email clients useless for 
this purpose.

- Ali

> On Mon, 13 Nov 2023 18:51:26 +, alicexbt  wrote:
>
> Hi Overthefalls,
>
> +1
>
> Using google for bitcoin mailing list is not good. It feels embarrassing that 
> some developers that built and maintained the only decentralized network used 
> to settle uncensored payments and some of them even working on nostr, can't 
> build their own mailing list which is better than present mailing list. I 
> have some ideas but it seems the influential developers have already decided 
> and wont accept anything.
>
> Nostr can be used to build a mailing list which also allows anyone to send 
> emails apart from publishing events from different clients. We just need a 
> new NIP so that nostr relays understand its a different event. There can be 
> multiple front end with different levels of moderation to hide some emails 
> and ultimately one will be used the most. It can use multiple relays and 
> relays share some information in NIP 11 which can include an email address.
>
> /dev/fd0
> floppy disk guy
>
> Sent with Proton Mail secure email.
>
> On Monday, November 13th, 2023 at 8:35 PM, Overthefalls via bitcoin-dev 
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > On Tue, 2023-11-07 at 09:37 -0600, Bryan Bishop via bitcoin-dev wrote:
> >
> > > Google Groups is another interesting option,
> >
> > I don't think I'm the only person on this list that is strongly opposed to 
> > using google for anything. They are too big and they have their hand in 
> > everything, and their eyes (and analytics) on everything.
> >
> > I remember when there were virtually no gmail email addresses that posted 
> > to this list. Suddenly in 2020 or 2021, we had an influx of gmail 
> > subscribers and posters. That didn't escape me then and it is not lost on 
> > me now.
> >
> > Email is great for public discussion for many reasons. The fact that 
> > everyone gets a copy of the data, there is no single central authority that 
> > can edit emails once they have been sent out. Anyone can archive email 
> > messages, they can generally store or publish the data anywhere they like. 
> > That is not the case with web forum content.
> >
> > I like the lightning anti-spam fee idea. That would encourage me to finally 
> > adopt lightning, and it would, I'm sure, produce some interesting results 
> > for the list.
> >
> > I don't think email should be out of the question. Does anyone besides 
> > kanz...@gmail.com think that sticking with email is out of the question?
> >
> > Let's do what's necessary to stick with email.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Encrypted (like BIP38) master private key

[Ali Sherief via bitcoin-dev]

Just like we have BIPP38 encrypted keys for singular private keys, I was 
wondering if it would be possible to come up with a way to encrypt an extended 
private key using reversible encryption.

BIP38 was designed with physical coins in mind, and in particular covers the 
cases for lot and sequence numbers in detail.

There is a case to be made that in an encrypted extended private key, the lot 
and sequence numbers can be placed in the HD derivation path. In particular 
they can be derived like this: m/lot'/sequence' and both of them use hardened 
derivation.

The advantage would be that coinmakers would only have to generate one master 
private key during manufacturing instead of a ton of private keys.

But this is not a very convincing advantage so I'd like to hear what is other 
people's take on this.

-Ali___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution

[Ali Sherief via bitcoin-dev]

Burak, I don't remember if this has been mentioned previously in the 
conversation about Ark, but a disadvantage in the protocol as it is currently 
is that "Ark require users to come online and "refresh" their coins every few 
weeks, otherwise the ASP can sweep the funds." (putting that in quotes because 
although I copied this from a forum, it may have originally been said on this 
list.)

However, yesterday I have come up with a scheme to mitigate this disadvantage, 
in a way that works similar to LN watchtowers.

This watchtower program for Ark would be made that runs on an 
internet-connected server and inputs your wallet password and the date in the 
future to perform the refreshing. A child process can then be spawned that acts 
similar to a cronjob, and stores the wallet password with AES encryption in 
memory.

The key to this cipher is the time stored in ISO 8601 format as a byte string. 
It is promptly discarded from memory.

Every second, the watchtower child process will attempt to decrypt the cipher 
using the current ISO 8601 time looking like "-mm-ddTHH:MM:SSZ" as the key.

Naturally this will only succeed at the requisite time at which the wallet is 
to be unlocked by the watchtower child process - following which the coins 
inside the ASP are refreshed, and the watchtower child process is terminated 
and the encrypted wallet password destroyed.

Of course, memory scrubbing should be applied to the region that has the 
decrypted wallet password.
If at any point the user comes online by themselves, they can simply cancel the 
watchtower refreshing task, which will terminate the watchtower child process 
without opening your wallet and refreshing coins.

The key feature is that nobody will be able to decrypt the wallet password 
unless they know the exact time it is to be unlocked as an ISO 8601 string. It 
cannot be unlocked at any time in the future, just at that particular instant, 
as long as the key is discarded and the software randomly guesses the 
decryption by attempting each second the new time as the encryption key. Even 
if the watchtower is hacked after the task has been made, the hacker still 
won't be able to decrypt the wallet password unless they brute-force the 
encryption key by exhaustively trying all timestamps in the future.

Alternatively, instead of encrypting the wallet password, it can encrypt a 
signed transaction which is used by Ark to refresh the coins. In this case, the 
wallet password would still need to be collected, but only for the purpose of 
signing the transaction, after which the password is promptly erased from 
memory.

How this can be extended to repeatedly arming the watchtower program with 
refreshes remains to be seen, but using the wallet password as the encryption 
directly is one option albeit not a secure one A better and more secure option 
would be to take note of the UTXOs created by the coin refreshing transaction, 
use those as inputs to a second refreshing transaction that is created 
immediately after the first one, sign it, and similarly create a third, fourth, 
etc. as many as are desirable for the user. Then every 4 weeks, one of these 
transactions can be broadcasted, in the order that they were created obviously.

Looking forward to your feedback on this.
-Ali___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving Second Layer Solution

[Ali Sherief via bitcoin-dev]

Regarding this:

> Users are not so well protected during reorgs, e.g. if Bob double-spends
> a transaction whose funds were later used in a payment to Carol, then
> Carol loses the money. For this reason, Alice will probably want to
> prove to users that no funds they receive in a payment derive from any
> deposit less than safe_confirmation_depth blocks.

I'm of the opinion that any L2 protocol having a similar concept of block 
mining but for L2 transactions is a pretty good idea, but the reorgs trapdoor 
you mentioned could theoretically be mitigated ARK nodes considering their 
settling transactions on L1 as final after say, 3 blocks, or maybe even 6 
blocks.

I'm leaning towards the standard 6 blocks, as this delay is invisible to users 
anyway, and only node operators will really notice it.

It is kind of the same way how miners can't spend coinbase transactions for 100 
blocks.

It's a pretty good idea from Burak though, and I can't wait to see nodes in 
action with this.

- Ali

> Hi Burak,
> 
> Thanks for this really interesting protocol! I tend to analyze
> complicated ideas like this by writing about them in my own words, so
> I've pasted my summary of your idea to the end of this email in case
> it's useful, either to other people or to you in helping understand my
> one concern.
> 
> My concern is the same one I think Olaoluwa Osuntokun mentioned on
> Twitter[1] and (less clear to me) might be related to ZmnSCPxj's
> concern[2]:
> 
> It seems to me that receiving a payment on the protocol, including
> conditional payments using HTLC, PTLC, or Anchor-TLC, requires waiting
> for the transaction containing that payment to confirm to a sufficient
> depth (e.g., I'd wait 6 blocks for small payments and longer for huge
> payments). Am I missing something?
> 
> My summary of how I think that part of the protocol works is in the
> sections labeled "Make an unconditioned payment" and "Make a conditional
> payment" below. In short, it's clear to me how the service provider and
> the customer can make instant atomic swaps with each other---they can
> either spend instantly cooperatively, or they have to wait for a
> timeout. But how can a receiver of funds be assured that they will
> actually get those funds unless there's already a timelock and
> cooperative spend path placed on those funds?
> 
> -Dave
> 
> Rough initial summary of Ark protocol:
> 
> Alice runs an Ark service provider. Every 5 seconds, she broadcasts a
> new unconfirmed onchain transaction that pays three outputs (the
> three Cs):
> 
> 1. Change Output: money not used for the other two Cs that gets sent
> back to the the transaction creator.
> 
> 2. Connector Output: an output that will be used in a future
> transaction created by Alice as protection against double spends.
> 
> 3. Commitment Output: a CTV-style commitment to a set of outputs that
> can be published later in a descendant transaction (alternatively,
> the commitment output may be spent unilaterally by Alice after 4
> weeks).
> 
> Bob wants to deposit 1 BTC with Alice. He sends her an unsigned PSBT
> with an input of his and a change output. She updates the PSBT with a
> commitment output that refunds Bob the 1 BTC and a connector output with
> some minimum value. They both sign the PBST and it is broadcast. We'll
> ignore fees in our examples, both onchain transaction fees and fees paid
> to Alice.
> 
> From here, there are several things that Bob can do:
> 
> - Unilaterally withdraw: Bob can spend from the commitment output to
> put his refund onchain. The refund can only be spent after a 24-hour
> time delay, allowing Bob to optionally come to an agreement with Alice
> about how to spend the funds before Bob can spend them unilaterally
> (as we'll see in a moment). For example, the script might be[3]:
> 
> pk(B) && (older(1 day) || pk(A))
> 
> - Collaboratively withdraw: as seen above, Bob has the ability to come
> to a trustless agreement with Alice about how to spend his funds.
> They can use that ability to allow Bob to trade his (unpublished) UTXO
> for a UTXO that Alice funds and broadcasts. For example:
> 
> - Alice creates an unsigned PSBT that uses as one of its inputs the
> connector from Bob's deposit transaction. This will ensure that
> any attempt by Bob to double-spend his deposit transaction will
> invalidate this withdrawal transaction, preventing Bob from being
> able to steal any of Alice's funds.
> 
> Also included in Alice's unsigned PSBT is another connector
> output plus the output that pays Bob his 1 BTC.
> 
> - Bob receives Alice's unsigned PSBT and creates a separate PSBT
> that includes his unpublished UTXO as an input, giving its value
> to Alice in an output. The PSBT also includes as an input the
> connector output from Alice's PSBT. This will ensure that any
> attempt by Alice to double spend her transaction paying him will
> invalidate his transaction paying her.
> 
> - Bob signs his PSBT and gives it to Alice. After verifying it,
> Alice 

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Ali Sherief via bitcoin-dev]

Hey guys,

I'm more of the opinion that if this particular format the spam transactions 
are using is addressed, it will not only cause the mempool to relax, but it 
will also give us time to regroup and work on Layer 2 before the next onslaught 
of spam transactions using a (slightly) different format begins.

-Ali

On Tue, May 9, 2023 at 3:02 AM, Peter Todd  wrote:

> On Mon, May 08, 2023 at 06:37:34PM -0400, Luke Dashjr via bitcoin-dev wrote:
>> Action should have been taken months ago. Spam filtration has been a
>> standard part of Bitcoin Core since day 1. It's a mistake that the existing
>> filters weren't extended to Taproot transactions. We can address that, or
>> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does).
>> Since this is a bugfix, it doesn't really even need to wait for a major
>> release.
>
> Miners are making millions of dollars from these inscription transactions.
> Miners can and do run their own nodes and interconnect to each other. Many
> people like myself will continue to run nodes that do not attempt to block
> inscriptions. And of course, the current flood of BRC-20 transactions embed
> very little data in the chain per transaction and could easily be adapted to
> use OP_RETURN or any number of other data embedding schemes; if they were
> modified to embed no data at all they wouldn't be much smaller, and I'm sure
> you'd still be complaining that they were spam.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Ali Sherief via bitcoin-dev]

I think one of the bigger problems facing the broader Bitcoin ecosystem is the 
lack of Lightning wallets for desktop. Mobile wallets are not really an issue, 
but as far as I know for desktop builds, there's really only Electrum, and Zap 
Wallet which support Lightning.

The alternative is interacting with the LN node directly, which probably won't 
be so bad, but it would be better if they carried GUI wallets like BItcoin Core 
does. Because windows and buttons help with mass adoption of pretty much 
everything.

I may even consider developing a Lighting wallet given the circumstances.

-Ali

On Mon, May 8, 2023 at 8:13 PM, Michael Folkson  
wrote:

>> probably easier just to reject any transaction where the fee is higher than 
>> the sum of the outputs
>
> And prevent perfectly reasonable transfers of value and attempted Lightning 
> channel closes during fee spikes? If I want​ to close my Lightning channel 
> during a protracted fee spike where I have to pay an onchain transaction fee 
> greater than the amount I am receiving you want to stop me doing that? You 
> are impinging on a valid use case as well as requiring a consensus rule 
> change.
>
> --
> Michael Folkson
> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> --- Original Message ---
> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev 
>  wrote:
>
>> probably easier just to reject any transaction where the fee is higher than 
>> the sum of the outputs
>>
>> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev 
>>  wrote:
>>
>>> Hi guys,
>>>
>>> I think everyone on this list knows what has happened to the Bitcoin 
>>> mempool during the past 96 hours. Due to side projects such as BRC-20 
>>> having such a high volume, real bitcoin transactions are being priced out 
>>> and that is what is causing the massive congestion that has arguable not 
>>> been seen since December 2017. I do not count the March 2021 congestion 
>>> because that was only with 1-5sat/vbyte.
>>>
>>> Such justifiably worthless ("worthless" is not even my word - that's how 
>>> its creator described them[1]) tokens threaten the smooth and normal use of 
>>> the Bitcoin network as a peer-to-pear digital currency, as it was intended 
>>> to be used as.
>>>
>>> If the volume does not die down over the next few weeks, should we take an 
>>> action? The bitcoin network is a triumvirate of developers, miners, and 
>>> users. Considering that miners are largely the entities at fault for 
>>> allowing the system to be abused like this, the harmony of Bitcoin 
>>> transactions is being disrupted right now. Although this community has a 
>>> strong history of not putting its fingers into pies unless absolutely 
>>> necessary - an example being during the block size wars and Segwit - should 
>>> similar action be taken now, in the form of i) BIPs and/or ii) commits into 
>>> the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which 
>>> defines the validation rules for Taproot scripts) which has allowed these 
>>> unintended consequences?
>>>
>>> An alternative would be to enforce this "censorship" at the node level and 
>>> introduce a run-time option to instantly prune all non-standard Taproot 
>>> transactions. This will be easier to implement, but won't hit the road 
>>> until minimum next release.
>>>
>>> I know that some people will have their criticisms about this, 
>>> absolutists/libertarians/maximum-freedom advocates, which is fine, but we 
>>> need to find a solution for this that fits everyone's common ground. We 
>>> indirectly allowed this to happen, which previously wasn't possible before. 
>>> So we also have a responsibility to do something to ensure that this kind 
>>> of congestion can never happen again using Taproot.
>>>
>>> -Ali
>>>
>>> ---
>>>
>>> [1]: 
>>> [https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/](https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp)
>>>
>>> ___
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Ali Sherief via bitcoin-dev]

Hi guys,

I think everyone on this list knows what has happened to the Bitcoin mempool 
during the past 96 hours. Due to side projects such as BRC-20 having such a 
high volume, real bitcoin transactions are being priced out and that is what is 
causing the massive congestion that has arguable not been seen since December 
2017. I do not count the March 2021 congestion because that was only with 
1-5sat/vbyte.

Such justifiably worthless ("worthless" is not even my word - that's how its 
creator described them[1]) tokens threaten the smooth and normal use of the 
Bitcoin network as a peer-to-pear digital currency, as it was intended to be 
used as.

If the volume does not die down over the next few weeks, should we take an 
action? The bitcoin network is a triumvirate of developers, miners, and users. 
Considering that miners are largely the entities at fault for allowing the 
system to be abused like this, the harmony of Bitcoin transactions is being 
disrupted right now. Although this community has a strong history of not 
putting its fingers into pies unless absolutely necessary - an example being 
during the block size wars and Segwit - should similar action be taken now, in 
the form of i) BIPs and/or ii) commits into the Bitcoin Core codebase, to 
curtail the loophole in BIP 342 (which defines the validation rules for Taproot 
scripts) which has allowed these unintended consequences?

An alternative would be to enforce this "censorship" at the node level and 
introduce a run-time option to instantly prune all non-standard Taproot 
transactions. This will be easier to implement, but won't hit the road until 
minimum next release.

I know that some people will have their criticisms about this, 
absolutists/libertarians/maximum-freedom advocates, which is fine, but we need 
to find a solution for this that fits everyone's common ground. We indirectly 
allowed this to happen, which previously wasn't possible before. So we also 
have a responsibility to do something to ensure that this kind of congestion 
can never happen again using Taproot.

-Ali

---

[1]: 
[https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/](https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp)___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Transcript: Online Socratic on MuSig2

[Ali Sherief via bitcoin-dev]

Hi Michael.

I read the transcript of the Socratic and I have to say that it is quite 
detailed and touches a lot of problems including the well-known theft/offline 
problems which also has forms elsewhere such as for passwords.

My question is, do you or anyone else in the Socratic know of any research to 
this that's don't involve a trade-off of theft or online connectivity?

ROAST and Liquid is perhaps the farthest I know of that addresses this problem, 
but it's using centralized nodes right now. I was thinking, maybe these 
federated nodes can be decentralized into a few of these "lite nodes" managed 
by each service wanting a payment, that make a threshold signature out of many 
subscribers paying at the same time.

- Ali___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Multipayment Channels - A scalability solution for Layer 1

[Ali Sherief via bitcoin-dev]

Over the past few days I've figured out a novel way to batch transactions 
together into blocks, thereby compacting the transaction size and increasing 
the transactions-per-second. This is all on layer 1, without any hardforks - 
only a single softfork is required to add MuSig1 support for individual invoice 
addresses.

The nucleus of the idea was born after a discussion with Greg Maxwell about a 
different BIP (Implementing multisig using Taproot, to be specific)[1]. He 
suggested to me that I should add MuSig1 signatures into the Taproot script 
paths.

After some thinking, I realized a use case for MuSig1 signatures as a kind of 
on-chain Lightning Network. Allow me to explain:

LN is very attractive to users because it keeps intermediate transaction states 
off-chain, and only broadcasts the final state. But without mitigations in the 
protocol, it suffers from two disadvantages:

- You have to trust the other channel partner not to broadcast a previous state
- You also have to trust all the middlemen in intermediate channels not to do 
the above.

Most of us probably know that many mitigations have been created for this 
problem, e.g. penalty transactions. But what if it were possible to create a 
scheme where so-called technical fraud is not possible? That is what I'm going 
to demonstrate here.

My scheme makes use of MuSig1, OP_CHECKLOCKTIMEVERIFY (OP_CLTV) timelock type, 
and negligible OP_RETURN data. It revolves around constructs I call 
"multipayment channels", called so because they allow multiple people to pay in 
one transaction - something that is already possible BTW, but with much larger 
tx size (for large number of cosigners) than when using MuSig1. These have the 
advantage over LN channels that the intermediate state is also on the 
blockchain, but it's very compact.

A channel consists of a fixed amount of people N. These people open a channel 
by creating a (optionally Taproot) address with the following script:
* OP_CTLV OP_DROP  
OP_CHECKMUSIG**

Simultaneously, each of the N participants receives the N signatures and 
constructs the N-of-N MuSig. Each participant will use this MuSig to generate 
his own independent "commitment transaction" with the following properties:

- It has a single input, the MuSig output. It has an nSequence of 
desiredwaitingblocks. 
- It has outputs corresponding to the addresses and balances of each of the 
participants in the agreed-upon distribution.
Disadvantage: Because the N-of-N signature is given to all participants, it 
might be leaked into the public and consequentially anybody can spend this 
transaction after the timelock, to commit the balance.*** On the other hand, 
removing the timelocks means that if one of the participants goes missing, all 
funds are locked forever.

A second output with a script OP_RETURN <32-byte connection ID> can be added to 
the transaction to enable L1 channel discovery.

Full nodes parsing the blockchain can maintain a list of connection IDs to 
connect to (but without a non-malleable refund transaction, nobody is going to 
use this). SPVs can simply export a list of them from Full Nodes.

A connection only lasts for one transaction. Spending the output to another 
MuSig of the above format will create a new connection if it spends to a 
similarly-constructed MuSig output with different signature. In all cases, the 
current connection is destroyed.

*This introduces a variable grace period, in blocks, after which anybody can 
broadcast this transaction to commit the channel funds distribution to each of 
the participants' addresses. blockheightofoutput is the block height of the 
musig output, and desiredwaitingblocks is the maximum number of blocks the 
connection can stay alive for.
**This implies that a hypothetical OP_CHECKMUSIG would take a single aggregated 
signature, a single aggregated public key, and an integer N that denotes how 
many public keys were combined together. I elected not to overload OP_CHECKSIG 
since MuSig and regular signatures are both valid for the same address types. 
This part is a rought draft and requires lots of work on making an 
OP_CHECKMUSIG opcode that satisfies the requirements of multipayment channels.
***This is quite a bad flaw of this scheme because it means that all the 
participants must be trustworthy - you can't use this in trustless 
environments. I appreciate any ways on how to implement non-malleable refund 
transactions with single (non-aggregated) signatures!
Perhaps the best solution is to offer both alternatives:  
OP_CHECKMUSIG in a public scenario where none of the participants want to face 
the prospect of losing their money, and 
* OP_CTLV OP_DROP  
OP_CHECKMUSIG with signature sharing in private scenarios.

This draft is very crude and parts have not been fully developed. Tips for 
fleshing it out is much appreciated. Not that there's anything wrong with LN 
for that matter, I'm just concerned about the security reprocussions of not 

Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format

[Ali Sherief via bitcoin-dev]

> I am attempting to achieve two goals with this proposal, primarily for the
> benefit of wallet users:
>
> Goal #1. Transfer labels between different wallet implementations
> Goal #2. Manage labels in applications outside of Bitcoin wallets (such as
> Excel)
>
> Much of the feedback so far has indicated the tension between these two
> goals - it may be that it is too difficult to achieve both, in which case
> Goal #1 is the most important. That said, I think further exploration is
> still necessary before abandoning Goal #2, because removing it would
> significantly reduce the value of this proposal and mean users need to rely
> on application-specific workarounds.
In my opinion, it would be best if these two goals were split into two separate 
BIPs where the BIP for Goal 2 requires Goal 1's BIP, gut Goal 1's BIP is 
independent. This is because wallet software and business spreadsheet processes 
have different and in some cases divergent needs.

A BIP shouldn't try to address too many things at once, that's why technologies 
like Segwit and Taproot were split into four or five BIPs each.

>  > Don't mandate the file extension... There is no way to enforce this on a
> BIP level.
> I'm not quite sure what you mean here - for example BIP174, which is widely
> used, states "Binary PSBT files should use the .psbt file extension." Also,
> this contradicts Goal #2 - Excel and Numbers register as handlers for .csv,
> and so make it clear that the file is editable outside of a wallet.
BIP174's assignment is a specification but not a hard requirement, becase if 
you have a file whose extension implies one type, but its MIME type (obtained 
from inspecting the file contents) indicates another type, then the extension 
should be disregarded by the parser.

I am aware that business processes are mostly CSV file oriented so you can make 
a statement akin to BIP174 in the Goal 2 BIP, that expects the medium of 
exchange to be in files ending in .csv. I wouldn't mind if you require .csv 
file extension in a BIP for Goal 2. But such a statement is not appropriate in 
the Goal 1 BIP which is only concerned with the wallet label format itself.

> > ZIP does not have good performance or compression ratio
> Indeed, but it is very widely available. That said, gzip is supported
> widely too these days. Unfortunately, gzip does not offer encryption (see
> next answer).
>
> > ZIP is an archiving format, that happens to have its own compression
> format.
> I agree this is not ideal. My main reason for choosing ZIP was that it
> supports encryption. It seems to me that without considering encryption, an
> application must create label export files that allow privacy-sensitive
> wallet information to be readable in plain text. Being able to transfer
> labels without risking privacy is IMO valuable. I considered other
> encryption formats such as PGP, but they are much more niche and so again
> contradict Goal #2.
Both of these look like parts of the spec that should be in the Goal 2 BIP. 
Because Goal 1, which is only concerned with wallet label importing, does not 
need to interact with compression or encryption.

I don't mind if you make Goal 2 BIP utilize ZIP compression with optional 
encryption, it's just that specifying this in the same place in the Goal 1 BIP 
stuff forces wallets to check for that stuff too to be compliant. It's 
important to make compliance as easy as possible.

Regardless, I still believe that making the xpub the ZIP password is a bad 
design, because some wallets that are made from a random list of private keys 
do not have xpubs at all. If the purpose of a password is to make label sharing 
between two parties secure, then why not simply let them agree on a password 
for their own use?

> > I don't see the benefit of encrypting addresses and labels together...
> additionally, the password you propose is insecure - anybody with access to
> the wallet can unlock it
> I'm not sure I understand your question, but both wallet addresses and
> wallet labels contain privacy-sensitive information that should be
> protected. Wrt to the password, there is actually a more fundamental
> problem with using the wallet xpub - there is no equivalent for multisig
> wallets. For this reason I'll remove that requirement in future iterations.
Let me explain.

Before you partitioned the BIP into two goals, I was under the impression that 
wallets would have to read an encrypted export file, which seemed very overkill 
to me (for one, all wallets would now need to bundle a ZIP or AES dependency 
module with their program).

But now I see why a password and encryption would be desireable for Goal 2 BIP 
applications. Like I said though, Goal 1 BIP applications (i.e. wallets) do not 
need any of that.

> > Why the need for input and output formats? There is no difference between
> them on the wallet level, because they are always identified with a txid
> and output index.
> The input refers to the txid and the input index (in 

Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format

[Ali Sherief via bitcoin-dev]

> This seems to run contrary with your point about letting users be in
> control of how they store this. Given that you can always connect together
> an output and its address or find the outputs at any address, it doesn't
> seem like it would actually leak any more information than just including
> addresses. Am I missing something?

That's actually true, and coming back to it now it feels more like a 
security-through-obscurity suggestion. It's still valid that the export files 
will be valuable telemetry, but now I'm starting to feel more concerned about 
how inputs and outputs would be represented in the first place.

Some folks have suggested writing them as descriptors for that purpose[1]. But 
I see problems with that approach; there are only descriptors for things like 
addresses, outputs, derivation paths and so on. I know of no descriptors for 
transaction IDs or inputs.

I am actually starting to contemplate whether it's wise to merge Inputs and 
Outputs to one classification conveniently called just "Outputs", because it's 
impossible to distinguish between them by looking at them (any input is also an 
output, but not vice versa). Wise, because I do not know of any wallet software 
that labels outputs.

- Ali

[1]: https://bitcointalk.org/index.php?topic=5411159.0

On Sat, Sat, 27 Aug 2022 16:03:01 -0500, billy.tet...@gmail.com wrote:
> @Ali Thats some good well thought through and well articulated feedback. I
> have one point of contention
>
> > it's important that unnecessary types are kept out of the format. People
> are known to leave files lying around on their computer that they don't
> need anymore, so these files can find their way via telemetry to
> surveillence entities. While we can't specify what users can do with their
> exports, we can control the information leak by preventing certain types of
> items that we know most users will never use from being exported in the
> first place.
>
> This seems to run contrary with your point about letting users be in
> control of how they store this. Given that you can always connect together
> an output and its address or find the outputs at any address, it doesn't
> seem like it would actually leak any more information than just including
> addresses. Am I missing something?
>
> On Wed, Aug 24, 2022, 14:44 Ali Sherief via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > Hi Craig,
> >
> > This a really good proposal. I studied your BIP and I have some feedback
> > on some parts of it.
> >
> > > The first line in the file is a header, and should be ignored on import.
> >
> > From past experience and lessons, most notably BIP39, it is important that
> > a version byte is defined somewhere in case someone wants to extend it in
> > the future, currently there is no version byte which someone can increment
> > if somebody wants to extend it. In the unique case of CSV files, you should
> > make the header line mandatory (I see you have already implied this, but
> > you should make it explicit in the BIP), but instead of a line with columns
> > in it, I suggest instead of Reference,Label, you make the format like this:
> >
> > BIP-wallet-labels,
> >
> > Since there are two columns per record, this works out nicely. The first
> > column can be the name of the BIP - BIP where the x's are numbers, and
> > the second column can be an unsigned 32-bit integer (most significant 8
> > bits reserved for version, the remaining for flags, or perhaps the entirety
> > for version - but I recommend leaving at least some bits for flags, even if
> > they all end up being just "reserved").
> >
> > You should make importing fail if the header line is not exactly as
> > specified - or appropriate, should you decide a different format for the
> > header.
> >
> > > Files exported should use the .csv file extension.
> > Don't mandate the file extension (read below for why):
> >
> > > In order to reduce file size while retaining wide accessibility, the CSV
> > > file may be compressed using the ZIP file format, using the .zip
> > > file extension.
> > I see three problems with this. The first is more important than the later
> > two because it makes them moot points, but I'll mention them anyway so you
> > get a background of the situation:
> > - The BIP is trying to specify in what file format the export format can
> > be written in onto the filesystem. There is no way to enforce this on a BIP
> > level (besides, Unix operating systems don't even consider the file
> > extension, they use its mimetype). Also specifying this in the BIP will
> > prevent modular "Layer 2" pr

Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format

[Ali Sherief via bitcoin-dev]

I think these problems can be mitigated if the CSV format is strictly defined, 
such as how I specified it in my previous message.

In particular, the parser has to recognize only one specific header line that 
has a version number somewhere, or abort - and I still insist on quoting the 
labels with double-quote and introducing a 3rd column with specific string or 
numeric types and then replacing all the special characters in the input/output 
with ":".

Strictly defining CSV version and consequentially, the fields, and then 
specifying on what kind of data the import is supposed to fail at will limit 
the complexity of importers to N different switch cases - where N is the number 
of circulating versions of the format (for now 1).

- Ali

On Thu, Thu, 25 Aug 2022 13:48:36 +, rha...@protonmail.com wrote:
> > Not only is JSON limited to editing only through specific software or text 
> > editors, but (in the latter case) it is fragile enough that a single 
> > missing character can cause an entire file to fail parsing. CSV is more 
> > forgiving in this regard.
>
> I think quite simply: A forgiving format is not appropriate for a standard.
>
> It'd be hard to understate how much extra and pointless effort it creates for 
> everyone, and every implementation ends up creating its own defacto standard 
> for what it produces and accepts. Even doing something as simple as adding an 
> extra column will not be possible in the future because it'll break 
> comparability with previous parsers.
>
> I've literally worked on projects where the csv parser has evolved into 
> scan-ahead to use heuristics to understand "rules" of a csv file, and then do 
> line-by-line heuristics to override those rules in pathological cases. Makes 
> a bit of sense when you're trying to achieve 30 years of backwards 
> compatibility. Doesn't make sense for much else..
>
> If your application users really like csv, then introduce an 
> application-specific import-from-csv and export-to-csv with your own rules.
> -Ryan
>
> --- Original Message ---
> On Thursday, August 25th, 2022 at 1:59 AM, Craig Raw  
> wrote:
>
> > Thanks for your thoughts Ryan.
> >
> > Without reference to the quality feedback on this proposal, I was aware 
> > when submitting it for review that it provides an excellent opportunity for 
> > bike shedding. As developers, we have all experienced frustration with data 
> > formats. One thing that I did not perhaps make clear enough is that this 
> > format is not solely intended for developers, but general users who are 
> > probably not well represented on this list.
> >
> > While doing research for this proposal I spoke to several professional 
> > users of Sparrow Wallet (who are not developers). They all expressed a 
> > desire for the format to integrate with their business processes, which are 
> > driven by business tools such as Excel. Labelling provides an important 
> > function in UTXO and address management in these scenarios, and needs to be 
> > accessible and manageable outside of wallet software.
> >
> > If this is to be achieved, it immediately rules out JSON as a data format. 
> > Not only is JSON limited to editing only through specific software or text 
> > editors, but (in the latter case) it is fragile enough that a single 
> > missing character can cause an entire file to fail parsing. CSV is more 
> > forgiving in this regard. With respect to your comments on escaping, my 
> > expectation would be that developers will be using a mature CSV library 
> > rather than handling character escaping themselves. I would rather propose 
> > a format that is generally usable, even if occasionally a label is escaped 
> > incorrectly.
> >
> > Finally, I'll note that CSV files are already common and uncontroversial in 
> > Bitcoin wallet software. Bitcoin Core, Electrum, Sparrow (and no doubt many 
> > others) already export addresses and/or transactions with their labels as 
> > CSV files. This proposal simply attempts to create a standard for importing 
> > and exporting all the labels in a wallet.
> >
> > Craig
> >
> > On Wed, Aug 24, 2022 at 9:01 PM  wrote:
> >
> >> I'd strongly suggest not using CSV. Especially for a standard. I've worked 
> >> with it as an interchange format many a times, and it's always been a 
> >> clusterfuck.
> >>
> >> Right off the bat, you have stuff like "The fields may be quoted, but this 
> >> is unnecessary as the first comma in the line will always be the 
> >> delimiter" which invariably leads to some implementations doing it, some 
> >> implementations not doing it, and others that are intolerant of the other 
> >> way.
> >>
> >> And you have also made the classic mistake of not strictly defining escape 
> >> rules. So everyone will pick their own (e.g. some will \, escape commas, 
> >> others will not cause it's quoted and escape quotes, and others will 
> >> assume no escaping is required since its the last column in a csv).
> >>
> >> Over time it morphs 

Re: [bitcoin-dev] BIP Proposal: Wallet Labels Export Format

[Ali Sherief via bitcoin-dev]

Hi Craig,

This a really good proposal. I studied your BIP and I have some feedback on 
some parts of it.

> The first line in the file is a header, and should be ignored on import.

>From past experience and lessons, most notably BIP39, it is important that a 
>version byte is defined somewhere in case someone wants to extend it in the 
>future, currently there is no version byte which someone can increment if 
>somebody wants to extend it. In the unique case of CSV files, you should make 
>the header line mandatory (I see you have already implied this, but you should 
>make it explicit in the BIP), but instead of a line with columns in it, I 
>suggest instead of Reference,Label, you make the format like this:

BIP-wallet-labels,

Since there are two columns per record, this works out nicely. The first column 
can be the name of the BIP - BIP where the x's are numbers, and the second 
column can be an unsigned 32-bit integer (most significant 8 bits reserved for 
version, the remaining for flags, or perhaps the entirety for version - but I 
recommend leaving at least some bits for flags, even if they all end up being 
just "reserved").

You should make importing fail if the header line is not exactly as specified - 
or appropriate, should you decide a different format for the header.

> Files exported should use the .csv file extension.
Don't mandate the file extension (read below for why):

> In order to reduce file size while retaining wide accessibility, the CSV
> file may be compressed using the ZIP file format, using the .zip
> file extension.
I see three problems with this. The first is more important than the later two 
because it makes them moot points, but I'll mention them anyway so you get a 
background of the situation:
- The BIP is trying to specify in what file format the export format can be 
written in onto the filesystem. There is no way to enforce this on a BIP level 
(besides, Unix operating systems don't even consider the file extension, they 
use its mimetype). Also specifying this in the BIP will prevent modular "Layer 
2" protocols and schemes from encoding the Export labels into another format - 
for example Base64 or with their own compression algorithm.

Now for the two "moot problems":
- ZIP does not have good performance or compression ratio, there are better 
algorithms out there like gzip (which also happens to be more ubiquitous; 
nearly all websites are serving HTML compressed with gzip compression).
- ZIP is an archiving format, that happens to have its own compression format. 
Archiving format parsers can have serious vulnerabilities in their 
implementation that can allow malware to swipe private keys and passwords, 
since the primary target for this BIP is wallets. For example, there was Zip 
Slip[1] in 2018, which allows for remote code execution. So the malware can 
even hide in memory until private keys or passwords are written to memory, then 
send them accros the network. Assuming it's targeting a specific wallet 
software it's not hard to carry out at all.

There's two solutions for all this:
1. The duck-tape solution: Use some compression algorithm like gzip instead of 
ZIP archive format.
2. The "throw it out and buy a new one" solution: Get rid of the optional 
compression specs altogether, because users are responsible for supplying the 
export labels in the first place, so all the compression stuff is redundant and 
should be left up to the user use if they desire to.

I prefer the second solution because it hits the nail at the problem directly 
instead of putting duck tape on it like the first one.

> This .zip file may optionally be encrypted using either AES-128 or
> AES-256 encryption, which is supported by numerous applications including
> Winzip and 7-zip.
> The textual representation of the wallet's extended public key (as defined
> by BIP32, with an xpub header) should be used as the password.
Not specific to AES, but I don't see the benefit of encrypting addresses and 
labels together. Can you please elaborate why this would be desireable?

Like I said though, it's better to leave it up to users to decide how to store 
their exports, since BIPs can't enforce that anyway (additionally, the password 
you propose is insecure - anybody with access to the wallet can unlock it, 
which is not desireable to some users who want their own security).

> * Transaction ID (txid)
> * Address
> * Input (rendered as txid)
> * Output (rendered as txid>index or txid:index)
Why the need for input and output formats? There is no difference between them 
on the wallet level, because they are always identified with a txid and output 
index. To distinguish between them and hence write them with the correct format 
would require a UTXO set and thus access to a full node, otherwise the CSV 
cannot be verified to be completely well-formed.

Another important point is that practically nobody labels inputs or outputs 
because most people do not know that those things even 

Re: [bitcoin-dev] New Silent Payment version

[Ali Sherief via bitcoin-dev]

Besides, all silent payments are mined at the end of the day, so they are still 
transactions that are included in publicly auditable blocks.

The only thing that changes from the user's point of view is that these 
addresses cannot be heirarchically derived with BIP44 (or any other path for 
that matter). Nobody else can find out the HD paths of an address anyway.

- Ali

On Sun, 21 Aug 2022 22:01:34 +, wo...@protonmail.com wrote:
> The current Silent Payment implementation uses the standard Taproot script 
> (Segwit V1).
>
> This does not in any way affect the consensus or auditability rules.
>
>
>
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Wednesday, August 17th, 2022 at 11:21 PM,  wrote:
>
>
> > Let's be clear, if Bitcoin allows secret payments that cannot be
> > publicly audited then they have exceeded the original consensus that
> > gave Bitcoin fungibility and I will be publicly disavowing Bitcoin and
> > advocating for a full sell down. Why don't you resurrect Monero. -DA.
> >
> > On 2022-08-17 10:08, woltx via bitcoin-dev wrote:
> >
> > > PR #24897 (https://github.com/bitcoin/bitcoin/pull/24897) has been
> > > updated with a new silent payment version, which eliminates some
> > > manual steps from the previous version (such as the need to set the
> > > `keypool` to avoid costly multi-key scan).
> > >
> > > This is achieved by using a new descriptor type ("sp()") that has no
> > > range and contains exactly one key.
> > >
> > > Example: "sp(cQq73sG9JD51uaRD)#9llg6xjm"
> > >
> > > This descriptor introduces a new type of output: "silent-payment".
> > > This output type returns a standard Taproot script (Segwit V1), but
> > > with HRP changed from "bc" to "sp" on the mainnet (or "tsp" on
> > > testnet and signet).
> > >
> > > This output type will always generate the same address (unless another
> > > "sp" descriptor is enabled on the same wallet).
> > >
> > > $ ./src/bitcoin-cli -signet getnewaddress '' 'silent-payment'
> > > tsp1pfmjyl7ecpmx8yf8cu6g3ez36jy7s9mzuh5pdnal3k0n588uzgmfs4s4fws
> > >
> > > To create a silent transaction, simply use the silent payment address
> > > as one of the outputs.
> > >
> > > The "send" RPC will automatically identify and tweak it.
> > >
> > > The transaction can contain multiple outputs, combining silent and
> > > standard addresses.
> > >
> > > I have written a step by step signet tutorial so reviewers can test
> > > this new version easily.
> > >
> > > https://gist.github.com/w0xlt/a7b498ac1ff14b8c292a22be789bd93f

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

Re: [bitcoin-dev] A method for BIP322 signing delegation

[Ali Sherief via bitcoin-dev]

This message relates to an edge case which BIP322 only partially solves, and 
that is Proof of Payment.

When you make a transaction to any business, it keeps the transaction in its 
records and generates an invoice so anyone can verify the transaction took 
place.

When you do a P2P transaction, whether on the blockchain or with paper money, 
there is always the risk that the other party will be dishonest, act in their 
own interest to convince people that they did not receive the transaction. 
Nobody has been able to completely get rid of this.

But in cryptocurrencies, this type of dispute is rampant, because it's also a 
scam attempt, to extract more money from the buyer. Legacy signed message isn't 
even enough to prove the transction took place - they can just claim (falsely) 
the address in the transaction is not theirs.

It usually happens like this:

1. Alice wants to buy something from Bob and sends bitcoins.
2. Bob denies receiving payment.
3. Alice publishes the txid of the transaction.
4. Bob denies that the address in the transaction belongs to him.

BIP322 signed messages only go half-way there: They can prove that the UTXO(s) 
belong to the buyer, and any good block explorer will show you the UTXOs that 
are being spent. So it can be independently established that Alice sent money, 
but not *who* it was sent to. That is where BIP322 falls short - there is no 
mechanism that forces Bob to sign a BIP322 message from the UTXO(s) he has just 
received, before the transaction is complete.

---

What should be done about this situation?

I propose using P2WSH 2-of-2 multisig to solve this problem. The script 
challenge will consist of something like OP_SHA256  OP_EQUAL[1][2]

[1]I don't even know if there is a standalone SHA256 opcode.
[2]OP_CHECKMULTISIG and OP_CHECKSIG both take public keys from the stack in 
addition to signatures, but we have arbitrary byte arrays and their SHA256 
hashes, not public keys and signatures. How can we make this work?

Now on the witness stack, is pushed the BIP322 signature. Both of the 
signatures are then published on the blockchain. The catch is that both of the 
signatures are requires to be supplied

We don't want the signatures to be hidden using Taproot script paths or 
anything because whole point of this scheme is to make it verifiable to the 
public.

But I think that this idea can seriously work out in practice:

- Alice starts a P2P payment with Bob (let's just call this whole scheme "P2P 
payments")
- Alice sends bitcoin to the 2-of-2 multisig address generated by the P2P 
payment.
- Alice signs a BIP322 message from a UTXO (or address, but preferably a UTXO) 
and provides one of the signatures.
- Bob is forced to sign another BIP322 message from his address if he wants his 
money, and provides another signature.
- One of them broadcasts the multisig transaction, and Bob gets his money.

Advantages:
- The signatures in the Multisig transaction are two BIP322 signatures, which 
prove who has control of which inputs.
-- Consequentially, it can be proven who paid who. It is like an invoice, but 
it cannot be doctored like company invoices and databases.

Disadvantages:
- If Bob chickens out at this point, the money in the P2P payment is lost 
forever.
-- So, it is in the buyer's best interest to cooperate, and also in the 
seller's interest, but not particularly the best one - Until Bob provides a 
service, he doesn't lose anything except for time.

What do you guys think about this scheme?

- Ali

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

[bitcoin-dev] [BIP] Implementing Multisig Using Taproot

[Ali Sherief via bitcoin-dev]

Greetings list.

Following the discussions I made about BIP322 delegation on this mailing list 
and in other places, I have decided that that delegation depends on a very 
similar problem that arises when writing contracts and commitments. That 
problem is how to implement private Multisig.

Of course, this can already be done using Taproot. But I doubt that many people 
know how to do it using script paths. BIP342 briefly touches on the subject but 
leaves it open. So I wrote a BIP to plug this hole, that precisely follows the 
guidelines hinted by BIPs 341 and 342, for creating and spending Multisig 
outputs.

I also managed to figure out the formula that BIP342 vaguely hinted at for 
figuring out "cost-effective multisignatures" (hint: it's not quadratic).

As far as I can tell, such a BIP hasn't been advanced before, so there should 
be no problem of "try working on the other BIP".

Use cases:

- Layer 2 protocols that use multisig (e.g. LN, Discrete Log Contracts)
- BIP322 message signatures, if it is decided that UTXO delegation is 
desireable.

I'm pasting the draft of the BIP below, with the metadata shaved off, but 
references are left intact. I haven't uploaded it to Github yet.



== Summary ==

This document defines the proper way to construct Multisig outputs and spends 
that utilize the privacy provided by Taproot script paths.

== Copyright ==

This document is licensed under the 2-clause BSD license.

== Abstract ==

A Multisignature (also called Multisig) unspent transaction output (UTXO) 
attached to an address allows two or more parties to restrict the spending of 
the UTXO inside the address until a specified number of parties sign the output 
spending it. Multisig UTXOs are extremely useful for creating contracts, and is 
therefore used in many applications where delegation of funds to a committee is 
required, such as in Lightning Network channels, in DLCs (Discrete Log 
Contracts), and in other kinds of contracts.

== Motivation ==

OP_CHECKMULTISIG has the disadvantage of revealing all co-signer public keys 
involved in a transaction. This compromises the privacy of those signers. 
Additionally, this construct is not compatible with Taproot because 
OP_CHECKMULTISIG is disabled in TapScript, thus those applications are unable 
to make use of Pay-to-Taproot (P2TR) addresses.

Constructing a Multisig output on Taproot is technically possible, but its 
implementation has not been specified by any existing BIP, to the author's 
knowledge. Additionally, most developers of Bitcoin applications do not know 
how to construct Multisig Taproot outputs.

== Design ==

Taproot gives us three different options for implementing Multisig, each with 
their own advantages and disadvantages'''Multisig implementation options 
reference''' The options were originally enumerated in 
[https://jimmysong.github.io/taproot-multisig Jimmy Song's slideshow] in a more 
detailed manner.:
# Single-leaf with a TapScript implementing K-of-N Multisig. This is 
functionally equivalent to legacy OP_CHECKMULTISIG, and shares all its 
advantages and disadvantages. In particular, all public keys of signers are 
revealed in the TapScript embedded in the first element of the witness program, 
so the privacy advantages of Taproot are compromised.
# Multiple leaves, each with a TapScript implementing K-of-K Multisig.
# Multiple leaves, each with a TapScript implementing MuSig of K keys (i.e. 
aggregate of K public keys).

This document uses the second option for implementing Multisig, because it only 
reveals the public keys of those who sign the transaction.'''Why wasn't 
MuSig considered?''' Although MuSig provides even more privacy by not revealing 
any original public keys all together, it is a cumbersome process to create 
since K parties must be online not only at one point to create the aggregated 
keys, but also at another point to create a signature. There is the problem of 
who will be the trustee of the MuSigs themselves, as opposed to just the 
delegated UTXOs. Also, There is no BIP that implements MuSig, to the author's 
knowledge.

== Specification ==

Notations used here are specified in [[bip-0340.mediawiki#design|BIP340]].

''taproot_output_script'' and ''taproot_sign_script'' refers to the Python 
functions of [[bip-0341.mediawiki|BIP341]] with the same name.

=== Constructing K-of-N Multisig outputs ===

All of the participating TapScripts must be collected together at 
construction-time. This implies that all signers must know each other 
beforehand'''Why should all signers know each other beforehand?''' Knowing 
all possible signers of a multisignature is required for many instances of 
delegation, so that an unknown party cannot insert a rogue signature at 
spending-time..

The algorithm takes as inputs:
* An integer value  ''m'', greater than 0
* An array ''scripts'' of ''m'' TapScripts as byte-arrays.
** The scripts must be written in the following format: "[PubKey p1] 
OP_CHECKSIG [PubKey 

Re: [bitcoin-dev] A method for BIP322 signing delegation

[Ali Sherief via bitcoin-dev]

Since I mailed the original scheme, some people have suggested to me that this 
delegation scheme can be written in TapScript, to avoid revealing the unspent 
public keys. I think that is a good idea.

Here is a very helpful slideshow about implementing Multisig scripts in Taproot 
by Jimmy Song[1] - specifically, I have looked into "Single leaf k-of-n 
multisig" and "Multi-leaf k-of-k multisig". I have not considered the approach 
with MuSig, considering there is not even a BIP for that.

To my understanding, Single leaf k-of-n multisig is functionally identical to 
"Using a single OP_CHECKSIGADD-based script" described in BIP 0342, footnote 5, 
which itself has nearly all of the properties of the original CHECKMULTISIG 
opcode[2]. In other words, it won't hide the non-signing public keys (the 
TapScript is literally " OP_CHECKSIG ...  OP_CHECKSIGADD 
OP_ OP_NUMEQUAL", so it doesn't solve the privacy problem.

That leaves Multi-leaf k-of-k multisig. Now to my understanding, in every 
TapLeaf/Branch, there is going to be a K-of-K TapScript similar to the one 
constructed above. In each leaf there will be a combination of K public keys, 
so the number of leaves is going to be equal to nCr(n,k).

No wonder why BIP 342 says that it's only cost-effective for small values of k, 
because the number of leaves and thus the transaction size swells as k 
increases.

Fortuantely, for the purposes of delegation, K will always be 1, because we 
only utilize 1-n multisig signatures as per my previous message. Thus the fee 
rate will be economical for all values of N i.e. number of delegatees. This 
enables this scheme to have a wider use case than just BIP322 (even here 
though, decreasing the raw transaction size of 'to_sign' is a net positive for 
space reasons).

In other words, every TapScript is just  OP_CHECKSIG OP_1 OP_NUMEQUAL, 
which can be simplified to just  OP_CHECKSIG since OP_CHECKSIG failure 
in a TapScript returns the empty vector (false) on failure, and 1 (true) on 
success. I wrote the longer script merely because it's consistent with the 
script format in [2], but since it's by no means a standardness requirement, we 
can save 2*N bytes in the entire transaction.

So, for small numbers of delegates, these savings are not very eye-watering, 
but if fees become larger then every byte will matter. After all, I envision 
uses for delegation beyond BIP 322 anyway.

At this point, the witness stack of 'to_sign' will have one of these 
TapScripts, and an appropriately constructed BIP 341 control block. Obviously 
'to_spend''s output scriptPubKey will push the SHA256 hash of the witness 
program.

Use cases:
- BIP 322 (obviously)
- Any L2 protocol where participants' funds must be delegated to a comittee 
e.g. LN channels - which, in fact, are still using OP_CHECKMULTISIG.
-- Where such a protocol requires the joint consensus of all participants, such 
as an LN channel closing gracefully, K can be modified appropriately, but this 
is beyond the scope of this scheme. Make a BOLT or the appropriate standard 
proposal if this affects your L2 network.

Advantages where they are relevant for BIP 322 :

- Signature fraud is still impossible to carry out (the entire to_sign 
transaction still has to be verified, but now Address can be empty since the 
public key is in the control block which is in the 'to_sign' witness, and the 
spent TapScript is also in the 'to_sign' witness).
- Delegated signers still use standard address type (Bech32m Taproot addresses).
- No new opcodes are introduced, and no existing ones are redefined so no 
soft-forks are necessary.

Advantages for all applications of this BIP :

- Only the delegatee who actually signs the message has a revealed public key, 
the others' are hidden - a major privacy advantage.
- Signers must be determined beforehand. Jimmy Song actually lists this as a 
disadvantage, but I disagree. For L2 delegation, it is necessary to know the 
other parties to avoid a MITM attack where one of the signers is replaced by a 
rogue signer - through non-cryptographic methods of course (e.g. a computer 
hack).

Disadvantages :

- Taproot is not widely deployed in applications yet?
- I can't think of any others, unless you consider the signer's public key 
being revealed a disadvantage [I wouldn't, because if it were hidden, it would 
defeat the whole purpose of signing by making it vulnerable to the 
aforementioned "signature fraud"].

My grasp on Taproot constructs is not 100%. So feel free to point out any 
errors in my reasoning for this scheme if you spot any.

- Ali

[1] - https://jimmysong.github.io/taproot-multisig
[2] - 
https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_ref-5-0

On Tue Aug 16 04:38:47 UTC 2022, a...@notatether.com wrote:
>(Note: I'm going to stick with this thread for all proposals for BIP322 
>polishing, not just delegation - unless the subject matter changes radically 
>as other people discuss it.)
>
>Instead of the admittingly 

Re: [bitcoin-dev] A method for BIP322 signing delegation

[Ali Sherief via bitcoin-dev]

(Note: I'm going to stick with this thread for all proposals for BIP322 
polishing, not just delegation - unless the subject matter changes radically as 
other people discuss it.)

Instead of the admittingly complicated scheme using transactions, I've created 
one that utilizes multisig to make the possible delegatees known at signing 
time. I had a discussion with vjudeu, garlonicon, and aliashraf about this over 
the past week or so, and while we did not reach a consensus about the solution 
to use, I feel that this scheme requires the least amount of modifications to 
BIP322 draft.

The problem being solved is how to delegate signatures to other scriptPubKeys* 
[sic] for privacy purposes.

*Here, I use P2WPKH addresses, under the assumption that the delegatees are 
people. If the delegatees are just some automated scripts or processes [as was 
mentioned in the BIP], then this scheme is equally valid with P2WSH 
multisignatures with appropriately constructed scriptPubKeys.

What's about to follow was copied almost word-for-word from my forum post with 
extraneous paragraphs removed:

---

It is extremely simple and doesn't require any additional transactions:

- Replace the message challenge of "to_spend" with a 1-of-N standard P2WPKH 
multisig. N is the number of people you want to be able to create the 
signature, and their respective pubkeys are included in the script.
-- In this way the possible delegatees are fixed at signature creation time and 
cannot be extended by creating more transactions.
- Replace the challenge solution in "to_sign" (it's the input that spends the 
output we made in "to_spend") with a witness stack containing: n   
...  1  0
-- The signature is generated as if it were for a real P2WPKH-multisig 
transaction. [the zero at the end is due to a bug in OP_CHECKMULTISIG that pops 
an extra element].

appendix - don't mix up this delegation and Full with UTXOs together - it 
increases the numebr of permutations that implementations have to verify.

Pros:

- No recursive transactions.
- If Alice and Bob are the two delegates of a signature (and one of them sign 
it), Carol does not know any of the private keys or challenge solutions and 
thus cannot claim the script was signed by her [besides the public keys of 
Alice and Bob are already in the signature]. Required, to avoid signature fraud.
- The Address field is not used when delegating, so the engine can actually 
print which (compressed) public key it is signed against - i.e. the address 
verification is provable, as opposed to reactive Legacy signatures.
-- Additionally, they will all be Segwit Bech32 addresses so it can just derive 
and print the corresponding bc1 address instead.
- There is no opcode or new algorithm introduced, so no soft-fork is required.

Cons:

- Everyone knows the public keys of the delegators, so there is no privacy 
[then again, in light of the signature fraud problem, this is possibly a 
non-issue].

---

I'd like to hear everyone's opinions about this.

I don't know who suggested the idea of delegation in the first place, but CCing 
luke-jr because he participated in that Github discussion, so his opinion about 
this scheme will clarify a lot of things about this problem.

- Ali

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

[bitcoin-dev] A method for BIP322 signing delegation

[Ali Sherief via bitcoin-dev]

[A similar message was posted in the Bitcointalk BIP322 thread.]

OK, I just figured out how to solve the delegation problem. It builds on Jeremy 
Rubin's transaction delegation post which I linked to a few days ago.

In BIP322, there is a [planned] provision for some person to delegate signing 
to another person. That means the second person can do all the signing stuff 
that the first person could do, and the signature is as if the first person 
signed it.

What this could be useful for?

- L2/Lightning Network, a channel is just 2-of-2 multisig, so a prospective 
channel co-creator "delegate" signing to the channel itself, by signing a UTXO 
inside the multisig - signing along with the other party, creating a dummy 
output (see below), which can be signed to prove liquidity on behalf of the 
channel, while keeping the channel itself anonymous.
- CoinJoin, To prove that some CoinJoin coordinator is liquid without violating 
its anonymity by revealing public keys, the person managing the CoinJoins 
delegates signing from all UTXOs to be used in the CJ, at once, delegating 
signing to another dummy output.
- By the same token, Mixers can prove their liquidity without revealing their 
UTXO set.
- Silent Payments, where the public key is not even known in the first place, 
the address of a silent payment can delegate signing to another dummy output 
which only the sender and receiver know about.

So how does this delegation work? It's very simple:

1. All UTXOs that want to delegate signing to a different party must sign a 
preliminary transaction of this format:
- All input/output amounts are zero.
- input 1 is an invalid input of the kind in BIP322
- the rest of the inputs are the UTXOs wanting to delegate signing to a 
different party, with valid signatures/witness stacks.
- there is only one output, and it is a P2WSH output with the following script:
OP_PUSH  OP_SWAP OP_HASH160 OP_EQUALVERIFY
- And the witness stack that will "spend" the transaction in the "to_spend" tx 
is simply:

- Likewise, the "to_spend" tx has only one input, refering to the txid of the 
delegating transaction with output point 0 i.e. the UTXO :0. 
Outputs of "to_spend" remain the same.
-- Contrary to the use of Hash160, we are NOT hashing a public key or script. 
We are hashing an address hash, implying that we are using addresses.

Do you know why I said "delegating to a different party"? Because it could be a 
functionally different entity, just like how CEO is diffferent from LLC company 
even if it has only 1 employee. The "address" here represents a kind of company 
 - it can represent a channel, it can represent a 
coinjoin, it can represent a silent payment. The channel/CJ/etc. only has to 
hash the decoded RIPEMD160 of an address, with another SHA256-RIPEMD160, to 
make an "address" that can be used to sign messages from.

This "address" aka. LLC company can even be encoded with Bech32 to make it look 
like a real address - obviously don't send any funds directly to that address 
because they will be lost - and in fact, it *should* be Bech32-encoded when 
transmitting the Signed Message.

A signed message has these three parts:

Message
Address
Signature

BIP322 specifies the signature is just the raw transaction format of "to_sign". 
Normally, the address would simply be the address you are signing from, but in 
the case of delegation, it is desireable for the original addresses to remain 
anonymous. So since an address must be filled in somewhere, the Bech32 
"hash-of-address-hash" created above can be used as a P2WSH address.

Advantages of this scheme:

- The real addresses/UTXOs signing the transaction are only known to each other 
and whoever is managing the "to_delegate" transaction.
- Only the real signers and the person who is in charge of the P2WSH output can 
sign the "to_delegate" output and thus sign a message from it (note that they 
could be the same person).
- There can be an arbitrary number of delegations before the transaction is 
actually signed (the new person who is in charge of signing, i.e. has the P2WSH 
output of the "to_delegate" transaction can simply generate another address 
hash, and delegate to that "address" in another transaction, giving some other 
person that "address" if they want to)
- Delegated signatures can wrap Full and Full with UTXOs signing formats, so 
Light clients do not have to directly support those two formats, either for 
complexity reasons, or because they have no UTXO set.
- And crucially: **There is no on-chain transaction, so the delegation is 
private and cannot be traced back by the public**.

And there are virtually no disadvantages to this.

I should emphasize that you don't delegate signing to another person, you 
delegate signing to another party that may just be comprised by one person. I 
say this because the delegation does not make any new on-chain UTXOs that 
someone could posess, but it simply creates a hash160 of some address hash that 
was generated by 

Re: [bitcoin-dev] Regarding BIP322 edge cases

[Ali Sherief via bitcoin-dev]

Earlier last year on March, there was a post here by Jeremy Rubin that explains 
how a person could delegate its UTXO to some script, by (AFAICT) creating a new 
transaction using that UTXO, with whatever script you want it to have.

It was written in terms of normal transactions, but can be extended to message 
signing transactions too.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018615.html

Only the beginning of the post is relevant here.

- Ali

On Wed, Aug 10, 2022 at 11:11:10PM +, Ryan Grant wrote:
> >> TODO: A way for the initial signer to delegate to another
> >> scriptPubKey; needed for better privacy and CoinJoin/Lightning
> >> compatibility
>
> I need more documentation to understand this motivation.
>
> On Tue, Aug 9, 2022 at 8:46 PM Ali Sherief via bitcoin-dev
>  wrote:
> > In the case of the last TODO, related to delegation to another
> > scriptPubKey, I am not quite sure at the moment what to do about
> > it - perhaps you guys can place a MAST (two Merkle branches, to be
> > specific) - the first branch has the original signer's scriptPubKey,
> > the second branch contains the delegated signer's scriptPubKey.
>
> I don't understand this requirement, but it seems that whatever
> parties are involved can make signatures on the delegating and
> delegated keys.

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

Re: [bitcoin-dev] Regarding BIP322 edge cases

[Ali Sherief via bitcoin-dev]

Wait a minute. I did some lookup on OP_CHECKDATASIG to see if it's in some btc 
BIP draft somewhere, and it is actually an opcode in Bitcoin Cash since some 
years ago - 
https://mengerian.medium.com/the-story-of-op-checkdatasig-c2b1b38e801a

I think we can safely assume that Kalle and the other major BIP322 proponents 
do not have BCH script compatibility on a high prioirty, perhaps not even 
medium prioity, so we should be able to make an opcode called OP_CHECKDATASIG 
for this BIP's internal purposes.

However, a new opcode cannot be created without a lengthy soft-fork (which 
requires miner signalling - but for what use here, this BIP does not directly 
impact miners?) with an activation height. If we want to redefine an existing 
opcode, we must also make a similar soft-fork. Because consensus rules are 
being modified here.

At the same time, a message signing/verifying algorithm using Script must 
implement some way to verify a *single* ECDSA or Schnorr signature that is on 
the stack. The existing opcodes such as OP_CHECKSIG verify all of the inputs 
and outputs, and this won't work here since there's a deliberate invalid iput 
in "to_spend".

I tried to research if there is any known use of OP_RESERVED in a script, even 
if it's only of academic origin, but I unfortunately could not find any 
references except for 
https://bitcoin.stackexchange.com/questions/105778/why-were-op-reserved-op-reserved1-and-op-reserved2-originally-reserved
 .

So this is now an open problem: How should Script verify a single signature 
that is on the stack without touching any of the inputs or outputs?

- Ali

On Wed, Aug 10, 2022 at 05:05:59PM +0200, vju...@gazeta.pl wrote:
> > I suppose in the case of legacy P2PKH signing, a hypothetical 
> > OP_CHECKDATASIG can take   off the stack and perform 
> > an ECDSA public key recovery
>
> You can always perform key recovery for legacy ECDSA: " OP_SWAP 
> OP_CHECKSIG" is always spendable, for any valid  DER-encoded pair. Here, 
> if "   OP_CHECKDATASIG" works for signature 
> verification BIP, then you only need to provide "" as an input, 
> the rest could be placed in some output, and your program could easily 
> compute that. Or you can use "OP_DUP OP_HASH160  OP_EQUALVERIFY 
>  OP_SWAP OP_CHECKDATASIG" as your output script, then the signer 
> has to provide a valid signature, and a valid public key explicitly, but if 
> you only have some signature, then you can always recover that key by 
> yourself.
>
> Because if OP_CHECKDATASIG is not handled, then still, signing by scripts can 
> handle that, but the Script would be unnecessarily complex. And because there 
> is no need to introduce OP_CHECKDATASIG on-chain, it can be safely done 
> inside this BIP.
>
> > I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help 
> > implement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid 
> > instruction.
>
> Because if you want to support any script, and you want to add a new opcode, 
> you have to make it somehow compatible with existing schemes. You have to 
> assign some byte for OP_CHECKDATASIG or for any new opcodes you want to add. 
> And you don't want to assign just the next free opcode, because you will get 
> OP_CHECKSIGADD or other opcodes from TapScript, so your script decoder will 
> no longer handle two script versions at once. Unless you want to make it also 
> compatible with altcoins like BCH, but I guess it is not needed.
>
>
> On 2022-08-10 15:53:31 user Ali Sherief  wrote:
> > > Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to 
> > > be somehow introduced to make it compatible with "Bitcoin Message".
>
> I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATASIG 
> can take   off the stack and perform an ECDSA public 
> key recovery, followed by SHA256/RIPEMD160, kind of like a hybrid between 
> OP_DUP/OP_HASH160/OP_EQUALVERIFY and OP_CHECKSIG.
>
> But the implementations would have to decode the Base58 address into "0x00" 
> plus the address hash. As the only supported invoice type for the Legacy 
> signing methods, this should be straight forward to do.
>
> > And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it 
> > is "conditionally valid transaction".
>
> I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help 
> implement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid 
> instruction.
>
> - Ali
>
> On Wed, 10 Aug 2022 04:59:46 +0200, vju...@gazeta.pl wrote:
> > > I'm not sure what is to be gained from adding an opcode
> >
> > Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be 
> > somehow introduced to make it compatible with "Bitcoin Message". And we 
> > have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is 
> > "conditionally valid transaction". It is also possible to assign some 
> > unused opcode, but then it will be more complex, because in Script, those 
> > opcodes make transaction invalid, 

Re: [bitcoin-dev] Regarding BIP322 edge cases

[Ali Sherief via bitcoin-dev]

> Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be 
> somehow introduced to make it compatible with "Bitcoin Message".

I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATASIG 
can take   off the stack and perform an ECDSA public key 
recovery, followed by SHA256/RIPEMD160, kind of like a hybrid between 
OP_DUP/OP_HASH160/OP_EQUALVERIFY and OP_CHECKSIG.

But the implementations would have to decode the Base58 address into "0x00" 
plus the address hash. As the only supported invoice type for the Legacy 
signing methods, this should be straight forward to do.

> And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it 
> is "conditionally valid transaction".

I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help 
implement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid instruction.

- Ali

On Wed, 10 Aug 2022 04:59:46 +0200, vju...@gazeta.pl wrote:
> > I'm not sure what is to be gained from adding an opcode
>
> Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be 
> somehow introduced to make it compatible with "Bitcoin Message". And we have 
> opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is 
> "conditionally valid transaction". It is also possible to assign some unused 
> opcode, but then it will be more complex, because in Script, those opcodes 
> make transaction invalid, but inside TapScript, those opcodes are defined as 
> OP_SUCCESS, and make things automatically valid.
>
>
> On 2022-08-09 22:53:34 user Ali Sherief via bitcoin-dev 
>  wrote:
> > Although there is a Github issue/PR at 
> > https://github.com/bitcoin/bips/pull/1347 for addressing all the TODO items 
> > of BIP322, I decided to throw it in the mailing list again to see if anyone 
> > else has suggestions for dealing with them.
>
> So in an older copy of the draft at 
> https://github.com/bitcoin/bips/blob/b6b0126e2d04793ba52a40f05d24538fa3f2c9ad/bip-0322.mediawiki
>  , I found the some TODO items, and I will copy-paste the ones in the 
> Specification section (for full proofs) here:
>
> > TODO: How does this interact with as-of-yet-unspecified "Silent 
> > Transactions"?
> > TODO: Some invalid opcode to allow only in various proof types?
> > TODO: A way for the initial signer to delegate to another scriptPubKey; 
> > needed for better privacy and CoinJoin/Lightning compatibility
>
> So to start with, I believe it will be very helpful to limit what opcodes 
> scriptPubKeys to be elligible to sign from them. The specification already 
> does so to a point, but in order for these to be recognizable, it's my 
> opinion that one of the NOPs should be placed at the beginning of the script 
> to activate proof parsing mode.
>
> Of course, an opcode is not necessary at all, if the program is able to infer 
> from context where the proof is coming from. After all, since they cannot be 
> broadcasted, they can't be mined in blocks, so will never be encountered in a 
> full node's usual verifier. I'm not sure what is to be gained from adding an 
> opcode - the only source for real transactions is from P2P-obtained blocks, 
> so when a human inputs a signature to be verified, it can check that a real 
> transaction is not being inserted by looking for the invalid input.
>
> For Silent Transactions, I have already given my suggestion in the PR, that 
> some subsection can be made saying that it can operate with them by using its 
> scriptPubKey (and other stuff that may be necessary - I am not excatly sure 
> what goes inside the Witness stack of message_signature).
>
> In the case of the last TODO, related to delegation to another scriptPubKey, 
> I am not quite sure at the moment what to do about it - perhaps you guys can 
> place a MAST (two Merkle branches, to be specific) - the first branch has the 
> original signer's scriptPubKey, the second branch contains the delegated 
> signer's scriptPubKey.
>
> - Ali

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

[bitcoin-dev] Regarding BIP322 edge cases

[Ali Sherief via bitcoin-dev]

Although there is a Github issue/PR at 
https://github.com/bitcoin/bips/pull/1347 for addressing all the TODO items of 
BIP322, I decided to throw it in the mailing list again to see if anyone else 
has suggestions for dealing with them.

So in an older copy of the draft at 
https://github.com/bitcoin/bips/blob/b6b0126e2d04793ba52a40f05d24538fa3f2c9ad/bip-0322.mediawiki
 , I found the some TODO items, and I will copy-paste the ones in the 
Specification section (for full proofs) here:

> TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?
> TODO: Some invalid opcode to allow only in various proof types?
> TODO: A way for the initial signer to delegate to another scriptPubKey; 
> needed for better privacy and CoinJoin/Lightning compatibility

So to start with, I believe it will be very helpful to limit what opcodes 
scriptPubKeys to be elligible to sign from them. The specification already does 
so to a point, but in order for these to be recognizable, it's my opinion that 
one of the NOPs should be placed at the beginning of the script to activate 
proof parsing mode.

Of course, an opcode is not necessary at all, if the program is able to infer 
from context where the proof is coming from. After all, since they cannot be 
broadcasted, they can't be mined in blocks, so will never be encountered in a 
full node's usual verifier. I'm not sure what is to be gained from adding an 
opcode - the only source for real transactions is from P2P-obtained blocks, so 
when a human inputs a signature to be verified, it can check that a real 
transaction is not being inserted by looking for the invalid input.

For Silent Transactions, I have already given my suggestion in the PR, that 
some subsection can be made saying that it can operate with them by using its 
scriptPubKey (and other stuff that may be necessary - I am not excatly sure 
what goes inside the Witness stack of message_signature).

In the case of the last TODO, related to delegation to another scriptPubKey, I 
am not quite sure at the moment what to do about it - perhaps you guys can 
place a MAST (two Merkle branches, to be specific) - the first branch has the 
original signer's scriptPubKey, the second branch contains the delegated 
signer's scriptPubKey.

- Ali

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

Re: [bitcoin-dev] P2P trading replacement transactions

[Ali Sherief via bitcoin-dev]

It would probably only work out if each output got their own private keys, 
since otherwise Alice can't share any outputs with Bob and vice versa.

The whole thing sounds like an HTLC with an additional trading of private keys 
for the actual trades instead of in the HLTC. How are they going to share their 
private keys securely, with PGP?

Perhaps Taproot with its selective revealing of certain script branches can 
help here, but I'm not sure about details.

- Ali

> Hi Bitcoin Developers,
>
> Does it make sense to trade replacement transactions for privacy? I have 
> shared basic details to implement this and would love to read opinions about 
> it or ways to improve it:
>
> =
> alice
> =
>
> tx1: input a (0.01) -> output b1 (0.008)
> -> change c1 (0.001)
>
> tx2: input a (0.01) -> output e2 (0.007)
> -> output f2 (0.001)
>
> =
>
> bob
> =
>
> tx1: input d (0.011) -> output e1 (0.007)
> -> change f1 (0.003)
>
> tx2: input d (0.011) -> output b2 (0.008)
> -> output c2 (0.001)
>
> =
>
> carol
> =
>
> - creates an API to manage trades that will use 2 of 3 multisig
> - alice and bob create orders for replacement
> - either they could be matched automatically using some algorithm or bob 
> manually accepts the offer
> - 2 of 3 multisig is created with Alice, Bob and Carol keys
> - bob locks 0.01 BTC in it and shares outputs e2,f2 with alice
> - alice signs tx2 and shares tx with bob
> - alice locks 0.011 BTC in it and shares outputs b2,c2 with bob
> - bob signs tx2 and shares with alice
> - both replacement txs can be broadcasted
> - funds are released from 2 of 3 multisig with a tx having 3 outputs (one to 
> pay fee which goes to carol)
>
> positives:
>
> - privacy
>
> negatives:
>
> - extra fees
> - will take some time although everything will be managed by wallet with API 
> provided by carol
> - need to lock bitcoin with same amount as used in tx1
> - amounts could still be used to link txs in some cases- carol and other peer 
> knows the details___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Ali Sherief via bitcoin-dev]

That's actually a good idea. Perhaps I can move the algorithms (of BIP137) and 
stuff to Bitcoin Wiki, and then convert the BIP to strictly a "Taproot message 
signing BIP".

Even though I already know the chances of such a BIP being numbered is low, at 
least the most important part will be accomplished already (get everybody to 
use BIP137, and later once BIP322 is finished make people use that).

I ultimately prefer that everyone should use BIP322 eventually, though it 
should have some kind of RFC2440-like format for maximum user-friendliness. 
Perhaps bit by bit, the message sanitization can be introduced as well.

- Ali

On Fri, Aug 5, 2022 at 12:12 PM, Pavol Rusnak  wrote:

> Hi Ali!
>
> Nice work. Since it seems this is a strict superset of BIP137, why not just 
> focus on things that you are adding (Taproot) while saying your BIP is an 
> expansion of BIP137?
>
> Your approach make it unnecessarily hard to figure out whether you are 
> changing anything in handling of ECDSA signature types or not. If it was 
> clearly stated you are just expanding BIP137 and removes everything that’s 
> already described in BIP137, it would be much more obvious to everyone.
>
> On Thu 4. 8. 2022 at 17:49, Ali Sherief via bitcoin-dev 
>  wrote:
>
>> Hi,
>>
>> I have created a new BIP, called notatether-signedmessage. It can be viewed 
>> at 
>> https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.mediawiki.
>>
>> For those who want a quick summary, it defines a step-by-step process for 
>> signing and verifying messages from legacy, native/nested segwit, and 
>> taproot addresses. It does not define a new signature format itself, except 
>> in the case of Taproot. For those addresses, I have defined a signature 
>> format that has 1 byte header/recID, 64 bytes signature, and 32 bytes x 
>> coordinate of a public key. This is required to run the BIP340 Schnorr 
>> verify algorithm using only the signature - and the header byte is added for 
>> backwards compatibility. Otherwise, it completely integrates BIP137 
>> signatures.
>>
>> I am planning to move that format to its own BIP as soon as possible, in 
>> lieu that it is unacceptable to define formats in an Informational BIP.
>>
>> Please leave your comments in this mailing list. CC'ing BIP editors.
>>
>> - Ali
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> --
>
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> Co-Founder, SatoshiLabs___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Ali Sherief via bitcoin-dev]

> IMO, there is no benefit to an additional message signing standard, especially
> one that doesn't address the problems with the current standard or (at
> present) BIP322.

In that case, I propose the following:

- I scrap the Taproot/Schorr and the two extensions inside the BIP, which will 
leave it with only parts and formats which have already been standardized 
(effectively, the legacy and segwit addresses).

Because here's the thing: The reason why wallets are not implementing 
sign/verify correctly is because there is no reference manual for doing so. 
This informational BIP is supposed to solve that problem by providing only a 
list of instructions for computing ECSDA sign/verify correctly.

Also, it is not visible right now, but there will also be a reference 
implementation so that wallet developers can actually code them correctly, as 
you've stated.

- Ali

On Fri, Aug 5, 2022 at 9:51 AM, Luke Dashjr  wrote:

> On Friday 05 August 2022 04:05:56 Ali Sherief wrote:
>> Yeah, I have a specific reason to advance this first (emphasis on the word
>> first).
>>
>> I briefly mentioned in the BIP that BIP322 has superior message
>> verification capabilities. This is true, but it suffers from the drawback
>> that wallets are not using it.
>
> Likely because it is a draft and incomplete.
>
>> Message signatures are highly relied upon in some places (just to name a
>> few, at many mining pools e.g. Slushpool, and the Bitcointalk forum),
>
> I'm not aware of any using the current message signatures _correctly_.
> Note they are not useful for proving that you sent a transaction, nor have the
> ability to send a transaction or access to bitcoins.
>
>> This BIP is kind of like a "bumper car", in that it forces compliance with
>> previous BIPs that extend the message signing format, in particular BIP137.
>
> BIPs can't force anything, they're just documentation.
>
> IMO, there is no benefit to an additional message signing standard, especially
> one that doesn't address the problems with the current standard or (at
> present) BIP322.
>
> Luke___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-notatether-signedmessage (appendix)

[Ali Sherief via bitcoin-dev]

Also, I forgot to write in the previous message, that this BIP is not a 
standard - that's the reason I raised the N+1 problem in the first place. As 
mentioned previously, it's strictly limited to a reference manual - which 
could've been hosted anywhere else (such as my own website), but these 
instructions ought to be made official.

- Ali___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Ali Sherief via bitcoin-dev]

Yeah, I have a specific reason to advance this first (emphasis on the word 
first).

I briefly mentioned in the BIP that BIP322 has superior message verification 
capabilities. This is true, but it suffers from the drawback that wallets are 
not using it. What they are using right now is a chaotic mixture of legacy 
address sign/verify and nonstandard segwit sign/verify. Attempting to enforce 
BIP322 on them in this stage will just create an N+1 problem, so an effort has 
to be made first to transfer these N signing implementations to a common 
ground, with as little as possible developer effort - it takes much less time 
to code the point-by-point steps than designing a class for BIP322 signatures, 
since the teams behind these wallets have to *agree* on how to code such a 
change. This ultimately decides whether or not the wallets implement such 
features as BIP322 or this BIP. [this paragraph is the meat of the reasoning.]

That is to say, BIP322 is more complex than this BIP (which in no way replaces 
BIP322), hence it requires a larger design effort on the part of wallet 
developers to implement. Considering that the vast majority of them already 
sign messages using the current format, it makes complete sense to make them 
all conform to this BIP first, then we finish BIP322, and then make wallets use 
that.

Message signatures are highly relied upon in some places (just to name a few, 
at many mining pools e.g. Slushpool, and the Bitcointalk forum), and it is 
unreasonable to expect users to cling on to an old address format, or use a 
specific wallet (Electrum) that provides nonstandard signature verification (it 
does *not* follow BIP137 despite supporting segwit messages, so their 
signatures are non-portable).

That is why it is necessary at the present moment to ensure as many wallets are 
possible are not only using the specification in my BIP to perform message 
signing and verification, but also implement, at a bare minimum, the legacy and 
segwit address parts. And the reason I did not mandate this requirement is the 
BIP is that wallets do not provide legacy addresses, then it makes no sense for 
them to add the sign/verify code for legacy addresses as well.

This BIP is kind of like a "bumper car", in that it forces compliance with 
previous BIPs that extend the message signing format, in particular BIP137. I 
admit that the Taproot signature format should not be located inside this BIP - 
I want to keep it strictly Informational, but rather, it should be contained in 
a newer Standards Track BIP that supersedes BIP137 - it's only task is to 
define everything BIP137 already defines, and  also add the Taproot signing 
format.

Like I said in the BIP, just making a proposal will not solve all these 
problems. It will only solve half of them, and the other half has to be solved 
by getting the other wallet implementations (Armory, Wasabi, BitcoinJ, 
Samourai, Mycelium, Electrum, and Trezor/Ledger among others) to implement this 
standard. It is not a difficult task but it's a non-trivial one, and we ought 
to be at least half-way to the finish line by assigning a number to this.

- Ali

--- Original Message ---
On Thursday, August 4th, 2022 at 10:26 PM, Luke Dashjr  wrote:


> Any reason not to just help Kalle out with BIP 322?
>
> https://github.com/bitcoin/bips/pull/1347
>
>
> On Thursday 04 August 2022 12:18:56 Ali Sherief via bitcoin-dev wrote:
>
> > Hi,
> >
> > I have created a new BIP, called notatether-signedmessage. It can be viewed
> > at
> > https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessag
> > e.mediawiki.
> >
> > For those who want a quick summary, it defines a step-by-step process for
> > signing and verifying messages from legacy, native/nested segwit, and
> > taproot addresses. It does not define a new signature format itself, except
> > in the case of Taproot. For those addresses, I have defined a signature
> > format that has 1 byte header/recID, 64 bytes signature, and 32 bytes x
> > coordinate of a public key. This is required to run the BIP340 Schnorr
> > verify algorithm using only the signature - and the header byte is added
> > for backwards compatibility. Otherwise, it completely integrates BIP137
> > signatures.
> >
> > I am planning to move that format to its own BIP as soon as possible, in
> > lieu that it is unacceptable to define formats in an Informational BIP.
> >
> > Please leave your comments in this mailing list. CC'ing BIP editors.
> >
> > - Ali
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP-notatether-signedmessage

[Ali Sherief via bitcoin-dev]

My sincere apologies, the link returns a 404 (trailing dot). The correct link 
to the BIP is 
https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.mediawiki

-Ali

--- Original Message ---
On Thursday, August 4th, 2022 at 3:18 PM, Ali Sherief  
wrote:


> Hi,
>
> I have created a new BIP, called notatether-signedmessage. It can be viewed 
> at 
> https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.mediawiki.
>
> For those who want a quick summary, it defines a step-by-step process for 
> signing and verifying messages from legacy, native/nested segwit, and taproot 
> addresses. It does not define a new signature format itself, except in the 
> case of Taproot. For those addresses, I have defined a signature format that 
> has 1 byte header/recID, 64 bytes signature, and 32 bytes x coordinate of a 
> public key. This is required to run the BIP340 Schnorr verify algorithm using 
> only the signature - and the header byte is added for backwards 
> compatibility. Otherwise, it completely integrates BIP137 signatures.
>
> I am planning to move that format to its own BIP as soon as possible, in lieu 
> that it is unacceptable to define formats in an Informational BIP.
>
> Please leave your comments in this mailing list. CC'ing BIP editors.
>
> - Ali
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP-notatether-signedmessage

[Ali Sherief via bitcoin-dev]

Hi,

I have created a new BIP, called notatether-signedmessage. It can be viewed at 
https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.mediawiki.

For those who want a quick summary, it defines a step-by-step process for 
signing and verifying messages from legacy, native/nested segwit, and taproot 
addresses. It does not define a new signature format itself, except in the case 
of Taproot. For those addresses, I have defined a signature format that has 1 
byte header/recID, 64 bytes signature, and 32 bytes x coordinate of a public 
key. This is required to run the BIP340 Schnorr verify algorithm using only the 
signature - and the header byte is added for backwards compatibility. 
Otherwise, it completely integrates BIP137 signatures.

I am planning to move that format to its own BIP as soon as possible, in lieu 
that it is unacceptable to define formats in an Informational BIP.

Please leave your comments in this mailing list. CC'ing BIP editors.

- Ali

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

Re: [bitcoin-dev] Zero-knowledge proofs e.g. Schnorr are incompatible with address signing without compromise

[Ali Sherief via bitcoin-dev]

> Yes, that's an intentional design choice in BIP340, see note 5: 
> https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#cite_ref-5-0. 
> The choice is either batch verifiability or public key recovery.

The way I understood the BIP, was that a user can do batch recovery or 
single-key recovery. Can you explain how it is possible to recover a public key 
from a single-key signature, because a few days earlier on the 
BIP-notatether-messageverify thread I was told (I think it was achow) that 
Schnorr doesn't allow for public key recovery.

At any case, I was already planning on just concatenating the public key after 
the signature (the other option I was thinking of, appending it after the 
Taproot address, is quite unruly in my opinion).

> I think it would be much better if people would cooperate to get BIP322 to 
> move forward than to keep inventing other formats. It's the obvious solution 
> in my opinion: not restricted to single-key policies, compatible with every 
> script type, and trivially extensible to future schemes.

This is why I especially tried to avoid making a new format - My BIP is 
strictly an Informational one. That strategy worked pretty well up to now, but 
now I find myself forced to make a small concession in the design to support 
the verification of Taproot address. But I'm glad it's quite trivial as 
appending a single variable. So at least this BIP won't be an obstacle to any 
such effort.

[Besides, since I'm also planning on detecting BIP137 in the verification 
methods, I can assume the Signature field contains arbitrary data.]

> > , just like BIP340).
>
>
> How so? Every taproot compatible wallet has a BIP340 implementation.

I guess I made an assumption, since almost all of the wallets I have seen did 
not have a sign message feature, not even for legacy addresses.

- Ali

--- Original Message ---
On Thursday, July 28th, 2022 at 3:27 PM, Pieter Wuille  
wrote:


> --- Original Message ---
> On Thursday, July 28th, 2022 at 3:27 AM, Ali Sherief via bitcoin-dev 
> bitcoin-dev@lists.linuxfoundation.org wrote:
>
> > Essentially, zero-knowledge proofs such as Schnorr are not compatible with 
> > address message signing - the public key cannot be retrieved from the 
> > address or the signature, so the address does not actually prove the 
> > authenticity of a Schnorr signature. That's why the public key is required 
> > as an input in the first place.
>
>
> Yes, that's an intentional design choice in BIP340, see note 5: 
> https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#cite_ref-5-0. 
> The choice is either batch verifiability or public key recovery.
>
> I regret ever using public key recovery when introducing the old legacy 
> message signing scheme. It should just have used script signatures like 
> BIP322 proposes.
>
> > In order to make it compatible with the address signing mechanism, the 
> > zero-knowledge part would have to be sacrificed in my BIP, or else a 
> > completely separate message signing format just for Taproot would be 
> > required
>
>
> You can avoid relying on public key recovery, and include the public key + 
> BIP340 signature in the encoded signature.
>
> > (which, in my view, is redundant - there is already the draft BIP322 which 
> > can verify anything and everything, but nobody is implementing that
>
>
> I think it would be much better if people would cooperate to get BIP322 to 
> move forward than to keep inventing other formats. It's the obvious solution 
> in my opinion: not restricted to single-key policies, compatible with every 
> script type, and trivially extensible to future schemes.
>
> > , just like BIP340).
>
>
> How so? Every taproot compatible wallet has a BIP340 implementation.
>
> Cheers,
>
> --
> Pieter
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Zero-knowledge proofs e.g. Schnorr are incompatible with address signing without compromise

[Ali Sherief via bitcoin-dev]

Here is an except of the BIP-notatether-messageverify thread, where I 
contemplate how to implement address/message signing support for Taproot i.e. 
Schnorr signatures, in my post at:

https://bitcointalk.org/index.php?topic=5407517.msg60642144#msg60642144

(stripped of bbcode formatting)

==

So I have mostly figured out what should be done regarding the signing and 
verification from Taproot addresses. The good news is that BIP340 has already 
made this a standard saving me the headache of having to re-implement this all 
over again (not that I want to in the first place).

Despite being a draft, I see it as a net positive to include this signing 
format for Taproot addresses ahead of time i.e. before wallets even support 
Taproot addresses yet.

A few notes before I begin the quote of relevant parts:

- Eventually they chose "BIP340/challenge" as the key prefix aka. the tag. So I 
guess a different tag "BIP-notatether" would be incompatible with that so I 
drop my signing tag.

- They selected encoding only the x coord of R and P (not that this is relevant 
to use since I chose (e,s) encoding format), and they chose Y must be the even 
for P and R. It might not be relevant here since I can also use (e,s) as a 
signature format, but I am having great difficulty deciding between that or 
(R,s). I believe that only one of these formats should be used for maximum 
consistency. [But I do not see wallets placing multiple fields for public keys 
just to support batch verification.]

- The public key is required for all Schnorr verification schemes. This 
complicates the message signing/verification UI as "address" is supposed to 
contain an address, however the verification scheme cannot recover the public 
key (as achow101 mentioned). These differences might call for making a separate 
draft just for Schnorr signatures. Personally, I want to refrain from making 
any decision until I review the BIP137 signatures.



 Default Signing 

Input:
* The secret key ''sk'': a 32-byte array
* The message ''m'': a 32-byte array
* Auxiliary random data ''a'': a 32-byte array

The algorithm ''Sign(sk, m)'' is defined as:
* Let ''d' = int(sk)''
* Fail if ''d' = 0'' or ''d'  n''
* Let ''P = d' · G''
* Let ''d = d' '' if ''has_even_y(P)'', otherwise let ''d = n - d' ''.
* Let ''t'' be the byte-wise xor of ''bytes(d)'' and 
''hashBIP0340/aux(a)''The auxiliary random data is hashed (with 
a unique tag) as a precaution against situations where the randomness may be 
correlated with the private key itself. It is xored with the private key 
(rather than combined with it in a hash) to reduce the number of operations 
exposed to the actual secret key..
* Let ''rand = hashBIP0340/nonce(t || bytes(P) || m)''Including 
the [https://moderncrypto.org/mail-archive/curves/2020/001012.html public key 
as input to the nonce hash] helps ensure the robustness of the signing 
algorithm by preventing leakage of the secret key if the calculation of the 
public key ''P'' is performed incorrectly or maliciously, for example if it is 
left to the caller for performance reasons..
* Let ''k' = int(rand) mod n''Note that in general, taking a uniformly 
random 256-bit integer modulo the curve order will produce an unacceptably 
biased result. However, for the secp256k1 curve, the order is sufficiently 
close to ''2256'' that this bias is not observable (''1 - n / 
2256'' is around ''1.27 * 2-128'')..
* Fail if ''k' = 0''.
* Let ''R = k' · G''.
* Let ''k = k' '' if ''has_even_y(R)'', otherwise let ''k = n - k' ''.
* Let ''e = int(hashBIP0340/challenge(bytes(R) || bytes(P) || m)) 
mod n''.
* Let ''sig = bytes(R) || bytes((k + ed) mod n)''.
* If ''Verify(bytes(P), m, sig)'' (see below) returns failure, 
abortVerifying the signature before leaving the signer prevents random or 
attacker provoked computation errors. This prevents publishing invalid 
signatures which may leak information about the secret key. It is recommended, 
but can be omitted if the computation cost is prohibitive..
* Return the signature ''sig''.


 Verification 

Input:
* The public key ''pk'': a 32-byte array
* The message ''m'': a 32-byte array
* A signature ''sig'': a 64-byte array

The algorithm ''Verify(pk, m, sig)'' is defined as:
* Let ''P = lift_x(int(pk))''; fail if that fails.
* Let ''r = int(sig[0:32])''; fail if ''r  p''.
* Let ''s = int(sig[32:64])''; fail if ''s  n''.
* Let ''e = int(hashBIP0340/challenge(bytes(r) || bytes(P) || m)) 
mod n''.
* Let ''R = s · G - e · P''.
* Fail if ''is_infinite(R)''.
* Fail if ''not has_even_y(R)''.
* Fail if ''x(R)  r''.
* Return success iff no failure occurred before reaching this point.

For every valid secret key ''sk'' and message ''m'', 
''Verify(PubKey(sk),m,Sign(sk,m))'' will succeed.

---

It's too early for my draft to cut off some dead wood from this draft, but I 
will end this post with a note:

- The purpose of address message signing/verification is to cryptographically 
prove that a 

[bitcoin-dev] Discussion about message verification draft BIP

[Ali Sherief via bitcoin-dev]

Hi guys, I have created a discussion thread for my draft BIP related to message 
verification on BitcoinTalk: https://bitcointalk.org/index.php?topic=5407517.0

Feel free to read it and contribute if you wish.

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

Re: [bitcoin-dev] Trying all address types in message signing verification (BIP)

[Ali Sherief via bitcoin-dev]

Well, if there are wallets that are already verifying BIP137 signatures, a 
universal BIP that encompasses all signatures would also have to check for 
BIP137 signatures obviously. Can't have an all-encompassing BIP that excludes 
some signature types.

Fortunately, as is the case for my original proposal, only the verification 
algorithm needs to be adjusted to identify BIP137 signatures. The signing part 
can just place the address and whatever signature it makes inside the message.

I have studied BIP137 today and it looks like it only changes the signature 
payload, not the address, so any BIP made to address this problem must also 
take into account that the signature may be in different formats.

Does anyone know if BIP322 is being used in any wallet, for reference?

On Thursday, July 21st, 2022 at 7:06 AM, Craig Raw  wrote:

>> Unfortunately, I do not know of any "verifiers" that will accept the above 
>> signature
>
> Sparrow verifies this signature.
>
> The approach used is to convert the message and signature to a public key, 
> trying first BIP137 and then the approach used by Electrum (they differ in 
> treatment of the signature header for segwit P2SH). The script type is 
> extracted from the provided address and compared against the address 
> constructed with the public key using the same script type. i.e. There is no 
> need to iterate through all script types, since the script type is implicitly 
> provided in the address.
>
> Craig
>
> On Wed, Jul 20, 2022 at 11:51 PM Greg Sanders via bitcoin-dev 
>  wrote:
>
>> Please see BIP322 
>> https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki
>>
>> On Wed, Jul 20, 2022, 5:46 PM Peter (Coinkite Inc) via bitcoin-dev 
>>  wrote:
>>
>>> Hi Ali.
>>>
 This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My 
 proposal is simply going to standardize the practice of placing the segwit 
 address into the address field, and does not require alterations to the 
 message signing format like those BIPs.
>>>
>>> COLDCARD makes signatures exacly like that, when told to sign with a segwit 
>>> address:
>>>
>>> % ckcc msg -s Hello
>>> Hello
>>> bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
>>> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=
>>>
>>> Unfortunately, I do not know of any "verifiers" that will accept the above 
>>> signature, but there is no alternative since the various BIP-322 proposals 
>>> never gained wide acceptance.
>>>
>>> Bitcoin Core does not support verifying that message, even though the UX 
>>> makes it look possible. In effect segwit features never got implemented to 
>>> that depth in Core. It's sad because the community is not maintaining core 
>>> (Core?) features to the same depth as Satoshi did when he was active in the 
>>> project.
>>>
 PS. I am pretty sure that there is a BIP for the original signing method - 
 what is its number?
>>>
>>> My understanding that the original approach was directly from Satoshi 
>>> himself when the original client was written. It has never been codified in 
>>> a BIP as far as I know.
>>>
>>> A related issue the the "ascii armor" that is sometimes used. It's a little 
>>> like RFC2440  but newline-treatment 
>>> isn't defined well enough for good interoperability, in my personal 
>>> experience.
>>>
>>> So in summary... yes a "defacto" BIP is needed and useful to do, in my 
>>> opinion. Then Core should be updated to support it as well.
>>>
>>> ---
>>> @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
>>>
>>> On Wed, Jul 20, 2022 at 04:10:09AM +, Ali Sherief wrote:
 [my third attempt at getting this message through. Surprisingly, I managed 
 to send this at the second try with the correct SMTP, From, To and all, 
 but maybe it was caught in GreyListing (protonmail).]

 I was thinking about creating a BIP to address the lack of standardization 
 for Segwit message signatures, but I want some advice before proceeding.

 The current state of affairs is that the wallets that do support signing 
 and verifying a bitcoin message can only sign legacy addresses. It is 
 technically possible to sign and verify segwit addresses, since ECDSA only 
 depends on the public key (hence why you need a private key to sign 
 messages).

 However, because there is no generally-accepted standard for signing 
 segwit messages, the wallets that do support this feature simply insert 
 the segwit address into the address field. Verification also only works 
 using the procedure on that specific wallet software, if only because the 
 conventional tools for verifying messages attempt to reconstruct a legacy 
 address only.

 This BIP is not going to enforce anything, it's just going to set 
 guidelines for writing a message signing and verification procedure.

 This BIP does not replace, supersede, or 

Re: [bitcoin-dev] Trying all address types in message signing verification (BIP)

[Ali Sherief via bitcoin-dev]

Hi Peter,

> COLDCARD makes signatures exacly like that, when told to sign with a segwit 
> address:
>
> % ckcc msg -s Hello
> Hello
> bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=
>
> Unfortunately, I do not know of any "verifiers" that will accept the above 
> signature, but there is no alternative since the various BIP-322 proposals 
> never gained wide acceptance.

This is largely why I avoided basing my idea off of BIP-322. Not only does a 
BIP has a higher chance of acceptance the less aspects it modifies, but I feel 
that although its not urgent (such as, for example, the segwit deployment BIP), 
this BIP should be made as soon as possible. It's also why I avoided specifying 
anything about testnet or regtest address singing - thankfully, I have yet to 
see ayone sign messages from these networks.

> Bitcoin Core does not support verifying that message, even though the UX 
> makes it look possible. In effect segwit features never got implemented to 
> that depth in Core. It's sad because the community is not maintaining core 
> (Core?) features to the same depth as Satoshi did when he was active in the 
> project.

Yes, if it looks possible from the UX, chances are that its very 
straightforward to implement in code. That's why I'm not expecting any problems 
when I finally draft the BIP.

In my original plans, I said the verifier was going to try Legacy, Nested 
Segwit, and Native Segwit encodings in sequence, but now, I think this 
step-by-step procedure is unnecessary. The correct encoding can be guessed by 
looking at the address prefix:

- If it starts with a "1", attempt the Legacy encoding. (Fail verification if 
it does not yield the correct address).
- If it starts with a "3", attempt the Nested Segwit encoding. (Fail 
verification if it does not yield the correct address).
- If it starts with a "bc1", fetch the version number from the immediately 
following character, and attempt the Native Segwit encoding with that version 
number. (Fail verification if it does not yield the correct address).
- If it starts with any other prefix, fail verification.

In my opinion, the signing and verification processes have to be precisely 
defined in the BIP - to be exactly the same as it presently is, and then these 
additions - to ensure that the BIP clearly deescribes how signing and 
verification should be implemented today - in addition to "tomorrow" when the 
BIP is widely accepted.

> So in summary... yes a "defacto" BIP is needed and useful to do, in my 
> opinion. Then Core should be updated to support it as well.

Since I already plan on adding a Python example for the signing and 
verification process, it will be a straightforward process to translate it to 
C++ without even minor interface/implementation difficulties.

Since I can't think of any more ways to streamline the BIP, I'm going to start 
a draft along these principles shortly.

- Ali

On Wednesday, July 20th, 2022 at 1:31 PM, Peter (Coinkite Inc) 
 wrote:


> Hi Ali.
>
> > This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My 
> > proposal is simply going to standardize the practice of placing the segwit 
> > address into the address field, and does not require alterations to the 
> > message signing format like those BIPs.
>
>
> COLDCARD makes signatures exacly like that, when told to sign with a segwit 
> address:
>
> % ckcc msg -s Hello
> Hello
> bc1qzeacswvlulg0jngad9gmtkvdp9lwum42wwzdu5
> HxuuWQwjw0417fLV9L0kWbt7w9XOIWKhHMhjXhyXTczcSozGTXM4knqdISiYbbmqSRXqI5mNTWH9qkDoqZTpnPc=
>
> Unfortunately, I do not know of any "verifiers" that will accept the above 
> signature, but there is no alternative since the various BIP-322 proposals 
> never gained wide acceptance.
>
> Bitcoin Core does not support verifying that message, even though the UX 
> makes it look possible. In effect segwit features never got implemented to 
> that depth in Core. It's sad because the community is not maintaining core 
> (Core?) features to the same depth as Satoshi did when he was active in the 
> project.
>
> > PS. I am pretty sure that there is a BIP for the original signing method - 
> > what is its number?
>
>
> My understanding that the original approach was directly from Satoshi himself 
> when the original client was written. It has never been codified in a BIP as 
> far as I know.
>
> A related issue the the "ascii armor" that is sometimes used. It's a little 
> like RFC2440 https://www.ietf.org/rfc/rfc2440.txt but newline-treatment isn't 
> defined well enough for good interoperability, in my personal experience.
>
>
> So in summary... yes a "defacto" BIP is needed and useful to do, in my 
> opinion. Then Core should be updated to support it as well.
>
> ---
> @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
>
>
> On Wed, Jul 20, 2022 at 04:10:09AM +, Ali Sherief wrote:
>
> > [my third attempt at getting this message through. Surprisingly, I 

[bitcoin-dev] Trying all address types in message signing verification (BIP)

[Ali Sherief via bitcoin-dev]

[my third attempt at getting this message through. Surprisingly, I managed to 
send this at the second try with the correct SMTP, From, To and all, but maybe 
it was caught in GreyListing (protonmail).]

I was thinking about creating a BIP to address the lack of standardization for 
Segwit message signatures, but I want some advice before proceeding.

The current state of affairs is that the wallets that do support signing and 
verifying a bitcoin message can only sign legacy addresses. It is technically 
possible to sign and verify segwit addresses, since ECDSA only depends on the 
public key (hence why you need a private key to sign messages).

However, because there is no generally-accepted standard for signing segwit 
messages, the wallets that do support this feature simply insert the segwit 
address into the address field. Verification also only works using the 
procedure on that specific wallet software, if only because the conventional 
tools for verifying messages attempt to reconstruct a legacy address only.

This BIP is not going to enforce anything, it's just going to set guidelines 
for writing a message signing and verification procedure.

This BIP does not replace, supersede, or obsolete BIPs 173 or 322. My proposal 
is simply going to standardize the practice of placing the segwit address into 
the address field, and does not require alterations to the message signing 
format like those BIPs.

In summary, in the verification part, the following address hashing algorithms 
will be tried in sequence in an attempt to reconstruct the address in the 
signed message:
- P2PKH (legacy address)
- P2WPKH-P2SH (nested segwit)
- P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit with 
version 0 as well as future native segwit address types such as Taproot) - 
where MAX_WITNESS_VERSION is the maximum supported witness version by the 
bech32 encoding.

The verification procedure stops if any of these hashes yield the correct 
address, and fails if all of the above methods fail to reproduce the address in 
the signed message.

In the signing procedure, the only modification is the insertion of the segwit 
address in place of the legacy address in the signed message.

If this BIP is approved, it does not require any changes to existing signed 
messages, and the original sign/verify algorithms will continue to interoperate 
with this improved sign/verify algorithm, without any action necessary from the 
developers.

So as you can see, this is the entire framework of the BIP I plan to draft. 
There is no need for any auxilliary feature additions into this BIP. I just 
want to hear the mailing list's advice about how I should draft such a BIP.

- Ali

PS. I am pretty sure that there is a BIP for the original signing method - what 
is its number?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trying to patch Core ZMQ "rawtx" topic to only publish unconfirmed transactions: How?

[Ali Sherief via bitcoin-dev]

Theoretically that would be the desired outcome for me but this change is going 
to be implemented as part of a casino which must display the status of new 
deposits that are made, even when they are unconfirmed to now. Hence why I need 
to receive the unconfirmed messages.

- Ali Sherief

On Mon, Nov 29, 2021 at 5:10 PM, LORD HIS EXCELLENCY JAMES HRMH 
 wrote:

> Wasn't this already not a problem because you can check if it was confirmed? 
> The transaction is not finalised in the mempool it is just speculation of a 
> transaction, so it makes sense to emit when the transaction is confirmed. 
> Just already check..
>
>> It appears that the ZeroMQ topic I'm listening to, "rawtx", not only
>> emits a raw transaction when it appears on the mempool, but once it's
>> already confirmed too.
>
> KING JAMES HRMH
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
> Willtech
> www.willtech.com.au
> www.go-overt.com
> duigco.org DUIGCO API
> and other projects
>
> m. 0487135719
> f. +61261470192
>
> This email does not constitute a general advice. Please disregard this email 
> if misdelivered.
> ---
>
> From: bitcoin-dev  on behalf 
> of 0xB10C via bitcoin-dev 
> Sent: Monday, 29 November 2021 8:32 PM
> To: Ali Sherief ; Bitcoin Protocol Discussion 
> 
> Subject: Re: [bitcoin-dev] Trying to patch Core ZMQ "rawtx" topic to only 
> publish unconfirmed transactions: How?
>
> Hi Ali,
>
> I've run into this multiple times myself. I've opened a draft PR [0]
> adding a rawmempooltx publisher.
>
> You're right. In zmq/zmqnotificationinterface.cpp the
> CZMQNotificationInterface is notified about TransactionAddedToMempool.
> Currently, this calls NotifyTransaction() (the publisher with the rawtx
> topic) and NotifyTransactionAcceptance() (the publisher with the
> sequence topic)[1]. I've added a call to a new
> NotifyMempoolTransaction() function (the publisher with the rawmempooltx
> topic).
>
> I'd find a mempool transaction publisher with both the raw transaction
> and transaction fee useful too. However, this requires changes to the
> chain notifications in interfaces/chain.h.
>
> [0]: https://github.com/bitcoin/bitcoin/pull/23624
> [1]:
> https://github.com/bitcoin/bitcoin/pull/23624/files#diff-ac4b2d3a8de2c4dd41ad9d75505ea6ce4dc87a476710a9ebee8acf9bebf5cca2L146-L148
>
> Best,
> 0xB10C
>
> On 11/26/21 5:56 PM, Ali Sherief via bitcoin-dev wrote:
>>
>> This has also been posted on Bitcointalk
>> forum: 
>> https://bitcointalk.org/index.php?topic=5373341.msg58539261#msg58539261
>> <https://bitcointalk.org/index.php?topic=5373341.msg58539261#msg58539261> I
>> have republished it here hoping someone more knowledgeable can post
>> some insight about this.
>> 
>> It appears that the ZeroMQ topic I'm listening to, "rawtx", not only
>> emits a raw transaction when it appears on the mempool, but once it's
>> already confirmed too.
>>
>> This messes with my software, causing it to add txids, addresses, etc.
>> a second time inside arrays (this means that the same transaction is
>> received twice in total).
>>
>> Array de-duping is not a viable solution long-term (because the array
>> will quickly grow to be big eventually and then this has to happen
>> every time a new element is added), so I'm trying to nip the problem
>> from the source by instructing Core to only publish unconfirmed
>> bitcoin transactions.
>>
>> According to
>> https://bitcoin.stackexchange.com/questions/52848/is-it-possible-to-configure-the-bitcoin-daemon-to-only-broadcast-unconfirmed-tra
>> <https://bitcoin.stackexchange.com/questions/52848/is-it-possible-to-configure-the-bitcoin-daemon-to-only-broadcast-unconfirmed-tra>
>> , it is not possible to configure this from a configuration or
>> command-line option. The source code must directly be edited. But
>> since the codebase has changed greatly, the proposed solution no
>> longer works.
>>
>> 
>>
>> So basically, I know that something inside
>> src/zmq/zmqnotificationinterface.cpp needs to be patched, but I'm not
>> sure which function, or how to do it. Because I only need unconfirmed
>> transactions to be published on ZeroMQ rawtx and not confirmed ones,
>> it's one of the following functions that I need to patch for my own build:
>>
>> CZMQNotificationInterface::TransactionRemovedFromMempool
>>

[bitcoin-dev] Trying to patch Core ZMQ "rawtx" topic to only publish unconfirmed transactions: How?

[Ali Sherief via bitcoin-dev]

This has also been posted on Bitcointalk forum: 
https://bitcointalk.org/index.php?topic=5373341.msg58539261#msg58539261 I have 
republished it here hoping someone more knowledgeable can post some insight 
about this.

It appears that the ZeroMQ topic I'm listening to, "rawtx", not only emits a 
raw transaction when it appears on the mempool, but once it's already confirmed 
too.

This messes with my software, causing it to add txids, addresses, etc. a second 
time inside arrays (this means that the same transaction is received twice in 
total).

Array de-duping is not a viable solution long-term (because the array will 
quickly grow to be big eventually and then this has to happen every time a new 
element is added), so I'm trying to nip the problem from the source by 
instructing Core to only publish unconfirmed bitcoin transactions.

According to 
https://bitcoin.stackexchange.com/questions/52848/is-it-possible-to-configure-the-bitcoin-daemon-to-only-broadcast-unconfirmed-tra
 , it is not possible to configure this from a configuration or command-line 
option. The source code must directly be edited. But since the codebase has 
changed greatly, the proposed solution no longer works.



So basically, I know that something inside src/zmq/zmqnotificationinterface.cpp 
needs to be patched, but I'm not sure which function, or how to do it. Because 
I only need unconfirmed transactions to be published on ZeroMQ rawtx and not 
confirmed ones, it's one of the following functions that I need to patch for my 
own build:

CZMQNotificationInterface::TransactionRemovedFromMempool
void CZMQNotificationInterface::BlockDisconnected

Both of these call NotifyTransaction() method which I assume fires a message on 
"rawtx" channel.

In the Stack Exchange question I linked above, Jonas Schnelli suggested adding 
an `if (!pblock)` check, but that was several years ago and the function he was 
referencing no longer exists.

But I still wonder if the pblock check is still applicable in the present day 
(i.e. if it's indicating a block the transaction is inside).

- Ali Sherief___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] src/httprpc.cpp InterruptHTTPRPC

[Ali Sherief via bitcoin-dev]

I am using Bitcoin Core's HTTP RPC server as a basis for my own application. 
While browsing the source code of src/httprpc.cpp, I notice that the 
InterruptHTTPRPC function 
https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/httprpc.cpp#L310-L314
 just calls LogPrint() without doing anything else.

Does the HTTP RPC server support interrupting the event loop at this time, or 
is this method a stub?

- Ali___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] An idea to block invalid addresses from reaching the peers.dat buckets

[Ali Sherief via bitcoin-dev]

This is an interesting read: https://bitcointalk.org/index.php?topic=5348856.0

So according to this, somebody is spamming the bitcoin network with addr 
message pointing to invalid addresses and ports, which bloats the peers.dat and 
corresponding structure in memory.

Since peers.dat uses a custom record type which I don't know how to parse, I 
wasn't able to check specifics of IP addresses listed in there, but I believe I 
have a workaround to prevent this kind of thing from happening. Exactly how 
easy or difficult it will be to implement this change I don't know.

- Change the AddrDb updating functionality so that it does not add nodes that 
are unreachable. Not unreachable by timeout, but "connection refused" kind of 
errors.

Such addresses can either be stored in a new, separate database-like file such 
as "ignore.dat", or they can be augmented in the peers.dat file under a new 
entry type (I'm not sure if this is even possible). In both cases the invalid 
nodes can be immediately flushed from memory to avoid processing them.

-- This is only done the first time the node is seen in the wild. To avoid 
blocking nodes which happened to go offline, the check won't be made if it's 
already in the buckets. So it won't clean up an attack like this (meaning 
peers.dat files have to be recreated to fix this) but it will prevent another 
in the future.

- In order to facilitate other nodes discovering blocked nodes, a new ZMQ 
message can be made that sends the node's list of ignored addresses. Since I 
haven't used ZMQ much I don't know the specifics of how to do this.

- Introduce a new file or command-line/config option called "ignorelist" or 
something with a list of subnets that will *not* be read into the AddrDB 
buckets in any case.

It will work differently from the banlist, whose primary job is to block peers 
that send invalid messages, not peers that are not, and cannot, be unreachable 
in the first place.

- Ali Sherief___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev