Search content
Sort by

Showing 20 of 923 results by vjudeu
Post
Topic
Board Development & Technical Discussion
Re: Is It Possible to Verify Participation In Aggregated Signatures
by
vjudeu
on 06/12/2024, 13:19:13 UTC
Let's see how keys are aggregated:
Code:
P3=024CBBD03BC9B079BC360A26A034A298EB4520333F87DA4A3D195F390B50B7BD27
P2=027FA2874F02C66B1B7778FD178E8332CF113FDB5536F2005E83DD1F6E77037A89
P1=02A3D48DC0B2BA69F340F68FB4D8BEEF5BE361FB64DAB71EF74ACCF6ACABF70B01
SHA-256("KeyAgg list")=481c971c3c0b46d7f0b275ae598d4e2c7ed7319c594a5c6ec79ea0d4990294f0
SHA-256(481c971c3c0b46d7f0b275ae598d4e2c7ed7319c594a5c6ec79ea0d4990294f0481c971c3c0b46d7f0b275ae598d4e2c7ed7319c594a5c6ec79ea0d4990294f0)=634f77a422b6a39257a76f2c13ae017702bacd4c49b33dad1139cdd56060d360
SHA-256(481c971c3c0b46d7f0b275ae598d4e2c7ed7319c594a5c6ec79ea0d4990294f0481c971c3c0b46d7f0b275ae598d4e2c7ed7319c594a5c6ec79ea0d4990294f0024CBBD03BC9B079BC360A26A034A298EB4520333F87DA4A3D195F390B50B7BD27027FA2874F02C66B1B7778FD178E8332CF113FDB5536F2005E83DD1F6E77037A8902A3D48DC0B2BA69F340F68FB4D8BEEF5BE361FB64DAB71EF74ACCF6ACABF70B01)=9309c24c2bc0162de694d5f3a80e35cd17e7db4afd1994b86a1470dc4ea5bf57
Then, the aggregated hash is 9309c24c2bc0162de694d5f3a80e35cd17e7db4afd1994b86a1470dc4ea5bf57, if those three keys are sorted. Because SHA-256 is executed in 512-bit chunks, it is aligned in this way:
Code:
6a09e667 bb67ae85 3c6ef372 a54ff53a 510e527f 9b05688c 1f83d9ab 5be0cd19

481c971c 3c0b46d7 f0b275ae 598d4e2c
7ed7319c 594a5c6e c79ea0d4 990294f0
481c971c 3c0b46d7 f0b275ae 598d4e2c
7ed7319c 594a5c6e c79ea0d4 990294f0

b399d5e0 c8fff302 6badac71 07c5b7f1 9701e2ef 2a72ecf8 201a4c7b ab148a38

024CBBD0 3BC9B079 BC360A26 A034A298
EB452033 3F87DA4A 3D195F39 0B50B7BD
27027FA2 874F02C6 6B1B7778 FD178E83
32CF113F DB5536F2 005E83DD 1F6E7703

e4408850 f10bfbab 723cc288 07ec49e0 491d6a67 50fff49c 2b6358ec 0ac4bc1a

7A8902A3 D48DC0B2 BA69F340 F68FB4D8
BEEF5BE3 61FB64DA B71EF74A CCF6ACAB
F70B0180 00000000 00000000 00000000
00000000 00000000 00000000 00000518

9309c24c 2bc0162d e694d5f3 a80e35cd 17e7db4a fd1994b8 6a1470dc 4ea5bf57
So, I guess by providing some in-between hashes, it could be possible to prove, that the aggregated hash contained a specific public key. For example, for the last key:
Code:
e4408850 f10bfbab 723cc288 07ec49e0 491d6a67 50fff49c 2b6358ec 0ac4bc1a

7A8902A3 D48DC0B2 BA69F340 F68FB4D8
BEEF5BE3 61FB64DA B71EF74A CCF6ACAB
F70B0180 00000000 00000000 00000000
00000000 00000000 00000000 00000518

9309c24c 2bc0162d e694d5f3 a80e35cd 17e7db4a fd1994b8 6a1470dc 4ea5bf57
Of course, public keys are not-so-well-aligned, because they take 33 bytes, instead of 32, but still, picking any other keys will change the initialization vector from e4408850f10bfbab723cc28807ec49e0491d6a6750fff49c2b6358ec0ac4bc1a to something else. And picking any other data, would very likely not hash into 9309c24c2bc0162de694d5f3a80e35cd17e7db4afd1994b86a1470dc4ea5bf57. But: I still have to dig deeper into the code, to produce more detailed logs.

I assume at least some of my assumptions about SHA-256 are correct, because I found the same constants in the code:
https://github.com/bitcoin-core/secp256k1/blob/master/src/modules/musig/keyagg_impl.h#L64
Code:
/* Initializes SHA256 with fixed midstate. This midstate was computed by applying
 * SHA256 to SHA256("KeyAgg list")||SHA256("KeyAgg list"). */
static void secp256k1_musig_keyagglist_sha256(secp256k1_sha256 *sha) {
    secp256k1_sha256_initialize(sha);

    sha->s[0] = 0xb399d5e0ul;
    sha->s[1] = 0xc8fff302ul;
    sha->s[2] = 0x6badac71ul;
    sha->s[3] = 0x07c5b7f1ul;
    sha->s[4] = 0x9701e2eful;
    sha->s[5] = 0x2a72ecf8ul;
    sha->s[6] = 0x201a4c7bul;
    sha->s[7] = 0xab148a38ul;
    sha->bytes = 64;
}
Post
Topic
Board Development & Technical Discussion
Re: Is It Possible to Verify Participation In Aggregated Signatures
by
vjudeu
on 05/12/2024, 11:37:56 UTC
Quote
The message is signed by 100 private/public key pairs, each using a deterministic nonce value.
Can you derive it? If you can, then it is half of the job done, because if people cannot pick any R-values they want, then you can split the signature, by using derived R-value.

