Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 333. (Read 228451 times)

1 doesn't "encode to a private key", 1 IS a private key.

An ECDSA private key is simply a number.  For bitcoin, it is ANY number between 1 and 115792089237316195423570985008687907852837564279074904382605163141518161494336
(when represented in base 10)

That number can be represented in any of various forms such as binary, hexadecimal, octal, decimal, base58, or Wallet Import Format (also known as base58check or WIF).

Perhaps you are asking how to represent the decimal value of 1 in WIF?

What I don't understand exactly is how 1 encodes to a private key.

The Bitcoin address 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH "belongs" to whoever knows the private key.

The private key is 1

So everyone that knows that the private key is 1, including you, now "owns" that address.

BTW the Bitcoin address 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm also has a private key equal to 1 so now, since you know the private key, you also "own" that address.

According to this, that address belongs to Luke Jr.: https://github.com/bitcoinjs/bip21/blob/master/test/fixtures.json

EDIT: changed title


So what I've done in the above is created a transaction that embeds a different transaction within it using OP_DROP. The inner transaction is as follows:


The inner transaction is fully signed and valid, sending 0.1BTC to 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH(1) and spending a hefty 0.4BTC in fees. However since nLockTime is set to be a bit over 2000 blocks in the future it'll be some time before anyone can spend it. On the other hand since the first transaction is public, and will be embedded into the blockchain once someone mines it, provided the second transaction is mined after the first the existence of both transactions proves I threw away 0.4BTC in fees to the miners as once the transaction is made public the sender has no control what-so-ever over who mines it. Basically this is a more sophisticated mechanism to achieve the "trusted identities through value destruction" I proposed earlier (https://bitcointalksearch.org/topic/m.1007449), with the advantages that this implementation requires just two transactions and as long as nLockTime is set reasonably far into the future the value destruction will always be valid.

The maximum value you can destroy in this manner, assuming the mechanism is known and there are miners watching the blockchain for these special transactions, is then a function of the number of blocks between the two special transactions. Basically a miner could work on getting mining successive blocks, then publishing the whole chain, however that becomes exponentially more difficult and expensive in terms of opportunity cost. 10 or 100 blocks should be plenty. Of course the expected value lost is proportional to the mining power you control, but mining power is pretty well distributed.

An actual implementation can do better than just a simple OP_DROP. For one thing the message should go in the scriptSig to aid pruning. Secondly the inner transaction doesn't need to be provided in full; much of it can be snipped out if a template it used. Even the whole scriptPubKey can be left out if the output always goes to a known address. The minimum required length is just the ~80 byte signature and the 32byte tx id for the input, and at that point you can probably stuff the whole thing into one of the "isStandard OP_DROP" type proposals or similar. Either way, what's important is to agree on a standard so the value destruction is valid.

EDIT: Just to make things clear, double-spending the inner tx isn't a problem. Remember that the whole point of this is to prove after the fact that you threw away bitcoins. If you double-spend the inner tx, you have no proof.

EDIT2: Miners don't have a disincentive to mine the outer. After all, the inner can be published separately and put into the mempool whether or not the outer tx exists. The decision to mine the outer is orthogonal and subject to the same logic as any other transaction.

1) ...which is really throwing away another 0.1BTC...

I haven't done any Bitcoin programming in a while. Is Sipa's secp256k1 libary still the fastest code available for computing the public key from a private key?

- snip -
Not sure what performance Danny gets out of their CPU.

@Danny does the tool you wrote/modified support using a GPU by any chance?

You do not even need to use addresses.
You can get public keys from these 50 privkeys from the blockchain

Instead of computing the full address, I should convert each target address to its binary RIPEMD160 hash value

-snip-


Not sure what performance Danny gets out of their CPU. Speed-up for a GPU is more in terms of 20-60 times vs. a CPU

Shorena, I think you have a gtx 970?

If so, that would be a faster way of making the program which cracks the keys quicker however, this depends on whether the program supports the cracking via a gpu...

How much of a faster process would it be? 200%?

"7" and "8" are close together as well. Even if the numbers are created randomly is not that unreasonable to assume that a few numbers in the series are close together.

@Danny does the tool you wrote/modified support using a GPU by any chance? I would suspect thats the only way to get to 50+ bit within a reasonable amount of time. If we assume similar performance to vanitygen, we can expect 30-40 million keys per modern GPU.