Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
Hey Michael, First I think the idea of "do nothing in the first 9 minutes" will unfortunately not be useful as the computed work is mainly there to prevent miners from altering the history of previous blocks. Thus following your suggesting would probably drastically decease the security of the network as less work protects previously mined blocks allowing for lower cost to compute a reorg. Let us assume the aforementioned point could somehow be resolved there would be another practical issue. It is hard / impossible to sync clocks in a distributed network which I think would be necessary for a system that you propose. (actually Bitcoin is one way of introducing a temporal ordering of events in a distributed network) Finally even if that was also resolved: How would you prevent miners to already compute the simpler difficulty problem directly after the block was found and publish their solution directly after minute 9? We would always have many people with a finished / competing solution. So while I appreciate the idea I have the feeling it would be impractical but maybe I missed something. Best Rene Michael Fuhrmann via bitcoin-dev schrieb am Sa., 15. Mai 2021, 23:57: > Hello, > > Bitcoin should create blocks every 10 minutes in average. So why do > miners need to mine the 9 minutes after the last block was found? It's > not necessary. > > Problem: How to prevent "pre-mining" in the 9 minutes time window? > > Possible ideas for discussion: > > - (maybe most difficult) global network timer sending a salted hash time > code after 9 minutes. this enables validation by nodes. > > - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just > high enough) times higher difficulty. so everyone can mine any time but > before to 9 minutes are up there will be a too high downside. It is more > efficient to wait then paying high bills. The bitcoin will get a "puls". > > > I dont think I see all problems behind these ideas but if there is a > working solution to do so then the energy fud will find it's end. Saving > energy without loosing rosbustness. > > > > :) > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
Please read the Bitcoin whitepaper. It's a very interesting read. -- Best Regards / S pozdravom, Pavol "stick" Rusnak Co-founder and CTO, SatoshiLabs On Sat, May 15, 2021, 23:57 Michael Fuhrmann via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, > > Bitcoin should create blocks every 10 minutes in average. So why do > miners need to mine the 9 minutes after the last block was found? It's > not necessary. > > Problem: How to prevent "pre-mining" in the 9 minutes time window? > > Possible ideas for discussion: > > - (maybe most difficult) global network timer sending a salted hash time > code after 9 minutes. this enables validation by nodes. > > - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just > high enough) times higher difficulty. so everyone can mine any time but > before to 9 minutes are up there will be a too high downside. It is more > efficient to wait then paying high bills. The bitcoin will get a "puls". > > > I dont think I see all problems behind these ideas but if there is a > working solution to do so then the energy fud will find it's end. Saving > energy without loosing rosbustness. > > > > :) > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Proposal: Force to do nothing for first 9 minutes to save 90% of mining energy
Hello, Bitcoin should create blocks every 10 minutes in average. So why do miners need to mine the 9 minutes after the last block was found? It's not necessary. Problem: How to prevent "pre-mining" in the 9 minutes time window? Possible ideas for discussion: - (maybe most difficult) global network timer sending a salted hash time code after 9 minutes. this enables validation by nodes. - (easy attempt) mining jobs before 9 minutes have a 10 (or 100 or just high enough) times higher difficulty. so everyone can mine any time but before to 9 minutes are up there will be a too high downside. It is more efficient to wait then paying high bills. The bitcoin will get a "puls". I dont think I see all problems behind these ideas but if there is a working solution to do so then the energy fud will find it's end. Saving energy without loosing rosbustness. :) ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Sum of the keys attack on taproot
What Tim said is right. To add to that, you may also wish to read about MuSig: https://blockstream.com/2018/01/23/en-musig-key-aggregation-schnorr-signatures/ Cheers, Ruben On Sat, May 15, 2021 at 10:32 PM Tim Ruffing via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, 2021-05-15 at 12:21 +0200, vjudeu via bitcoin-dev wrote: > > > > All that is needed is producing a signature matching the sum of the > > public keys used in taproot, which is "(a+b-a)*G", > > This is simply not true. > > Taproot does not enable this, or any other form of "cross-input > aggregation", i.e., spending multiple UTXOs with a single signature. > > > Tim > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Sum of the keys attack on taproot
On Sat, 2021-05-15 at 12:21 +0200, vjudeu via bitcoin-dev wrote: > All that is needed is producing a signature matching the sum of the > public keys used in taproot, which is "(a+b-a)*G", This is simply not true. Taproot does not enable this, or any other form of "cross-input aggregation", i.e., spending multiple UTXOs with a single signature. Tim ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Sum of the keys attack on taproot
We have some taproot address with private key "a" and public key "a*G", owned by Alice. Bob wants to take Alice's coins without her permission. He owns taproot address with private key "b" and public key "b*G". He knows "a*G" by exploring the chain and looking for P2TR outputs. To grab Alice's funds, he creates "(b-a)*G" taproot address and send some small amount to this address. Then, Bob can create a transaction with two inputs, taking coins from "a*G" and "(b-a)*G" addresses. All that is needed is producing a signature matching the sum of the public keys used in taproot, which is "(a+b-a)*G", reduced to "b*G", so Bob uses his "b" private key to produce Schnorr signature. Is there any protection from this attack?___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
