Topic: 28 000 unconfirmed TXs - page 3. (Read 6024 times)

Do you have any information on the transaction?  What address was it sent to, etc?

hmm, i got a transaction 2 days ago... and until now it was unconfirmed (no double spend confirmed)..., and i checked now... and it just disappeared from my blockchain transaction logs lol...

can anyone explain me what happened? how can i recovery it? D:

my money T.T

Only make the blacklist temporary, you dont want to block legitimate addresses aswell, it could be a disaster.

By only blocking 1 person with 100.000 bitcoin in error, can make huge losses to the community.

I propose a blacklist aswell, but only one of 30 days, after 30 days he can move the coins, if he spams again, then another 30 days and so on.

Permanent ban can be exploited, and you dont want to ban errorously a white address

Then let's raise the maximum block size already. Those Chinise miners can go fuck themselves with their whining. I have had enough of this moronic argument about the block size. Miners have no right to even open their mouth in this argument because one change to the protocol and their ASICs turn useless. The only real owners of the bitcoin network are the bitcoin holders who can vote with their private keys what to do next with the protocol. If you are a parasite miner who sells all their mined coins then you are not a stakeholder and have no right to participate in this discussion.

This framing of the 1MB debate above is totally irrelevant to the historical and current context of the situation for Bitcoin.

The 1MB was a "sanity check" later described as a general spam limiting measure. When Satoshi did the commits to put this limit in everyone who used bitcoins had to run a full node. Many of them had low-power hardware and were just learning about his new form of electronic money. He did not want a rogue miner to create a series of large blocks which were >1000x the prevailing average block size, and put people off at such a delicate time. Also, the first mention of FPGA mining on bct was made then. A rogue miner using FPGA tech was the very thing Satoshi feared at that time.

Now the 1MB is argued by some as a general anti-spam protection. Yet the only real protection is higher fees. The community has already observed much of the policy recommended by Core Dev in this respect and fees per tx (in non-flooding periods) are reasonably healthy. I measured 6 days worth of >900KB blocks back in Feb 2015 and the average block fee was 0.25 BTC. It is reasonable to extrapolate this out to 5 BTC in fees per 20MB block in 6 years time, when the block reward is down to 6.25 BTC. This means that an organic, demand/supply balanced, i.e. viable fees market should be possible at that time. It is only then that spammers can be priced out of business. When their tx expire from the mempool then their fees are available to them to re-use for the next attack. It is better to take their money off them, even if it means a bigger blockchain in the meantime.

Trying to leverage the 1MB to force a viable fee-market earlier is a dangerous experiment in "Blockchain Economics", as the market will simply turn to other cryptocurrency solutions instead. Markets can't be forced to do anything, as a long list of central bankers are finding out time and time again.
Further, the 1MB does not allow for legitimate peak loadings. Let's say the "non-spam" content of blocks is 250KB. What happens if legitimate bitcoin business demand requires 1.5MB for a while? In that case, ordinary users get the message that Bitcoin is unusable when most needed. This would be a cancer to ecosystem growth.

I am not saying that handling ever growing blocks is easy, and there are other scaling issues behind the 1MB, but these need to be found as demand rises, not hidden behind the 1MB which is already causing distortions in the functioning of the network.

That is actually a very good idea and could be reasonably feasible. Hopefully keeping the root TXs in the internal DB won't consume too much memory and checking their existence won't consume too much CPU.


But this soft fork is backwards compatible. It would only make a difference when the network is flooded by TXs and it encourages people to update their clients because updated nodes would reject their TXs otherwise. Don't worry about the algorithm, it can safely use something such as SHA256 but have some bits swapped in the end or in between so that a plain SHA256 ASIC would be useless.

BitMessage uses SHA256 very similarly to bitcoin but the same ASICs can not be used that are used for bitcoin mining. BitMessage has a fixed difficulty on the protocol level. Not very good but it's way better than having no difficulty at all because it makes attacking many times more expensive. If Bitcoin was to implement TX mining, then its difficulty should be adjusted according to the number of unconfirmed TXs.


It's good to know that such a patch exists but it would be better if it was included in bitcoin-core.

The mempool should drop "less important" TXs because who cares if some of them could be legit if the node is running out of RAM. Dropping less important TXs is the lesser evil in comparison to an out of memory exception . All it can do is to politely tell the other node that their TX could not be accepted at this time and that they should try sending it again later.


I disagree but I might have used a wrong term. Instead of rejection I would rather call it postponing. The honest nodes whose TXs are postponed by neighbouring nodes must attempt to resend the TX in gradually increasing intervals. If a node resends the TX too often they would be banned by their neighbours.


