The cure to botnets and one-way-trust pools

[ir.hn]

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.

[1714140818]

1714140818

[1714140818]

1714140818

[1714140818]

1714140818

[1714140818]

1714140818

[garlonicon]

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).

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.

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.

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.

Totally making botnets infeasible since the bot would have to know the private key to where the coins are going.

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

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.

That's not the case, because you can produce valid ECDSA signature without knowing the private key. Some examples: https://bitcointalk.org/index.php?topic=5373858.0

[ranochigo]

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.

[ir.hn]

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

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

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.

That's not the case, because you can produce valid ECDSA signature without knowing the private key. Some examples: https://bitcointalk.org/index.php?topic=5373858.0

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.

[ir.hn]

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.

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.

[NotATether]

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 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.

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?)

[ir.hn]

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 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.

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?)

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.

[ranochigo]

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.

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.

[PrimeNumber7]

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.

That's not the case, because you can produce valid ECDSA signature without knowing the private key. Some examples: https://bitcointalk.org/index.php?topic=5373858.0

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.

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.

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.

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.

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.

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.

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.

[ir.hn]

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.

That's not the case, because you can produce valid ECDSA signature without knowing the private key. Some examples: https://bitcointalk.org/index.php?topic=5373858.0

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.

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?

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.

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.

6.25 BTC / 100 is not 1 satoshi.  Im not exactly sure how the coinbase address rules work currently but if using this idea it would have to be equally split between a defined number of addresses.  Or you could say the signature needs to come from a coinbase address that gets at least 1% of the block reward and all the other addresses can get any amount desired.  That would probably be ideal to give maximum flexibility.

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.

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.

true but using that logic bank trustworthiness hasn't really been a big issue either.  So many banks are competing for your money that they are incentivized to be trustworthy and the government insures your deposits right?  The real value of this idea is preventing the 51% attack.  How do you know the mega pool (which this method prevents) wouldn't be able to use your hashrate to someday attack the network?  Breaking up the pools won't 100% guarentee that the same operator doesn't run the majority of the small pools but just like breaking up monopolies in the real world, it does usually work and makes it exponentially harder for it to happen.

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.

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.

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.

[ir.hn]

You might be able to implement it in an altcoin but I have my doubts that it would ever materialize in Bitcoin.

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.

[garlonicon]

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?

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:

Code:

fake_signatures.py 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f
981c008269574d9bb73a2e781270e2163297b3d3ca9645b5e0664ffcbb19e78a,3cc2a888bae4811e75e64e19f2ce668951a3520e93e31a74b4cd4e9ce9508839,ed97aea4f9b66aca0c41ac88c2f0d90ef2ad269af0951ba2b07c70f7d1542b3c
53b9632a4250eb518426a545daa99fc6a72addfcb62714fbe81e269cd9ee39e8,62cbe3cc5eec2cbcbf61793a1d94414b43536c0e9219da703be5f141c46fa364,166db19e268d41b8cb76eedb50c57969635bcce2218b1921df45656a24de751a
a050e9237241c02d17684df9b9039fd707fcecb2fbd9d46af95dfeb6ef1daaa3,5e3bd1a08a7418066e4231adbfa23cc969617bb67f35a5f9a4d1ebae9a196fc7,a20a81207eb5aa382759debfc3ca98d4a3cf85474c9dbb6684dbd5bae3abe58d
9f2e42881a9cd3ddd088ebc77857beb9929c42e76e3b3ab7d1928652d2b731cf,0a4353b1fe7c167d63eaa45aeb23f83d219fd31ca74a17adc84cb18bc3184833,32a9cacbb64e5679eb40dfca1192bccc3db0e19d63d1e68286fe119d7d494c8a
a46f5889983efb70e00927f5afeeb2c4042783ca36525968657e339416a6bd8d,185c697570158909298fb10019d7a3e62ed647e9a6ecd1992f3d3098a498eec9,dcd110dd05f2ef9bb46639b0abe858a545bc61f1cd0e5462f41e7003d5f68bba
8ca48464e4dd3789ec41b83827b93e840471cfce2c8e6349e4087f56c335991f,6fb96292e9a2e5480085d9b8f69bd6aa62cee3b76b090cd5d5e25f8ce253adea,b6b20ab75d2ad6e8e79fe3fdc9e28a66e2a6acecfe87a7f33cb5c3fba1d070d3

I don't think that method you reference would work because the public key has to be chosen before the signature is generated

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.