 Show Posts
|
|
Pages: [1]
|
Blockstream's explorer can already show the signature of each input I don't want to get only (r,s) pair, because it is trivial. I want to get data, behind a given z-value. For example, you can see this transaction: 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000147304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0111000000 And then, you can easily notice this signature: 47304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01 Then, extracting (r,s) pair is trivial, and anyone can do that easily: r=3609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a
s=573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee However, to fully verify things, you also need z-value. And it is not just a transaction hash. Instead, it is that thing: 0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000 And then, you can complete the proof: z=c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670
r=3609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a
s=573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee
Q=025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357
n=fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141
1/s=18c3acadca5e7b9fc3cd6b221f30e66fa26c07450aeafe2327f6c51fd7a75147
z/s=df8e03f52bb441d2e9ed959efabceaebbc9211918c5e5420b8164577f9c603eb
r/s=93978dc15dbb351e107f083839792787230beb342db2a8bea4fd3fa18990c6a7
(z/s)G=024D008960C8AAFA40869FDACF9088FC96F68E6AC6DBC26ADAB611145C7BB2C12A
(r/s)Q=03E830824028F11FC59B3D4C1A7A135D1DFB3FD3CA7E7563D896889B46A77DCF13
R=(z/s)G+(r/s)Q
R=023609E17B84F6A7D30C80BFA610B5B4542F32A8A0D5447A12FB1366D7F01CC44A
R.x=3609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a But: getting this z-value is far from trivial. And it is different, if you have different address types. It is not just a hash of the transaction, it is much more complex. For example: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawikiSo, is there any tool, which would work in that way? decodesignatures 01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f0000000000eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000147304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0111000000
{
"signatures": [
{
"hex": "47304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee01",
"r": "3609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a",
"s": "573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee",
"sighash": "01",
"data": "0100000096b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd3752b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3bef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000001976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac0046c32300000000ffffffff863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e51100000001000000",
"z": "c37af31116d1b27caf68aae9e3ac82f1477929014d5b917657d0eb49478cb670",
"version": 1,
"prevouts": [
"hex": "96b827c8483d4e9b96712b6713a7b68d6e8003a781feba36c31143470b4efd37",
"data": "fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01000000",
"vin": [
{
"txid": "fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f",
"vout": 0
},
{
"txid": "ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a",
"vout": 1
}
]
],
"sequence": [
"hex": "52b0a642eea2fb7ae638c36f6252b6750293dbe574a806984b8e4d8548339a3b",
"data": "eeffffffffffffff",
"sequences": [
4294967278,
4294967295
]
]
"vin": [
{
"txid": "ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a",
"vout": 1,
"scriptSig": {
"hex": "1976a9141d0f172a0ecb48aee1be1f2687d2963ae33f71a188ac"
},
"value": 6.00000000,
"sequence": 4294967295
}
],
"outputs": "863ef3e1a92afbfdb97f31ad0fc7683ee943e9abcf2501590ff8f6551f47e5e5",
"locktime": 17,
"sighash": "01000000"
}
]
} the explorer has to store this additional data on top of what they are storing They don't have to "store" it, just "compute" and "show to the user". And if this is computationally expensive, then maybe it can be done on a client side, instead of server side? |
|
|
|
There are many kinds of block explorers: some are just showing regular blockchain data, as they are handled by full nodes. Some are UTXO-based, and focused on pruned ones. However, when I think about it, I guess we could need another kind of explorer: a signature explorer. Why it would be needed? Well, there are many questions about z-values. Extracting them from transactions, and signed messages, can be tedious. It is much, much easier, to just hack into the client, and dump signatures in that way, than to write a code from scratch, which would handle FindAndDelete, Segwit, Taproot, Bitcoin Message, and who knows what. Also, actually signed messages are quite similar, to what is really shown by block explorers anyway. For example: instead of scriptSig, there is a previous output script. Another thing is that if you can see, what is actually signed, then you can better understand different sighashes, SIGHASH_SINGLE bug, s-value grinding, and so on. |
|
|
|
It's pretty curious that I am talking about how we need to increase bitcoin block size while others come up with a solution to decrease the amount of storage we need to occupy to support bitcoin. Do you have full archival node? Because if you do, then I wonder how many times it crashed, and you had to reindex it. Because for example copying 500 GB of data from one disk to another is not a big deal. The bigger problem is verification time, where you can spend a week on reindexing the chain, and rebuilding the database from scratch, even if all blocks are already downloaded. I think we should step up, hardware aren't that expensive today as they were back ten years ago. I also wonder, how many times you tried to verify the chain. Because CPU speed is not much better than ten years ago. When it comes to CPU speed, you can for example see, that CPU-based mining is still quite slow, which means, if you want to mine blocks on the lowest difficulty, it is not that much better, than it was ten years ago. If you look at signet, you see that the base difficulty is even lower than on mainnet! And now, I made a copy of the whole chain on my 4 TB external disk, and I spend next hours on getting it reindexed, to the point where it were before latest crash. Guess what: copying the whole chain was quite fast, but verification is still ongoing, it was started on Monday this week, and I hope it will finish before next Monday, without crashing. But I restart the client regularly, and refresh my copy, to not start reindexing from 2009 again. Guess what: reindexing is much slower than refreshing my backup. |
|
|
|
We can get 4 TB M.2 SSD around $200 nowadays so the cost of maintaining the full blockchain data is cheaper now compared to few years back, so I will still recommend go with the full data I already have one full archival node, and many pruned nodes. The cost is not the issue in case of local node, the problem is you usually don't get hardware with built-in 4 TB disk, so you need some external one. And then, OS can do some optimizations to turn it off, when it is not used, and then you need to reindex your full node, because of corrupted database, when Bitcoin Core is killed by some I/O error. Also, if you have any server, running 24/7, then it is not one-time-cost to buy some larger disk, because you pay monthly or yearly for that, so it is a cost, that will force you to pay more, for a longer time. Which means, having 4 TB of storage on your server in the cloud, will eventually be much more expensive than having 4 TB of local storage, because you are not the owner of that disk, but you pay for a service of having that storage, and then it quickly becomes more expensive than buying a disk and owning it. |
|
|
|
|
Just an idea, but I think it is worth implementing. If you want to get a block explorer, it requires storing the whole chain. That means, you need to have all blocks, and maintain full archival node, if you want to run a block explorer. As blockchain gets bigger and bigger, people no longer can use their internal HDD or SSD, permanently attached to their machines, because many devices have 256 GB or 512 GB storage. That means, some external disks are needed, for example connected via USB.
So, what is the problem with external disks? Well, they are sometimes disconnected by the OS, for example when Bitcoin Core downloads a lot of data into memory, and processes all of that, without doing any I/O for a long time. Which means, some unexpected I/O error could easily kill Bitcoin Core, and then you end up reindexing the chain (which takes a lot of time, even if you have for example the first 500 GB already downloaded, and stored on your external disk). That also means, if you cannot turn "energy efficient mode" off, you are forced to monitor your Bitcoin Core client, and restart it every sometimes, just to dump everything into your disk, before your OS will detach it, because of external disk inactivity for N minutes.
That means, the final setup looks like that: there is a full archival node, sitting on some external disk, just to be safe, and to have the whole blockchain, just in case. But on internal disk, on which OS is running, there is some pruned node, for daily operations. Also, when it comes to nodes running 24/7, those nodes usually can be placed on some servers, but their storage is usually not so big, to allow storing the whole chain. Which means, only a local node on external disk is full archive node, all other nodes are in pruning mode.
As blockchain gets bigger and bigger, we can expect there will be more and more pruned nodes. Because using external block explorers is unsafe, it is usually a good idea to have your own block explorer, and just import addresses as watch-only, if you want to explore them. However, if your node is in pruning node, then some commands does not work, for example importing addresses, because there is not enough history for a full rescan. Which means, to have a full functionality, it is still needed to attach some external disk, and ask full archival node for some proofs, to import them into pruned node.
However, pruned nodes already contain a lot of useful information. For example, each pruned node can verify, if a new incoming transaction is correct or not. That means, each pruned node contains a full UTXO database. And very often, what users really care about, is not the full history, related to some address. Users often just want to observe only some unspent transaction outputs, and not dig into the whole history of past transactions, and spend transaction outputs. All of that leads us to the idea from the topic: having UTXO explorer, instead of block explorers.
|
|
|
|
|
When you read about ECDSA used in Bitcoin, you probably learn about adding points and doubling it. But it is also possible to subtract any two points. You can also multiply or divide any point by any number, but you cannot multiply or divide two public keys without knowing at least one matching private key.
Halving a point is possible, but it does not break ECDSA security. It is a bit different than typical integer division when you can just divide everything by two and quickly come to zero and break everything. It is not the case when using ECDSA and doing calculations over finite field.
To better understand it, you can do some calculations on smaller finite fields, for example using modulo 67. You can start from 1 and multiply it by two. You will get 1,2,4,8,16,32,64 and then suddenly you will get 128-67=61. Here you can see that dividing 61 by two will give you 64.
|
|
|
|
everyone have to divide received value by its chosen part of K This is insecure, because when you know some number and you know number/K, then you can calculate someone else's K. But even if all parties could agree on some K and create such signatures, it is still not enough, because you can still calculate someone else's private key. sA=(z+r*privKeyA)/(kValueA*kValueB) sB=(z+r*privKeyB)/(kValueA*kValueB) sA/sB=(z+r*privKeyA)/(z+r*privKeyB) privKeyA=(sA/sB-z)/r privKeyB=(sB/sA-z)/r Everyone knows sA, sB, z and r, so everyone can calculate anyone private key if you use the same K in both signatures. |
|
|
|
|
If the client can mark someone else's transaction as valid and it is based on checking UTXO set, it should also allow spending my own funds. Why it is not possible without rescanning blocks?
|
|
|
|
|
This system is still unsafe. Assume Bob would be a cheater. He could create fake transaction sending his CPU to himself. Then, he could silently create transaction sending BTC to another address and broadcast it as soon as Alice release her honest transaction. Then, Alice will lose both coins, because her reverse transaction would be treated as "double-spending attempt" by the BTC network.
Even creating another type of transaction is still not sufficient. For example you can safely create a message that lists all inputs and all outputs for both coins. But even if such message would be a valid transaction in both networks (if signed by all parties), it is still vulnerable to "race attack" when honest party releases its coins and dishonest party creates another transaction moving funds to its own address and broadcasts it (making any next transactions as "double spend attempts").
|
|
|
|
Największe przekrenty w tej dziedzinie jeszcze przed nami moim zdaniem. Te pokażą się wraz z powstaniem pierwszego dużego krypto banku, który będzie przechowywał za nas nasze bitcoiny i wyplacał 3% w skali roku na lokacie Smiley Znam stronę, która to robi mniej więcej od 2013. Aktualna stopa zwrotu wynosi tam 4,08% w skali roku. Dlatego myślę, że znajdzie się sporo takich stronek, gdzie ludzie się ogarną szybciej od banków i coś takiego będzie już dostępne zanim jakikolwiek bank choćby o tym zacznie myśleć. Tak czy inaczej: jak się nie ma klucza prywatnego u siebie bądź współdzieli się takowy klucz z kimkolwiek innym (choćby z jakimś bitomatem), to trzeba się liczyć z możliwością utraty wszystkich środków. Problem w tym, że nawet Escrow wymyślone przez samego Satoshiego ma swoje wady, a ewentualne warianty tego pomysłu (dostosowane do wymiany monet na dwóch różnych łańcuchach) mają tych wad jeszcze więcej. Po prostu na razie nikt nie wpadł na to, jak to technicznie rozwiązać tak, aby: 1) każdy miał u siebie swój klucz prywatny 2) nikt nikomu nie musiał ufać 3) każdy mógł się wycofać w każdej chwili (transakcja zaakceptowana w całości albo w ogóle) 4) całość była nierozróżnialna od typowej transakcji Co do altów, to moje zdanie jest takie, że gdyby te alty były takie wspaniałe, to z łatwością wyparłyby BTC z pozycji lidera i wszyscy by się po prostu przerzucili na inną monetę. Ba, można nawet zrobić to tak, że monety na innym łańcuchu zostaną przyznane pod warunkiem zniszczenia monet z innego łańcucha w określony sposób, to akurat jest dość proste. Problem w tym, że nikt nie wymyślił lepszego łańcucha, nikt nie napisał lepszego kodu, więc mamy to, co mamy i musimy z tym żyć, dopóki ktoś nie wymyśli czegoś lepszego. |
|
|
|
|
