June 2020

what's the news on v4 release?

How’s it running?

Been working on an anonymous cryptsystem for bitcoin and other currencies. how's everything?

Also I wrote this library for 2 devs working on wallets: https://github.com/narodnik/biji_wallet/ I think we should fix it up a bit more and include it... I'm waiting though for v4 since I couldn't figure out the v3 zmq async loop

I need a bit of help, I'm encountering something I find highly suspicious and don't quite understand. For an address I own, someone transferred a small amount of BTC which was, within the same block, also transferred back to the same address. So, the output in block X is also an input in block X, which seems like it might be an issue 😕 Any thoughts? Libbitcoin, when I tried to automatically move the incoming funds stated it could not find the previous output, which is when I started investigating and found this weird situation

There's nothing wrong with a subtree of referential transactions within the same block within the protocol. I don't know what mechanism you tried to use, but it's not that weird a situation to hear about. I have on a number of occasions facilitated the commitment of a transaction by spending the output with a greater fee, thereby 'paying for confirmation'

I figured out the transaction indeed makes sense, thank you for confirming 🙂

mine have regularly been of the form a pays b, so b pays b to facilitate the confirmation of a pays b

The scary part is, it turns out someone managed to reconstruct their private key because somewhere in the set of transactions from this address an 'r' value / nonce was reused 😕

😳

I'm glad we had multiple extra tools watching transactions 😳

The only issue with two related txs in one block is that the output must precede the input tx, in serialization order. It’s a stupid consensus “bug”, preventing parallelism for no reason.

if you didn't form the spend from your address, then there's something up, but if you executed the spend the fact that they both end up in the same block isn't an error.

It seems like someone managed to reconstruct their private key and tried to (and kind of did) scam us out of a small amount of BTC

I don't understand your scenario. 'Reconstruct' implies they didn't have the key without giving a reason as to why they would have lost it in the first place.

Context: I work on an infrastructure for receiving and subsequently moving around BTC, the received BTC is moved to our cold storage, but we have an address for each user which they can deposit to. This address is reused for all their deposits (yes, this is not recommended, but a single recognizable address for a user wasn't and isn't really an issue for us, our target audience is mostly beginners so ease of use was higher on the priority list). Now, the user doesn't have their key, we manage that so we can send the received BTC to different wallets under different situation (cold wallets, trading wallets, etc). Now, after sending a couple of deposits for a particular user on to our cold wallet, it turns out one of those transactions (which are generated and broadcast with the help of libbitcoin) reused an 'r' value that was used for an earlier transaction from the same address, allowing this user to find their own private key and both deposit + withdraw their money, sadly it was credited to their account before we found the issue, but luckily it was only a small amount 😕

sounds like a tough problem

Signing nonce?

yeah, the 'r' in the signature was the same for two separate transactions

You don’t use deterministic nonce?

both seem to be transactions that have more than 1 input and per-design a single output

We removed to non-deterministic nonce option years ago.

I use the create_endorsement method to sign for each single input

Is there a nonce parameter?

checking

Grep did not help me, any clue where secp256k1_nonce_function_rfc6979 is defined?

just took a look - seems like the call to secp256k1_ecdsa_sign is nullptr parameterized and should instead expose that parameter for control.

If I sign several inputs from the same address, should I expect the r-value of the signature to be the same? because investigating my issue, I've found there are several occurences of a duplicated 'r' whenever I take several inputs from the same address and sign them individually

I took a look at secp internals - not enough to answer your question but enough to say that there is a nonce parameter which isn't required and in which our sign function is providing a nullptr. In my judgement that means that you're getting deterministic behavior

I was indeed wondering about that parameter

AFAICT not an implementation bug, by design. See specification.

Certainly it's how secp is expected to behave. If they wanted to require the nonce they should fail without it. But a user controlled nonce is supported by the library to the tune of a 32byte array. I did not look at the specification though

