<unnamed>

Public Key

npub1uxks6rvrzqljyfp92sffgqypf8fpts0pv2dshvmmnrse76v0avlqy7wq7p

Profile Code

nprofile1qqswrtgdpkp3q0ezysj4gy55qzq5n5s4c8sk9xctkdae3cvldx87k0spz4mhxue69uhhyetvv9ujumn0wd68ytnwv46qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpp4mhxue69uhkummn9ekx7mqnkytxl

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-08 01:00:39 CEST

- reply

📅 Original date posted:2021-11-24
📝 Original message:Hi Andrew,
I'm confused why PSBT_IN_TAP_BIP32_DERIVATION and PSBT_OUT_TAP_BIP32_DERIVATION
contain not just the derivation path for the xonlypubkey, but also the tapleaf merkle path.
First I thought it was perhaps necessary in order for a signer to guess which
script leaves it can sign with its own keys. But you can't really know that without
actually seeing the script. When a signer looks at a script, it presumably already
knows the leaf path.
- Sjors
> Op 22 jun. 2021, om 23:22 heeft Andrew Chow via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
> Hi All,
>
> I would like to propose a BIP which defines new fields for Taproot
> support in PSBT.
>
> The full text is below, and the rendered file can be found at
Now at: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki <https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki>
> -
> | Taproot Key BIP 32 Derivation Path
> | <tt>PSBT_IN_TAP_BIP32_DERIVATION = 0x16</tt>
> | <tt><xonlypubkey></tt>
> | The 32 byte X-only public key
> | <tt><hashes len> <leaf hash>* <32-bit uint> <32-bit uint>*</tt>
> | A compact size unsigned integer representing the number of leaf
> hashes, followed by a list of leaf hashes, followed by the master key
> fingerprint concatenated with the derivation path of the public key. The
> derivation path is represented as 32-bit little endian unsigned integer
> indexes concatenated with each other. Public keys are those needed to
> spend this output. The leaf hashes are of the leaves which involve this
> public key.
> |-
> | Taproot Key BIP 32 Derivation Path
> | <tt>PSBT_OUT_TAP_BIP32_DERIVATION = 0x07</tt>
> | <tt><xonlypubkey></tt>
> | The 32 byte X-only public key
> | <tt><hashes len> <leaf hash>* <32-bit uint> <32-bit uint>*</tt>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211124/44e36110/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211124/44e36110/attachment.sig>

2023-06-08 00:51:18 CEST

- reply

📅 Original date posted:2021-04-09
📝 Original message:Thanks for the detailed response. Just 1 thing I needed to clarify:
> To the list of concerns at the top of the BIP, I would add one: losing multisig setup context. E.g. in the event of a fire where you only recover your steel engraved mnemonic(s), but no longer have the wallet descriptors.
>
> Good point.
>
>
> If you still have all devices and know (or guess) the threshold then BIP48 and sorted_multi descriptors will save you. But if you have a 2-of-3 setup and lost 1 device then without the metadata your coins are lost. In a future with musig(?) and miniscript increasingly the setup data is just as critical as the seeds.
>
> How so? Each signer device should ideally have a copy of the multisig configuration. If you lose 1 device in a 2-of-3, you can still spend from the wallet? Unless I'm missing something here.
I was thinking about a scenario where all devices are destroyed. All you have left are the mnemonics. But indeed if at least one of your devices is still intact AND it has the configuration, you're also good.
But there are plenty of devices out there that can't do this. Those devices can still be useful, even if they can't fully check everything.
Sjors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210409/7ec8f067/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210409/7ec8f067/attachment.sig>

2023-06-08 00:51:17 CEST

- reply

