Bitcoin private key BASE58 problem

[mynonce]

...
The only way I would be ok with coins being locked or frozen would be if there was some method for the true owner to prove their ownership and reclaim them.

Exactly. Therefore, if someone else then Satoshi is able to move Satoshi's early mined coins, so Satoshi has to react.

When objects of value are found in a ship wreck at the bottom of the sea, should those that managed to find the wreck be allowed to profit from that find?  Or should a government agency take evderything salvaged and destroy it?

[1714955177]

1714955177

[1714955177]

1714955177

[1714955177]

1714955177

[1714955177]

1714955177

[1714955177]

1714955177

[pooya87]

It's not a case of hoping no one exploits the vulnerability. ECC will almost certainly be broken at some point in the future, and any coins protected by it will definitely eventually be stolen. We will absolutely move to a new algorithm, but it should not be the decision of the majority to lock coins which we do not own with no say from the true owner. I would much rather those coins are stolen than we set a precedent that the community can decide to lock your coins and there is nothing you can do about it.

Vulnerability in protocol is a very different thing than "locking other people's coins". Lets take OP codes that were disabled/removed from protocol. They had vulnerabilities and if anyone had any coins locked by an OP code like OP_CAT their coins would have been locked because such output can not be spent.
Or for example if you had any coins that were locked with a script like the following (pubkey script) they are unspendable now that BIP-147 is active because "majority decided".

Code:

OP_1 OP_0 OP_0 OP_CheckMultiSigVerify OP_DUP OPHASH160 <hash> OP_EqualVerify OP_CheckSig

You see in bitcoin the majority has been making this kind of decisions for a very long time and it won't be any different for ECC in the far away future either.

[o_e_l_e_o]

Exactly. Therefore, if someone else then Satoshi is able to move Satoshi's early mined coins, so Satoshi has to react.

If anyone is going to prevent someone from stealing Satoshi's vulnerable P2PK coins, then it should be Satoshi and only Satoshi. We should not get to decide to deprive Satoshi of all their coins.

You see in bitcoin the majority has been making this kind of decisions for a very long time and it won't be any different for ECC in the far away future either.

Correct me if I'm wrong, but I'm not aware of any coins being made unspendable by the removal of OP_CAT or by BIP 147. This is in stark contrast to the millions of coins owned by potentially hundreds of thousands of people which would be made unspendable by depreciating ECC.

[pooya87]

Correct me if I'm wrong, but I'm not aware of any coins being made unspendable by the removal of OP_CAT or by BIP 147. This is in stark contrast to the millions of coins owned by potentially hundreds of thousands of people which would be made unspendable by depreciating ECC.

I don't think they have either but theoretically speaking they could have. I agree that it is a bad example but there hasn't been any drastic changes to the protocol for any drastic example.

[o_e_l_e_o]

I don't think they have either but theoretically speaking they could have. I agree that it is a bad example but there hasn't been any drastic changes to the protocol for any drastic example.

It does lead to an interesting thought experiment, though, with implication for the future. Let's say someone shows up today with a significantly valuable amount of bitcoin - say a few hundred - which is now unspendable because of some historical change that was made to the protocol. What does the community do, and what are the consequences of that decision?

The right thing to do would not be to deprive that user of their money, but that would require changing the protocol in some way (maybe even forking) to allow those coins to be spendable, which would be a significant undertaking for the sake of one user. Or do we simply shrug our shoulders and say "Well, sucks to be you"? What are the consequences of us essentially preventing a user from accessing money which is rightfully theirs? That makes us far too similar to a centralized bank or exchange for my liking.

[alexeyneu]

An uncompressed bitcoin public key is 65 bytes long, made up of "04", followed by the 32 byte x coordinate and then the 32 byte y coordinate.
A compressed public key is 33 bytes long, made up of either "02" or "03" depending on if the y coordinate is positive or negative, and then the 32 byte x coordinate.

An address is not simply a public key in Base58Check. To convert a public key to an address, you must first SHA-256 hash it, then RIPEMD-160 hash it, then add a 0x00 network byte to the start, SHA-256 hash it twice, take the first four bytes of this hash as a checksum and append it to the end, and then convert the whole thing to Base58Check. If you want to work backwards from an address, you can only strip the checksum and network byte to arrive at the RIPEMD-160 hash output. You can't go back any further to find the public key.

there're two \0 bytes to be added . second one added to start right before base58 op.

Code:

	char *t = new char[1000]();
	char *tbitaddr = new char[1000]();
	size_t c = 1000;
	size_t cbit = 1000;
	unsigned char bitaddr[25] = {};
	unsigned char pubhash_md[20] = {};
	unsigned char pubhash_mdprefx[21] = {};

	unsigned char pubhash[32] = {};
	unsigned char hashtag[32] = {};
	unsigned char hashtag_f[32] = {};

	const unsigned char b[66] = "BurnItAll0000000000000000000000000000000000000000000000000000000b";
	SHA256(b, 65, pubhash);
	RIPEMD160(pubhash,32,pubhash_md);
	pubhash_mdprefx[0] = 0x0;
	memcpy(pubhash_mdprefx + 1, pubhash_md , 20);
	SHA256(pubhash_mdprefx, 21, hashtag);
	SHA256(hashtag, 32, hashtag_f);
	bitaddr[0]  = 0x0;
	memcpy(bitaddr + 1, pubhash_md, 20);
	memcpy(bitaddr + 21, hashtag_f, 4);
	b58enc(tbitaddr,&cbit,(void *)bitaddr,(size_t)(sizeof(bitaddr)));
	b58enc(t,&c,(void *)b,(size_t)(sizeof(b)-1));
	std::cout << "pubkey :" << std::endl << t << std::endl << "address:" << std::endl << tbitaddr << std::endl;

[o_e_l_e_o]

there're two \0 bytes to be added . second one added to start right before base58 op.

There aren't. The reason that code adds 0x00 twice is because the second time it calls back to the RIPEMD-160 output, instead of calling back to the RIPEMD-160 output with the 0x00 already prepended.

Take the public key, SHA256 it, RIPEMD-160 it, then add 0x00 to the start. Call this pubhash_prefix. SHA256 this twice, take the first 4 bytes, and then append these 4 bytes to pubhash_prefix. Convert to base58 and you have your address.

[alexeyneu]

really it's same one, yeah.

[TheArchaeologist]

Take the public key, SHA256 it, RIPEMD-160 it, then add 0x00 to the start. Call this pubhash_prefix. SHA256 this twice, take the first 4 bytes, and then append these 4 bytes to pubhash_prefix. Convert to base58 and you have your address.

The same thing as described by o_e_l_e_o, this time in python code:

Code:

bin = binascii.unhexlify(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))