Enjoy?

[dyask]

It is interfering with normal transactions.   Maybe not everywhere but at least some operations.  

No it does not. Please educate yourself before posting nonsense.
These transactions will most likely never be confirmed anyways. They have no impact on the network.

Why do you assume everywhere is running the same software?   That isn't the case.   I had to have a wallet manually updated because the software couldn't accept a deposit while there were unconfirmed transactions.    Of coarse that is a software problem, but this has shown up at two different places I know of, which means there are like a lot more.

Should the software handle it?  Of course, but it takes time to update software and there are always risks.    

Technically the problem is at the edge of the network, not the network itself.  Functionally though it impacts the use of the network.   Over time the problems will be fixed.  

 

[Automatic]

It is interfering with normal transactions.   Maybe not everywhere but at least some operations.  

No it does not. Please educate yourself before posting nonsense.
These transactions will most likely never be confirmed anyways. They have no impact on the network.

I think what he's saying is:-

His client is using the MIN_OUTPUT size out (From 1Enjoy and any other addresses doing this), and, is using it as an input. As his transaction relies on the transaction that'll never be confirmed, his transaction also won't be confirmed.

[dyask]

Dusting is just creating a lot of very small transactions.   It wastes space in the block chain with these dust transactions that still take up room.   I'm not clear on all the applications of it.   There are some theories on how it could be used to help track a wallet back to an IP.

Wrong theories aren't worth much.  Transactions aren't sent to a particular address, there is nothing to trace.

Another use might be to try to build a list of valid address.   In theory one could generate private keys and see if they match any of the list of known wallets.   If you get a hit you have a valid private key.   That approach is unlikely to work, but it doesn't stop someone from trying.

Um there is thing called the blockchain which already contains every valid address that has received bitcoins.  For an "attacker" to send you a satoshi they would already by definition need to know your address and know it is valid.   

Bitcoin private keys can't be brute forced.  There isn't enough energy in our solar system.   If they could then someone sending you a satoshi is the least of your worries. 

Hmmm, you are assuming there isn't an undiscovered weakness in the code.   Anyway I clearly said is was unlikely to work.   That doesn't stop someone from trying.   

[Lauda]

Why do you assume everywhere is running the same software?   That isn't the case.   I had to have a wallet manually updated because the software couldn't accept a deposit while there were unconfirmed transactions.    Of coarse that is a software problem, but this has shown up at two different places I know of, which means there are like a lot more.
Should the software handle it?  Of course, but it takes time to update software and there are always risks.    
Technically the problem is at the edge of the network, not the network itself.  Functionally though it impacts the use of the network.   Over time the problems will be fixed.    

That is a problem of your software (and whoever made it). If it does have an effect on it, that does not mean it has one of the network or default client.

That would be a pretty stupid fault in the network, using common sense one must realize that this is not the case.
90-95% users here now lack a fair amount of knowledge, I don't even wanna begin imagining how they see the complex stuff..

+1 for you. And well, here is an example on how they treat complex stuff. It's not that complex, but oh well. Someone states that nLockTime is used for Reverse Transactions. I could be wrong about my statement, but I highly doubt it since I used it to create LockMyCoins (which is currently being redone).

Yeah I've read that topic. I just don't understand these people. I will openly say that I currently do not know what nLockTime is used for, but I do not post about it claiming random nonsense when I lack the knowledge. That seems the problem in many people. You're most likely correct on the matter.

[HostFat]

Look at the last merges, devs are already fixing the malleability problem
http://www.reddit.com/r/Bitcoin/comments/1xniph/look_at_the_last_merges_devs_are_already_fixing/

[Mitchell]

Yeah I've read that topic. I just don't understand these people. I will openly say that I currently do not know what nLockTime is used for, but I do not post about it claiming random nonsense when I lack the knowledge. That seems the problem in many people. You're most likely correct on the matter.

It's easy. It prevents a transaction from being accepted into the Blockchain before a certain timestamp or block is reached. That is the basic explanation of nLockTime. Nothing more, nothing less.

[dyask]