You are absolutely right. I have previously proposed that every 144th block should have the technically maximal possible size or some other giant size such as 64 MiB just to clear the backlog of unconfirmed TXs once per day. Other blocks should have a size of 8 MiB which I believe is more reasonable than 1 MiB. That limit should not be raised in the future but instead if needed then the maximal size of the 144th block could be increased.

I can't put it any better than that. People saying that we need to raise the blocksize limit to prevent DOS is utterly and obviously senseless, illogical, and untrue; contrary to all reason or common sense; laughably foolish and false*.

https://www.reddit.com/r/Bitcoin/comments/3cfext/bitcoin_under_attack/csvoxvp
*http://dictionary.reference.com/browse/absurd

This only activates for transactions that violate the rules of the system.

If your node receives a transaction that spends unspent outputs, then it is a valid transaction and it gets added into the memory pool.  Once it is added to the memory pool, it gets forwarded.

There is a minimum relay fee required.  

The DOS protection is the tx fee.  If someone is willing to spend actual bitcoins for their transactions, then they can spend loads of transactions.  Eventually, they run out of bitcoins.

Yeah. It's called the banscore. It apparently doesn't work if someone is intent on spamming.

The node could see that all of these chained transactions stem from one transaction. It could block any transaction that has an ancestor of that particular transaction. If the node kept a database of the spam transaction chaintip, it could quickly determine whether the parent transaction was part of the spam chain and block the child.

It would require a soft-fork and we all know how long soft-forks take and their consequences.

As long as the devs are smart enough (I do hope they are) to not use an algo that has an ASIC (e.g. sha256 or scrypt) it could potentially work. How does bitmessage implement this and how do they determine the difficulty?

There is a patch called Replace-By-Fee where transactions spending the same inputs can be replaced with another that has a higher fee. The mempool should not drop "less important" transactions because some of them could be legit. Rather, miners should choose which transactions to include by their priority, which I believe already happens.

You should never see that your transaction be rejected, simply that it will take a while to confirm. I believe that all transactions should confirm eventually. Instead of having no chance for a low fee transaction to confirm, there should be a chance eventually for it to confirm in the future. The RBF patch allows you to replace the transaction in the mempool so that it has a higher priority with a higher fee, thus allowing your transaction to confirm sooner (hopefully).

Ok I believe you now. I thought there is already an IP blacklist based DOS protection that is effective for 24 hours.

About your solution, it doesn't protect against precompiled TX spam from once-before-seen addresses to never-before-seen addresses.

I still propose to investigate the possibilities of attaching a PoW to TXs, since this approach is used in BitMessage and it works. ASIC fear is rather similar to quantum computing fear because both are hypothetical. Even if someone decides to build an ASIC just for TX spamming it will take several years for them to finish it. By that time we might come up with an even better solution to fight against spam TXs. It will win us a lot of time. TX mining can be done without a hard fork. For example, one would add a nonce behind the OP_RETURN until the TX hash begins with enough zeroes to satisfy the TX PoW difficulity requirement. Nodes would then prefer TXs that have more zeroes in the beginning of their hash.

Another option to fight TX spam is to implement TX fee auction. The latter is needed anyway because there can only be a limited number of TXs included in a block so the miners will prefer to include the most profitable TXs. When there are more unconfirmed TXs than could possible fit in a block the nodes must have a technical possibility to replace their earlier TXs with a modified version that includes a higher TX fee. I believe this also can be done without a hard fork because nodes must just recognize the replacement TXs and discard the old version of that TX if the new version has a higher TX fee. Since the mempool must also have an upper limit of say 64 MiB, individual nodes should keep a priority list of TXs. When the mempool is full and a new TX comes in, the node will see if the new TX's priority is higher than the priority of the least important TX in the mempool. If it is so, the node will drop the least important TX and add the new TX to its mempool.

If the above is implemented, the attacker must constant win the TX fee auction against all the other users of the bitcoin network. It will quickly become very costly to keep up the attack. As a honest node, I would only see my TX rejected by neighbouring nodes due to not having a high enough TX fee. I would then modify the TX to add a slightly bigger fee and broadcast it again until it is no longer rejected.

I'm sorry if it seems like I'm trying to bash your ideas for improvements. I'm simply pointing out flaws in your proposal and ways that it could fail. The point of this is to come up with ways that can make this work. I personally don't think that your proposal will work to stop spam. It introduces new issues with the necessary computing power required to create transactions.