Quote
All information is public except for the complete set of private/public key pairs that contributed to the aggregated signature and aggregated public key.
Aggregated public key has to be public, because you have to verify, that the whole multisig is correct. So, you may not know P1, P2, P3, ..., P100, but you have to know "P=P1+P2+P3+...+P100", because this P-value is used to generate a Taproot address for the whole group.

Quote
If this verification is possible, how can I achieve it using the secp256k1 library?
A signature is just a multiplication and addition between the aggregated public key of all participants (P-value), and aggregated signature nonce (R-value). If you can split the joined signature into "P=AliceP+TailP" and "R=AliceR+TailR", then, there is only one matching s-value, meeting the equation "s=sAlice+sTail".

Quote
it seems I might need to extract the s value from the 64-byte aggregated signature (which includes both R and s) and modify it appropriately
I guess you need both R and s, because "R=AliceR+TailR", and "s=sAlice+sTail". And then, if "AliceR" is deterministic, and you can derive it, then you can avoid the attack, described by Garlo Nicon.

Quote
Additionally, I would need to remove the contribution of the specific public key (noting that the corresponding private key and nonce are known) from the aggregated public key, and then verify against the modified aggregated signature and the modified aggregated public key.
You only have to verify two signatures: the full 100-of-100 multisig, and Alice's signature. The tail signature of 99-of-99 multisig will be correct, if those two will also be, and if joining those two parts will lead you to identical signature, as in 100-of-100 multisig.

