You don't need to know the private key until you want to send the bitcoins. There is no way to know if someone else has a copy of a private key unless they use it or reveal it.


The card could have a chip that will sign a message to prove that it has the private key. It could also destroy the private key after revealing it to prevent anyone from using the card after the private key has been revealed.

What is the issue and how bad is it?

Eventually, the subsidy will be 0. It cannot be avoided. I don't think that delaying the inevitable accomplishes anything.


Slowing down the pace does not help the miners, and increasing the 21 million limit only subsidizes inefficient miners.



Creating artificial incentives to use LN will only hurt Bitcoin and LN as the value derived from those incentives must be taken from someone.

I hope you didn't pay for it. If you did, you have been scammed.

Personally, I have no idea what the excitement is all about.

Is it because someone still has access to a private key from 2009? Is it because that person may have been of the earliest miners?

What makes this person so newsworthy?

In the Bitcoin world, the private keys we see are usually encoded with Base58Check, but in other applications they are typically encoded as base-64 after being encrypted.

I'm not sure what you mean by "technically" as you have stated that the price is determined by supply and demand.

Maybe you are asking about how prices are reported. The reported price is simply the price of the most recent trade on an exchange, or an average of most recent trades across different exchanges or over time. The precise source of a reported price depends on who is reporting it.

If you want C code, this will give you plenty: https://duckduckgo.com/?q=elliptic+curve+library+C

Keep in mind that most people don't write their own because there are already libraries in most languages that have been tested.

@larry_vw_1955

If you strongly believe that you have a better method, then the best thing to do would be to publish a BIP so that everyone can see the merits of your proposal. Those who like your proposal will adopt it, and those who don't will not.

That's one of the beauties of open source development -- you can implement anything you want without the permission or approval of anyone else.

I think I understand completely.

My question is what does "ownership" in this system mean? What is the significance of "ownership" beyond simply controlling the address in the last signed message in the chain? How does it relate to the real world? How does it relate to the common definition of the word "ownership"?

Note that Bitcoin itself is based on the this concept. When you transfer bitcoins you are simply extending a signature chain.

However, the system proposed here has a problem shared with NFTs -- the system transfers only an abstract notion of ownership. It doesn't have the ability to transfer full ownership, by which I mean all of the capabilities, rights, and responsibilities commonly inferred by that term.

Specifically this:

The transfer does not include the private key for the address, so how can it be claimed that ownership of the address has been transferred? Furthermore, even if the private key is also transmitted, then ownership is only shared and not transferred because the previous owner still has the private key.

I think you are overthinking it. Here is a solution:

Every item has a RFID. An app on the customer's phone scans the item and pays for it. The payment is recorded in a database. When the customer walks out, the tag is scanned again and the database is queried  to determine if has been purchased. There is no need for a smart tag. The scanners do all the work. The tag doesn't have to be removed. In fact, you probably want to make it difficult to remove.

However, Amazon is already way ahead of you. They have stores where you just walk in, take what you want, and then leave. The store's cameras identify you and everything you take, and then charge your credit card.

I noticed. I don't know what the significance is, though.

It doesn't prove much except that OneSignature was able to obtain (or create) two signed messages, and that the signer of the first message was aware of the address used to sign the second.

It would not be unreasonable to assume that OneSignature mined block 1018 (as well as many others) unless something important is at stake, but that does not make them Satoshi.

The purpose of a SHA-256 hash is to detect corruption of the data. It is a checksum. If you don't agree, then what is its purpose?


You are contradicting yourself. Your 46-word phrase would detect an error, but it could not fix it because if the duplicates don't match, you don't know which one is wrong. So, it is no better than the BIP-39 checksum.

I acknowledge that there has been a lot of fraud in the crypto space. Educating people about fraud is important. Scammers should be punished, but victims need to learn from their mistakes.

Now, I ask you. What do you hope to achieve by your witch hunt?

First of all. It is not just a missing last word that has 128 possibilities. Every word has 128 possibilities if it is missing, assuming that no others are also wrong or missing.


Bech32 does have better error detection, but that doesn't make BIP-39's error detection bad and SHA-256 is an appropriate choice for a checksum.



Embedding a checksum may not be the best solution, but it is better than nothing. Also, your assumption that the software can correct a seed phrase is wrong. The software does not have enough information and would have to resort to brute force search. And that would only be practical if you know which words are wrong or missing.

I suggest that you compute your hourly rate. You will find that it is much more lucrative to get a low-paying job.

Raspberry Pi 4 is not x86. It is ARM, so you want to download bitcoin-24.0-aarch64-linux-gnu.tar.gz assuming that your version of Ubuntu is 64-bit (otherwise bitcoin-24.0-arm-linux-gnueabihf.tar.gz).

I recommend that you follow this guide: https://raspibolt.org/

Note that the guide assumes that you are using RPi OS Lite 64-bit which is derived from Debian 11. There might be slight differences in the commands.

Bitcoin private keys have exactly 256 bits. A private key with fewer would require that the remaining bits be set to something.

That is true. Brute force attempts that check a range generally prioritize ranges that are likely to have more use. Due to bugs or laziness, the low end of the 256-bit range probably deserves a higher priority. If the attempt assumes that any key is equally likely, then there is no benefit to start at the beginning of the 256-bit range, but on the other hand, starting at 1 is as good as any number, so why not.

Thus, most brute force attempts checking a range start at 1, making the low end of the 256-bit range more vulnerable simply because it is the range checked most often.

On the other hand, since there are so many people already checking the low end, an attacker might want to choose a different range that does not have as much attention in order to avoid the competition.

In the end, a randomly generated private key is extremely unlikely to be in a range that any attacker is searching, so there is no practical reason to be concerned.