I propose using a blacklist. Each node would see whether there are addresses that are being spent to or from that are in spam transactions. It would add said transactions to its blacklist and simply not relay any transactions that include certain addresses. This would reduce the amount of spam transactions to and from certain addresses. This would work for current spamming situations since the easiest way for spammers to spam is to simply send dust between addresses. Once these addresses are blacklisted, they won't be added to the mempool.

Please feel free to poke holes in my idea. I am open to change and modifications.

The attacker could also have a quantum computer or majority of the mining power or whatever fictional contra argument you can fantasize about.

Since TX PoW is not used for mining and is solely used to reduce spam, the algorithm can be changed with super consensus. Only spammers would be against such protocol changes. Their ASICs would become worthless. You start to seem more and more like a bitcoin traitor, unable and unwilling to come up with solutions and only trying to bash ideas for improvements with rather lame counter arguments.

We've recently crossed over the 80,000 transaction threshold
The blockchain.info transaction feed has been proven to be untrustworthy last time we were flooded with transactions, but TradeBlock and other newer sites keep a more accurate number

edit: TradeBlock just died, I give up

CPU at 9%: http://188.166.81.128/localdomain/localhost.localdomain/cpu-day.png

43000 transactions: http://188.166.81.128/localdomain/localhost.localdomain/bitcoind_mempoolcount-day.png

78Mb mempool: http://188.166.81.128/localdomain/localhost.localdomain/bitcoind_mempoolbytes-day.png

consider my edited response quoted below
The attacker can do what I said above, use ASICs to continuously drive up the tx difficulty.

2 options. Either the difficulty should be pre set to a reasonable level similarly to how a maximum block size is a constant.
Or, TX PoW difficulty should be dynamic so that at times of attack the difficulty rises temporarily. The latter is much better alternative to what we currently have because then the mempool won't get flooded but instead TXs would get longer to compile.


So let the spammer setup a ton of nodes. That will be a limited resource which will eventually get depleted. Also, if you read my answer above you will understand that as the attack is carried out the TX PoW difficulty goes dynamically up rendering the attacker's precalculated PoWs useless.

That combined with a block size limit of 8 MiB and minimum TX fees would be enough to stop such attacks. In addition, the protocol can be adjusted to respond to a sudden increase in the number of unconfirmed TXs so that minimum TXs fees would be risen programmatically.

Ok. Perhaps I did not understand. Perhaps you can inform me. I will re-read your posts and see if my understanding changes.

How so?

Even when done with public keys, if the spammer has setup a ton of nodes and each one has the exact same wallet but different signing keys and ip addresses, each node could send a couple of transactions per second yet when all of the nodes are combined, it is still spamming the network. This solution still wouldn't work. Nodes could filter based on addresses, but even that could still be circumvented.

knightdk, you simply did not understand what I was suggesting about TX PoW. All your replies were ill formed and overly pessimistic without understanding my idea. If you are a troll, then I would like to have you vaporized.

TX "mining" can be done without impact on devices that have less computing power.

Distinguishing between nodes can be done without linking them to the IP. For example, you can do it based on the signing public key.

That makes your whole long reply invalid.

Most of the dust transactions that are spamming the network are being dropped by most node's mempools. It is primarily these dust transactions that cause the mepool to grow so large.

So you are suggesting that we must mine txs in order to have it be accepted and confirmed? What if the malicious spammer has an ASIC that can calculate these PoWs faster than everyone else and makes them more difficult? That means that he just raised the difficulty of his transactions, thereby increasing his priority. This causes other people to have a lower difficulty than the majority and thus their priority is lower. So what happens to those people that don't have sufficient computing power to calculate a PoW more difficult than the spammers? Does this make their transaction have a lower priority and they are essentially locked out of making transactions?

If a PoW calculation is difficult, what happens if my computer does not have the computing power to calculate a sufficiently difficult PoW? Is it rejected and blocked from the network? Does that mean I will have to wait even longer for Bitcoin Core to start the first time so that it can generate a PoW that identifies the node as me?

While there may be 72000 unconfirmed transactions, the standard mempool and standard Bitcoin Core software drops certain transactions. The site, tradeblock, where you are getting this number from, records the transactions differently. They record all transactions broadcasted, which will include all of the dust and spam transactions that other nodes and miners will drop from their mempools. The 72000 number is not an accurate representation of what the actual number of transactions in the mempool is.

Edit: Take 2, because apparently the first one was wrong.

This is not right at now there are "only" near 18.000 unconfirmed transactions....

https://blockchain.info/it/unconfirmed-transactions?offset=0