--- Log opened Wed Dec 14 00:00:46 2022
00:04 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
00:04 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
00:23 -!- __gotcha [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
03:22 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
03:22 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
03:42 -!- brunoerg [~brunoerg@187.183.43.178] has joined #bitcoin-core-pr-reviews
04:41 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Read error: Connection reset by peer]
04:41 -!- __gotcha [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
05:32 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
05:32 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews
06:27 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
06:27 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 265 seconds]
07:04 -!- jonatack1 [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
07:06 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
07:14 -!- rozehnal_paul [~rozehnal_@142.157.221.175] has joined #bitcoin-core-pr-reviews
07:24 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Read error: Connection reset by peer]
07:25 -!- __gotcha [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
07:58 < rozehnal_paul> anyone here early?
08:09 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
08:12 -!- b_101_ [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
08:16 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 272 seconds]
08:34 -!- brunoerg [~brunoerg@187.183.43.178] has quit [Remote host closed the connection]
08:34 -!- Eppie [~Eppie@102.89.32.147] has joined #bitcoin-core-pr-reviews
08:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
08:39 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit [Ping timeout: 265 seconds]
08:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
08:50 -!- jesseposner [~jesse@user/jesseposner] has quit [Quit: Textual IRC Client: www.textualapp.com]
08:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit [Ping timeout: 256 seconds]
08:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
08:52 -!- jesseposner_ [uid580595@user/jesseposner] has joined #bitcoin-core-pr-reviews
08:53 < LarryRuane> hi rozehnal_paul: .... we'll get started in about 7 minutes
08:54 -!- jesseposner_ [uid580595@user/jesseposner] has quit [Client Quit]
08:54 -!- jesseposner_ [uid580595@id-580595.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
08:54 -!- jesseposner_ [uid580595@id-580595.ilkley.irccloud.com] has quit [Client Quit]
08:55 -!- jesseposner [uid580595@user/jesseposner] has joined #bitcoin-core-pr-reviews
08:56 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit [Ping timeout: 252 seconds]
08:59 -!- Jmy [~Jmy@dynamic-046-114-003-065.46.114.pool.telefonica.de] has joined #bitcoin-core-pr-reviews
09:00 -!- d33r_gee [~d33r_gee@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:00 < d33r_gee> hello
09:00 < stickies-v> hi
09:00 -!- guest647 [~guest6@5E1B91B1.dsl.pool.telekom.hu] has joined #bitcoin-core-pr-reviews
09:01 < rozehnal_paul> hi
09:01 < Jmy> Hi everyone
09:01 < andrewtoth_> hi
09:01 < guest647> hi
09:01 < b_101_> hi
09:01 < ishaanam[m]> hi
09:02 < LarryRuane> #startmeeting
09:02 < LarryRuane> hi!
09:02 < emzy> hi
09:02 < schmidty_> hi
09:02 < theStack> hi
09:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
09:02 < LarryRuane> welcome everyone! today we'll be discussing https://bitcoincore.reviews/26631 "test: add coverage for dust mempool policy (-dustrelayfee setting)"
09:03 < glozow> hi
09:03 < LarryRuane> feel free to say hi so we know who's present!
09:03 < lightlike> hi
09:03 -!- w0xlt_ [sid555702@id-555702.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:03 < LarryRuane> By the way, if anyone has a suggestion for a PR to review, or if you'd like to volunteer to host a review club, please leave a comment here or DM me on IRC!
09:04 < LarryRuane> So what do people think of this PR, any general thoughts? 
09:05 < LarryRuane> Any questions on the Notes for today's review? Anything not clear or you'd like to discuss?
09:05 < rozehnal_paul> Seems like a non-controversial PR, more testing the better..
09:06 < LarryRuane> rozehnal_paul: +1
09:06 < LarryRuane> Who had a chance to review the PR?
09:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit [Ping timeout: 246 seconds]
09:07 < d33r_gee> question on running the test... is it done by running test_framework.py?
09:07 < b_101_> y/tested ACK
09:07 < LarryRuane> We're honored to have the PR author here, @theStack
09:08 -!- Jmy [~Jmy@dynamic-046-114-003-065.46.114.pool.telefonica.de] has quit [Quit: Ping timeout (120 seconds)]
09:08 < theStack> d33r_gee: the simplest is to directly call the python file, i.e. $ ./test/functional/mempool_dust.py
09:08 < b_101_> d33r_gee: you can run it directly `test/functional/mempool_dust.py`
09:08 < schmidty_> Echoing rozehnal_paul , perhaps question for LarryRuane /group: what would be a common reason to NACK a PR that adds testing coverage?
09:08 < LarryRuane> and I want to thank him, and @glozow for their help in preparing for this review club meeting!
09:09 < d33r_gee> theStack thanks! will try that
09:09 < LarryRuane> I can't think of a reason to NACK, but only to make some suggestions
09:09 < glozow> Tests require maintenance too. A test should be clear enough such that, in the future, if it fails, we know what's gone wrong in the code.
09:09 < andrewtoth_> yes, but that would be a reason to suggest changes, not NACK right?
09:10 < theStack> schmidty_: one reason that i could think of NACKing is if a test is too resource-hungry or takes too long
09:10 < theStack> andrewtoth_: +1
09:10 < rozehnal_paul> +1 @gloz
09:10 < glozow> andrewtoth_: sure
09:10 < rozehnal_paul> woops
09:10 -!- Jmy [~Jmy@dynamic-046-114-003-065.46.114.pool.telefonica.de] has joined #bitcoin-core-pr-reviews
09:10 < LarryRuane> one mistake I used to make in writing tests is to make them too fragile ... if the test makes a very narrow requirement for the result, then it can break in the future when there's not really anything wrong
09:11 < rozehnal_paul> +1 glozow : if the approach needs to be rethought, it ought to be NACKd
09:11 < LarryRuane> there's quite an art to writing a good test ... you want it to verify correct functionality (not leave something important unverified), but not be overly specific
09:12 < ishaanam[m]> andrewtoth_: another reason for NACKing could be if the suggested test could make more sense as a unit test instead of a functional test. 
09:12 < glozow> ishaanam[m]: +1
09:12 < LarryRuane> I think another trend we'd like to promote for testing is move from functional (python) tests to unit tests, when possible
09:12 < d33r_gee> tested ACK
09:12 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
09:13 < LarryRuane> or even make code changes that make it *possible* to test with unit tests ... when something fails in a unit test, it's often much easier to narrow down where the problem is, because you're not running as much code
09:13 < b_101_> LarryRuane: can you elaborate the rationale for that?
09:13 < LarryRuane> i think the refactoring effort in the P2P layer has this as one of its goals
09:13 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
09:15 < LarryRuane> well, functional tests run one or more full nodes, and there are more chances for false failures due to timing windows or things like, shutting down and restarting nodes being less .... reliable?
09:15 < schmidty_> And speed?
09:15 < b_101_> LarryRuane: ok, thx
09:15 < LarryRuane> also as I said, when something goes wrong, there's so much code that's being run by the test, it may be hard to tell where the problem actually is
09:16 < LarryRuane> schmidty_: +1 yes, unit tests can run MUCH faster than functional tests for a given amount of actual testing ... you don't have the delays in starting up the nodes, for example
09:17 < LarryRuane> great question! I think we'll always have the functional tests, but the more that can be tested in unit test the better, all else equal
09:17 < rozehnal_paul> LarryRuane implying that unit tests do not require full-node usage nor starts&stops?
09:17 < rozehnal_paul> just to be clear
09:18 < theStack> talking about speed, in an earlier version of the PR the test used multiple nodes, one for each config options (like it's currently done e.g. in mempool_datacarrier.py)... even with a small number of nodes, the test took significantly longer to be setup (non-surprisingly), so i changed to one node that is just restarted
09:18 < LarryRuane> rozehnal_paul: yes that is correct
09:18 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit [Ping timeout: 265 seconds]
09:18 < b_101_> theStack: +1
09:19 < LarryRuane> theStack: one thing I wondered, would it be a good idea to have an RPC to change this dustrelayfee, do you think? maybe test-only?
09:19 < LarryRuane> then you wouldn't need to restart the node at all ... something i wondered as i reviewed the PR
09:19 < LarryRuane> of course that's then changing production code! no longer just a test-only PR! (so harder to get merged)
09:20 -!- brunoerg [~brunoerg@187.183.43.178] has joined #bitcoin-core-pr-reviews
09:20 < LarryRuane> we're kind of into question 2 already, but can anyone tell us, How does the test work? What is its approach?
09:21 < b_101_> It creates all posible Script types including a couple future SegWit versions, and try each of this scripts on a list of `-dustrelayfee` arbitrary settings, including the default of `-dustrelayfee` of 3000
09:23 < LarryRuane> yes, it tests various combinations along 2 dimensions (that's why you see two nested loops in `run_test`
09:23 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:23 -!- Jmy [~Jmy@dynamic-046-114-003-065.46.114.pool.telefonica.de] has quit [Quit: Connection closed]
09:24 < rozehnal_paul> sorry if this is off-track, but i couldn't read line 102: [.8f] isn't something i could recognize
09:24 < rozehnal_paul> what does .8f mean
09:24 < schmidty_> theStack: 1337 haha
09:24 -!- brunoerg [~brunoerg@187.183.43.178] has quit [Ping timeout: 272 seconds]
09:24 -!- Jmy [~Jmy@dynamic-046-114-003-065.46.114.pool.telefonica.de] has joined #bitcoin-core-pr-reviews
09:24 < rozehnal_paul> schmidty_ lol
09:25 < LarryRuane> rozehnal_paul: no that's not off-track, that's a great question .. are you familiar with the "f" strings that python3 now supports?
09:25 < glozow> it means display a float to the 8th decimal point
09:26 < LarryRuane> formatted strings ... provides a more convenient way to, well, format strings! I think the .8f means floating point with 8 digits of precision (to the right of the decimal point)
09:26 < rozehnal_paul> LarryRuane not really but i just googled it. thanks & thanks glozow
09:27 < LarryRuane> good question! it's nice when we cover actual code in these review clubs! :)
09:27 < theStack> if someone is wondering why the `.8f` was needed, start up your python interpreter and type in "0.00000001". what you see as a result is a notation that bitcoind can't make sense of
09:27 < theStack> schmidty_: xD
09:28 < LarryRuane> there's a whole family of script generation functions such as `key_to_p2pk_script()` that are very interesting to examine .. @theStack added those in a previous PR, very helpful to both the tests and for understanding
09:28 < rozehnal_paul> theStack python3 changed it to scientific notation [when accessed from a variable name at leat]
09:29 < theStack> rozehnal_paul: exactly!
09:30 < LarryRuane> feel free to continue previous discussions, but let's get to Q3, Why is the concept of dust useful? What problems might occur if it didn’t exist?
09:30 < schmidty_> theStack: thoughts on doing the output_key_to_p2tr_script helper doing the truncation itself?
09:30 -!- Eppie [~Eppie@102.89.32.147] has quit [Quit: Ping timeout (120 seconds)]
09:31 < michaelfolkson> hi
09:31 < LarryRuane> schmidty_: can you explain why the `pubkey[1:]` is there?
09:31 < theStack> the review club session LarryRuane is talking about was https://bitcoincore.reviews/22363, hosted by glozow. for anyone learning about scripts and output types, it's a great exercise to fill out this table there
09:31 < schmidty_> LarryRuane: I believe x-only-pubkeys, saving a byte: https://bitcoinops.org/en/newsletters/2019/11/13/#x-only-pubkeys
09:31 < rozehnal_paul> dust could be used as an attack vector by enlarging the utxo set, as dust has to be accounted for by fullnodes, and if there are 50million dust outpusts to account for, then fullnodes get...tired.
09:32 < d33r_gee> Q3:  it helps to keep the size of the UTXO set small, which is important for maintaining the decentralization of the Bitcoin network.
09:32 < rozehnal_paul> so we preempt the attack by creating the idea that there are transactions that are too small to be valid\
09:32 < LarryRuane> schmidty_: beautiful! Everyone here should be reading Optech each week, by the way!
09:32 < b_101_> This expression list the bytes object skipping the first byte, since `pubkey` is a compressed public key, the first byte indicate `x02=even`, `x03=odd`. This piece of data plus the `x` coordinate (bytes 2 to 33) is used to calculate `y` in compressed keys
09:33 < LarryRuane> rozehnal_paul: yes, great answer!
09:34 < LarryRuane> b_101_: +1
09:34 < theStack> schmidty_: theoretically the output_key_to_p2tr_script helper could be adapted to accept both legacy and x-only-pubkeys, by looking at size, yes. not sure if we would really need it that often though, i think for using p2tr we usually create x-only-pubkeys from the start
09:36 < ishaanam[m]> rozehnal_paul: these transactions are technically still valid and can be mined into valid blocks. However these transactions are considered non-standard, which means that they are not relayed to other nodes.
09:36 < b_101_> My understanding is that uncompressed pubkeys are disallowed for non legacy descriptors/scripts since segwit implementation, is this right?
09:36 < LarryRuane> having a dust limit is what i would say an anti-DoS measure ... many things in Bitcoin Core are anti-DoS!
09:36 < LarryRuane> (the first part of the Notes covers this)
09:36 < theStack> ishaanam[m]: +1
09:37 < schmidty_> Thoughts on the concept of dust becoming less useful as p2tr gets more widely adopted (more folks using scripts and the cost to spent the output being largely unknown)?
09:38 < LarryRuane> schmidty_: That's a great point, the dust caclulation has to sort of "guess" at how big the future spending input will be, and with p2tr, that's gets harder
09:39 < michaelfolkson> No different to P2SH or P2WSH though right? Script is still hashed until you come to spend
09:40 < michaelfolkson> Maybe encourages use of longer scripts
09:40 < LarryRuane> michaelfolkson: good point, but is the variation greater with p2tr?
09:41 < LarryRuane> Q4 has been partially answered by ishaanam[m]: "What is the difference between valid transaction and a non-standard transaction?"
09:41 < rozehnal_paul> schmidty_ very interesting
09:41 < rozehnal_paul> ishaanam[m] what stops a malicious miner from accepting dust, and thereby circumventing our Dust-Dos-Defense??
09:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
09:42 < schmidty_> michaelfolkson: exactly. Id anticipate more p2tr since you can bring along complex scripts "for free" (keyspend case)
09:42 < rozehnal_paul> ishaanam[m] **
09:42 < rozehnal_paul> could you elaborate or send a link for those (me) who wants to learn about 'keyspend case'
09:42 < rozehnal_paul> schmidty_ ^
09:43 < LarryRuane> rozehnal_paul: "what stops a malicious miner from accepting dust" -- nothing! but by not forwarding, it's much less likely that a miner will ever see transactions with dust outputs
09:43 < ishaanam[m]> LarryRuane: +1
09:44 < LarryRuane> for that reason (second part of Q4): Would it be better if transactions that don’t meet the dust treshhold were considered invalid?
09:44 < theStack> rozehnal_paul: this workshop is great for learning taproot https://bitcoinops.org/en/schorr-taproot-workshop/ covers both key-path and script-path spends
09:45 < rozehnal_paul> LarryRuane A miner creating and trying to mine its own dust transaction would soon go bankrupt, I would imagine.
09:45 < rozehnal_paul> Q4P2: There is likely a reason I'm missing, but I don't see why dust txs are invalidated outright
09:45 < rozehnal_paul> thx theStack
09:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit [Ping timeout: 256 seconds]
09:47 < ishaanam[m]> For Q4: I don't think that would be better because as mentioned previously, this is more of a "guess" so I don't think that it would make sense to hold all transactions to this partially arbitrary standard for validation.
09:47 < LarryRuane> I think the answer is (but others chime in), if we make dust part of consensus, then we could never lower it later, because that would be relaxing a rule, which would be a hardfork
09:48 < LarryRuane> it would make tx that were previously illegal, now legal ... we could *raise* the dust limit, that would be a softfork ... (do i have this right, anyone?)
09:49 < theStack> LarryRuane: that's also my understanding
09:49 < LarryRuane> this relates to Q9: "Can you see a future scenario where we’d want to change the default value of -dustrelayfee? Would it more likely be increased or decreased? What does this depend on and which other configuration options would then also very likely be adapted?"
09:49 < schmidty_> Im not sure how prevalent they are anymore, but protocols built on Bitcoin like counterparty allowed issuance of tokens. Some of those tokens could have a high $ value, but be stored in a low BTC value output.
09:51 < LarryRuane> schmidty_: interesting! so this might be a reason to lower the dust limit in the future? I was thinking if BTC because much more valuable per unit in the future, what's considered dust today would not be then
09:51 < LarryRuane> (similar to what you said)
09:51 < rozehnal_paul> spitballing: if tx fees were somehow lowered in the future, we could lower the dust limit, as it would cost less to spend. not sure how this would affect other config.options
09:52 < rozehnal_paul> Q9
09:52 < schmidty_> Not sure either way, just pointing out theres a lot of non BTC value in BTC outputs which complicates the dust idea.
09:52 < theStack> thought experiment for Q9: let's say for years blocks are more or less constantly full with a minimum fee-rate of hundreds of sats/vbyte. would that be a reason to *increase* the default dust-limit at some point?
09:53 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
09:54 < LarryRuane> seems like that's true! hard to get my mind around!
09:55 < schmidty_> theStack: I would think so. Fun fact:There was a period of high fees in 2017 and due to poor UTXO management, Coinbase had a bunch of small value UTXOs that were worth less than the fee to spend them (https://irishtechnews.ie/coinbase-accused-of-incompetence-after-hoarding-millions-of-utxos/).
09:55 < LarryRuane> i think that's the answer we (or actually @theStack, who wrote this question) was looking for, the `incrementalrelayfee=` option might want to change also
09:55 < michaelfolkson> A fee market denominated in Bitcoin so shouldn't be impacted by price of Bitcoin in fiat terms but purely the demand for block space
09:55 < LarryRuane> schmidty_: did they spend them anyway?
09:56 < michaelfolkson> If demand for block space was permanently much higher then yeah you'd probably want to increase dust feerate as no chance of current dust getting into a block
09:57 < schmidty_> LarryRuane: consolidated a few months later I believe: https://medium.com/@alcio/when-the-bitcoin-dust-settles-878f3431a71a
09:57 < rozehnal_paul> schmidty_ that event in 2017 is how i first heard of dust!
09:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit [Ping timeout: 260 seconds]
09:58 < LarryRuane> schmidty_: thanks, we're getting close on time, is there any remaining question anyone would like to bring up or answer?
09:58 < rozehnal_paul> +1 consolidated a few months later
09:59 < Jmy> Is it possible in theory to merge multiples UTXOs by using cross-input signature aggregation and then spend all these poorly managed UTXOs at once (paying also the tx-fee only once)?
09:59 < LarryRuane>  looks like we've already covered Q12
10:00 < LarryRuane> cross-input sig aggregation isn't implemented yet, IIUC
10:00 < b_101_> What did you mean by: Why is -dustrelayfee a hidden (or debug) option?
10:00 < LarryRuane> ok sorry, we're at time, please feel free to keep discussing!
10:00 < LarryRuane> #endmeeting
10:01 < svav> Thanks all
10:01 < d33r_gee> thanks everyone
10:01 < emzy> Thanks everyone!
10:02 -!- d33r_gee [~d33r_gee@45-27-31-99.lightspeed.sntcca.sbcglobal.net] has quit [Quit: Connection closed]
10:02 < michaelfolkson> Thanks!
10:02 < theStack> thanks for hosting LarryRuane and to all participants!
10:02 < LarryRuane> thanks to everyone for contributing! and especially @theStack for the PR!
10:02 < ishaanam[m]> thanks!
10:02 < schmidty_> Thanks LarryRuane and theStack 
10:02 < Jmy> Thanks all of you!
10:02 < theStack> i'm also still around for ~30 minutes if anyone wants to continue discussing
10:03 < LarryRuane> theStack: what's the answer to Q10 "Q4 has been partially answered by ishaanam[m]: "What is the difference between valid transaction and a non-standard transaction?" ... i'm not sure!
10:03 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
10:03 < LarryRuane> oh sorry, copy-paste error,
10:03 < andrewtoth_> thanks LarryRuane!
10:04 < LarryRuane> What does the largest possible output script that adheres to standardness rules look like? Is it currently implemented in the functional test?
10:04 < rozehnal_paul> Thanks So much, cant wait till next week
10:04 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:05 < theStack> any participants still around that want to answer Q10?
10:05 < LarryRuane> my *guess* is that `key_to_p2pk_script(uncompressed_pubkey)` would be the largest
10:05 < rozehnal_paul> im here
10:05 < theStack> it's already on the larger side compared to widely used output scripts, but still far from the largest :)
10:05 < schmidty_> Jmy: Absent cross input aggregation, in theory a miner during low fees could allow a block of dust to be spent with no fees to cleanup UTXO set as a service to node operators. Not sure where the output of all that dust would go though.
10:06 < b_101_> thank you all
10:07 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
10:07 < theStack> hint for Q10: think about an output script type that is even less used than P2PK
10:08 < theStack> (or well, at least less used _nowadays_...)
10:08 -!- dulcedu [~dulcedu@172.92.166.6] has joined #bitcoin-core-pr-reviews
10:08 < LarryRuane> schmidty_: this is interesting, so a miner could advertise on twitter or somewhere, "directly send me zero-fee transactions, and if they spend dust and don't create MORE dust, i'll mine them" just to be nice? wouldn't the people sending those transactions decide where the output goes?
10:08 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit [Ping timeout: 265 seconds]
10:08 < LarryRuane> does anyone know how many dust UTXOs exist currently?
10:09 < michaelfolkson> Less than P2PK? A future witness version :)
10:09 < schmidty_> LarryRuane: sure they would decide, but it would just be a dust output again unless it was aggregated into larger output amounts.
10:10 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
10:10 < theStack> michaelfolkson: heh, good one :D those are way too short though for being candidates for the answer
10:11 < schmidty_> theStack: bare multisig?
10:11 < theStack> LarryRuane: interesting question about how many dust UTXOs... might be a nice mini-project to find that out
10:11 < theStack> schmidty_: bingo!
10:12 < LarryRuane> schmidty_: is that standard tho?
10:12 < LarryRuane> oh it is! okay cool, TIL!
10:12 < theStack> what are the specifics of the _largest_ bare multisig considered standard?
10:12 < LarryRuane> guessing 3/5?
10:13 < LarryRuane> i see your test does have "bare multisig (3-of-3)"
10:14 < theStack> yes, but is that specific one really the largest one? (what kind of pubkeys does it use?)
10:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit [Ping timeout: 246 seconds]
10:14 < schmidty_> LarryRuane: Unchained did some research on this previously, but its out of date: https://unchained.com/blog/dust-thermodynamics/
10:14 < LarryRuane> compressed!
10:15 < LarryRuane> schmidty_: +1 thanks!
10:15 < theStack> LarryRuane: exactly, i.e. it's not the maximum size
10:16 < LarryRuane> i changed the test to: `keys_to_multisig_script([uncompressed_pubkey]*3)` and it still passes
10:16 -!- orangecoinchaser [~orangecoi@pool-72-69-81-87.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews
10:16 < schmidty_> "During the high-fees market of late 2017, 15–20% of all UTXOs had value densities below the lowest fee of 50–60 Satoshi/byte, making them almost impossible to spend. 40–50% of all UTXOs had value densities below the average fee of 600–700 Satoshi/byte, making them harder to spend."
10:16 < LarryRuane> would that be good to add as another test case, do you think?
10:16 < theStack> LarryRuane: exactly, and that's the maximum AFAICT
10:16 < theStack> LarryRuane: agree!
10:17 < Jmy> schmidty_: iicu this means that e.g. once a year people who know that they have some dust around could negotiate where to send all of that, maybe to donate somewhere? And the miner could then creat a new output which then is no dust anymore and could be spend by someone else?
10:17 < schmidty_> Jmy: They could donate to Brink. Hear those grantees do great work.
10:17 < LarryRuane> schmidty_: interesting, I heard a rumor that Roger Ver was behind the attack (if you want to think of it that way) to generate very high fees ... to make BCH look better
10:18 < theStack> in pre nulldata (OP_RETURN) times i think people used primarily bare multisig outputs to store arbitrary data in blocks
10:18 < LarryRuane> theStack: "that's the maximum AFAICT" -- what about 3 of 5?
10:18 < theStack> LarryRuane: standardness rules only allow up to n=3
10:18 < LarryRuane> theStack: i read that too
10:18 < LarryRuane> theStack: i see, thanks
10:19 < theStack> the m in m-of-n doesn't matter by the way, as it doesn't change the output script size
10:19 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has quit [Remote host closed the connection]
10:19 < LarryRuane> OH, good point
10:19 < Jmy> schmidty: cool, thanks for your explanation
10:20 < Jmy> schmidty_: cool, thanks for your explanation
10:20 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
10:20 < rozehnal_paul> neat
10:21 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined #bitcoin-core-pr-reviews
10:21 < LarryRuane> theStack: curious, did you look into doing this test as a unit test, is it possible?
10:21 < LarryRuane> if not, it would be interesting to see what would be required to make it unit-testable
10:22 < theStack> LarryRuane: good question, didn't look into it, i'm more familiar with the functional ones
10:22 < rozehnal_paul> LarryRuane is your preference for unit > functional tests universal in software engineering, or specific to bitcoin? and is unit > functional testing preference controversial or pretty accepted?
10:22 < LarryRuane> functional tests ARE very cool, i love how easy they are to read!
10:23 < michaelfolkson> You've got PRs merged with unit tests in the past though right theStack?
10:23 < michaelfolkson> i swear I've seen some
10:23 < LarryRuane> rozehnal_paul: i think it's universal, not just bitcoin core
10:24 < schmidty_> rozehnal_paul: Not Bitcoin specific. Back in my web engineering days the preference was similar. Unit test (run frequently) everything where possible (using mock objects if needed) and "integration" tests to test that everything is working together (run less frequently)
10:24 < LarryRuane> maybe i overstated it during review club ... it's important to have both, unit tests that zero in on one piece of logic, but also functional tests to make sure everything can work together
10:24 < theStack> michaelfolkson: yeah there must have been some, a longer time ago
10:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit [Ping timeout: 256 seconds]
10:25 < LarryRuane> it's conceivable that unit tests covering two different subsystems both pass, but then when you put them together, one makes an unwarranted assumption about the other, so the functional test fails
10:25 < michaelfolkson> I didn't realize how many PRs you've got merged. 235! Mostly functional tests I think
10:26 < rozehnal_paul> thx
10:26 < LarryRuane> (or integration tests, as @schmidty_ said -- YES, we used that term in earlier projects i've worked on!)
10:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
10:27 < LarryRuane> "how many PRs you've got merged" -- theStack is really a machine! (haha)
10:28 < theStack> michaelfolkson: some of them really small refactorings also. i feel like the number of commits/PRs alone is kind of an inadequate measure alone
10:28 -!- dulcedu53 [~dulcedu@172.92.166.6] has joined #bitcoin-core-pr-reviews
10:29 < theStack> anyone wants to give a shot at Q13 "Can you give an example of an output script that is considered standard and is added to the UTXO set (i.e. no null-data), but is still unspendable? Bonus: is there a way to create such an output script where this unspendability can even be mathematically proven?"? i thought this one was fun
10:30 -!- dulcedu53 [~dulcedu@172.92.166.6] has quit [Client Quit]
10:30 < LarryRuane> as long as we're on the topic of tests, one thing i learned the hard way over the years is to keep the tests EXTREMELY SIMPLE, they don't have to be efficient! Here's a great example: https://github.com/bitcoin/bitcoin/blob/678889e6c6231cf461de59eefe6fb8eb07468848/src/test/util_tests.cpp#L275
10:31 < michaelfolkson> theStack: Requiring a signature from a public key that doesn't have an associated private key?
10:31 < LarryRuane> (this is a positive example, BTW, not a negative example!) this sequence of tests could have been written with some clever loop,
10:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit [Ping timeout: 256 seconds]
10:31 < LarryRuane> but then the reader would have to understand how the loop works and confirm that it's correct... the way it's actually written is SO obvious
10:32 < theStack> LarryRuane: hehe nice one
10:32 < theStack> michaelfolkson: yes, but can you prove that there is no associated private key?
10:33 < LarryRuane> michaelfolkson: your answer sounds right ... if the public key is like 0000000000000... then
10:33 < LarryRuane> we can be PRETTY sure that no one has a private key that goes with that, although theortically possible?
10:35 < LarryRuane> to go back to what i was saying about testing ... if the test is complex (to save lines of code, cpu time, memory, whatever), then you might feel the need to write a test for the test! we DON'T want to go there!!
10:36 < theStack> LarryRuane: yeah, for all those "theoretically possible" cases we can't mathematically prove that it's unspendable... but there are possibilities for output scripts that are guaranteed to be unspendable
10:37 < LarryRuane> OP_FALSE?
10:37 < theStack> that also, but i mean ones that are considered standard
10:37 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
10:37 < LarryRuane> oh i see.. hmm no i can't think of it!
10:37 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
10:38 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:38 < theStack> it's scripts that contain a public key that is not on the curve
10:39 < theStack> i.e. ones that don't fulfill the secp256k1 y^2 = x^3 + 7 equation
10:39 < michaelfolkson> Does Taproot prevent including public keys not on the curve?
10:40 < michaelfolkson> Need to check the BIP. It suggests using a random public key *on* the curve when you want to encode an unspendable path
10:41 < instagibbs> you can't spend them, but you can make them
10:41 < theStack> michaelfolkson: it doesn't prevent. i naively opened a PR a while ago trying to change those to be considered non-standard, but didn't consider the implications for e.g. exchanges: https://github.com/bitcoin/bitcoin/pull/24106
10:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit [Remote host closed the connection]
10:42 < michaelfolkson> Ha interesting PR, I never saw this one
10:43 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has joined #bitcoin-core-pr-reviews
10:43 < LarryRuane> really interesting comments on that PR!
10:44 < michaelfolkson> I think I was preoccupied with something else in January of this year
10:44 < michaelfolkson> Why I missed it
10:44 < michaelfolkson> But yeah its a fun one
10:44 < theStack> here is the wallet-related variant of the same PR btw: https://github.com/bitcoin/bitcoin/pull/24121 it was rejected with the same reasoning
10:45 < LarryRuane> amazing how much can be learned by closed PRs!
10:45 < LarryRuane> *by reading closed PRs
10:47 < michaelfolkson> So should it have been disallowed by consensus in the original soft fork? I'm guessing no
10:47 < michaelfolkson> Because you might want to use an unspendable path
10:48 < instagibbs> you'd have to update wallet address decoding software to not send to it
10:48 < instagibbs> f.e.
10:48 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
10:49 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:49 < michaelfolkson> Oh of course, yeah
10:49 < instagibbs> I just read that off the closed PR :) good history
10:49 -!- Jmy [~Jmy@dynamic-046-114-003-065.46.114.pool.telefonica.de] has quit [Ping timeout: 256 seconds]
10:50 < schmidty_> Bitcoin NOPtech, for coverage of unmerged PRs
10:50 < theStack> i wonder if sending to pubkeys that are not on the curve would have been invalid since the beginning, if that would have prevented storing big amounts of data in bare multisig outputs
10:50 < theStack> on the other hand, one could always use the output scripts with hashes for that...
10:51 < theStack> schmidty_: haha i'd subscribe immediately
10:51 < LarryRuane> schmidty_: haha love that!
10:52 < LarryRuane> theStack: good point, no way to check if a hash has a preimage!
10:53 < theStack> so maybe it would have been even worse because people stored the same data divided up into a larger number of UTXOs
10:53 < instagibbs> there's an old (never deployed) gmax idea to gossip partial preimages of p2sh to force people to do lot of hash work to store stuff in utxo set, somewhere on bitcointalk...
10:54 -!- dulcedu [~dulcedu@172.92.166.6] has quit [Quit: Connection closed]
10:56 < theStack> instagibbs: cool, if you happen to find that again, would love to read it
11:02 -!- rozehnal_paul [~rozehnal_@142.157.221.175] has quit [Quit: Connection closed]
11:02 < instagibbs> Can't figure out what search terms to use, heh
11:04 < instagibbs> I suspect the idea was something like: in p2p, p2sh outputs must be accompanied by the ripemd160 preimage(sha2 hash of the redeemscript) in order to be propagated
11:07 < instagibbs> so to use the utxo set as a storage layer, you'd have to do quite a bit of hashing generating a 32 byte preimage that does that
11:08 -!- guest92 [~guest@5E1B91B1.dsl.pool.telekom.hu] has joined #bitcoin-core-pr-reviews
11:09 -!- guest92 is now known as h7
11:25 -!- jonatack1 [~jonatack@user/jonatack] has quit [Ping timeout: 246 seconds]
11:26 -!- orangecoinchaser [~orangecoi@pool-72-69-81-87.nycmny.fios.verizon.net] has quit [Quit: Connection closed]
11:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:b49d:c24b:e260:b4c0] has quit []
12:23 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:46 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
13:04 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 272 seconds]
13:23 -!- jonatack1 [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
13:42 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
14:13 -!- furszy [~furszy@user/furszy] has quit [Quit: ZNC - https://znc.in]
14:13 -!- furszy [~furszy@104.128.239.93] has joined #bitcoin-core-pr-reviews
14:46 -!- furszy [~furszy@104.128.239.93] has quit [Changing host]
14:46 -!- furszy [~furszy@user/furszy] has joined #bitcoin-core-pr-reviews
16:29 -!- jrawsthorne [~jrawsthor@static.235.41.217.95.clients.your-server.de] has quit [Quit: ZNC 1.8.1 - https://znc.in]
16:59 -!- BUSY [~BUSY@user/busy] has quit [Remote host closed the connection]
17:02 -!- BUSY [~BUSY@user/busy] has joined #bitcoin-core-pr-reviews
17:08 -!- guest647 [~guest6@5E1B91B1.dsl.pool.telekom.hu] has quit [Ping timeout: 268 seconds]
17:08 -!- h7 [~guest@5E1B91B1.dsl.pool.telekom.hu] has quit [Ping timeout: 260 seconds]
18:38 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
18:39 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
18:40 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Client Quit]
18:42 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
19:29 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Read error: Connection reset by peer]
19:32 -!- __gotcha [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
20:25 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Read error: Connection reset by peer]
20:25 -!- b_101_ [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 246 seconds]
20:26 -!- __gotcha [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
20:39 -!- __gotcha [~Thunderbi@85.234.220.109] has quit [Read error: Connection reset by peer]
20:39 -!- __gotcha1 [~Thunderbi@85.234.220.109] has joined #bitcoin-core-pr-reviews
20:41 -!- __gotcha1 is now known as __gotcha
22:02 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
22:07 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 252 seconds]
22:23 -!- ___nick___ [~quassel@cpc68289-cdif17-2-0-cust317.5-1.cable.virginm.net] has quit [Ping timeout: 272 seconds]
--- Log closed Thu Dec 15 00:00:46 2022