--- Log opened Mon Mar 01 00:00:45 2021
00:25 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]
00:29 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
01:09 -!- realname192 [~real@37.163.172.156] has joined ##taproot-activation
01:18 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 245 seconds]
01:38 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
01:41 -!- jonatack [~jon@37.173.106.99] has joined ##taproot-activation
01:54 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
02:00 -!- realname192 [~real@37.163.172.156] has quit [Quit: Leaving]
02:23 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
02:24 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
02:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
07:08 < darosior> Thanks aj for the answer to the "LOT=False is dangerous" FUD post on the ML
07:16 -!- brg444 [uid207215@gateway/web/irccloud.com/x-grayfyxgnmhtyjsj] has joined ##taproot-activation
08:04 -!- criley [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation
08:10 <@michaelfolkson> darosior aj: Yeah I think aj response is good too. I have no problem with Core releasing LOT=false personally. But some people seem determined to even resist that at the moment so the choice appears to be working towards a community lot=true UASF or endless circular arguments at this point.
08:18 <@michaelfolkson> A community lot=true UASF avoids the F7 argument which was the key one I think. Getting a lot=true out there without putting the responsibility on Core seems the only option to pursue whilst people are willing to block Core releasing anything activation related
08:48 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 260 seconds]
09:13 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation
09:29 -!- CARO1 [~Cesar@2804:7f4:c19d:f7fa:1da1:7c2a:5e33:7061] has joined ##taproot-activation
09:30 -!- CARO2 [~Cesar@2804:7f4:c19d:f7fa:e47f:3edd:f411:1666] has joined ##taproot-activation
09:33 -!- CARO3 [~Cesar@2804:7f4:c19d:f7fa:7c3a:c9c7:c1a3:9e77] has quit [Ping timeout: 272 seconds]
09:34 -!- CARO1 [~Cesar@2804:7f4:c19d:f7fa:1da1:7c2a:5e33:7061] has quit [Ping timeout: 272 seconds]
09:36 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
09:47 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
09:47 < maybehuman> I was almost tempted to write a "LOT=true is an attack on Bitcoin" post as a response :-)
09:48 < maybehuman> because it kind of is. The argument being that a small economically relevant group can basically decide the lot question (and hence softfork activation) seems really dangerous
09:49 < maybehuman> e.g. if Brian Armstrong decided that Coinbase is going with lot=true, that (and a few angry Twitter users making noise) would already be enough to fulfill the criteria
09:51 < maybehuman> so the community follows, the softfork activates, everybody is happy, only five years down the line the government comes to him and asks that he rejects all blocks that don't signal support for some sanctions list
09:51 < maybehuman> how could he refuse? lot true worked so well before..
09:52 < maybehuman> ofc that scenario could also happen without LOT, but that's not a reason to build the tools for this right into Core and so on
09:57 < luke-jr> maybehuman: softfork support != activation
09:57 < maybehuman> meaning?
09:58 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Read error: No route to host]
10:00 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
10:04 < luke-jr> maybehuman: the situation aren't even comparable
10:06 < maybehuman> but the tools work the same in both, no?
10:06 < luke-jr> no
10:06 < luke-jr> activation only works because the community supports it
10:07 < maybehuman> btw, it just occured to me: Couldn't you also implement lot true externally? i.e. have some script listen to new blocks and then call invalidateblock if one doesn't signal
10:07 < luke-jr> if you don't like Taproot, you simply run a node that invalidates Taproot-signalling blocks
10:07 < luke-jr> I could, but a typical user couldn't
10:07 < luke-jr> you could also do the same for any consensus rule
10:10 < maybehuman> I mean, there's the dedicated lot=true client already from what I've read. What I'm saying is instead of maintaining a complete fork of Core, why not just maintain and distribute some Python script?
10:12 < luke-jr> because most people can't use a Python script?
10:15 < maybehuman> I bet if you try, you can add some clickable icon that runs the script which in turn starts the Bitcoin executable. they wouldn't even have to know it's a script
10:16 < maybehuman> and for the people who can use scripts, they can just add it to their existing setup instead of switching to some lower reputation binary
10:18 < luke-jr> no difference..
10:19 < maybehuman> activation only works because the community supports it <-- Is that meant as a statement of a moral principle or is there a technical explanation behind it?
10:20 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
10:21 < luke-jr> maybehuman: activation code does nothing if nobody runs it; why would they run it, if they don't want the protocol change?
10:21 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation
10:22 < jeremyrubin> heh maybehuman i was thinking about the python script last night
10:22 < maybehuman> luke-jr: presumably, because they want to stay in business with Coinbase?
10:22 < luke-jr> maybehuman: then Bitcoin is already lost
10:28 < maybehuman> in any case, it would be enough if the miners ran it
10:29 < luke-jr> no
10:31 < luke-jr> that's called a 51% attack
10:32 < maybehuman> ok. What I'm saying is whatever it's called, it seems to me that it's getting easier to pull off with lot true
10:34 < luke-jr> nope
10:34 < luke-jr> tha'ts just FUD
10:43 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
11:07 -!- niftynei_ is now known as niftynei
11:11 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation
11:18 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed]
11:45 < brg444> lot=true is only as effective as the rough consensus support for the underlying proposal maybehuman
11:51 < luke-jr> Matt's lol "activation w/o signalling" otoh can be used to force any rules :/
11:51 < luke-jr> though it may fail over the long run
11:52 < luke-jr> ironically, it's not reliable by either the pro- or anti- side
12:01 -!- jonatack [~jon@37.173.106.99] has quit [Ping timeout: 264 seconds]
12:02 < belcher> i dont see how matt's flag day signalling can force anything more or less than BIP8/LOT=true, both are flag days except BIP8 allows 95% of miners to activate it early
12:06 < luke-jr> 90% now
12:07 < luke-jr> belcher: let's say you want to reject Taproot. How do you do it?
12:07 < belcher> luke-jr in your email "lot=false is dangerous" you said \""Flag day" activation is not fundamentally flawed or dangerous, just slow since everyone needs time to upgrade.\"
12:07 < luke-jr> belcher: right, that's with signalling
12:07 < luke-jr> flag day without signalling is dangerous
12:08 < luke-jr> note that email was outside the context of these crazy new non-signal ideas :P
12:08 < belcher> what does signalling do? many old soft forks didnt have signalling
12:08 < luke-jr> such as?
12:08 < luke-jr> signalling indicates the softfork is active, so there is no dispute over the correct rules
12:09 < luke-jr> it is well-defined what the "correct" behaviour is if the rule is violated
12:09 < luke-jr> upfront, before anyone risks mony
12:09 < belcher> in a soft fork activated by a flag day, the current height being ahead of the flag day is what indicates that the soft fork is active so that there's no dispute
12:09 < luke-jr> anti-SF folks will disagree
12:10 < belcher> i dont follow
12:10 < belcher> people can disagree with anything, even bip8 lot=true
12:11 < luke-jr> but if they disagree with BIP8(True), they wouldn't be following the Taproot chain; they'd fork off
12:11 < luke-jr> by rejecting the 90%th block
12:11 -!- jonatack [~jon@37.173.106.99] has joined ##taproot-activation
12:12 < belcher> the equivalent for people disagreeing with a flag day activation is that they create a rule which requires an invalid taproot spend transaction
12:13 < luke-jr> that's far more complicated and not doing so doesn't imply Taproot is active
12:14 < belcher> if someone is using a full node with the flag day code as their wallet, then for them taproot is active
12:15 < belcher> as for complicated, sure but many things are complicated... this discussion started because you said flag day UASFs allow developers to force changes onto the community, i say no thats not true because its always possible to do a counter-UASF (in this case, require a taproot-invalid spend)
12:17 < belcher> thats the original reasoning for why UASFs arent necessarily coercive, so for example if coinbase.com tried to push a UASF node which added sanctions blacklists to bitcoin, then the counter-UASF would be that the first block after the flag day requires a spend from one of those addresses.... that's why coinbase's hypothetical UASF would fail
12:18 < luke-jr> and if those addresses won't sign? ;)
12:18 < luke-jr> rejecting a SF should not require jumping through hoops
12:18 < belcher> it already does, theres no "should"
12:20 < belcher> if the addresses wont sign they presumably dont care enough about not being blocked (and in either case a simple address blacklist would easily fail because bitcoin users can generate an infinite number of addresses, but this was just an example)
12:21 < luke-jr> it doesn't with BIP 8
12:22 < belcher> suppose coinbase.com created a soft fork node which used bip8 to add a censorship rule, but they used bip8 to activate it, could the community resist that? of course they could, but they would have to jump through hoops of adopting another client which specifically required a transaction which broke one of those censorship rules
12:23 < luke-jr> no, just reject the signal
12:24 < belcher> and how do they do that? they jump through a hoop by downloading and installing a new node which rejects block headers with a certain version bit set
12:25 < jeremyrubin> invalidateblock signaling blocks
12:27 < belcher> invalidateblock is essentially adding a new consensus rule, and its still jumping through a hoop
12:27 < belcher> i dont even know why "jumping through a hoop" is bad, the whole of bitcoin involves hoops to jump through, you have to download software and install it, save your seed phrase, copypaste addresses or scan QR codes
12:27 < belcher> and in either case theres no "should", saying "users should not have to do X" is pointless, thats just how the thing already works
12:28 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 276 seconds]
12:30 < belcher> it seems bluematt's flag day proposal aims to remove miners entirely from the issue, and removes the objection that "a small % of miners could block the SF"
12:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
12:31 -!- jonatack_ [~jon@37.170.82.107] has joined ##taproot-activation
12:34 -!- jonatack [~jon@37.173.106.99] has quit [Ping timeout: 260 seconds]
12:35 < luke-jr> [20:23:26] <luke-jr> no, just reject the signal
12:36 < belcher> luke-jr so if i understand right, for the main point of the signalling in the block header version bytes is so that nodes could easily reject the soft fork?
12:37 < belcher> for you* the main point
12:37 < luke-jr> and so that it is well-defined that the softfork is active on the chain
12:37 < luke-jr> and with BIP 8, also to help any LOT=False nodes along
12:37 < luke-jr> (or later LOT=True)
12:37 < luke-jr> certainly more than one purpose
12:40 < belcher> regarding the point about it being well-defined if a soft fork is active, have you read matts reply to you about this on the mailing list? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018497.html
12:40 < belcher> it comes down to the fact that the only node which matters is your own, if your own node enforces a certain rule then that rule is active for you
12:50 < luke-jr> that doesn't address it at all
12:52 < luke-jr> I am talking about an objective thing, not subjective
12:52 < belcher> i dont see what signalling actually proves, whats to stop a miner signalling and then not actually enforcing the rule? that happened right after the bip66 soft fork
12:56 < luke-jr> miners don't enforce rules, users do
12:56 < luke-jr> if a user sees a chain split over a rule violation, how should he react if he doesn't really care? an objective criteria is needed to give a clear answer
12:57 < luke-jr> if you want to use Taproot, but you don't know if other nodes will protect it, how do you find out?
13:00 < belcher> you can never know, how do you know today that other users enforce the inflation schedule? its unknowable
13:00 < belcher> you can only ever know for yourself... thats why the slogan was that the only node which matters is your own
13:02 < jeremyrubin> i'm so lucky my node says I have 10,000 BTC
13:02 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
13:03 < jeremyrubin> The only nodes that matter are yours and anyone you hope to do business with... and anyone they hope to do business with... and......
13:03 < jeremyrubin> otherwise we'd all be regtest billionaires
13:06 < belcher> jeremyrubin importantly, anyone who sends you bitcoins, especially if you have the power to say "sorry that transaction was invalid and i wont give you the good or service you bought"
13:08 < jeremyrubin> constructive receipt is a thing
13:08 < jeremyrubin> You wanting to call your regtest Bitcoin doesn't give you magic legal shield
13:16  * jonatack_ regtest billionaires, i like the sound of that
13:18 < belcher> legal arguments dont matter much remember
13:19 < belcher> otherwise its paypal
13:24 <@michaelfolkson> UASF (LOT=true) kick off meeting tomorrow (Tuesday) 19:00 UTC on ##uasf IRC channel https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018515.html
13:41 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation
14:00 -!- Alexandre_Chery [946685a8@148.102.133.168] has joined ##taproot-activation
14:02 -!- Alexandre_Chery [946685a8@148.102.133.168] has left ##taproot-activation []
14:04 < luke-jr> just as block transactions provide consensus on transaction ordering, version bits provide consensus on protocol rules
14:04 < luke-jr> miners can't just put anything - they have to put what nodes consider valid - but it coordinates between those nodes
14:05 < luke-jr> otherwise you get a byzantine general problem
14:06 -!- kiwi_32 [946685a8@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.133.168] has joined ##taproot-activation
14:07 -!- kiwi_32 [946685a8@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.133.168] has quit [Client Quit]
14:08 -!- kiwi_32 [946685a8@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.133.168] has joined ##taproot-activation
14:09 -!- kiwi_32 is now known as Alexandre_Chery
14:09 -!- Alexandre_Chery [946685a8@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.133.168] has quit [Client Quit]
14:15 < belcher> luke-jr do you remember this? https://github.com/xtbit/notbitcoinxt a bitcoin node which pretends to be a forknode BitcoinXT, including setting the version bits if its used to mine... but doesnt actually follow any different consensus rules
14:15 < luke-jr> so?
14:15 < belcher> version bits is a fiction, theres nothing that says users have to actually follow what version bits say
14:17 < belcher> theres actually no way to tell what rules other nodes are enforcing, ultimately all you can do is try to trade with them and see if you get the message "sorry your money is no good here"
14:17 < belcher> so not using version bits cant be a reason against bluematt's flag day proposal
14:20 <@michaelfolkson> https://bitcoin.stackexchange.com/questions/102684/what-is-the-point-of-miner-signaling-in-a-soft-fork-activation-mechanism-what-s
14:21 -!- Alexandre_Chery [946685a8@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.133.168] has joined ##taproot-activation
14:23 <@michaelfolkson> Maybe this answer could be improved. But it was my understanding that the point is that if miners are ready immediately it can activate immediately. If they aren't they can activate later. Flexibility that isn't available with a flag day
14:24 < luke-jr> belcher: you're missing the point
14:27 < belcher> can you explain luke-jr ?
14:30 -!- Alexandre_Chery [946685a8@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.133.168] has quit [Quit: Connection closed]
14:30 <@michaelfolkson> Also with the flag day higher risk of an invalid Taproot spend creeping into a block (and needing a large re-org) because you don't know in advance that majority of miners will be running the flag day release
14:33 -!- Alexandre_Chery [946685a8@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.133.168] has joined ##taproot-activation
14:34 < jeremyrubin> An alternative signaling would be for the final 100 blocks in a MUST_SIGNAL to be required to be spent to taproot addresses
14:34 < belcher> how is that different from bip8 lot=true? there you also dont know in advance if any miners would enforce it (and of course as we know the economy enforces not the miners)
14:35 < jeremyrubin> That at least provides some more concrete evidence -- observing non spending of them without a valid taproot witness -- that the rule is in effect
14:35 < jeremyrubin> (100 because of coinbase maturity)
14:35 < jeremyrubin> belcher: does that make you happier?
14:35 <@michaelfolkson> belcher: If you want to avoid bigger re-orgs than normal you care about majority of miners running it
14:35 < jeremyrubin> It's still not perfect, as it's entirely possible to be a trap, but much higher assurance than signaling alone
14:36 < belcher> interesting idea jeremyrubin, so its an incentive, if it was possible to steal those taproot outputs then a miner would
14:37 < belcher> michaelfolkson i thought that was the point of bip8 and bip9, that seems like an argument for bip8 lot=false.... since both bip8 lot=true and a flag day have the downside that bitcoin might lose hashpower for a little bit
14:37 < jeremyrubin> Yep, but they won't because their block will get orphaned
14:37 < luke-jr> [22:30:42] <michaelfolkson> Also with the flag day higher risk of an invalid Taproot spend creeping into a block (and needing a large re-org) because you don't know in advance that majority of miners will be running the flag day release <-- you don't know that either way
14:37 < luke-jr> [22:34:01] <jeremyrubin> An alternative signaling would be for the final 100 blocks in a MUST_SIGNAL to be required to be spent to taproot addresses <-- that wouldn't fix anything
14:38 < luke-jr> belcher: The assumption with LOT=True is that blocks are invalid without the signal, and miners won't mine them
14:39 < jeremyrubin> luke-jr: that is false. observing that a rule is in place for a long time contributes to empirical evidence a rule is enforced
14:39 < jeremyrubin> we can never fully know what rules miners are using
14:40 < jeremyrubin> c.f. inflation bug and SPV mining
14:40 < luke-jr> jeremyrubin: enforced by miners != enforced by nodes
14:40 < luke-jr> the latter is what matters
14:40 < jeremyrubin> they both matter
14:40 < luke-jr> you want any anti-Taproot nodes to go off on their own separate chain if they care that much
14:40 <@michaelfolkson> This was good on the impact of a chain split and re-orgs on upgraded (LOT=true) nodes, upgraded (LOT=false) nodes and unupgraded nodes https://diyhpl.us/wiki/transcripts/bitcoin-magazine/2021-02-26-taproot-activation-lockinontimeout/
14:41 < jeremyrubin> mostly beside the point I'm making which is around belcher's epistemology how do we know what we know
14:42 <@michaelfolkson> Explained well that even though economic users enforce the rules, if you want to avoid larger re-orgs than normal for unupgraded nodes you need a miner majority enforcing rules too
14:42 -!- Alexandre_Chery [946685a8@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.133.168] has quit [Quit: Connection closed]
14:48 < nothingmuch> luke-jr: is the reason that isn't a fix that a P2TR coinbase output is already valid under the current rules, so would be accepted in a non-taproot chain as anyone can spend?
14:49 < jeremyrubin> yes but you'd have an invalid witness
14:49 < luke-jr> nothingmuch: yes
14:49 < jeremyrubin> or could have
14:49 < luke-jr> nothingmuch: and that rule doesn't include any spend at all
14:49 < jeremyrubin> Yes, the proof you would be looking for is that those are spent only with a valid taproot witness
14:49 < jeremyrubin> and it's not a proof
14:49 < jeremyrubin> just "evidence"
14:50 < luke-jr> right, "doesn't mine an invalid tx" doesn't imply "can't mine an invalid tx" much less "if mines an invalid tx, the network should reject it"
14:50 < jeremyrubin> We only know any rules of the bitcoin network by seeing them not broken over long periods of time
14:50 < jeremyrubin> We don't actually have any proven rules
14:50 <@michaelfolkson> jeremyrubin: Rusty has made similar point on not really knowing what rules are being enforced https://rusty.ozlabs.org/?p=620
14:51 < jeremyrubin> bitcoin is fundamentally empirical
14:51 < luke-jr> no, but we know de jure what rules are expected to be imposed by the signals
14:51 < luke-jr> nodes that disagree on Taproot, would be using another chain that rejects its activation
14:51 < jeremyrubin> we does not include, at least, belcher
14:52 < jeremyrubin> More aptly -- btcd and bitcoin core could both be signaling for what they think means taproot but have differences in implementation
14:52 < luke-jr> not relevant to the point
14:52 < jeremyrubin> Yes it is
14:53 < jeremyrubin> you can't know what is actually valid or not except by inference based on what happens or not
14:53 < luke-jr> you can know what *should* be valid or not
14:53 < jeremyrubin> For example, "the sky is blue" seems like a good rule, but last year I woke up to an orange sky.
14:54 <@michaelfolkson> If it is Bitcoin Core vs btcd on different consensus rules Bitcoin Core wins both by significant majority running it and perception of being the "reference implementation"
14:54 < luke-jr> without a signal, there is no way to even coordinate what *should* be valid
14:54 < luke-jr> michaelfolkson: not necessarily
14:54 < jeremyrubin> michaelfolkson: we might never learn that there are differing consensus rules between
14:54 < jeremyrubin> this has already happened
14:54 < jeremyrubin> cf inflation bug
14:54 < jeremyrubin> it just didn't result in a split
14:55 < jeremyrubin> that was a case where we didn't know what rules were actually being enforced by the network vs what we expected the network to do
14:55 < jeremyrubin> It's not completely insignificant, but I think that IMO signaling is sufficient evidence that a rule will be in place
14:55 < jeremyrubin> belcher: does not, so I propose to him alternative evidence
14:55 < luke-jr> jeremyrubin: but we knew what rules were SUPPOSED to be enforced
14:56 < nothingmuch> perhaps a better way to frame this is there need to be 2 soft forks simultaneously to guarantee a safe chainsplit? without signalling the activated chain appears valid to nodes that want to reject activation?
14:56 < belcher> jeremyrubin signalling is fine evidence, but its only evidence not proof.... i was making this point because of the argument "flag day activation is bad because it doesnt use signalling"
14:56 < jeremyrubin> segwit was like this to an extent, with Litecoin's segwit bounties
14:56 < luke-jr> nothingmuch: sure
14:57 < jeremyrubin> people look for social evidence
14:57 < jeremyrubin> that's probably the best we can hope for
14:57 < luke-jr> belcher: if you steal my taproot coins, who is to say nodes backing you up are wrong?
14:57 < jeremyrubin> belcher: there cannot be proof of any rule in bitcoin, just compounding evidence
14:57 < nothingmuch> more accurately: two disjoint soft forks
14:57 < jeremyrubin> if you don't like signaling as sufficient, let others take the first leap on creating outputs
14:58 < jeremyrubin> then when those aren't stolen for a while, you have more evidence
14:58 < nothingmuch> and MUST_SIGNAL is a rule that can be differentiated even though it has no direct economic meaning
14:58 < belcher> jeremyrubin you have proof about what rules you're following, but only evidence about what rules other people are following
14:58 < jeremyrubin> not even really
14:59 < luke-jr> nodes act on the signal either by activating Taproot, or rejecting such an activating block
14:59 < belcher> though i guess if their node rejects your transaction and they say "sorry your money is no good here" then thats proof
14:59 < jeremyrubin> If we did have proof, we wouldn't have run code with inflation bugs. We clearly don't have proof in a usable format... also code runs somewhere... compilers... cosmic rays... yadda
15:00 < belcher> yep fair point
15:03 < jeremyrubin> belcher: are you satisfied with "signaling is a mechanism to make some risk-takers feel confident enough to create taproot outputs, seeing taproot outputs not stolen over a period is a mechanism for me to feel safe creating taproot addresses"?
15:04 < belcher> not really for the first part, thinking back to the segwit soft fork i think the most important part was seeing all those companies saying they run bitcoin core 0.13.1
15:04 < belcher> for the second part, yes sure seeing many bitcoins in segwit addresses not being stolen was quite convincing
15:05 < belcher> or rather, not seeing a theft attempt and chainsplit
15:05 < jeremyrubin> so you need a wider set of signaling?
15:06 < jeremyrubin> signaling in a non-honest mutable way?
15:06 < belcher> signalling from economic nodes, not miners
15:06 < belcher> miners are the ones who set the block header version
15:06 < jeremyrubin> chicken egg
15:07 < jeremyrubin> I suppose we could wreck fungibility and make it so that users scan all coins they get to make sure that it was never part of an invalid taproot spend
15:07 < jeremyrubin> Would that be satisfacotry?
15:07 < nothingmuch> jeremyrubin: isn't that implied if they are running a full node?
15:07 < luke-jr> ^
15:08 < jeremyrubin> is what implied?
15:08 < luke-jr> jeremyrubin: full nodes won't accept a transaction with any invalid in history
15:09 < stortz> you download the entire coin route from block reward all the way to it's final UTXO, for every coin
15:09 < jeremyrubin> no you're missing what belcher is saying, which i think is a bad idea so I'm explaining the ramifications of it
15:09 < belcher> what am i saying? (according to you)
15:09 < jeremyrubin> you can absolutely say "I will not accept any coin which has a v1 taproot output in history that did not include a taproot valid witness"
15:09 < belcher> ah
15:10 < belcher> yes i am saying that...
15:10 < belcher> someone could easily do that by running the relevant full node
15:10 < jeremyrubin> So even though a miner could mine one validly, you as a user can begin enforcing the rule in a non standardized signal activated way
15:10 < jeremyrubin> No the point would be that users need to start enforcing a rule at some point in order to satisfy belcher, and he doesn't accept signaling as a mechanism for them to coordinate future things
15:10 < jeremyrubin> so nodes can't use signaling via miners at all, they just need to start enforcing at some point
15:11 < stortz> what
15:11 < belcher> "he doesn't accept signaling as a mechanism for them to coordinate future things" <--- where did you get that from? lol
15:11 < jeremyrubin> there's no mechanism for them to run software that can follow the rules and to signal they are running such software
15:11 < belcher> right
15:12 < nothingmuch> jeremyrubin: does that entail accepting blocks that do spend v1 witnesses before activation, and only rejecting txs that include them in their history?
15:12 < belcher> (thats a good thing fwiw, because it helps privacy)
15:13 < jeremyrubin> The issue is that from what belcher is describing there is no way to check that maj economic nodes are running compatible software without them somehow already being willing to reject *something* that previously was not rejected
15:13 < jeremyrubin> Otherwise it's just useless signaling and we don't know (or have any idea) of what their eventual software might do
15:14 < jeremyrubin> Belcher beleives (as stated previously) that the only thing that matters is what your local node does
15:14 < jeremyrubin> So if your local node allows for invalid txns to be made but filters the outputs you show in your balance, this is acceptable
15:15 < jeremyrubin> And people should damn well do their best to avoid sending you such coins
15:15 < jeremyrubin> (btw this is broken for one glaring reason, curious if anyone will catch it)
15:15 < belcher> well yeah, i stand by most of that (except the clarify, the nodes which matter are you own and those you trade with)
15:15 < belcher> i thought this was pretty uncontroversial
15:15 < belcher> remember how we spent all that time getting people to use full node wallets? this is why, because they protect things like the inflation schedule
15:16 < jeremyrubin> Yeah but to activate a new rule on a every man for himself rule is just far too chaotic
15:16 < belcher> we'll have to deal with it
15:16 < belcher> nobody promised developing bitcoin will be easy
15:17 < jeremyrubin> no you can just use bip8 signaling and at least you have way more confidence -- not proof -- that the rule is in place
15:17 < jeremyrubin> don't let perfect be the enemy of good
15:17 < belcher> the purpose (in my view) of things like miner activation and a flag day is so that almost every node out there starts enforcing a new rule at the same block height
15:17 < belcher> what part of my worldview means that bip8 signalling doesnt work?
15:18 < jeremyrubin> because you want people to begin enforcing the rule in an uncoordinated way?
15:18 < belcher> where are you getting that from?
15:18 < jeremyrubin> [3/1/21 15:04] <belcher> not really for the first part, thinking back to the segwit soft fork i think the most important part was seeing all those companies saying they run bitcoin core 0.13.1
15:19 < belcher> jeremyrubin bitcoin core 0.13.1 used bip9 activation... so every full node out there started enforcing segwit at exactly the same block height
15:19 < belcher> there was nothing uncoordinated about it
15:19 < belcher> but it was pretty important to me that if i send coins to places like localbitcoins or bitstamp they wont say "sorry belcher your money is no good here"
15:20 < jeremyrubin> that's a contested fact if BIP9 had responsibility for activation
15:21 < jeremyrubin> And further running 13.1 is not observable
15:22 < jeremyrubin> how do you know they actually upgraded v.s. changed client for PR?
15:22 < jeremyrubin> and lastly, signaling now will do the same thing, lot=true or false
15:23 < belcher> i broadly agree with all of that
15:23 < jeremyrubin> so I don't see how there was truly anything extra in segwit era than right now
15:23 < belcher> the point i was making was about flag day activation, which doesnt use signalling at all
15:23 < belcher> people said "flag day activation cant work because it doesnt use signalling", and i believed i explained why thats wrong
15:24 < belcher> sure signalling is one way, but its not strictly necessary
15:24 < belcher> some of the soft forks that satoshi did didnt use signalling
15:25 < jeremyrubin> I think a more fair assesment is that pure flag days (no signaling) are user hostile
15:25 < jeremyrubin> flag days + signaling are less use hostile
15:25 < belcher> when satoshi added the 1MB block size limit with a flag day soft fork, was that hostile to users?
15:25 < jeremyrubin> they at least make it possible to write software to automatically handle the issues and "know what you got"
15:26 < jeremyrubin> I discount the satoshi era
15:26 < jeremyrubin> when you see buddha in the road kill him
15:26 < jeremyrubin> doesn't really matter what satoshi did
15:26 < belcher> the point isnt that satoshi did it, it could have been anyone, the point is that it was a soft fork done with a flag day and no signalling
15:27 < belcher> how do nodes even signal? they cant write to the block headers, do you mean they signal in their transactions? (
15:27 < jeremyrubin> they can't signal!
15:28 < belcher> jeremyrubin a broader question to help me understand, what enforces bitcoin's consensus rules according to you? so if someone spent coins from a segwit address without knowing the private key, or printed infinite bitcoins, what stops that from happening? if i understand you right there needs to be some kind of signalling...?
15:28 < jeremyrubin> no there doesn't *need* to be signaling
15:29 < nothingmuch> doesn't rejecting non-signalling blocks count constitute a kind of signalling? in which case mandatory signalling by miners gives nodes an opportunity to do that that would otherwise not be there?
15:29 < jeremyrubin> but signaling is a convenience because software is hard to write and we want to get more evidence of what the rules are
15:29 < jeremyrubin> so it's an opportunity to get a bit more evidence
15:29 < belcher> nothingmuch the opportunity is always there because nodes could reject a transaction
15:29 < jeremyrubin> it's not end-all-be-all
15:30 < luke-jr> "let's just hope Taproot is active after August"
15:30 < luke-jr> is what you have without signalling
15:30 < belcher> jeremyrubin so your position isnt "signalling is always necessary" as i thought, but "signalling makes activation safer and easier" ?
15:30 < luke-jr> signalling gets you "Taproot is clearly active; let's hope it is enforced"
15:30 < jeremyrubin> but it is necessary for us to release the safest software we can
15:31 < belcher> there is no hope needed luke-jr, all thats needed is to run my own full node and ask the people i trade with
15:31 < belcher> that was true even for segwit
15:31 < belcher> nobody cared about segwit signalling, they cared about what full nodes were being used
15:31 < belcher> the bip148 nodes didnt signal at all if you remember
15:31 < belcher> instead the businesses which ran them posted about it on twitter or the uasf.co site
15:32 < luke-jr> the point is you don't want it to be disputable
15:32 < belcher> what do you mean by disputable
15:32 < luke-jr> if someone steals your taproot coins, you want it to be indisputably stolen
15:32 < luke-jr> not "oh, well I consider Taproot active; you don't? oh crap"
15:33 < belcher> but thats how bitcoin works, miners could make a chain split whenever they want
15:33 < luke-jr> and it won't be Bitcoin because we know the rules
15:33 < luke-jr> but if you don't have a clear activation, the rules become debatable
15:33 < belcher> miners could steal my ecdsa coins right now if they wanted, i would say "oh well i consider ecdsa active; you don't? good luck selling my coins anywhere"
15:34 < belcher> luke-jr we would know that the taproot rules take effect after block height 700000 (or whichever the height turns out to be)
15:34 < belcher> theres no debate, its either below 700000 is >=
15:34 < luke-jr> no
15:34 < belcher> err, its either below or above
15:34 < jeremyrubin> to be fair, we do bury deployments
15:34 < jeremyrubin> so I think that flag days are sufficient when they are in the past
15:35 < nothingmuch> the a posteriori belief that ecdsa is enforced is well supported by the fact that hasn't happened, but somebody has to be the first to give a counterparty a P2TR address believing that will be safe
15:35 < jeremyrubin> we don't need signaling for events in the past
15:35 < luke-jr> jeremyrubin: because we only support that one chain
15:35 < jeremyrubin> however, signaling is something of value purely for future events
15:35 < jeremyrubin> luke-jr: false
15:35 < belcher> im so surprised that things i thought were obvious are actually controversial, so you guys really think that *miners* is what protected coins in segwit addresses?
15:36 < jeremyrubin> we would support any chain which activated at that height
15:36 < luke-jr> belcher: said nothign of the sort
15:36 < jeremyrubin> there could be multiple
15:36 < luke-jr> jeremyrubin: no
15:36 < belcher> obviously we're misunderstanding each other then
15:36 < jeremyrubin> we got rid of adding checkpoints right
15:36 < luke-jr> jeremyrubin: Knots has continued to update checkpoints, and I'm sure everyone would abandon Core if they allowed such a reorg
15:37 < jeremyrubin> no, but miners did serve in coordinating when we all decided to activate the new rule?
15:37 < jeremyrubin> coordinating != activating
15:37 < luke-jr> (the BIP148 code in Knots was eventually replaced by a checkpoint post-Segwit)
15:37 < belcher> i found the old site https://web.archive.org/web/20171228111943/https://bitcoincore.org/en/segwit_adoption/
15:37 < belcher> look at those big names
15:38 < jeremyrubin> luke-jr: eh whatever. I don't nesc agree with decision to stop adding checkpoints but I'm just observing what the software does
15:38 < luke-jr> jeremyrubin: nobody would sit back and let such a reorg happen
15:38 < belcher> essentially saying that if someone stole your segwit coins they couldnt spend them at: bitstamp, bitrefill, bittylicious, bustabit, etc
15:38 < belcher> it was nothing to do with signalling, everything to do with the economy... its the economy that enforces the rules
15:38 < belcher> thats why you had that guy put 40000 btc into a segwit address pretty soon after the soft fork
15:38 < jeremyrubin> luke-jr: I have never seen any humans checked in and built into a binary :)
15:39 < luke-jr> jeremyrubin: if software does something the human doesn't like, it gets rejected ;)
15:40 < jeremyrubin> tell that to the therac-25
15:40 < luke-jr> wut
15:40 < jeremyrubin> machine which killed people because of stupid bugs
15:40  * jeremyrubin checks out
15:43 < jeremyrubin> closing point is that I was much more worried about the folks opposing segwit than about the folks saying they wanted it.
15:44 < jeremyrubin> 0 opposing businesses for taproot...
15:44 < belcher> taproot itself is fine, the controversial part is activation
15:45 < belcher> (controversial for now, despite everything im still pretty confident we'll find a solution eventually)
15:45 < luke-jr> we already found a solution ;)
15:47 < stortz> the solution is lot=true 1Y and we just forget about this
15:47 < luke-jr> pretty much :P
15:48 < belcher> luke-jr ignoring people you disagree with you is not productive :)
15:48 < belcher> who disagree with you*
15:48 < nothingmuch> it'd be interesting to poll LOT=false supporters for what timeout value, if any, would make LOT=true acceptable to them
15:48 < luke-jr> belcher: tell Matt
15:49 < belcher> that goes for everyone
15:49 < belcher> we're all bitcoiners here
15:50 < luke-jr> I'm not ignoring anyone; just not interested in stall attempts and shed painting
15:50 < luke-jr> if you don't run LOT=True, that's only hurting yourself
15:51 < belcher> that depends
15:51 < nothingmuch> that's not a charitable interpretation of the objections to LOT=false
15:51 < nothingmuch> erm, objections to LOT=true
15:51 < belcher> apparently people who genuinely want to help bitcoin and make sure it safely and quickly gets taproot are engaging in "stall attempts and shed painting" :)
15:51 < jeremyrubin> noting that most of the proponents of LOT=false are saying LOT=false first, followed by a LOT=true
15:52 < luke-jr> nothingmuch: did you miss the recent "let's throw out BIP 8 entirely and start with new ideas galore"?
15:52 < jeremyrubin> so LOT=true is not seen as fundamentally broken in some way as a activation mecahnism
15:52 < nothingmuch> luke-jr: nope, that's why i think the timeout question is interesting. FWIW i disagree with Matt, but i don't see it as stall attempts or shed painting, just a different risk evaluation
15:52 < luke-jr> jeremyrubin: seems that was just a stall with an ulterior motive of never LOT=True ever
15:54 < luke-jr> in 6 months they'd be saying "nevermind, we're still not doing LOT=True"
15:54 < belcher> luke-jr how does that fit in with the view that "flag day activation is just LOT=true without the miners"
15:54 < luke-jr> belcher: it inherently isn't LOT=True.
15:54 < nothingmuch> flag day + mandatory signalling? or just flag day?
15:54 < luke-jr> LOT=False nodes won't activate
16:36 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed]
17:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
17:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
17:50 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]
18:04 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 268 seconds]
18:06 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation
18:06 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
18:29 -!- belcher [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
18:29 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
18:30 -!- bob333 [~bob@46.28.204.21] has quit [Ping timeout: 246 seconds]
18:31 -!- bob333 [~bob@46.28.204.21] has joined ##taproot-activation
18:56 -!- jonatack_ [~jon@37.170.82.107] has quit [Read error: Connection reset by peer]
20:04 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 268 seconds]
20:04 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 268 seconds]
20:04 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 268 seconds]
20:04 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 268 seconds]
20:04 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 268 seconds]
20:05 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
20:05 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 268 seconds]
20:16 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation
20:16 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##taproot-activation
20:16 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
20:16 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
20:20 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
20:21 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation
20:21 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
20:52 < aj> <belcher> thats why you had that guy put 40000 btc into a segwit address[...]
20:52 < aj> belcher: do you have a cite for that?
20:55 < brg444> aj: https://www.reddit.com/r/Bitcoin/comments/7tcmi4/bitcointalks_famous_user_loaded_moved_his_40k_btc/?utm_source=share&utm_medium=mweb
20:59 < aj> belcher: yep found it; it was in a p2sh segwit address prior to that, but doesn't look like it was revealed that it was a segwit address until then?
21:09 -!- CARO2 [~Cesar@2804:7f4:c19d:f7fa:e47f:3edd:f411:1666] has quit [Ping timeout: 272 seconds]
21:10 -!- CARO [~Cesar@2804:7f4:c29a:f13:c98:64f5:b539:ca3a] has joined ##taproot-activation
22:20 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds]
22:42 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
23:10 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 268 seconds]
23:10 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation
23:15 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
23:15 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation
23:24 -!- DigDug [~toshiba@ool-44c6b39a.dyn.optonline.net] has quit [Ping timeout: 265 seconds]
23:41 -!- DigDug [~toshiba@ool-44c6b39a.dyn.optonline.net] has joined ##taproot-activation
--- Log closed Tue Mar 02 00:00:45 2021