Topic: The cure to botnets and one-way-trust pools (Read 160 times)

If you check everything, then fake signatures will be rejected. But skipping any single step in signature verification can lead to accepting fake signatures. For example, if you have some known public key, you cannot accept just any r,s,z values. You have to check if someone has a message that can be hashed to z-value. If not, you can get something like that, for example for block zero:
It has to be chosen in SIGHASH_ALL, but not always in SIGHASH_SINGLE. If you make sure that all needed pieces are signed, then you are safe. You can base on signet, here all blocks are signed and it seems to be done in the right way. Changing signet challenge to something different should be enough to test your idea in practice.

Well I want to give BTC at least the option of staying relevant.  Whether they continue to keep their head in the sand is now up to them, I have given them all my best ideas that if implemented would keep BTC market dominant.  They can't say they weren't endlessley warned.

Hard to follow that but since the idea requires the signature of a predetermined public key, you wouldn't be able to fake it correct?



good points but for one satoshi did not need to expend valuable resources to mine because he was just doing it on a PC and was probably the only one mining.  He could have been just doing it to secure the network and didn't save the private keys (after the test transaction to hal finney) so he wouldn't be tempted to spend them cause that would basically be a premine.  We can never know if someone saves their private keys or not but we could know at least they have them saved temporarily to mine the block.  We can be sure that no coins were mined directly to a legitimate (but hidden) burn address.

You cannot produce a signature for an arbitrary message of an arbitrary private key. You can produce an (arbitrary) signature, and arbitrary message and calculate the corresponding public key, and calculate the corresponding address to the public key.


You explain why your solution would not prevent botnets above. A coinbase transaction could send 1 satoshi to a private key distributed to all computers in a botnet, and the remainder to the botnet operator.

Pool trustworthiness has largely not been a major issue in the bitcoin world. It is trivial for a miner to switch from one pool to another, and pools are generally expected to payout mining rewards on a frequent basis.

The question as to if the coin produced via early blocks is not necessarily if satoshi (or whoever mined those blocks) controlled the private keys when the blocks were mined, the question is if satoshi controls the private keys associated with the output of the coinbase transactions today.

Satoshi did spend some of his coin that he mined, so it is reasonable to believe that he controlled all the private keys associated with the coinbase transactions of the blocks he mined at the time they were mined. Further, anyone mining any kind of coin will need to expand valuable resources to mine, so it would be illogical for someone to intentionally mine in a way that results in coinbase transactions being sent to addresses they (directly or via an agent) cannot spend from.

That is already happening. The responsibility of taking care of their own devices lies on the operators themselves. At best, you're trying to make botnet mining harder, while trying to introduce sophisticated schemes also at the expense of the user. Solving pool dominance is not at the core of Bitcoin's issue, because at the end of the day, your network's hashrate is still concentrated with those that has the most equipment and resources.

The way I see it, this scheme does not really benefit the community as a whole, nor does it eliminate the possibility of users using botnets to mine. You will profit as long as you continuously send the funds out as it gets mined, so you'll still be able to net most of the coins. You might be able to implement it in an altcoin but I have my doubts that it would ever materialize in Bitcoin.

If a device is connected to the internet and it has software/firmware then it could be targeted by hackers.  Someone will figure out a way to do it eventually, they will target the control board not the asic chips themselves.  But the control board controlls the asic chips and they can be performing your hashes for their pool instead of the one you set.  Most botnets are IoT devices and no one is manually installng malicious firmware on those.

Wait, how do you infect an ASIC with malware if it cannot execute arbitrary codes in the first place? (It's not like malicious firmware is being manually installed by a human, right?)

Botnets are not a huge problem on asics currently but in the future if bitcoin stays relevant then they will be.  Hackers will target asics with malware that use a portion of the hashes to mine to their address instead of the one the user set.  Also preventing botnets for mining bitcoin is just one reason why this method is superior to the current way, solving mega pool dominance is one that is particularly important for bitcoin currently.

So the way this would work in the method I am proposing is that you have to sign the entire block, which signature has at least a certain number of leading zeroes to win the block.  Verifiers would reject a proposed block if the entire thing including the nonce and all data werent signed over.



If this is the case then ECDSA is broken.  Although one way around this would be to require the coinbase address(es) to have sent coins previously (this would also function to reduce UTXO bloat, downside bieng less permissionless).  But this is not a huge deal anyway because the coinbase transaction wouldn't be able to be spent even if the public key was chosen to spoof the signature......  Actually thinking about it more I don't think that method you reference would work because the public key has to be chosen before the signature is generated (since you have to sign over the public key along with all other block data), so you couldn't search for a public key that would give you the valid signature.

Just to be clear, this problem isn't particularly salient in crypto, because it isn't that feasible. Bitcoin is best mined with ASICs and an array of botnets would only be a fraction of what ASICs can mine. Sure, you might be able to gain some money by mining Ethereum, but not much. The solution proposed will mean that the user has to know that a botnet is functioning in the computer and that funds are not locked (ie. moved out immediately) so they'll have a very short timeframe regardless.

Botnets are primary useful for click frauds, DDOS, etc. I don't think it is a particularly prominent issue that is easy to solve.

It would be the same as today. Each miner can mine its own coinbase transaction and just include a single transaction, sending coins to some pool. In this way, the situation would be the same, just a payment would be sent in two steps, instead of landing directly on pool's address.

There is no need to sign blocks in this model. You can mine blocks in merge mined way, the same as P2Pool did in the past. Instead of decreasing block time, you can just lower the difficulty and amount, then after joining many P2Pools in some tree-based model, you can cover all miners. To be backward-compatible, there is a need to join payments in a separate chain, then form some on-chain transaction and distribute rewards. Also note that with taproot, multisig for pools will take less space.

You don't need any private key if you have signed transaction.

That's not the case, because you can produce valid ECDSA signature without knowing the private key. Some examples: https://bitcointalksearch.org/topic/the-smallest-valid-signature-5373858

This is based on https://git.wownero.com/wownero/meta/issues/28

Basically what I have to add to this technique is just simplification.  Instead of taking the hash of the block to mine it like bitcoin does now, simply take the signature of the block instead to mine. The signature would be based on the coinbase address private key (the bitcoin address the block reward is sent to).  

One way we can allow some lower trust pool setups would be to allow multiple coinbase transactions and only one of the coinbase addresses have to be signed for.  So for example we could still allow 100 person pools to exist by allowing there to be 100 coinbase addresses that split the block reward and the miner only has to sign for one of them.

Some interesting benefits to this would be:

Totally making botnets infeasible since the bot would have to know the private key to where the coins are going.  Also mining slavery where some person or organization forces a person to mine against their will and give all proceeds to the bad guy.  This would mean that slavery of this type is prevented because the miner would have to know the private key.  This slavery could be in the form of government regulation as well.

Instead of the users having to trust the pool and the pool not having to trust the users; the user would not have to trust the pool as much and the pool would have to trust the user now instead.

Provable circulating supply.  All the blocks satoshi mined might have gone to randomly generated public keys without private keys.  If satoshi had to sign for the coinbase address to mine the block, we could verify he indeed did own the private keys and those blocks would be in the circulating supply instead of us not sure if they are really circulating or not.