📅 Original date posted:2021-04-09
📝 Original message:Hi all,
First of all thanks for your continued work on standardising multisig setup.
The use case I personally find most interesting is not a multi-party setup, but rather just combining a bunch of my own devices. Those might even be in the same room during the setup, only to be moved to my moon base later.
This means I've paid less attention to the encryption scheme, so I might set TOKEN=0, but nevertheless I am skeptical about it. The first step is for the Coordinator to generate a TOKEN, presumably using its own entropy. But IIUC anyone who intercepts that token can decrypt any future step in the setup process. This suggests a chicken-egg problem where you need some pre-existing secure communications channel.
To the list of concerns at the top of the BIP, I would add one: losing multisig setup context. E.g. in the event of a fire where you only recover your steel engraved mnemonic(s), but no longer have the wallet descriptors.
If you still have all devices and know (or guess) the threshold then BIP48 and sorted_multi descriptors will save you. But if you have a 2-of-3 setup and lost 1 device then without the metadata your coins are lost. In a future with musig(?) and miniscript increasingly the setup data is just as critical as the seeds.
A future standard (or extension of this one) should recommend an encryption convention for the descriptor data, ideally such that with *any* of the seeds you can decrypt a file that contains the full setup. That file could then just float redundantly around the internet and pieces of paper in various locations, without compromising privacy.
The proposed encryption system doesn't help with that though, because it's based on entropy from the Coordinator, rather than from the signers.
Smaller suggestions:
* link to this new mail thread in the BIP
* use magic bytes so .bsms so operating systems like Android / iOs can open the right app for them
* don't use separate file extensions for encrypted vs unencrypted content, just indicate somehow that a given field is encrypted
* although plain text files are handy for debugging, I think a binary format like PSBT is much powerful. Any device that can parse and write binary PSBT should be able to implement a similar parser / writer for a binary .bsms format.
* BIP48 and sorted_multi descriptors are useful in a loss-of-metadata scenario. The BIP uses both in the examples, but doesn't explictly endorse these derivations. It also contradicts them: "If the Signer chooses the path, it should try to avoid reusing XPUBs for different wallets.". Maybe this is out of scope.
* one way to resolve xpub reuse would be to make the "BIP48" path a function of the co-signer fingerprints and wallet threshold, but this requires an extra communication round
* there should be a way for signers to communicate their capabilities, perhaps with a different xpub for each potential scheme. E.g. there's m/48' native SegWit now, MuSig and/or or Tapleaf based multisig in the future, or even generic Miniscript support.
* the idea of only storing the receive descriptor, not the change descriptor, is fine by me, though I'd prefer an extension to the descriptor format to deal with this
Sjors
> Op 5 apr. 2021, om 09:02 heeft Hugo Nguyen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
> Hi all,
>
> Please find below the complete draft of the Bitcoin Secure Multisig Setup (BSMS) BIP. The spec has gone through a number of important updates in the last month or so. Thanks everyone who has participated in the review process.
>
> As a PR: https://github.com/bitcoin/bips/pull/1097
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210409/d254f217/attachment.sig>

2023-06-07 20:31:15 CEST

- reply

2023-06-07 20:31:14 CEST

- reply

2023-06-07 20:17:58 CEST

- reply

