Why Komodo Group-Signed Transactions are Not Spam

[Pursuer]

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.

argument with you guys is pointless, I am sorry I even tried!

[1714803265]

1714803265

[PondSea]

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.

Can you please provide where in the white paper abuse is defined?

[jl777]

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?

[Holliday]

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?

Wait. In the same post where you are defending your transactions from being labeled as spam, you label other transactions spam and mention an attack. I'm not sure if I follow the logic. Could you elaborate?

I'm genuinely trying to understand the entire situation.

[jl777]

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?

Wait. In the same post where you are defending your transactions from being labeled as spam, you label other transactions spam and mention an attack. I'm not sure if I follow the logic. Could you elaborate?

I'm genuinely trying to understand the entire situation.

Good point. rephrase my usage of "spam attack" to "time period where the mempool has a lot of unconfirmed transactions"

I doubt whoever is responsible for the recent spike in transactions has taken the effort that we have to reduce the impact of dPoW transactions, and in fact they could well have designed their transactions to use up as much of the mempool as possible.

[e-coinomist]

expected bitcoin blocks every day: 144
average bitcoin blocks vary every day: 100+ ??
komodo notary nodes: 64
Each notary node group signs a raw bitcoin transaction.
Total transactions sent per bitcoin block: 1
Total transactions sent per day approx: 100+ ??
Fee paid per block transaction: 0.00031200 BTC
Total approx fee paid per day if 100 is taken as value for each day bitcoin blocks mined: 0.00031200 * 100 = 0.03120000 BTC
As of now, 1 Day's blockchain Mempool Transaction Count Size: 33,599
33,599 Mempool Transaction Count size - 100 Komodo Notary Transaction = 33,499

Komodo pays 0.03120000 BTC for notary services a day? Thirty bucks. Well in comparison to other altcoin's needs for keeping their blockchain save from tampering that is a true bargain.
Could cause trouble if some other 200~300 altcoins discover the possibility. At that point in time maybe a "NotaryCoin" as an intermediate between the blockchain and all alts with notary demands would make sense. Oh, wait! There allready is NameCoin.

Just got that feeling NameCoin would have been the better choice for your needs.

Dont know if this thread belongs into the politics or into the altcoin sections.

[Holliday]

Good point. rephrase my usage of "spam attack" to "time period where the mempool has a lot of unconfirmed transactions"

I doubt whoever is responsible for the recent spike in transactions has taken the effort that we have to reduce the impact of dPoW transactions, and in fact they could well have designed their transactions to use up as much of the mempool as possible.

Fair enough.

I guess the thing on everyone's mind (or at least my mind) here is what is happening during the times outlined with the green circles.



From what has been stated in this thread from the people with knowledge of Komodo, is that Komodo transactions aren't causing the spikes in the green circles. Can you say with confidence that Komodo transactions are happening with the same frequency during the times circled in red as the times circled in green? If so, then I'd say the title of this thread is appropriate.

Obviously, something is happening during these massive spikes and I think most people involved with Bitcoin would like to know what it is (hence this thread). Many people claim it's simply "normal use" but I'm just not buying that.

[KomodoPlatform]

Komodo pays 0.03120000 BTC for notary services a day? Thirty bucks. Well in comparison to other altcoin's needs for keeping their blockchain save from tampering that is a true bargain.
Could cause trouble if some other 200~300 altcoins discover the possibility. At that point in time maybe a "NotaryCoin" as an intermediate between the blockchain and all alts with notary demands would make sense. Oh, wait! There allready is NameCoin.

Just got that feeling NameCoin would have been the better choice for your needs.

Dont know if this thread belongs into the politics or into the altcoin sections.

This is indeed one of our goals, to give the Bitcoin protection to other altcoins too!

Instead of using Bitcoin blockchain (like we do) they can use Komodo blockchain, and achieve the same result but a lot cheaper. This further increases the utility of Bitcoin network and its hashing power.

Altcoins benefit, bitcoin plays a bigger role... the whole crypto benefits.

[TooDumbForBitcoin]

Good point. rephrase my usage of "spam attack" to "time period where the mempool has a lot of unconfirmed transactions"

I doubt whoever is responsible for the recent spike in transactions has taken the effort that we have to reduce the impact of dPoW transactions, and in fact they could well have designed their transactions to use up as much of the mempool as possible.

Fair enough.

I guess the thing on everyone's mind (or at least my mind) here is what is happening during the times outlined with the green circles.



From what has been stated in this thread from the people with knowledge of Komodo, is that Komodo transactions aren't causing the spikes in the green circles. Can you say with confidence that Komodo transactions are happening with the same frequency during the times circled in red as the times circled in green? If so, then I'd say the title of this thread is appropriate.

