Topic: Questions about Bitcoin QT (Read 1209 times)

Well, I guess one could make some money by creating a smatphone application like that which includes a small advertisement area below a nice animation about earth and a black hole and asks for donations upon exit (may be even on a funny way, like "please support the quantum physic researchers, so we may avoid this possible catastrophe, here is my BTC address, thanks").
Does this idea leave your idea being completely useless?

An online address book wouldn't do any good.  Remember spending goes both ways.  If you generate a key which is in use (which we can safely say is so unlikely as to be infeasible) you could steal the funds of the existing keyholder (just as the existing keyholder could spend any funds you send there). 

So you find out a key you generated already exists?  What do you do delete the key?  Ok so the system now relies everyone to be honest.   Simply put if you EVER randomly generate an existing address, don't tell anyone.  Sell every bitcoin you own and THEN tell everyone because it likely means some kind of catastrophic flaw in the cryptographic primitives.   The infeasibility of not being able to duplicate a private key is a cornerstone on which the security model is based.

Having some kind of lookup and check would be as useful as having a "has the world been destroyed by a blackhole" app on your smartphone which will in realtime continually advise you that it hasn't happened.  As long as the app shows a green checkmark you can safely know the world hasn't yet been destroyed by a rogue backhole.

Thank you for the reply.

I guessed the probability is low, but didn't know if there is an "online address book" kind of protection on the online network anyway and if new public keys should be "reserved and activated" online before they can start receiving coins (something what the online wallet could automatically do in the background without bothering me with a notice but has to be done manually in case of a cold storage).

So, they don't...

It doesn't.  However law of probabilities make the chance of a collision infintesimal.  Note this isn't something unique about Bitcoin, all public key cryptography works the same way.  You may have a much better chance of just mashing keys on your keyboard and producing the private key for htttps://google.com than you do creating a private key which is in use.  2^160 is more atoms than exist on our solar system.   If you need a visualization imagine you randomly selected a single atom from somewhere in solar system (it could be an atom of carbon in the dust bunny under your bed, or an atom of hydrogen in a storm of jupiter).  It would be easier for someone else to pick a single atom in the solar system and happen to pick the same one as you then it would be to generate the same 160 bit number.


If you generate the same private key (or one which produces the same pubkeyhash) then either you or the other party could spend the funds.  This isn't anything unique about paper wallets, the same thing would apply if you used an online wallet as well (how do you know the colliding address isn't a paper wallet which is unknown to the network).  The chance is essentially zero.  You could generate quadrillions of keys per day for the next billion years and not even have a 1% chance of a collision. 


Of course.  To check the "value" of an address you only need the address.   If there is a collision either you or the other person could spend the funds.  See above for why that is essentially a zero percent chance.

I never felt the need to do this before, but I wish to set up my first "cold storage".

My questions are:
- Does the QT wallet need to register (open / claim / reserve) the public key on the online network before it can start receive coins?
- Can this single public address receive multiple transactions? (Is the key pool of the online wallet only for receiving the change from the amounts I send, but not what I receive?)
 
I read about paper wallets and it seems like I can generate a new public + private key pair completely offline and send my coins from an online wallet to that new public address without ever exposing my private key to online machines (malwares, keyloggers, etc).

But somehow it sounds weird for me.
-> How does the offline key generator know if somebody else uses that public key already? Won't I just send my coins to a stranger if (s)he also generates the same random address before I sweep my cold wallet?

Nah.  Someone with the technical ability to run a mining pool can probably just write a computer program to handle both the bets and the double spends.  No need to share the income with you at all.

Because you gotta sit there all day and place a ton of small bets on a bunch of different sites.

Why would a mining pool assist you with that?  They could just do it themselves and keep all the profit.

Actually it's pretty simple. Any of those dice websites that roll on a 0 confirmation tx, you confirm the tx if you win, double spend the tx to your own account if you lose.

As I said:


Furthermore, for your scam to be successful you'll have to find gullible victims that are willing to accept large value transactions with 0 confirmations.  I suspect that will be more difficult to do regularly than you think.

How would the members find out? It's not like the pool is going to send out a notice saying they're partnering with a thief.

But once their members all left, they would no longer be a "pool of significant size".  Therefore you wouldn't be able to steal nearly as much.  

