That makes no sense; fe_mul just multiplies two field elements modulo p. That R constant is an implementation detail, that even differs between 32-bit and 64-bit platforms. It's not actually multiplying the result by this value.

Note that field elements are internally stored in a denormalized representation where the limbs can overflow. If you want to convert it to a portable format, use fe_get_b32.

Perhaps you should open an issue or discussion topic (https://github.com/bitcoin-core/secp256k1/issues or https://github.com/bitcoin-core/secp256k1/discussions/categories/q-a) on the library, because that's definitely not supposed to happen.

It's okay if you don't feel this terminology is warranted. Do you disagree it is useful abstraction?


A template-matching based verifier will only be compatible with a subset of potential BIP322 signatures, reporting "inconclusive" for others. That's the price for not having a full script interpreter.

But even if *all* implementations use just template-matching based verification, this approach still has the advantage of defining a single format that is compatible with *all* potential future extensions that correspond to script features. Because addresses are encodings of scripts, and what we're signing for is the ability to spend outputs sent to a certain address, using script for the message signing too is just the obvious match in my view.


I believe it is entirely uninteresting to work on any kind of message signing system that is restricted to a subset of what script can do. That is postponing another inevitable future problem again, when that subset no longer suffices.

The Bitcoin script system *is* a (programmable) digital signature scheme on its own, which achow101 is referring to as "script signatures". This digital signature scheme is distinct from the ECDSA/Schnorr signature algorithms available in Bitcoin script (but builds upon it).

• The "public keys" of this digital signature scheme are the scriptPubKeys in transaction outputs.
• The "messages" of this scheme are the spending transactions, excluding witness data.
• The "signatures" of this scheme are the scriptSigs and witnesses in transaction inputs.

It's a programmable signature scheme in that it supports more complex assertions than "a single party with key X agrees"; e.g. it can express agreement of multiple parties (using e.g. a P2SH scriptPubKey with a redeemscript that requires signatures with multiple keys). The actual script semantics are more-or-less irrelevant for this. It just suffices to express the kinds of assertions we care about.

BIP322 is taking this script signature system, and transposing it to a different context: messages that aren't transactions. Everything else remains the same: the scriptPubKeys remain the "public keys" verified against (=addresses), the "signatures" remain scriptSigs/witnesses (but now embedded in a BIP322 signature encoding, rather than being placed in a transaction). However, the "messages" are replaced with a virtual transaction derived from the message being signed, rather than any real transaction. This permits reusing all the script logic a signer and/or verifier may have (however complex or simplistic that may be) for transactions to be immediately applied to messages.

No new opcodes are needed or involved - the only thing that changes is that in BIP322 context, OP_CHECKSIG (and friends) don't compute a sighash from a spending transaction, but from a virtual transaction that is derived from the message being signed. If you want to BIP322-sign for "I have the ability to spend funds sent to address X" with message M, all you need to do is demonstrate your ability to "spend" funds sent to X, using a virtual transaction that commits to M. If you have the capacity (in terms of access to private keys, and in terms of having signing algorithms for it) to do that for the script corresponding to X (whether that's a simple single-key constructor, or something far more complicated) for real transactions, you also have the ability to do that for this BIP322 virtual transaction.

I don't understand any of the concerns brought up here. AFAICT, the only thing necessary to move BIP322 forward is finalizing the last details of the specification, and implementing it (which may mean bring the Bitcoin Core implementation up-to-date, if BIP changes are made, and/or implementations for other software, which may be template based).

I'm not sure about papers. Some of the low-level field arithmetic in libsecp256k1 was inspired by techniques used in certain curve25519/ed25519 implementations, but it has certainly evolved from there, with many optimizations by several contributors.

I came up with the bracket notation, and it isn't an optimization; just a concise way of of writing down the data flow to allow (humans) to reason about the correctness of the algorithm.

See https://en.bitcoin.it/wiki/Bech32_adoption for a continuously maintained list.

Oh, I had missed part of the question. I don't recall why the documentation limits to 0x7FFF; either it was just to be conservative and not "leak" a constraint from either of the field implementations into the interface, or it was so an int on platforms with 16-bit int could be used.

Regarding the ranges of permitted magnitudes: indeed, the point is to avoid carries in additions. By having even just a few slack bits in every limb, it's possible to have field elements with a temporarily "denormalized" representation (where the individual limb values exceed 2^26 or 2^52). The restrictions on how much they permit exceeding that 2^26 or 2^52 depends mostly on the multiplication code, with is optimized to take advantage of these limits.

Interesting question!

The reason for the restriction is simply to keep secp256k1_fe_set_int simple. Field elements are represented as 10 26-bit or 5 52-bit limbs internally, so restricting the function to only accept inputs that can be represented by a single limb means the function can just set all limbs to 0 and set the bottom one to the provided value.

Now in retrospect, it does seem that this function is rather pointless. It's currently only used for setting values to 0 or to 1 anymore. That used to be different; early on we e.g. didn't have a mechanism for constructing compile-time constants, and e.g. the B constant in the curve equation (y^2 = x^3 + B, with B=7 for secp256k1 proper) didn't exist until fairly recently.

