Topic: ... (Read 4660 times)

You can now use the settxfee JSON RPC command to set the default transaction fee for 24 hours http://blockchain.info/api/json_rpc_api

or set fee policy to generous in the javascript interface to increase the base fee to 0.001 BTC

You are looking in the wrong place.

The 0.81177179 BTC change from this transaction:
http://blockchain.info/tx/f3b95391c4ed5af0fa7f737aac52a6d9892feb34543a077f30b81696cc1d4021

Was used as the input for BOTH of these 2 transactions:
http://blockchain.info/tx/97825f2228c0087acf2b7edce81c79838931845c4b0595ed4088966ebdf9d633
http://blockchain.info/tx/ccb75ea48acc40f249f445ab7b6913e6a805938c022fbc6c9dcbdc67e4cb8847

Since the spend of that change in ccb75ea48acc40f249f445ab7b6913e6a805938c022fbc6c9dcbdc67e4cb8847 has been confirmed, it no longer exists to be used by 97825f2228c0087acf2b7edce81c79838931845c4b0595ed4088966ebdf9d633.

Good news! Both of those transactions have finally confirmed.

Bad news...

The following transaction is a double-spend and will therefore NEVER confirm.

http://blockchain.info/tx/97825f2228c0087acf2b7edce81c79838931845c4b0595ed4088966ebdf9d633

Why not limit the number of outputs in each transaction?

Don't worry, there is already a 5 BTC reward up to include this transactions in a Block:

https://bitcointalksearch.org/topic/5-btc-bounty-to-mine-these-two-transactions-for-coinbase-143915

So they will probably get confirmed soon.

Don't the receivers of an unconfirmed transaction also try to keep it alive by rebroadcasting?

Considering these transactions have ~600 outputs, it's likely that some of its receivers did get it.

I don't think this is true. I was able to double spend MtGox by sending a payment with the same coins (with fee) as was transmitted by MtGox auto-sweep an hour before (without fees). https://bitcointalksearch.org/topic/m.1483106. It was included in the next block.

I think you misunderstood any node following the reference client rules will drop and refuse to relay a double spend.  So if you have tx A and you wish to replace it with tx B, when your node broadcasts tx B to the 8 (or 50) immediate peers the most likely outcome is they all detect tx B is a double spend of tx A (because tx A is in their memory pool) and promptly drop it.  You can keep broadcasting tx B thousands or even millions of times and they will happily drop it each time. 

Now eventually nodes do "forget" about unconfirmed tx so after that you can broadcast tx B, and your peers not having a record of tx A relay the tx on to other nodes, who will relay it to other nodes, and eventually every node and miner will know about tx B.   There is one "gotcha" though. As long as your node knows about tx A (it is still in the wallet) your node will keep reminding other nodes about tx A (who will remind other nodes) this will ensure that nobody ever forgets about tx A preventing a spend of tx B.

So simple version:
a) Bypass the peer network and get the replacement tx in a block.
OP can contact a mining pool and ask him for help (likely for a fee)

or

b) Allow the network to "forget" about the original tx and try again.
OP (or someone who in the future is in the same scenario and doesn't want to need to contact a miner) can remove the tx from the wallet file, wait long enough that the network forgets about it and create a replacement tx.

There is no time restriction on re-spending transaction inputs; the same transaction can immediately be double-spent - resent with less change and more fees. The unconfirmed transaction will be discarded from memory pools when a replacement transaction using the same inputs is included in a block.

The only caveat is that if you delete the transaction from the Bitcoin client and send a different total amount, Bitcoin may compose the replacement transaction from different inputs, since it uses an algorithm that chooses inputs based on minimizing change. A "resend transaction with more fees" feature could be implemented in Bitcoin that ensures a duplicate spend of the same inputs (plus more inputs if needed to add the increased fee). However there is little need, because the reference Bitcoin always includes at least the minimum fees.

blockchain.info will temporarily brand your address with a double-spend warning for others when it detects them on the network.

I'm getting "transaction not found" when I look for  http://blockchain.info/tx/88eb395b48a6d3875d8d55a6efd34afd2e1d4e397b43f9f790479914fba0c74b

Was there a double-spend on this initial transaction?  Wow, that would be quite a mess for a lot of people.

It isn't part of memory pool selection rules in bitcoind.  Most (all?) major pools use custom software but AFAIK unless it has changed recently no pool does "forward looking of fees".  

The OP has two solutions:
The first solution is to delete the offending transactions locally (requires some wallet.dat surgery).  Other nodes including miners will "forget" about the unconfirmed transactions in time (I believe 24 hours?).  This would allow creating a replacement transaction with an appropriate fee to ensure timely inclusion.

The second solution is to contact a pool operator directly, provide them the transaction hash(es) and for a manually paid bounty (fee) they may be willing to manually add the offending transactions to the pool's next block.  IIRC Luke has done this in the past.

If both of those solutins sound like they suck, well that is the point.  The mandatory fee rules exist to protect the network from a denial of service attack.  If one could create 600 outputs using 22KB for a mere 0.0005 BTC (about 1.2 cents) then one could also create transactions totaling ~30,000 transactions and 1 MB for about $0.50.  For less than minimum wage an attacker could denial of service attack the largest computing network in the world and add roughly about 4GB of spam to the blockchain per month.

Simple version:  DON'T BYPASS MANDATORY ANTI-SPAM RULES.  They exist to protect the network.  When you bypass them the network teats the transaction like a threat and the "immune system" which consists of dropping and delaying high-cost low-value transactions kicks in.

I thought this behavior had already been implemented in bitcoind. I might be wrong though, can't find it on github.

You could directly ask some large pool operator to please include it. Maybe for a small donation to the pool.

afaik no miner software has that implemented.

It would, but your change address 1969VR2qCchXMW94tpcYirbVLUfFw4Pw7b has many unspend inputs, you used input that is not output of any of the 2 transactions in original post. You have to use just the right input for it to even work. You have to use for example bitcoind sendrawtransaction after creating and signing it. Not a easy job for causal user. https://en.bitcoin.it/wiki/Raw_Transactions

Anyway this method like adding big tx fee to subsequent tx just to process previous tx with fee amount below the recommended one is most likely only theoretical, and not many miners/pools check for it as far as I know, but I may be wrong and things changes.

I would just wait, it eighter gets processed, or the tx will disappear. By the way these tx with less than recommended fees includes in the block only EclipseMC pool, and only when there are not enought of regular tx, so big thanks to them even adding these tx and supporting bitcoin microtransactions niche this way !

BTW your yesterday similar tx
http://blockchain.info/tx/4d2f20a628037a1723ad4e8d11b7333577c1382f5daf728d440ad5ef01795cd9

has been included by EclipseMC, so they didnt stop including those txs.

Nah, the other 2 transactions are still unconfirmed. He used the wrong output from the address.

Apparently it did.

As I said to OP, you may attempt to send the "locked money" to yourself, and pay a large transaction fee in the process. Theoretically the whole unconfirmed chain should be analyzed together by miners. (the fee would be used to pay for all of them).
I suppose something like 0,1 BTC as fee is already quite large.

But if you're not in a hurry, just wait.

Let us know here if Coinbase resolves this issue for you.  They should not be sending out unconfirmed outputs, and I won't be recommending them to anyone until/unless they make good on this for you.

I've emailed their support, gone through the support links on the website, and even tweeted at them. Nothing, no response. Experimenting with BTC has turned out to be a pretty expensive lesson!

In that case Coinbase screwed up. They shouldn't be accepting (and re-sending) transactions that haven't confirmed.  If it was me, I'd be contacting them and complaining.

This was a payment from coinbase to my wallet. I didn't do anything wrong (I don't think)

