--- Log opened Thu Apr 22 00:00:33 2021
06:04 -!- Netsplit *.net <-> *.split quits: _0x0ff, belcher
06:05 -!- Netsplit over, joins: belcher, _0x0ff
07:39 <+JoinMarketRelay> [hackint/mojo_] Hi. I was looking into github action and codecoverage methods. I think it would be good if we get some basic action and coverages report setup for the repo. Will also help contributors to write unit tests. I can make a PR with the scripts if its helpful.
07:40 < belcher> mojo_ would that be for running tests automatically?
07:41 <+JoinMarketRelay> [hackint/mojo_] Yes. CI +_code coverage (generated by running tests)
07:41 <+JoinMarketRelay> [hackint/mojo_] CI part can be configured to build in different rust version and platform env.
07:44 <+JoinMarketRelay> [hackint/mojo_] This is how they look for each PR https://github.com/rust-bitcoin/rust-lightning/pull/892
07:45 < belcher> i see, yes sounds good to me
07:45 < belcher> as well as unit tests, integration tests seems very useful as well
07:46 < belcher> the really interesting parts to test are the creating of a coinswap from beginning to end
07:46 < belcher> i saw the electrum server electrs has a full test where it set ups bitcoin core in regtest, electrs and electrum wallet, all to test electrs
07:47 <+JoinMarketRelay> [hackint/mojo_] >  the really interesting parts to test are the creating of a coinswap from beginning to end
07:48 <+JoinMarketRelay> [hackint/mojo_] For this we need to first setup integration testing..
07:48 <+JoinMarketRelay> [hackint/mojo_] Itcan be done with docker files.
07:49 <+JoinMarketRelay> [hackint/mojo_] The setting up part wont be much of a big deal. Just modifying the github actions. But we have to code it somehow first that can be run via an action.
07:53 <+JoinMarketRelay> [hackint/mojo_] I was also thinking maybe we should add some unit tests using rust-miniscript interpreter, to check the created transactions follows consensus rules and the contract actually spends the funding correctly.
07:54 <+JoinMarketRelay> [hackint/mojo_] This can ofcourse be checked if when we do integration testing, but for now using miniscript might be simpler.
07:56 < belcher> i dont think thats a good idea, to me it seems better to use integration tests with bitcoin core (for example create a transaction spending to the script, then another transaction spending the previous transaction, and check to see whether bitcoin core's testmempoolaccept call really succeeds)
07:57 < belcher> in that way we test against bitcoin's real consensus rules, to me at least testing against miniscript seems a lesser good test
07:59 <+JoinMarketRelay> [hackint/mojo_] Ya makes sense. Have you seen this? https://github.com/bitcoindevkit/bitcoin-regtest-box
08:00 <+JoinMarketRelay> [hackint/mojo_] Its a a docker container with btcoin core regtest + elects server to run this kind of tests.
08:01 <+JoinMarketRelay> [hackint/mojo_] I thinbk it will be possible to write tests talking to electrs in this container and do a full coinswap round.
08:04 < belcher> i wasnt aware of that, that looks nice
08:05 < belcher> to be clear teleport has nothing to do with electrs, i just mentioned electrs as an example of another project that uses integration tests
08:09 <+JoinMarketRelay> [hackint/mojo_] Ok, but wont it be required to have some kind of address index database to do integration? I am not sure. If its possible to do just with core then we can simply use the regtest only container. I don't have much experience writing integration code though. Bitcoin core uses some python wizardry to do it. I hope its possible to do in rust too.
08:10 < belcher> teleport does not need any address index to run
08:10 < belcher> you can use python if that makes it any easier for you
08:15 <+JoinMarketRelay> [hackint/mojo_] teleport doesn't use address index, but the integration test might have to. I am guessing here. Anyway. I intend to complete basic unit testing for the for the current codes first. Setup basic CI and coverage stuffs. Will take me some time to get that covered.
08:16 <+JoinMarketRelay> [hackint/mojo_] Will look into integration tests after that.
08:19 < belcher> why would integration tests need to use an address index?
08:20 < belcher> maybe to check as the test result that a certain address ended up with coins on it, but for that you could do `importaddress <address>` and then bitcoin core will track payments to it without needing an address index
08:42 <+JoinMarketRelay> [hackint/mojo_] But in the case of a maker posting a contract transaction, the taker (or the next maker) needs to react to that event and do some acts right? Hmm., I guess it should be possible to do that also with core wallet.
08:43 < belcher> yep, with regtest you can also create blocks at will
08:43 < belcher> when i was creating the code for contract txes i had a test where i spent the same UTXO with the hashlock branch and the timelock branch, both succeeded with `testmempoolaccept` and failed if, for example, the hash preimage was wrong
08:46 <+JoinMarketRelay> [hackint/mojo_] Ya makes sense. But I was wondering it seems the sequence field is `0` in the current form of contract transaction created here. https://github.com/bitcoin-teleport/teleport-transactions/blob/f6878d7a47e9f05b5453c610b5edd97d0a0b3de5/src/contracts.rs#L141
08:46 <+JoinMarketRelay> [hackint/mojo_] How is then the OP_CSV will execute?
08:49 < belcher> ill check
08:50 <+JoinMarketRelay> [hackint/mojo_] Also I have been looking up on how core reads the stack for CSV and it seems it reads 5 bytes.  https://github.com/bitcoin/bitcoin/blob/4b5659c6b115315c9fd2902b4edd4b960a5e066e/src/script/interpreter.cpp#L595-L598
08:50 < belcher> aha yes, you're right, that wont work
08:50 < belcher> i guess it ended up that way because those contract transactions arent used for anything yet
08:50 < belcher> but its quite easy to read the locktime from the contract_redeemscript and put it as the sequence value
08:51 < belcher> hold on, no that not right
08:51 < belcher> the contract transaction isnt subject to locktime
08:51 <+JoinMarketRelay> [hackint/mojo_] and the actual value of lock time is 2 bytes. as per BIP68  https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki#specification
08:51 < belcher> instead the transaction which later spends the contract transaction UTXO must have a sequence number
08:51 <+JoinMarketRelay> [hackint/mojo_] Aha ok right..
08:52 < belcher> so putting "sequence: 0" is correct
08:52 < belcher> regarding your link to bip68, yes i remember now reading that page
08:52 <+JoinMarketRelay> [hackint/mojo_] Yes agreed. It has to be the sequence of spending transaction.
08:53 <+JoinMarketRelay> [hackint/mojo_] but i think we need to change the locktime encoding in the script here. https://github.com/bitcoin-teleport/teleport-transactions/blob/f6878d7a47e9f05b5453c610b5edd97d0a0b3de5/src/contracts.rs#L93 Its cant be just a i64 int push.
08:54 < belcher> it would be good to find out for sure
08:55 <+JoinMarketRelay> [hackint/mojo_] Yeah. Planning to dig into rust lightning repo next. They must be doing this thing.
08:55 < belcher> so i have another rust project i never published called "rust bitcoin play" where i wrote various functions in order to figure out exactly how to use rust-bitcoin.... ill upload it now because a lot of the teleport stuff comes from there
08:55 <+JoinMarketRelay> [hackint/mojo_] Great. Will be helpful for me too..
08:57 < belcher> here https://gist.github.com/chris-belcher/7988c798292883fd8421c6fa6b846ef5
08:57 < belcher> i just realized some of those functions could nearly be copypasted to become integration tests
08:57 < belcher> also they contain a few dead-ends i ended up not using, such as rust-wallet
08:58 < belcher> this one seems most useful im remembering now https://gist.github.com/chris-belcher/7988c798292883fd8421c6fa6b846ef5#file-rust-bitcoin-play-rs-L702
09:03 <+JoinMarketRelay> [hackint/mojo_] Ok it seems you got it accepted in testmepoolaccept too with i64 int push. I wonder how CSV is evaluating there. Oh or is it because test mempool accept doesn't execute the reedem script? becuase it will be executed by the tx spending the contract tx. nNot the contract transaction itself.
09:04 < belcher> testmempoolaccept does execute the redeemscript, it does the same checks that are done for any transaction being relayed or mined
09:38 <+JoinMarketRelay> [hackint/mojo_] Yes But when a transaction is relayed the redeem script is not checked. The transaction only contains the redeem script hash. The script will be executed when the spending transaction discloses the full script.
09:39 <+JoinMarketRelay> [hackint/mojo_] To see this OP_CSV in action you need to make a spend of the contract transaction.
09:44 < belcher> when the the transaction spending _to_ the script is relayed you're right the redeemscript is not checked, but when the transaction spending _from_ the script is relayed then yes the redeemscript is checked because this transaction reveals the whole redeemscript
09:44 < belcher> in my code above testmempoolaccept is used on the transaction which spends from the script
09:44 < belcher> while create_senders_contract_tx() in teleport creates a transaction which spends to the script
10:00 <+JoinMarketRelay> [hackint/mojo_]  Hmm that does seem to be the case. Will look up whats happening with the CSV here.
10:42 -!- greypw_ [~greypw@unaffiliated/greypw] has joined ##coinswap
10:48 -!- Netsplit *.net <-> *.split quits: +JoinMarketRelay, greypw
10:55 -!- JoinMarketRelay [~jmrelay@unaffiliated/waxwing] has joined ##coinswap
10:55 -!- mode/##coinswap [+v JoinMarketRelay] by ChanServ
11:57 -!- OTC [3d5db399@061093179153.ctinets.com] has joined ##coinswap
11:57 -!- OTC [3d5db399@061093179153.ctinets.com] has quit [Client Quit]
17:01 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##coinswap
17:04 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]
17:09 -!- belcher_ is now known as belcher
--- Log closed Fri Apr 23 00:00:34 2021