Why do you assume everywhere is running the same software?   That isn't the case.   I had to have a wallet manually updated because the software couldn't accept a deposit while there were unconfirmed transactions.    Of coarse that is a software problem, but this has shown up at two different places I know of, which means there are like a lot more.
Should the software handle it?  Of course, but it takes time to update software and there are always risks.    
Technically the problem is at the edge of the network, not the network itself.  Functionally though it impacts the use of the network.   Over time the problems will be fixed.    

That is a problem of your software (and whoever made it). If it does have an effect on it, that does not mean it has one of the network or default client.

WRONG - It wasn't my software, it was software at a vendor I was trying to use.   So far we know of two different places where this was a problem including the blockchain.info sweep function.   There are likely many more we don't know about.   For most people this makes up what is perceived to be the bitcoin network.   It doesn't matter that it is outside the network for the average person.  

Brushing off this a problem in other people's software is a lame approach.   The simple fact is that these are not valid transactions and should be in the blockchain in the first place.   Granted it is easy to manually work around.   However, if bitcoin is going to go mainstream we really can't afford to have nonsense issues like this.    

How many places are transactions blocked because software is waiting for there be no unconfirmed transactions for a public address?

[HostFat]

https://bitcoinfoundation.org/blog/?m=201402

Gavin Andresen    Feb 12 2014

You may have noticed that some exchanges have temporarily suspended withdrawals and wondering what’s going on or more importantly, what’s being done about it. You can be rest assured that we have identified the issue and are collectively and collaboratively working on a solution.
 
Somebody (or several somebodies) is taking advantage of the transaction malleability issue and relaying mutated versions of transactions. This is exposing bugs in both the reference implementation and some exchange’s software.
 
We (core dev team, developers at the exchanges, and even big mining pools) are creating workarounds and fixes right now. This is a denial-of-service attack; whoever is doing this is not stealing coins, but is succeeding in preventing some transactions from confirming. It’s important to note that DoS attacks do not affect people’s bitcoin wallets or funds.
 
Users of the reference implementation who are bitten by this bug may see their bitcoins “tied up” in unconfirmed transactions; we need to update the software to fix that bug, so when they upgrade those coins are returned to the wallet and are available to spend again. Only users who make multiple transactions in a short period of time will be affected.
 
As a result, exchanges are temporarily suspending withdrawals to protect customer funds and prevent funds from being misdirected.
 
Thanks for your patience. Follow us @BTCFoundation for updates as we learn more and make progress.

[Lauda]

That is a problem of your software (and whoever made it).

WRONG - It wasn't my software, it was software at a vendor I was trying to use.   So far we know of two different places where this was a problem including the blockchain.info sweep function.   There are likely many more we don't know about.   For most people this makes up what is perceived to be the bitcoin network.   It doesn't matter that it is outside the network for the average person.  

The author of the software. His problem. It is getting fixed anyways, it wasn't a priority issue.

It's easy. It prevents a transaction from being accepted into the Blockchain before a certain timestamp or block is reached. That is the basic explanation of nLockTime. Nothing more, nothing less.

Thanks for that simple explanation. Yet some people don't understand that.

[Mitchell]

Thanks for that simple explanation. Yet some people don't understand that.

That's life

[dyask]

That is a problem of your software (and whoever made it).

WRONG - It wasn't my software, it was software at a vendor I was trying to use.   So far we know of two different places where this was a problem including the blockchain.info sweep function.   There are likely many more we don't know about.   For most people this makes up what is perceived to be the bitcoin network.   It doesn't matter that it is outside the network for the average person.  

The author of the software. His problem. It is getting fixed anyways, it wasn't a priority issue.

The point is that as Bitcoin goes mainstream, it can't afford to have these types of issues.  Things need to work smoothly all the time for Bitcoin to succeed.   Granted that in the scheme of current events this is a minor issue.    

[Lauda]

Thanks for that simple explanation. Yet some people don't understand that.

That's life

Bitcointalk > life, in this case. It is much worse here.  

[Mitchell]

Thanks for that simple explanation. Yet some people don't understand that.

That's life

Bitcointalk > life, in this case. It is much worse here. 