📅 Original date posted:2019-05-07
📝 Original message:Hey Pieter,
I think this is a reasonable collection of changes that make sense in combination. Some initial feedback and questions.
From the BIP:
> If one or more of the spending conditions consist of just a single key (after aggregation),
> he most likely one should be made the internal key. If no such condition exists, it may
> be worthwhile adding one that consists of an aggregation of all keys participating in all
> scripts combined; effectively adding an "everyone agrees" branch. If that is inacceptable,
> pick as internal key a point with unknown discrete logarithm (TODO).
I assume Luke Dashjr referred to the above when saying:
> Is there any way to use the Taproot construct here while retaining external
> script limitations that the involved party(ies) *cannot* agree to override?
> For example, it is conceivable that one might wish to have an unconditional
> CLTV enforced in all circumstances.
One reason why someone would want to avoid a "everone agrees" branch, is duress (or self-discipline, or limiting powers of a trustee). In particular with respect to time-locks.
Can this "unknown discrete logarithm" be made provably unknown, so all signers are assured of this property? Bonus points if the outside world can't tell. The exact mechanism could be outside the scope of the BIP, but knowing that it's possible is useful.
Perhaps Lightning devs have an opinion on "everyone agrees" with respect to hash pre-images. I suspect there is no benefit in guaranteeing that a pre-image must be revealed or a timeout must be waited for and there's no way around that condition.
Regarding usage of Schnorr: do I understand correctly that the "everyone agrees" internal key MUST use Schnorr, and that individual branches MAY use Schnorr, but only if they're marked as tapscript spend?
Why is tapscript not mandatory?
Misc details:
In the Design section under "Merkle branches" I suggest adding bullet points with short descriptions of "various known mechanisms for implementing this". In addition to "space savings" maybe also briefly mention a few other pros and cons, like implementation complexity and privacy. And then point out which one you picked.
In the Design section, explicitly point out you're no longer using the hash of a public key (can move some explanation up from rationale section). This is a significant change, even if you have good reason to believe it's perfectly safe.
Regarding the 64 byte SHA256(tag) || SHA256(tag) 64-byte long context-specific constant: maybe add that sha-2 block size is 512 bits
"Conceptually every Taproot output corresponds to" -> some of this conceptual stuff belongs in or before the Specification section. Try briefly explaining how tagged hashes and script validation (stack) interact, before specifying them in detail. The figure (without the pseudo-code) can be helpful for that.
In the figure with the merkle tree, the description says there's "3 script leaves.". So what's going on in leaf D? If it's a way to indicate an unused leaf, why is E different (or is also TapLeaf)? Maybe emphasize that "TapLeaf" tag is there so prove to all signers there's no secret conditions (the CVE-2012-2459 protection you refer to).
Sjors
> Op 6 mei 2019, om 22:17 heeft Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
> There are multiple references to "space savings", but no rationale for
> treating "space" as something to save or even define. The costs are in CPU
> time and I/O (which "space saving" doesn't necessarily reduce) and bandwidth
> (which can often be reduced without "space saving" in commitments). The
> proposal can apparently be made simpler by ignoring this irrelevant "space
> saving" goal.
>
> Tagged hashes put the tagging at the start of the hash input. This means
> implementations can pre-cache SHA2 states, but it also means they can't reuse
> states to produce data for different contexts. (I'm not sure if there is a
> use for doing so... but maybe as part of further hiding MAST branches?)
>
> Is there any way to use the Taproot construct here while retaining external
> script limitations that the involved party(ies) *cannot* agree to override?
> For example, it is conceivable that one might wish to have an unconditional
> CLTV enforced in all circumstances.
>
> It may be useful to have a way to add a salt to tap branches.
>
> Some way to sign an additional script (not committed to by the witness
> program) seems like it could be a trivial addition.
>
>
> On Monday 06 May 2019 17:57:57 Pieter Wuille via bitcoin-dev wrote:
>> Hello everyone,
>>
>> Here are two BIP drafts that specify a proposal for a Taproot
>> softfork. A number of ideas are included:
>>
>> * Taproot to make all outputs and cooperative spends indistinguishable
>> from eachother.
>> * Merkle branches to hide the unexecuted branches in scripts.
>> * Schnorr signatures enable wallet software to use key
>> aggregation/thresholds within one input.
>> * Improvements to the signature hashing algorithm (including signing
>> all input amounts).
>> * Replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD, to support
>> batch validation.
>> * Tagged hashing for domain separation (avoiding issues like
>> CVE-2012-2459 in Merkle trees).
>> * Extensibility through leaf versions, OP_SUCCESS opcodes, and
>> upgradable pubkey types.
>>
>> The BIP drafts can be found here:
>> * https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki
>> specifies the transaction input spending rules.
>> * https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki
>> specifies the changes to Script inside such spends.
>> * https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
>> is the Schnorr signature proposal that was discussed earlier on this
>> list (See
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.ht
>> ml)
>>
>> An initial reference implementation of the consensus changes, plus
>> preliminary construction/signing tests in the Python framework can be
>> found on https://github.com/sipa/bitcoin/commits/taproot. All
>> together, excluding the Schnorr signature module in libsecp256k1, the
>> consensus changes are around 520 LoC.
>>
>> While many other ideas exist, not everything is incorporated. This
>> includes several ideas that can be implemented separately without loss
>> of effectiveness. One such idea is a way to integrate SIGHASH_NOINPUT,
>> which we're working on as an independent proposal.
>>
>> The document explains basic wallet operations, such as constructing
>> outputs and signing. However, a wide variety of more complex
>> constructions exist. Standardizing these is useful, but out of scope
>> for now. It is likely also desirable to define extensions to PSBT
>> (BIP174) for interacting with Taproot. That too is not included here.
>>
>> Cheers,
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:16:49 CEST

- reply

📅 Original date posted:2019-03-08
📝 Original message:> (1) It has been well documented again and again that there is desire to remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in non-segwit scripts represents a rather significant vulnerability in Bitcoin today, and (3) lots of effort has gone into attempting to find practical use-cases for OP_CODESEPARATOR's specific construction, with no successes as of yet. I strongly, strongly disagree that the highly-unlikely remote possibility that someone created something before which could be rendered unspendable is sufficient reason to not fix a vulnerability in Bitcoin today.
>
>> I suggest an alternative whereby the execution of OP_CODESEPARATOR increases the transactions weight suitably as to temper the vulnerability caused by it. Alternatively there could be some sort of limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be executed per script, but that would require an argument as to why exceeding that limit isn't reasonable.
>
> You could equally argue, however, that any such limit could render some moderately-large transaction unspendable, so I'm somewhat skeptical of this argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined is rather difficult in any case.
Although I'm not a fan of extra complicity, just to explore these two ideas a bit further.
What if such a transaction:
1. must have one input; and
2. must be smaller than 400 vbytes; and
3. must spend from a UTXO older than fork activation
Adding such a contextual check seems rather painful, perhaps comparable to nLockTime. Anything more specific than the above, e.g. counting the number of OP_CODESEPARATOR calls, seems like guess work.
Transaction weight currently doesn't consider OP codes, it only considers if bytes are part of the witness. Changing that to something more akin to Ethereums gas pricing sounds too complicated to even consider.
I would also like to believe that whoever went through the trouble of using OP_CODESEPARATOR reads this list.
Sjors

2023-06-07 20:16:36 CEST

- reply

📅 Original date posted:2019-03-07
📝 Original message:Can you elaborate a bit on what kind of reject messages your users are getting? I assume the users wallet connects directly to the Bitcoin p2p network?
What does the wallet do when a transaction is rejected? Does it forget about it (that seems unsafe) or compose another one (with overlapping inputs)?
Sjors
> Op 6 mrt. 2019, om 17:49 heeft Andreas Schildbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
> Reject messages cannot be replaced for debugging user problems. At least
> unless you plan to make RPC or bitcoind logfiles available via the P2P
> protocol (both probably not a good idea).
>
> The typical case is, I get mailed a wallet logfile with reject messages
> and that's all I have. I cannot access the bitcoind logfile(s) of the
> node(s) that generated the reject message in the first place. Nor can I
> access their RPC interface.
>
> I strongly suggest re-enabling reject messages by default before 0.18.
>
>
> On 06/03/2019 01.53, Marco Falke via bitcoin-dev wrote:
>> Bitcoin Core may send "reject" messages as response to "tx", "block" or
>> "version" messages from a network peer when the message could not be accepted.
>>
>> This feature is toggled by the `-enablebip61` command line option and has been
>> disabled by default since Bitcoin Core version 0.18.0 (not yet released as of
>> time of writing). Nodes on the network can not generally be trusted to send
>> valid ("reject") messages, so this should only ever be used when connected to a
>> trusted node. At this time, I am not aware of any software that requires this
>> feature, and I would like to remove if from Bitcoin Core to make the codebase
>> slimmer, easier to understand and maintain. Let us know if your application
>> relies on this feature and you can not use any of the recommended alternatives:
>>
>> * Testing or debugging of implementations of the Bitcoin P2P network protocol
>> should be done by inspecting the log messages that are produced by a recent
>> version of Bitcoin Core. Bitcoin Core logs debug messages
>> (`-debug=<category>`) to a stream (`-printtoconsole`) or to a file
>> (`-debuglogfile=<debug.log>`).
>>
>> * Testing the validity of a block can be achieved by specific RPCs:
>> - `submitblock`
>> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
>> potentially invalid POW
>>
>> * Testing the validity of a transaction can be achieved by specific RPCs:
>> - `sendrawtransaction`
>> - `testmempoolaccept`
>>
>> * Wallets should not use the absence of "reject" messages to indicate a
>> transaction has propagated the network, nor should wallets use "reject"
>> messages to set transaction fees. Wallets should rather use fee estimation
>> to determine transaction fees and set replace-by-fee if desired. Thus, they
>> could wait until the transaction has confirmed (taking into account the fee
>> target they set (compare the RPC `estimatesmartfee`)) or listen for the
>> transaction announcement by other network peers to check for propagation.
>>
>> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless there are
>> valid concerns about its removal.
>>
>> Marco
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 20:14:40 CEST

- reply

📅 Original date posted:2018-09-10
📝 Original message:> Op 30 aug. 2018, om 22:24 heeft Ryan Havar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
> ==Motivation==
>
> One of the most powerful heuristic's employed by those whose goal is to undermine
> bitcoin's fungiblity has been to assume all inputs of a transaction are signed by
> a single party. In the few cases this assumption does not hold, it is generally
> readibly recognizable (e.g. traditional coinjoins have a very obvious structure,
> or multisig outputs are most frequently validated onchain).
In addition to mixers, custodial wallets and exchanges also contribute to breaking this heuristic; even though there’s a single entity signing multiple inputs, that entity doesn’t represent a single owner of the funds. As with mixers, exchanges and custodial wallets can sometimes be spotted as well, but we don’t know what percentage is missed.
Breaking this heuristic at scale would be good, but do we know to what degree it’s already broken? Is there any empirical research measuring its accuracy and false positive rate?
> Should bustapay enjoy widespread adoption, a "v2" specification
> will be created with desired extensions.
I would not put future promises in a BIP. Rather, explain how extension might work.
> ==Specification==
>
> A bustapay payment is made from a sender to a receiver.
>
> Step 1. Sender creates a bitcoin transaction paying the receiver
>
> This transaction must be fully valid, signed and all inputs must use segwit. This transaction is known as the "template transaction”.
Using PSBT?
> This transaction must not be propagated on the bitcoin network.
This can’t be guaranteed, and even after step 5 a reorg could cause it to get confirmed. It’s useful to explain why this doesn’t matter.
>
> Step 2. Sender gives the "template transaction" to the receiver
>
> This would generally be done as an HTTP POST.
> The exact URL to submit it to could be specified with a bip21 encoded address. Such as bitcoin:2NABbUr9yeRCp1oUCtVmgJF8HGRCo3ifpTT?bustapay=https://bp.bustabit.com/submit <https://bp.bustabit.com/submit> and the HTTP body should be the raw transaction hex encoded as text.
This seems too detailed. If you want to specify the message protocol, maybe that can have it’s own section where you list each of the messages, the URL, parameters and encoding. Then you can keep this overview section shorter.
The use of HTTPS kind of forces sender and recipient to use a 3rd party service, even though this could done bilaterally. What if the payment request contained a (single-use) Onion URL an expiration date? The recipient would have to keep a hidden service up until the expiration date, though the sender could try again if there’s temporary reachability issue.
Adding a (onion) URL to the the payment request also makes gradual adoption easier, because recipients don’t need to worry if senders support this protocol.
> Step 3. Receiver processes the transaction and returns a partially signed coinjoin
>
> The receiver validates the transaction is valid, pays himself and is eligible for propation. The receiver then adds one of his own inputs (known as the "contributed input") and increase the output that pays himself by the contributed input amount. Doing so will invalidate the "template transaction"'s original input signatures, so the sender needs to return this "partial transaction" back to the receiver to sign. This is returned as a hex-encoded raw transaction a response to the original HTTP POST request.
> * Bustapay could be abused by a malicious party to query if you own a deposit address or not. So never accept a bustapay transaction that pays an already used deposit address
Indeed, once the recipient adds funds, they reveal more about themselves to the sender then they would otherwise. I think that needs more elaboration.
I assume the transaction in step (1) is some sort of collateral to insure they’re not just trying to extract private information from you? However if fees are low they could still double-spend it after the recipient revealed their address, especially because the recipient has no way of RBF’ing the original (though CPFP could help). Perhaps require that the original transaction pays a fee based on the expected size of the final transaction?
>
> Notes for sending applications:
>
> * The HTTP response must *not* be trusted. It should be fully validated that no unexpected changes have been made to the transaction.
Not trusting anything is obvious. :-) It’s better to explicitly state what exactly needs to be verified (amounts, destinations, inputs, etc), and maybe list a few obvious shenanigans to watch out for.
A more general concern is that the sender can’t know for sure the recipient really supports this protocol, so it should assume that whatever information it pings to some API could be used maliciously. In what ways could it be abused?
Sjors
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180910/d1d40a7e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180910/d1d40a7e/attachment.sig>

