Did you mean 16 GB?   16 MB sounds a bit low and make 4-way collision finding quite expensive.

If it is 16 GB, does this indicate that they planned collision finding in their design?  Or is there another reason you need that much memory for mining?

Using the same assumption of collection collisions for 5 seconds, you need about 45 MHash/s without commitment header to compute 500 4-way collisions and 550 MHash/s when witness is required.
But you can save more by using a longer collision time, e.g. 14 Mhash/s / 180 MHash/s for 30 s.   What is the estimated hash rate of the FPGA?

I know that it requires some extra hashes but if my math is correct we are talking about 12-13 GHash/s for a 400 PHash/s pool.  And I don't think 12-13 GHash/s cost millions of dollar per year.

This is how I derived the number:

A 400 PHash/s pool grinds through 100 million mid-states per second.  With 4-way asicboost, it needs about 25 million 4-way collisions per second.

If one collects collisions on a central server (the most efficient way to find a lot of collisions in a big pool), one needs about 3 billion hashes to create 25 million 4-way collisions.  If one can live with 5 seconds delay (i.e. blocks miss some high-fee transactions from the last 5 seconds), one can  reduce this to 5 billion hashes in 5 seconds, or a billion hashes per second.

Collecting the hashes and storing them to find the collision is not trivial, but should be possible.  You have to do it for any form of covert asicboost.   

Now, the extra commitment in the UTXO makes computing the hashes more expensive.  Instead of a single hash, you need to compute 12-13 Hashes for the Merkle root (if you still use Merkle grinding to generate the commitment hashes).  But it requires no extra storage.  So the total extra cost is 12-13 GHash/s for a 400 PHash/s pool.  Everything else is unchanged.

It requires both hard- and software support.  The software needs to feed the hardware with different first half headers for which the same second half of the header can be used.  The hardware must be designed to make use of the fact the second half of the header is used with different first halfs and leave out some calculations.  If I understand the antminer design correctly, their hardware can turn off the circuit that recomputes the very first step of the second header.  This saves some energy, but not make it faster.


it should apply the same way to GPUs, FPGAs or CPU miners.   However, I think it is more useful if you have several THash/s.


Empty blocks can have several different reasons.  They may indicate asicboost (which may add an additional delay for computing colliding hashes), but it can also be a slow block verifier, or the network has high delays, or just an inefficient design of the pool.

I think you can compute collisions for an empty blocks in advance before the previous block was found (is there any reason why not?).  So while you search for Merkle Tree collisions, you can still use the precomputed collisions to mine empty blocks with Asicboost.  But this all is pure speculation on my part.


You can make them completely invisible.  Randomize the payout address, swap transactions that are exactly at the same fee level, insert your own transactions that you send to the network to hide the fact that it is an artficial transaction, etc.
You only publish the block if you have a solution, the colliding Merkle Roots are never published (they cannot be used for other blocks).
But you can't hide using asicboost from someone who has access to the hardware or the communications between server and hardware, so it is possible to verify whether the antminer you have in your home uses Asicboost.

BIP-62 was withdrawn.  You may be confusing it with BIP-66, which didn't have low-S requirement.  There is also a relay policy for low-S but not a soft fork.  BIP-146 may fix it some day.

There are several discussions on reddit on r/btc.  I think BitClub mined three blocks with high-S and BitmainWarrenty (not to be confused with Bitmain) was also involved.  It also temporarily broke blockchain.info.

I doubt it. There is a website that explains the math behind it, but it isn't a step by step guide or even an automatic JavaScript program.

Note that there are very few broken signatures, maybe once every few months. And they are usually exploited quickly (which is only possible if the addresses are reused). And some people have bots running that can do this immediately.

Looks like someone put a challenge for breaking weak signatures:

https://blockchain.info/de/tx/695b04afbc477d045d396f062eeff5e950e5e44f91b7e2b273c5a74e27306177

When spending the first three outputs of this transaction, a weak signature was used.

The first output used k=1 when spent.  This was broken immediately by a bot.
The second output used the same k as a previous transaction of  19iAvuzfb8uH2SZLYcbb5wtbBZdn1o3vRm.  The latter is probably a weak brainwallet or something similar.  I didn't break it though.  amaclin, can you explain?
The third output has k=private key.  I solved the challenge and collected.
The fourth output is still unsolved.

The other four outputs are not yet spent.  I guess we still have to wait for the challenge.  Or maybe the address is weak for some other reason.

The passphrase is like a 25th word of the seed.  Every passphrase gives you a different wallet, and if you forget the passphrase (or lose the seed) the BTC stored in the wallet are lost.

@amaclin: your program fails for this block:
https://blockchain.info/block/0000000000004c78956f8643262f3622acf22486b120421f893c0553702ba7b5

If the remaining data is correct, the total fee is about 60688.8 BTC

Note that this also includes fee that was paid in error (e.g. swapping fee and value field) and later returned by the miner.

I  think multibit has an option to reset the blockchain, or repair the wallet or similar, to rescan the transactions.  This may help you.  Or maybe your transactions confirmed in the mean time.


Note that you should never enter the seed words on your PC in the correct order, unless you lost your Trezor.  You risk that some hacker has a keylogger on your computer and has now the private key.

