<unnamed>

Public Key

npub1xq96jnxfzrdq4zgre20yqjrjsd29vcw8ymypl4v59cg6q6p66cts8q2u5f

Profile Code

nprofile1qqsrqzaffny3pks23ypu48jqfpegx4zkv8rjdjql6k2zuydqdqadv9cpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dss62hy2

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-08 01:21:56 CEST

- reply

📅 Original date posted:2023-05-25
🗒️ Summary of this message: A proposed L2 protocol involves settling transactions on L1 after a delay of 3-6 blocks to mitigate the risk of reorgs. Users must wait for sufficient confirmation depth before receiving payments.
📝 Original message: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 signs her PSBT and broadcasts it.
>
> - Collaboratively trade commitments: as mentioned, the commitment
> output that pays Bob may be claimed instead by Alice after 4 weeks, so
> Bob will need to either withdraw or obtain a new commitment within
> that
> time. To trade his existing commitment for a new commitment looks
> similar to the collaborative withdrawal procedure but without the
> creation of an immediately-spendable onchain output:
>
> - Alice creates an unsigned PSBT that uses as one of its inputs the
> connector from Bob's deposit transaction, again preventing double
> spending by Bob. Alice also includes a new connector and a new
> commitment that again allows Bob to later claim 1 BTC.
>
> - Bob receives Alice's PSBT and creates a PSBT transferring his
> existing commitment to her, with the new connector again being
> included as an input to ensure atomicity.
>
> - Bob signs; Alice signs and broadcasts.
>
> - Make an unconditioned payment: using the mechanisms described above,
> it's possible to make either an onchain payment or an offchain
> payment---just have Carol receive the new output or commitment rather
> than Bob. That payment would have no conditions (except its
> atomicity).
>
> - Make a conditional payment: imagine that Carol knows a secret (e.g.
> a preimage) that Bob is willing to pay for.
>
> - Alice creates an unsigned PSBT depending on the connector from
> Bob's deposit transaction and creating a new connector. The PSBT
> includes an output paying Carol (either onchain or via a
> commitment) with an HTLC, allowing Carol to claim the funds if
> she
> reveals the secret or allowing Bob to claim the funds after a
> timeout.
>
> - Bob receives Alice's PSBT and creates a PSBT transferring his
> existing commitment to her with the HTLC condition attached and,
> again, with connectors being used to ensure atomicity.
>
> - Bob signs; Alice signs and broadcasts.
>
> - Carol can settle her HTLC by either revealing the secret onchain
> or by trading her commitment containing the HTLC clause for a
> commitment from Alice that doesn't contain the clause (which
> Alice will only accept by learning the secret, since Alice has
> to settle with Bob). Alice can then either settle onchain or
> trade commitments with Bob after giving him the secret.
>
> - Do nothing for 4 weeks: if Bob does nothing for four weeks, Alice
> can claim the funds from the commitment output (i.e., takes his
> money).
>
> If Bob did actually do something, and if every other user who also
> had an unpublished output in the commitment transaction did
> something, then they all exchanged their portion of the funds in
> this output to Alice, so Alice can now claim all of those funds
> onchain in a highly efficient manner.
>
> Regarding the connector outputs, although all of the examples above show
> Alice directly spending from the connector output in Bob's deposit
> transaction, atomicity is also ensured if Alice spends from any output
> descended from Bob's connector output. Connector outputs from different
> deposits can be used as inputs into the same transaction, merging their
> histories. This allows all operations made by Alice to be fully atomic,
> ensuring that she doesn't lose any money during a reorg of any length.
>
> 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.
>
> [1] https://twitter.com/roasbeef/status/1661266771784126464
>
> [2]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021710.html
>
> [3]
> https://min.sc/#c=pk(B) %26%26 (older(1 day) || pk(A))

2023-06-08 01:13:19 CEST

- reply

📅 Original date posted:2022-09-11
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220911/5966df87/attachment.html>

2023-06-08 01:12:41 CEST

- reply