Obviously, something is happening during these massive spikes and I think most people involved with Bitcoin would like to know what it is (hence this thread). Many people claim it's simply "normal use" but I'm just not buying that.

Your description of the green circles as spikes would be more accurate if they didn't occupy more than half the horizontal axis in your figure.

[jl777]

Good point. rephrase my usage of "spam attack" to "time period where the mempool has a lot of unconfirmed transactions"

I doubt whoever is responsible for the recent spike in transactions has taken the effort that we have to reduce the impact of dPoW transactions, and in fact they could well have designed their transactions to use up as much of the mempool as possible.

Fair enough.

I guess the thing on everyone's mind (or at least my mind) here is what is happening during the times outlined with the green circles.



From what has been stated in this thread from the people with knowledge of Komodo, is that Komodo transactions aren't causing the spikes in the green circles. Can you say with confidence that Komodo transactions are happening with the same frequency during the times circled in red as the times circled in green? If so, then I'd say the title of this thread is appropriate.

Obviously, something is happening during these massive spikes and I think most people involved with Bitcoin would like to know what it is (hence this thread). Many people claim it's simply "normal use" but I'm just not buying that.

what is happening is that during the spikes komodo transactions are reduced due to nodes running out of usable utxo.

and the max rate is about 100 per day, can never be much more than that
so there is no way it is adding tens of thousands of tx in hours

komodo is a responsible user of the bitcoin blockchain and we can taken great efforts to minimize the blockchain usage.

[PondSea]

Good point. rephrase my usage of "spam attack" to "time period where the mempool has a lot of unconfirmed transactions"

I doubt whoever is responsible for the recent spike in transactions has taken the effort that we have to reduce the impact of dPoW transactions, and in fact they could well have designed their transactions to use up as much of the mempool as possible.

Fair enough.

I guess the thing on everyone's mind (or at least my mind) here is what is happening during the times outlined with the green circles.



From what has been stated in this thread from the people with knowledge of Komodo, is that Komodo transactions aren't causing the spikes in the green circles. Can you say with confidence that Komodo transactions are happening with the same frequency during the times circled in red as the times circled in green? If so, then I'd say the title of this thread is appropriate.

Obviously, something is happening during these massive spikes and I think most people involved with Bitcoin would like to know what it is (hence this thread). Many people claim it's simply "normal use" but I'm just not buying that.

what is happening is that during the spikes komodo transactions are reduced due to nodes running out of usable utxo.

and the max rate is about 100 per day, can never be much more than that
so there is no way it is adding tens of thousands of tx in hours

komodo is a responsible user of the bitcoin blockchain and we can taken great efforts to minimize the blockchain usage.

In addition to that, we have been in testnet for over 3 months then mainnet for a month. If we were the cause then you would see a floor in the memory pool numbers for that duration, which you cant.

[Holliday]

Your description of the green circles as spikes would be more accurate if they didn't occupy more than half the horizontal axis in your figure.

Apologies, I didn't realized people enjoyed JJG style sesquipedalian loquaciousness and summarized "sudden massive increases in the rate of transactions relayed to the Bitcoin network, creating a backlog which takes considerable time to clear, especially when the rate is again increased multiple times during the process of clearing the previously existing backlog" into "spikes" for both brevity's sake along with the fact that the person I was having the discussion with had previously called it that earlier in our conversation and it would be clear that both he and I understood what we were talking about. Not to mention the fact that I included the picture (worth 1000 words last time I checked the exchange rate).

But, thanks so much for clearing that up for us!

[Holliday]

what is happening is that during the spikes komodo transactions are reduced due to nodes running out of usable utxo.

and the max rate is about 100 per day, can never be much more than that
so there is no way it is adding tens of thousands of tx in hours

komodo is a responsible user of the bitcoin blockchain and we can taken great efforts to minimize the blockchain usage.

In addition to that, we have been in testnet for over 3 months then mainnet for a month. If we were the cause then you would see a floor in the memory pool numbers for that duration, which you cant.

Thanks for your replies!

I'm slightly confused about this part.

nodes running out of usable utxo.

[jl777]

what is happening is that during the spikes komodo transactions are reduced due to nodes running out of usable utxo.

and the max rate is about 100 per day, can never be much more than that
so there is no way it is adding tens of thousands of tx in hours

komodo is a responsible user of the bitcoin blockchain and we can taken great efforts to minimize the blockchain usage.

In addition to that, we have been in testnet for over 3 months then mainnet for a month. If we were the cause then you would see a floor in the memory pool numbers for that duration, which you cant.

Thanks for your replies!

I'm slightly confused about this part.

nodes running out of usable utxo.

with the spike in mempool, there are no vins (usable utxo) that can be used. The type of usable utxo is constrained to reduce the space needed for each tx

but if transactions are stuck, then notarizations get stuck too. they are not even generated into the mempool