11:35:44 <br-m> <articmine> The fee is protection only if the transaction is mined. Which is why it is critical that only transactions that are economic to mine are relayed > <@boog900> otherwise fee/cost to build the tx is the protection 
11:36:55 <br-m> <articmine> This is why the minimum node relay fee was introduced in the first place 
11:39:56 <br-m> <articmine> Also an invalid transaction gets stopped at the first node, and a node that relays invalid transactions gets blocked. 
11:41:54 <br-m> <articmine> The valid but uneconomic transactions are a much greater thread if they get relayed. It is here where the real potential for a DDOS lies
11:46:03 <br-m> <articmine> Threat 
11:47:29 <br-m> <boog900> @articmine: FWIW this isn't the case currently, they will just get disconnected not banned, but yeah this could be changed. 
11:47:30 <br-m> <boog900> This also requires network addresses be constrained, anyone with a lot of addresses or on an anonymity networks can still DoS
11:49:36 <br-m> <articmine> Disconnecting is likely enough to frustrate a DDOS
11:52:08 <br-m> <boog900> some public nodes have over 100 connections, if an attacker made multiple connections they would still be able to DoS the node I think 
11:52:27 <br-m> <boog900> even if they get disconnected after every bad tx 
11:54:09 <br-m> <articmine> As for anonymity networks yes, user POW is an option. I would prefer burning small amounts of XMR as an alternative instead 
11:55:02 <br-m> <articmine> My point is that valid transactions that are not economical to mine are a far greater threat
11:57:30 <br-m> <articmine> There is a real threat of a DDOS when the transactions are relayed by the nodes.
12:03:01 <br-m> <boog900> if valid txs that are uneconomical to mine is enough to DDoS then txs that are economical to mine is enough to DDoS.
12:03:01 <br-m> <boog900> Unmined txs are still spending a key image, which can only be spent once, if you can create enough txs to DDoS nodes with txs that will never be mined then you can do the same with economical txs, right? 
12:04:44 <br-m> <boog900> It does cause a separate issue where txs will be stuck in the pool until they are ejected but it shouldn't be a DoS
12:06:29 <br-m> <articmine> With economical TXs you actually spend the fee. So it is not the same 
12:08:17 <br-m> <boog900> with uneconomical TXs you are locking your funds until the txs are ejected from the pool 
12:09:34 <br-m> <articmine> Yes but the funds are refunded. On can create massive transactions that lock up miniscule amounts of XMR
12:09:56 <br-m> <boog900> @articmine: after days though 
12:10:09 <br-m> <boog900> not enough time to create multiple txs for spam 
12:10:57 <br-m> <boog900> you either have enough KIs with XMR to DoS the chain with valid txs, economical or not, or you don't. 
12:11:35 <DataHoarder> if you mine a monero block you can create 2160 outputs :)
12:13:38 <DataHoarder> though https://github.com/monero-project/research-lab/issues/108 could segregate these so that is not viable
12:31:57 <sech1> Technically you can mine a 300 KB block consisting only of outputs, that would be around 7600-7700 outputs
13:36:07 <DataHoarder> or more if you go into penalties? or is that the header limit
14:00:24 <sech1> More if you go into penalties, but then the individual outputs will get so small you won't be able to spend them
15:47:35 <br-m> <articmine> sech1: ... but they can be reused to create valid spam transactions in the future
15:48:52 <DataHoarder> so 108 would be important there to enforce sweep on coinbase, to single output (segmenting coinbase/others)
15:49:02 <DataHoarder> but they could also just call that for each output they have
15:49:24 <DataHoarder> unless there's a reasonable fee applied
15:58:40 <br-m> <articmine> Yes. At the very least 108 should be revisited in the light of FCMP++
15:59:47 <br-m> <articmine> Especially given that churn is no longer as relevant 
16:02:24 <DataHoarder> funnily, many coinbase inputs -> one output should probably be taxed lower than few inputs -> one output :)
16:02:41 <DataHoarder> relatively, not absolute
16:04:18 <br-m> <articmine> If we take out the membership proof it will be taxed lower 
16:05:47 <br-m> <articmine> Much lower as the number of inputs inceeases
22:23:49 <tevador> https://github.com/monero-project/research-lab/issues/146