Latest posts of: TheArchaeologist

Quote from: VERBOSE on November 22, 2021, 09:19:02 PM

hi all, i have a wallet created like a paper wallet, by my birthday date and enough 64 character numbers to get the address and private key
i have a transaction that received bitcoin on july 30, 2015 or 2016 but i don't save the txid.
i selected 1 of 3 addresses with private key and saved that year.

it starts from previous birthday, last month and previous year.

1KVF6G8zFMGhjHuqMWV1QcGiv2fo8kgQ37
1Ax5GUH9no2zRzcWhWEFXbofdPKd11fYKE
17WcVeQzBqKzBEe7V8dse8RsbwCuKAqu4f

I checked again and there is no transaction history.

Can someone help me? I don't know what to do, because it's a great asset.

thank you very much.

Very confusing topic so far with no clear answers. Can you confirm a few things:

Did you use the WIFs you have (starting with K/L or 5) to get the addressed in your post?
When you take about 64 character numbers do you mean consisting of the numbers 0-9 and a-f?

Basically if you have a WIF or the private key (64 chars, 0-9 & a-f) for only the three addresses in your original post then they are worthless since none of these addresses were ever funded.

If however the WIFs/private keys correspond to other addresses you can look those up in any block explorer.

I've written a post on using regtest last year, you could check it out here: https://bitcointalk.org/index.php?topic=5268794.0.

From this guide:
Confirmation needed
So whenever you do one or more transactions in your regtest environment they will be unconfirmed as long as you don't mine at least an extra block. Since there are no active miners on your private regtest chain you have to take care of that yourself. The good news is that means you also don't have to wait for an average of 10 minutes for a block to get mined.

So just like nc50lc mentions the transaction isn't included in any block yet, that's the reason the balance is not updated. You can verify this by checking if the txid is in the mempool of you regtest environment:

Code:

bitcoin-cli -regtest getrawmempool

You should see the txid (0ae84b140e3be5d4933daa4f25e3d1cd5c02b9485ede54ad4c24a91e7d0d28f2) listed.

To get the transaction included in a block you need to mine at least 1 block, you can do this by using generatetoaddress:

Code:

bitcoin-cli -regtest generatetoaddress <numBlocks> <address>

Where <numBlocks> is an integer value of the number of blocks we want to mine and <address> is the address the mining reward should go to.

After mining the balance should be adjusted as you expected.

Quote from: PlutonowyPokrzycz on May 18, 2021, 10:13:42 AM

I wonder what was the oldest brainwallet ever found. Vasek reported this one in her paper: "This string contains 0.25 BTC hiding in plain sight." -> 1AJ3vE2NNYW2Jzv3fLwyjKF1LYbZ65Ez64
It has been used for the first time on 2011-07-14.
The story behind it here: https://bitcointalk.org/index.php?topic=28877.0

1. Was there anything older found by anyone?
2. What has been used before? Purely random generated numbers?

Interesting question, I was curious myself so did some analysis into this. This is the top-5 of known brainwallets and when they first were used on the bitcoin blockchain:

Code:

Date first used  Address                                Passphrase used
2011-07-14       1AJ3vE2NNYW2Jzv3fLwyjKF1LYbZ65Ez64     This string contains 0.25 BTC hiding in plain sight.
2011-09-05       1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm     0000000000000000000000000000000000000000000000000000000000000001
2011-09-14       1ERczz9PRkdcbLmFRgGKKTU5BADthAcHdi     one two three four five six seven
2011-10-14       1Km3PemDrwiwA1gEEgKLgizLgdsqwp4XZz     testing 123
2011-12-03       1JryTePceSiWVpoNBU8SbwiT7J4ghzijzW     Satoshi Nakamoto

So it does seem the "This string contains 0.25 BTC hiding in plain sight." was indeed the very first one.

Disclaimer: based on the brainwallets I have available. Could be older ones I simply am not aware of. If that's the case please let me know!

Quote from: FractalEncrypt on November 15, 2021, 08:58:55 PM

I was able to find my RBF answer here
https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line/blob/master/05_2_Resending_a_Transaction_with_RBF.md

But do I need a sequence for each input? If I have 4 inputs, do I need 4 sequence fields?

This is described in BIP-125 (https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki):

Explicit signaling: A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1).