I'm now considering adding a constant secp256k1_fe for 0 (a constant for 1 already exists), and removing the function. Thanks for the observation!

The statement above is false. The signatures are still hashed and committed to by blocks. No immutability is lost. If you don't believe me, please read BIP 141 carefully:



The data is removed from the transaction merkle tree, and instead committed to in the witness merkle tree. That witness merkle tree is committed to in the coinbase.

The only thing the 'SegWit semi-ligh' client you describe can do is verify that no historical inflation occurred. It cannot be used to verify incoming SegWit payments in a meaningful way beyond what a light client today can do, so it's useless for any economically relevant entity to rely upon.


Perfectly clear, but I disagree. Nodes can already prune history, and I think in the future nearly every node will. This does not impact security, as they still download and verify everything. If you feel like running a 'semi-ligh' node which is basically useless, still needs to maintain the full UTXO set (likely the largest resource cost of running a node in the near future), and in return only get a small constant factor of bandwidth reduction, be my guest.


No, it's a technicality. The same data is still committed to in the wtxid. It's just moved.


This is wrong. The witnesses are committed to by the wtxid, which are included in the witness merkle tree, which is committed to by the coinbase, which contributes to the block header.

You cannot change a witness and expect a block to still be valid, except to your pointless 'semi-ligh' node.


Again, nodes already don't have any obligation to store signatures (or anything) for future use.

That's a nonsensical security model. You're allowing an attacker to take anyone's money with invalid signatures, but not spend it twice? He'll just pay you and then steal the money back. No need for a double spend.

Without the ability to validate signatures, you can effectively not validate any useful property of the system. If that's the model you want, it already exists, and it's called a light client. All SegWit does in this regard is reducing the bandwidth for such nodes. It doesn't change the requirements for nodes that do need to validate.


There is just as much proof in SegWit transactions as in others. The only difference is that it does not contribute to the txid. It's still included in transactions and blocks, it's still required for validation, and it's still committed to.

There is indeed a new storage model possible where someone chooses to delete old signatures but not delete the rest. However (1) there is already no guarantee that nodes keep around everything for you, and if you want proof in the future that a transaction took place you'll need to keep it yourself (which every wallet software does) (2) that new model is only useful for serving light clients that already don't care about the signatures anyway.

Validating nodes need to download and verify the signatures. This is true now, and will be true after SegWit.

Validating nodes do not need to keep signatures around after validation. This is true now (pruning), and will be true after SegWit.

Anyone who has a transaction included in the chain can construct a proof that this happened (SPV proof), and this proof includes the signature that was used. This is true now, and will be true after SegWit (using the wtxid merkle tree instead of the txid merkle tree).

That's not correct. Floyd's cycle-finding algorithm can be used to find colliding script hashes with O(1) memory, for just a factor 3 slowdown.

From the point of view of old clients, segwit adds one coinbase output that contains the root hash of the Merkle tree that commits to the witness transaction ids. It uses 47 extra bytes per block, so technically, yes, it "wastes precious blockchain space". The blockchain on-disk can be pruned though (implemented as an experimental feature in Bitcoin Core 0.11, and with nearly full functionality in 0.12), so calling it "permanently" is not very accurate.

If you're talking about storage space used by segwit-compatible full nodes, well, obviously it will use more space, because it increases block capacity - that capacity has to go somewhere. However:

• The extra space used by witnesses is more prunable than normal block space, as it's not needed by non-validating clients.
• Has less effect on bandwidth, as light clients don't need the witness data.
• Has no effect on the UTXO set, so does not contribute to database growth and/or churn.
• Enables script versions, which will make the introduction of Schnorr signatures much easier later on, which are more space efficient than what we have now (even for simple single-key outputs/inputs).

Running with -testnet is default. You can run with -notestnet, but this will result in an error, as the "main chain" code is disabled in all but the unit tests.

For the features, look here: https://github.com/ElementsProject/elementsproject.github.io/blob/master/README.md

The peg is two-way, but relies on a federation of functionaries that hold the coins in multisig and verify transfers.

On the sidechain side, a 21M UTXO entry is awarded to the functionaries, who transfer coins out of it whenever transfers on the Bitcoin side into the sidechain happen.

Indeed.

Signed blocks are blocks where the proof-of-work mechanism is replaced with a traditional signature. Block creation, for test purposes, is done by a federation as well, rather than by mining.

Hard to say without seeing the script...

See any of these graphs (different time ranges):
http://bitcoin.sipa.be/ver-2k.png (1 week)
http://bitcoin.sipa.be/ver-10k.png (5 weeks)
http://bitcoin.sipa.be/ver-50k.png (half a year)
http://bitcoin.sipa.be/ver-ever.png (since genesis)

I guess some comments here would help. It's just guaranteeing a print of 3 significant digits, so it counts how many places to shift the comma by to bring the number between 100 and 999.....

This is not technically true anymore. Since recently, there is a full RFC6979 implementation inside libsecp256k1, with test vectors that were generated by another implementation (feel free to review it; it's too recent to go in Bitcoin Core v0.10.0 still, though). The reason for this change was making sure that the easiest way for using the library is always safe - the old API allowed you to shoot yourself in the foot if you passed in a bad nonce.