--- Day changed Sat Dec 08 2018
03:34 -!- takamatsu [~takamatsu@unaffiliated/takamatsu] has quit [Ping timeout: 246 seconds]     
04:20 -!- undeath [~undeath@hashcat/team/undeath] has joined #joinmarket     
04:48 -!- Lightsword [~Lightswor@107.170.253.193] has quit [Read error: Connection reset by peer]     
04:48 -!- Lightsword [~Lightswor@107.170.253.193] has joined #joinmarket     
06:55 < undeath> is the funding tx actually needed in CJXT if you have a refund tx for every step?
07:11 -!- beIcher [~user@unaffiliated/belcher] has quit [Ping timeout: 250 seconds]     
07:13 -!- beIcher [~user@unaffiliated/belcher] has joined #joinmarket     
07:49 < undeath> I just realised you can effectively de-link input + output on CJXT by putting the ouput on a different subtree than the input
07:58 < waxwing> undeath, on first point, i'm not sure what you mean, but i'm guessing you mean: can you avoid having a multisig for the shared control element at the start of the process?
08:00 < undeath> yes, exactly
08:07 < arubi> undeath, anything prior to the shared control script can be double spent so isn't the "point of shared control" always the start of the process?
08:07 < undeath> but everything after it can be double-spent too
08:08 < undeath> why make an exception for the first one?
08:08 < undeath> it'll allow a kind of watermarking for almost no gain
08:09 < arubi> maybe I'm missing context.  how can anything past the shared control be double spent (not including points of the graph where additional funding is added - where we set backouts)
08:10 < undeath> yes, I'm talking about the points where additional funding is added
08:11 < undeath> wouldn't that ideally be at (almost) all points?
08:11 < waxwing> undeath consider the following case: a starting tx TX1, with two TXs coming out of it, TX2 and TX3. I'm deliberately not using the 'funding' terminology. And consider if we use no multisig.
08:12 < waxwing> Now suppose TX1 has two inputs from Alice, Bob (A, B). A 1.0, B 4.0 are the two input utxo amounts.
08:12 < waxwing> and suppose the output amounts are not the same of course, so TX1 outs are: A 1.2 B 3.8 (no multisig)
08:12 < waxwing> and those two outs are fed into TX2 and TX3 respectively, along with other promise utxos from the other party.
08:13 < waxwing> The problem I have here is, how can any backout defend Bob against Alice spending that first output of 1.2, which is larger than her initial input?
08:15 < undeath> I realise this is a problem, but how can the funding tx defend against this on its own? Do all later added inputs have to be small (enough)?
08:16 < undeath> I assumed you will just have your PTG in a way that still make the promise txes possible
08:16 < waxwing> with multisig either both agree, or it doesn't go through. that can basically block further progress through the tree to a malicious counterparty, leaving a timelocked backout, presigned, as the only thing that can "complete" the process
08:17 < undeath> if your transaction has inputs from both parties it has to be signed by both of them, hence they already need to agree in that case
08:17 < arubi> the issue is with the outputs in the following step
08:18 < arubi> alice will surely agree to sign the first step to non-shared control output, because she gets +0.2 btc either way
08:18 < waxwing> the introduction of a promise "adds-in" to an existing flow. if that fails, no harm done, we just "resolve" at the state *prior* to the tx that introduced the new promise.
08:18 < arubi> at that point, she's free to broadcast the tx, and spend the 1.2btc on their own
08:22 < arubi> basically, every time we "increase the balance" of the shared control script, a backout is needed.  this is true for the first step (initial funding) and every time a promise goes in
08:23 < undeath> yes, sure
08:28 < waxwing> you don't need a backout from funding if the first non-funding tx only uses the funding as its input. "promise utxo requires backout for previous tx" is the rule, i believe.
08:29 < waxwing> i think mainly what undeath was adding to the discussion the other day was talking about using effectively promise utxos, but not from outside the PTG, from within it.
08:29 < waxwing> i mainly wanted the promise utxo idea to avoid having everything coming just along one tree/path, for improving privacy/mixing effect, so i guess that's why i didn't think about it
08:31 -!- Giszmo [~leo@190.162.241.129] has joined #joinmarket     
08:31 < arubi> "you don't need a backout from..."  yea you're right.  also yes now I realize that I was missing context about this ^
08:32 < waxwing> but re: multisig, yeah we should def think carefully about tricks. i don't see a way to avoid it entirely? obv, understand that that's desirable.
08:33 < waxwing> rather than handwaving schnorr, or dusting off some paillier libraries and going to town
08:33 < arubi> taproot would be very nice for cjxt
08:33 < undeath> what is the advantage of a multisig tx to a tx with inputs from all parties?
08:34 < waxwing> the advantage is such a utxo (2/2 say) can't be spent unilaterally
08:34 < undeath> ah     
08:34 < undeath> ofc     
08:34 < undeath> but does it matter if that's the last tx of the PTG each party signs?
08:35 < waxwing> multiple inputs from different people mean a *transaction* requires agreement, but multisig means spending of coins requires agreement, the second restriction's a lot stronger :)
08:36 < waxwing> well even having a pre-signed tx somewhere in the PTG doesn't guarantee it'll go through first compared to a double spend
08:38 < waxwing> maybe this subsection is useful in this discussion: https://gist.github.com/AdamISZ/a5b3fcdd8de4575dbb8e5fba8a9bd88c#more-sophisticated-construction-allowing-external-inputs
08:39 < waxwing> (i'm still thinking about it though, interesting)
08:45 < undeath> oh, sure. I realize where my error in thinking was
08:45 < undeath> thank you for the explanations!
08:46 < arubi> :)     
08:48 < undeath> for some reason I was missing that spending the funds from F does require *someone* to actually have control over the utxo resulting from F. And that someone should obv be everyone, to stay trustless
09:43 < belcher> localbitcoins cheating their affiliates? https://www.reddit.com/r/Bitcoin/comments/a4a7ah/localbitcoins_steals_from_affiliates_caught_them/ i wonder if the new KYC requirements caused traders to go to other sites
09:44 < belcher> that kind of behaviour doesnt make sense if lbtc is earning well
09:44 < belcher> though maybe the OP is a liar
10:21 < arubi> "over 5000 affiliates", and he sees every one of their transactions?  wow
10:38 -!- rdymac [uid31665@gateway/web/irccloud.com/x-qyapbwbfyncuzron] has joined #joinmarket     
11:00 < waxwing> seems like porting over to PyQt5 with pyqt5reactor won't be too painful; got the gui running and working through syntax changes one by one. no guarantees but my guess is it'll be OK.
11:02 < undeath> cool
12:19 < waxwing> would it be insensitive of me to force use of '.' instead of ',' for decimals? i guess so :) i just wasted an hour because i forgot my laptop comes from Europe :)
12:24 < belcher> not insensitive, that kind of stuff has probably caused the loss of multimillion dollar missions to mars
12:48 < waxwing> unbelievably enough, i can't find a method to change it. i find a suggestion on stackexchange which doesn't work, and there's extensive documentation for QLocale, but ... ?
12:48 < waxwing> here's an example of the same problem/confusion, the answer is "you can't change the locale" but ... there's also no method to change the decimal point ... https://stackoverflow.com/questions/13313896/changing-locale-in-qt#13314464
12:53 < undeath> so it's dependent of the system's settings? that means joinmarket does not need to care about it?
12:53 < undeath> you may just need to adjust your system's qt settings
12:54 < waxwing> i don't think you can reset it, from within the python script, see the answer to the above Q
12:55 < waxwing> i was trying to avoid some very ugly hack; if i allow the use of ',', i actually got a core dump:
12:55 < undeath> lol     
12:55 < waxwing>   File "joinmarket-qt.py", line 612, in startSingle
12:55 < waxwing>     amount = int(Decimal(btc_amount_str) * Decimal('1e8'))
12:55 < waxwing> decimal.InvalidOperation: [<class 'decimal.ConversionSyntax'>]
12:55 < waxwing> Aborted (core dumped)
12:56 < waxwing> which is a bit surprising. i can hack around this i guess, but it seems absurd to not allow the programmer to set something so simple ...
12:56 < undeath> so you cannot control if you receive a comma or a dot?
12:56 < waxwing> fwiw this is pretty much the only bug left, everything else seems to work fine, number of edits was fairly minimal
12:57 < waxwing> undeath, i would love to find out that i'm wrong, but been searching on it for a while. my bet is you can do it, but by hacking around intended behaviour.
12:57 < waxwing> setNumberOptions in the QtLocale doesn't have it. that's what amazes me.
12:57 < waxwing> you can read it with decimalPoint(), ofc
12:58 < undeath> I thought Qt would allow you to input one of them depending on your locale settings but pass the normalised string/decimal to the application
12:58 < undeath> but such a normalisation does not happen?
12:58 < waxwing> well, the context is something called QDoubleValidator; i'm trying to control user input in the bitcoin amount
12:58 -!- \x [~user@unaffiliated/-x00/x-1893888] has joined #joinmarket     
12:58 < waxwing> which was fine in PyQt4, i set the limits 0.00000001, 100, 8 which means anything from that min to max with 8 decimal places
12:59 < waxwing> fine here too, except it insists on the machine's locale. i should probably just fix the Decimal() conversion problem and just deal with it.
12:59 < waxwing> but it annoys me.
12:59 < waxwing> i mean what's the bloody point of being a programmer if you can't control things :)
13:00 < undeath> :D     
13:03 < undeath> https://stackoverflow.com/questions/38329004/qt-decimal-separator
13:03 < undeath> does this help?
13:05 < waxwing> i don't know; the QDoubleValidator doesn't reference the locale directly. https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/scripts/joinmarket-qt.py#L136
13:06 < waxwing> i suspect not, but thanks for looking. i'll probably just fix the Decimal conversion and deal with that. i hate guessing, especially with stuff that's pretty complex like Qt.
13:44 < waxwing> undeath, turns out the way it's done in the answer that i linked to, does actually work. i'd misinterpreted it.
13:44 < waxwing> not wishing to bother you, just let you know that the problem seems to be solved.
13:44 < undeath> well, that's something :)
13:59 < waxwing> hmm pretty much everything seems to work now, except: in python2, i'm not sure how to install pyqt5; `pip install pyqt5` works on py3 but not py2
14:03 < undeath> there doesn't seem to be an official build for py2
14:09 < Lightsword> try pyside2
14:09 < Lightsword> instead of pyqt5
14:32 -!- technonerd [~techno@unaffiliated/technonerd] has quit [Ping timeout: 250 seconds]     
14:36 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 264 seconds]     
14:45 -!- Giszmo [~leo@190.162.241.129] has quit [Ping timeout: 240 seconds]     
14:47 -!- technonerd [~techno@unaffiliated/technonerd] has joined #joinmarket     
14:56 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #joinmarket     
15:01 -!- Giszmo [~leo@ip-68-236-219-201.nextelmovil.cl] has joined #joinmarket     
15:12 < waxwing> Lightsword, right, will give it a try.
15:39 < waxwing> Lightsword, i have a feeling you told me, but does pyqt5reactor work with that? i just looked at the repo again and it doesn't seem to mention it.
15:40 < waxwing> hmm, looks like yes from searching
15:40 < Lightsword> https://github.com/sunu/qt5reactor/blob/58410aaead2185e9917ae9cac9c50fe7b70e4a60/src/qt5reactor/core.py#L117
15:40 < Lightsword> yeah
15:44 < waxwing> oh, heh, i actually have to uninstall PyQt5 since it tries it first, or else there's some install option i guess
16:11 -!- undeath [~undeath@hashcat/team/undeath] has quit [Quit: WeeChat 2.3]     
16:28 < waxwing> huh, it loads up but can't get the menu :(
17:01 < waxwing> ok fixed that, so i think there were only like 2 syntax differences between pyqt5 and pyside2, but this is testing on python2, i'll have to try it on the py3 side also in a bit.
17:02 < waxwing> oops spoke too soon, it core dumped
17:11 -!- rdymac [uid31665@gateway/web/irccloud.com/x-qyapbwbfyncuzron] has quit [Quit: Connection closed for inactivity]     
17:23 -!- Giszmo [~leo@ip-68-236-219-201.nextelmovil.cl] has quit [Ping timeout: 250 seconds]     
17:37 -!- Giszmo [~leo@ip-223-234-219-201.nextelmovil.cl] has joined #joinmarket     
17:49 -!- AgoraRelay [~jmrelayfn@p54866C79.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]     
18:00 -!- beIcher [~user@unaffiliated/belcher] has quit [Ping timeout: 244 seconds]     
18:02 -!- AgoraRelay [~jmrelayfn@p54866D7B.dip0.t-ipconnect.de] has joined #joinmarket     
18:03 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 256 seconds]     
18:06 -!- beIcher [~user@unaffiliated/belcher] has joined #joinmarket     
18:18 -!- beIcher [~user@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]     
18:19 -!- beIcher [~user@unaffiliated/belcher] has joined #joinmarket     
18:29 -!- Giszmo [~leo@ip-223-234-219-201.nextelmovil.cl] has quit [Ping timeout: 268 seconds]     
18:46 -!- Giszmo [~leo@45.232.32.35] has joined #joinmarket     
19:28 -!- beIcher [~user@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]     
19:32 -!- beIcher [~user@unaffiliated/belcher] has joined #joinmarket     
19:46 -!- Giszmo [~leo@45.232.32.35] has quit [Ping timeout: 250 seconds]     
20:06 -!- Giszmo [~leo@190.162.241.129] has joined #joinmarket     
22:21 -!- beIcher [~user@unaffiliated/belcher] has quit [Ping timeout: 268 seconds]     
22:21 -!- beIcher [~user@unaffiliated/belcher] has joined #joinmarket     
22:46 -!- puddinpop [~puddinpop@unaffiliated/puddinpop] has quit [Ping timeout: 268 seconds]