Keep the records that are 131 and 66 characters long. 131 chars are for the uncompress pubkey and 66 chars for the compressed pubkey. The uncompressed pubkey prefix is 04 and the compressed pukey is 02 or 03.
The compressed ones are indeed only half the size. But I meant the ones where the length varies by only 2, which is probably caused by truncating the first 148 characters. Could it be the 148 characters isn't always the same? Compare those 2:
I haven't found one. I'm curious which SPV wallets would check for P2PK-balances when you enter a private key, but I can't really test that. I'm currently searching the latest transactions that sent funds to a pubkey, to see how often it's still used. My guess is it's barely used, and considering I haven't missed this feature in years, it makes (some) sense they haven't implemented it.
the only flaws we can consider but won't are end users security practices. ~ We wanted everyone to be able to use our product not just the technically inclined. When my child whom is under 10 years old was able to navigate and utilize the service we knew we where onto something.
For what it's worth: I don't think I've ever had any complaints from users who messed up. But it happened once or twice that someone forgot their part private key after they gave me the public key.
Quote
Ona side note are you referencing user Lauda I was unaware they passed away. Regardless of whom your referring to I send my condolences.
Bitcointalk user Lauda is gone, but the person who used to own the account is not known to be dead. See:
After this post, "Lauda" will cease to exist. By that I mean: The faceless virtual persona named "Lauda", who exists only in cypherspace, will become detached from its "soul", and left as an empty shell. "Lauda" has abruptly reached end-of-life.
I'd need to know which one to keep, and even better: how to decide that from the raw data. The current output is 81 GB (815,497,912 lines), which is too large to sort on this server (only 93 GB disk space remaining). Sorting is needed to remove all duplicates, which is needed to reduce the file size before checking for addresses with a balance.
Does anyone have an idea or suggestion which wallet would be able to setup such a watch-only wallet that properly recognizes the P2PK transaction balances and additionally the later mostly P2PKH spam to the derived addresses?
Bitcoin Core can do this:
Quote from: from Bitcoin Core Console
Code:
importpubkey "pubkey" ( "label" rescan )
Adds a public key (in hex) that can be watched as if it were in your wallet but cannot be used to spend. Requires a new wallet backup. Hint: use importmulti to import more than one public key.
Note: This call can take over an hour to complete if rescan is true, during that time, other rpc calls may report that the imported pubkey exists but related transactions are still missing, leading to temporarily incorrect/bogus balances and unspent outputs until rescan completes. Note: Use "getwalletinfo" to query the scanning progress.
Arguments: 1. pubkey (string, required) The hex-encoded public key 2. label (string, optional, default="") An optional label 3. rescan (boolean, optional, default=true) Rescan the wallet for transactions
Result: null (json null)
Examples:
Import a public key with rescan > bitcoin-cli importpubkey "mypubkey"
Import using a label without rescan > bitcoin-cli importpubkey "mypubkey" "testing" false
Also note that Electrum can indeed successfully sweep coins from P2PK inputs; it just won't let you watch them as you can for an address.
I did not know this (and it is the main part of my problem). From what I was told, Fork wallets can't do this (but I don't want to expose the private key to test it). If Electrum can sweep/import private keys with P2PK-funds, it's not possible to sign offline if it can't import the balance from the pubkey. Considering all of those have a very valuable balance, that's a big shortcoming.
If you don't trust the randomness of your OS, which has been designed, built, and tested by experts in the field of cryptography, and want to do things manually, then just picking up a bunch of random dice and shrugging your shoulders is irresponsible. If you don't test your dice, how can guarantee your min-entropy is sufficient?
The main difference is that I can easily verify a dice is (more or less) random, but it's very difficult to verify any wallet doesn't produce a pre-recorded seed. The wallet is a black box, while the dice has a very obvious "user interface".
I just found out Electrum can't handle "send to pubkey" inputs. If you for instance import 1PTYXwamXXgQoAhDbmUf98rY2Pg1pYXhin (to create a new watch-only wallet), it shows all the spam transactions it received and a total balance of 0.00181009 BTC. The real balance is 3,233.17181009 BTC. I can't really find much information about this, searching on keywords give completely different results. Is this a bug? Does Electrum simply not care about the few (but highly funded!) old addresses out there? Or am I missing something?
Until a week ago, I didn't even know "send to pubkey" exists. I clearly joined Bitcoin late.
I try to send them single merit. I wish I was a merit source to give them more. But this is just an extra burden for me. If the merit sources subscribes the topic for notification and they regularly send merits to the posts then users will find some kind of incentives for them to follow the topic.
My source sMerit keeps piling up, it's at 300 200 now. I took the quick solution and "bumped" all posts that you Merited.
I like the idea of motivating users in this topic But it'll probably be abused at some point.
Anyone knows how many people here are actually doing something similar like Ratimov? I don't know anyone else who is using medium images like this, and I don't think we need to change anything in forum just to make one person more comfortable He said that images showed before in forum, that means Medium made some recent changes with blocking the image proxy.
So you're saying Ratimov caused Medium to block Bitcointalk's image proxy? It could be they didn't mind just a few images being hotlinked, but don't like it on a massive scale.
Yes! I rather not see Medium images than give them access to Bitcointalk user's IP addresses. I like the image proxy and I think it should remain active for all sites without exceptions.
In your example of a dice which rolls a six 20% of the time, then you reduce the min-entropy of each dice roll from 2.585 bits to 2.322 bits. That's 0.263 bits per roll. Might not seem like much, but over 50 rolls, that becomes significant.
My point was that 20% is a huge deviation, much larger than any real flaw in a simple standard dice. So I personally wouldn't worry about someone brute-forcing my 100 dice throws.
Yes, I'm looking for spending_signature_hex. Sorry about the mixup.
I'm currently running this:
Code:
for day in `ls inputs/*gz`; do echo $day; gunzip -c $day | cut -f7,8,18 | grep -v spending_signature_hex | grep pubkeyhash | grep -vP "\t$" >> output2.txt; done
If it doesn't run out of disk space, I'll continue from there tomorrow. It won't fit for sure That's going to be a problem, because I need a few times more disk space to sort the data. 1 TB might not even be enough.
This is a bit smaller:
Code:
for day in `ls /var/www/blockdata.loyce.club/public_html/inputs/*gz`; do echo $day; gunzip -c $day | cut -f7,8,18 | grep -v spending_signature_hex | grep pubkeyhash | grep -vP "\t$" | cut -f1,3 >> output2.txt; done
MrFreeDragon already described what we're looking for here.
Explanation: it truncates spending_signature_hex to only the pubkey (I used a detour, but it works without reducing performance much). This reduces the size, and I can remove duplicates for each day already. That should reduce the output size. I'll let it run overnight. Update: This produces different results: