--- Day changed Sat Sep 08 2018
01:31 < arubi> wrt cjxt fee bumps, I was thinking it might make sense to do that using bip68 relative locktime (nsequence) vs bip65 absolute locktime (nlocktime).  my reasoning is, if we use absolute locktime, one tx that becomes stuck due to low fees will create a "drift" in locktimes for all subsequent transactions in the coinjoin, so then we have to take that into account when signing the next tx in the tree.
01:31 < arubi> for a tx at index n of the swap, say we have 10 signed versions of it, each with increasing fees, and each timelocked to a further away block height, if eventually version 8 of tx_n (timelocked 7 blocks later than the cheapest fee one) got confirmed, suddenly we have multiple signed versions of tx_(n+1) valid at the same time, which means that one party might attempt to relay the highest fee valid one first.  this can also have the same effect 
01:31 < arubi> on more than just the next tx in the series.
01:31 < arubi> using relative locktimes in nsequence, we can pre-sign the same 10 versions of increasing fee transactions, but timelock them relatively to how many blocks passed /since the parent confirmed/.  this assures that timelock drift doesn't happen and we are free to sign the same increments for all txs in the series without taking drift into account.
01:32 < arubi> (end paste)
01:42 -!- undeath [~undeath@unaffiliated/undeath] has joined #joinmarket     
02:32 < belcher> ty waxwing 
02:33 < belcher> good point arubi, i didnt actually realize you could use nsequence that way
02:34 < belcher> one issue might be denyability/fungiblity, since many wallets like bitcoin core and electrum set nlocktime for all their transactions, but im not aware of any that set nsequence
02:38 -!- undeath [~undeath@unaffiliated/undeath] has quit [Quit: WeeChat 2.2]     
03:14 < arubi> belcher, right the custom nsequence stands out, but hopefully electrum and core could also start using it.  maybe only for when spending non 0-conf inputs
03:23 < waxwing> arubi, can you repeat that, i've had a big mess with my server and IRC stuff because my vps provider switched my IP address.
03:41 < arubi> waxwing, https://0bin.net/paste/dtQwBKelTj5aA6Mu#lLnyAjfKpESoDft1yNHK-pTeZ0GwKf33zRD6ZX44AYJ
04:25 < waxwing> arubi, thanks, yep, definitely makes far more sense to use CSV, but agreed that that is rather unfortunate ...
04:25 < arubi> waxwing, to be clear, op_csv is not needed
04:26 < waxwing> oh sorry, right, just nsequence.
04:28 < arubi> right so, suppose other wallets start setting nsequence like they do nlocktime, then that would be cool.  basically if the input you're spending is already confirmed, then setting nsequence for "current_block_height - block_height_of_input" would be the same as setting "nlocktime for current_height"
04:36 < waxwing> right.
04:36 < waxwing> maybe propose it somewhere, could start with just #bitcoin . see if there's any counterargument.
04:37 < arubi> not a bad idea.  gonna try that later on
06:45 -!- undeath [~undeath@unaffiliated/undeath] has joined #joinmarket     
11:05 -!- undeath [~undeath@unaffiliated/undeath] has quit [Quit: WeeChat 2.2]     
11:57 < belcher> after running ./install.sh it looks like secp256k1 wasnt installed correctly, these are the error messages https://pastebin.com/yxK608L6 any idea what to try?
12:05 < waxwing> it's not immediately jumping out at me what to do there, maybe arubi has a thought
12:06 < waxwing> it certainly looks like a wrong version of the *.so rather than it not being available at all, but i'm not sure what to deduce from that.
12:08 < belcher> i installed secp256k1 on this computer months and months ago, back when joinmarket first started using that lib
12:08 < belcher> impmort secp256k1 in python works, trying to figure out how to find its version, i could try uninstalling it
12:08 < waxwing> heh, "months", that's like over 2 years :)
12:08 < waxwing> tempus fugit
12:09 < waxwing> oh; so i think you're saying, outside the virtualenv it loads in python prompt, but not inside it? no, wait, i'm confused
12:10 < waxwing> yes removing existing secp might work, but i'm getting a bit lost what's going on, it seems you have the secp shared library *inside* the venv, so ...
12:11 < belcher> oh wait, ill try inside venv
12:12 < waxwing> yeah it won't work, that's what's borking it. trying to compare yours and mine now.
12:12 < belcher> yes, inside virtualenv "import secp256k1" failed to load with  that same error, outside it loads correctly
12:13 < waxwing> well mine has a different directory structure under site-packages to yours, which is probably just because it's from a while ago. we need arubi on this I think.
12:13 < waxwing> at some point i'll try a fresh install on VM, it's been a couple of months since i tried that
12:14 < waxwing> i kinda consider 'coincurve' a TODO (i believe it's in TODO.md), although i've done nothing on it, i get the impression it works and is used by other projects and is up to date; this one is unfortunately not and that may be part of the problem (or, all of it)
12:45 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer]     
13:20 -!- lnostdal [~lnostdal@77.70.119.51] has joined #joinmarket     
14:54 < arubi> belcher, I have to go afk in a minute, but I'm wondering what you get when you run `nm jmvenv/lib/python2.7/site-packages/secp256k1-0.13.2-py2.7-linux-x86_64.egg/secp256k1/_libsecp256k1.so | grep secp256k1_ecdsa_recoverable_signature_parse_compact`
14:54 < arubi> should be:
14:55 < arubi> 0000000000003630 t _cffi_d_secp256k1_ecdsa_recoverable_signature_parse_compact
14:55 < arubi> 0000000000003640 t _cffi_f_secp256k1_ecdsa_recoverable_signature_parse_compact
14:55 < arubi> 0000000000014d50 T secp256k1_ecdsa_recoverable_signature_parse_compact
14:55 < arubi> if it says 'U' instead then something is definitely wrong..  also what about `echo ${LD_LIBRARY_PATH}`
14:56 < arubi> basically I think that somehow the system's libsecp is in the way..  we'll see tomorrow