Do you want to say that you updated your code and do not use
any more?  



Yes.  Small example: c6c25c2955bab88d68a5fe9e1c4f357c49b053b37812aacb2f6deba701462de1
There are also some 900 kb+ transactions.


I prefer using the field Z_N. Then you can simply write


ECDSA signature is as follows:
and the rest as you wrote.

I called k the "private key" of R, since R = k * G. Sorry for the confusion.  So k = 1/2 (or 0x7ffff...a1).
The private key of the signature is still the private key of the address that is spend, e.g., of the brain wallet "cat".  

The reason why k=1/2 is chosen is that it leads to a shorter r.   Note that choosing k=1/2 allows everyone to compute the private key.  But since the private key is already known  (it's the brainwallet of cat or dog or password, etc.) this doesn't hurt in this case.

Unfortunately, this attack is still quite successful.  One reason is that even miners spending the 1000 Satoshi outputs will get a lower fee (about 70 bits/kB) than with regular transactions.  So the spammer spent less for the outputs than cleaning them up costs. There are currently still > 5 BTC in the 100 most spammed addresses.  Cleaning them up takes about 70 MB.

The problem is that the dust limit is computed from the mintxfee and some miners have it still set to 10bits/kB.   Also it take much less space and therefore fee to send to 1000 Addresses than it takes to spend from 1000 Addresses.  There were several suggestion to penalize outputs over inputs when computing the required fee but AFAIK it was never done in the standard bitcoin client.

The number 00000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63 is now the most repeated R value on the blockchain (>70000 uses this morning, all other repeated R values are together used about 7000 times).

I saw on the IRC logs that gmaxwell suggested to use this R value for sweeping dust transactions, since it saves 11 bytes of encoding (leading zeros can be omitted) and since the private keys are publicly known, so there is no harm in doing this.  Some time ago, he also posed a challenge to explain this.

The corresponding private key is 1/2  (in modular arithmetic, so its numeric value is (order+1)/2).  It indicates that the generator G of secp256k1 was chosen such that 1/2G has this x coordinate (this cannot be a coincidence, that would be as likely as if the lottery winning numbers would be the same five times in a row).  In principle the generator G could have been chosen such that 1/2G is any valid point (almost every second 256-bit number corresponds to a valid point), so why did the creators of secp256k1 choose this particular number?  What else is so special about this number?

The document describing the SEC elliptic curves seems to avoid this topic altogether.  It doesn't describe how G was generated.

This assumes that there is no bug or design flaw in the TREZOR.  For example, with firmware up to 1.3.2 it is possible to get the keys from a stolen TREZOR without the PIN.  For the current firmware I don't know an easy way (the hard way by carefully opening the chip and using an electron microscope is not preventable).  With a secure passphrase you would be safe against these attacks.  However, a targeted attack would first install a keylogger on your computer to get the passphrase and then steal your TREZOR.  Still, the thief would need an electron microscope or know a new attack vector to get around the PIN (a cheaper way may be a fault attack).

This does not mean that hardware wallets are insecure.  A software wallet is much easier to compromise: You just need to install a Trojan on the victim's computer. The next time the wallet is used, the password and the private keys are sent to the command & control server.  With a TREZOR, you usually need a Trojan on the victim's computer (or physical access) AND you need to know a critical bug in the firmware that can be exploited.  These bugs usually get fixed quickly when they are discovered.

For Chinese the words that are in both lists have the same numeric ID.  If I understand it correctly they contain exactly the same words, it's just that they use different variants of Chinese symbols (simplified vs. traditional).   This may be bad, because the traditional Chinese seed produces different keys than the simplified Chinese seed, even though they both match the checksum.

For French vs. English, the situation is not so bad.  You have some seeds where you can't say whether they are French or English, sometimes the checksum is okay for French, sometimes for English and sometimes for both languages.  But the keys produced are at least the same (unless the French and English seeds differ by accents).  The 128/256 bit seed from which the passphrases were produced is not used for anything, so it is not so bad if they differ.

Changing the word lists opens new problems.  We can't know how many French/Spanish/Chinese/Japanese seeds are already in use.  I think, the most practical solution is to just drop the requirement that the word lists are sorted and require a linear search.  When the language is not unique, check all supported languages and accept the seed if it has the right checksum for at least one language.  Auto correction requires that the user chooses the language before entering the seed. In the end the private keys are computed from the seed, ignoring the language for which it was computed. The checksum is only there to prevent people from doing stupid things like inventing their own seed with low entropy.

A public key in Bitcoin is a point on an elliptic curve.  It must be encoded either as two coordinate 04+x coord + y coord or as parity plus x coordinate.  If it is not in this form the script always fails, which means it is unspendable.  In this transaction the public key is the string "find...satoshis", which doesn't start with 04 and doesn't lie on the elliptic curve.

It would be funnier if they had at least used a point of the form 02 + "32 byte string" and made sure that the point is really on the curve.  Extra points if they managed to spend it

BTW, this joke is now permamently in the UTXO list of every full node, which means it takes a little bit of RAM on every full node for the next centuries.  This is why these kind of spam is not liked so much.

So in the word list っ and つ are sorted as the same letter.  This may be standard for japanese localization, but if you don't have this localization installed you get a different order.  The bad thing is that the binary-search method in the bip39 mnemonics tool doesn't work if the list is not sorted.  Thus, for example, the unit tests of python-mnemonics fail.

Doesn't work.  They need double the hashing power.  If they have that, the selfish mining strategy would work much better with one chain.    Basically, the subpools would attack each other.


Holding one block for some period is not good for a miner.  Selfish miners lose some blocks by doing this.   What makes selfish mining profitable is that as soon as they get two blocks ahead they will always win and can wait until the remaining network catches up to kill all the blocks that the honest miners produced.

A selfish mining attack is clearly visible.  You get forks that are several blocks long.  Bitcoin users can no longer trust confirmed transactions. A miner with enough hashing power to make such an attack should hopefully realize that the damage to Bitcoin and the resulting price drop will make him earn less and make his huge investment in mining hardware almost worthless.  Even if they just rented the equipment and would try to monetize their profit fast, it wouldn't work.  They only profit after two weeks when the difficulty is adjusted.  Before that, they would only lose a lot.

One problem was also that the effect of the soft fork on the "SPV mining"-hack was never tested.  The developers didn't even know the miners were doing this or if they were aware they wouldn't know the details.  It would be good if the miners also used TestNet regularly under realistic scenarios.  E.g. they could spend a ten-billionth of the hashing power on TestNet.  Keep the hashing power small enough, so that others can still do useful tests on TestNet with a small ASIC usb stick, but use it all the time and try changes there first.  A soft fork can be forced to apply earlier on testnet by just sending some additional hashing power supporting the soft fork.


this is a good idea.  Most SPV clients already are connected to several nodes, so it shouldn't be too hard to implement.  One probably has to ignore a single node on a shorter fork to avoid false warnings.  In this scenario it would have made the SPV client secure as long as it has enough outgoing connections.

How much hashing power was supporting the fork?  I only saw AntMiner, F2Pool and BTCNugget, which have less than 50 % together.  Wouldn't the fork have stopped automatically when these pools ran out of "luck" and the remaining network caught up?  We'll probably never know who of the smaller pools would have supported the wrong chain.

The 150 BTC reward that these pools lost is not really lost; they will be reflected in a slightly smaller difficulty soon and thus evenly distributed between all pools.  Also, the 100 BTC f2pool lost is probably less than what they gained by their dangerous tactic of mining on the longest chain without verifying it.

However, it's hard to say how much they really gain with their "SPV-mining" strategy.  The orphan rate would be higher, but this would apply for the other pools as well. Sometimes they would produce a block on the old parent that gets orphaned immediately, sometimes they orphan the block of another miner that didn't distribute fast enough.  Since China has most mining power, maybe the big Chinese pools would even profit from this higher orphan rate, when the difficulty is adjusted.

BitcoinXT didn't hard fork, nor will it deploy a hard fork automatically in it's current release.  The link at the beginning of the thread point to Gavin's development repository; the patch is not merged into the official maintained by Mike. There is no pull request. It's probably not even ready for serious testing, yet.

So please calm down and wait at least until Gavin thinks the code is ready.

Could it be a problem of localization?  Every language has its own sorting rules and often this is implemented in the library.  Maybe if you have japanese localization the list is sorted correctly.

Looking into the official bip39 wordlists it seems other languages have the same problem, e.g., french:


I'm not sure what the right solution is.  Sorting the word list with LANG=C would change the indices of the words and break compatibility.  Requiring that localization setting must match the language of the word list make automatic tests difficult.  Especially if you don't have support for the language installed.

ELI5 is difficult .  I try for a higher age...

The developers designed a soft fork BIP66 that does not allow some malformed bitcoin transaction (that have a strange signature that may not be accepted by newer versions of openssl).  To make sure that there is only minimal forking, they had some rules accompanied with the fork.

• Miners vote for the fork by setting version 3 in the block header.
• Only when 75 % of the miners vote, the change has any effect at all
• When 95 % of the miners vote, the new client ignores all miners voting 2 and orphans them off.

The latter should have produced a few orphans for the 5 % that didn't update.  However, it looks like f2pool and antpool just voted by setting version 3 but did not implement the rules of the fork, at least not the last one.   They built a fork on top of a block from a miner that didn't update.  Since they have a lot of hashing power they managed to produce a longer fork that was alive for some time before being overtaken by the miners implementing the soft fork correctly.  The effect is that we may see transactions with 6 confirmations that are later double spend.  Also f2pool will loose a lot of blocks since they are orphaned later.

If you have a full node that is updated, you have nothing to worry.  It will just ignore the invalid forks.   If you have a SPV client, it will trust the miners to not do something stupid like this and thus it may be on the wrong side of a fork.  There is a small chance that you see a transaction with a few confirmations that doesn't make it to the 0.10.x chain.

Since the unconfirmed and double-spend transactions are removed by now, it is no longer possible to see this.   I opened the transaction in Blockchain.info.  If advanced mode is enabled it showed me the unconfirmed input with a small red U.  I clicked on the corresponding links to get to the parent transaction.

The parent transaction was a transaction with many inputs and many outputs.  It's parent transactions had a similar shape.  The coin values were more or less random.  The transaction was originally sent by Blockchain (usually the origin IP is not accurate at all but if it says they sent it, it should be accurate).  All these point very clearly showed that it used the Blockchain.info mixing service.  Here is an example for how such a transaction looks like: edd0626aab907e4eb41cd132f457ebc0411458f0532b5233681692b03c2e81d9

I followed the chain of unconfirmed inputs simply by clicking on the input with the U.  Until I got to a transaction, where all inputs were confirmed.  This was the transaction that was double-spent by the transaction I posted.  Again Blockchain.info provided the link to this transaction and this is what I posted.

IIRC, the double-spend was sent about 20 minutes after the initial mixing transaction and it has a much higher fee  (0.01 instead of 0.0005).

It depends on what happened and how the mixing service is implemented.  Possibilities and outcomes:

• All mixing transactions are reverted and you can simply spend your original unmixed coins again,
• Some mixing transactions were confirmed; part or all of the money is sitting in the mixer address.  Then there are three possibilities
  
  • The private keys for the mixer addresses were added to your wallet.  Then you are still able to spend the money.
  • The private keys are stored at the service provider.  Then the service provider can recover the money that is stuck and send it back.
  • The private keys were never stored at all  .  Then the money is lost and you can only hope that you get reimbursed.

I hope it is not the last one.  This would be a bad implementation of the mixer as this incident demonstrates. 

Yes, I didn't think of Grover's algorithm.  However when practical quantum computers arrive, the scheme is not useful anymore.  Breaking DLP on 768 bit curves should be much easier than Grover's algorithm, which still needs 768 bit curve multiplications in this setting.


What you need to break is hash128(f(c,x1,x2,m)) = c,  where hash128 is whatever hash function is chosen for the scheme and f is a complicated injective function involving 768 bit ECC multiplications (which needs hundreds of thousands of 64-bit operations) and which uses different kinds of operations than the hash function.  Changing a bit in the input of f should change several 100 bits in the output of f.  It is similar to but more complicated than a fixed-point attack.  Does this kind of attack to hash128 have a special name? 

The function f(c,x1,x2,m) is x1*G|x2*x1*G|(m-c*x1)*G|(m-c*x2)*x1*G in case you wonder, where x1,x2 are 768bit numbers, m is 380 bit and c 128bit.  It is not injective only if x1=x2<T, in which case the proof is not fake.

Anyway, for t=256, the scheme can be easily adapted: use 1024 bit elliptic curves.  For every output, the sender needs to provide E,F (2*129 bytes), m (64 bytes), c (32 bytes) and as usual an output script (~26 bytes).  So in total 380 bytes.   That is 33 % more than the 284 bytes needed for t=128 but it is still reasonably small.

Did I forget anything in the size estimation?  The values U,V can be computed from c. The value x can be computed by the receiver from the ZK proof if value r is chosen using a secure deterministic random number generator seeded with a shared secret between sender and receiver.  The value Delta would be included in the fee.  The fee is another 64 byte value that needs to be included in every transaction (but only once even if there are many outputs).  The size of the inputs does not change.

Some of the inputs of your transactions are unconfirmed, that means the transactions paying you are not yet mined and there is also a double spent warning for them.  Also their inputs are still unconfirmed.  It may be a double spend somewhere along the chain.

I guess this is partly due to the ongoing stress test; the blocks are full and transactions are confirmed slowly.  Before the transactions that pay you are confirmed your transaction cannot be confirmed.  It may even be that the transaction paying you is never confirmed, in which case you have to make sure you get paid again and send a new transaction.

Update:  Looking closer, it seems that you have run the coins through a mixer.  One of the persons who mixed with you double spent their transaction:

https://blockchain.info/tx/ee7a8a57edb82d7941945f9f27a4c5f72c1d3b41a686c9b9d6341c1e5e2547ca

You have to wait until blockchain.info sorts out this mess and removes the unconfirmable transactions from its database.

To prove that a key is the nth hardened child, you need to provide I_L and prove that it is the result of a HMAC_SHA512 operation.  I don't see how you can prove the latter without giving the second operand of this operation.  However, for a hardened step this contains the private key.

The input and output values are not the same, as there will be transaction fees and some randomness in the sub-satoshi area of the fuzzvalue.   The sub-satoshi area alone should provide about 200 bits of random difference between input and output which is secure against logarithm.  So I think in the worst case it should still be secure against an outside analyzer.  It could be that some participants of the transaction gain more information, since they also have to exchange the exact fee spent by the outputs of any partially build transaction.  But I think it could be similarly solved as the problem of adding inputs and outputs without knowing who added which input and which output.

It's not a collision attack between two hashes.  There is only one hash involved here and it has to fit its own input.  If the hash function is a random oracle it is possible to prove that 2^t calls to the hash oracle are necessary on average to produce a fake proof.  Of course, true hash functions are not random oracles, but they come very close.  I think there is more trust in current hash functions than, say, in ECC (simply because hash functions have been longer around than ECC).  Also current hash functions cannot be broken by quantum computers as far as I know.

I understand that you want to play devil's advocate and I agree that the impact is much larger than in the crypto used in the Bitcoin main chain.  If you can fake a single signature in bitcoin, you can just access one output, but if you can fake a proof of being a small positive number, you can drain the whole side-chain.  If CCT would be implemented in the main chain, you can even mint as much money as you want and it would be undetectable unless you spend too much.

My personal opinion is that the security t=128 is good enough for now but it may change in a few decades if the cost per computation continues to decrease exponentially at the same rate it has done so far.