This is one of the risks you take when accepting transactions with 0 confirmations. I suppose you can try and find someone else to accept the 13 BTC from you with 0 confirmations as well.  If the OP transaction ever confirms then all the other transactions confirm. If it gets reversed with a double-spend, then the whole chain collapses.

um, don't send 13BTC worth of goods/services until your incoming 13BTC confirms

Not really, since the propagation delay also increases the amount of time other miners work on an old block. I don't have a mathematical proof, but my gut feeling is that on average the size of the block simply does not matter.

So if I have a transaction that relies on a transaction that relies on a transaction that relies on this guy: http://blockchain.info/tx/88eb395b48a6d3875d8d55a6efd34afd2e1d4e397b43f9f790479914fba0c74b, does that mean that I won't get any confirmations until this goes through (if ever)?

My transaction (http://blockchain.info/tx-index/52509782/9eb202978e1653a0d3b1c936c2a07228055ce434c6c065c727336cfc0a74d115) has been unconfirmed for like 8 hours now and I think I traced the backup to the OPs transaction by using bitcoincharts (http://bitcoincharts.com/bitcoin/txlist/#9eb202978e1653a0d3b1c936c2a07228055ce434c6c065c727336cfc0a74d115). I guess there is no recourse right? I just hope I didn't just lose 13btc because of random chance. Anyone have any consoling words for me?

Do you control any of the outputs?

I think that if you initiate a transaction from any of the outputs, and put a juicy fee on it, miners will combine the two when analyzing its fee/priority ratio. That might speed things up.

0.0001 per kB (not KiB) to relay x 22.530kB in size = minimum 0.0023 fee to relay (vs 0.0005 paid). Bitcoin requires the minimum fee if any output is less than 0.01 BTC, which many many are.

Good point forgot about the lower threshold for relay vs inclusion.

as i recall, the relay fee is 0.001 vs the creation fee of 0.005.  so it seems like your transaction would be relayed at least (if your node broadcasts it, some others should relay it).  it would be pushed down to the bottom of the list as more transactions are added

They only have 1 input though. I thought many inputs was the biggest problem in what concerns verification time.
Actually, if this transaction was paying 0,011 in fees, wouldn't it be better to include it instead of 22 tx of 1kb paying 0,0005 each, in what concerns propagation time? Since the latter would have at least 22 different inputs to be validated.
EDIT: Dumb me, outputs have to be inserted in the transaction index, and that's likely to take more time than validating inputs. Ignore what I said above.

I only looked at the first one but it is one giant "spammy" transaction (per low priority rules) which is 22KB and has a fee of 0.005 BTC.  The min mandatory fee for low priority transactions is 0.0005 BTC per kb.  For this tx that would require 0.011 BTC so the tx is non-compliant and many nodes will simply drop it.

Even with a 0.011 fee how long it takes to be confirmed depends on if a miner wants to include it in a block.  Most miners are just going to pass on including junk like this.  22KB with 600? outputs is enough to increase the risk of getting an orphan.   So say it increases propagation delay by 1%.   So I can collect get 25 BTC or include your tx and get 25.01 BTC but 1% of the time I lose the entire block.  In the long run I earn more by not including your tx.  If I were running a pool I wouldn't include it ... ever.

...