📅 Original date posted:2022-08-16
📝 Original message:(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 <pub1> <pub2> ... <pubn> 1 <a-signature> 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

2023-06-08 01:12:41 CEST

- reply

📅 Original date posted:2022-08-19
📝 Original message: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 "<PubKey 1> OP_CHECKSIG ... <PubKey N> OP_CHECKSIGADD OP_<N> 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 <PubKey> OP_CHECKSIG OP_1 OP_NUMEQUAL, which can be simplified to just <PubKey> 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, ali at 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 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 <pub1> <pub2> ... <pubn> 1 <a-signature> 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

2023-06-08 01:12:40 CEST

- reply

📅 Original date posted:2022-08-14
📝 Original message:[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 <hash-of-address-hash> OP_SWAP OP_HASH160 OP_EQUALVERIFY
- And the witness stack that will "spend" the transaction in the "to_spend" tx is simply:
<address-hash>
- 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 <delegation-txid>: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 <but is not a smart contract> - 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 the delegators, and the hash-of-address-hash does not necessarily have to represent a person, it can also represent a service.
FAQ:
Q: Does this utilize the Full format?
A: Yes.
Q: How to represent the delegation in a signed transaction?
A: Just encode the hash-of-address-hash in Bech32 version 0 and put it in the Address field.
Q: If the delegation is private, then how can the address-hash be known and the transaction signed?
A: The UTXO signers take a random address associated with them <could be one of their own address, could be the address of a multisig that is being used elsewhere etc.> and then make the hash160 of that address. Whoever they give this to, can sign a BIP322 transaction.
Q: How can the public verify a delegated BIP322 transaction if the address-hash is private?
A: The hash-of-address-hash is revealed in the Address, not in the Signature. BIP322 states that the signature only contains the "to_sign" transaction, which does not contain the witness stack of "to_spend" that has the hash-of-address-hash (because THAT was already spent in "to_spend") therefore the address hash is Bech32 (version 0) encoded and can be decoded to re-construct "to_spend" transaction and from there "to_sign".
Q: How to differentiate between non-delegated and delegated signatures?
A: You can't. But then again, BIP322 doesn't differentiate between "message signatures from an address" and a signature from a set of UTXOs so it wouldn't be able to identify a delegated transaction anyway.
Rather, a full-blown verification software should present a list-box or a set of radio buttons, that toggles between "Legacy", "Simple", "Full", "Full with UTXOs" and "Full with Delegation" - Each of these controls the content in the Address field - this would already be required to support validating Legacy signatures anyway, which are otherwise incompatible with the transaction-based signing (and this is the workaround BIP322 specifies to support that).
Q: What if the verifier does not have a UTXO set (light clients)?
A: Then present three toggles or radio buttons: "Legacy", "Simple", and "Delegated" - each of these options only require a single encoded address to be specified in the field, and Full, and Full With UTXOs signatures can be wrapped with a delegation to support a single address. Consequentially, these control how the signed transaction is [re]constructed for sign/verify.
CC'ing Kalle as he might be interested in this.
- Ali

2023-06-08 01:12:37 CEST

- reply

📅 Original date posted:2022-08-10
📝 Original message:> 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 <signature> <pubkeyhash> 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, vjudeu at 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 <bitcoin-dev at lists.linuxfoundation.org> 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

2023-06-08 01:12:37 CEST

- reply

📅 Original date posted:2022-08-09
📝 Original message: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

2023-06-08 01:12:30 CEST

- reply

📅 Original date posted:2022-08-05
📝 Original message:> 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 <luke at dashjr.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220805/bc680629/attachment.html>

2023-06-08 01:12:29 CEST

- reply

📅 Original date posted:2022-08-04
📝 Original message: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

2023-06-08 01:12:29 CEST

- reply

📅 Original date posted:2022-08-05
📝 Original message: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 <luke at dashjr.org> 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-08 01:12:18 CEST

- reply

📅 Original date posted:2022-07-28
📝 Original message: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)''<ref>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.</ref>.
* Let ''rand = hashBIP0340/nonce(t || bytes(P) || m)''<ref>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.</ref>.
* Let ''k' = int(rand) mod n''<ref>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'').</ref>.
* 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, abort<ref>Verifying 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.</ref>.
* 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 message has come from a specific address. Granted, this is malleable, since the signing isn't technically done with address, but with public keys in the case of both ECDSA and Schnorr, so a legacy address which validates a message implies that its corresponding segwit addresses can also validate it, since they all share the same public key. In the case of Taproot, if somebody wanted to verify that a message indeed came from a taproot address, 'Signature' can be overloaded by concatenating the Schnorr signature and public key together like this:
(e,s) or (R,s) || public key
And the public key sent to the verification algorithm. The signature will still be a fixed-size payload. It is true that it destructs the "zero-knowledge" benefit with Schnorr signatures, but this will allow maximum compatibility with ECDSA address verification. After all, hasn't BIP340 itself made tradeoffs of its own to preserve compatibility with ECDSA message generation, such as choosing the parity of Y coordinates?
The truth is, is that you can't verify an address message without general knowledge of the public key. And zero-knowledge signatures such as Schnorr completely disallow for that. Given that it is highly likely that future address types will also make use of Schnorr signatures, and the growing disproportion between legacy addresses and the rest of the addresses requires that the community make a choice regarding message signatures now - Do they really want them, or not?
========
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.
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 (which, in my view, is redundant - there is already the draft BIP322 which can verify anything and everything, but nobody is implementing that, just like BIP340).

2023-06-08 01:11:57 CEST

- reply

📅 Original date posted:2022-07-20
📝 Original message:[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?

2023-06-08 00:57:04 CEST

- reply

📅 Original date posted:2021-07-12
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210712/0c857f86/attachment.html>