2023-06-07 20:13:38 CEST

- reply

📅 Original date posted:2018-07-14
📝 Original message:> Op 6 jul. 2018, om 20:08 heeft Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
> Hello everyone,
>
> Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures,
> over the same curve as is currently used in ECDSA:
> https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki
The power of simplification at work, thanks Pieter!
Questions:
Regarding verification: why does bytes(P) use compressed key serialization rather than the implicit Y coordinate used for signing? I understand space savings don't matter since these values don't end up on the blockchain. Is it just easier to implement or is it faster?
Regarding rationale for choosing (e,s) vs. (R,s), you say that (e,s) "avoids the difficulty of encoding a point R in the signature". But since e = H(sG - eP || m) also involves converting a point to some byte encoding in order to hash it, how much difficulty is actually avoided? Is that, like for previous question, because you could get away with compressed keys rather than implicit Y coordinates?
Regarding batch verification: "randomly generated independently for each batch of verifications" - by whom? I assume randomly picked by the verifier?
Regarding random number used for signing. The suggested (?) deterministic algorithm to derive secret key ''k'' from the private key ''d'' seems similar to RFC6979. Maybe it's useful to briefly explain the difference, as well as your rationale for not making it mandatory (presumably the same as why RFC6979 isn't mandatory although most (?) wallets use it).
Nits:
* Motivation: "signatures ... These are standardized", but the "standardized" link points to the secp256k1 curve parameters, not to anything signature related afaik
* "message m: an array of 32 bytes", maybe add "typically the sha256 hash of the transaction components commited to by SIGHASH_TYPE”
* I left a few even smaller nits as a PR: https://github.com/sipa/bips/pull/10
Cheers,
Sjors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180714/065df004/attachment.sig>

