|
41
|
Bitcoin / Development & Technical Discussion / Re: Watching a bunch of addresses using -zmqpubrawtx=<address>
|
on: November 04, 2021, 12:30:38 PM
|
Meanwhile if someone here knows how to track tx's in a particular block, and also get the current block height...
Getting the blockheight (latest block) from bitcoin-core: bitcoin-cli getblockcount
Tracking transactions in a particular block: bitcoin-cli getblockhash <blockheight>
where <blockheight> is the block of which you want to see the included transactions, use the recveived blockhash for the next command:
bitcoin-cli getblock <blockhash>
Working example: bitcoin-cli getblockcount
returns -> 708171
bitcoin-cli getblockhash 708171
returns -> 00000000000000000008677cb8837ed65aae105d7c69a8c59929d419acd82eae
bitcoin-cli getblock 00000000000000000008677cb8837ed65aae105d7c69a8c59929d419acd82eae
returns:
{
"hash": "00000000000000000008677cb8837ed65aae105d7c69a8c59929d419acd82eae",
"confirmations": 2,
"height": 708171,
"version": 536870916,
"versionHex": "20000004",
"merkleroot": "c97736339fbc33d74f37b567752e44a21fcf16681cd8a20cc9616f3263d362>
"time": 1636028408,
"mediantime": 1636024965,
"nonce": 794427675,
"bits": "170cfecf",
"difficulty": 21659344833264.85,
"chainwork": "000000000000000000000000000000000000000023a58a560224f1764bbd2b1>
"nTx": 1021,
"previousblockhash": "0000000000000000000a5b363eb16cef32f96d426ab0e12d788f440>
"nextblockhash": "0000000000000000000ba2dc289a1c88fcc2038fb6c29e456a20843cb87>
"strippedsize": 766974,
"size": 1697345,
"weight": 3998267,
"tx": [
"903340bf415d3e8b60ee4b05ec86fc74a4e4a4b3e6d4a00c781e9bfe91843aee",
"ee2567364be24addd23ea77edfebc0bb66d8d9b182dadb91cd0a39908d2c6fa4",
"e8beceac0cf99d303975036b89d1c9e3e4f96e596fcac70d2451644eb62639d1",
"6b1bce4995656bd6c547e32f0719eb649838e7d34bdb423f3316b2093c9e9a8b",
"f8bf080de438d1a1b71364ba9203e704b8ef9767964fdf3698bbd82c327a37b0",
"b8a5ccbb753a394cb3f5d6e4fd4cc5f9649a67eee878f389acf23f16becdefbd",
"812291d79c5b347ba801da97f353f58bf1e51a4cc17006ab5e7ebedb571eff5d",
<snip>
"0cadeaa28319ee1074a57ceebc2da373d3a929cc427d82183e7be16e26c4d419",
"e4a2d32e42a5a31df12217ae561da6ea5032fe27c86d7c957610c1963da59df1",
"51327517a743d787b8f5186210f5bf835e61e0dfbd8eca3a47632cddab6362e6"
]
}
Note: Json "tx"-field consists of a list of all the transaction-hashes in the block.
Examples are from cli, ofcourse you can interact with rpc as well to do this. Let me/us know if this was of any help or if you are looking for something different / extra. I can probably help  |
|
|
|
|
44
|
Bitcoin / Development & Technical Discussion / Re: Looking for some help regarding a transaction issue with Bitcoin - CLI
|
on: November 02, 2021, 12:43:17 PM
|
Here's my analysis: So you created a transaction with a single input: spending the output with index 1 from txid b6950e9ab01346be8723b87cb1138a558b1323a609ce1b4bf31c87eae6051b56. Looking up this transaction on testnet shows there are two outputs in this transaction. You are trying to spent the second output (index=1), 0.00070000 BTC linked to address tb1qydzefuvmycm2sx5ngjy6ayjnudu3r2ezu62gnx. This transaction seems to be unspent at the moment so: so far so good Let's look at the outputs of your transaction: 0.00028895 to tb1qkvf2k3yd5mc46gf7znwnpx7vty2pfmt9ezrg6m
0.00041105 to tb1qydzefuvmycm2sx5ngjy6ayjnudu3r2ezu62gnx
-----------+
0.00070000
So the input of your transaction is equal to your outputs (meaning no fee is used). As pointed out by others this is a problem. In order to test your transaction I tried submitting the transaction and it was accepted with txid 48c67f340414a3e8beb74aa20fa282c9f8b47dab5c8f6a2b8331c58302d746fe (the same as in your JSON under txid). Although since it has no fee it might actually never get confirmed. See https://live.blockcypher.com/btc-testnet/tx/48c67f340414a3e8beb74aa20fa282c9f8b47dab5c8f6a2b8331c58302d746fe/My conclusion: You scuccesfully created a transaction (although you should look into the fee). However to send your transaction you need the actual rawtransaction, which is in your json-output labeled "hex". So the last step for you from the cli would be: bitcoin-cli -testnet sendrawtransaction 02000000000101561b05e6ea871cf34b1bce09a623138b558a13b17cb82387be4613b09a0e95b60100000000ffffffff0291a0000000000000160014b312ab448da6f15d213e14dd309bcc591414ed65df70000000000000160014234594f19b2636a81a934489ae9253e37911ab2202473044022012ecb312379eaed3d45b83ca31447be1e59eb3f70bd4a2eab1a45d417400a049022036e790e564897d9c975f81bbeeb5225b54cac81effe619817f88a10a403755ca0121023325d7e56c02f2ddac211972c140b4c004f690ef995cc8fc7be4fdadf320faa000000000
In other words, the output you showed in JSON-format is from createrawtransaction. It justs create a signed transaction ready for broadcast. To actual broadcast the transaction you should use sendrawtransaction. Hope this helps! |
|
|
|
|
45
|
Bitcoin / Development & Technical Discussion / Re: New database for blockchain
|
on: November 02, 2021, 11:58:05 AM
|
You can bring in the raw transactions and just compress that one table: https://mariadb.com/kb/en/innodb-page-compression/I would *think* that it would still be much faster then using a rpc call to get the data. For single person using it, it probably would not matter. If it's exposed for the world to use then you need to have it in a db. -Dave It all depends on the use-case you have. If for instance I would create a webservice and expose it to the world to return the raw transaction based on a txid in the request it would make very much sense to store all the transactions in a DB. But if I would like to be able to analyze/query the blockchain I wouldn't get very far only storing the rawtransactions in a DB. Raw transactions are optimized to contain as much data as needed in a minimum storage space. However good luck creating a query like "when was the last time adress X received over 0.1 BTC" based on raw transaction data only. There is a reason the UTXO's are stored in a DB by core itself. So what I meant (and what I did) I extracted all the info needed from the raw transactions and stored them in a several RDBMS tables. Added some indexes and this a perfect solution for my use-case. So in the end I had no need for the raw transactions themselves anymore. TLDR: Just storing raw transactions in a RDBMS table doesn't mean all the data within is easy accessible. |
|
|
|
|
46
|
Bitcoin / Development & Technical Discussion / Re: New database for blockchain
|
on: October 31, 2021, 08:41:04 AM
|
Ok, I think I will try to pack all RAW transactions directly in a Leveldb database.
Has anyone tried that already?
Hi, I have done this in a RDBMS (MariaDB). Although after a while I got rid of storing the RAW transactions myself, just made a couple of database tables that store the information I need (like block, transaction, address, etc). In the rare occasions I do need a raw transaction I just provide the txid to the rpc api from core (getrawtransaction). Just keep in mind that adding indexes will make it more efficient but it will also add to the storage space required. I got it setup on a 2TB sdd which is now approx. used for 50%. If I would have kept all the RAW transactions in the DB it would mean I would probably run into storage problems by now. |
|
|
|
|
48
|
Bitcoin / Development & Technical Discussion / Re: Generation of priv/pub in given range..
|
on: July 22, 2021, 09:51:30 AM
|
It's not clear what you are looking for. Do you want the private keys of all public keys in that range or just one? If you want only one, it should be easy to do. If you want all, then you will find that it is infeasible just because of the number of keys in that range.
Since OP states he want the results saved in 100GB files he clearly means all pirvate/public keys in range. |
|
|
|
|
50
|
Bitcoin / Development & Technical Discussion / Re: Program for searching addresses bitcoin and ethereum based on files with a list
|
on: June 17, 2021, 06:37:18 AM
|
I'd argue that it's faster to leave the confirmation checks out if the FP rate is very low, because the checks involve performing a network request to bitcoin nodes, each one taking anywhere from a few dozen to a few hundred milliseconds, because nodes' RPCs can only process one address request at a time.
When I did this myself I used my own database to do the lookup. So I didn't use RPC calls to a node or reaching out to an external data source. But I agree, it takes time. That's why I only used this on found addresses to rule out false positives. Balance confirmation checks could be more feasible if software was designed that can input several million addresses in one network request, considering how fast internet speeds are today - but no such software currently exists.
That would mean you supply every found address to this external service and you either get a balance (including 0.00000000) back per address or a response the address isn't found. That could work if such a service would exist but in that case you are just outsourcing the confirmation of found addresses to this external service. It's an interesting idea, wouldn't be too hard to make, might try do to this myself since I already have a database with all real-time balances. In conclusion: I was pointing out that when you use brainflayer you can expect (a lot of) false positives so one way or another you should have a confirmation in place that at least checks if the address is used on the blockchain before and preferable if the answer is yes also checks the current balance. This confirmation can be done in several ways, it all depends on which tooling and data you have available. |
|
|
|
|
57
|
Bitcoin / Development & Technical Discussion / Re: Private key hack new method
|
on: August 17, 2020, 01:18:03 PM
|
But with my base point this is anower address
I thant modyfy base point and private key for get privkey * real base point = true pubkey = true, becouse now I have only my fake privkey * fake base point = true pubkey. This understand ?
No, because what you are trying to do doesn't make any sense. I only used my example to show that it's really simple (because that's the way is is supposed to work) to calculate the public key from a private key. However the other way around is impossible (when the private key was generated truly random. But when I know both I can easily claim that I did it the other way around. But just like on every other thread you asked the same thing over and over again : No it can't be done! End of story. |
|
|
|
|
58
|
Bitcoin / Development & Technical Discussion / Re: Private key hack new method
|
on: August 17, 2020, 12:35:12 PM
|
Ok, I have a super-secret 1337 calculation because I'm a math guru. So you see, someone provided me with this uncompressed public key: 041a87e4688d8b9445b5b038cb3b34c186331f1ab4fc0822dcca44192043eab3b7accf8e941f95ae80b8f373229b7a3f83144160d8982e648f60c8e5cb968ec72e
Now when running my base-point calculator (tm) for 10 minutes it came back with the calculated private key: Private key calculated: 20536951ACC1F347F922E64A62AEC1CE3B73F038A99CB9D56F3D313F2F8CAAC5
Address found: 1BoatSLRHtKNngkdXEeobR76b53LETtpyT
So this is what you are looking for? |
|
|
|
|
Show Posts
