what exactly do you need to search a pubkey for? what's the point?
let's say you have found a pubkey with funds, so?
I'm gonna answer this as I read your question, as in: what good would it do to know the public key anyway? In order to use the "Baby Step - Giant Step" Algorithm ( https://en.wikipedia.org/wiki/Baby-step_giant-step) you need to have the public key. So that's why  |
|
|
|
Yes, but only a fraction of all adresses have published their pubK... I think it would be best to create an AI for this task.
What exactly would the AI do in your idea? I don't know what you mean by "published" their pubK but you should know that: - Almost all coinbase transactions (newly generated coins) in the first two years were paid out to public key (P2PK-addresses). In other words: all these public keys are known as they are "published" in the blockchain.
- For all the P2PKH-addresses the public key is not known, only the hash, unless the address has been used even a single time in an outgoing transaction. In that case the public key is known and once again "published" in the blockchain.
So instead of claiming only a fraction of addresses have published their public keys I would say most of them are known. But once again: if you think you can use the "published" public key in order to find the corresponding private key I have bad news for you. That is not going to happen.. |
|
|
|
Rather than searching for addresses you should search for pubkey with funds (there are a lot) with a kangaroo or rho program. It will be much faster, ~2.4e19 years with rho or kangaroo against ~9e28 years with address finder (on 256xTelsa V100)  Do not use my kangaroo program which is limited to 125 bit range key search ! Edit: For instance this pubkey: 02545d2c25b98ec8827f2d9bee22b7a9fb98091b2008bc45b3b806d44624dc038c (1HQ3Go3ggs8pFnXuHVHRytPCq5fGG8Hbhx) hold 69370BTC I know you know Jean Luc but for the "get rich fast" newbies out there: just because the public key is known doesn't mean you will be able to find the private key by bruteforcing. The only time this has been done is with specific puzzle-transactions in which along with the public key the search space is predefined. |
|
|
|
the point is that u can give vs a list of addresses with balance in them and if it finds a private key then it is one to an address with btc in it.
If you give a full address as target and let VanitySearch run for the next billion years you might be able to find a match. Too bad you won't be a life to see the result  But seriously: If you are trying this kind of tooling to get rich fast you are wasting your time! |
|
|
|
Well, since the address is never funded it is *not* in the blockchain! edit: thanks to SiNeReiNZzz it is funded now.. |
|
|
|
Reading this one, but would be nice if someone explains the backend process.
Ok, I will do so in short: An address (at least in this context) is just a different representation of a public key. In order to generate an address you need a private key, which is used to generate a public key, which in turn is presented as a bitcoin address using base58 encoding: Private Key -> Public Key -> Address Keep in mind that getting from Private Key to Public Key is a one direction operation. So you can generate a Public Key from a Private Key but not the other way around. The only way to find an address is starting with specific characters is by bruteforcing, trying candidates until you find one that matches. Simplified: Target: I want an address starting with 1beer...
Random Value used as Private Key -> Public Key -> Address = 1ztyx...
Random Value +1 used as Private Key -> Public Key -> Address = 15b7..
....
Random Value + 123102931 used as Private Key -> Public Key -> Address = 1beer...
The found address starts with the target so we are done.
Each extra character gets exponentially harder to find, so the longer your target, the longer it will take to find if at all possible. |
|
|
|
Although they should be based on compressed keys only, there where cases like these: I have a Nano S wallet initialized by restoring my BIP39 mnemonic, segwit path, no passwords.
This BIP39 should be, in principle, a BIP32 hierarchical deterministic wallet, and produce as such only compressed public keys.
However, in my case they are uncompressed. When I call the getFirmwareVersion() method, it responds that 'compressedKeys': False and when I call getWalletPublicKey() I obtain, indeed, public keys in uncompressed form (\x04+x_coord+y_coord) Source: https://www.reddit.com/r/ledgerwallet/comments/7znmwr/nanos_keys_are_uncompressed/So it does seem there are historical cases out there with uncompressed keys based on BIP32/39. |
|
|
|
Been diving into redeemScript and their corresponding P2SH addresses. Have a question I can't find a definite answer for, trying here:
Is it possible to create what I would call a catastrophic redeem script, hash it and output its "3-address", which will - even though you have the full script and hence the private key - always fail, i.e. always return "false", so that any coins sent to it are forever unspendable?
Since P2SH addresses contain only the hash of the script, it is impossible for anyone to call it "bad" until the underlying full script is revealed, i.e. when someone tries to spend from it.
If I understand things right, redeemScript are actually executed during spending, not only "this hash matches this input, we're good", and I would guess that it was fairly easy to create a script that no matter what always returns "false"?
Am I right? Can I create a "P2SH public address blackhole", send coins to it, reveal its full script (private key), and still no one would ever be able to spend the coins?
If this is a well-known thing, what is it normally called? Thanks.
Sure that is possible. With a P2SH address, the hash of the redeem script is being used as input for generating the address. In other words, the redeem script will be evaluated when you try to use it as an input for a transaction. So if the script itself is faulty or for instance would always push a 0 to the stack it is indeed unspendable. So: the 3-address itself is not based on the private/public key (like in P2PKH) but instead on the redeem script. So having the private key doesn't change the fact you can't spend it. |
|
|
|
To be honest, i don't really see why this address would be special...
It would take a very short time to generate several of these addresses, then make sure there's only one UTXO left funding said address with a predefined amount of sat's.
In this case t's not about the difficulty (at least not for me) but I do think it has some kind of a story to it. It might be more interesting to find the vanity addresses that actually belonged to certain people, or that were used in certain events?
If you know of any, please share them. That's one of the reasons I started this thread: addresses with some kind of story attached to them, hell they don't have to be vanity addresses at all as long as they come with a good story attached to them! |
|
|
|
Hey all, I know there are a lot of Vanity addresses out there and other kind of addresses with some kind of story attached to them. I'm looking for addresses with some kind of story.. I'll kick off with this one: 1SaToShiTN5fyhh19bkxhx4SMBwcDgaWg
Which has 1 Satoshi left in balance!
|
|
|
|
Check a couple of things: Did you fill the following settings in your config file of bitcoin core (bitcoin.conf, on linux in .bitcoin-folder): server=1
rpcpassword=<password>
rpcuser=<user> You should fill in the <password> and <user> values with your own. If you want to be able to also get transaction info on addresses not in your wallet you also want to add txindex to your bitcoin.conf file: Fire up bitcoind: Check to see if you can use rpc calls from the commandline: curl --user <user>:<password> --data-binary '{"jsonrpc":"1.0","id":"curltext","method":"getblockcount","params":[]}' -H 'content-type:text/plain;' http://127.0.0.1:8332
Where you use the same <user> and <password> as included in your bitcoin.conf file If all works fine, you can setup things for Python, First install the bitcoin-rpc package (I assume you use python3): sudo pip3 install bitcoinrpc
And finally connect from python: from bitcoinrpc.authproxy import AuthServiceProxy, JSONRPCException
rpc_connection = AuthServiceProxy("http://%s:%s@127.0.0.1:8332"%("<user>", "<password>"),timeout = 120)
print('You are synced up to block %s) , % rpc_connection.getblockcount())
And once again, replace the <user> and <password> with your own settings. |
|
|
|
Most of the things I could come up with have already been mentioned in the prior responses. The idea you have has two sides as far as I can see: - Discourage the re-use of an address, so for example: you would not use the same address you sent from as change address in the same transaction. This means I have to plan ahead, knowing I should use a different address for change otherwise I could not give up my private key.
- Plausible deniability: Publishing your private key would mean not only you but the entire world would now know you private key. Setting the timestamping aspect apart, this would mean you can never claim you didn't know the private key at all. In other words: it's not possible to prove you didn't do a transaction.
Also: there are alrady a lot of bots active sweeping addresses for which the private key has somehow leaked. This list would become a free database for those people to add to their bot. It's almost guaranteed some of the addresses will be funded again, intentional or not, and they will be emptied within seconds. All in all: My opinion is there are way too many downsides to this. |
|
|
|
You could then make a transaction to Bob using 30 inputs to pay him exactly the amount you want without any need of a change address. Probably worth mentioning for OP's sake that this is an exceptionally inefficient way to use bitcoin, and you will end up paying huge amounts in fees and potentially waiting a long time for your transaction to confirm. Much better to just spend a single input and accept the change. Agreed, i was just pointing out to OP the fact that outputs have to be spent in whole as opposed to the (non existing) balance as was suggested. |
|
|
|
The point is that they are allowed to move partial bitcoin.Take this transaction as an example, https://bitinfocharts.com/bitcoin/block/75030/15Z5YJaaNSxeynvr6uW6jQZLwq3n1Hu6RX You can see 15Z5YJaaNSxeynvr6uW6jQZLwq3n1Hu6RX moved out 301 bitcoins, but it still had 7,944.06 bitcoins left. This seems not abiding by the UTXO rule. I found UTXO did not work in many transactions in 2010. Can someone explain this to me? Thank you guys! You are mixing two entirely different concepts. What you are assuming/describing here is there is a balance on an address which can only be spent in one go. But as others stated before me: bitcoin doesn't transfer from one address to another address like you would do with bank acounts. Instead bitcoin works with transactions which have one or more inputs and one or more outputs. Now here comes the "partial part": if you received 10 BTC from Alice there will be an "unspent transaction output" or UTXO which you can use as input for another transaction. So if you want to pay Bob 3 BTC you can use the unspent output in which you received the 10 BTC for that. However you cannot say: "See this output gave me 10 BTC, use 3 of them to pay Bob so I will still keep 7 BTC in my address". What happens within bitcoin: you are making at transaction to pay Bob 3 BTC by using the entire unspent output from Alice. In this case it would mean you would have to make another output for the remaining 7 BTC, known as the change address. So in short: - Don't think of bitcoin addresses like accounts with a balance.
- Instead it's better to compare a bitcoin transaction with a cash transaction: If I received a $10 bill from Alice and then needed to pay Bob $3 I cannot tear up the $10 bill, instead I give Bob the entire $10 and expect to get $7 in change.
- However if I got paid a lot of small amounts through time a total of 100 10-cent coint payments would also rack up to $10. If Bob then needed $3 I could pay him by giving him 30 of the 10-cent coins I accumulated. Or in bitcoin transactions: The "balance" of the address (the sum of all UTXO) would be the equivalent of $10 funded by 100 small inputs through time. You could then make a transaction to Bob using 30 inputs to pay him exactly the amount you want without any need of a change address.
|
|
|
|
@nc50lc, @achow101: Thank you. In the end I didn't miss anything I guess I just misinterpreted what's been said . But I rather ask then keep wondering what I'm missing! To sum up: If you are trying to spent a previous funded P2PK output don't threat that input for your new transaction as if it were a P2PKH output because the signing would be faulty. |
|
|
|
Well...
You can spend the extra "donations", because they are in a P2PKH address, that you DO have a private key to. The private key is the same for both P2PK and P2PKH "addresses" made from the same key.
Exactly my point, so why is it that nc50lc is saying (as I have seen some others claim as well): You shouldn't derive the address based from that Public Key because the owner wont be able to spend it using the "P2PKH" script even if he has the private key.
Just wondering if I'm missing something here.. |
|
|
|
What he meant is P2PK scripts are Pay-to-Public-Key ( read it literally to understand ). You shouldn't derive the address based from that Public Key because the owner wont be able to spend it using the "P2PKH" script even if he has the private key. I really need a self proclaimed genius to elaborate on this. So I guess I'm lucky you are here Say I'm Satoshi (hell anyone claims that nowadays) and I have guarded my private keys very well. When I started back in '09 every coinbase was paid out to a public key (P2PK). So the genesis block was paid out to this public key: 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f
Some/most of the blockexplorers convert this to an address. Hell even bitcoin-cli decoderawtransaction used to do this a few releases back. Using python I've done this before myself: def big_public_key_to_address(public_key):
#Step 1: Create hash of public key:
hash_of_public_key = hashlib.sha256(bin).digest()
#Step 2: Calculate RIPEMD-160 of the public key:
r = hashlib.new('ripemd160')
r.update(hash_of_public_key)
r.hexdigest()
#Step 3: Adding network bytes (00) to RIPEMD-160
networked = binascii.unhexlify('00'+r.hexdigest())
#Step 4: Double hash the networked RIPEMD-160
sha4a = hashlib.sha256(networked).digest()
sha4b = hashlib.sha256(sha4a).digest()
#Step 5: Get the first four bytes of sha4b:
four_bytes = str(binascii.hexlify(sha4b).decode('utf-8'))[:8]
#Step 6: Adding the four_bytes to the end the RIPEMD-160 from step 3:
address_hex = str(binascii.hexlify(networked).decode('utf-8')) + four_bytes
#Step 7: Convert the hex_address using base58 to bitcoin adres
address_base58 = base58.b58encode(binascii.unhexlify(address_hex))
Which would produce the famous address: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
But more importantly step 6 produces:
00 62e907b15cbf27d5425399ebf6f0fb50ebb88f18 c29b7d93
Fast forward, 11 years later. Some of my fans are doing tribute payments. Small amounts keep coming. Through the years i accumulated over 18 bitcoins. However lots of them were made by doing a P2PKH-payment to the 1A1...DifNa address. For example: transaction hash:
ce03b5624df568367e63da5cb5eba08c4eccb4bcd13588484d11e1014d07c721
Output:
<snip>
Index:0
Address: 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
Value:0.00001000 BTC
Pkscript
OP_DUP
OP_HASH160
62e907b15cbf27d5425399ebf6f0fb50ebb88f18
OP_EQUALVERIFY
OP_CHECKSIG
So why can't I spent the above output when I have all the ingredients needed for prove? Genuine question, I'm sure I miss something. Also: if I can't spent these kind of outputs it would mean all these tribute transactions are unspendable (assuming thet have been paid using P2PKH transactions, not P2PK). |
|
|
|
Data != Files
Data ~= Files A file is nothing but some data with an associated key. What I'm talking about is storing data, with a key so it is easily retrieved. Files are traditionally identified by an extension such as ".jpeg" but this is quite wasteful so I propose replacing it with a number (maybe 3 or 4 byte or a VarInt). So you have: 1. Raw data 2. Key (filename) 3. Data type (1=jpg, 2=png, ...) FYI, Bitcoin SV is already doing something like this, and they already have a system devised for splitting up large files into several OP_RETURN transactions, but I'm not sure if they have a keying mechanism. That is the icing on the cake. - but the idea could be taken further with features such as splitting up large files, versioning, and whatever else. So, to re-phrase, my idea is to come up with a *standard* store data on the blockchain (not a new idea, already being done my MS and others), together with a key (possibly a new idea, but I won't be so arrogant as to think somebody else has not already thought of it). And this would be a standard - it would not be limited to BTC core, it would be a standard that could be implemented on any blockchain. that is all. Do you have any idea what it would cost to store even a simple .jpg picture on the bitcoin blockchain? Also, what if that picture would show unwanted/illegal stuff? It would mean all full nodes in the entire world would now store this unwanted/illegal stuff. Just my two cents: You are having an idea for a standard for something that is not wanted in any way on the bitcoin blockchain. The moment it would become a standard I would for sure turn off my node. I can't imagine any other public blockchain would ever try to accomplish this. You want to store/exhcange files use usenet/torrent or whatever. |
|
|
|
I mean, technically the distinction between a file and data (and anything digital really) is rather arbitrary ¯\_(ツ)_/¯
Agreed! However I was mainly responding to OP who said: "My idea is nothing but to come up with a standard for storing files on the blockchain, so Alice can put a file on the blockchain with a certain filename, can give that filename to Bob and Bob can read the file without too much pain." and then saying: "See, even Microsoft does this now". In that context: storing a small amount of data using the standard OP_RETURN is not the same as Microsoft now storing files in the bitcoin blockchain. |
|
|
|
|
Show Posts
:
