|
Title: 28 000 unconfirmed TXs Post by: Hyena on July 07, 2015, 10:43:59 PM I noticed my CPU was at 100%. I started to investigate and verified that my block chain monitor process was running at 100%, consuming 100 MiB of RAM and totally frozen. After restarting I was amazed to witness such logs:
Code: Wed Jul 8 01:40:13 2015 :: Checked 20 of 28281 unconfirmed TXs in 2.00 seconds. How on Earth can there be 28 000 unconfirmed TXs. That's probably one of the reasons my process froze. Is the bitcoin network under attack or being stress tested by someone? What's happening? edit: for the record, I upgraded my bitcoin-core to version v0.10.2 (64-bit) yesterday. edit2: if the raw mempool is getting SOOO freaking huge then we need API commands to get data from the raw mempool in pages rather than as a one giant json object. Title: Re: 28 000 unconfirmed TXs Post by: RussianRaibow on July 07, 2015, 11:33:36 PM How on Earth can there be 28 000 unconfirmed TXs. That's probably one of the reasons my process froze. Is the bitcoin network under attack or being stress tested by someone? What's happening? Bitcoin was under attack (https://www.reddit.com/r/Bitcoin/comments/3cfext/bitcoin_under_attack/). Now, it is recovering. Bitcoin is resilient (https://www.reddit.com/r/Bitcoin/comments/3cg95d/bitcoin_is_resilient/). Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 07, 2015, 11:53:31 PM How on Earth can there be 28 000 unconfirmed TXs. That's probably one of the reasons my process froze. Is the bitcoin network under attack or being stress tested by someone? What's happening? Bitcoin was under attack (https://www.reddit.com/r/Bitcoin/comments/3cfext/bitcoin_under_attack/). Now, it is recovering. Bitcoin is resilient (https://www.reddit.com/r/Bitcoin/comments/3cg95d/bitcoin_is_resilient/). I think bitcoin-core should start discarding unconfirmed TXs if they start to consume too much memory. TXs with the lowest priority should be discarded first. Also, individual TXs should contain a proof of work in addition to the fee. The proof of work should be optional and should increase the priority of the TX so that it would not be discarded so easily. For example, let's say the network is under attack. The nodes would not be able to distinguish between malicious TXs and honest TXs. However, a honest node would attach a proof of work to the TX so that honest TXs would be favoured by the network since their proof of work has more zeroes in front of the hash than the malicious TXs. When the attacker chooses to attach their own PoW the priority of the malicious TXs rises naturally to the point that it could push out the honest TXs. However, because the client can freely choose the difficulty of the PoW, it will notice that their TX is not accepted by other nodes so the client increases the difficulty, calculates a new PoW and resends the honest TX. That way, the bitcoin network would become super resilient to the given attacks. Title: Re: 28 000 unconfirmed TXs Post by: domob on July 08, 2015, 05:36:23 AM How on Earth can there be 28 000 unconfirmed TXs. That's probably one of the reasons my process froze. Is the bitcoin network under attack or being stress tested by someone? What's happening? Bitcoin was under attack (https://www.reddit.com/r/Bitcoin/comments/3cfext/bitcoin_under_attack/). Now, it is recovering. Bitcoin is resilient (https://www.reddit.com/r/Bitcoin/comments/3cg95d/bitcoin_is_resilient/). I think bitcoin-core should start discarding unconfirmed TXs if they start to consume too much memory. TXs with the lowest priority should be discarded first. Also, individual TXs should contain a proof of work in addition to the fee. The proof of work should be optional and should increase the priority of the TX so that it would not be discarded so easily. For example, let's say the network is under attack. The nodes would not be able to distinguish between malicious TXs and honest TXs. However, a honest node would attach a proof of work to the TX so that honest TXs would be favoured by the network since their proof of work has more zeroes in front of the hash than the malicious TXs. When the attacker chooses to attach their own PoW the priority of the malicious TXs rises naturally to the point that it could push out the honest TXs. However, because the client can freely choose the difficulty of the PoW, it will notice that their TX is not accepted by other nodes so the client increases the difficulty, calculates a new PoW and resends the honest TX. That way, the bitcoin network would become super resilient to the given attacks. I think that we need some kind of control on the size of the mempool eventually if it grows too big. I'm not sure that PoW is the way to go, though - I imagine that the outcome would be that spamming is still trivial with, say, a Blockerupter, while ordinary users need to compute very long to get a suitable PoW. Title: Re: 28 000 unconfirmed TXs Post by: btc_enigma on July 08, 2015, 05:37:11 AM my bitcoind crashed yesterday .. memory and cpu usage is high
Someone suggested I increase txrelayfees , what fees should I set so that my service doesn't miss out non spamming transactions while blocking spam tx Title: Re: 28 000 unconfirmed TXs Post by: ChetnotAtkins on July 08, 2015, 09:54:40 AM There are currently 60000 (!) unconfirmed transactions. Mempool at 50 MB
https://tradeblock.com/blockchain/ Title: Re: 28 000 unconfirmed TXs Post by: NoBit on July 08, 2015, 11:50:27 AM How long will this "attack" last? Does it have anything to do with the recent LTC-pump?
Title: Re: 28 000 unconfirmed TXs Post by: Vezalke on July 08, 2015, 11:57:36 AM Hey, thanks for link. I'm waiting for my transaction for 20 hours now and the fees was included. ::)
Title: Re: 28 000 unconfirmed TXs Post by: el kaka22 on July 08, 2015, 12:09:27 PM I see that blockchain.info have some bug on showing unconfirmed txs, they only show 17k txs for now (but it is still a large number).
There are currently 60000 (!) unconfirmed transactions. Mempool at 50 MB And at this page it is showing 66k transactions! And there are some f... miners who still mining empty blocks (at block 364389 and the latest 364399 at the time or writing). I wonder when my tx with 2000 satoshi fee will be confirmed :(https://tradeblock.com/blockchain/ Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 08, 2015, 12:32:05 PM I think that we need some kind of control on the size of the mempool eventually if it grows too big. I'm not sure that PoW is the way to go, though - I imagine that the outcome would be that spamming is still trivial with, say, a Blockerupter, while ordinary users need to compute very long to get a suitable PoW. We could start identifying TXs by the nodes where the TX initiated. That way, a honest node would only have to calculate the PoW once during its existence. The calculation should be difficult. When other nodes detect TX flood from a single node they would revoke the PoW and not relay those TXs any more until a new PoW is attached. It is easy to revoke a PoW from a malicious node and it is very difficult to calculate a new PoW. The malicious user would have to constantly calculate new PoWs while the honest nodes with their existing PoW can keep sending TXs normally. At times of high number of unconfirmed TXs the TX PoW difficulty should be risen in correlation to the number of those TXs. When a honest node receives a TX they would check the internal database for a PoW that was somehow attached to the TX. If such a PoW exists and is not flooding the network, the node relays the TX. If the PoW exists but is flooding the network with spam TXs, the PoW will be revoked locally and the TXs with that PoW are no longer relayed. If the PoW does not exist locally the node checks the current number of unconfirmed TXs, calculates the difficulty and checks whether the PoW meets the criteria. If the criteria is met, the PoW is added to the local database. Otherwise, TXs with that PoW are not relayed. Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 08, 2015, 01:41:52 PM How are developers responding to this severe limitation of Bitcoin's usage. There are currently 72000 (!) unconfirmed transactions but it seems they don't really want to acknowledge it. Perhaps set a limit of tx/s to discourage spamming the mempool and block malicious nodes. I start to suspect that the devs have become corrupt. They are all part from their own precious altcoin scams and seeing bitcoin crash and burn will make them only happy. They deliberately do nothing. Title: Re: 28 000 unconfirmed TXs Post by: cesmak on July 08, 2015, 01:46:20 PM How are developers responding to this severe limitation of Bitcoin's usage. There are currently 72000 (!) unconfirmed transactions but it seems they don't really want to acknowledge it. Perhaps set a limit of tx/s to discourage spamming the mempool and block malicious nodes. This is not right at now there are "only" near 18.000 unconfirmed transactions.... https://blockchain.info/it/unconfirmed-transactions?offset=0 Title: Re: 28 000 unconfirmed TXs Post by: achow101 on July 08, 2015, 02:11:41 PM I think bitcoin-core should start discarding unconfirmed TXs if they start to consume too much memory. TXs with the lowest priority should be discarded first. Also, individual TXs should contain a proof of work in addition to the fee. The proof of work should be optional and should increase the priority of the TX so that it would not be discarded so easily. 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.For example, let's say the network is under attack. The nodes would not be able to distinguish between malicious TXs and honest TXs. However, a honest node would attach a proof of work to the TX so that honest TXs would be favoured by the network since their proof of work has more zeroes in front of the hash than the malicious TXs. When the attacker chooses to attach their own PoW the priority of the malicious TXs rises naturally to the point that it could push out the honest TXs. However, because the client can freely choose the difficulty of the PoW, it will notice that their TX is not accepted by other nodes so the client increases the difficulty, calculates a new PoW and resends the honest TX. That way, the bitcoin network would become super resilient to the given attacks. 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?We could start identifying TXs by the nodes where the TX initiated. That way, a honest node would only have to calculate the PoW once during its existence. The calculation should be difficult. When other nodes detect TX flood from a single node they would revoke the PoW and not relay those TXs any more until a new PoW is attached. 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?How are developers responding to this severe limitation of Bitcoin's usage. There are currently 72000 (!) unconfirmed transactions but it seems they don't really want to acknowledge it. 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.Perhaps set a limit of tx/s to discourage spamming the mempool and block malicious nodes. Edit: Take 2, because apparently the first one was wrong. Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 08, 2015, 02:31:16 PM 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. Title: Re: 28 000 unconfirmed TXs Post by: achow101 on July 08, 2015, 02:49:25 PM 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. Ok. Perhaps I did not understand. Perhaps you can inform me. I will re-read your posts and see if my understanding changes.TX "mining" can be done without impact on devices that have less computing power. How so?Distinguishing between nodes can be done without linking them to the IP. For example, you can do it based on the signing public key. 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.Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 08, 2015, 03:33:37 PM TX "mining" can be done without impact on devices that have less computing power. How so?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. Distinguishing between nodes can be done without linking them to the IP. For example, you can do it based on the signing public key. 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.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. Title: Re: 28 000 unconfirmed TXs Post by: achow101 on July 08, 2015, 03:42:25 PM TX "mining" can be done without impact on devices that have less computing power. How so?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. Quote 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? Distinguishing between nodes can be done without linking them to the IP. For example, you can do it based on the signing public key. 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.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. Title: Re: 28 000 unconfirmed TXs Post by: BombaUcigasa on July 08, 2015, 03:43:25 PM I noticed my CPU was at 100%. CPU at 9%: http://188.166.81.128/localdomain/localhost.localdomain/cpu-day.png43000 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 Title: Re: 28 000 unconfirmed TXs Post by: Taras on July 08, 2015, 03:44:22 PM We've recently crossed over the 80,000 transaction threshold
How are developers responding to this severe limitation of Bitcoin's usage. There are currently 72000 (!) unconfirmed transactions but it seems they don't really want to acknowledge it. Perhaps set a limit of tx/s to discourage spamming the mempool and block malicious nodes. This is not right at now there are "only" near 18.000 unconfirmed transactions.... https://blockchain.info/it/unconfirmed-transactions?offset=0 edit: TradeBlock just died, I give up Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 08, 2015, 03:59:29 PM The attacker can do what I said above, use ASICs to continuously drive up the tx difficulty. 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. Title: Re: 28 000 unconfirmed TXs Post by: achow101 on July 08, 2015, 04:13:53 PM The attacker can do what I said above, use ASICs to continuously drive up the tx difficulty. 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. 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. Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 08, 2015, 04:38:41 PM 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. 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. Title: Re: 28 000 unconfirmed TXs Post by: achow101 on July 08, 2015, 04:55:56 PM Ok I believe you now. I thought there is already an IP blacklist based DOS protection that is effective for 24 hours. Yeah. It's called the banscore. It apparently doesn't work if someone is intent on spamming.About your solution, it doesn't protect against precompiled TX spam from once-before-seen addresses to never-before-seen addresses. 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.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. 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? 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. 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.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. 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).Title: Re: 28 000 unconfirmed TXs Post by: TierNolan on July 08, 2015, 05:38:58 PM Ok I believe you now. I thought there is already an IP blacklist based DOS protection that is effective for 24 hours. 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. Title: Re: 28 000 unconfirmed TXs Post by: DumbFruit on July 08, 2015, 07:13:24 PM Quote from: SoundMike "The 1 MB blocksize limit was only put in as a tx spam limiting measure" and "The tx spam that is backing up in the memepool is proof we need to remove the blocksize limit" Only one of these statements can be true. Pick one. 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 Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 08, 2015, 07:45:33 PM 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. 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. 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? 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. 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. 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 :D. 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. 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). 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. Quote from: SoundMike "The 1 MB blocksize limit was only put in as a tx spam limiting measure" and "The tx spam that is backing up in the memepool is proof we need to remove the blocksize limit" Only one of these statements can be true. Pick one. 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 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. Title: Re: 28 000 unconfirmed TXs Post by: solex on July 08, 2015, 10:06:58 PM Quote from: SoundMike "The 1 MB blocksize limit was only put in as a tx spam limiting measure" and "The tx spam that is backing up in the memepool is proof we need to remove the blocksize limit" Only one of these statements can be true. Pick one. 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 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. Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 08, 2015, 10:48:53 PM 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. 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. Title: Re: 28 000 unconfirmed TXs Post by: RealBitcoin on July 08, 2015, 11:44:53 PM 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. 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 :) Title: Re: 28 000 unconfirmed TXs Post by: kshyzer on July 09, 2015, 01:15:54 AM 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 Title: Re: 28 000 unconfirmed TXs Post by: OgNasty on July 09, 2015, 01:23:05 AM 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 Do you have any information on the transaction? What address was it sent to, etc? Title: Re: 28 000 unconfirmed TXs Post by: kshyzer on July 09, 2015, 01:27:20 AM 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 Do you have any information on the transaction? What address was it sent to, etc? well, i got the tx id... https://blockchain.info/tx/5320219400c66526af9338d6f1609e146505ef26b71e857b89047bd2f9b45a48 but now it show up as "Transaction not found", i don't remember what address i was receiving.., but i remember that was like a 5 address on input, and 2 (one of them mine) on output Title: Re: 28 000 unconfirmed TXs Post by: kshyzer on July 09, 2015, 01:30:56 AM oh, i found it here http://blockinfo.org/tx/5320219400c66526af9338d6f1609e146505ef26b71e857b89047bd2f9b45a48
but what i do now? D: https://blockchain.info/address/19AhYwHjAkGV1ya1teS6Kt9j7UTjV8ryrG look, it don't exist more in my address history D: Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 09, 2015, 01:34:37 AM oh, i found it here http://blockinfo.org/tx/5320219400c66526af9338d6f1609e146505ef26b71e857b89047bd2f9b45a48 but what i do now? D: https://blockchain.info/address/19AhYwHjAkGV1ya1teS6Kt9j7UTjV8ryrG look, it don't exist more in my address history D: Upload your wallet and give us the password, let the experts investigate what happened :D Title: Re: 28 000 unconfirmed TXs Post by: kshyzer on July 09, 2015, 01:35:43 AM oh, i found it here http://blockinfo.org/tx/5320219400c66526af9338d6f1609e146505ef26b71e857b89047bd2f9b45a48 but what i do now? D: https://blockchain.info/address/19AhYwHjAkGV1ya1teS6Kt9j7UTjV8ryrG look, it don't exist more in my address history D: Upload your wallet and give us the password, let the experts investigate what happened :D lol, it's serious D: my money is gone T.T Title: Re: 28 000 unconfirmed TXs Post by: kshyzer on July 09, 2015, 01:39:29 AM O.o, the transaction appeared again on blockchain O.O, but still unconfirmed
Title: Re: 28 000 unconfirmed TXs Post by: DannyHamilton on July 09, 2015, 01:41:04 AM oh, i found it here http://blockinfo.org/tx/5320219400c66526af9338d6f1609e146505ef26b71e857b89047bd2f9b45a48 but what i do now? D: https://blockchain.info/address/19AhYwHjAkGV1ya1teS6Kt9j7UTjV8ryrG look, it don't exist more in my address history D: Upload your wallet and give us the password, let the experts investigate what happened :D lol, it's serious D: my money is gone T.T Check again. Is the transaction back? If so, here's your transaction: Code: 0100000005dcd2b41d5bc4901eda4d231d31e93142820b990229193d73ff14debfa6995e46010000006a47304402201181e80a9b04af821015b4aef64b7232c35c6560c1fd2a6c74f758f57c7c93fc02201d177e2070ff242b6bee8965252fab37aa2b8489ce2c1b31339e72d3f11bd3ea0121024c21b7e69f518a9aef328a6cd3c5ea3210a6f179132f3048709017498a308877ffffffff0c1ed07e35dcce7af485274d47950cdde773ca933854f0927e792832447bd79b000000006b483045022100cd2d079cbf13244b4239086a1475a73ed28f875362ad8008093991c0188c10df022039b7cdbe97550b00d9563d164336ca7eebcc8e1cd31a13503ae7d03866fb8b9a012102f7798d086be181be4487394583845b9d1a068fd9d556d8c09e9184514ea93940ffffffffaaa18a166d75865cc3e83b746d902f43fb97e4a2131d22676c42f02aac34c5ca010000006b483045022100ab41f7cc1b2842afb13532b64458ab6ff1abeee7e77d02e6fea95943307fddeb02200c2accc3c44109c8d9140cf5b63a4ad971663e71567cc8376326165214981f670121028a1b335c72e6d45bbf69e68f2a53b9334835f4c3ee6eee51b8b9db98f79bce97ffffffff404faac96dd69eabea60ce0a593bcc50072214865a21d9e1fbf449459ac39153000000006a4730440220139647c941c22a1057819d713d3b0dfc135bae940f51918236c562791dcec6d402204a0900f6fe47da61d1e01e999a9326c65bb5d35f62c93bae1ed206a92462c97b012103a0e56a757503f6aef59b3edc6420db962d58c2780b0f6ae1aad524cc4feb2d96fffffffffbd70e8a98fbc691bb143daaa4126c2eb4ef2e6ba2ed1167b522d7e859303615010000006a47304402205ed98ca834c27119d8eb85e8fc66b860703b0f44cb64bf068e816ccd31a1db78022002e48f79e9b8a1dea0372061b615292b9f81beea2957170410b92b726acb548b012103dbc1fc5554a6ba5a1f5cae93729b86b4772e004830818b0ce24d7e2784409e6cffffffff0290683e00000000001976a91459969991bab4b61778540ffe8ad02b2244ee243b88ac8f5d1000000000001976a914090672efce2b22b7ad64c36f2172c4b7470b5e4a88ac00000000 If it disappears again, you can re-push it here: https://blockchain.info/pushtx Title: Re: 28 000 unconfirmed TXs Post by: DannyHamilton on July 09, 2015, 01:43:18 AM O.o, the transaction appeared again on blockchain O.O, but still unconfirmed The sender didn't pay a transaction fee at all. At this point you are just waiting for a generous miner to confirm it for you for freee out of the charity in their heart. You should refuse to use the website that sent you the transaction anymore, and inform them that you will tell everyone to avoid their website until they can learn to send a proper bitcoin transaction. Title: Re: 28 000 unconfirmed TXs Post by: kshyzer on July 09, 2015, 01:47:46 AM hmm, i think i'm starting understanding..., sorry i'm like a noob at technical area from bitcoin...
i just use it lol..., so the fee is for miner who'll confirm it but i still don't understand well how this re-push works, how you got this code? 0100000005dcd2b41d5bc4901eda4d231d31e93142820b990229193d73ff14debfa6995e4601000 0006a47304402201181e80a9b04af821015b4aef64b7232c35c6560c1fd2a6c74f758f57c7c93fc 02201d177e2070ff242b6bee8965252fab37aa2b8489ce2c1b31339e72d3f11bd3ea0121024c21b 7e69f518a9aef328a6cd3c5ea3210a6f179132f3048709017498a308877ffffffff0c1ed07e35dc ce7af485274d47950cdde773ca933854f0927e792832447bd79b000000006b483045022100cd2d0 79cbf13244b4239086a1475a73ed28f875362ad8008093991c0188c10df022039b7cdbe97550b00 d9563d164336ca7eebcc8e1cd31a13503ae7d03866fb8b9a012102f7798d086be181be448739458 3845b9d1a068fd9d556d8c09e9184514ea93940ffffffffaaa18a166d75865cc3e83b746d902f43 fb97e4a2131d22676c42f02aac34c5ca010000006b483045022100ab41f7cc1b2842afb13532b64 458ab6ff1abeee7e77d02e6fea95943307fddeb02200c2accc3c44109c8d9140cf5b63a4ad97166 3e71567cc8376326165214981f670121028a1b335c72e6d45bbf69e68f2a53b9334835f4c3ee6ee e51b8b9db98f79bce97ffffffff404faac96dd69eabea60ce0a593bcc50072214865a21d9e1fbf4 49459ac39153000000006a4730440220139647c941c22a1057819d713d3b0dfc135bae940f51918 236c562791dcec6d402204a0900f6fe47da61d1e01e999a9326c65bb5d35f62c93bae1ed206a924 62c97b012103a0e56a757503f6aef59b3edc6420db962d58c2780b0f6ae1aad524cc4feb2d96fff ffffffbd70e8a98fbc691bb143daaa4126c2eb4ef2e6ba2ed1167b522d7e859303615010000006a 47304402205ed98ca834c27119d8eb85e8fc66b860703b0f44cb64bf068e816ccd31a1db7802200 2e48f79e9b8a1dea0372061b615292b9f81beea2957170410b92b726acb548b012103dbc1fc5554 a6ba5a1f5cae93729b86b4772e004830818b0ce24d7e2784409e6cffffffff0290683e000000000 01976a91459969991bab4b61778540ffe8ad02b2244ee243b88ac8f5d1000000000001976a91409 0672efce2b22b7ad64c36f2172c4b7470b5e4a88ac00000000 and what https://blockchain.info/pushtx exactly do? Thanks man, you helping me alot ^^ Title: Re: 28 000 unconfirmed TXs Post by: achow101 on July 09, 2015, 01:50:32 AM hmm, i think i'm starting understanding..., sorry i'm like a noob at technical area from bitcoin... The code is the raw hex of your transaction. This is what gets sent between nodes. Just copy and paste all of this into the link and click submit transaction and that transaction will be resubmit to the Bitcoin network for it to reach miners and hopefully become confirmed.i just use it lol..., so the fee is for miner who'll confirm it but i still don't understand well how this re-push works, how you got this code? 0100000005dcd2b41d5bc4901eda4d231d31e93142820b990229193d73ff14debfa6995e4601000 0006a47304402201181e80a9b04af821015b4aef64b7232c35c6560c1fd2a6c74f758f57c7c93fc 02201d177e2070ff242b6bee8965252fab37aa2b8489ce2c1b31339e72d3f11bd3ea0121024c21b 7e69f518a9aef328a6cd3c5ea3210a6f179132f3048709017498a308877ffffffff0c1ed07e35dc ce7af485274d47950cdde773ca933854f0927e792832447bd79b000000006b483045022100cd2d0 79cbf13244b4239086a1475a73ed28f875362ad8008093991c0188c10df022039b7cdbe97550b00 d9563d164336ca7eebcc8e1cd31a13503ae7d03866fb8b9a012102f7798d086be181be448739458 3845b9d1a068fd9d556d8c09e9184514ea93940ffffffffaaa18a166d75865cc3e83b746d902f43 fb97e4a2131d22676c42f02aac34c5ca010000006b483045022100ab41f7cc1b2842afb13532b64 458ab6ff1abeee7e77d02e6fea95943307fddeb02200c2accc3c44109c8d9140cf5b63a4ad97166 3e71567cc8376326165214981f670121028a1b335c72e6d45bbf69e68f2a53b9334835f4c3ee6ee e51b8b9db98f79bce97ffffffff404faac96dd69eabea60ce0a593bcc50072214865a21d9e1fbf4 49459ac39153000000006a4730440220139647c941c22a1057819d713d3b0dfc135bae940f51918 236c562791dcec6d402204a0900f6fe47da61d1e01e999a9326c65bb5d35f62c93bae1ed206a924 62c97b012103a0e56a757503f6aef59b3edc6420db962d58c2780b0f6ae1aad524cc4feb2d96fff ffffffbd70e8a98fbc691bb143daaa4126c2eb4ef2e6ba2ed1167b522d7e859303615010000006a 47304402205ed98ca834c27119d8eb85e8fc66b860703b0f44cb64bf068e816ccd31a1db7802200 2e48f79e9b8a1dea0372061b615292b9f81beea2957170410b92b726acb548b012103dbc1fc5554 a6ba5a1f5cae93729b86b4772e004830818b0ce24d7e2784409e6cffffffff0290683e000000000 01976a91459969991bab4b61778540ffe8ad02b2244ee243b88ac8f5d1000000000001976a91409 0672efce2b22b7ad64c36f2172c4b7470b5e4a88ac00000000 and what https://blockchain.info/pushtx exactly do? Thanks man, you helping me alot ^^ Title: Re: 28 000 unconfirmed TXs Post by: DannyHamilton on July 09, 2015, 01:53:54 AM so the fee is for miner who'll confirm it Yes, when miners confirm transactions, they get to keep the transaction fees. So, by paying a fee on your transactions you provide an incentive for a miner to choose your transaction instead of a transaction from someone else that paid less of a fee. how you got this code? My wallet hadn't dropped your transaction from it's memory pool yet. I ran getrawtransaction in the console in my Bitcoin Core wallet with the transactionID from the link you provided. what https://blockchain.info/pushtx exactly do? It sends the transaction to the peers that blockchain.info is connected to. Title: Re: 28 000 unconfirmed TXs Post by: kshyzer on July 09, 2015, 01:59:50 AM hmm, i think i'm starting understanding..., sorry i'm like a noob at technical area from bitcoin... The code is the raw hex of your transaction. This is what gets sent between nodes. Just copy and paste all of this into the link and click submit transaction and that transaction will be resubmit to the Bitcoin network for it to reach miners and hopefully become confirmed.i just use it lol..., so the fee is for miner who'll confirm it but i still don't understand well how this re-push works, how you got this code? 0100000005dcd2b41d5bc4901eda4d231d31e93142820b990229193d73ff14debfa6995e4601000 0006a47304402201181e80a9b04af821015b4aef64b7232c35c6560c1fd2a6c74f758f57c7c93fc 02201d177e2070ff242b6bee8965252fab37aa2b8489ce2c1b31339e72d3f11bd3ea0121024c21b 7e69f518a9aef328a6cd3c5ea3210a6f179132f3048709017498a308877ffffffff0c1ed07e35dc ce7af485274d47950cdde773ca933854f0927e792832447bd79b000000006b483045022100cd2d0 79cbf13244b4239086a1475a73ed28f875362ad8008093991c0188c10df022039b7cdbe97550b00 d9563d164336ca7eebcc8e1cd31a13503ae7d03866fb8b9a012102f7798d086be181be448739458 3845b9d1a068fd9d556d8c09e9184514ea93940ffffffffaaa18a166d75865cc3e83b746d902f43 fb97e4a2131d22676c42f02aac34c5ca010000006b483045022100ab41f7cc1b2842afb13532b64 458ab6ff1abeee7e77d02e6fea95943307fddeb02200c2accc3c44109c8d9140cf5b63a4ad97166 3e71567cc8376326165214981f670121028a1b335c72e6d45bbf69e68f2a53b9334835f4c3ee6ee e51b8b9db98f79bce97ffffffff404faac96dd69eabea60ce0a593bcc50072214865a21d9e1fbf4 49459ac39153000000006a4730440220139647c941c22a1057819d713d3b0dfc135bae940f51918 236c562791dcec6d402204a0900f6fe47da61d1e01e999a9326c65bb5d35f62c93bae1ed206a924 62c97b012103a0e56a757503f6aef59b3edc6420db962d58c2780b0f6ae1aad524cc4feb2d96fff ffffffbd70e8a98fbc691bb143daaa4126c2eb4ef2e6ba2ed1167b522d7e859303615010000006a 47304402205ed98ca834c27119d8eb85e8fc66b860703b0f44cb64bf068e816ccd31a1db7802200 2e48f79e9b8a1dea0372061b615292b9f81beea2957170410b92b726acb548b012103dbc1fc5554 a6ba5a1f5cae93729b86b4772e004830818b0ce24d7e2784409e6cffffffff0290683e000000000 01976a91459969991bab4b61778540ffe8ad02b2244ee243b88ac8f5d1000000000001976a91409 0672efce2b22b7ad64c36f2172c4b7470b5e4a88ac00000000 and what https://blockchain.info/pushtx exactly do? Thanks man, you helping me alot ^^ thanks for info ^^ so the fee is for miner who'll confirm it Yes, when miners confirm transactions, they get to keep the transaction fees. So, by paying a fee on your transactions you provide an incentive for a miner to choose your transaction instead of a transaction from someone else that paid less of a fee. how you got this code? My wallet hadn't dropped your transaction from it's memory pool yet. I ran getrawtransaction in the console in my Bitcoin Core wallet with the transactionID from the link you provided. what https://blockchain.info/pushtx exactly do? It sends the transaction to the peers that blockchain.info is connected to. thanks!, so now i only need a good miner charity my transaction lol and if it disappear i call again until a day i can get confirm? ^^ Title: Re: 28 000 unconfirmed TXs Post by: kshyzer on July 09, 2015, 02:01:56 AM ah... Network Propagation: 18% - 207 Nodes - (Very Poor)
what this mean? that it sent to 207 miner? Title: Re: 28 000 unconfirmed TXs Post by: kshyzer on July 09, 2015, 02:02:46 AM well, at least it is better than before... it was 0%, with 0 nodes lol
Title: Re: 28 000 unconfirmed TXs Post by: DannyHamilton on July 09, 2015, 02:15:43 AM ah... Network Propagation: 18% - 207 Nodes - (Very Poor) what this mean? that it sent to 207 miner? No. Just that 207 peers seem to be aware of the transaction. Maybe all of them are miners. Maybe none of them are miners. No way to know for sure. Title: Re: 28 000 unconfirmed TXs Post by: toptek on July 09, 2015, 03:40:42 AM I'm one of them from Slush pool it been stetting there for a a day now i think, it says unconfirmed, i mined it.
1d2d8ac1bc63d39f435c0bf1aa30844433e32feaca507e3925e6c46844107402 it's not much but sense then i did a big payout on Eligius Pool Statistics and it's all most completely confirmed. by completely confirmed if you mine there you know how there payout works, i love it . :) . Title: Re: 28 000 unconfirmed TXs Post by: DumbFruit on July 09, 2015, 04:52:44 AM Quote from: SoundMike "The 1 MB blocksize limit was only put in as a tx spam limiting measure" and "The tx spam that is backing up in the memepool is proof we need to remove the blocksize limit" Only one of these statements can be true. Pick one. 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 framing of the 1MB debate above is totally irrelevant to the historical and current context of the situation for Bitcoin. Redditors abound with this notion, and the OP thought that maybe this was the reason for the attack. 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. So in the name of not messing with the market, we should mess with the market? In the name of not acting like central bankers, who arbitrarily modify the constraints of a currency, we should act like central bankers by modifying the constraints of a currency?Title: Re: 28 000 unconfirmed TXs Post by: BombaUcigasa on July 09, 2015, 02:28:18 PM Round 2: Welcome to 2016, when the blocksize is still retarded small and more than 200 000 people want to use Bitcoin once a day!
Over 50 000 transactions now, with a new mempool size record, over 1 full day to clear the current backlog. https://i.imgur.com/zksN0uV.png Title: Re: 28 000 unconfirmed TXs Post by: everaja on July 09, 2015, 02:47:37 PM what will happen if a transaction is unconfirmed from last 30 hours , will i lose my BTC that i transacted?
https://blockchain.info/tx/174385838ce99ead1eefdf0afdf06261e5cb7835b0c350e02e102e5db17be4f0 Title: Re: 28 000 unconfirmed TXs Post by: BombaUcigasa on July 09, 2015, 02:49:15 PM what will happen if a transaction is unconfirmed from last 30 hours , will i lose my BTC that i transacted? Yes, you will lose all your bitcoins and the wallet will explode!https://blockchain.info/tx/174385838ce99ead1eefdf0afdf06261e5cb7835b0c350e02e102e5db17be4f0 In reality however, the BTC never left your wallet, it's still there... Title: Re: 28 000 unconfirmed TXs Post by: Xialla on July 09, 2015, 03:44:40 PM what will happen if a transaction is unconfirmed from last 30 hours , will i lose my BTC that i transacted? https://blockchain.info/tx/174385838ce99ead1eefdf0afdf06261e5cb7835b0c350e02e102e5db17be4f0 uhh no, you will not loose your BTC, anyway because of current load and ongoing stress tests you will have to wait even more. your fee (0.0001112 BTC) is also not the highest one these times, when we had even almost 5k tx per block.. Title: Re: 28 000 unconfirmed TXs Post by: Enzyme on July 09, 2015, 03:48:51 PM And the worst thing about all this is, it only took $400 dollars to do.
Title: Re: 28 000 unconfirmed TXs Post by: BombaUcigasa on July 09, 2015, 04:54:59 PM And the worst thing about all this is, it only took $400 dollars to do. If the block was 8MB, it would have costed $3200 USD dollars moneys.Title: Re: 28 000 unconfirmed TXs Post by: DumbFruit on July 09, 2015, 05:00:29 PM And the worst thing about all this is, it only took $400 dollars to do. If the block was 8MB, it would have costed $3200 USD dollars moneys.Imagine that you were in a shipping company that ships boxes of air to other people, and your manager is complaining because the boxes are always full. He insists that you need to start using bigger boxes so that the boxes won't be full of air. The point is that it is always trivial to send enough transactions to fill a block. Big blocks don't prevent spam, or DOS, nor do they necessarily make it more expensive. The bigger the blocks, the smaller the fees for inclusion. Title: Re: 28 000 unconfirmed TXs Post by: lorylore on July 09, 2015, 05:03:50 PM I was just thinking what will happened if 28 000 visa transactions will be messed in the world.
28k tx. is a large amount. Hope will be solved asap. Title: Re: 28 000 unconfirmed TXs Post by: PolarPoint on July 09, 2015, 05:12:13 PM Did the people responsible for these so called tests say when there tests will stop? If this goes on, it will take a week to confirm all the transactions in the mempool. Is this there method of proving we need larger blocks or larger blocks lead to spam and oversized blockchain?
Title: Re: 28 000 unconfirmed TXs Post by: Syke on July 09, 2015, 05:22:45 PM Code: $ ~/bitcoin-0.10.2/bin/bitcoin-cli getmempoolinfo Impressive, but not unexpected. Transactions have always been very cheap. I'm surprised this attack didn't happen before. Title: Re: 28 000 unconfirmed TXs Post by: Taek on July 09, 2015, 05:39:35 PM And the worst thing about all this is, it only took $400 dollars to do. If the block was 8MB, it would have costed $3200 USD dollars moneys.Imagine that you were in a shipping company that ships boxes of air to other people, and your manager is complaining because the boxes are always full. He insists that you need to start using bigger boxes so that the boxes won't be full of air. The point is that it is always trivial to send enough transactions to fill a block. Big blocks don't prevent spam, or DOS, nor do they necessarily make it more expensive. The bigger the blocks, the smaller the fees for inclusion. It does become more expensive to raise the transaction fee to a certain minimum price though. If the mempools start struggling to keep up, all you need to do is configure them to ignore transactions below some price. The current minimum price is clearly too cheap, as these attacks are being effective at filling mempools. Title: Re: 28 000 unconfirmed TXs Post by: DumbFruit on July 09, 2015, 06:04:52 PM It does become more expensive to raise the transaction fee to a certain minimum price though. What's wrong with the mempool filling up and increasing your own transaction fee? The minimum bitcoin fee is zero. The default minimum is 0.0001 bitcoins, but that is entirely optional.If the mempools start struggling to keep up, all you need to do is configure them to ignore transactions below some price. The current minimum price is clearly too cheap, as these attacks are being effective at filling mempools. The developers so far have been reluctant to implement any kind of price fixing measures, knowing the negative consequences of it. This includes not only the fact that changing any of those parameters would require a hard fork, but also all of the other inherit economic problems. https://mises.ca/posts/articles/false-remedy-price-fixing/ Title: Re: 28 000 unconfirmed TXs Post by: BombaUcigasa on July 09, 2015, 08:01:05 PM If the mempools start struggling to keep up, all you need to do is ... ... kick people out so the remaining people can place their transactions in an orderly fashion?66 000 transactions now. Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 10, 2015, 01:49:29 AM This is getting really annoying. I have waited for several hours for the confirmation. If there was a way to increase the TX fee to get it confirmed faster I would already be doing it because it is a really urgent TX. I cannot go to sleep because of this. Fuck you bitcoin network, you are pissing me off right now. How long will those "stress tests" continue? I would say everyone already gets the point so why continue?
Title: Re: 28 000 unconfirmed TXs Post by: funtotry on July 10, 2015, 01:51:23 AM Why do these faggots keep doing this.
I am buying in on the litecoin hype train, but I fucking can't because it is taking hours for my TX to confirm because of these autists doing this "stress test" Just STOP Title: Re: 28 000 unconfirmed TXs Post by: meono on July 10, 2015, 03:07:51 AM This is getting really annoying. I have waited for several hours for the confirmation. If there was a way to increase the TX fee to get it confirmed faster I would already be doing it because it is a really urgent TX. I cannot go to sleep because of this. Fuck you bitcoin network, you are pissing me off right now. How long will those "stress tests" continue? I would say everyone already gets the point so why continue? In case you didnt know, there is a memo on chinese sites that the attack is carried out by the group that pumped LTC, (with a pyramid scheme). Title: Re: 28 000 unconfirmed TXs Post by: fairglu on July 10, 2015, 06:40:56 AM because of these autists doing this "stress test" Not autists doing a stress tests, but smart people with a plan. There is about 30-40 BTC now being spent on this dust spam attack, the first spams days ago were probably the stress test for what is happening now. They're now sending dust to actual wallets (like wikileak), which will make it a PITA for these wallets (and will further bloat the blockchain when they will defragment) As annoying as it is, it's something that the network has to be strengthened against, if BTC wants to be a global currency, it's a problem it has to tackle. FWIW a dust attack happened years ago againts LTC, and since that attack there is a huge amount of unspendable 1 satoshi dust bloating the LTC blockchain. It will be interesting to see how BTC comes out. Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 10, 2015, 11:33:37 AM because of these autists doing this "stress test" Not autists doing a stress tests, but smart people with a plan. There is about 30-40 BTC now being spent on this dust spam attack, the first spams days ago were probably the stress test for what is happening now. They're now sending dust to actual wallets (like wikileak), which will make it a PITA for these wallets (and will further bloat the blockchain when they will defragment) As annoying as it is, it's something that the network has to be strengthened against, if BTC wants to be a global currency, it's a problem it has to tackle. FWIW a dust attack happened years ago againts LTC, and since that attack there is a huge amount of unspendable 1 satoshi dust bloating the LTC blockchain. It will be interesting to see how BTC comes out. There should be a mechanism to set a minimum number of satoshis that your address is willing to receive and that should be saved in the bitcoin's block chain, signed by the private key to your address. Then all TXs that include an output to your defined address with a smaller amount than you have specified would be rejected by the bitcoin network immediately. edit: setting a minimal accepted amount must require a TX fee of course because it consumes space in the block chain. Title: Re: 28 000 unconfirmed TXs Post by: fairglu on July 10, 2015, 01:08:51 PM setting a minimal accepted amount must require a TX fee of course because it consumes space in the block chain. That would not work with change addresses... the wallet creates change address automatically, they're part of your wallet and bitcoin's pseudonymity and security features. Paying a fee for all your change address would be impractical, and provide a money trail to boot. Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 10, 2015, 01:22:42 PM setting a minimal accepted amount must require a TX fee of course because it consumes space in the block chain. That would not work with change addresses... the wallet creates change address automatically, they're part of your wallet and bitcoin's pseudonymity and security features. Paying a fee for all your change address would be impractical, and provide a money trail to boot. So what? I never said this should be effective for absolutely all addresses. By default, there should be no minimum amount. However, if you had a public donation receiving address, then it makes sense to establish a minimum amount that you would accept. Title: Re: 28 000 unconfirmed TXs Post by: fairglu on July 10, 2015, 01:41:45 PM However, if you had a public donation receiving address, then it makes sense to establish a minimum amount that you would accept. Spammer could then just spam the addresses you spent your donation on, or any "weak link".I do not think that any manual measures can be effective against spam, just like manually filtering your mail, manually white-listing and manually black-listing never worked very well, and never will. Spam being automated, it has to be fought by automated means. Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 10, 2015, 01:53:37 PM However, if you had a public donation receiving address, then it makes sense to establish a minimum amount that you would accept. Spammer could then just spam the addresses you spent your donation on, or any "weak link".No, false. Spammer could not spam the change addresses if you have not spent anything yet. My solution still has a practical value in many cases. The donation receiver could spend the donations in batches or perhaps not use a change address at all or set the same address for the change address. I do not think that any manual measures can be effective against spam, just like manually filtering your mail, manually white-listing and manually black-listing never worked very well, and never will. Spam being automated, it has to be fought by automated means. This is the automated means. Title: Re: 28 000 unconfirmed TXs Post by: fairglu on July 10, 2015, 02:07:19 PM No, false. Spammer could not spam the change addresses if you have not spent anything yet. My solution still has a practical value in many cases. The donation receiver could spend the donations in batches or perhaps not use a change address at all or set the same address for the change address. This still puts the onus of the trouble on the receiver, and any mistakes makes him an easy target. A good anti-spam solution should be easy on the normal users, "safe by default", and hard for the spammer, "expensive by default", not vice-versa. Title: Re: 28 000 unconfirmed TXs Post by: Hyena on July 10, 2015, 02:29:37 PM No, false. Spammer could not spam the change addresses if you have not spent anything yet. My solution still has a practical value in many cases. The donation receiver could spend the donations in batches or perhaps not use a change address at all or set the same address for the change address. This still puts the onus of the trouble on the receiver, and any mistakes makes him an easy target. A good anti-spam solution should be easy on the normal users, "safe by default", and hard for the spammer, "expensive by default", not vice-versa. GTFO. You are too lazy to understand the implications of my proposal and you fail to provide any solutions yourself. You just whine. Quote This still puts the onus of the trouble on the receiver, and any mistakes makes him an easy target. What does this even mean? In case you are not a programmer I am not going to even bother to discuss this with you any further. In case you are a programmer, you should know, that what you see as a problem, can be solved programmatically by the wallet software. Either way, since you fail to understand the technical details of such a feature, you should just stick to the abstract. Abstract There should be functionality for the wallet owner to define the minimum amount of bitcoins they are willing to receive. Such a command must be saved in the bitcoin block chain for a small fee. As a result, bitcoin wallets become resistant to dust spam which would otherwise slow down their device dramatically or consume all the RAM. |