Feel free to contact the operators of the larger mining pools, but I suspect you won't get the responses you are hoping for.

Right, but pools typically pay out the majority of the revenue to miners. If they solve 20 blocks a day and 1% of that is profit for the pool, they make 5 BTC a day.

If a pool of significant size aided me w/ double spending I could easily steal 100 BTC a day and give them half of that.

OFF TOPIC

I must be getting slow today.  That's two posts in a row that D&T got in ahead of me.

/OFF TOPIC

None that I'm aware of.

You probably wouldn't be able to pay enough to make it worth the risk for them.  If the miners in the pool discovered that the pool operator was assisting someone in committing fraud, many miners would likely leave the pool for a non-criminal enterprise.  This would significantly reduce the number of blocks that the pool could solve per day.  Each reduction of 1 block would reduce the gross revenue of the pool by 25 BTC.

Probably not or at least not any pool of significant size.  Left you some friendly feedback.

Are there any mining pools who would be willing to make deals like that?

I would, of course, be willing to pay a sizable cut of the profits generated from accepting my double-spend Txes.

No.

Within 30 seconds (actually quite a bit faster than that), the first transaction will have relayed throughout the bitcoin network.  Nearly all peers will be aware of it.  The reference client (and nearly all ppers that are based on it) is designed to ignore and not relay transactions that attempt to double spend an input that it currently holds in memory.  Therefore, none of your peers will relay the second transaction, and it will most likely not get confirmed before the 0-fee transaction since most miners will not hear of it.

You will need to find a very large mining pool that is willing to accept your double-spend transaction in place of the transaction that they already know about.  Then you will need to transmit the double spend transaction directly to an IP address that the pool operator supplies you.  You will then need to hope that they solve a block with your fee-paying transaction before any other miners or pools solve a block with the free transaction.

Probably not.

1) The client won't intentionally double spend so you will need to delete the the first tx from the wallet "history".  The client provides no mechanism to do this natively although tools like pywallet can be used. 

2) All nodes will drop double spends in favor of the first tx they saw.  So in your example you sent tx#1 to all your peers.  When you send tx#2 to the same peers they will immediately recognize it as a double spend and simply "drop" (delete) it.   Changing to new peers is unlikely to work as your peers relayed tx#1 to their peers who relayed it to their peers, etc, etc, etc, and within a few seconds every node on the planet is aware of tx#1 and will see any attempt to double spend it as invalid and just drop tx#2 without relaying.

The network is intentionally designed to make double spending difficult.  
The client is intentionally designed to make creating tx that have a very high probability of being "stuck" (never relayed to included in a block by most clients) difficult.

You can hack around these design constraints but don't expect it to be easy.  This is why Danny indicated you need to wait a few days.   If a particular node NEVER dropped tx#1 then it would never store or relay tx#2 however to avoid a memory exhaustion attack eventually nodes will drop the oldest tx from the memory pool.  You can't control when your tx#1 will be dropped by other nodes.  It will occur as needed with each node acting independently.  Until tx#1 is dropped from a particular node any attempt to broadcast tx#2 will mean it is simply dropped by that node.  Until tx#1 is dropped by a majority of nodes the probability that it will be able to propogate the network and find one or more miners is very low. 

In theory you could bypass all that by sending the tx directly to a miners however most miners don't make their processing nodes known or accept inbound connections.  Those that do don't allow replacement of txs in memory pool for obvious reasons (malicious double spend).

Hmm, what I need to be able to do with spending an output twice though is the following:

Create a transaction (no tx fee), send it.

Wait 30 seconds.

Create a different transaction spending the same output (with tx fee), send it.

Would that work? The 2nd tx should get confirmed first since it has a tx fee even though it was sent after.

Use raw transactions. Or modify the source code and re-compile it. (It may also be possible with the new "Coin Control" feature, I'm not sure, I haven't tried that yet).


Create a transaction that is very unlikely to be relayed or confirmed.  Then use pywallet to remove that transaction from your wallet.  Wait a few days for all peers to drop the transaction from their memory.  Create a new transaction that uses the same inputs (use "Coin Control" or raw transactions).

First off, how do I disable the transaction fee for low priority transactions? It forces a transaction fee even though I set it to 0.

And what's the easiest way to spend an output twice? (Yes, I'm fully aware of the fact only one of the transactions will make it into the blockchain and be valid.)