2023-06-07 20:09:59 CEST

- reply

📅 Original date posted:2018-01-28
📝 Original message:I can see how merging after the fact could be more practical than appending existing transactions.
I think what Moral Agent suggested is the same as your original proposal, namely dropping rule 3. Only fee per weight unit increase from rule 4 would matter.
The minimum per WU increase could be far higher than the minimum relay fee. The few times I’ve used RBF in practice I increased the fee by at least 50%. Rule 4 could be made more strict. I don’t know what number, if any, would address concerns about relay spam?
This wouldn’t be backward compatible. Does that matter as long as there’s enough nodes that follow the new rules? Is there a punishment for relaying transactions that violate rule 3? Could a recipient using the older rules be mislead (in a way that’s worse than the fact that RBF allows the sender to replace the transaction with anything they want anyway)?
Peter Todd wrote:
> You'd also be able to push others' txs out of the mempool.
Can you elaborate on this issue?
And wrote:
> payment service for instance where a large number of deposits are aggregated into a smaller number of payments
So this would involve wallets (of users who deposit coins) cooperating with an exchange API to consolidate in-mempool transactions?
And wrote:
> In fact I considered only requiring an increase in fee rate, based on the
theory that if absolute fee went down, the transaction must be smaller and thus
miners could overall earn more from the additional transactions they could fit
into their block. But to do that properly requires considering whether or not
that's actually true in the particular state the mempool as a whole happens to
be in, so I ditched that idea early on for the much simpler criteria of both a
feerate and absolute fee increase.
Why would you need to consider the whole mempool? Let’s say a miner is considering to replace transaction A and B with transaction C, where C pays a higher fee per byte than both A and B. This creates space for ~ one additional transaction in the block. It seems to me the miner only needs to check that the lowest fee per weight transaction > min_fee(A,B). At least in first approximation.
Sjors
> Op 24 jan. 2018, om 17:05 heeft Rhavar via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
>
>> I'm confused, the mempool only sees 1 transaction at a time, first A, then later B. "the original transactions", plural, should not exist in the mempool.
>>
>> B's fee and rate needs to be larger than A's, but B will be greater than or equal to A anyway. So, just increasing the fee rate will cause a larger fee anyway.
>>
>> Am I missing something?
>
> Kind of. The first case is that you do the "smarter" type of merging, where you get an original transaction and then say add an additional output(s) to it.
>
> The issue with this, is from a practical perspective is _very_ complex. Because you really need to do a lot of tracking to see which of the two transactions actually confirm. And if you are promising fast payments, you can be stuck in a weird limbo state where you're waiting for the original one to "safely" confirm before it's safe to make a re-payment (even a non-malicious will likely contain the replacement).
>
> bip125 already supports this use-case, but I will suggest that the logic to deploy this is sufficiently complex that no one is going to attempt any time in the near future.
>
>
> But "retroactive transaction merging" is actually pretty approachable problem for a service to implement. You just get N valid transactions you've made, merge them into one. Strip extraneous inputs[1], and combine and alter the change amount.
>
> The reason this is so appealing to implement, is there is very little complexity. If the "retroactive transaction merge" fails, or doesn't get confirmed, it actually has no impact. If it does get confirmed, that's just pure cost-savings.
>
> However, the rules of bip125 currently make it (unnecessarily?) unappealing, because I can never lower the absolute amount of fees I pay. Hence I think it'd be pretty sweet if they could be relaxed to support this if it can be done in a pretty risk free way.
>
>
>
> [1] Need to be very careful with that, if you're ever merging a merged transaction.
>
>
>>
>>
>> On Wed, Jan 24, 2018 at 3:44 AM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> On Tue, Jan 23, 2018 at 10:49:34PM +0000, Gregory Maxwell via bitcoin-dev wrote:
>>>> On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
>>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>> Interesting. I didn't think about this before, but it seems like bip125 is
>>>>> rather incentive incompatible right now? If we're assuming a competitive
>>>>> mempool, it really doesn't seem generally rational to accept a replacement
>>>>> transaction of a lower fee rate.
>>>>
>>>> BIP125 replacement requires that the fee rate increases. The text of
>>>> the BIP document is written in a confusing way that doesn't make this
>>>> clear.
>>>
>>> In fact I considered only requiring an increase in fee rate, based on the
>>> theory that if absolute fee went down, the transaction must be smaller and thus
>>> miners could overall earn more from the additional transactions they could fit
>>> into their block. But to do that properly requires considering whether or not
>>> that's actually true in the particular state the mempool as a whole happens to
>>> be in, so I ditched that idea early on for the much simpler criteria of both a
>>> feerate and absolute fee increase.
>>>
>>> --
>>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>>

