Bitcoin Forum
August 18, 2022, 05:01:11 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 »
1  Bitcoin / Development & Technical Discussion / Re: Why would make the extra merkle commitment asicboost uneconomical? on: April 12, 2017, 09:38:20 PM
Consider: today miners could use centralized devices to generate midstates, but instead the S9/R3 miners have fairly expensive FPGAs with 16MB of attached dual channel DDR2133 to generate the ~2000 midstates per second they need.  

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?
2  Bitcoin / Development & Technical Discussion / Why would make the extra merkle commitment asicboost uneconomical? on: April 12, 2017, 09:57:47 AM
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.
3  Bitcoin / Development & Technical Discussion / Re: Asicboost: several questions. on: April 08, 2017, 05:45:21 PM
1) Is asicboost a hardware or software optimisation?
According to my current understanding, asicboost optimizes mining through forming a merkle root of special kind. That sounds like it should be implemented in software? Does hardware need to be designed in special way to take advantage of optimized merkle roots? If so, can such special hardware be used to mine regular, unoptimized blocks?

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.

2) Is asicboost (as the name suggests) applicable only to ASICs (not to GPUs, FPGAs)? If so - why?

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.

3) Does observing of empty blocks from a miner increase our suspicions of asicboost being used?
I guess, that since they need a special merkle root, it may happen, that an empty or almost-empty block provides a necessary merkle root, so they just keep mining such an empty block until it is mined or an optimized merkle root found for a filled block, whichever happens first?

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.

4) If it's all about special merkle roots, why couldn't we detect asicboost optimized blocks just by analysing the blocks and their merkle roots?

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.
4  Bitcoin / Development & Technical Discussion / Re: Transaction malleability 2017 on: March 10, 2017, 10:27:29 PM
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
5  Bitcoin / Development & Technical Discussion / Re: New Weak Signature Challenge on: February 04, 2017, 10:43:24 PM
Is there a website that simplifies the process of computing the private key from a weak signature?

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.

6  Bitcoin / Development & Technical Discussion / New Weak Signature Challenge on: January 30, 2017, 12:05:10 PM
Looks like someone put a challenge for breaking weak signatures:

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.
7  Bitcoin / Hardware wallets / Re: TREZOR: Technical issues on: January 07, 2017, 05:41:42 PM
b) when using hidden wallets, how is the passphrase generated within the device when multiple wallets are used? Is the seed related in this process? Because if I use the seed to recover my wallets, the passphrase couldn't be generated unless you put it explicitly, so it'll be impossible to access my wallets If I only know the seed, therefore all my BTC will be lost, aren't they?

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.

8  Bitcoin / Development & Technical Discussion / Re: Total Fees on: January 02, 2017, 10:23:20 AM
@amaclin: your program fails for this block:

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.
9  Other / MultiBit / Re: Weird error, Trezor, Multibit, Low spendable balance detected. Please help. on: December 14, 2016, 12:10:49 AM
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.

No, just moved to another PC, and did a restore. Not, a new wallet / seed.

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.
10  Bitcoin / Development & Technical Discussion / Re: Double Spend? Or What happen? on: December 13, 2016, 11:40:46 AM
2) I didn't include signatures because I do not have the private keys for these addresses Smiley


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.
11  Bitcoin / Development & Technical Discussion / Re: Double Spend? Or What happen? on: December 13, 2016, 11:06:38 AM
It's a standard SegWit P2WPKH over P2SH transaction.  However, I guess amaclin didn't include any signatures (witness), when pushing it to  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  Smiley
12  Bitcoin / Bitcoin Discussion / Re: Multisig transactions with private key "1" on: December 04, 2016, 02:38:17 PM
Okay, amacllin noted these transactions already in August:

But nobody has a good explanation why these exists.
13  Bitcoin / Development & Technical Discussion / Re: Post your SegWit questions here - open discussion - big week for Bitcoin! on: December 03, 2016, 08:59:29 PM
While clearly many of the improvements result from signatures segregation, do all of them depend on it? Or are there some, that are implemented independently, that don't need signatures segregation? If all improvements depend on signatures segregation, then there's actually little sense in distinguishing the two meanings one from another.

Edit: In other words, can some of the improvements be implemented as a separate softfork, or maybe even without softforking at all?

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.
14  Bitcoin / Development & Technical Discussion / Re: Why LN needs SegWit? on: December 03, 2016, 12:02:50 PM
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.
15  Bitcoin / Bitcoin Discussion / Multisig transactions with private key "1" on: December 03, 2016, 11:42:58 AM
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:

There is only a little address reuse.  I count over 1000 different addresses in the last three months.
16  Bitcoin / Development & Technical Discussion / Re: SegWit change addresses? on: November 24, 2016, 04:38:18 PM
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.
17  Bitcoin / Development & Technical Discussion / Re: What's going on with the Testnet? on: November 06, 2016, 01:48:50 PM
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

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 nor on (and I can't push it to, because their push interface can't parse witnesses).

Or is something wrong with it?

> bitcoin-cli getrawtransaction 35aafd22054d15bcb4f2444de56989b18fd9765f3c33fbb8b89ff12092d611f6

18  Bitcoin / Development & Technical Discussion / Re: The Soft Fork Deception on: October 28, 2016, 06:07:09 PM
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.
19  Bitcoin / Development & Technical Discussion / Re: Why is ECDSA needed at all? on: October 20, 2016, 03:45:58 PM
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.
20  Bitcoin / Development & Technical Discussion / Re: Why is ECDSA needed at all? on: October 20, 2016, 03:37:40 PM
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.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!