The transaction being signed, I expect, should also provide a different hash for the data being signed (i.e. the signature hash has different data, though some of it may be the same (e.g. the output script given that it's a deposit to the same address))

See RFC 6979: https://tools.ietf.org/html/rfc6979

well, my quick skim says we're doing everything there. so yes, we're compliant. the nonce is deterministically constructed.

Well prolly something to escalate either to libsecp or the RFC.

yep - if r = kG (mod q) and G is your key and q is the prime number, the choice of k is what you want - which according to the rfc isn't related to the nonce.

Within the create endorsement and generate signature functions, the value parameter is defaulted to max_uint64, could that be an issue? I.e. could that lead to multiple hashes that are effectively the same? I mean it shouldn't because they are spending different outputs right?

Until I map the process described in section 3.3 of the rfc back to its inputs from our side I couldn't say. It's where I'd start

    const auto sighash = to_sighash_enum(sighash_type);
    if (input_index >= tx.inputs().size() ||
        (input_index >= tx.outputs().size() &&
            sighash == sighash_algorithm::single))
    {
        //*********************************************************************
        // CONSENSUS: wacky satoshi behavior.
        //*********************************************************************
        return one_hash;
    }

Looks like the default params get me to the 'unversioned' signature algorithm, which has this gem 😛

👻

That was satoshi’s brilliant idea for returning an error.

👻

I “fixed” it once. I was very new. @narodnik patiently corrected me.

I most often have 0 or 1 as index with at most 1 output and always 'single' signature, so there might be cases I hit this 😕

Is that the condition??

This is:

if (input_index >= tx.inputs().size() ||
        (input_index >= tx.outputs().size() &&
            sighash == sighash_algorithm::single))

That’s more specific, it’s an index out of bounds condition (logical error).

indexing is 0 based right?

Yep

Ok, then I shouldn't hit that 🤔

Right

When the size() of inputs == 2, however, I have a number of cases where both signatures have the same 'r' value within that transaction 😕

Sometimes defaults are set to bogus because the choice matters and there isn’t a reasonable preference that should be assumed.

that seems like a rather big security issue to me

What does?

the reasoning about the defaults

How so?

With a bogus default the program compiles when that parameter is not provided, if there is no default I'll get a compiler error to force me to actually make a choice

You choose the parameters, and get correct results.

Sure, but when default parameters are used in several places, a mistake, such as not setting things to versioned or not providing the 'value' parameter, may go unnoticed. From a security perspective these defaults are dangerous, in a library that deals with currency I would expect a compile error is much preferred

In cases where one doesn’t care to provide a version, a reasoned default is provided.

So, my main question is then, would using a 'versioned' signature provide better security in light of my issue with duplicated r values

I doubt it, but not looking at the code.

Ok

The version is the same for each sig you apply it to.

It worries me that a transaction that spends two UTXOs for the same address will possibly have two identical 'r' values for the signatures, when both UTXOs should be different and should not have the same signature hash right?

Seems like a reasonable concern, but not an implementation issue.

So for context, it seems that someone is running software that is trying to find and exploit duplicate 'r' values (i.e. multiple transactions coming from the same address). What we're seeing is that anything coming into a compromised address is immediately sent through to another address outside of our control. Now they are not trying to be stealthy they are using the same target address to send their stolen BTC to each time. In fact they also include an output from that address as a secondary input to the 'stealing' transaction (I find this weird).

Beside the point

That is what I'm trying to do indeed

👍

Now, I'm fairly certain that this software is essentially scanning transactions and storing pairs of (address, r) and when it finds a duplicate 'r' it derives the private key and starts sending anything coming into that address to another address under their control. I'm not sure we are being targeted specifically, I figure an operation like this could work on a reasonable gaming computer with enough memory and storage for the database. If it ever hits an address with a bit more BTC it could have covered the energy / operational costs

Cool

their solution is the deterministic nonce we use though 😅

On testnet, here 3 out of 4 inputs have the same value for 'r' in their signature: https://blockchair.com/bitcoin/testnet/transaction/9a16e7bbfab607a6e3cd70266726094b87248cb8378276c3174ba96df133681e

I essentially follow: https://github.com/libbitcoin/libbitcoin-system/wiki/Examples-from-Building-Transactions for building transactions