well bitcoin is decentralized and has clear rules about which transactions are valid and these rules are being abused. you can call it Delayed Proof-of-Work or Stress test or Political crap about block size or even it is the protocol and I like sending those transactions and in all cases the transactions are clogging the network causing a huge memory pool which the current block size without activation of any of the proposals can not handle.
and then it causes the fee war and users having to wait hours for their transactions to be confirmed.
you can right now make a small program and make 100,000 requests per second to bitcointalk.org and you aren't doing anything wrong TCP protocol allows you to make these requests but you are just DDoS attacking bitcointalk.org and making it inaccessible to other users.
What makes one users transactions "legitimate" and another users transactions not? They are valid tx's according the protocol, so obviously they can be sent. Looking at it from a "legitimate use" point of view, the transactions serve a purpose and aren't just created for no reason at all as in a spam attack.
next time try reading the comment first and then come up with a better answer instead of just saying something to have said it.
I have been careful about my choice of words. I clearly said the rules are being
abused, if you don't know what abuse means check a dictionary, it doesn't mean illegitimate.
I am very curious to know what rules are being abused.
I designed the dPoW notarization tx to minimize the size on the blockchain. If multisig could even have been used for an Mof64 tx, it would be 2 to 3 times larger.
i saw one tx that was a silly 50 utxo input to a 50 utxo output which was caused by this very spam attack that prevented funds from arriving to that wallet in time, so it had to use all the utxo to fund the inputs. If blocks are normal, then it would have been a single input (which was in transit) and 50 outputs. These 50 outputs use the fully dereferenced pay to pubkey script so it does not have to include the pubkey in the vin script that spends it. That saves the 20 bytes of rmd160 hash that otherwise would be there, not to mention the few extra bytes from script opcodes.
We are paying about 25 sats per byte to not interfere with the normal wallet default of 50 sats, so it is running at a lower priority and not pricing out other transations. It sounds like you would prefer we pay higher prices, which would fractionally price other transactions out. We just might have to if the current spam attack is a permanent state of affairs.
It sounds to me that you consider any usage of bitcoin that isnt officially sanctioned by the QT wallet to be an abuse. Do I have that right?
I followed the protocol. I designed the minimal space using solution that achieves Mof64 functionality. If that is abuse, then it seems to me any usage of bitcoin is abuse unless the central transaction approval committee officially provides a license to utilize such transactions.
Who is on this committee?