Quote
Given the available public information, is it possible to verify whether a specific private/public key pair contributed to the aggregated signature or whether a private/public key pair contributed to the aggregated public key?
It depends on the exact multisig implementation (because there is more than one way to do that, and I don't know, which one you will want to observe). It is technically possible to make proofs, that "Alice took part in this 100-of-100 multisig". But: if your model does not reveal any kind of proofs, and you can only see some Taproot address, spent by key, and you see only things, which are seen by all on-chain observers, then you cannot do that.

Because in general, it works in this way: you have a regular signature, where you don't know, if it is 100-of-100 multisig, or 2-of-2 multisig. And then, someone can give you some data, to reveal, that it is "at least 2-of-2 multisig" (or "exactly 100-of-100 multisig" in some models), and that Alice was there. But: if you don't have this additional data, then you don't know that.
Post
Topic
Board Development & Technical Discussion
Merits 8 from 4 users
Re: Is It Possible to Verify Participation In Aggregated Signatures
by
vjudeu
on 30/11/2024, 12:43:31 UTC
⭐ Merited by hugeblack (4) ,Pmalek (2) ,garlonicon (1) ,nc50lc (1)
Quote
Is it possible to verify that this specific private/public key pair contributed to the aggregated signature, or is such verification impossible?
Yes, it is possible. If you can join signatures, then you can split them as well.

https://en.bitcoin.it/wiki/Schnorr
https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

For example, let's assume, that you have some message:
Code:
SHA-256("Hello World!")=7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069
SHA-256(7f83b1657ff1fc53b92dc18148a1d65dfc2d4b1fa3d677284addd200126d9069)=61f417374f4400b47dcae1a8f402d4f4dacf455a0442a06aa455a447b0d4e170
e=61f417374f4400b47dcae1a8f402d4f4dacf455a0442a06aa455a447b0d4e170
And then, you have this signature:
Code:
P=0256B76A89AF551C6C58B1972EE5BE3DAE2A2A39202AD7439962F647780F025E6A
R=025DA08419189F4C48912F64130DC262C522EBE81E10663927FB1341EC41E208E8
s=9308a87057ca70d6b6c597f5043686f2e2fa8487e05e6e46e510528b404da729
R=(s*G)-(e*P)
e*P=03B8A8E160E82E98A0B8C5EE01FF29C3A2E77D46025F650C83A66D88BA403B1553
-e*P=02B8A8E160E82E98A0B8C5EE01FF29C3A2E77D46025F650C83A66D88BA403B1553
s*G=02ED17F278B2F475F11FCB09E6E0E0896DF364A0ED45D38562B54D97AB597207E6
R=02ED17F278B2F475F11FCB09E6E0E0896DF364A0ED45D38562B54D97AB597207E6+02B8A8E160E82E98A0B8C5EE01FF29C3A2E77D46025F650C83A66D88BA403B1553
R=025DA08419189F4C48912F64130DC262C522EBE81E10663927FB1341EC41E208E8
Then, you have some public key, and you want to prove, that it contributed to the joined signature:
Code:
P1=02F985ACFBC922F770416B08DF8349C2921C8D3FB897D33016F248AE0BAC01EAC7
R1=03291B441C0114DBD87A886B78A8638925E87AFFC8984923A73065F2A9A5C28354
s1=4070aca19b7fb7d7c176a4f07847bd95254c6aa0a4130cd5a3450687682564ac
R1=(s1*G)-(e*P1)
e*P1=03D320F76728B621214ECBF76377097543FE1C35CD0F59446B30DB101F6E1E8286
-e*P1=02D320F76728B621214ECBF76377097543FE1C35CD0F59446B30DB101F6E1E8286
s1*G=0351C2C68EC24625EAFF584FA481A0E46B99E9F115AA2606653542A3516A599305
R1=0351C2C68EC24625EAFF584FA481A0E46B99E9F115AA2606653542A3516A599305+02D320F76728B621214ECBF76377097543FE1C35CD0F59446B30DB101F6E1E8286
R1=03291B441C0114DBD87A886B78A8638925E87AFFC8984923A73065F2A9A5C28354
Now, you know, that the key "P1" also signed the message "e" with some "(R1,s1)" signature. And you also know, that there are other signers, if you subtract signatures:
Code:
R2=R-R1
R=025DA08419189F4C48912F64130DC262C522EBE81E10663927FB1341EC41E208E8
R1=03291B441C0114DBD87A886B78A8638925E87AFFC8984923A73065F2A9A5C28354
-R1=02291B441C0114DBD87A886B78A8638925E87AFFC8984923A73065F2A9A5C28354
R2=03BA57C07F6845102EF4BF058BBF9A5E306C9C6E3FA4F23FB95CC40B1F73BBA57B
P2=P-P1
P=0256B76A89AF551C6C58B1972EE5BE3DAE2A2A39202AD7439962F647780F025E6A
P1=02F985ACFBC922F770416B08DF8349C2921C8D3FB897D33016F248AE0BAC01EAC7
-P1=03F985ACFBC922F770416B08DF8349C2921C8D3FB897D33016F248AE0BAC01EAC7
P2=02C566F588AE841DBB44D6269F064F03F1231E389CAA3064F5BE8E95F6395332AD
s2=s-s1
s=9308a87057ca70d6b6c597f5043686f2e2fa8487e05e6e46e510528b404da729
s1=4070aca19b7fb7d7c176a4f07847bd95254c6aa0a4130cd5a3450687682564ac
s2=5297fbcebc4ab8fef54ef3048beec95dbdae19e73c4b617141cb4c03d828427d
And you can verify, that the subtracted part is also valid, if you try to check it in the same way:
Code:
P2=02C566F588AE841DBB44D6269F064F03F1231E389CAA3064F5BE8E95F6395332AD
R2=03BA57C07F6845102EF4BF058BBF9A5E306C9C6E3FA4F23FB95CC40B1F73BBA57B
s2=5297fbcebc4ab8fef54ef3048beec95dbdae19e73c4b617141cb4c03d828427d
R2=(s2*G)-(e*P2)
e*P2=028544ECDFF2E8817BC8700B32C59F084791C11C2F623F0429402AFD0EDE4A70B0
-e*P2=038544ECDFF2E8817BC8700B32C59F084791C11C2F623F0429402AFD0EDE4A70B0
s2*G=03B215DA5324BC05125A6CCED56E12A748F9AF8378370EDDDE69FB22AD7E12EFDB
R2=03BA57C07F6845102EF4BF058BBF9A5E306C9C6E3FA4F23FB95CC40B1F73BBA57B
But of course, you don't know, if "P1" or "P2" belongs to a single person. It can be a part of some larger group, which could be splitted further.
Post
Topic
Board Development & Technical Discussion
Merits 7 from 4 users
Re: Anyone has a minimalistic, C++ Implementation of the original bitcoin protocol?
by
vjudeu
on 27/11/2024, 07:32:59 UTC
⭐ Merited by BlackHatCoiner (4) ,ABCbits (1) ,vapourminer (1) ,tiltedIceCream (1)
Quote
only what is necessary to form a working bitcoin chain
Then, just take version 0.1.0, and remove things, which you don't need. For example: instead of "scriptSig" and "scriptPubKey", you only need "sig" and "pubKey", and ECDSA implementation. I guess the bare minimum is hashing, so you can start from SHA-256 implementation (because then, you can form a chain). The next thing is public key cryptography, which means secp256k1 implementation. If you have those two, then you can form the basic chain. If you ignore everything else, then you will have "downgraded soft-fork", where your version will only check P2PK, and accept everything else as valid.

Quote
Anyone has a minimalistic, C++ Implementation of the original bitcoin protocol?
I was trying to do something like that, but it is not yet ready.

Quote
What exactly are you trying to do and what parts of the libraries do you find non-minimalistic and why is that a problem?
I guess it is about recreating the process of making Bitcoin from scratch. Because between empty main function, and the first released version, there are definitely more points, where you have "half-baked coin", and where you can learn, why things are set, the way they are. For example: the bare minimum doesn't need any Script. The bare minimum doesn't need versioning. And there are many other things, which you can remove, and still cover everything, what is described in the whitepaper.

So, to sum up: start from SHA-256 implementation, which will give you just "something mineable, without any public keys". Then, add public keys support. And then, you will have the bare minimum.

And if you want to test some basic concepts, then you can even downgrade it into SHA-1 with secp160k1, or even CRC-32 with some 32-bit elliptic curve, if you want some weaker test network.
Post
Topic
Board Development & Technical Discussion
Re: Question about the genesis wallet
by
vjudeu
on 26/11/2024, 07:38:47 UTC
Quote
Why have the bitcoins never been moved from satoshi's genesis wallet?
Because if you start a new coin from scratch, then you naturally start from zero coins in circulation. The first version had no "Genesis Block" at all. But: if you have no such block, then you can always erase the full chain, by mining in the past. Then, you don't have to start from 2009. You can start from 1970 as well, and create a chain of blocks for 39 years.

So, you start from a version without any Genesis Block, produce some chains, and notice, that it is needed, to block any incentive, to mine blocks in the past, and constantly rewrite the chain. To make the system honest, it is also needed to prove somehow, that you also didn't mine the chain in advance, and everyone had the chance to mine it, after being released.

Then, you use some information from the outside, like a text from the newspaper (or the mainnet block hash, as it is in testnet4). You make this block special, which also allows you, to reset the chain, if needed. And during testing, you can check different scenarios, by starting from different genesis blocks.

For example: this is prenet Genesis Block: https://bitcointalk.org/index.php?topic=5355610.0

Quote
They can't be moved because they are like a bank's reserve or is there another theory?
Those coins are locked forever. Coins could be locked into OP_RETURN as well (or rather: OP_FALSE, because the meaning of OP_RETURN was different at that time), or the amount could be set to zero. It doesn't matter, nobody can access them, because you start from an empty database, and then add new coins, on top of that. Of course, it was more natural, to use a regular OP_CHECKSIG, with a regular key, to have the ability to prove, that you started the chain, if that would ever be needed.
Post
Topic
Board Development & Technical Discussion
Merits 3 from 1 user
Re: Will the high volume of transactions make Bitcoin more anonymous?
by
vjudeu
on 26/11/2024, 07:17:45 UTC
⭐ Merited by ABCbits (3)
Quote
I didn't know if it was possible to change the outcome of TX numbers with some coding skills
Well, you can mine anything you want. Transaction ID is just SHA-256 of some data. And everything can be mined: you can mine block headers, you can mine addresses (then you get vanity addresses), and you can mine transaction IDs.

Quote
Sadly, I can't visit topic=528291.
https://bitcointalk.org/index.php?topic=5282911.msg56567378#msg56567378

Quote
with increased block size
I guess this thing will not happen. Because it will allow more spamming, and will not increase the number of transactions significantly enough. I think we will rather see single UTXOs, handling more than one person, and transaction joining. And of course, Ordinals blocked any block size increase for a while, and this argument will always be raised, if anyone will attempt to do so in the future.

Quote
Imagine current Bitcoin but with a huge block size and millions of transactions every day.
And also with much less nodes than today, where you cannot download historical data, because there are not enough non-pruned peers, which will serve you that data.

Quote
it should be very hard to track my mixed coins because there will be many people who sent 1 Bitcoin and received almost the same on another address
You assume, that other people make their transactions in a proper way. But very often, it is not the case. For example: if you don't reuse addresses, but 99% other people do so, then by taking a set of transactions, and excluding address reuse, it is possible to find you.

Which means, that if you want to hide properly, then you have to get some statistics first, and see, what is the most popular way of using a given coin, and do it in a similar way. And then, the question is: if other people significantly degraded their privacy, does it really matter, if there are millions of transactions, if all of them passed through KYC?

Quote
I'd love to know how Blockchain Analysis companies work.
Then just run a full node, and observe some traffic. There are many cases of address reuse, KYC, SPV nodes connected directly to you (so you can get their IPs, and connect them with their transactions), and so on. And for example Ordinals make it even easier, when people first publish some data on-chain, and then post on social media, that they own some monkeys.

Not to mention, that you can also group people by used amounts, address types, or even client versions. And many nodes, running 24/7, have some static IPs, so you can even check that kind of data.
Post
Topic
Board Development & Technical Discussion
Merits 8 from 2 users
Re: Requesting Testnet4 tBTC
by
vjudeu
on 23/11/2024, 08:55:46 UTC
⭐ Merited by LoyceV (4) ,vapourminer (4)
Quote
Shower thought: I'm not sure how "chain work" competes against "chain length": can 1 difficult ASIC block wipe out thousands of easy CPU blocks?
Yes. The main limitation is difficulty adjustment: you cannot make "stronger" block, than your difficulty says (because then, everyone would just work on top of the Genesis Block, all the time, and would be guaranteed to throw away the whole chain in the future, with constantly increasing probability).

For example: the Genesis Block has the "real" difficulty of 2536, but it is declared as "1d00ffff", so it is only counted as 1. And the chainwork is then counted as 0x100010001, not 0x9e8770a5c23.

Quote
Does this mean an ASIC miner can reorg the last ~600 blocks if he ignored those blocks and mines 7+ blocks on top of block 54502?
Yes. But they don't do that, because most miners just run the default settings, without thinking about profitability, and without coding their own implementations. I guess most people would not even enable CPU mining, if Garlo Nicon would not share those changes publicly. It is not that easy to come up with a better algorithm, and most people are not programmers, and they simply stick to what they can find, instead of writing their own code.

However, if ASIC miners would want to maximize their profits (and lower the network difficulty), then they would ignore hundreds of CPU-mined blocks, and only consider ASIC-mined blocks as "real", and reorg all CPU-mined blocks, just by mining on top of the latest ASIC-mined block.

But of course, as long as this change is not implemented, then this miner can happily rule testnet4, and make it de-facto signet for a while. Because each ASIC block, which will confirm all previous blocks, basically sets the attack in stone, so the chain will not be reorged in the future.

And also, because testnet4 coins got some value anyway, and are actively traded, then another network should be used for real testing. And of course, testnet5 should have completely different rules, because in other case, Bitcoin Core developers would participate just in altcoin pump and dump, if they will keep making test networks, without preventing those coins from being traded.
Post
Topic
Board Development & Technical Discussion
Re: Will the high volume of transactions make Bitcoin more anonymous?
by
vjudeu
on 22/11/2024, 14:46:45 UTC
Quote
Will the high volume of transactions make Bitcoin more anonymous?
No. For example, let's assume, that you make a transaction like this one: https://mempool.space/tx/000000000fdf0c619cd8e0d512c7e2c0da5a5808e60f12f1e0d01522d2986a51

Then, does it matter, how many transactions are there? In practice, not really, because for example making a transaction with a lot of leading zero bits is something, where you have to write some code, to achieve that. Which means, that a typical user won't do that, and it is crystal clear, that someone who did it, had some coding skills. And that information alone can be used to narrow down the possible set of coin owners.

Quote
I mean those transactions that use mixers, CoinJoin and btc to monero exchange methods to hide the identity.
If you have a lot of small transactions, and some huge CoinJoins, then CoinJoin participants are only hidden inside the CoinJoin traffic. That's why, it is possible to sometimes achieve better results, just by doing a regular one-input-two-outputs transaction, than being a part of some huge CoinJoin.

The same with address types. Some people use only addresses starting with '1'. If you increase Segwit traffic, it won't change their situation (and vice versa).

And the same with coin amounts. If you send 0.01 BTC, then you can hide in a group of people, which also use round amounts. And seeing more transactions, sending 0.01234567 BTC, won't change your situation.

Quote
I mean hundreds of millions of transactions every day
If you want to get there, then you need transaction joining. And then, things which can be seen on-chain, are loosely connected with actually performed transactions, because then, a single on-chain transaction can handle a lot of users. Which means, that you have "Alice -> Bob -> Charlie -> ... -> Zack" seen in wallets, but "Alice -> Zack" is what you can actually see on-chain. The 4 MB witness limit won't let you push hundreds of millions distinct transactions on-chain, where every user would have its own UTXO. Instead, you would have multiple users per UTXO, to fit all of that in a block.

Quote
with millions of transactions, it should be very difficult to track, right?
Difficult, but still possible, because the traffic of unconfirmed "to-be-batched" transactions, can still be observed. For example: if you have Lightning Network, then on-chain, you have just some channel opening, and channel closing transaction. But: if you run some LN node, then you can observe, how coins are flying through your node, and you can get some statistics, out of that. And then, on-chain, after getting a lot of confirmations, you can only see a few transactions here and there, to set up, and close channels, but if you had a node, running 24/7, then you can have a clue, what happened in-between. And the same is true with transaction joining: nodes would still need to broadcast to-be-batched transactions in unconfirmed state, and they could be traced in a similar way, as LN transactions are traced today.
Post
Topic
Board Development & Technical Discussion
Re: modular inverse in bitcoin arithmetic
by
vjudeu
on 19/11/2024, 06:00:10 UTC
Quote
nothing is said about working with very long numbers.  So I presume that is trivial to both languages.  Is this correct?
Yes, they both have unlimited integers.

Quote
I will want to use some simple GUIs to help me understand what I am going.
It is hard to graphically express enormously big curves. Here are all of them, meeting y^2=x^3+7 equation, up to 1000: https://github.com/vjudeu/curves1000/tree/master/png

For example, if you have p=967 from Garlo Nicon's examples, then you have this: https://raw.githubusercontent.com/vjudeu/curves1000/refs/heads/master/png/967.png

Quote
Should I use Ruby per all the web pages, or Python per the book.
You can pick any language you want. Also, if you just want to explore basic things, then curves up to 32-bit should be sufficient, so you can use any language, even C/C++, because it will take some time, to know enough, to work with bigger curves correctly.

Example 32-bit curve: p=0xfffff9af, n=0xfffe390b, base=(0x1,0x3cad5d2d)

Also, Sage is your friend: https://sagecell.sagemath.org/
Code:
p = 0xfffff9af
n = 0xfffe390b
h = 1
K = GF(p)
a = K(0)
b = K(7)
E = EllipticCurve(K, (a, b))
G = E(0x1,0x3cad5d2d)
E.set_order(n * h)
d = 0x1
P = d * G
print(hex(P[0]),hex(P[1]))
And then, you have two points, for example (0x1,0x3cad5d2d) and (0x3,0x43f09f34). If you can't get the private key here, then you won't succeed with bigger curves, so you should start with this 32-bit curve, or smaller, and get familiar with them first.
Post
Topic
Board Bitcoin Discussion
Merits 2 from 1 user
Re: Nakamoto's wallets will cause chaos
by
vjudeu
on 12/11/2024, 07:41:20 UTC
⭐ Merited by ABCbits (2)
Quote
DISCLAIMER: For the purposes of the following article I'll be operating under the assumption that the so-called "Patoshi Pattern" is, in fact, a single miner entity and that this entity was Satoshi. As such, I shall use "Satoshi" and "Patoshi" interchangeably. While it is not possible to prove this claim beyond a reasonable doubt, the behaviors exhibited by this miner suggest someone with an extremely deep knowledge of Bitcoin very early in its existence - a Satoshi-level understanding. But that's a topic for another post.
See? Even in the sources you linked, there is still some doubt, if Satoshi=Patoshi. And I think it is not the case, for example because the Genesis Block does not match some patterns.

Also, each time, when extraNonce was resetted to zero, then you can have this miner, or that miner. And the way of mining also changed over time.

Quote
I don't know that 20,000 inputs is a threshold
1 MB legacy transaction size is a threshold. If you have 1400 UTXOs, then you have 70k coins. That will give you a transaction of slightly below 100 kvB. So, for 14,000 UTXOs, you can potentially move 700k coins, maybe 750k coins, if they are all P2WPKH inputs. But: because of legacy P2PK or P2PKH, it will take much more space than that.

Quote
there are very few transactions that have 20,000 inputs
Note that you will need a regular DER signature, for each individual input. And note that you cannot use a Segwit discount, because it didn't exist at that time, and you had only P2PK or P2PKH. So, you will need at least a few blocks, to even combine all of those coins, even if you solve everything at once.

Quote
Only 9 transactions have 20,000 inputs and there is no block with more than 20,000 inputs.
Well, 20k inputs in a single 1 MB legacy block space, would mean something around 50 bytes per input. It is hard to get DER signatures that small. The smallest valid ones take 9 bytes, and you would need the private key for x-value pubkey below 0x80 (which is very hard), and around 2^249 s-value grinding (which is also extremely hard). Even exploiting SIGHASH_SINGLE bug will force you to grind a lot of SHA-256 transaction data, to get 9-byte signatures, because for around 128 valid s-values, and around 64 valid r-values, you will get around 8192 matching keys, so even if you prepare non-random pubkeys upfront, it will be hard to get there.
Post
Topic
Board Bitcoin Discussion
Merits 5 from 2 users
Re: Nakamoto's wallets will cause chaos
by
vjudeu
on 11/11/2024, 21:50:14 UTC
⭐ Merited by ABCbits (4) ,vapourminer (1)
Quote
what do we do with addresses which have no owners, or Nakamoto's wallets?
Nothing. The default action is "do nothing, keep the status quo".

Quote
Nobody can move the bitcoin from the weak addy to a strong quantum addy.
Yes. But: if it will be possible to make a valid signature, without knowing the real private key, then it may be still possible, to require some stronger proof.

For example: nobody knows the private key to 032baf163f5e27261ab3228e61fb86dc98054abd514751fce93d7444e8fbc6a293, but coins from this P2PK were moved, because of SIGHASH_SINGLE bug: https://mempool.space/testnet/tx/3952b35bde53eb3f4871824f0b6b8c5ad25ca84ce83f04eb1c1d69b83ad6e448

And if for example this particular way of spending coins will turn out to allow "fake signatures", targeting real keys, then it is possible to block only that single path, without blocking anything else.

Quote
A theft of 1M btc would cause chaos.
1. I doubt, that Patoshi=Satoshi.
2. Coins are splitted. You don't have a single UTXO with 1M coins. You have 20k different keys, holding 50 BTC on each UTXO.
3. Moving 1M coins will not happen in a single block, because if you have 20k inputs, then it will be too huge transaction, to get everything at once.

Quote
the dev should lock address where it's public key is known which isn't really related with SHA-256
1. All transactions flying in mempools, have their public keys already exposed.
2. A lot of hash-based address types, have also their public keys exposed. They are then weaker, because you can break them by valid signature, and also by a different public key, giving the same 160-bit hash.
3. You cannot use a coin today in a meaningful way, without having OP_CHECKSIG, or its equivalent.
4. Breaking SHA-256 will also break OP_CHECKSIG, because then, it is possible to make a random valid signature, and then make a transaction, matching a given 256-bit preimage.
Post
Topic
Board Bitcoin Discussion
Re: The Possibility Of An Altcoin To Overcome Bitcoin Is Very Rare.
by
vjudeu
on 05/11/2024, 14:10:54 UTC
Quote
Internet Explorer is the most popular web browser and everybody knows about it, and it's everybody's first browers, bla bla bla
In case of a browser, you can use Internet Explorer, or Mozilla Firefox. Or Google Chrome. Or Safari. You have a choice. And if you create a website, then you don't have to change your hosting provider, if you want to switch your browser.

When it comes to cryptocurrencies, then you cannot hold both BTC and LTC, at the same time, with the same amount. You cannot have $1000 in "crypto", and decide, that "today, it is $500 in BTC, and $500 in LTC". And tomorrow, if you change your mind, then you cannot instantly say "now I signed this message, so now I pick $700 in BTC, and $300 in LTC, and want to use it in that way". You have to make a transaction, and pay some fees. Which means, that changing your choices, creates additional costs, which can very easily become a bottleneck, because you don't have "just $1000 in crypto". You have to pick something, and stick with that choice. And as long as it is the case, and as long as altcoins create completely separate monetary bases, you have to pick only "this coin or that coin". You cannot have both BTC and LTC, on the same UTXO.

So, it is more similar to the situation, where you have some EXE file, and you want to switch from Windows to Linux or MacOS. Of course, there is Wine project. But: it took many years for people, to get there. And still, there are many cases, where a particular EXE file works only under Windows, and nowhere else. And then, you are forced to use Windows, even if you don't want to.

And then, the comparison is even more fair, if you pick "x86 vs ARM vs M1 vs AVR", and so on. Because then, if you have your EXE, and you want to run it somewhere else, then you still need a compatibility layer, like a virtual machine, or a transcompiler, which will translate all of that, opcode by opcode. Then, you really have to "abandon EXE, to have ELF", just like you have to "abandon BTC, to have LTC". You cannot use both, at the same time, just like you can visit bitcointalk from two different browsers.

Quote
But the only "1000x" opportunities out there will be from digital currencies that change the paradigm
I think people need more features on existing coins, and not just more coins. If your strategy is "please sell your BTCs, and buy my product", then many people will not do that, because they know the history. I guess a lot of BCH users would really want to have 1:1 peg with BTC today. Now, after 7 years, it is clear, that those, who stayed with BTC, simply won.

And also, this "1000x" stick has two ends: there is of course a chance for 1000x gains, but there is also a chance for 1000x losses. And if you are not an altcoin creator, then you usually are on the losing side, when altcoin makers simply cash out into BTCs, and leave naive investors behind. It happened too many times in the crypto world, so wise people have many reasons, to worry about that kind of scenario (and not that many examples of 1000x gains, to really believe, that this particular altcoin is the unicorn).
Post
Topic
Board Development & Technical Discussion
Merits 8 from 2 users
Re: Requesting Testnet4 tBTC
by
vjudeu
on 05/11/2024, 10:45:08 UTC
⭐ Merited by mikeywith (4) ,LoyceV (4)
Quote
Lifting the 21M cap
It wouldn't change anything now, because we are still before the first halving. And I don't know, if testnet4 will live long enough, to even approach the first halving.

Quote
Removing the 20mins exception rule all together
It will only increase the price on centralized exchanges, and make testnets even more similar to the mainnet. Then, a different Genesis Block, would be the only major difference.

Quote
Reset the blockchain every X block
Yes, I guess X=1 should work quite well.

Quote
I need 866TH to solve a block every 10 mins on average
The real difficulty is around 6x bigger, than it should be, because of CPU miners.

Quote
I don't need to keep it mining 24/7
Once per two weeks, there is a difficulty adjustment, and then, only ASICs can mine a single block. Recently, it took one hour. And before that, there was a time, when it took around 4 hours. And ASIC miners could simply block all CPU miners, once per two weeks, if they would just stop mining.

Quote
you can always see their blocktimestamp is 20m+1 second of the previous block
If no CPU solves the block for 20 minutes, then the difficulty drops to the minimum for everyone. Then, even if you have some ASIC, you have no other choice, than to mine at the minimum difficulty. Of course, you can mine in the past, but Median Time Past rule forces timestamps to move forward, so it is quite limited by the timestamps of the previous blocks (which is why sometimes you have no other option, than to put a timestamp from the future, when MTP rule forces you to do so).

Quote
It explains how none of other miners can compete at 121M difficulty.
Well, it just makes much more sense to mine mainnet blocks, or pick some other altcoin in that case. Many people expected to sell testnet4 coins at 7000 satoshis per unit, and they were quite surprised, when CPU miners dumped 100k coins, and dumped the price into 20 satoshis (which is now slowly recovering, but testnet3 is worth much more than testnet4, so many people just don't have any reason to switch; also because testnet3 is much faster chain, and allows much more bloat).
Post
Topic
Board Development & Technical Discussion
Merits 5 from 1 user
Re: What happen if Merkle trees didn't include in blockchain?
by
vjudeu
on 04/11/2024, 06:11:47 UTC
⭐ Merited by ABCbits (5)
Quote
what would happen if merkle trees didn't included in the blockchain
Then, instead of a single 256-bit number, you would have only the transaction counter in the block message, and all transactions after that.

Quote
SPV mechanism would be more difficult and less efficient, since it needs to download whole block which contain relevant TX.
If you use a hash function like SHA-256, which is based on Merkle–Damgård construction, then things can be optimized, and then done in SPV way. For example: you can give someone the initialization vector, just before the latest SHA-256 internal block, and the last 512-bit chunk. It would be sufficient to verify, that the hash of the whole block was mined correctly.

The same about proving transaction inclusion: even if you hash all data, as a single SHA-256 call, then still: you can prove, that a chunk "X" is included, by giving the initialization vector, some chunks in-between, and a final SHA-256 result, for that specific chunk.

So, SPV would be of course harder, but still possible, because SHA-256 splits data into 512-bit chunks by definition.
Post
Topic
Board Development & Technical Discussion
Re: Could alternative (e.g. post-quantum) cryptography be introduced via BitVM?
by
vjudeu
on 01/11/2024, 21:09:05 UTC
Quote
However, the idea with BitVM is that any cryptosystem could be emulated.
Yes. But it is costly, if you have to put all of that on-chain. It is much better to just have some external proof, and only commit to it on-chain. For example: something like this sudoku puzzle: https://github.com/zcash-hackworks/pay-to-sudoku

Imagine how more complex everything would be, if you would push the whole NxN sudoku puzzle inside the input script.

Quote
The Bitcoin developers would have some time more to decide which algorithm is the best one
No matter what you pick, it should be deployed on some kind of test network first anyway. So, no matter if it would be a soft-fork, or a long Script, the way of deployment is similar.

Quote
I'm however not sure how much must be posted on-chain in the case a spend is contested.
If you have some external proof, then in most cases, you cannot spend the coin on-chain, if you don't know the solution.

And if some different elliptic curve is used, then you can use a DLEQ proof: https://groups.google.com/g/bitcoindev/c/MezoKV5md7s

Quote
if BitVM can/should be used for this purpose
I guess not, because if you have to put a lot of data on-chain, then it is an equivalent to shrinking the maximum block size. And those limits will not be lifted in the nearest future, because it would only open a wide door for some spam, and the amount of real coin usage will be left unchanged (or even some users will switch into other networks, as a result).
Post
Topic
Board Development & Technical Discussion
Merits 4 from 3 users
Re: Could alternative (e.g. post-quantum) cryptography be introduced via BitVM?
by
vjudeu
on 01/11/2024, 05:27:43 UTC
⭐ Merited by ABCbits (2) ,d5000 (1) ,vapourminer (1)
Quote
Would this be possible?
It is better to make a regular soft-fork in that case: https://groups.google.com/g/bitcoindev/c/p8xz08YTvkw

Quote
I can imagine the "simulation algorithm" to be enormous, like the gigabyte-big ZK provers.
It shouldn't matter, because you shouldn't put everything on-chain. See: https://bitcointalk.org/index.php?topic=277389.0 (this topic contains the word "witness", but it is not about Segwit).

Quote
Or are there unsurmountable challenges?
Even if ECDSA will be broken, then still, there are scripts you can do, which could be safely used, even in that kind of scenarios. For example: "OP_SHA256 OP_CHECKSIG" is one of those Scripts, where you have to put a message, which will hash perfectly into x-value of the public key, and will pass Schnorr signature verification.

Another example is "Pay to Proof of Work", when you require a DER signature below N bytes.

So, even if OP_CHECKSIG will lose its original meaning, then still, it will then be just a calculator, working on 256-bit numbers. But: it will be possible to mount another challenge, where you would need many OP_CHECKSIGs, to move the coins. And they can be wired in a way, where knowing the private key will give you no advantage, because the challenge will require solving dependencies between keys, and not the keys alone.

Quote
Was this perhaps even discussed in some technical forum or mailing list already?
Well, there are some posts. Here is another one: https://groups.google.com/g/bitcoindev/c/SPmrzARLMFU
Post
Topic
Board Development & Technical Discussion
Re: Requesting Testnet4 tBTC
by
vjudeu
on 28/10/2024, 11:30:25 UTC
Quote
How do I create my own block header from scratch?
You call "getblocktemplate", and Bitcoin Core gives you everything you need, to form a full block.

Quote
Is there a Bitcoin Core command which creates me the 80-bytes given input parameters?
There were in the past, but they are now deprecated. Now, you pass the whole block template into your mining software, which then constructs it, based on that. But: if you explore a block template, then you notice, that it contains everything you need.

Quote
What if none of the 2^32 nonces is correct?
Then, you just try a different block header, until you hit it. In case of ASIC-mined blocks, checking all 2^32 nonces takes them just some seconds, and most of the time, they use something called "extraNonce", which is just a value, pushed on the stack. Which is why when you explore their coinbase transactions, you can see this extraNonce, set to some 32-bit value (which will then give you a block with 64 leading zero bits).

Also, for the same reason, ASIC miners grind their timestamps, and block versions, which was called in the past "ASIC boost", because it is faster to modify a block header, than the coinbase transaction, and recalculate the merkle root. And also, some people wanted to fix it, by allowing to put non-zero bits in places, like "previous block hash", where you will always have some zeroes, and based on difficulty, this space could be potentially used for additional bits.

Quote
Sorry for the loaded questions
No problem. Testnets are created mainly to test mining, because everything else can be easily tested from a user perspective, if you have other networks like signet. So, it is natural to ask about mining in testnets.
Post
Topic
Board Development & Technical Discussion
Re: Requesting Testnet4 tBTC
by
vjudeu
on 28/10/2024, 10:33:07 UTC
Quote
Is there a mining software which can take block timestamp as an input value?
Yes, try "bitcoin-util grind". It will allow you to CPU-mine absolutely any block headers, you just put some 80 bytes there, and you will get some 80 bytes back, with the right nonce (if it exists).

Quote
The ckpool miner not only does keep the block for 20 minutes before sending it, but his timestamp is also 20 minutes plus a second into the future.
Yes, because you first mine a block with future timestamp, and then you broadcast it, at the right time. If you would mine it with earlier timestamp than that, then you would need to meet the real network difficulty. Which is also, why ASIC miners increase inflation, when they put the current time in their blocks (because then, the current time can be rolled back, according to the MTP rule, and the same timestamp can be reached again by CPU miners).
Post
Topic
Board Bitcoin Discussion
Re: Gresham's Law and Bitcoin
by
vjudeu
on 28/10/2024, 07:55:13 UTC
Quote
Could something like this happen to Bitcoin?
Of course. For example: you have a lot of bad altcoins, which are terrible, when it comes to preserving any value, but they are great, when it comes to transacting. Also, that's why Bitcoin domination is decreasing over time.

Quote
same currency in two different physical forms
Then, you can compare Bitcoin with Lightning Network or with sidechains.

Quote
Bitcoin only has one possible manifestation, so Gresham's Law cannot apply
What about test coins, like testnet3 or testnet4? If you check https://altquick.com/exchange/ and look at "Weekly BTC volume", then testnet3 is usually at the top. And if you look at https://mempool.space/testnet then you will see, that the network is so congested, that you can get around 40 tBTC from fees alone, and 2 GB of block data, worth 2500 tBTC, is waiting for confirmation.

Also, there is a way, to wrap BTCs, and make an altcoin out of that, while maintaining 1:1 peg, and while having peg-ins and peg-outs, in a form of real BTC transactions. So, there is definitely more than "one possible manifestation", because you can always "sign coins, to peg them in", and then "move coins, to peg them out".
Post
Topic
Board Development & Technical Discussion
Merits 4 from 1 user
Re: Requesting Testnet4 tBTC
by
vjudeu
on 28/10/2024, 05:21:43 UTC
⭐ Merited by BlackHatCoiner (4)
Quote
it returns "null"
Quote
3. You avoid all kind of "already seen block, nothing to be done" cases, where your own node will do nothing, because it already has that particular block.
If you send a block to your own node, which already has it, then it does nothing.

Quote
Why is it inconclusive?
Let's see the code: https://github.com/bitcoin/bitcoin/blob/master/src/rpc/mining.cpp#L1057

Quote
Code:
static RPCHelpMan submitblock()
{
    //...
    bool new_block;
    auto sc = std::make_shared<submitblock_StateCatcher>(block.GetHash());
    CHECK_NONFATAL(chainman.m_options.signals)->RegisterSharedValidationInterface(sc);
    bool accepted = miner.processNewBlock(blockptr, /*new_block=*/&new_block);
    CHECK_NONFATAL(chainman.m_options.signals)->UnregisterSharedValidationInterface(sc);
    if (!new_block && accepted) {
        return "duplicate";
    }
    if (!sc->found) {
        return "inconclusive";
    }
    return BIP22ValidationResult(sc->state);
},
    };
}
I guess your block is then "valid", but there is some other block, at the same height. And then, your block may be correct, but the other block may be also correct. The next block will tell the truth. And the next ASIC block will pick the right chain, and destroy all alternative chains.

Or: maybe you are trying to submit a block too early to the node, when it is "not yet valid". Because you have a valid block, some CPU miners have a valid block, some ASIC miners have a valid block, and first-seen-safe rule is applied. And because the block difficulty is equal to one in "86% cases", then the final winner is announced, when the block with the real difficulty appears.