So one sequence is enough.

Quote from: FractalEncrypt on November 15, 2021, 03:52:01 PM

Hi all,
I have 2 unrelated questions, but both about how to properly formulate a transaction template.

1. I'd like to know how to add an RBF indicator to the transaction (and any relevant details).

Here's my current standard raw transaction template I use;

Code:


 createrawtransaction \
'[{"txid": "txid1", "vout": vout1},
{"txid": "txid2", "vout": vout2},
{"txid": "txid3", "vout": vout3},
{"txid": "txid4", "vout": vout4}]' \
'{"address1": Amount1,
"address2": Amount2,
"address3": Amount3,
"address4": Amount4}'

The software I am using to create, sign, and send transactions is Bitcoin Core QT (console)

In createrawtransaction, there's an optional sequence field that you can set when specifying the inputs. To set a transaction to Opt into RBF, you need to set the sequence for at least one input to be 4294967293 or lower.

Quote from: ETFbitcoin on November 15, 2021, 09:51:27 AM

By "relevant source", i meant what Satoshi said publicly or what Satoshi said to other people in private. Nevertheless, your deduction and mentioned source makes sense and i find it's plausible.

Also the bitcoin wiki about the Genesis block https://en.bitcoin.it/wiki/Genesis_block mentions this:

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
This was probably intended as proof that the block was created on or after January 3, 2009, as well as a comment on the instability caused by fractional-reserve banking.

Quote from: TheArchaeologist on November 15, 2021, 07:18:02 AM

Quote from: BlackHatCoiner on November 14, 2021, 11:58:53 AM

But, Satoshi's public keys are known. Back in 2009, the coinbase transaction was P2PK, not P2PKH. So, they couldn't mine to a burning-looking address. They had to firstly mine them and then send them to such address.

Why the two steps? If Satoshi really would he could just mine to a public key and then raise the value of that by 1. So something like:

Code:

Block 0, payout to:
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001

Block 1, payout to: 
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000002

Block 2, payout to: 
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003
etc..

In that case the blocks would have been clearly marked and they would be unspendable because they are like the P2PK-version of a burner address since there is no way the private key is known matching those public keys.

So if Satoshoi's goal was to clearly mark the blocks he mined he could have used such a solution instead of messing around with the LSB of a nonce. But like I said before, Satoshi really cared about privacy so there is no way he intentionally marked the blocks he mined. I believe it's probably the other way around, his plan was to never spent the coins he mined but he wouldn't clearly mark them as unspendable since this would give away those coins were mined by him in the first place.

Quote from: ETFbitcoin on November 14, 2021, 10:48:16 AM

Quote from: TheArchaeologist on November 13, 2021, 06:53:35 PM

Quote from: mynonce on November 13, 2021, 06:46:53 PM

Another thing is that Satoshi included a hidden message referencing The Times newspaper on the genesis block's coinbase timestamp parameter (The Times 03/Jan/2009 Chancellor on brink of second bailout for banks) and never mentioned it.

That message was put in there to give prove no mining was done before that date. So it was there for a purpose. Since Satoshi was very strict about privacy it wouldn't make sense he intentionally created a way to distinguish blocks mined by himself.

I never hear/don't remember about this, can you show relevant source about it?

You could simply deduct that by reason. If you want to proof something didn't exist before a certain date nowadays you would name something like the hash of a block. You can be pretty sure if you see the correct hash of block 701000 mentioned in a message that message couldn't have been constructed before the block was mined. Satoshi proofed this by quoting the headline of a newspaper. So this genesis block couldn't be mined before the newspaper came out.

A quick google search for "Satoshi pre-mine" turned on some results like https://danhedl.medium.com/bitcoins-distribution-was-fair-e2ef7bbbc892. But then again I don't know the definition you have for relevant source

Quote from: larry_vw_1955 on November 14, 2021, 04:54:30 AM

now bring on the hate.

Why would we bring on the hate because you give your opinion/view on the matter?

Quote from: mynonce on November 13, 2021, 06:46:53 PM

Quote from: irukandji on October 29, 2021, 11:53:59 PM