2023-06-07 20:07:52 CEST

- reply

📅 Original date posted:2017-11-21
📝 Original message:I came across the proposed Bitcoin Core implementation of BIP159 [0] in this PR [1]. The goal is to allow pruned nodes to "serve a limited number of historical blocks" (as opposed to none at all).
It contains a counter-measure for peer fingerprinting. I'm trying to understand how that impacts extendibility.
> Peers may have different prune depths (depending on the peers configuration,
> disk space, etc.) which can result in a fingerprinting weakness (finding the
> prune depth through getdata requests). NODE_NETWORK_LIMITED
> supporting peers SHOULD avoid leaking the prune depth and therefore
> not serve blocks deeper then the signaled NODE_NETWORK_LIMITED
> thresholds.
This means pruned nodes can only serve the last 288 blocks:
> If signaled, the peer MUST be capable of serving at least the last 288 blocks (~2 day
As the blockchain keeps growing there will be ever more pruned nodes (perhaps offset by new nodes with more storage). Although a strict improvement over todays situation, it seems a bit wasteful to have a node with 10-100 GB of storage only be able to share the most recent 288 blocks.
It would be nice if a future extension of this BIP allows more flexibility. To limit the ability to fingerprint nodes, we could limit the number of choices to e.g. 288 + 1000 * 2^n. That yields only 8 possibilities at the current chain size. A slightly better formula could take into account typical hard drive size increments, leaving enough space for the OS and other data. Node operators could opt-in to this if they think the increased fingerprint risk outweighs their desire to share archived blocks.
I can also imagine - but not implement :-) - a future scenario where nodes prune a random subset of their chain, meaning that even nodes with little storage can be of help during Initial Blockchain Download (IBD) of other nodes.
How would such extension be signaled for? Would we need a whole new version bit?
Would upgraded nodes need a new message type to communicate the chosen prune depth? Or can that information tag along some existing message?
Jonas Schnelli pointed out on the Github discussion that waiting for BIP150 would be appropriate. Can you explain how this is related? Although I can see why whitelisted peers can be exempted from the anti-fingerprinting measure, I would not want to restrict it to just those.
Some minor suggestions for improving the BIP itself:
* add link to mailinglist discussion(s) in reference section
* explain that 288 is not just the minimum limit for Bitcoin Core, but also the bulk of traffic (as I understand from earlier discussion [2])
Cheers,
Sjors
[0] https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki
[1] https://github.com/bitcoin/bitcoin/pull/10387
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/thread.html#14315
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171121/0bd335ba/attachment.sig>

