What if you can't store the public keys of all cosigners on the hardware wallet? You should. If you cannot, then you can see, why hardware wallets are worse than software wallets. Would you then see the wrong address on all devices? If you cannot store all xpubs, then you cannot verify a new address. More than that: you cannot even create it, because how are you supposed to do that? And then, the question is: how this hardware wallet can support multisig properly, if it doesn't have required features? |
|
|
|
Meanwhile, testnet4 is going to achieve "one ASIC block per difficulty adjustment" state, so testnet4 chain can even "halt" for a while, if ASIC miners will turn their devices off, after they see the current difficulty. Here we are. Testnet4 is now stuck on block number 48383: https://mempool.space/testnet4/block/00000000761cd6bff5e11258943e401e1bb094a8013e810e1d6031ce273a4b7cNow, we are waiting for ASICs. Which means, that testnet4 may be resistant to timewarp attacks, but on the other hand, it is not resistant to being stuck, if only CPU miners will be there. Edit: This time, someone pushed us forward: https://mempool.space/testnet4/block/000000000000000926c6550e123e4825ae9210bf79bb1efbc7af0d11e18a8b8aHowever, it took around 4 hours (blocks were 2 hours in the future, and then, the actual time was put there). If nothing changes, it will take longer and longer, until the difficulty will start falling. |
|
|
|
Satoshi may have been testing out the network against 51% attack between 19th to 25th may 1. At that time, the longest chain would survive, not the heaviest. It was just a simple block counting. So, putting more power did nothing. Instead, it was all about hitting more blocks. 2. He had a prenet, where he could produce 20-bit difficulty blocks, so he could test chain reorganizations here, if needed. 3. Doing tests on live network would discourage a lot of users. Imagine you join the system, mine some blocks, they are confirmed, and suddenly, someone destroys all of that. If you consider, that even then, six confirmations were considered quite safe, then it would hurt a reputation of Bitcoin, if users would witness some deeper reorgs. 4. Deeper reorgs were discussed in details, for example Value Overflow Incident. So, such attacks would be also discussed as well, even on some mailing list, if forum was not yet there. |
|
|
|
I would like to know how to write in elliptic curve where g is a point? ECDSA is not DSA. This is not how it works. You have DSA, and you want to convert it into ECDSA, but you won't, because in DSA, you have just some numbers, while in ECDSA, you have points. Which means, that if you work only on private keys, then you can of course compute all things there. But: when you want to do the same thing on public keys, then you won't multiply two public keys alone. And also, you won't raise a given generator, to a given power, because exponentiation is just repeated multiplication. My old topic about it: https://bitcointalk.org/index.php?topic=5460766.0 |
|
|
|
If you want to preserve some rare sats (let's assume you find them in a bigger utxo), you can split that utxo into 3 Imagine how easier could it be, if only signed things would move. And if you would have to explicitly specify, what is moved, and where, for example as a commitment to R-value in a signature. But instead, Ordinals force users to create more UTXOs, for no reason. Not to mention transactions, which store ASCII-encoded transaction data inside OP_RETURN, or even JSON files. Some people wonder, why sometimes fees are high. And the answer is simple: if you have a protocol, designed to bloat the chain, then it will take more space than needed, and increase fees for everyone, for no reason. |
|
|
|
Is BIP-322 a failure case? Well, it is used in Signet. If you compare, what is signed in Signet blocks, and what message is signed by this BIP, then you will note, that they are similar. Is it unfinished and isn't there any conclusion? My conclusion is, that if you start a new regtest node, mine some coins on the desired outputs, and then ask someone, to sign specifically those outputs, then you will get roughly the same outcome, as you can get from this BIP, but easier, and with already working implementation. |
|
|
|
BIP-300 enables a new type of L2, where "withdrawals" (the L2-to-L1 txns) are governed by proof-of-work -- instead of a federation or fixed set of pubkeys. https://github.com/bitcoin/bips/blob/master/bip-0300.mediawikiThe future is now. It is possible to make P2WSH address, which can be unlocked, if you grind your signature, to take less than N bytes (testnet4 example: tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d). Which means, that sidechain users can just prepare some state of their network, convert it to 256-bit number, expressed as some private key, and use its public key in the locking script. Then, only sidechain miners will know the key upfront (and the latest state of their network, at the same time). They will grind spending transaction, until reaching enough Proof of Work, to move the coins. It is possible to use tricks like OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY, to enforce a given locktime, after enough Proof of Work will be reached. When the final transaction will be broadcasted on-chain, it will contain all sidechain fees, so they will go into mainnet miners. It means that replacing this transaction will require providing a competing grinded signature, with full-RBFed fees. The private key will be known, if grinders will use half of the generator as their R-value (to make the signature smaller), but to get the coins, the attacker would still need to do the grinding, to spend more fees, than the original transaction, and to meet all locktime conditions, set by sidechain users. |
|
|
|
What will you do when the next wave of spam floods Bitcoin? Just do more batching. Full-RBF is enabled for a reason. Your payment will be confirmed, if you will do that with another people, so that everyone will pay the fraction of the fee. The default model, where a single user is creating a single transaction, is not suitable for a large scale. Fees will be high, and doing solo transactions will be expensive. And then, sooner or later, you will have a choice: to join a group of people, and push a joined transaction on-chain, or to stop transacting, and wait for lower fees. And I don't want to wait, so I will just do some batching. The same with UTXO ownership: in the future, owning a single UTXO may be too expensive, so a lot of people will have their coins locked behind some kind of multisig, just to decrease their fees. Another thing is to redirect the flood into other systems. For example, if Ordinals are confirmed on testnet, then people don't have to push it into the mainnet. Bitcoin would be much more congested, if it would be the only network. And it would need to be much more scalable, to handle all traffic from all subnetworks. And as long as we are not there yet, then test chains can decrease the load, because then, some projects can start on testnet, and stay on testnet, if mainnet fees will be too big for them. |
|
|
|
there are not enough changes made in (either) testnet to make it deviate sufficiently from mainnet We already had enough disruption in testnet4, to activate UASF, and use new timewarp rules: https://github.com/bitcoin/bitcoin/issues/30786So, the differences are big enough, to split the chain. And if you apply testnet4 rules on testnet3, you will probably land on a different chain. Even in testnet4, I landed on a different chain, just by mining blocks 20 hours in the future. The new ASIC block will resolve those issues, but it is easy to trigger CPU-based chainsplit. |
|
|
|
the BTC client will have to support both Testnet3 and testnet4 https://github.com/bitcoin/bitcoin/pull/29775/files#diff-c534c365a32e58168519cb10607734c54323b7f79049dd9a0a3dfbdfd649b31cargsman.AddArg("-testnet", "Use the testnet3 chain. Equivalent to -chain=test. Support for testnet3 is deprecated and will be removed with the next release. Consider moving to testnet4 now by using -testnet4.", ArgsManager::ALLOW_ANY, OptionsCategory::CHAINPARAMS);See? Removing support is planned. And you can confirm it, by reading the comments in the discussion between developers. If someone else would want to develop testnet3, as an altcoin, then sure, go on. But it would be removed from Bitcoin Core in the future. |
|
|
|
can you share more numbers Just use inversion, and get some ECC calculator: 1/2=0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a1
1/3=0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa9d1c9e899ca306ad27fe1945de0242b81
1/4=0xbfffffffffffffffffffffffffffffff0c0325ad0376782ccfddc6e99c28b0f1
1/5=0x66666666666666666666666666666665e445f1f5dfb6a67e4cba8c385348e6e7
1/6=0xd5555555555555555555555555555554463c62c03cbc85871fd9f975582d3661
1/7=0x49249249249249249249249249249248c79facd43214c011123c1b03a93412a5
1/8=0xdffffffffffffffffffffffffffffffee3590149d95f8c3447d812bb362f7919
1/9=0x8e38e38e38e38e38e38e38e38e38e38d842841d57dd303af6a9150f8e5737996
1/10=0xb33333333333333333333333333333324f7a676e477fa35d0646756291bf9414
1/11=0xa2e8ba2e8ba2e8ba2e8ba2e8ba2e8ba219b51835b55cc30ebfe2f6599bc56f58
1/12=0xeaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa980759fd3760292e16fd62c011431bbd1
1/13=0x13b13b13b13b13b13b13b13b13b13b139834d5ea5c40a9dd3623dfe3727a53ca
1/14=0xa4924924924924924924924924924923c12744dd70aeb02669073cc83cb529f3
1/15=0x22222222222222222222222222222221f6c1fb51f53ce22a19938412c66da24d
1/16=0xeffffffffffffffffffffffffffffffecf03ef184454163803d538a40332dd2d
...
1/128=0x7dffffffffffffffffffffffffffffff5fe210b98a45bedd68698a894e7ab41e
1/129=0xa4b692da4b692da4b692da4b692da4b5c18a4ea054ff19b357b30348bd881e14
1/130=0x352b52b52b52b52b52b52b52b52b52b4e7c1db2bf914fdd54560dc7fb517156e
1/131=0x7b1d501f44659e4a427157f05dcd30da4254182896bd4f03546ef0e3f6b28500
1/132=0xb83e0f83e0f83e0f83e0f83e0f83e0f753ee5548eea2d0690fdf28e557c9f4c8
1/133=0xe8e6fa39be8e6fa39be8e6fa39be8e6e7ba4dc37e2d648a225da5604eb9f12f2
1/134=0x05bb39503d226357e16ece540f4898d5f11332cbd9e4f81fe7a346e495db0176
1/135=0xe759203cae759203cae759203cae7590ddcd6e80d38035c802aef0f1080384ed
...
1/0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036413d=0x3fffffffffffffffffffffffffffffffaeabb739abd2280eeff497a3340d9050
1/0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036413e=0x55555555555555555555555555555554e8e4f44ce51835693ff0ca2ef01215c0
1/0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036413f=0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0
1/0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140=0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140 For example: https://www.boxentriq.com/code-breaking/big-number-calculator |
|
|
|
It is a proof that someone had private key to puzzle 66 year before it was officialy solved. No, it is not. If you have any address for some compressed public key, then you can safely convert P2PKH into P2WPKH, and it will be standard. For example: P2PKH: 1111111111111111111114oLvT2
Script: 76a914000000000000000000000000000000000000000088ac
P2WPKH: bc1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq9e75rs
Script: 00140000000000000000000000000000000000000000 And if you know, that instead of those zeroes in the middle, you have other hex digits, then you can just copy-paste them, and change address type, as you wish. Of course, P2PKH works for both compressed and uncompressed keys, but P2WPKH are standard only for uncompressed ones. |
|
|
|
free 8$ btc
addrss compress P2PSH : 34gbwEu34QBz7bozafSyStRqw9f6Jw7cTt
privkey hex : 2832ed74f2b5e35ee
privkey wif : KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZfFoWMiwBt943V7CQeX It is not free. Those coins are burned. If you have "024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd" as a Script, which is hashed into "20d45a6a762535700ce9e0b216e31994335db8a5", then it means, that it is invalid. decodescript a91420d45a6a762535700ce9e0b216e31994335db8a587
{
"asm": "OP_HASH160 20d45a6a762535700ce9e0b216e31994335db8a5 OP_EQUAL",
"desc": "addr(34gbwEu34QBz7bozafSyStRqw9f6Jw7cTt)#yzl924t9",
"address": "34gbwEu34QBz7bozafSyStRqw9f6Jw7cTt",
"type": "scripthash"
}
decodescript 024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd
{
"asm": "-25166 OP_UNKNOWN [error]",
"desc": "raw(024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd)#nzhdaeu5",
"type": "nonstandard"
}
SHA-256(024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd)=6acc4b0c8dfbb843c080137199ef9165a7d099cad14d38d989212cb66975ba32
RIPEMD-160(6acc4b0c8dfbb843c080137199ef9165a7d099cad14d38d989212cb66975ba32)=20d45a6a762535700ce9e0b216e31994335db8a5
|
|
|
|
How would the real extended public key become known? If you have enough keys, and you know, that they are all coming from the same wallet, then you can try to retrieve the master public key, and later, the master private key. However, it seems to be not this one, which was shared, because it contains only the key to puzzle 66 (not to all puzzles). Why zpub and why BIP84 key derivation? Because it is written in this particular key. But it does not mean, that it is the same, which was used in the puzzle. It can only be used as a hint, to determine, which tools were used by the author of this post. To my knowledge BIP84 derivation is for P2WPKH, ie. native Segwit addresses which aren't used in this puzzle. Well, Bitcoin Core can sometimes give you P2PKH, and sometimes P2WPKH. It is possible, that a single master key, will give you different address types in different wallets. For example, you can see P2WPKH in Bitcoin Core, and iancoleman tool can give you P2PKH instead. So what's the purpose of a half-baked extended public key when it's incomplete? Some wallets can only load descriptors, or master keys, and in this case, you can write a single key in a "master key format". So, to sum up: I thought that the author of the post somehow got the master key, but it seems to contain only that single key, but just written in yet another format, to be loadable by some specific wallets. |
|
|
|
|
Yes, I know it is zpub. I know it uses BIP84 key derivation for P2PKH addresses. I know it contains 024ee2be2d4e9f92d2f5a4a03058617dc45befe22938feed5b7a6b7282dd74cbdd public key, double SHA-256 checksum, equal to 0xb968b15d, and some other information, which you can see in hex. However, the chain code, and some other information is still missing.
And also, even if you can figure it out, then you probably won't derive the key from the puzzle, but the "non-truncated key" instead. Which means, that you will get hard, 256-bit keys, where only some N bits would match the puzzle. But there could still be enough non-zero bits, to make breaking it quite hard, if you try this method.
And also note, that by breaking this single key, you could reach extended private key, and then access the whole wallet.
|
|
|
|
Pub Address (Extended): 4MfFsKsazAXve7DsPH6644tBvfNic7TVg3MgGJochCBzq4dGsa8abgz8Vnb63beVNuwi What is that supposed to be? This is the extended public key. I didn't verify it yet, but if it is valid, then by knowing this key, you could potentially derive all public keys from the puzzle. And if that would be confirmed, then someone could sweep all unsolved keys, up to the 125-bit public key. |
|
|
|
It works for me: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0 Edit: Also works here: User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:109.0) Gecko/20100101 Firefox/115.0 Edit: More working browsers: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:130.0) Gecko/20100101 Firefox/130.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 Edg/128.0.0.0 |
|
|
|
|
Show Posts