Also I thought (and I'm probably wrong) that putting some text through the Sha256 algorithm produced a 256 character string of ones and zeroes. If that correct. If so how do we them get the digest?

The 256 refers to the outcome of the SHA-256 algorithm always being 256 bits, so 256 elements of either a value 0 or 1. For readability you could write them down like '010100100010001001011101111..' but that does not mean the algorithm produces a 256 character string as you think.

So once these 256 bits are known you can represent those in many ways. One way is to write them down in hexadecimal where 8 bits are grouped into a byte and this byte is represented by a hex value. For instance:

Code:

Imagine the private key starts with these 8 bits:
11110110

The hex represenation of that would be:
f6

Since a private key consists of 256 bits you will get 32 (256/8) of these "letters (a-f) and numbers". Written down in human dreadable form in 64 characters.

The exact same key is often encoded in Wallet Import Format (WIF) as well, this is what you (probably) saw when generating an address on the bitaddress site. If you copy the WIF and paste it in the "Wallet Details" tab you can check out the full private key as well.

All in all: SHA-256 always produces a 256 bit result, this result can be encoded in many different ways but they all will refer to the same outcome.

Quote from: HedAix on November 11, 2021, 02:03:23 PM

Thanks for the offer. however extracting all the public keys represents the same problem for me. There are too many to manually extract and copy. I need a way of going through the text file and pulling out all the private keys so I can paste them en masse into the sweep field in Electrum. Any thoughts as to how I can do that?

Kind of depends if you can do any programming yourself or not. You could create a simple python script that will read the file line by line and extract the public key for those lines there is one present. Then in the end you could wite all found keys to a single file. I'm not aware of the structure of the file you got so my suggestions are kind of general. Anyway creating such a script shouldn't take much time.

I you have a list of addresses to share for which you want to check the balance, please post them here and I will check them (automated) for you.

Please note: not asking for the entire file, public addresses only.

All I see is free advertisement

Quote from: COBRAS on November 01, 2021, 11:52:17 AM

Is it posible generate with scrypt "virtual" test transaction to real publick key(empty, without money any old publick key for ex) and get valid r,s,z for this transaction and this real publick key ?

Transactions to a public key (so a P2PKH transaction), where this "real" public key is on the receiving end will not make any difference. You need signatures made by the corresponding private key and those will obviously only occur whenever an outgoing transaction is made for the lattice attack to work.

If you want to have some more info on how this kind of attack works read this study called "Biased Nonce Sense: Lattice Attacks against
Weak ECDSA Signatures in Cryptocurrencies". PDF here -> https://eprint.iacr.org/2019/023.pdf

To elaborate a bit on the excellent answer of pooya87 check out how to get from raw transaction to the transaction-id using a transaction from block 100000 as example. The raw transaction is what is stored within a block on the blockchain.

Code:

txid: 
e9a66845e05d5abc0ad04ec80f774a7e585c6e8db975962d069a522137b80c1d

raw transaction:
01000000010b6072b386d4a773235237f64c1126ac3b240c84b917a3909ba1c43ded5f51f4000000008c493046022100bb1ad26df930a51cce110cf44f7a48c3c561fd977500b1ae5d6b6fd13d0b3f4a022100c5b42951acedff14abba2736fd574bdb465f3e6f8da12e2c5303954aca7f78f3014104a7135bfe824c97ecc01ec7d7e336185c81e2aa2c41ab175407c09484ce9694b44953fcb751206564a9c24dd094d42fdbfdd5aad3e063ce6af4cfaaea4ea14fbbffffffff0140420f00000000001976a91439aa3d569e06a1d7926dc4be1193c99bf2eb9ee088ac00000000

Perform a SHA-256 hash on the raw transaction twice ( you can do this online using https://emn178.github.io/online-tools/sha256.html, use input-type hex):

Code:

SHA-256((0100.. 0a00) = 201fa3cb0ad2a6f14d87492a582ccaa6dc6635946b700e2ab45099d2609ae187
SHA-256(201fa3cb0ad2a6f14d87492a582ccaa6dc6635946b700e2ab45099d2609ae187) = 1d0cb83721529a062d9675b98d6e5c587e4a770fc84ed00abc5a5de04568a6e9

So the outcome calculated is 1d0cb83721529a062d9675b98d6e5c587e4a770fc84ed00abc5a5de04568a6e9 which does not match the txid expected. This is because bitcoin uses little-endian notation for the txid in which the least significant byte is on the far left. In other words the bytes calculated for the hash-256 should be encoded as little endian by reversing the byte order.

This means the e9 (least significant byte, at he most right should go the far left: e9....
The next byte is added to this becoming: e9a6
Completing this reversing will give: e9a66845e05d5abc0ad04ec80f774a7e585c6e8db975962d069a522137b80c1d, which is the txid expected.

Check out more info about big-endian and little-endian here: https://www.techtarget.com/searchnetworking/definition/big-endian-and-little-endian. Although that doesn't answer why Bitcoin choose to use little endian in the first place for txid's.

You could just use the bitcoin client back then to mine.

Quote from: NotATether on November 04, 2021, 05:36:18 PM

But what if the Hash160, by chance, happens to match another part of the raw transaction (that is not in the designated vout or vin areas)? It's something that I thought about just now.

In practice that won't happen. But it doesn't even matter. Just like with a bloom filter you could see it as a false positive if it would. If the hash160 isn't found in the raw transaction you can be sure the address you are looking for is not funded in the transaction. If however it is found you move on to the next step, decode the transaction and look for the address, if it doesn't happen to be there the address wasn't funded in there after all. But like I said this won't happen.

And in case you wondering what if the hash160 is mentioned in the vin-part (so it is used for funding): it won't. The vin mentions the txid of an unspent transaction + the index. So if the address you are watching is used for spending the hash160 won't be found in the raw transaction you are evaluating.

Quote from: NotATether on November 04, 2021, 02:03:36 PM

That's actually a great idea. The zeromq message queue that bitcoind-rpc exposes emits Buffer objects as the raw transaction which are just a bunch of bytes. If I can serialize the addresses down to bytes of hash160s as well, I can avoid all those expensive calls to decoderawtransaction and then for transactions which *do* match, call decoderawtransaction on them later to retrieve the value sent to those addresses.

Yes, exactly the strategy I meant. To elobarate:

Say you want to monitor if address 3ChwpX32vBgXAZdheYGiFskMAZqQpKUZiT is getting any transactions:

Code:

3ChwpX32vBgXAZdheYGiFskMAZqQpKUZiT -> hash160= 78d65fb3b8fa013867a396d610a542a7213c1d99
Can be found by doing a b58 decode (won't work for bech32 addresses ofc)

Now let's say you will get the following transaction from zmq:

Code:

txid:e8e2a211e269d8105669367ce336eb4e2145f52816d1c1f528c3eb4795018c84

Raw-tx:
010000000154a8e81dd0fb53f0f82f2d6b90d2972a3dd1718ee4c1e9113a1add12f6c5e334000000006a47304402203f96e1b966ac9a8eaf7c6ee011f280ec9ba0f4a31eff9e678ffcbacd2d9ef3a10220292d03b0694ddf8e4773ceea0a85341574febc0243a76cbdbaaae9cc7c998d390121037873692731f2bd925132c2c05852deb44718dee093d8ce1567bf174e8440f03dffffffff0166aa2d000000000017a91478d65fb3b8fa013867a396d610a542a7213c1d998700000000

Now check to see if the hash 160 (78d65fb3b8fa013867a396d610a542a7213c1d99) is contained in the raw transaction (so without any decoding):

010000000154a8e81dd0fb53f0f82f2d6b90d2972a3dd1718ee4c1e9113a1add12f6c5e33400000 0006a47304402203f96e1b966ac9a8eaf7c6ee011f280ec9ba0f4a31eff9e678ffcbacd2d9ef3a1 0220292d03b0694ddf8e4773ceea0a85341574febc0243a76cbdbaaae9cc7c998d3901210378736 92731f2bd925132c2c05852deb44718dee093d8ce1567bf174e8440f03dffffffff0166aa2d0000 00000017a91478d65fb3b8fa013867a396d610a542a7213c1d998700000000

Yes it does. In that case do whatever extra steps you want including decoding the transaction, etc.

Quote from: NotATether on November 04, 2021, 01:45:51 PM

I've been getting errors about exceeding it on testnet by calling decoderawtransaction on every single incoming transaction my node detects.

If all you are doing is monitoring for incoming transactions for specific addresses you could do without the decoding and just check if the raw transaction contains the ripemd-160 of the address instead.