Well, that's true. But oh well, we have been off-topic for to long now, haha. If you want to continue our little chat (which I enjoyed greatly) you can always send me a PM

[DeathAndTaxes]

I also thought also about b). If you know that Blockchain.info relays spam, why relay the tx to all nodes yourself.

Well I don't know for sure if it the attacker has a direct connection OR if blockchain.info is relaying these non-standard transactions.  Without being on the receiving end of a spam attack I can't see where it is coming from.

Just putting both out as a possibility.  The attack may be doing all this on his own, or he may be just relaying them to blockchain.info knowing it will do the relaying for him, or he may be relaying them in additional to blockchain.info to increase the "coverage".  The relaying will stop when it hits a reference client so having multiple super nodes "helping" means it will reach more nodes.

Reference Implementation doesn't not relay non-standard tx but doesn't ignore them either if they belong to your own wallet.

Yes that is a good way to put it.  If you are running the QT client you aren't helping the spammer but if you got spammed it is going to show up.

and will not show up in your wallet until they are included in a block.

This is only true if no one relays the tx to you.

Correct but the reference client (and other clients which enforce the same rules) make up a super majority of the bitcoin nodes.  Unless the attacker or some other custom super node (possibly blockchain.info) has a direct connection to you it is very likely all of your peers will drop these transactions and never rely them to you.

For example, maybe I was spammed and just don't know it because all my direct peers are nodes running the reference client (or one with similar relay rules).

[btcash]

If you are running the QT client you aren't helping the spammer but if you got spammed it is going to show up.

This should be changed. Right now users can be spammed with thousands of TXs. I am sure having a few hundred TXs in your History that you can't spend sucks. Sure you can prune them with pywallet but 90% of the users won't don't that. Especially mobile users.

[DeathAndTaxes]

If you are running the QT client you aren't helping the spammer but if you got spammed it is going to show up.

This should be changed. Right now users can be spammed with thousands of TXs. I am sure having a few hundred TXs in your History that you can't spend sucks. Sure you can prune them with pywallet but 90% of the users won't don't that. Especially mobile users.

How would you propose changing it?  I guess optionally you could hide transactions below a certain threshold (possibly the same limit as they will be uneconomical to spend anyways), but you can "undo" Bitcoin transactions even ones you don't "want".

[apsvinet]

I wouldn't complain if someone gave me free stuff.. Seriously tho, I can't really see anything to worry about.

[DPoS]

Look at the last merges, devs are already fixing the malleability problem
http://www.reddit.com/r/Bitcoin/comments/1xniph/look_at_the_last_merges_devs_are_already_fixing/

funny that they had to get attacked before they lifted a finger...  snotty asses

[btcash]

How would you propose changing it?  I guess optionally you could hide transactions below a certain threshold (possibly the same limit as they will be uneconomical to spend anyways), but you can "undo" Bitcoin transactions even ones you don't "want".

There is one other relevant rule: transactions with very small outputs ("dust" -- around 5,000 satoshis, based on the -minrelaytxfee setting) are considered non-standard and are not relayed.

Simple ignore all non-standard TXs, regardless if they belong to your wallet. Litecoin already has a dust hard limit. All inputs smaller 0.00001 are ignored by the client.
Sure you can remove the spam from your wallet, but implementing a new rule would discourage spam like this.

I wouldn't complain if someone gave me free stuff.. Seriously tho, I can't really see anything to worry about.

You are not able to spend the "free stuff" (unless a miner includes this spam into a block, which I doubt). It is just there the bloat your wallet and history.

[dyask]

I wouldn't complain if someone gave me free stuff.. Seriously tho, I can't really see anything to worry about.

That stupid 1 Satoshi spam may have cost me .05 BTC.  It isn't much money but it has at least cost others LOTS of wasted time.  Anytime someone is stealing your time it isn't free.

A wallet I was working with a vendor with got spammed.  Their software won't transfer from a wallet with unconfirmed transactions.   Since it was their wallet I'm at their mercy to manually transfer the funds because the connection between that wallet and my account was broken.  

You can keep your free stuff!