Topic: It is possible to make a ZERO spend with Bitcoin? (Read 1750 times)

Can you point to one on the blockchain?

Ive seen tons of transactions that were for 0BTC and they were specifically Casinos advertising to addresses once used for gambling!

Yeah you can send zero to an address.  It would be treated as a non-standard (would it be invalid??) tx and likely not be mined, but I bet if you included a large miner fee somebody might do it.  Any valid tx can be put in a block, it's just that most miners don't put in non-standard tx's.  But if you can get somebody to mine it, and it's a valid tx, and they mine it into a block, by god it's in the blockchain.  Eligius is the only pool currently mining non-standard transactions.  So connect to them and include a large miner fee, and your tx if it's valid, it will probably get mined within a few days.  Leave your client running and re-broadcast it occasionally.

Usually, people send 0 not to an address, but to a *provably unspendable output*, like this tx here where the guy send 0 to the "address" and the rest of the input (all of it) went to miner fees.  The output (recipient) was an OP_RETURN output, which means it is not allowed to be referenced as a future input, so any money sent to it is provably lost forever.  So if he had sent money to it instead of zero, that money would have been lost.

Edit:  As for answering your original question.  All bitcoin addresses include a checksum, which means that if anything in the address is altered, it will be immediately identified as mis-typed and it won't be a valid address.  The actual raw tx however is just the ripemd160 hash without the checksum, but all ripemd160 hashes correspond to a bitcoin address, it's just that you can create a public address which you don't know, and nobody knows, the private key for.  As for testing a private key, no you don't need to send money to test it.  Any 32 byte hex string from 0000000000000000000000000000000000000000000000000000000000000001 to fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140 is a private key.  The Wallet Import Format versions that start with 5 or K or L are base58 encoded versions of that hex, and they, like addresses, include a checksum, so they know if you mis-typed something.

Your bitcoin client will know if you try to import an incorrect key.  For example, here's a randomly created private key:

5JACuvzpeMyASNGLrcBux1gBkSEJqUWc6xxg5MvnBUrmqPkuPMQ

I'm going to change the last letter from a capital Q to lower case, and get

5JACuvzpeMyASNGLrcBux1gBkSEJqUWc6xxg5MvnBUrmqPkuPMq

If I try to import that, I'm going to get an error, because it's not a valid WIF private key.  The checksum doesn't match.  It doesn't correspond to *any possible* private key, so it's not valid.

A "checksum" is a hash of a message.  So for example, I want to send you "hello" and make sure you get it without any mistakes.  So I send you "hello2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824" and your client just already knows that the last 64 characters of any message I send you are the checksum hash.  So it goes and hashes "hello" and verifies that it comes out with 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824, and it then checks the message you sent and verifies that everything lines up.  If you change any letter anywhere in the message "hello2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824" it will not compute as valid.  (Or rather, it's extremely unlikely it will.  And also, you could just send an entirely different message which is still valid, like "goodbye82e35a63ceba37e9646434c5dd412ea577147f1e4a41ccde1614253187e3dbf9".  That's why in bitcoin, transactions include both checksums on the addresses, as well as digital signatures from the private keys, which are basically special checksum hashes that can only be generated by the private key.  That way, the client knows both that the message isn't tampered with and also that the private key has approved the transaction.)

No, just the theory that some "bug in software generating private keys" made those funds unavailable. It's possible he transferred the funds to wallets he doesn't control, but then you can't call those keys "lost". If he did transfer funds (and I don't believe it), there have to be be some other reason why would he do such a thing. There are much more logical explanations what happened, like (in other from the least probable to most probable):
- hackers have been using transaction malleability to steel 1000 bTC a day through 2.5 years, and went unnoticed;
- Mark Karpeles transferred the funds to some other entity for any possible reason;
- hackers or the corrupted employe broke into their "cold" wallet and grabbed the coins;
- the alleged leaked document which states 750.000 BTC are missing is wrong, and those coins are still in control by Mark Karpeles & his associates.

Pick an explanation you believe most, but don't believe they had trivial error in code which genereted invalid keys. However incompetent they are, that task is too easy and that scenario is unbelievable.

To the OP you can not perform a spend of zero.  Bitcoin doesn't work on the concept of balances it works on the concepts of inputs and outputs.  When you make a transaction it has one or more inputs which are references to the outputs of prior transactions.   You can't spend part of an output you either spend it or you don't.

You could however spend right back to the same address however as others pointed out that would make the public key known and in theory if ECDSA was weakened or degraded could allow the private key to be compromised in the future.

The better option would be to sign a message with the private key and use a third party implementation (like say QT client) to verify that signature.  If the signature is valid then the relationship between your private key and public address are valid.

Is it confirmed?  Tx below 5430 satoshis are not invalid that is incorrect.  They are however non-standard and as such miners will not include them in blocks by default and nodes will not relay them by default.

No, I believe its equivalent to saying hey, I am going to give you 0$. Let me know if you received it.

I would send 1btc to see if everything is fine, isn't enough?

I am in the process of creating a paper wallet so I am interested by all problems associated with paper wallets, I am reluctant to use bitaddress so I think I will try to use Bitcoin-qt to create my paper wallet and I will store it in a safe in Singapore

Care to explain why I did recieve an amount of BTC 0.00000001 ?

That's always possible.    For example:  they might have only had one physical copy of the key,
and the piece of paper got lost or stolen,   or a "hacker" broke into the "offline" server,   snagged a copy of the keys,
and deleted them all.

There are thousands of ways they could have screwed up and lost the keys.


This is why a cautious, responsible company would for sure have multiple backups of the secret keys

plus prevent any one individual from gaining access to them,  by  dividing the keys,  and using a validated system to construct the keys  when required,  requiring participation of  N out of M   of the trusted individuals.

and frequent audits of  customer transactions and deposit balances, to authenticate any requirement to withdraw from cold storage, AND to ensure the vast majority of funds are rolled into cold storage.



Based on the news... there is reason to think MtGox was anything BUT sufficiently cautious, with well-thought-out implementation  of back office security controls.

So, Itod, you completely reject the theory that Karpeles lost the keys to MtGox's cold wallets?

Key generation is literally a few lines of code. It was tested in all programming languges from the begining of the bitcoin. Whoever ("many") speculated that, they don't know first thing about bitcoin. MtGox software may have had thousand bugs, but there's 0 chance key generation was one of them.

In that case you can sign a message with the private key and use one of the many signature-validation-tools out there to validate the signature.

It has been speculated by many that MtGox lost the private keys to their cold cold storage wallets because of a bug in their key generation software.

Before putting 10,000 BTC in an address, I would want to check to make sure the private key really works for that address.  Wouldn't you?

The OP doesn't really have an appreciation for how straightforward hashing a random number twice is.

What do you mean by testing an address? Why would you need to "test" it?

Testnet.

But what if there is a bug in my internal testing procedure?  Ultimately the only true test that is 100% reliable is to do a live spend.

Transactions below 5430 satoshis are not valid and won't get confirmed anyway.

You wouldn't want to actually do something like this live on the blockchain, instead you should develop your own internal testing procedure based on the spec. The reason being that executing a spend puts your public key out there on the blockchain, which is less security for your keypair versus just having the payment address publicly known (which adds RIPEMD-160 to the mix).

If you perform a spend with the intention of keeping a balance in that address, you've basically handed the RIPEMD-160 portion of the attack to anybody who wants to compromise your keypair. Granted it's still a daunting task, but the best security practice is to never reuse an address that has performed a spend.