2023-06-07 20:07:36 CEST

- reply

📅 Original date posted:2017-11-09
📝 Original message:> Op 9 nov. 2017, om 21:45 heeft Jacob Eliosoff via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
> As I understand you, a private key in cold storage would (of course) remain valid across HFs, but an address would be valid only for the nForkId it was generated for. There may be cold-storage-type cases where it's important for an address to be valid across all chains, ie, to intentionally allow replay? But I guess this could just be a special nForkId value, say -1?
If I understand the proposal correctly, you can always spend coins; it's the next transaction that is replay protected.
I like the idea of specifying the fork in bech32 [0]. On the other hand, the standard already has a human readable part. Perhaps the human readable part can be used as the fork id?
Note that in your currently proposal nForkId is only in the transaction signature pre-image. It's not in the serialized transaction, so a node would just have to try to see if the signature is valid. I don't know if that's a problem.
Can you clarify what you mean with:
> Allowing signatures with `nForkId=1` can be achieved with a soft fork by incrementing the script version of SegWit, making this a fully backwards compatible change.
What's the purpose of nForkId 1?
> potentially a way to opt-out of replay protection of any fork, where deemed necessary (can be beneficial for some L2 applications).
Can you give an example of where this opt-out would be useful? Why wouldn't it be enough to just sign one transaction for each fork?
In Spoonnet, the version number is added to the SIGHASH_TYPE in the pre-image. Your solution of just adding another field seems easier, but maybe there's a downside?
Sjors
[0] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#Bech32
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171109/e5a52b05/attachment.sig>

2023-06-07 20:06:49 CEST

- reply

