|
The multiple address output there is misleading and never should have been added in the first place.
The multiple addresses mean that it is a multisig so that txout requires some number (defined by the scriptPubKey) of the specified pubkeys to sign the spending transaction. There are no multiple UTXOs nor does the UTXO magically split for the cosigners. It is a single UTXO that requires multiple people to spend it. It's the same thing as a normal multisig in a P2SH or P2WSH, just that the "redeemScript" is in the scriptPubKey of the output, rather than the hash of it.
|
|
|
|
New paper from Jonas Nick, Tim Ruffing, and Yannick Seurin for a 2 round Schnorr Multisignature scheme based upon the original 3 round MuSig scheme. Abstract: Multi-signatures enable a group of signers to produce a single signature on a given message. Recently, Drijvers et al. (S&P'19) showed that all thus far proposed two-round multi-signature schemes in the DL setting (without pairings) are insecure under concurrent sessions, i.e., if a single signer participates in multiple signing sessions concurrently. While Drijvers et al. improve the situation by constructing a secure two-round scheme, saving a round comes with the price of having less compact signatures. In particular, the signatures produced by their scheme are more than twice as large as Schnorr signatures, which arguably are the most natural and compact among all practical DL signatures and are therefore becoming popular in cryptographic applications (e.g., support for Schnorr signature verification has been proposed to be included in Bitcoin). If one needs a multi-signature scheme that can be used as a drop-in replacement for Schnorr signatures, then one is either forced to resort to a three-round scheme such as MuSig (Maxwell et al., DCC 2019) or MSDL-pop (Boneh, Drijvers, and Neven, ASIACRYPT 2018), or to accept that signing sessions are only secure when run sequentially, which may be hard to enforce in practice, e.g., when the same signing key is used by multiple devices.
In this work, we propose MuSig2, a novel and simple two-round multi-signature scheme variant of the MuSig scheme. Our scheme is the first multi-signature scheme that simultaneously i) is secure under concurrent signing sessions, ii) supports key aggregation, iii) outputs ordinary Schnorr signatures, iv) needs only two communication rounds, and v) has similar signer complexity as regular Schnorr signatures. Furthermore, our scheme is the first multi-signature scheme in the DL setting that supports preprocessing of all but one rounds, effectively enabling a non-interactive signing process, without forgoing security under concurrent sessions. The combination of all these features makes MuSig2 highly practical. We prove the security of MuSig2 under the one-more discrete logarithm (OMDL) assumption in the random oracle model, and the security of a more efficient variant in the combination of the random oracle and algebraic group models.
https://eprint.iacr.org/2020/1261 |
|
|
|
I got the following output for git rev-parse HEAD. 0b2abaa666d6f3331e3246ffd64dd47946e9dcdf Possibly a SHA1 hash  It is, and that's what I was looking for. The exact version is "Bitcoin Core version v0.20.99.0-0b2abaa66" and I have not changed anything in the code so hopefully there shouldn't be any uncomitted changes. Bitcoin Core version v0.20.99.0-0b2abaa66
Copyright (C) 2009-2020 The Bitcoin Core developers
Please contribute if you find Bitcoin Core useful. Visit
<https://bitcoincore.org/> for further information about the software.
The source code is available from <https://github.com/bitcoin/bitcoin>.
This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING
or <https://opensource.org/licenses/MIT>
Doesn't look like there are any uncommitted changes.
I built this commit and it tested without any errors. As a basic troubleshooting step, I suggest that you first do make clean and then rebuild and test with make check. If it still fails, then I'll take a look at the config.log you linked earlier. |
|
|
|
|
What commit are you currently building? You can get this information by doing git rev-parse HEAD.
What is the exact version you are using (this will include the shortened git commit id and whether the build contains uncommitted changes)? You can get this by doing src/bitcoind -version, the full version number is in the first line.
|
|
|
|
|
It means that make check skipped those tests because an earlier unit test failed. You can run the unit tests again with by executing src/test/test_bitcoin to get a bit more information on what failed.
Did you make any code changes?
|
|
|
|
It's because both Bcash and Segwit2x occupied some service bits to indicate their own forks while they were still able to connect to Bitcoin nodes. Bcash was using bit 6, and Segwit2x was using bit 8. Both bits thus needed to be skipped for some time to avoid collisions. See https://github.com/bitcoin/bitcoin/pull/10982 |
|
|
|
|
addr messages contain the addresses of other nodes. It's how IP addresses for other nodes are spread around the network.
|
|
|
|
I understood what you have written. I am thinking now that there should be many indexes on database to provide better performance in such edge case. This should speed up process of keys importing.
For example: indexing first parts of the keys so the search process would be by few first characters and it would speed up greatly.
Indexes don't help in the wallet right now (and probably won't for the foreseeable future). Indexes would probably slow down the import because most of the time spent during an import is in the writing of the imported thing to the wallet file. With more indexes, there will be more data to be written, so that may take even longer. Bitcoin Core actually never reads data from disk except during the initial loading. It does not use the wallet file like an actual database so there aren't constant reads. Thus indexes don't really help with that. What probably would help is keeping keys in memory in a hash table (std::unordered_map) rather than a RB tree (std::map). The lookups are all happening in memory, and hash tables are O(1). Currently we use a std::map which is a RB tree, so lookups are O(log(n)) I didn't observed that whole wallet was loaded into memory, as Bitcoin Core takes much less memory even if the wallet.dat was 2 GB.
Hmm. It suppose that the internal BTree structure of the underlying BDB file takes up more space than I thought it did. |
|
|
|
|
Firstly, just because it takes a while for your crazy edge case does not mean that the software poorly written.
Secondly, an extremely large number of keys is not a common use case, thus the wallet is not written nor optimized for this use case.
Will this be fixed? Maybe. It might not be worthwhile to do so. Rewritten? Not any time soon. Rewriting the wallet is a huge undertaking and can't just be done on a whim. It'll be a long and slow process to rewrite it as changes have to be relatively small and it needs to be done incrementally.
If you're wallet is greater than 10 GB, then you will need to have more RAM than that to not constantly go into swap space. Bitcoin Core loads the entire wallet into memory, so if on disk it's 10 GB, then almost all of that is ending up in RAM. If you don't have enough RAM, it's not going to go very well.
If you don't need the transaction history for your 151 million keys, then you can try using the scantxoutset command. It'll go faster because it isn't scanning the entire blockchain history and then copying it to a separate wallet file.
|
|
|
|
If I wanted to press on, is there a way to generate a signature (and leave me to create the final witness manually), or at that point am I left with basically reimplementing it myself or hooking directly into the Bitcoin Core code? Since the "concatenate the signature with my script" is the only step that I'm missing for signing the thing automatically.
With Bitcoin Core's tooling, there is no way. You will have to do it manually or find other tools to make the signature for you. |
|
|
|
So I tried to do it again and somehow got a different error this time: "error": "Unable to sign input, invalid stack size (possibly missing key)"
Is this what you meant? Yes, that is the error. Could you clarify why it wouldn't be able to sign my transaction? Would it be because it's non-standard? I'm not sure how that would affect things. From reading the spec, in particular BIP141 and the Script definitions, my impression is that signing a transaction is a simple matter of serialising part of it and calculating the ECDSA signature, which shouldn't depend on the actual script being used (taken from https://en.bitcoin.it/wiki/BIP_0143). Then, as https://en.bitcoin.it/wiki/BIP_0141 defines it, constructing the witness script would simply involve concatenating the resulting signature with whatever is passed as the input to the command. Am I misunderstanding something here? It is because the script is non-standard. Generating the signature is easy, it's constructing the witness that is hard. While for this particular script constructing the witness is easy, the only way you know that is because you have analyzed the script and determined how to make the witness. For other scripts it's not so easy. As a script gets more complicated, you need to reason about what it does in order to figure out how to create the final witness. Since it is hard to do, Bitcoin Core just does template matching - it will only sign and make a witness for scripts that match some predetermined templates. The script that you have chosen does not match any of those templates. I did give it a try using OP_CHECKSIG for a canonical pay-to-pubkey script, but bitcoin-tx recognised it as a pubkey script and created a P2WPK output, which is not what I want.
That's a bug and has been fixed for 0.21. Does this mean that there's no way to use Bitcoin Core to sign P2WSH outputs, or am I misunderstanding what you said about OP_CHECKSIGVERIFY? If so, how would one even sign and use such a transaction?
Yes, there is no way to use Bitcoin Core to sign for arbitrary P2WSH and P2SH outputs. There is a project which does allow for a general witness creator. It's called Miniscript and it is able to work on arbitrary scripts because it limits the scripts to certain opcodes and requires certain opcode ordering in order for it to be able to understand what a script does. Once this is implemented in Bitcoin Core, it will be possible to create and sign for arbitrary scripts so long as they conform to Miniscript. However we are still a ways out from this getting into Core. I will also admit that my original attempt used a much more complex witnessScript, which would succeed either on a 2-of-2 multisig, or on a single sig after a checksequenceverify timelock expired. In my attempts to simplify it yesterday night, I must have botched something in the process. Now that I've gotten the witness script to at least match and the error is different, I'll give it another try with my original script, and if I get anything interesting I'll add it here. This makes me believe I am making some mistake in the serialisation of the full script. Is there a canonical tool that I can use to "compile" Script?
You can try using btcdeb |
|
|
|
Would you like me to post the verbose log of what I did, including the actual values for the public keys, private keys and addresses?
Yes. Private keys aren't necessary, only if you want to share them. I tried doing exactly the same thing you did, but did not run into your error (although I ran into another one which I'll explain below). The likely culprit is that you have specified the scriptPubKey incorrectly. The error I ran into is one that you will run into too. Specifically, it's that Bitcoin Core cannot sign this transaction because you are using OP_CHECKSIGVERIFY. It looks like you are going for the typical Pay to Pubkey script, but the Pay to Pubkey script uses OP_CHECKSIG, not OP_CHECKSIGVERIFY. Unfortunately Bitcoin Core does not have a general signer (note that this is a hard problem) and thus cannot sign your transaction because it does not understand a script that uses OP_CHECKSIGVERIFY. |
|
|
|
|
Can you post the actual witnessScript and the funding transaction (the one that sent money to the address)?
|
|
|
|
I can't seem to find the transaction, the input is also not available.
on regtest
I wasn't going to burn real money on this, besides the fact that getting my Bitcoin is a pain in the ass. |
|
|
|
Please don't. Using transactions below the standard size limit will interfere with fixing a security vulnerability in the protocol.
As long as the tx remains within the standardness rules (and the goal is to do that), the txs shouldn't interfere. I didn't know about the 82-byte floor, most fascinating, where can I read about it?
There's a comment about it in the source: https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L588You'll want to look up the CVE to get more info on the attack it protects against. My new goal is definitely to broadcast an 82-byte transaction, have it mined and included in a block (the regular way - i.e. not asking miners "please", because that fails the reproducibility test in my book), and being able to spend from wherever the coins end up.
Being able to spend the output created might make this impossible to do. With a scriptSig that's already as small as possible, the output is really the only other place you can shrink. A practical question: In theory, a sigScirpt could be "OP_1" which together with the length byte would be "0151", i.e. 2 bytes. However, I've never gotten this to work in practice. My understanding - please do enlighten me if I'm totally off - is that you must provide both an unlocking code (which in turn must be "push only", i.e. have no other opcodes than those that push items onto the stack and it must furthermore not be nothing, AND the locking code, and further - that the hash of the locking code must correspond to the address you're spending from (i.e. where the txid, or UTXO if you will), points to (otherwise you could spend from all anyone-can-spend-addresses with just "0151", which you can't).
Nope. You can just push the redeemScript and it'll work. Here's an 82 byte transaction I made on regtest that spends a P2SH output with the redeemScript of OP_TRUE. The output is does the unknown witness thing, so you can't actually spend this output without a miner. 02000000013f0c4fa2d2ee6cc8ec4a24f1100cf03d6053ee5e50f923867caed8b5e15d903a00000000020151ffffffff01605af4050000000014521200000000000000000000000000000000000000000000
To begin with: are there 82-byte transactions from say 2017 and until now? Or is my 85-byte example some sort of record?
Probably not. I might search the blockchain for the smallest tx, but that'll take a while. |
|
|
|
|
The smallest transaction that can be relayed is 82 bytes. There is a hard minimum at 82 bytes as that is the non-witness size of a 1 in, 1 out P2WPKH transaction. The limit is there to protect against CVE-2017-12842.
You can shave off 1 byte by using a redeemScript of just OP_TRUE. Then you won't need to push anything else to the stack in the scriptSig.
If you are willing to make an output that only miners can spend, but can still be relayed, then you can create a witness output with an unknown witness version. Currently only segwit v0 is defined, but segwit currently allows up to version 16. Besides v0, only v1 has been proposed - this is taproot. You can use the other witness versions and transactions containing those outputs will still be relayed. The caveat is that those outputs cannot be spent because spending them is non-standard. Only miners can spend them since they aren't consensus invalid. And if you wait too long to spend them, they will become unspendable when that witness version is defined.
So you can replace your P2WPKH output with an unknown witness version and just pad it up to the 82 byte minimum. Furthermore, such an output will also have a bech32 address, and in theory, any wallet that supports segwit can send to that address.
In case you are wondering, I did also try a couple of other weird things to get small transactions. Unfortunately they don't work.
I was able to make a 64 byte transaction using the unknown witness version trick, but because I was trying to spend an output with an unknown witness version, this was non-standard and wasn't accepted by my node.
It is possible to make a 0-of-0 multisig, and Bitcoin does allow bare multisig scriptPubKeys. However the standardness check on multisigs requires at least a 1-of-1, so this didn't work either.
|
|
|
|
|
Changing this is a hard fork, so everyone needs to upgrade their node to one which doesn't have this bug. This is difficult to do and not very worthwhile.
|
|
|
|
|
The PoW is stateless and progress-less. Finding a hash with some number of leading zeroes does not make you any closer to finding a valid hash. Having any sorting based on that is not useful.
Being "backed by some computing power" is not useful if it has no effect on whether a transaction will be confirmed. And since mining is stateless, that computing power is not making it more or less likely that a particular transaction will be confirmed
|
|
|
|
This is after make. Is it over? Are the files somewhere? It says that they are made in doc/man but this is what I get when I go there:
Most of the binaries can be found in src/ (i.e. src/bitcoind, src/bitcoin-tx, etc.). bitcoin-qt is in src/qt/bitcoin-qt. That log line is saying that it entered doc/man and did something there. It does not mean that the build results are there, just the build results of the steps it did there. |
|
|
|
|
Show Posts
