Panel Discussion - Double-spend Proofs Versus Double-spend Relay

[Music] now you start technics speaking that would be possible practically speaking I don't think it makes much sense because they're kind of connected to each other they they interact better in their specific in implementations I think the main difference between the two is the specific set of variables that make something a super standard or a standard yeah transaction that are more geared towards their specific implementations did the idea of choosing between these proven TX relay and the implementation of the priorities still makes a lot of sense to separate in implementation anyway you can choose to not do any super standard if you want and still do the TX relay but then as imaginary user name mentioned non upgraded s between wallets will not get the benefit from from this protection I absolutely think we need to combine the proposals to some degree whatever comes out specific things about the for example there's things that are not in the si SP SNP proposal such as explorations not dealt with it all it needs to be dealt with so seven things I like about that the other proposal are the standard replacing non-standard idea I love that idea so and and then the whole we have different views on fees that the Rees been relayed says fees is not part of the solution the other one says it is I I think I think whether what to do about fees could wind up mixing and matching the fees is is an interesting topic because we we know that fees is and concept really introduced by Corps in in a way that moves it towards a specific economic model that really wasn't part of the initial Bitcoin and what we've been discussing in the last two years I think is to replace the idea of fees with something slightly more complicated because the original Bitcoin said that the age of a transaction or an input specifically is much more important the specific code in the original satoshi client says that if you have a transaction input that is very old timewise and you your transaction is zero fee that basically is seen as a very high-quality transaction anyway so we're I'm hoping we are going to is is not have fees specifically in any of these situations but we're go into a situation where we for instance count the amount of inputs or outputs so you you allow more transactions to be used with lower fees because they empty out the you th offset that's just an example so it sounds like fees were used early on to effectively penalize transactions but not to refuse they're being committed right I think today these are being used a lot for spam control and I was wondering especially things like non-priority transactions and of course both proposals are sending more data over the wire right so how does the ability to create spam and spam multipliers you know negatively affect these proposals at this point the SI proposal I feel hat has the boss attack vectors very well locked down because you limit to things you limit the number of messages that can be relayed as alerts against a transaction and you limit the size so while earlier there was a rate limiter in the old code that was a NXT that's begin with we've upgraded that in the implementation and the spec so I think that it's totally controlled as far as the toss vector so there's two points here first of all I think that if we allow transactions whole transactions b2b relate you will send more data the ability to send first a small transaction as a simple example and then send 100k transaction and and suddenly you obligate the network for its self-protection to send the 100k transaction as well becomes an issue and at the same time the whole concept of transactions are bigger than proofs and also means that if you have one original transaction and 15 wristbands I'm kind of wondering how many of those refunds are being broadcast as well whereas in just one okay that's good and whereas in the double span proof concept the message being sent is extremely small it refuses to send anything broadcast or propagate anything that doesn't actually have a transaction in the mempool to match it so you can't just you know create hundreds of proofs and last if just like in in in the relay apparently when there is more than one REE spend then you will not relay the second one so I think the the spamming itself is mitigated quite well because it is directly connected to the amount of transactions that that a note allows in Zoo is mental TomTom Jim question so yeah one question about it because it's obvious that then relaying takes more data but from the perspective of the spammer is it easier to spend by creating all these respects or just can it just as well create different transactions I mean what was just transaction relay somehow increase the abilities of a spammer over what it already can do with ordinary transactions cost the real a proposal increases it roughly by a factor of two because you can relay one extra transaction that's not gonna give mind okay so if that's that's the risk in the past there was some amplification but not now I just want to respond to some of the things Tom said 100k REE spend is not possible in an SI proposal because it's not Stanton super standard only a 2k transaction is super standard well this we're talking about this proposal though so it's not a weakness of my proposal that you can relay a large alert that large it is however a weakness of your proposal that you try to protect the transaction that large I concede that the proofs are smaller than relaying a transaction because the real proof is the transaction it's the thing that double spender signed that incriminates him you can read ACK the questions what can you read act thanks to the sink hashed algorithm in in BCH we can what's not to be in Bitcoin in BCH we can read act things from it and have it remain improved so the proposal read acts all the inputs that are involved which is a good idea and makes it smaller it also read acts all the outputs as I said earlier I think that's a bad idea because it reduces the address ability of the of the alert so yeah one thing just to say that I find fascinating is there's a huge commonality here which is that no one is arguing anymore to not relay some form of alert right so effectively you could imagine that the DS proof is kind of like a more efficient relay of the full transaction and one thing that I found interesting about that is you know people have made the observation that des proofs aren't available for all transaction types so perhaps if the more efficient version isn't available we could fall back to the the ultimate proof which is just to relay the transaction imagine I use your name Jeff question oh I just want to point out because there was a discussion about spam potential which is right now as in first thing is this directly tied to the fees that you pay per transaction but if you are if you are doing a double span double span transaction relay then there is this potential to increase the network load much larger than the fee that is going to get confirmed so you know you can relay a very small transaction that is 192 bytes and pay the appropriate satoshi fees 192 and then you and then you put out a much much larger transaction and that would have to be related much much and your question is is that correct or no no no but I just I just want to point out that that is one spam amplification factor yeah so because 192 versus the the reason could be 2 K in those 50 K or and also the proofing well I guess the proof would be smaller but yeah the the fees if you if you if you bake fees into the standard which could you just also easily be done with any super standard TX relay that's an option it's just we have to make it we have to make that trade-off between making the standard brittle or making it adaptive to the network so it has a question for Tom Harting it's kind of a little bit related you had talked about the Reese penned gap right and how important it was to minimize that wouldn't the des proof minimize that respect because the proof will travel a lot faster for you know non-trivial Willie sighs its transactions today to the extent that it's smaller I suppose it would yeah if it Redux the other unseen inputs it would be slightly faster you're supposed to argue with me about this well ok so if we say to K we're assuming that we also deploy super standard right so I think we need to sort of imagine these as it's you know separate possibilities we that we deploy like what we have today is just respond right and now do we move to super standard or not I would say yeah to verify the proof you you have to do well you have to verify the signatures either way and do the hashing either way yeah so it's just the size Chris mentioned earlier yesterday did he it would be nice crust you know come to consensus on doubles been proof or double spoon or Ebay what do we want to put our effort towards but I'm wondering like we already have T X relay and bu and XT like do we really need to pick can we not just implement both and kind of see what happens is it really so bad if we have both live on the network that the talk from you Peter a couple of days ago implied that the way to get better double Spence to actually land at the miners was to use the relaying of transactions and and I think it was funny because the first comments already it was hey it's interesting to see that this relaying of the transaction is actually the cause of the double spends if you were to turn it off it will be very interesting to know if your test comes out differently and I think that's the biggest issue I have with double spend relay it it hurts the network it has two major effects the first one being a transaction that would currently useful before B you implemented this be completely rejected on the first seen rule now suddenly does propagate through the network and this is is ok-ish for normal notes because they most likely have a mempool see all the transactions for SPV knows this is disastrous though because if you have a fast wristband where the second transaction is two words an SPV user then there is no way for that SPE user to actually figure out it is a wristband because it never gets the first transaction because the first transaction is filtered by the bloom filters it wasn't to him so he doesn't get it and therefore the relay will hurt SBV users exponentially and that is supposed to be 99% of the users so um I'd like to respond to that if I can um and I think it brings up an interesting topic which I think we're skirting around I'd like to make it very clear which is that it seems like in a lot of cases the presence of a Rhys pend needs to effectively mean that that like both transactions have to take on the qualities or the priorities of the the other and in this case a solution to the problem that you proposed would be well even if one transaction doesn't hit the bloom filter it gets relayed to the SPV node anyway due to the presence of the key you know the double spend transaction and I think we see that actually in a lot of places because we're talking about like one of the important parts of the des proof and the transaction relay is to you know relay these entities at high priority right and Tom Xander you were talking about what's great about the des proof is that it's a separate channel from the transaction relay and I took that to mean effectively a separate high priority you know will not be it's throwing oh yeah sensor thrown out you know it's just a channel right is that a good assessment of the reasons can can I first respond to this little mistake so when you mentioned the SPV nodes being at risk because of real angry spends they may not seen the red one the code out there doesn't do that that was identified as a risk and so it doesn't do that that was a in room for that for now we're not really in response at SPV nodes because we wanted to fix that problem but also the correct thing to do as Andrew said is to send make sure before you send the proof of whatever kind you send the original transaction make sure they have it the suggestion that relaying the Rhys Bend is dangerous because it's bad and it may get to it maybe mind is not correct on a bunch of levels first of all as security its security through obscurity and that's not something that we want to rely on I mentioned earlier the double spender himself could send it to hundreds of nodes everyone needs to be prepared for receiving it and the fact that we're doing it now and it hasn't caused a ton of problems means that generally because it's even on the BTC Network at one time XT was about 20% of nodes on the BTC network so almost every node was getting all the response with the normal connection counts and it never cost a problem they didn't have RBF back then I think I remember imaginary user name himself did it did a test to check whether the mining of Reese pens was increased by relaying them and they believe he found that it didn't or was the opposite so it does so that simulation it addresses a specific thing which is if it increases the chance of a tx2 getting through the minor first of in a upside down in a upside down situation and the finding is that real a double spend does not increase that by any significant amount so that was your partner that found that it did not it did not however address the question of whether a ill minded miner will who get both would have a higher chance of would have a higher chance of oh I got the x2 I might as well mine he has to first of that one's not addressed for variety of reasons but if such a minor exists and the answer is probably yes so yeah yes that wasn't the argument I was making the argument I was making is that it goes to SPV my users and and you said that that's not the case because the BU software doesn't send it SPG miners s with three clients that doesn't mean it doesn't reach sp3 clients because if I send it if I send the bad transaction to a different note that one can itself send it to an SP fee note as well it doesn't have to come if it sees it first because they don't really read spend only if it sees it first or if it's not standard you basically come back to the original current setup where your your transaction is not going to be seen by the majority of nodes if you have a lower fee for instance and therefore you still have all the opportunities because constantly instead of you needing to contact hundreds of nodes like you yourself suggested suddenly you just have to send it to one bu node and they will contact hundreds of note for you I just want to say on a higher level the idea that one the idea that one transaction is contraband and the other one is good the idea that because you got something one millisecond later than another one that it mustn't be relayed and other nodes mustn't be able to draw their own conclusions about whether it's and users can't draw their own conclusions about what the gap was isn't a strong way of approaching it the better way to do it is to make the network transmat transparent to both of them and then at the point of consumption the decision has to be made whether there's really a problem there or not can't identify one as good or bad you could be you can be seeing them easily in fifty percent of the time for assignment a time until you transmit it you're making the wrong decision it's not possible to do that I would like to rebound on two things that that you said the first one is that really that not rallying the second transaction is security by obscurity and we shouldn't rely on that and I agree 100% but on the other and that doesn't mean that like I don't think that's an argument for word insecurity and let me take like a metaphor to try to explain that I D I have a log on you know on the door on my house right because I do not rely on everybody being nice and not breaking in that doesn't mean that the person that break-ins is not a giant douche bag and and that doesn't mean that we should like consider that behavior as normal so I don't think that's a very strong argument for the man's man Oh ever you met another one that I think is usually usually quite misunderstood but there is no notion of this is the real transaction and this is the double span right because we are on distributed network and all notions of time or what haven't happened or did not happen is inherently subjective it's not is gonna have its own and there is literally no way to ensure that like this is why we need Bitcoin in the first place it's for all the not to converge to what a common state before that there is literally no common state that exists and there is no commented that can exist and and so as a result that the idea that there would be an original transaction and it would be that double span and we need to block that double span it's it's not wrong it's actually completely meaningless right it like it cannot be right or wrong it doesn't like it doesn't make any sense to begin with so yeah that's yeah that's pretty much the idea I wanted to run faces it's completely agreed I can I just respond to this very own um I also tend to agree with you and obviously we need blocks and improve of work to other transactions but I mean of course we have this kind of gray area where you say like okay first thing safe it's like I mean the whole idea of having this boundary of like let's say okay after three seconds of not seeing anything it's safe it's because we do some ordering and assume that the total network even though on a micro scale it does not have like in ordering of transactions that's that's consistent between notes on a scale of like 10 seconds it does have an ordering right if you don't have a transaction then you should it's it's so does buy enough that comes after that I agree with that go ahead so I wanted to say that I do agree that security by obscurity is you know never the best pattern but also we have to be very clear that when we give full knowledge to a minor of a transaction twice we are giving them a choice to choose between two things where it's completely ambiguous as to the in the intended recipient or where what transactions have valid transaction they're both valid transactions they don't really have any way to choose so the debate really is is anytime you see to you know that you have no idea to know whether an what's actually going to get mind on the network and that this is a case where the merchant needs to consider it a bad case for the merchant so they're either going to need to refund payment or they're going to need to just acknowledge that something has gone wrong and that is absolutely the requirement so I think that trying to minimize the case where a minor could be bribed it's not necessarily security by obscurity it's really just making sure we don't make it easier for them just handing them the keys and saying okay here here C R so a way for you to cheat the network and just get some extra money there any profit driven minor if we don't know what they're going to do we can't assume that the minors are going to behave well so this is really just a risk analysis of do we want to give them all the information so that they can do try to be profitable or are we going to try to just give them a proof that something's gone wrong so that the merchant has been notified that this thing has gone wrong to me the main difference between the double spend proof and the TX relay is not whether it provides the notification they both provide the notification they both give the data that's needed what is the difference I think is the technical effort to implement the specific solution so double spread proofs we're talking about using a different channel to be able to send those proofs using a nymphet that is new and it requires some updates in order for software to support double spend proofs today where TX relay does not require any real integration changes inside of the ecosystem and I think that's the main point they both do work one has a slightly higher attack vector and that the miner can choose to grab the higher priority transaction and could lead to that but at the same time the merchant is going to get notified and they're going to reject the payment anyway so it's kind of inconsequential at the end of the day but it's the integration complexity that I'd like to try to focus on and I really haven't heard much of a discussion about that part okay well to respond to your your concern can the experiment you would want to do ideally is to have a world with only Delfin proofs or attempts to have only Devils van proofs and then have one that has free relay and see if if fewer adverse confirms happen and one of the other we I don't know if we can do that we can't do that experiment cuz we can't lock down the relay FTX - even if we don't have relay nodes the attacker can do it the node restarts or even the wallet I think in some scenarios could relay this conflict because maybe or maybe not but but we do have experiment experimental data that Android Theater presented and that's available you can just scroll through the Reis pens on double spend cash and see what does it seem like when do surprising adversity x2 confirms happen and it's when they were relayed very close together the time is the is the thing that makes it happen the fee is not the thing that's currently making it happen overall and today it's not because they can't get it they can get it I like to address what just just said I mean I think there's one big difference and that I think as not it's not addressable versa takes relay is that the big transaction case right like you will get a faster real live as a double spent proof and I don't see how you can get around that when you say big transaction you yeah like it like a hammock a transaction versus like a 100k transaction versus the one ksi says 2 K is the max so you wouldn't try that you what what do you do with the 100k a spend do you just assume it's not gonna be a problem it would not be a zero conference so no he's no but he's he's asking about the responders 100k so the way I originally retrospect the these super standard or relay and the Super Center replacement was actually tied together and I believe that part was addressed by the fact that the 2k is going to replace 100k at all times that's how I read it that is correct yeah because it's it's it's yeah it's just it's defined to be not part of the protected class and so if it does lodge itself at a minor it would get dislodged by I just really really clicked I I like that idea then like it makes sense like to say okay like we only have like two up to 2k or something for these transactions and they get replaced but then we all this other kind of forms that you have to attack the first scene saves rule to replace it this year replaced by 2k super standard right so it seems to me like this is like a path you could go but it has the hurdle of more changes that can break existing yeah existing software with with es proof we must also assume and I think that's a point that Tom hunting also made it we must assume that these miners will get both transactions so you always have that problem you have to these are two different problems to solve this is this is not correct the miners are not responsible for creating these proof and any node can do that no but if we're just gonna relay not kind of relay transactions but kind of relay the the proofs then an attacker is still going to attempt to get it to get there double spend transactions to over a miners so we still must have the policy of how to handle this second transaction already so being aware of them is already good for the merchant right and I think that the problem is that mr. TX realized you might get to the point where the merchant is not aware of the big transaction this goes together with my talk an hour ago where a double spent proof is not meant to have any influence on the miners on which transactions to to mine I completely agree with the further with the statements made earlier that the the right transaction is is a judgment call and can't be made by the system - can decide however they want I don't I don't mind the the point of double spend proves is to let the merchants know that something happened so they can lift it out of the system and and take responsibility so if I'm standing on the street and you pay me something and you double spend behind my back that I know that hey I shouldn't give you an article tears both from me that's the point so it's it's not nothing more and and while I have the mic I wanna respond to two things that basically are the same point it's about the way that if we deploy this because there's one rather large problem with the relaying because the solution may suggest it for SPV wallet to get the knowledge of a transaction is for a node to change its behavior where if you have the scenario my attacker sends a transaction to himself and then a couple of seconds later he sends a transaction to the merchant the problem with an SPF e wallet is it would never see the first transaction therefore with the relay it would never actually notice there was a problem so the solution to that was suggested the node changes behavior it sends both transactions to the SPV wallet this assumes that SPV wallet is upgraded and will actually detect this say hey there's a transaction that not for me currently that means that all SB wallets ignore it and if you do this if you make the network change this for a while until all SP wallets have been upgraded and patched you will actually create a bigger problem because as before now that transaction that is currently not being relayed at all actually reaches the SPF e wallet so you're actually creating a problem and this is the deployment issue if we could do a snap replays and everybody's devices it gonna be upgraded today then there is something to be said but there is a huge problem with rolling out the relay for SBV Wallace right now and we can't fix that in any way whereas you can so I I omitted from the description of the how that when we start doing that how to address that we did identify that you always need the SPV wallet will request race pens nobody nothing will be relayed to the wallet unless it requests it and changes to the node and changes to the SPV wallet are required under both proposals and I think the magnitude of the changes is similar also I want to return to the wait um Tom's II do you believe that the magnitude is similar as well the that the change is needed to the SPV wallet in in the double spent proofs are currently and and this was actually also mentioned in the presentation from imaginary username the changes needed are essentially that nobody gets hurt because they get a message they don't understand and therefore they don't get the notification and so we're I think and wallet has the the reason to upgrade to get notifications whereas in your proposal the wallet needs to upgrade to not get a diminished experience no that's not correct because they don't know no SPV wallets are currently requesting double spins so no one nobody would get hurt also it's not true that the only changes needed would be to ignore purse we want them to use the purse they have to be able to process the purse so that change is needed doesn't exist right now it does I like it from there was a question about the engineering effort which is why I wanted to stop you guys right it does sound like we're coming to the point where you know not counting nickel and diming lines of code like the that we need you know a certain level of changes to all these certain you know to the same components within the Bitcoin network SPB while it's full notes someone who watches this video is going to notice I never responded about the 100k Ries Bend which is a really good question you so you pay someone with a 2k transaction and then you do 100k Reece Bend so it's a reef and it's not protected but that's not important it's actually it's only function in every spend relase and it's a serve as an alert and the reason that's not a big problem is because with an alert you want it to go really fast or with it sorry because it's it's not the alert it's also if you're worried that a miner is going to mine it you're worried that it's gonna get to the miner fast but it's not gonna get some minor fast it's gonna go it's very slow so it's was that rely on security through obscurity in the sense that he could send 100k transactions a minute to just get going that I mean that assumes that the path of the transaction to the miner and to the merchant the same but like it could be different so that the merchant doesn't see it but the 9s world I think you're speaking I'm not assuming a best-case scenario for me I'm just saying it's going to be on average 200 times slower so what about the scenario when the attacker sends the 200k transaction first waits five seconds and then finally sends the transaction to the merchant that's a big problem for your proposal but not a problem at all in mine because we don't protect hundred K transactions that would not be relied on why is it not a problem if you don't protect them the merchant would say well you didn't you didn't pay me with a super standard transaction so I'm not giving you the goods until it confirms this second transaction is a stent super standard transaction so fight okay so you're saying five seconds later they do like a reverse we spend kind of thing but still that's that's five seconds but you have you have 50 x times the other propagation that's hence you wait the finished second so all the minus or you have it and then in your proposal you want the miners to replace it that assumes that all the miners follow this policy otherwise you will increase the ability of merchants to get robbed maybe maybe you can diagram it okay imagine we have a attacker that takes a hundred K transaction pays himself and then he sends the transaction to the merchant knowing that the transaction to the merchant is a much shorter path so there's a good chance it doesn't have to be a hundred percent chance that the transaction that he pays the merchant actually reaches the merchant and it's a double spend and the hanukkah transaction never reaches the merchant and so your proposal also doesn't actually do anything about the the the relaying of the transaction in the first place so it falls out of it but it still is an open hole isn't it did I miss something okay so can i clarify for a sec so you're saying the 100k transaction doesn't get to the merchant within the five second time window because it's so big is that what you're saying also you're saying it doesn't pay the merchant it's the respect okay so basically it's the same as the other scenario but it's transmitted earlier so basically you have the bad guy who's trying to gain me he's trying to he's trying to guess how much later it's gonna rise at the minor so and transmit it before that yeah so he could try to do that he's trying to make a guess of long does does the efficiency of double spend proofs justify the engineering effort alone without even discussing these issues the engineering efforts I mean this is based on the creation of a hash that is going to be signed for transaction this is the basic the core part of Bitcoin this code is there might need to be reflected a little bit to make it reusable instead of copy/paste I don't expect it to take a lot of time and this goes for all implementations because verifying signatures and the way that signatures are verified is that it takes it over a specific input a specific output that's also that based on the sick hash and those those lines of codes are already there so it really isn't a significant amount of work somebody just needs to sit down and do it which is probably the actual writing of code is a much lower amount of work than the actual you know creating over new message in the network layer and that kind of details which next beefy client doesn't even have to do that I want just to this discussion about double spend transactions and which one should be mine which ones shouldn't be mined I think it's very important to stress that the dub double spins don't happen by accident that could potentially happen by some sort of bug you know in a wallet or something that they are they're not by accident that just doesn't happen by accident and so I think that a clearer way to view the double spin transaction is that they're both double spin transactions they're both unwanted transactions the double the double spin proof approach why I like it is it seems to be less invasive and less changing how things are running at the moment it's a separatist notification hey guys something's going on I'm not sure what the relay of transaction adds that doubles band of proof doesn't add and to me the real cost and possibly we don't talk about it enough yeah is there is a significant cost in my mind as to the perceived risk as to the eventual result of further double spins occurring and it's and I think it's more complex than just social media exacerbates the perceived risk but that the end result is people lose people perceive a risk and that's it that I mean that that's that's why why double spending is an issue or you know zero confidence because it's a perceived risk even that's not a major risk it's pretty it's almost good enough today but there's this perceiver so everyone holds back so anything that increases that I think has a significant effect in adoption has a significant effect in in development and just in people provide looking to provide custom experience if there's more perceived risk around it so that to me is the cost with with the rely and so I just wanted to chain yeah I'd like to respond to that because the the idea that it should be clear from what we've discussed today that that addressing this this area isn't just about the format of the alert the format of the alert I agreed proofs can work but just sending alerts is only a part of it and that proposal if it's simpler it's because it has skipped over a bunch of things it says let's just protect all standard transactions that's not a good idea it doesn't address expiration that's not okay so we have to take all the ideas on the table and so I to say that it's simpler to do it is just because it doesn't do enough well what what risks or what notifications aren't covered in the devil spin it's not clear when aut X will become spendable again in unless you're gonna permanently make that UT oh you take so and spendable that has to be addressed also it tries to protect hundred K transactions well why is it like a either all of us these two I I don't I don't understand that like it's not I'm just responding to the idea that one's really simple I don't get how double some proofs has anything to do with exploration because it doesn't change the the way that existing transactions are relayed or mind it's separate from the s PNP replacement who doubles BAM proof proposal is a whole other channel and layer and yeah it so there's nothing to expire right but the person asking the question I think is assuming that just making a proof is the whole thing and I'm not just it the proof itself is more complex so it's not it's not almost enough well we're not talking I told you that the format of the alert isn't the only difference the two are very similar as alerts it's the other parts of the protection that are important I'm just I I want to respond to the other question that was asked about Oh oh it was it was the answer that Tom gave about the effort so he was saying that implementing proofs is no big deal and so I'm not gonna say that implementing relay is no big deal because it's obvious that it's no big deal and it's already implemented I do think that it's far too easy to underestimate the effort involved in implementing something like proofs it's complicated because it's a new message type and you have I had another slide that I didn't wind up showing but today I put up a slide in Tokyo where they showed there's four different ways you can get an ordering of TX 1 and TX 2 and what can happen in those scenarios when you add the proof in there and you and you talk about what happens at the minor versus what happens at the merchant there's 36 different combinations of orderings that can happen on both of them and and that doesn't mean you have 36 cases to solve you you try to come up with the rules like and there's some rules specified in the in the spec which say if I get a proof and I've never heard of this UT X so before I throw it away if I I think there's some risk there after actually because if you throw it away well I'm not sure that's a Tom this is actually my question that Tom's Anderson maybe I can just segue into it so to attempt to throw a monkey wrench into the so double spend proofs we've kind of agreed that it's much more efficient right so let's say an attacker was to create slightly more efficient it's it's more it's um the size of a transaction you know the data paths can be much smaller right and it would therefore be related faster so as an attacker let's say I create 200 K transactions right and effectively and they're they're double spends of each other and effectively then the double spend proof will beat those transactions propagating through the network and therefore be dropped due to this this don't relay double spend proofs if you don't you haven't seen the transaction yet rule right so I'm wondering what is the source of that role I feel like you know you've created this a high priority alert channel but now you're you're chaining it to a low priority channel and you want to talk a little bit about why that was needed and how maybe we can solve this problem the basic reason why this was needed is simple it's a to protect from spam attacks because we when we provide a no-questions-asked high level transport we need to make sure that somebody can't abuse it and the simplest way to avoid abusing a system is to make it have a cost and the cost in this case is that there has to actually be a minor bull transaction which typically implies a cost mining cost for instance or the the fees specifically so that's the reason why they are combined and and it's a good point I think one of the reasons why we have these questions I how many had a fantastic question as well you know what happens when you send hundreds of double spent transactions so you have one actual transaction and then you just create a hundred to double spent reductions and and you know this is these are the kind of questions you get when you start implementing it where a simple thing that my idea about this is that a double spend proof that comes in will only need be kept on an old for probably 10 20 seconds because I expect like any mempool transaction that is in a menthol I expect that we don't actually send the double spam proof unsolicited we send a nymph which means that you have a round trip because otherwise any note will get lots of lots of duplicates lots of ways to bandwidth so you need to cash it for some time anyway and as a result what you what you can do is you have a first level cache where you keep off your double spent relays and then you you know you keep I have seen this idea of double spend relay till the transaction is mined something like that and that side steps all of these problems you don't relay that's the rule you do not relay the double spent proof until you have in your memo one of the two transactions yeah I'm just thinking of a certain interesting scenario for the for the TX relay model where you know the miners are behaving properly they doin first scene and they're replacing non-standard transactions and non super standard transactions by super standard transactions which is a requirement but that gets a little bit weird if you have a block boundary so if I go to a vending machine and I publish a non-standard transaction to to a minor that accepts it and I just wait until a block gets mines then at that moment buy my stuff with a super standard transaction then the gap suddenly becomes the entire block isn't that a problem isn't that too large well the conflict that arrives so the conflict will arrive in as part of the block yes but then then you then needed it itself propagation of the whole block that is basically becoming your gap yeah that's interesting I haven't thought of that attack before in general you do you would treat a you would treat you treat you need to treat all the transactions that come in a block as how if they've just been seen and that's and normally they would come later you know because the block comes much later so they would not they wouldn't count as invalidating but say your scenario is you wait for the block and and then a minor is behaving properly because he cannot you know he has already done the non stare at through session but hasn't seen the super standard one and then you know then certainly your cap becomes quite large I would say but it only of course applies to situations where you can wait for the payment at an exact time like a vending machine but it's still an interesting scenario like risk voice can't you simply model this like by basically taking the ratio of block polarization time to 600 seconds and saying this is the kind of like floor on the on the double spending avoidance I can do and simply say okay there's like a percent it's for less than the percent is like a criminal chance that you have this block and you can actually exploit it but I mean if I look at the merchants and customer interaction like you're not going to wait at the checkout counter although a block of ice right how does that how does how does that question distinguish between these two proposals well with with a double spent relay that the the of course the second transaction would just be relayed as a double spend anyway even if it's already in the first one was already in a block or I might yeah it's still double spent right but maybe don't have your scenario right okay so I'm publishing a non-standard transaction and at the moment the block comes in I'm publishing at the super standard transaction so the the the the super standard system is doing nothing wrong because he's including in a non-standard section without having seen a super standard transaction but for in your proposal you would have to wait for the entire block to come in in order to see the non-standard transaction the first one whereas in the in the NYADA proposal the double spent proof would just be sent immediately but there isn't there is almost the same attack I mean if yes almost a semi whatever the difference is sending a double spell in this case the difference is not sending a double strength proof or a 100k transaction there is attending a double spent proof or sending an entire block in terms of speed in terms of the gap but but you could just as easily double spend regardless of what the plan is if you're going to get the miner to put the reece penned in a block and then you're going to immediately you mean processing the entire the notification time for the merchant like the gap use once yeah once it gets to that transaction but it has to process the whole block yeah the merchant has to process the whole block for he guess before he detects the double spend instead of just receiving the double spend so it's not it's not a big timeframe here but it does increase the gap I would say for this scenario and maybe it's an edge case but it's a good one and this I think is the main reason why I I would aim towards a separate system a separate channel for notifications like these don't build it on top of an evolving system because you know these kind of things fantastic thinking I'm pretty sure there's gonna be more little gaps in the in the ideas of how these things work if you reuse the existing channels because it's gonna it's like a game system a friend of mine worked for a game site and and whenever there was an update there was a certain group of people that would always you know spend a lot of time trying to find holes and then you know for the next week after it you end up fixing all the little holes and there's gonna be unintended side effects and it's gonna be in a continuous problem as long as you keep on using the existing channels because you're any change to fix the problem will end up being inside of the system that you're trying to fix with unintended side effects people who are selling solutions that aren't created yet are always able to do that and the assumption is that the new system won't have any problems but the new system actually has a whole all of its problems that haven't even been discovered yet because it hasn't been written and has it been used but at least they don't interact with each other well the if the idea of super standard is actually a different channel it is it is also asking what needs to be done to make it efficient so it's not just reusing the existing channels talked about super chance to test standards the one thing that I'm wondering about is how do you foresee rollouts imagine that the miners over the course of three months will start introducing super standards and replacement when would have become safe for notes to get doubles before for SPV notes for su wallets to get the double spend relays well what I said was that you have to treat the activation of the replacement real similar to a hard fork it has to be something that is everyone agrees to turn that on at the same time if I turn it on it means we're wallets would say that this transaction is it's reliable fair enough I don't think that's a good idea but that's not my decision to make yeah it's good just to understand the dimensions of each problem right and so looking on the other side on the non priority transactions I find this proposal pretty interesting and completely new I haven't heard of it before you know these last talks and of course I have a few concerns one would be could an attacker just effectively fill completely spam the network with transactions that he know will likely not be committed until the mental is full right and then the benefits of relaying non-priority go away because now we have to start rejecting transactions from the mempool maybe yeah we can give imaginary username uh my um so the idea of non-priority versus standard priority is not to say that nodes would have to start relaying non-priority now because the realm of non priority is big and there will always be a threshold no matter where you dogs draw it there will always be a threshold where no it starts to be unwilling to relate it um the idea is to draw a line between standard priority and non priority where you know above the line that is safe below the line notes miners do whatever you want just like they do today feel free to play with it just don't affect things that are above that line today we just don't relay those transactions are some law some notes and some miners do and that is status proven to be your problems oh ah so what you're saying is to clearly and in a centralized fashion define sort of when a transaction drops into the non priorities well I mean I mean on rueland I mean today we also draw that line it was not followed by a new by everyone we also draw that line in terms of defining a mineral a fee that is prevailing on the network this proposal simply take that line and make it a more solid one death you know where where one side would replace the other instead of just a rule where one side gets real a and one side doesn't because today we also have a default min rule a rule that has been default which is effectively just a recommendation it's not right and that default line has actually made you know a lot of it created some problems but it also made a lot of difference in terms of making zero calm more reliable like things that are below it it tends to it tends to get blocked by the network and tends to not get mind so the non priority proposal is to harden that line at least by agreement and then um it's giving the option to the miners that basically let's call it minor cheese let's basically allow a mind to say hey I want to receive zero feed transactions and mind them but they know that there's opposition to it because you know there's there's risk to zero comp because the rest of the network doesn't and you get into a situation where either everybody moves and nobody moves and that's just not healthy so we're we're you now have the option for those miners that want to move the line to essentially say okay I'm going to make a separate layer of an NP transactions that allow you to you accept it but you do it in a way that doesn't cause abuse but so why do we need like this line at all when the double spend proof can handle those transactions as well because they're not the deadline for instance for the minimum fee is not in order to protect against a replay the double spends that's not the point they are here to predict the network you know it's easy to call them spam I understand yeah uh in terms of addressing double span I just want to reiterate what say what was in my slides they addressed two kinds of audiences like I agree that if everyone adopts that was improved and it will be fine and the line is may probably not need it um but um separately if miners draw that line and harden that lines and it protects wallets who do nothing at all wallets can just sit back do nothing and still get higher security in in in double spent proofs the whole and concept is optional yeah while it doubles them proof you what you have to get a wallet at half that gets those alerts in order to benefit from it so if we had to characterize you know out of all the proposals which one would be the most permissionless what do people think and then maybe we can do a show of hands and then they can argue it out what do you think about that so if you think that will spend proofs you know enable more permissionless innovation raise your hand yeah if you think that double spend proofs allow greater permissionless innovation then raise your hand with respect to the doubles man relay sure in mind I mean I don't let's let's make that one optional I'd say because you know that's that's for a later time I it seemed like maybe about three-quarters of the people spend yes yeah they are it's a free option question at least right there because I did not what yes but if you were asking the opposite question I would not vote no either I think it has very little impact the most dimensional problem unfortunately I'm trying to simplify it but yeah but so so so Tom Harting you first you want to do you want to sort of respond to the fact that 75% of the people think that double spend proves create more permissionless innovation no I'd like to hear why anyone in the audience when a state why are Tom Zander do you want to go I think the yeah you voted yes so open your mouth okay so the main reasons for me are I like the idea of not having to have as many changes forced on a wallet to implement features a wallet can choose not to accept the new double spend proof messages just fine and it makes the standard behavior that they're doing today for most purchasing wallets just slightly more safe based on that original proposal with very few changes in the logic of the wallet it also allows for the non priority transactions to be treated very independently by the miners and if those are going out then they can choose how to relay what's happening there but we can still provide the proofs in a very lightweight way to the wallets that choose to subscribe to those messages so it gives more flexibility to me on how we handle non-priority transactions in the future gives some flexibility to the to the network to say well you know these are non priority but these low maybe they have some other conditions that they say well these non priority of transactions I am going to relay to other parts of the network and gives them a choice to do that while giving us a way to give very small proofs that these double spins are occurring even in those cases so I just see it as less complexity for the existing system which means the people that have already developed solutions don't have to make that many modifications meaning that the permissionless choices they made previously don't get impacted and it allows for the more flexibility on the non priority transactions without having to incur an additional size restriction for relaying that transaction so since the double spend proofs are smaller it allows us to distribute those faster and also cover the non priority cases in a cleaner way as if I'm reasoning about it correctly okay is that what you meant by permissionless it's because I was I thought permissionless would mean allowing people to do that more things without asking permission yeah so what I meant was let's say you have a new service you want to deploy it on the network it requires you know weird transactions right so can you just talk to XT and have you know one node that supports that transaction type or do you need everyone to kind of acknowledge that transaction in lockstep okay I don't want to know what I said but I think that I think the relay it's way better for that because everyone knows how to process them already but but it so your point what a Josh's point was that it's easier to ignore because it's incremental it proofs are easier to ignore so responsibility let's say tummies let's say you had a you know a transaction that you'd normally accept and you have one that looks weird and it's a double spend would you now relay the one that you normally wouldn't relay because it's a double spend or would you just ignore it what does the speck say the the speck says that they follow the same rules as the standard transactions yeah then the idea is because the miners aren't going to treat them as protected so for me the concept of permissionless innovation is that you know if if one miner says hey I'm gonna work with this big bank and I'm gonna make lots of transactions that completely fall within the consensus rules but don't follow a standard then that is one of the the big simple examples of Michener's innovation everybody will accept it and it doesn't hurt anybody the blocks get bigger I guess but that's about it double spend proves basically don't hurt that that's a very simple use case I'm not saying that the relays hurt the system either it doesn't hurt permissionless innovation in in practically all the use cases I come and then this is probably the most extreme one I can come up with I have a question about something earlier about what Tom's lands are you what you said about I'm using also as a separate infamous it's the new double Spence I'm just trying to figure out a little bit how big these double Spence can be but I mean I would say that that's about four or five inch maybe max a single double Spence is really small doesn't really maybe it's a bit of a technical detail but does really make sense to the same same level as as normal transactions we don't get very big either where essentially what you want to do is if if you have one no that connects to eight or even 100 nodes then you don't want to make that one note send the full data to all of those because if that one node itself is also connected to honored nodes it would get hundred duplicates yes whereas if it only gets an in then it might get a hundred in duplicates but it doesn't matter too much yeah the depends of course on how big it is compared to an inch and that's slightly bigger it is definitely bigger but it's also bigger to send both an infant and setting an additional infinity there's no round-trip maybe maybe a consideration I don't know I don't know this is the original design in Bitcoin and it's actually used quite a lot in the industry because you know if you have a hundreds of them you save the difference in them nine times 99 so it is definitely a benefit I don't see why Josh why you see such a big difference in wallet developers experience did you had two major things one was that the you said the proof would be easy to support and and once they decided to but they didn't have to and the other was that you see an advantage of the service that miners can provide with the ESPE replacement the second point I agree with that and I think that should be done I think it's an element of the of that proposal that that's just a good idea and I I don't think I don't I don't see how you can be so sure that implementing the proof so it's going to be easier that seems to me like it's not going to be easier for the SI if they wallet as I said before I think all things considered it's let's just say it's about equal I like to point out a couple things so first of all I think that we should actually maybe not talk too much about double spending transactions I mean that up like a transaction is being double spent as a result of being an input being double spend right and I think you should focus on this like actually that was spending inputs this is what what's happening but like it's the data transactions now it's mainly because it's like a atomic set of inputs being that's been like but actually what happens is the input and the other thing is that on the on the spam case that actually got me thinking and I think I touched this area a couple times when I was thinking about this like the that whether double spend relay or whether it's a transaction relay or a proof relay in either case it strongly depends on the the other part that you brought up Tom that is Tom Harding I mean and that is like what is a super Senate or whether we have a Super Stallion transaction and whether they actually I know the member or not because that depends on like the the propagation of the proof or the propagation of the relay it depends a lot on the the rules we make for actually accepting into the mantle so it seems to me that you cannot even separate these two cleanly so to just address the point the main reason that I feel like it's slightly more permissionless is the treatment of the non priority transactions and still being able to provide proofs for those transactions to give flexibility to people that want to create more complex transaction types the wallet integration issue is a very minor one and honestly I don't think there's a huge difference I think it's a slight difference and I'm still very cautious about the idea of replacement transactions I'm not completely sold that replacement transactions are the correct way other than just notifying that there is two transactions that are happening a certain way with transaction relays we can relay that transaction but if it's based off of the existing mempool rules then a lot of nodes are not going to see both the standard and the non priority transaction relayed because the non priority transactions by default are not generally relayed so it creates this slight gap that the proof fills in a unique way because now we can provide the proofs on those non priority transactions and still not worry about the high bandwidth thresholds that would happen because those non priority transaction may have extremely extensive scripts or do something slightly different okay so I think I get it you're saying this is the argument that in the with a proof system there this opens up the possibility that nonstandard can transactions can be freely relayed things that are currently non-standard they can choose to relay them on their own merit so if I'm sure besides that oh well this isn't a standard transaction but I think that this is reasonable enough that I am going to relay it the proofs allow for that flexibility for the eat those types I don't exactly see how the proofs allow that and also the reasons why that's not done don't have anything to do with have no more to do with redouble spending or zeroconf than or then relaying standard transactions the reasons like I I think the reason we don't relay one megabyte non-standard transactions is because nobody's really worked on what happens when you have a mix of lots of 250 byte transactions and bundt also a lot of mega byte transactions I agree but under maybe maybe it works fine but I say they are allowed to try and if we're not going to free lay the non-priority transaction then there's nodes that are not going to see both they're only going to see the standard transaction they're gonna have no evidence that this double spend actually occurred until a block possibly lands that has this non priority transaction in it since it is not going to relay both with the proof we can reliably prove that this non-priority transaction actually had a conflict and actually relay that proof without worrying about the burden of the non priority transaction being super large well but everybody's going to have the proof generation so they have to parse through it before they create the proof so they also answer the final caveat though which as Tom Harting says it's interesting because it's it's the devil we don't know is if we relay the double spend proofs right and perhaps we don't because we're worried about spam right where is that exact line gonna fall where we're relaying non-priority double spend proofs and how much spam coming this is where I like omni's thought process on this is that it's about a double spent input so if I only have all I need is to provide one proof that I saw two of that input I don't care if there was 42 of that input I need one proof that I saw it twice and that's all I need and the bandwidth requirements are extremely low so I definitely like his thought process there where it's really about the input being double spent it's not about the fact that there was two double spend transit factions is that two transactions shared an input so I don't know whether my last comment could recursive L ask a question yes sir right but I just wanted to actually wanna attack on here but like just what you said like the input right but you have to make sure that like what Tom's Anna said that there is this Pam risk isn't thanks exactly baited because there is now we have a very cheap transaction and that creates a double span right so this is whatever I think that we have to make sure that that these double spend proves I'm not cheap to generate because we have some set of transactions now that that are too cheap like we exhausted this debate and to follow up on the original question of does it hurt permission with permissionless innovation and i think we kind of came to consensus here it does help permissionless innovation I think double spend proves help permissionless innovation because we will always see weird things coming up that we haven't seen yet and you know the changing of policies the ideas of what kind of transactions are standard will most likely change over the next couple of years as more people more businesses and to this space and that should be allowed where double spend proofs essentially just don't don't mind because it's just about the inputs that gets double spends that's it I'm against innovation and don't want anybody new coming into the space I guess that wraps it up oh sure thank you guys