📅 Original date posted:2017-10-02
📝 Original message:Op 2 okt. 2017, om 03:56 heeft Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
>
> On Monday 02 October 2017 12:35:38 AM Mark Friedenbach wrote:
>>> b. OP_RETURNTRUE (Luke). I proposed this in an earlier version of BIP114
>>> but now I think it doesn’t interact well with signature aggregation, and
>>> I worry that it would have some other unexpected effects. c. Generalised
>>> NOP method: user has to provide the returned value, so even VERIFY-type
>>> code could do anything
>>
>> I see no reason to do either. Gate new behavior based on script execution
>> flags, which are set based on the script version. Script versions not
>> understood are treated as "return true" to begin with. The interpreter
>> isn't even going to try to decode the script according to the old rules,
>> let alone try to execute it, so there's no reason for the old soft-fork
>> compatability tricks.
>>
>> The new soft-fork trick is that you increment the script version number.
>> That is all.
>
> This breaks parallel softfork deployments.
If unknown script versions are treated as "return true", there's no need for versions to be deployed in sequence, right? Maybe they should be called numbered script types, rather than script versions.
Sjors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171002/99d0f6a0/attachment.sig>

2023-06-07 20:06:24 CEST

- reply

📅 Original date posted:2017-09-28
📝 Original message:Peter Todd wrote:
>
> Re-use of old addresses is a major problem, not only for privacy, but also
> operationally: services like exchanges frequently have problems with users
> sending funds to addresses whose private keys have been lost or stolen;
[...]
>
> To help combat this problem, I suggest that we add a UI-level expiration time
> to the new BIP173 address format. Wallets would be expected to consider
> addresses as invalid as a destination for funds after the expiration time is
> reached.
[...]
Perhaps outside the scope of BIP173, but what about baking it into the protocol? That way a transaction that's sent too late, simply won't get confirmed. This removes the need for refund logic or asking a customer to pay just a few extra cents. You could also disallow a second payment.
Two downsides I can think of:
* privacy, as differences in expiration policy would be visible on chain
* miners might be able to game it in their interaction with brokers
> Being just an expiration time, seconds-level resolution is unnecessary, and
> may give the wrong impression. I'd suggest either:
>
> 1) Hour resolution - 2^24 hours = 1914 years
> 2) Month resolution - 2^16 months = 5458 years
So that's 4.8 characters for hours, or 3.2 for years, plus checksum space? The shorter the better. Perhaps one or two bits can be used to specify an exponent; a large range seems more useful than high precision. For instance a merchant doesn't care if the customer pays within 10:00:00 minutes or 10:00:01 minutes and you wouldn't care if your address is valid 50 years or 50 years and 3 minutes. This point may be mute if minute level resolution is not practical.
> Both options have the advantage of working well at the UI level regardless of
> timezone: the former is sufficiently short that UI's can simply display an
> "exact" time (though note different leap second interpretations), while the
> latter is long enough that rounding off to the nearest day in the local
> timezone is fine.
>
> Supporting hour-level (or just seconds) precision has the advantage of making
> it easy for services like exchanges to use addresses with relatively short
> validity periods, to reduce the risks of losses after a hack. Also, using at
> least hour-level ensures we don't have any year 2038 problems.
Greg Maxwell wrote:
> One thing to keep in mind is that address format linked fields are
> most efficient if they're multiples of 5 bits. Perhaps use 1 bit to
> indicate an embedded amount and 19 bits of 1 day precision, resulting
> in a 1435 year span.
Is this because 5 bits are one bech32 character (2^5=32) or there is another reason? And does that include the space needed for the checksum?
Hopefully one day addresses can be abstracted away, because they really aren't what people intuitively think they are, but I don't see that happen on short notice. Until then they shouldn't exhibit "surprising" behavior.
Embedding amounts in an address could confuse people when they reuse it. Wallets would e.g. have to ignore the amount value if they previously sent money, but without changing the address string displayed in the UI.
> Keep in mind that high precision of the expiration times is asking the
> sender to have a higher precision of idea of the time, date only is
> kinda nice. I think shorter expiration times are unlikely to be
> useful due to clock skew-- you can't assume a signer has any access to
> the Bitcoin network at all.
Many merchant services and exchanges use 10-15 minute expiration though. At the wallet level, all sender and recipient need to agree on is their relative time. Fallback behavior for a signer with no access to time could be to ignore the deadline.
Andreas Schildbach wrote:
>
> This feels redundant to me; the payment protocol already has an
> expiration time.
The BIP-70 payment protocol has significant overhead and most importantly requires back and forth. Emailing a bitcoin address or printing it on an invoice is much easier, so I would expect people to keep doing that.
Sjors
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170928/48685946/attachment-0001.sig>