If you just want to move to another PC, multibit should only ask you for pin and maybe for a passphrase when you restore the wallet.  In that case you are safe.

LOL.

I'm wondering why people do these experiments with 2500 $ worth of bitcoin on mainnet, even though it is likely that they just lose the bitcoins.

It's a standard SegWit P2WPKH over P2SH transaction.  However, I guess amaclin didn't include any signatures (witness), when pushing it to Blockchain.info.  So this transaction will never be confirmed by segwit-enabled miners.

Since SegWit isn't activated yet, it should be possible to include it in a block or even double spend it.  Are there any pools that accept non-standard transactions and that don't support segwit?  Looks like amaclin is betting 3.37 Bitcoin that nobody can easily double-spend them.

Here is a related thread and check the trust ratings  

https://bitcointalk.org/index.php?topic=1710442.0

Okay, amacllin noted these transactions already in August:

https://bitcointalk.org/index.php?topic=1575527.0

But nobody has a good explanation why these exists.

My personal opinion: segregated witnesses add a new kind of transactions, which look like anyone-can-spend for non-upgraded node making it a soft-fork.  So it is possible to choose completely new set of rules while still making it a soft fork. You now have two options:

• use the old rules for the new transactions making it only segregated witnesses.  Any further updates require either a hard fork or a new witness script version and then you need to support both intermediate and new version.
• or learn from the problems in the past and fix some small but nasty things that were on the hardfork wishlist for some time, like O(n) hashing and signing the input amount.

I prefer the second option.

The much discussed witness discount also serves two things: incentivice spending UTXOs by making signing cheaper and giving a block size increase with a soft-fork.  And it also discourages using the additional space for crypto-graffiti spam, since the discounted witnesses might not be stored forever.  You have a one-time chance to take all these advantages, so why not take it?  You can't introduce them in a second step without a hard fork.

I see the political problems - giving a signal against doing any necessary hard fork, making it harder to increase the capacity later.  But from a technical standpoint bundling these changes makes sense.

Malleability affects pre-signed child transactions in chains of unconfirmed transactions.  If you malleate the parent transaction, the child transactions is not valid, anymore. These unconfirmed transaction chains are used in LN to securely open channels or close channels.

SegWit is also useful to pre-sign the child transaction before signing the parent transactions, e.g. for the initial funding transaction you want to have signed emergency close channel transactions before signing the funding transactions.  With SegWit the transaction id does not depend on the signature and can be computed before the funding transaction is signed.

I noticed that there are a lot of 2 of 3 multisig transactions where one key has the private key 1. This makes them effectively 1 of 2 multisig, although I think the owner isn't aware of this.   Does anyone know, who is creating these?

Here is an example:
https://blockchain.info/tx/9aebe8dedd172d3662d0713ec94dff3ede1efca9b315b52be087872d06a93dc3

There is only a little address reuse.  I count over 1000 different addresses in the last three months.

I think the idea so far is to add a segwit account to segwit enabled wallets.  The segwit account then has segwit addresses (p2sh at first).  The user is free to choose between his segwit account and non-segwit account and whether he wants to transfer his funds to the segwit account.  When he uses the segwit account, he uses segwit change addresses.  So every user can decide for himself if/when he wants to update to segwit (of course, only after it gets activated).

It would be possible to use a mixed account with both segwit and non-segwit addresses and maybe even native p2wpkh addresses for change.  But this may be confusing to users, cause inconsistent balances between different wallets (e.g. when sharing xpubs), and make it easier to spot the change output.

I also have problems with testnet.  Some transactions I sent a few days ago still show as unconfirmed in Mycelium even though they have 4800 confirmations on blockr.io.

And then I have sent a Segwit transaction.  I first sent it without fee and later resent it with 5000 Satoshi fee. That still hasn't been confirmed after almost 2000 blocks have past.  It is not displayed on tbtc.blockr.io nor on test-insight.bitpay.com (and I can't push it to blockr.io, because their push interface can't parse witnesses).

Or is something wrong with it?

Did you know that BIP-66 (which you mentioned) was an important security fix?  Before that soft fork, it was possible to fork 64-bit miners from 32-bit miners by mining a transaction with a certain malicious signature.

Also note that reverting a soft fork is a hard fork.

A different problem with your approach is that everyone can spam the blockchain for free by sending loads of unsigned transactions that don't belong to him.  Your algorithm requires them to be included in the immutable blockchain before the miners can even start to check if the sender authorized them (including the fee).  Since one doesn't even have to own bitcoins to do this, one doesn't lose anything when spamming.

The problem is, what if someone else sends the transactions with your public key.  Of course, you don't send the private key, but how do you unfreeze your funds.  Does it timeout?   What if some-one DoS attacks you by sending another transaction in the moment it timeouts?

If it timeouts, the miners may also steal your coins by claiming that you didn't send the private key, wait for the timeout and then mine a different transaction with your revealed private key.

You may think you can have three one-time functions, private key -> public key -> address to avoid the first problem.  Then only you know the public key and can send the first transaction. But that also doesn't help, either.  The moment you want to spend your coins some peer may use the information to double-spend the coins.  The miners don't know which to include and may include the wrong one.  Then you are back at the situation where the honest person has to somehow convince the miners to switch to a different transaction.