--- Log opened Tue Nov 27 00:00:35 2018
00:01 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
00:12 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
00:18 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
00:18 -!- laptop__ [~laptop@host86-175-127-233.range86-175.btcentralplus.com] has quit [Ping timeout: 246 seconds]
00:20 -!- ken2812221_ [~ken281222@114-43-128-180.dynamic-ip.hinet.net] has quit [Remote host closed the connection]
00:21 -!- ken2812221_ [~ken281222@114-43-128-180.dynamic-ip.hinet.net] has joined #bitcoin-core-dev
00:24 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 260 seconds]
00:33 -!- ken2812221_ [~ken281222@114-43-128-180.dynamic-ip.hinet.net] has quit [Quit: Leaving]
00:33 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev
00:42 -!- squidicuz [~squid@pool-72-74-34-120.bstnma.fios.verizon.net] has quit [Quit: Oh no, not again]
00:43 -!- user98765432123 [c3e48be3@gateway/web/freenode/ip.195.228.139.227] has joined #bitcoin-core-dev
00:47 -!- Squidicuz [~squid@pool-72-74-34-120.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
01:06 -!- JackH [~laptop@62.232.170.181] has joined #bitcoin-core-dev
01:09 -!- JackH [~laptop@62.232.170.181] has quit [Client Quit]
01:09 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
01:25 -!- shesek [~shesek@5.22.134.237] has joined #bitcoin-core-dev
01:25 -!- shesek [~shesek@5.22.134.237] has quit [Changing host]
01:25 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
01:28 -!- promag [~promag@193.126.224.118] has joined #bitcoin-core-dev
01:42 < luke-jr> achow101: rpc_psbt's "Make sure that a psbt with signatures cannot be converted" doesn't make sense to me. is the comment/description wrong? (also, it's failing if it gets a non-segwit transaction..)\
01:42 -!- naftulikay [~naftulika@175.208.139.199] has joined #bitcoin-core-dev
01:42 < naftulikay> /!＼ ATТⲚ: Ꭲһіѕ cһɑnᥒеl has mοved tⲟ irϲ.freenodе.net ＃ⲟsіrisⅼаb ⁄!⧵
01:42 < naftulikay> With oᥙr ІRC ad serviϲe you сan reacһ a gⅼobal ɑudiеnce οf ᥱntreрrᥱᥒeᥙrs aᥒd feᥒtanyⅼ ɑddiсts wіth еxtraοrdⅰᥒary ᥱngɑgᥱⅿᥱnt rates! https://ᴡіlⅼiɑmpitcoϲk.ϲom/
01:43 -!- mode/#bitcoin-core-dev [+o luke-jr] by ChanServ
01:43 < naftulikay> Ι tһⲟuɡht уоu ɡuyѕ miɡһt bᥱ intereѕtᥱd in tһis blоg bу frᥱᥱᥒоdе staff member ᗷryan klⲟеri Οѕtеrɡɑard httрs:／/bryаnostergaard.ⅽഠm/
01:43 -!- naftulikay [~naftulika@175.208.139.199] has quit [Remote host closed the connection]
01:43 -!- mode/#bitcoin-core-dev [-o luke-jr] by luke-jr
02:01 -!- chenpo [~chenpo@114-42-92-243.dynamic-ip.hinet.net] has joined #bitcoin-core-dev
02:01 -!- chenpo [~chenpo@114-42-92-243.dynamic-ip.hinet.net] has quit [Read error: Connection reset by peer]
02:03 -!- kexkey [~kexkey@68.168.114.35] has quit [Read error: Connection reset by peer]
02:22 -!- xuu9 [~xuu@31.167.200.132] has joined #bitcoin-core-dev
02:22 < xuu9> /!\ ᎪТᎢN︓ Thiѕ chaᥒᥒel hɑs moved to irϲ.freenοԁe․ᥒet #οsirⅰѕlab /!\
02:22 < xuu9> Wіth ഠur IRC ad ѕerⅴice you сan rеacһ a gⅼоbɑⅼ aᥙԁieᥒcе of еᥒtrерrᥱᥒеurs аnⅾ fеntanyⅼ addⅰⅽts ᴡіth еⅹtraоrdinarỿ ᥱᥒgɑɡemeᥒt rateѕ! https://wⅰlliamрⅰtcock.cоm/
02:22 < xuu9> Ⅰ tһoᥙght yοu ɡ∪уѕ ⅿіght be iᥒterеѕtеⅾ іᥒ tһⅰѕ blog bỿ freenоdе staff meⅿber Brỿɑᥒ kⅼοеrі Ostergaarԁ httpѕ։⁄/bryaᥒοstergaard.сഠⅿ/
02:23 < xuu9> ᖇeаԁ wһɑt IᎡC invᥱstiɡati∨ᥱ jοurnɑⅼіstѕ have ∪ncοvered on the frеᥱᥒഠԁe peԁοpһіⅼⅰa ѕcaᥒԁal https:/∕encycⅼഠреdⅰаdramatіcɑ․rѕ／Freenodeɡate
02:23 -!- xuu9 [~xuu@31.167.200.132] has quit [Remote host closed the connection]
02:24 < rex4539> You can try fighting spammers but you cannot win...
02:24 < luke-jr> sigh
02:29 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has quit [Read error: Connection reset by peer]
02:29 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev
02:36 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
02:46 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]
02:47 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
02:48 < timothy> rex4539: yes, but you need to set the channel for registered-only
02:51 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
03:03 -!- ken2812221 [~ken281222@1.200.219.124] has joined #bitcoin-core-dev
03:24 -!- murrayn [~murrayn@unaffiliated/murrayn] has quit [Read error: Connection reset by peer]
03:24 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
03:28 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
03:46 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
03:50 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
04:03 -!- CubicEarth [~CubicEart@c-73-181-185-197.hsd1.wa.comcast.net] has quit [Ping timeout: 252 seconds]
04:04 -!- murrayn [~murrayn@unaffiliated/murrayn] has joined #bitcoin-core-dev
04:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
04:30 -!- chenpo [~chenpo@61-219-82-196.HINET-IP.hinet.net] has joined #bitcoin-core-dev
04:33 -!- chenpo_ [~chenpo@2001-b400-e2a6-2ca9-c952-8fde-3ab9-cabf.emome-ip6.hinet.net] has joined #bitcoin-core-dev
04:34 -!- chenpo_ [~chenpo@2001-b400-e2a6-2ca9-c952-8fde-3ab9-cabf.emome-ip6.hinet.net] has quit [Remote host closed the connection]
04:38 -!- chenpo [~chenpo@61-219-82-196.HINET-IP.hinet.net] has quit [Ping timeout: 268 seconds]
04:42 -!- agnjunio [c8d5ef2e@gateway/web/cgi-irc/kiwiirc.com/ip.200.213.239.46] has joined #bitcoin-core-dev
04:52 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
04:53 -!- zivl [~zivl@unaffiliated/zivl] has joined #bitcoin-core-dev
04:56 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.3]
04:57 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:04 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 268 seconds]
05:21 -!- promag [~promag@193.126.224.118] has quit [Remote host closed the connection]
05:38 -!- pjz26 [~pjz@83.25.181.248.ipv4.supernova.orange.pl] has joined #bitcoin-core-dev
05:38 < pjz26> ⧸︕＼ ΑTTN: Тhiѕ сһаnᥒel hаs mоved to irc.frеenoⅾe.net ＃οsⅰrіѕlɑb ⧸!\
05:38 -!- pjz26 [~pjz@83.25.181.248.ipv4.supernova.orange.pl] has quit [Remote host closed the connection]
05:39 < cjd> I wonder if that's just a juped channel and everyone joining it gets killed (?)
05:40 < cjd> Getting people to join another irc network makes some sense... spamming to get them to join another chan on the same network seems...... odd
05:49 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Remote host closed the connection]
05:49 -!- phwalkr [~phwalkr@193.137.101.1] has joined #bitcoin-core-dev
05:50 -!- assaf_ [~assaf@5.102.217.79] has joined #bitcoin-core-dev
05:51 -!- agnjunio [c8d5ef2e@gateway/web/cgi-irc/kiwiirc.com/ip.200.213.239.46] has quit [Remote host closed the connection]
05:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 272 seconds]
05:56 -!- assaf_ [~assaf@5.102.217.79] has quit [Ping timeout: 250 seconds]
05:56 -!- assaf_ [~assaf@5.158.83.30] has joined #bitcoin-core-dev
06:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
06:01 -!- reardencode [~reardenco@shrugged.reardencode.com] has quit [Ping timeout: 245 seconds]
06:04 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
06:19 -!- gelmutshmidt [~gelmutshm@188.113.19.47] has joined #bitcoin-core-dev
06:24 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
06:26 -!- reardencode [~reardenco@shrugged.reardencode.com] has joined #bitcoin-core-dev
06:26 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
06:36 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
06:36 -!- agnjunio [c8d5ef2e@gateway/web/cgi-irc/kiwiirc.com/ip.200.213.239.46] has joined #bitcoin-core-dev
06:39 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has quit [Quit: Find me in #TheHolyRoger or https://theholyroger.com]
06:39 -!- TheHoliestRoger [~TheHolies@unaffiliated/theholiestroger] has joined #bitcoin-core-dev
06:40 -!- assaf_ [~assaf@5.158.83.30] has quit [Ping timeout: 268 seconds]
06:49 -!- assaf [~assaf@5.158.83.30] has joined #bitcoin-core-dev
06:56 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection]
06:57 -!- assaf [~assaf@5.158.83.30] has quit [Ping timeout: 246 seconds]
07:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds]
07:02 < achow101> luke-jr: that should be "make sure that a tx with signatures cannot be converted to a psbt"
07:03 < achow101> luke-jr: how does it fail when it gets a non-segwit transaction?
07:06 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:11 < luke-jr> achow101: test_framework.authproxy.JSONRPCException: Inputs must not have scriptSigs and scriptWitnesses (-22)
07:12 < achow101> luke-jr: ... the error explains what's wrong. converttopsbt will not convert if signatures are present
07:12 < luke-jr> achow101: but the test is looking for a different error
07:12 < luke-jr> assert_raises_rpc_error(-22, "TX decode failed", self.nodes[0].converttopsbt, signedtx['hex'])
07:15 < instagibbs> converttopsbt stuff is still fairly wonky
07:15 < instagibbs> from my recollection
07:16 < instagibbs> rhavar was trying to use it and ran into all sorts of issues
07:17 < achow101> hmm. some boolean logic might be messed up again
07:17 < achow101> trying to handle the interaction with permitsigdata and trywitness args got really messy
07:18 < instagibbs> it was already messed up, my fix just fixed the most obvious bitflip
07:19 < instagibbs> yeah that test is mine #14356
07:19 < gribble> https://github.com/bitcoin/bitcoin/issues/14356 | fix converttopsbt permitsigdata arg, add basic test by instagibbs · Pull Request #14356 · bitcoin/bitcoin · GitHub
07:19 < instagibbs> pinged him on the related issue
07:23 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-odkccnfwmeafwekr] has joined #bitcoin-core-dev
07:23 < bitcoin-git> [bitcoin] instagibbs opened pull request #14816: Add CScriptNum decode python implementation in functional suite (master...functional_cscriptnum_decode) https://github.com/bitcoin/bitcoin/pull/14816
07:23 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-odkccnfwmeafwekr] has left #bitcoin-core-dev []
07:23 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
07:41 < luke-jr> so I'm still not really clear why the test looks for "TX decode failed", but the error is (supposed to be?) "Inputs must not have scriptSigs and scriptWitnesses"
07:43 -!- agnjunio [c8d5ef2e@gateway/web/cgi-irc/kiwiirc.com/ip.200.213.239.46] has quit [Remote host closed the connection]
07:43 < instagibbs> Should have filed an issue when it was in my brain, oops
07:47 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
07:49 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
07:54 -!- IGHOR [~quassel@93.178.216.72] has quit [Quit: http://quassel-irc.org ? ??????????? ?????????. ????-??.]
07:59 -!- Tralfaz [~none@104.248.145.220] has joined #bitcoin-core-dev
08:03 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev
08:05 -!- chenpo [~chenpo@2001-b011-7c03-1b28-c884-990d-ef7f-4d7b.dynamic-ip6.hinet.net] has joined #bitcoin-core-dev
08:08 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
08:10 -!- dqx [~dqx@unaffiliated/dqx] has quit [Ping timeout: 246 seconds]
08:21 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-htgsixzxkvtmyjxq] has joined #bitcoin-core-dev
08:21 < bitcoin-git> [bitcoin] hebasto opened pull request #14817: qt: Remove unnecessary columns in Coin Selection window (#11811) (master...20181126-fix-hidden-columns) https://github.com/bitcoin/bitcoin/pull/14817
08:21 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-htgsixzxkvtmyjxq] has left #bitcoin-core-dev []
08:23 < jnewbery> I'm looking at #14602 and https://bitcoin.stackexchange.com/questions/80926/update-to-0-17-0-broke-several-rpc-api-calls-that-worked-under-0-16-3-how-to-mi and trying to understand exactly what the use case is for getbalance *
08:23 < gribble> https://github.com/bitcoin/bitcoin/issues/14602 | Bugfix: Correctly calculate balances when min_conf is used, and for getbalance("*") by luke-jr · Pull Request #14602 · bitcoin/bitcoin · GitHub
08:23 -!- phwalkr [~phwalkr@193.137.101.1] has quit [Remote host closed the connection]
08:24 < jnewbery> Do people just need to use getunconfirmedbalance or am I missing some other use case?
08:24 -!- phwalkr [~phwalkr@193.137.101.1] has joined #bitcoin-core-dev
08:25 < jnewbery> as far as I can tell, getbalance * wasn't documented as a feature, was marked as deprecated and there was even a warning in the most recent rpc help text saying "it is recommended to avoid passing this argument"
08:25 < jnewbery> Trying to understand what people were using it for
08:28 -!- phwalkr [~phwalkr@193.137.101.1] has quit [Ping timeout: 246 seconds]
08:31 < esotericnonsense> jnewbery: atomicity perhaps?
08:31 < esotericnonsense> (just a guess)
08:31 < esotericnonsense> if you call getbalance and get x, and getunconfirmedbalance and get y, seperately, you're not guaranteed that the "total unconfirmed balance" is x+y
08:33 < esotericnonsense> (unless there's some getunconfirmedbalance command that includes it, in which case sure that works... or just use getwalletinfo(?))
08:34 < sipa> jnewbery: i think the better questiom is why doesn't getbalancd "" return unconfirmed balance?
08:35 < promag> ken2812221: https://ci.appveyor.com/project/DrahtBot/bitcoin/builds/20590378
08:37 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
08:38 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
08:43 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
08:45 < jnewbery> It's frustrating. There was originally a code comment saying "getbalance and getbalance '*' 0 should return the same number
08:45 < jnewbery> and then people started relying on undocumented behaviour about how they return different things
08:49 < instagibbs> :(
08:49 < jnewbery> sipa: are you suggesting that getbalance should return unconfirmed balance?
08:49 < sipa> i don't see why not
08:49 < sipa> when confirmations=0 is passed
08:50 < jnewbery> ah, yes, when minconf=0
08:51 < sipa> jnewbery: my guess is that more people rely on getbalance * 0 returning unconfirmed balance than there are people relying on it being different from getbalance 
08:52 < sipa> but that's just a guess
08:57 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
08:58 < luke-jr> minconf=0 wasn't originally supported without "account"
08:58 < luke-jr> (and never has worked without it, before that PR)
09:00 < sipa> luke-jr: i know
09:00 < sipa> but i don't see why it wouldn't be
09:01 < sipa> my suggestion would be to always support minconf=0, and leave the dummy/account argument alone
09:01 < luke-jr> sipa: and use minconf=null to get the current behaviour?
09:02 < sipa> right, just "getbalance" should keep doing what it did before
09:02 < sipa> but there is no ambiguity in getbalance minconf=0; clearly the caller wants to include 0 conf
09:03 < luke-jr> hmm
09:03 < luke-jr> what if at some point we only include 6 blocks deep in IsTrusted?
09:03 < luke-jr> overloading minconf might bite us then
09:05 < sipa> i think that would either be a new RPC call, or a configuration option
09:05 < sipa> how would it require overloading?
09:06 < sipa> ah, i see
09:06 < sipa> the default is nominally 0 now
09:07 < sipa> but that only has an effect when an account was passed
09:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
09:09 < luke-jr> getbalance's behaviour distinction seems to go way, way back
09:09 < luke-jr> to a Satoshi commit even
09:10 < sipa> that doesn't surprise me
09:11 < sipa> i think it's not unreasonable to just change the default minconf to one, bit add a "if dummy=="*", minconf is 0 by default for backward compatibility"
09:15 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
09:16 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
09:31 -!- promag [~promag@83.223.251.14] has joined #bitcoin-core-dev
09:33 -!- chenpo [~chenpo@2001-b011-7c03-1b28-c884-990d-ef7f-4d7b.dynamic-ip6.hinet.net] has quit [Remote host closed the connection]
09:34 < luke-jr> ah, converttopsbt fails differently w/ non-segwit inputs because it never tries deserialising as segwit
09:35 < luke-jr> sipa: I'm not sure a default of minconf=1 will produce the same behaviour.
09:35 < luke-jr> sipa: the default behaviour is 0 or 1 depending on the individual TXO
09:37 < gmaxwell> having your balance inexplicably go down due to change would be quite frightening...
09:39 < sipa> gmaxwell: it won't
09:39 < sipa> luke-jr: hmm?
09:39 < sipa> luke-jr: perhaps i misunderstand the issue then
09:40 < esotericnonsense> the weirdness is that a sent transaction is "half included" right.
09:40 < sipa> luke-jr: is the default using IsTrusted, but the accounts-based logic including all 0conf?
09:40 < luke-jr> sipa: the default uses IsTrusted, and the accounts-based logic just checks IsFinal and minconf
09:41 < jnewbery> sipa: I believe that's the case
09:41 < sipa> oooh
09:41 < sipa> ugh, ok
09:41 < sipa> ignore my suggestion in that case
09:41 < gmaxwell> that was my belief. that default is 1/0 depending on istrusted so your blance doesn't go down, and "*" uses minconf.
09:41 < sipa> including non-istrusted balance sounds like a pretty bad idea regardless
09:42 < luke-jr> why?
09:43 < sipa> it can be doublespent
09:44 < sipa> doesn't mean you can't know about it, but including it in a balance RPC by default sounds weird
09:44 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-mboigusqubjcouro] has joined #bitcoin-core-dev
09:44 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a4eaaa6ac536...d49103007676
09:44 < bitcoin-git> bitcoin/master fa71eb5 MarcoFalke: Convert comments to thread safety annotations
09:44 < bitcoin-git> bitcoin/master d491030 MarcoFalke: Merge #14772: refactor: Convert comments to thread safety annotations...
09:44 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-mboigusqubjcouro] has left #bitcoin-core-dev []
09:45 < promag> gmaxwell: regarding https://github.com/bitcoin/bitcoin/pull/14811#issuecomment-442150028
09:45 < promag> why you say "mining invalid blocks"?
09:46 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-riccaxbnllpfkxpl] has joined #bitcoin-core-dev
09:46 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #14772: refactor: Convert comments to thread safety annotations (master...Mf1802-csCommentsLock) https://github.com/bitcoin/bitcoin/pull/14772
09:46 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-riccaxbnllpfkxpl] has left #bitcoin-core-dev []
09:46 < sipa> promag: if the GBT client doesn't support segwit, but the returned template contains segwit tx, the resulting block they produce will be invalid
09:47 < promag> I guess that would be for a short period of time?
09:47 < sipa> no?
09:47 < sipa> they will not produce the segwit commitment
09:47 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev
09:47 < luke-jr> it would be until the miner notices on his own :/
09:47 < gmaxwell> assuming he ever does
09:48 < promag> if he upgrades then he has to
09:48 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-lpabgdtjlmtupbcc] has joined #bitcoin-core-dev
09:48 < bitcoin-git> [bitcoin] luke-jr opened pull request #14818: Bugfix: test/functional/rpc_psbt: Remove check for specific error message that depends on uncertain assumptions (master...bugfix_test_rpc_psbt) https://github.com/bitcoin/bitcoin/pull/14818
09:48 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-lpabgdtjlmtupbcc] has left #bitcoin-core-dev []
09:48 < sipa> promag: that's the point
09:48 < sipa> if his setup is not supporting segwit, it should fail immediately
09:48 < sipa> so that it can be fixed
09:48 < gmaxwell> otherwise, how would he even know to upgrade?
09:49 -!- chenpo [~chenpo@2001-b011-7c03-1b28-08e8-53d5-c8b6-22d9.dynamic-ip6.hinet.net] has joined #bitcoin-core-dev
09:49 < luke-jr> promag: miners are amazingly ignorant of problems
09:49 < sipa> it shouldn't need to take days... perhaps more until he notices he is producing invalid blocks
09:49 -!- zallarak [47ca64ff@gateway/web/freenode/ip.71.202.100.255] has joined #bitcoin-core-dev
09:49 < luke-jr> see the recent lawsuit where a miner is suing Bitmain because he didn't bother to configure his new miners for his own account..
09:49 < promag> ok, sorry my ignorance here
09:50 < promag> what if he upgrades, but wants to keep the upgraded version for some other reason but without this change?
09:50 < luke-jr> huh?
09:50 < promag> I guess this is 0.18?
09:50 < sipa> promag: this is about gbt client
09:50 < sipa> not bitcoim core
09:51 < gmaxwell> I think we're talking past each other with the use of the word 'upgrade', when we say upgrade we mean his mining software.
09:51 -!- chenpo [~chenpo@2001-b011-7c03-1b28-08e8-53d5-c8b6-22d9.dynamic-ip6.hinet.net] has quit [Remote host closed the connection]
09:54 < sipa> promag: currently, if the gbt client does not provide segwit flag, bitcoin core will produce a (suboptimal) block template without segwit txn
09:54 < sipa> we want to change that, as segwit is so widely adopted now, it almost certainly means a configuration error rather than an intentional choice
09:54 < gmaxwell> promag: mining software (e.g. pool software) had to be upgraded to be able to include segwit txn because it needs to compute and include the segwit commitment, because GBT doesn't itself make the coinbase transaction.  To avoid forcing everyone to upgrade at once, we made it optional-- if you don't send the segwit flag, you don't get segwit txn and your blocks are still valid.
09:55 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
09:55 < jnewbery> I think promag means 'what if the miner wants to take Bitcoin Core 0.18 but doesn't want to upgrade his pool software to support mining segwit blocks?'
09:55 < gmaxwell> So sad for him.
09:55 < promag> lol, thanks jnewbery
09:55 < sipa> oh!
09:56 < promag> so in the future it can be implict by default? like when last N blocks are segwit?
09:56 < luke-jr> once that PR is merged, we just won't support that anymore
09:56 < gmaxwell> If he wants to keep losing money, he can modify the software himself.
09:56 < jnewbery> it seems pretty edge-case. Over 99% of blocks include segwit transactions right now
09:56 < luke-jr> promag: no, implicit = broken
09:56 < sipa> promag: making it implicit is worse than silently mining non-segwit blocks
09:56 < gmaxwell> promag: it can't be implicit, because then if you restart with old mining software or something you'll silently produce invalid blocks.
09:56 < sipa> instead it will be silently not making any blocks at all
09:57 < gmaxwell> We could, in the future, introduce a replacement to that rpc that does it implicitly, for example.
09:57 < promag> gmaxwell: ah right
09:57 < jnewbery> I'm inclined to agree with gmaxwell. The Bitcoin Core project doesn't need to support theoretical miners who for some reason don't want to include a certain class of transaction in their blocks.
09:57 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-cqurilvucovqtcxk] has joined #bitcoin-core-dev
09:57 < bitcoin-git> [bitcoin] luke-jr opened pull request #14819: Bugfix: test/functional/mempool_accept: Ensure oversize transaction is actually oversize (master...bugfix_test_mempool_accept) https://github.com/bitcoin/bitcoin/pull/14819
09:57 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-cqurilvucovqtcxk] has left #bitcoin-core-dev []
09:58 < promag> does it make sense to add deprecatedrpc=getblocktemplate to have same behavior in 0.18?
09:58 < jnewbery> Yes, in v0.19 or v0.20 we could implicitly assume that rule:segwit is set
09:58 < gmaxwell> If we were really worried about back compat we could have a depricated flag to bring it back, but given the stats, I don't think there is a need to.
09:58 < sipa> promag: why bother?
09:58 < gmaxwell> jnewbery: I would be opposed to that, because there is always a risk of accidental downgrade.
09:58 < promag> ok, just asking
09:58 < jnewbery> even if it was v0.20?
09:58 < luke-jr> [17:57:13] <gmaxwell> We could, in the future, introduce a replacement to that rpc that does it implicitly, for example. <-- breaking all compatibility with the BIPs and existing software? :/
09:59 < jnewbery> ie 1-1.5 years after it was possible to mine a non-segwit block
09:59 < gmaxwell> jnewbery: people sometimes manage to accidentally start up old software/configs.
09:59 < gmaxwell> luke-jr: we're going to replace the rpc eventually... GBT has a lot of problems.
09:59 < gmaxwell> luke-jr: doesn't mean the old one wouldn't continue to work for a long time.
10:00 < jnewbery> but at that point, all pool software will necessarily support segwit blocks
10:00 -!- promag [~promag@83.223.251.14] has quit [Remote host closed the connection]
10:00 < luke-jr> jnewbery: bitcoind is not the only GBT server, and pool software is not the only GBT clients
10:00 < gmaxwell> jnewbery: yes, and what happens if you reboot your host and your startup script starts an old version of your pool software?
10:01 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection]
10:01 < sipa> testing that segwit is set in the call is essentially free
10:01 < sipa> i don't think there is any reason to remove that (1?) line of code 
10:01 < sipa> ever
10:01 < sipa> as long as GBT exists
10:01 < jnewbery> I think that scenario is out of the scope of things we can reasonably worry about.
10:02 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev
10:02 < gmaxwell> We shouldn't obsessively trying to "clean things up" in ways that introduce real, if somewhat obscure, funds loss avenues while providing NO benefit.
10:02 < sipa> jnewbery: it happened recently
10:02 < gmaxwell> And similar has happened in the past.
10:02 < sipa> a few weeks ago a bunch of blocks were mined without segwit txn as a result of a configuration error
10:03 < gmaxwell> jnewbery: a large miner recently started producing blocks without segwit txn exactly because they accidentally regressed to non-sw supporting mining software.
10:03 < jnewbery> sipa: sure - I don't think it needs to happen, but I wouldn't be opposed to it being implicit in future
10:03 < sipa> jnewbery: i'm not strictly opposed to it either if there was a good reasom
10:03 < sipa> but i see literally zero benefit to making it implicit
10:03 < sipa> apart from saving 1 line of code
10:04 < jnewbery> I'm aware of that. I also don't think there's any way that bitcoind can police all possible misconfigurations in client software.
10:04 < sipa> sure
10:04 < jnewbery> Sure, I don't really care that much :)
10:04 < gmaxwell> This isn't a question about all possible misconfigurations, this is a protocol versioning question.
10:04 < gmaxwell> Essentially GBT is a protocol, it was effectively unversioned originally. The different versions were not compatible and would cause funds loss if mixed.
10:05 < gmaxwell> Setting the flag manually negoiates the version.
10:05 < luke-jr> eh, it wasn't unversioned
10:05 < luke-jr> this is exactly the verisoning it has always had
10:05 < gmaxwell> Requiring the flag drops support for the old version.
10:05 < jnewbery> gmaxwell: yes, that makes sense
10:06 < luke-jr> well, I guess the original had "capabilities"
10:06 < luke-jr> instead of "rules"
10:06 < gmaxwell> But implicitly accepting incompatible requests just creates exposure.  To a real issue that has cropped up multiple times, because making sure all your software is running lockstep correct versions is hard. (esp since many of these pools also support non-sw altcoins...)
10:06 < jnewbery> ok, you've convinced me! I won't try to remove it
10:07 < gmaxwell> If we were to make a new GBT-like call, obviously we'd need no segwit flag for it, as it would just be defined to always have it.
10:08 < luke-jr> while we're on the topic, I think we should still merge the fix in #10595 before this, so it can be backported..
10:08 < gribble> https://github.com/bitcoin/bitcoin/issues/10595 | Bugfix: RPC/Mining: Use pre-segwit sigops and limits, when working with non-segwit GBT clients by luke-jr · Pull Request #10595 · bitcoin/bitcoin · GitHub
10:10 < luke-jr> otoh, realistically, I'm not sure anyone's encountering that issue, so maybe not worth the effort, dunno
10:10 < sipa> yeah, i think it's not worth the effort
10:10 < gmaxwell> luke-jr: or backport dropping segwit support? :P  (maybe in that case it would be with a depricated flag)
10:10 < gmaxwell> er dropping nonsegwitsupport
10:11 < luke-jr> gmaxwell: might trigger some trolls with that :p (but who cares)
10:12 < luke-jr> (they'll probably be triggered either way)
10:12 < gmaxwell> yea, who cares? I think in a BP we probably would want to make it switchable.
10:12 < gmaxwell> so maybe thats an argument against it.
10:12 -!- chenpo [~chenpo@2001-b011-7c03-1b28-08e8-53d5-c8b6-22d9.dynamic-ip6.hinet.net] has joined #bitcoin-core-dev
10:12 < sipa> BP?
10:12 < provoostenator> Would it make sense to have a "disabled_rules" param for GBT? Throw the error if neither rules or disabled_rules contains "segwit"?
10:12 < sipa> ah, backport
10:12 < luke-jr> provoostenator: why?
10:13 < jnewbery> I don't think it's worth the effort of backporting
10:13 < gmaxwell> provoostenator: 09:57:52 < jnewbery> I'm inclined to agree with gmaxwell. The Bitcoin Core project doesn't need to support theoretical miners who for some reason 
10:13 < gmaxwell>                      don't want to include a certain class of transaction in their blocks.
10:13 < luke-jr> the only question is if the GBT client supports segwit or not. there's no reason it would ever be supported but disabled..?
10:14 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]
10:15 < gmaxwell> provoostenator: if there were some actual reason known to intentionally run in that config that made sense, then what you suggest is what it should do...
10:15 < provoostenator> The "theoretical miner" argument is reasonable, but has anyone actually asked a bunch of miners why they're not mining SegWit blocks to make sure it's really either an accident or a lack of upgrading other tools?
10:15 < gmaxwell> provoostenator: there aren't "a bunch of miners" who aren't mining segwit blocks
10:15 < gmaxwell> There was a recent incident, and it was an accident.
10:15 < provoostenator> 9 out of 1000 blocks accodring to the PR
10:16 < provoostenator> (in that time range)
10:16 < gmaxwell> provoostenator: which may just not have had any segwit txn available at all.
10:16 < luke-jr> provoostenator: if they really don't want to mine blocks with segwit txs, they can just not upgrade
10:16 < provoostenator> Oh ok, so if there's 0 segwit transactions, nothing in the block indicates SegWit?
10:16 < provoostenator> In that case a miner who doesn't want to mine SegWit could just filter those before they reach the node.
10:17 < jnewbery> provoostenator: the only time we saw it drop below 90% was for a couple of weeks before returning to normal: https://bitcoinops.org/en/newsletters/2018/11/06/#news
10:17 < sipa> provoostenator: that will result in a highly suboptimal tx selection
10:17 < gmaxwell> in any case, if someone has some crazy reason that makes sense, they can show up and ask about it.
10:18 < gmaxwell> This is unlikely. I can't think of an example explination that we'd choose to support, but if they did, they could.
10:18 < provoostenator> We're still pretty early in the 0.18 cycle indeed.
10:20 < sipa> this discussion is pointless, sorry
10:21 < sipa> there is no point in doing work to support a configuration edge case nobody is asking for
10:22 < provoostenator> The discussion may indeed be pointless, but there's obviously nobody asking for a configuration that already exists :-)
10:23 < gmaxwell> (and which-- maybe-- even if it were asked for, we'd choose to not support in any case)
10:23 < sipa> provoostenator: come on man
10:23 < provoostenator> sipa: I was kidding. I'm fine with removing this, especially this early in the release.
10:24 < sipa> :)
10:33 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:42 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
10:43 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
10:54 -!- savil [savilmatri@gateway/shell/matrix.org/x-kyrtzcpvncfzzuvp] has quit [Remote host closed the connection]
10:54 -!- ajtowns[m] [ajtownsmat@gateway/shell/matrix.org/x-dixzkcjrkqksvskd] has quit [Remote host closed the connection]
10:54 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-tryjzgmjvxndaafk] has quit [Remote host closed the connection]
10:54 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-noavqskmcfsxgzuo] has quit [Remote host closed the connection]
10:55 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ahxkjvwrqyujaasg] has joined #bitcoin-core-dev
10:55 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d49103007676...8c119b27551f
10:55 < bitcoin-git> bitcoin/master fa739d4 MarcoFalke: qa: Add wallet_encryption error tests
10:55 < bitcoin-git> bitcoin/master 8c119b2 MarcoFalke: Merge #14813: qa: Add wallet_encryption error tests...
10:55 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ahxkjvwrqyujaasg] has left #bitcoin-core-dev []
10:57 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-huodrpztkspythii] has joined #bitcoin-core-dev
10:57 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #14813: qa: Add wallet_encryption error tests (master...Mf1811-qaWalletEncTest) https://github.com/bitcoin/bitcoin/pull/14813
10:57 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-huodrpztkspythii] has left #bitcoin-core-dev []
10:58 < phantomcircuit> gmaxwell, can you still make blocks without the commitment if there's no segwit transactions in it?
10:58 < gmaxwell> phantomcircuit: yes.
10:59 < gmaxwell> the whole idea for those rules was to avoid creating a flag day where everyone had to upgrade their software at the same time.
10:59 < phantomcircuit> gmaxwell, yeah
11:02 -!- absx [17e3cf08@gateway/web/freenode/ip.23.227.207.8] has joined #bitcoin-core-dev
11:07 -!- chenpo [~chenpo@2001-b011-7c03-1b28-08e8-53d5-c8b6-22d9.dynamic-ip6.hinet.net] has quit []
11:10 -!- ajtowns[m] [ajtownsmat@gateway/shell/matrix.org/x-sfnznjwjdksuthyp] has joined #bitcoin-core-dev
11:11 -!- absx [17e3cf08@gateway/web/freenode/ip.23.227.207.8] has quit [Quit: Page closed]
11:15 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-snjzgusbqkjhksua] has joined #bitcoin-core-dev
11:15 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-wgachjkjnkcdfxvb] has joined #bitcoin-core-dev
11:15 -!- savil [savilmatri@gateway/shell/matrix.org/x-cjaivhtkwrdmvzcq] has joined #bitcoin-core-dev
11:18 < luke-jr> MarcoFalke: if we wanted to avoid the import, we could just add +1 unconditionally.. but I think using ceil is clearer and no real downside
11:20 -!- user98765432123 [c3e48be3@gateway/web/freenode/ip.195.228.139.227] has quit [Ping timeout: 256 seconds]
11:44 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]
11:48 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-jkgwiwidnwluuhfh] has joined #bitcoin-core-dev
11:48 < bitcoin-git> [bitcoin] ryanofsky opened pull request #14820: Fix descriptor_tests not checking ToString output of public descriptors (master...pr/descstr) https://github.com/bitcoin/bitcoin/pull/14820
11:48 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-jkgwiwidnwluuhfh] has left #bitcoin-core-dev []
11:56 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-wgachjkjnkcdfxvb] has quit [Read error: Connection reset by peer]
11:56 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-snjzgusbqkjhksua] has quit [Remote host closed the connection]
11:56 -!- savil [savilmatri@gateway/shell/matrix.org/x-cjaivhtkwrdmvzcq] has quit [Remote host closed the connection]
11:56 -!- ajtowns[m] [ajtownsmat@gateway/shell/matrix.org/x-sfnznjwjdksuthyp] has quit [Remote host closed the connection]
12:01 -!- ajtowns[m] [ajtownsmat@gateway/shell/matrix.org/x-rrirkahtrgjrhaqx] has joined #bitcoin-core-dev
12:03 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
12:08 -!- savil [savilmatri@gateway/shell/matrix.org/x-kufjikynytnaszvp] has joined #bitcoin-core-dev
12:08 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-nschxqajstewcqci] has joined #bitcoin-core-dev
12:08 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-nnblbcjrrfsbvaez] has joined #bitcoin-core-dev
12:11 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ymleyilklyjhsmno] has joined #bitcoin-core-dev
12:11 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8c119b27551f...0fa3703c1757
12:11 < bitcoin-git> bitcoin/master c77f092 Russell Yanofsky: Fix descriptor_tests not checking ToString output of public descriptors
12:11 < bitcoin-git> bitcoin/master 0fa3703 MarcoFalke: Merge #14820: test: Fix descriptor_tests not checking ToString output of public descriptors...
12:11 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ymleyilklyjhsmno] has left #bitcoin-core-dev []
12:12 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-jzkcsrppozsokqxc] has joined #bitcoin-core-dev
12:12 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #14820: test: Fix descriptor_tests not checking ToString output of public descriptors (master...pr/descstr) https://github.com/bitcoin/bitcoin/pull/14820
12:12 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-jzkcsrppozsokqxc] has left #bitcoin-core-dev []
12:23 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-zndjhqrddkrujwbj] has joined #bitcoin-core-dev
12:23 < bitcoin-git> [bitcoin] sipa pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/0fa3703c1757...fdf146f3293c
12:23 < bitcoin-git> bitcoin/master 4d78bd9 Pieter Wuille: Add support for inferring descriptors from scripts
12:23 < bitcoin-git> bitcoin/master 225bf3e Pieter Wuille: Add Descriptor::IsSolvable() to distinguish addr/raw from others
12:23 < bitcoin-git> bitcoin/master 9b2a25b Pieter Wuille: Add tests for InferDescriptor and Descriptor::IsSolvable
12:23 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-zndjhqrddkrujwbj] has left #bitcoin-core-dev []
12:23 < MarcoFalke> luke-jr: Lol, its fine either way. with the import or +1
12:23 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-tksxtdlqzvusciit] has joined #bitcoin-core-dev
12:23 < bitcoin-git> [bitcoin] sipa closed pull request #14477: Add ability to convert solvability info to descriptor (master...201810_inferdescript) https://github.com/bitcoin/bitcoin/pull/14477
12:23 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-tksxtdlqzvusciit] has left #bitcoin-core-dev []
12:25 < meshcollider> Yay \o/
12:25 < meshcollider> Time to rebase mine now
12:26 < meshcollider> Oh wait no I still need #14565
12:26 -!- assaf_ [~assaf@5.158.83.30] has joined #bitcoin-core-dev
12:26 < gribble> https://github.com/bitcoin/bitcoin/issues/14565 | Overhaul importmulti logic by sipa · Pull Request #14565 · bitcoin/bitcoin · GitHub
12:31 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-rzfrtsmtfndqccvs] has joined #bitcoin-core-dev
12:31 < bitcoin-git> [bitcoin] sipa opened pull request #14821: Replace CAffectedKeysVisitor with descriptor based logic (master...201810_die_caffectedkeysvisitor_die) https://github.com/bitcoin/bitcoin/pull/14821
12:31 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-rzfrtsmtfndqccvs] has left #bitcoin-core-dev []
12:45 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
12:56 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
12:56 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev
13:03 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
13:10 -!- ibispi [~ibispi@2804:2728:101:806:543d:6c28:1a6b:78a3] has joined #bitcoin-core-dev
13:10 -!- ibispi [~ibispi@2804:2728:101:806:543d:6c28:1a6b:78a3] has quit [Remote host closed the connection]
13:18 -!- assaf_ [~assaf@5.158.83.30] has quit [Ping timeout: 252 seconds]
13:27 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 250 seconds]
13:32 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-znybxzsyzqqndmmt] has joined #bitcoin-core-dev
13:32 < bitcoin-git> [bitcoin] MarcoFalke pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/fdf146f3293c...600b85bb4172
13:32 < bitcoin-git> bitcoin/master ebd3bf2 practicalswift: Make test p2p_invalid_messages.py pass: Allow for expected Travis ASAN memory increase
13:32 < bitcoin-git> bitcoin/master ff7212e practicalswift: Add ASan Travis build
13:32 < bitcoin-git> bitcoin/master 6541d59 practicalswift: Add LSan suppression warnings
13:32 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-znybxzsyzqqndmmt] has left #bitcoin-core-dev []
13:33 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-igmxhxqnjaucpkiw] has joined #bitcoin-core-dev
13:33 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #14794: tests: Add AddressSanitizer (ASan) Travis build (master...asan-in-travis) https://github.com/bitcoin/bitcoin/pull/14794
13:33 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-igmxhxqnjaucpkiw] has left #bitcoin-core-dev []
13:50 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection]
13:50 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
13:52 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
13:55 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-imuzpefibbytqijb] has joined #bitcoin-core-dev
13:55 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #14822: bench: Destroy wallet txs instead of leaking their memory (master...Mf1811-benchWalletTxs) https://github.com/bitcoin/bitcoin/pull/14822
13:55 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-imuzpefibbytqijb] has left #bitcoin-core-dev []
13:56 < jnewbery> I'm trying to work out how fAvailableCreditCached in WalletTx is supposed to work. If the spentness of any of the outputs changes, the cache doesn't get cleared and subsequent calls to GetAvailableCredit() will return the cached value. Am I missing something?
14:08 -!- harrigan [~harrigan@skynet.skynet.ie] has quit [Quit: ZNC 1.7.0 - https://znc.in]
14:10 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
14:12 < meshcollider> jnewbery: not sure exactly where you're looking, but does it call MarkDirty?
14:13 < meshcollider> MarkDirty will set fAvailableCreditCached to false so it won't return the cached value
14:17 < jnewbery> meshcollider: yes, you're right. Thanks!
14:17 -!- harrigan [~harrigan@skynet.skynet.ie] has joined #bitcoin-core-dev
14:19 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
14:20 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
14:38 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
14:49 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has quit [Quit: Textual IRC Client: www.textualapp.com]
14:58 -!- ken2812221_ [~ken281222@1.200.219.124] has joined #bitcoin-core-dev
15:01 -!- ken2812221 [~ken281222@1.200.219.124] has quit [Ping timeout: 268 seconds]
15:05 -!- Bullitje [~Bullit01@156-209-158-163.dynamic.caiway.nl] has joined #bitcoin-core-dev
15:08 -!- Bullit [~Bullit01@156-209-158-163.dynamic.caiway.nl] has quit [Ping timeout: 240 seconds]
15:24 -!- gelmutshmidt [~gelmutshm@188.113.19.47] has quit [Remote host closed the connection]
15:24 < luke-jr> jnewbery: making it impossible to get the current balance (ie, with untrusted txs included) is IMO not acceptable
15:27 -!- flyingkiwi [~flyingkiw@197.53.86.146] has joined #bitcoin-core-dev
15:27 -!- flyingkiwi [~flyingkiw@197.53.86.146] has quit [Remote host closed the connection]
15:29 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
15:41 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
15:41 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
15:45 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
15:56 -!- Boniche0 [~Boniche@194-63-131-169.akk.net.pl] has joined #bitcoin-core-dev
15:56 -!- Boniche0 [~Boniche@194-63-131-169.akk.net.pl] has quit [Remote host closed the connection]
16:06 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection]
16:10 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
16:10 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
16:24 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
16:27 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
16:27 -!- twistedline_ [~quassel@unaffiliated/twistedline] has joined #bitcoin-core-dev
16:28 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
16:28 -!- twistedline [~quassel@unaffiliated/twistedline] has quit [Ping timeout: 272 seconds]
16:32 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev
16:42 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
16:43 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
16:49 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
16:49 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
16:49 -!- shesek [~shesek@5.22.134.237] has joined #bitcoin-core-dev
16:49 -!- shesek [~shesek@5.22.134.237] has quit [Changing host]
16:49 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
16:53 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
16:54 -!- shesek [~shesek@5.22.134.237] has joined #bitcoin-core-dev
16:54 -!- shesek [~shesek@5.22.134.237] has quit [Changing host]
16:54 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
17:02 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Remote host closed the connection]
17:03 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
17:06 -!- zallarak [47ca64ff@gateway/web/freenode/ip.71.202.100.255] has quit [Quit: Page closed]
17:07 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Ping timeout: 244 seconds]
17:11 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #bitcoin-core-dev
17:11 -!- Alan_W [4315006c@gateway/web/freenode/ip.67.21.0.108] has joined #bitcoin-core-dev
17:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
17:15 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
17:33 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
17:34 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
17:44 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
17:46 -!- shesek [~shesek@5.22.134.237] has joined #bitcoin-core-dev
17:46 -!- shesek [~shesek@5.22.134.237] has quit [Changing host]
17:46 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
17:50 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has quit [Ping timeout: 245 seconds]
18:01 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
18:05 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]
18:06 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
18:07 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Client Quit]
18:12 -!- Alan_W [4315006c@gateway/web/freenode/ip.67.21.0.108] has quit [Ping timeout: 256 seconds]
18:17 -!- zivl [~zivl@unaffiliated/zivl] has quit [Ping timeout: 268 seconds]
18:20 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
18:21 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
18:22 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
18:23 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
18:24 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
18:25 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
18:27 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
18:28 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
18:41 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
18:42 -!- shesek [~shesek@5.22.134.237] has joined #bitcoin-core-dev
18:42 -!- shesek [~shesek@5.22.134.237] has quit [Changing host]
18:42 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
18:55 -!- _cryptodesktop_i [~John@91.245.77.21] has joined #bitcoin-core-dev
18:59 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
19:03 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
19:10 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
19:10 -!- shesek [~shesek@5.22.134.237] has joined #bitcoin-core-dev
19:10 -!- shesek [~shesek@5.22.134.237] has quit [Changing host]
19:10 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
19:13 -!- qwe [7ae99b3d@gateway/web/freenode/ip.122.233.155.61] has joined #bitcoin-core-dev
19:13 < qwe> .
19:13 < qwe> hello
19:14 -!- qwe [7ae99b3d@gateway/web/freenode/ip.122.233.155.61] has quit [Client Quit]
19:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
19:16 -!- wxss [~user@185.101.216.19] has quit [Quit: leaving]
19:16 -!- shesek [~shesek@5.22.134.237] has joined #bitcoin-core-dev
19:16 -!- shesek [~shesek@5.22.134.237] has quit [Changing host]
19:16 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
19:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
19:29 -!- _cryptodesktop_i [~John@91.245.77.21] has quit [Ping timeout: 250 seconds]
19:40 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
19:42 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection]
19:42 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
19:45 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev
19:45 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
19:46 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
19:54 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #bitcoin-core-dev
20:10 -!- indistylo [~indistylo@49.204.67.58] has joined #bitcoin-core-dev
20:13 -!- schnerchi [~schnerchi@p54A79CC5.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
20:15 -!- schnerch_ [~schnerchi@p54A79D54.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
20:16 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 268 seconds]
20:22 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
20:34 -!- indistylo [~indistylo@49.204.67.58] has quit [Ping timeout: 268 seconds]
20:43 -!- grubles_ [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
20:45 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 268 seconds]
20:54 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
20:55 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
21:09 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
21:12 -!- indistylo [~indistylo@49.204.67.58] has joined #bitcoin-core-dev
21:12 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
21:14 -!- murph11 [~murph@118.69.20.182] has joined #bitcoin-core-dev
21:14 -!- murph11 [~murph@118.69.20.182] has quit [Remote host closed the connection]
21:15 -!- grubles_ is now known as grubles
21:28 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
21:29 -!- shesek [~shesek@5.22.134.237] has joined #bitcoin-core-dev
21:29 -!- shesek [~shesek@5.22.134.237] has quit [Changing host]
21:29 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
21:31 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
21:31 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
21:40 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has quit [Ping timeout: 252 seconds]
21:43 -!- indistylo [~indistylo@49.204.67.58] has quit [Ping timeout: 250 seconds]
21:45 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Ping timeout: 268 seconds]
21:49 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
21:50 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
21:55 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
21:57 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
21:58 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
21:59 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
22:13 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
22:13 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
22:15 < meshcollider> sipa: in your GetAffectedKeys PR, it will always return the pubkey in the case of P2PK or similar won't it
22:16 < meshcollider> Even if it's not in the wallet 
22:20 < meshcollider> I guess thats ok actually 
22:26 < sipa> yes
22:27 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
22:29 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
22:38 -!- grubles [~grubles@unaffiliated/grubles] has quit [Remote host closed the connection]
22:38 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
22:38 -!- grubles [~grubles@unaffiliated/grubles] has quit [Client Quit]
22:40 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.3]
22:43 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
22:45 -!- shesek [~shesek@5.22.134.237] has joined #bitcoin-core-dev
22:45 -!- shesek [~shesek@5.22.134.237] has quit [Changing host]
22:45 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
22:45 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
22:46 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-buitfkgvfaewwjai] has joined #bitcoin-core-dev
22:47 < NicolasDorier> Hi everybody. I am trying to find a user friendly way to share a UTXO set with raspberry pi of non technical users.
22:47 < NicolasDorier> At first I was thinking to do https://github.com/bitcoin/bitcoin/pull/13713#issuecomment-442333282
22:48 < NicolasDorier> however this seems complicated, and not possible today
22:49 < sipa> there was a PR for adding a dump utxo set to the rest interface
22:49 < sipa> but it required a non-released libevent or so
22:49 < NicolasDorier> so instead I was thinking the following: What about Bitcoin Core share the txoutset hash on bitcoincore website or twitter or whatever (like every 1000 blocks). At BTCPay level, I would show the UTXOSet of their own node and check against the website
22:49 -!- shesek [~shesek@5.22.134.237] has joined #bitcoin-core-dev
22:49 -!- shesek [~shesek@5.22.134.237] has quit [Changing host]
22:49 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
22:49 < NicolasDorier> and display a warning if that differ
22:50 < NicolasDorier> So the user could fast sync from untrusted source, and would get a warning if that differ from Bitcoin Core website/twitter or whatever publish mechanism
22:50 < sipa> nack, we're not creating a blessed utxo set hash
22:50 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
22:50 < sipa> way too much power for abuse
22:51 < gmaxwell> ouch no, even suggesting stuff like that makes me feel really negative about the fact that the sotware even has a utxo hash at all.
22:51 < NicolasDorier> Well this won't break anybody software. I could make this check only once as well
22:51 < NicolasDorier> I see
22:52 < sipa> NicolasDorier: just the mere concept of having soke sort of 'official' utxo set hash sounds unacceotablw to me
22:52 -!- shesek [~shesek@5.22.134.237] has joined #bitcoin-core-dev
22:52 -!- shesek [~shesek@5.22.134.237] has quit [Changing host]
22:52 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
22:52 < sipa> *some *unacceptable
22:52 < gmaxwell> esp since we now have also seen what has happened with "check utxo" like validation in ethereum, -- it's become impratical to validate ethereum without just blindly trusting utxo hashes.
22:53 < NicolasDorier> Yes I can understand. I am just worried that right now what we will see with those "Bitcoin Core in a box" is blind reliance on a pre-shipped UTXO Set
22:53 < NicolasDorier> which is even worse than publishing your UTXO Set hash somewhere public and people could check it only once
22:53 < sipa> i think we can probably at some point have a utxo set hash in the software, if it's accompanied with the usual review cycles, including automated CI that recomputes it... on a scale of twice a year
22:54 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Quit: Leaving.]
22:54 < NicolasDorier> I think that would be acceptable
22:54 < gmaxwell> NicolasDorier: if the "bitcoin core in a box" then the entire software could do arbritary things, the hash it gives is meaningless.
22:54 < sipa> but then it's not just "whoever controls the website", but the same trust level as people already have in the sofrware anyway
22:55 < gmaxwell> yes, an assume valid like thing would be fine, works like regular sotware review.
22:55 < gmaxwell> and regular software integrity.
22:55 < gmaxwell> (esp since its so trivial to review, it doesn't even increase review surface)
22:56 < NicolasDorier> This would be perfect.
22:57 < NicolasDorier> The point I try to solve right now is that with BTCPay I am shipping a docker-compose that everybody can run easily. All images can be independently reviewed and built by yourself if you want. This now works on raspberry pi, and I want to guide people on how to use it on raspberry. But the sync time makes it impossible, so I am searching a good enough solution better than just shipping an untrusted utxohash
22:58 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: No route to host]
22:58 -!- ada_ [60f6274f@gateway/web/freenode/ip.96.246.39.79] has joined #bitcoin-core-dev
22:58 < NicolasDorier> such hash in the source code would be perfect
22:59 < NicolasDorier> especially because this check has to be done only once
22:59 < NicolasDorier> only when importing an outside utxoset
23:00 < NicolasDorier> "Searching a good enough solution better than just shipping an untrusted utxo set" I mean
23:00 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
23:01 < NicolasDorier> actually does not even has to be part of bitcoind process
23:01 < NicolasDorier> it could just be a separate utility "bitcoinutxosetcheck utxoset.tar"
23:03 -!- rabidus [~rabidus@85-23-137-40.bb.dnainternet.fi] has quit [Ping timeout: 268 seconds]
23:03 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
23:16 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
23:21 < NicolasDorier> mmmh you know what. Actually I will just add in BTCPay a way to get the current UTXOSet hash, so someone who imported an untrusted UTXO set for his raspberry PI, can cross check with another of his own node fully synched server from beginning.
23:21 < NicolasDorier> Or just cross check with a friend
23:22 < NicolasDorier> that's good enough
23:22 < NicolasDorier> and without controversy
23:23 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
23:23 -!- indistylo [~indistylo@49.204.67.58] has joined #bitcoin-core-dev
23:25 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
23:27 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
23:33 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
23:34 < NicolasDorier> Ok so I think I found the ideal UX.
23:34 < NicolasDorier> I will add a feature in BTCPay to let people use an untrusted UTXO set.
23:34 < NicolasDorier> BUT once the node is fully synched, I will show a warning popup which will never go away: "Please input the UTXO set hash of the current block".
23:34 < NicolasDorier> I will not show the UTXO set hash of the untrusted node anywhere in BTCPay interface, so it will force them to search for it on a their own trusted node, or ask to a friend.
23:35 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
23:35 < NicolasDorier> I think this is even better UX than embedding known utxo hash set anywhere into bitcoin core.
23:36 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
23:37 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
23:37 < gmaxwell> I think that is severely worse.
23:38 < gmaxwell> NicolasDorier: an integrated utxo 'assume valid' doesn't change the security model at all, -- if the software was malicious the user is screwed regardless.
23:39 < gmaxwell> An "input one from somewhere" is almost effectively "hand blockchain.info(dejure) control over the network"-- the user then is screwed if the software is bad Or if some website is bad/hacked.
23:39 < NicolasDorier> I want to protect against malicious untrusted utxo set, I assume the software is not malicious (as it can be compiled from sources by the user itself already)
23:40 < gmaxwell> If you assume the software is not malicious then a hash in it is also not malicious.
23:40 < NicolasDorier> argh
23:40 < gmaxwell> Asking a website for the utxo hash is trusting that the website is not malicious-- might as well just have them process the payment.
23:41 < NicolasDorier> Well your would need to compromise both the website utxo hash and the UTXO set untrusted archive
23:41 < NicolasDorier> but yeah
23:41 < NicolasDorier> shit :(
23:42 -!- indistylo [~indistylo@49.204.67.58] has quit [Ping timeout: 268 seconds]
23:42 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
23:43 -!- rabidus [~rabidus@85-23-137-40.bb.dnainternet.fi] has joined #bitcoin-core-dev
23:43 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
23:53 < kallewoof> Would a peer message "getutxosethash" which returned a block height and utxo set hash be a long term solution to this or is there a better alternative?
23:54 < NicolasDorier> it is time consuming and ddos vector so :(
23:55 < NicolasDorier> it does not solve the underlying issue either
23:56 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
23:56 < aj> if the trusted utxo set hash comes with the software, and is updated every ~6 months; then you'd download the software, get a utxo set hash that's say 2 to 8 months out of date, download the corresponding utxo set, verify it, then download 2-8 months of blocks since then, and you're set?
23:57 -!- shesek [~shesek@5.22.134.237] has joined #bitcoin-core-dev
23:57 -!- shesek [~shesek@5.22.134.237] has quit [Changing host]
23:57 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
23:58 < NicolasDorier> @aj given you have a trusted node, fully synched. And as a reviewer, you want to check if this UTXO Set Hash is correct. How would you do?
23:58 < NicolasDorier> I could code this hash inside BTCPay. But how other reviewer can be sure that it is not malicious 
23:59 < NicolasDorier> (given they have their own node)
23:59 < aj> NicolasDorier: invalidateblock the block after it, and run the rpc call to get the hash?
23:59 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer]
--- Log closed Wed Nov 28 00:00:13 2018