19:00:20 <wumpus> #startmeeting
19:00:20 <lightningbot> Meeting started Thu Jul 25 19:00:20 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:20 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:24 <sipa> ohai
19:00:26 <jonasschnelli> hi
19:00:26 <kanzure> hi
19:00:27 <jnewbery_> hi!
19:00:33 <achow101> hi
19:00:34 <amiti> hi
19:00:41 <andytoshi> hi
19:00:44 <meshcollider> hi
19:00:45 <BlueMatt> a wild jnewbery_ imposter apears
19:00:53 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral
19:01:18 <moneyball> Hi
19:01:18 <ariard> hi
19:01:19 <wumpus> one proposed topic today: Transaction Rebroadcasting https://gist.github.com/amitiuttarwar/b592ee410e1f02ac0d44fcbed4621dba
19:01:26 <jonasschnelli> I have just a little topic/announcement suggestion: bitcoinbuilds.org (can be done at the end when time)
19:01:27 <promag> hi
19:01:51 <jamesob> hi
19:02:01 <jonatack> hi
19:02:16 <wumpus> hi everyone!
19:02:23 <wumpus> #topic High priority for review
19:02:43 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  6 blockers, 6 things waiting for concept ACK
19:02:46 <BlueMatt> #16421
19:02:48 <gribble> https://github.com/bitcoin/bitcoin/issues/16421 | Conservatively accept RBF bumps bumping one tx at the package limits by TheBlueMatt · Pull Request #16421 · bitcoin/bitcoin · GitHub
19:03:03 <sdaftuar> i'd like to review beg #15759, which is already a high priority for review item
19:03:07 <gribble> https://github.com/bitcoin/bitcoin/issues/15759 | [p2p] Add 2 outbound blocks-only connections by sdaftuar · Pull Request #15759 · bitcoin/bitcoin · GitHub
19:03:21 <wumpus> BlueMatt: that's one you want to add I suppose?
19:03:44 <BlueMatt> yesplz
19:03:54 <wumpus> ok added
19:03:55 <jamesob> 15759 is a good PR, A+++++ 10/10 would review again
19:04:45 <sipa> do two jamesob ACKs count as two? i see a win-win situation here
19:06:01 <MarcoFalke> Can I add #16363
19:06:02 <jamesob> I'll read it in decreasing line number order this time
19:06:03 <wumpus> he did ack it twice so...
19:06:03 <gribble> https://github.com/bitcoin/bitcoin/issues/16363 | test: Add test for BIP30 duplicate tx by MarcoFalke · Pull Request #16363 · bitcoin/bitcoin · GitHub
19:06:38 <wumpus> MarcoFalke:sure, added
19:07:32 <wumpus> anything to add/remove from chasing concept ack?
19:08:38 <ariard> still need reviews for #15713, which is current step to go forward on removing cs_main locks in wallet
19:08:41 <gribble> https://github.com/bitcoin/bitcoin/issues/15713 | refactor: Replace chain relayTransactions/submitMemoryPool by higher method by ariard · Pull Request #15713 · bitcoin/bitcoin · GitHub
19:09:09 <ariard> (current tip ACKed by jnewbery and jonatack)
19:09:16 <MarcoFalke> ariard: Looks like you pushed a new commit today
19:09:26 <achow101> #16341 for Chasing Concept ACK?
19:09:28 <gribble> https://github.com/bitcoin/bitcoin/issues/16341 | WIP: Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
19:09:30 <wumpus> good to know, I see it's already on there
19:09:40 <MarcoFalke> Oh, I see they re-ACKed
19:09:51 <ariard> I took jnewbery cleanup commit for BroadcastTransaction
19:10:30 <MarcoFalke> ariard: It conflicts with #16452. So which one should go in first?
19:10:33 <gribble> https://github.com/bitcoin/bitcoin/issues/16452 | refactor: use RelayTransaction in BroadcastTransaction utility by ariard · Pull Request #16452 · bitcoin/bitcoin · GitHub
19:10:49 <jnewbery_> I think 15713 goes first
19:11:06 <jnewbery_> 16452 is a nice clean-up, but doesn't hold up the series of PRs
19:11:12 <wumpus> achow101:added
19:11:12 <ariard> #15713, so that's way I would be able to addreess nits in 16452
19:11:14 <gribble> https://github.com/bitcoin/bitcoin/issues/15713 | refactor: Replace chain relayTransactions/submitMemoryPool by higher method by ariard · Pull Request #15713 · bitcoin/bitcoin · GitHub
19:11:43 <MarcoFalke> Good, I'll take a look at 15713 :eyes:
19:11:55 <ariard> thanks!
19:12:28 <wumpus> #topic Transaction broadcasting (amiti)
19:12:33 <promag> +1 on 15713
19:12:47 <amiti> write up here: https://gist.github.com/amitiuttarwar/b592ee410e1f02ac0d44fcbed4621dba
19:13:06 <amiti> tldr; want to improve privacy with updates to rebroadcast logic
19:13:37 <amiti> instead of nodes rebroadcasting only wallet txns, rebroadcast all txns it believes should have been in the last block
19:14:04 <amiti> looking for critical feedback, concept acks, any high level implementation thoughts
19:14:23 <wumpus> how much is this expected to increase bandwidth usage?
19:14:51 <amiti> choosing the parameters carefully will be important - dramatically impacts the worst case bandwidth usage
19:15:15 <wumpus> and does this help with privacy? the first node broadcasting something will still be the same one
19:15:24 <wumpus> as I see it, at least
19:16:14 <amiti> not necessarily. if a node has a txn in its mempool that should have been picked up in a block already (high fee rate and is old), it will rebroadcast. independent of originating wallet.
19:16:32 <MarcoFalke> wumpus: Yes, the first node (i.e. the wallet) will be the same one
19:16:40 <MarcoFalke> But hopefully not for rebroadcasts
19:16:42 <jnewbery_> wumpus: I think it does. Currently, if you see a peer brodcast a tx more than once, you can be almost certain that it originated the tx, and we rebroadcast our txs that are unconfirmed for more than half an hour
19:17:06 <sipa> i think it primarily addresses how currently we gratuitously rebroadcast, making it obvious continuously to every peer what our own transactions are
19:17:15 <sipa> it certainly doesn't address all forms of leaking that information
19:17:28 <MarcoFalke> small steps :)
19:17:44 <wumpus> so either every node does this, or it reveals which nodes have a hot wallet
19:18:13 <sipa> wumpus: the rebroadcast logic will be in the mempool, so even without wallet enabled, it will work
19:18:41 <wumpus> and if all nodes do it, that sounds very bad for bandwidth usage
19:19:02 <achow101> at first glance, this sounds like it will cause bandwidth usage greatly increase
19:19:09 <sdaftuar> wumpus: i think if we constrain it to old transactions at the top of themempool, it should be a small bandwidth effect?
19:19:28 <sipa> i suspect it's also filted by the knowninvs logic, so we wouldn't rebroadcast to the same peer twice
19:19:36 <wumpus> so basically all nodes would create noise for the nodes with a wallet to hide in, hmm
19:19:56 <MarcoFalke> sipa: The knowninvs will reset every couple of blocks, no?
19:19:59 <sdaftuar> wumpus: i think it's more than that, it's way to ensure that things that should be mined get relayed, eg to nodes with small mempools or recently started up
19:20:06 <sdaftuar> sort of like a mempool-sync might do
19:20:14 <achow101> would it be picking the oldest high fee rate transactions to rebroadcast, up to some n? Or would it pick some n transactions and choose the oldest and highest fee rate of them?
19:20:18 <wumpus> sdaftuar: oh good point
19:20:22 <sipa> right, full nodes have an incentives themselves to see their mempools match what it actually mined
19:20:29 <sipa> even without wallets
19:20:40 <amiti> achow: traverse top of mempool by ancestor fee rate, filter out recent transactions, rebroadcast remaining
19:20:58 <jnewbery_> if we consider the top of the mempool to be "transactions we expect to get mined soon" and they're not getting mined, rebroadcasting them to make sure miners are aware seems like sensible mempool logic
19:21:21 <jnewbery_> if not, then the mempool might as well expire them - they're doing our node no good
19:21:24 <sipa> i guess there could be some sort of exponential backoff, that after a tx has been rebroadcast multiple times, it becomes rarer (this may be especially relevant when peers may have other consensus/policy rules)
19:21:49 <achow101> amiti: so every rebroadcast would have the same number of transactions?
19:21:55 <sipa> though i guess that's done automatically by our own expiration logic
19:21:59 <achow101> or rather same amount of data being broadcast
19:22:17 <wumpus> so if every node broadcasts the transactions at the top of the mempool, this will be more or less the same transactions for every node
19:22:20 <MarcoFalke> achow101: No. Txs that were added to the mempool or to blocks are excluded
19:22:23 <sipa> achow101: i guess that depends on how well the mempool matches what is being mined
19:22:34 <MarcoFalke> wumpus: Yes, mostly
19:22:38 <wumpus> if someone broadcasts a *different* transaction, or one that would rank lower according to policy, this is suspect
19:22:41 <sdaftuar> sipa: i think a rebroadcast cap makes sense, also a cap on the number of things rebroadcast in one go (to prevent any kind of edge-case behavior)
19:22:51 <sipa> gleb: here?
19:22:59 <sdaftuar> he's away
19:23:02 <sipa> i'm wondering how to integrate this with erlay
19:23:20 <sipa> (which shouldn't be a blocker for this discussion of course, but it's nice to have things thought out)
19:23:33 <wumpus> I'm not entirely sure that this generates noise with enough variance to contribute to privacy
19:23:58 <sipa> wumpus: hmm?
19:24:12 <wumpus> it'd just change the logic to 'anyone that broadcasts a transaction that is not on the top of the mempool is broadcasting their own transaction'
19:24:15 <sipa> is your concern "this isn't enough" or "this doesn't contribute anything" (possible)
19:24:19 <provoostenator> In particular, this wouldn't benefit lowball fee transactions I assume?
19:24:32 <MarcoFalke> wumpus: The wallet rebroacast would be removed of course
19:24:34 <jnewbery_> wumpus: nodes would still relay new transactions they saw
19:24:41 <wumpus> MarcoFalke: ohhh!
19:24:45 <MarcoFalke> heh
19:24:47 <wumpus> MarcoFalke: okay then it makes a lot more sense
19:25:21 <MarcoFalke> Maybe we should introduce each topic with a three line summary
19:25:37 <provoostenator> (I mean: I would not add more privacy to wallet transactions with a low fee, but also doesn't make it worse)
19:25:41 * MarcoFalke meta
19:25:48 <provoostenator> *it
19:26:21 <achow101> how would this interact with prioritizetransaction? I assume it would be a privacy leak that you prioritize some particular transaction if that transaction was part of the rebroadcast but not the top for other nodes
19:26:24 <MarcoFalke> provoostenator: The fee rate should have no effect on privacy after the proposal is merged, no?
19:26:40 <amiti> provoostenator: my proposed changes would not rebroadcast wallet txns with a low fee until that txn makes it to the top of the mempool
19:26:45 <sipa> hmm, so how will low-feerate transactions get broadcast at all?
19:26:47 <sdaftuar> achow101: i think we'd have to use a sort on actual feerate, and not modified feerate
19:26:56 <MarcoFalke> sipa: When they are created
19:26:57 <sdaftuar> sipa: pacakge relay, or wait til they get to the top of the mempool, i think?
19:26:59 <MarcoFalke> (once)
19:27:08 <sipa> oh, nvm; the normal "just entered the mempool" relay will do that, not rebroadcast logic
19:27:13 <amiti> sdaftuar: correct
19:28:17 <provoostenator> So IIUC (I should read the whole thing): we still broadcast the first time as per usual, but we only *rebroadcast* top of mempool?
19:28:27 <harding> So if I create a low fee transaction that doesn't get relayed initially for some reason, my wallet would never broadcast it unless I just happened to have my node open at the point where fees have dropped?
19:28:39 <amiti> provoostenator: correct
19:28:56 <wumpus> harding: it would broadcast it the first time
19:29:08 <harding> wumpus: right, but what if it wasn't relayed the first time?
19:29:25 <achow101> harding: I think it's the same situation now. you'd still have to wait for the fees to drop and have your wallet be open so that other nodes will accept it
19:29:40 <MarcoFalke> harding: Right, but we can improve inital relay as well
19:29:49 <MarcoFalke> (workin on it)TM
19:31:11 <wumpus> concept ACK on the idea from me
19:31:12 <harding> achow101: to overcome the dynamic minimum relay fee, that's true.  I'm thinking of the case where I generate a transaction with a (say) 288-block estimatesmartfee target.  That's only rarely going to be near the top of the mempool.  Right now, my wallet will rebroadcast that every hour or so (random delay); with this change, it'd only rebroadcast it if my wallet was open at the right time.
19:31:36 <sipa> harding: but on the other hand, your peers will do the rebroadcast for you
19:31:50 <sipa> those who heard the initial broadcast at least
19:32:39 <sipa> you can argue that that's relying on their altruistic behaviour, but right now we're already kinda doing that hoping for them to relay it at all
19:32:42 <sdaftuar> it seems reasonable for the wallet to try to ensure that the transaction was relayed to at least one peer, perhaps
19:32:43 <harding> An actual usecase of my is that I sendrawtransaction spends from my cold wallet with my network disabled so that I can do a final inspection of the transaction in my local mempool (mainly to check that I didn't forget an output and spend all to fees).  That means I always use wallet rebroadcasting in those cases.
19:32:43 <jnewbery_> harding: s/it'd only rebroadcast it if my wallet was open at the right time/it'd only rebroadcast if your node was online at the right time
19:32:49 <jnewbery_> but I think your point stil lstands
19:33:45 <achow101> harding: use testmempoolaccept instead?
19:33:49 <sipa> harding: that seems like a reasonable use case (though personally i'm using analyzepsbt for that now, before even broadcasting it)
19:34:06 <amiti> harding: you are right. in the circumstance where a low fee rate txn was not relayed the first time and none of your peers have it, these changes would make it take longer until your txn got rebroadcast, and potentially your node has to be online the right time.
19:34:14 <sipa> i do think we need a way for this to work when a tx is submitted to your mempool while you're offline
19:34:39 <provoostenator> One consideration I've seen discussed in a PR recently is that the node doesn't tell the wallet what happened.
19:34:43 <harding> sipa: I also do that now too.  When dealing with thousands of my money, it's belts, suspenders, extra belts, and extra suspenders.  :-)
19:34:44 <provoostenator> And one thing to also consider is that with dynamic loading, a user might unload their wallet after initial broadcast.
19:34:57 <sipa> wow thousands of moneys
19:35:08 <sdaftuar> a lot of ico's these days
19:35:24 <sipa> the mempool could have a per-tx flag "ever broadcast"
19:35:27 <MarcoFalke> Could the mempool keep track if the txs was pushed to at least one peer?
19:35:32 <sipa> jinx
19:35:55 <wumpus> IIRC the wallet used to keep track of number of broadcasts of a transaction, this was removed at some point
19:35:56 <sipa> in that case, even the initial broadcast of a tx could become pure mempool responsibility
19:36:02 <sipa> wumpus: correct
19:36:12 <achow101> sipa: isn't it already?
19:36:14 <sipa> though it was just used for showing in the UI whether a tx had propagated
19:36:19 <MarcoFalke> wumpus: That wouldn't work if the wallet is on a different node than the mempool
19:36:26 <sdaftuar> sipa: if you're the last of your peers to learn of a transaction, was it "ever broadcast"?
19:36:29 <wumpus> which wasa arguably somewhat useful :) but yes
19:36:31 <sipa> achow101: well i mean *the mempool* rather than ATMP
19:37:06 <sipa> sdaftuar: anything you've learned from the network would never get that flag, only rpc/wallet submissions
19:37:19 <MarcoFalke> sdaftuar: If you get the tx from the network it was broadcast
19:37:20 <wumpus> MarcoFalke: is that even possible?
19:37:39 <wumpus> the wallet will always submit the transaction to the local mempool first right?
19:37:46 <sipa> right
19:37:49 <MarcoFalke> Sure. Use signrawtransaction on the one with the wallet and sendrawtransaction on the one with the mempool
19:38:14 <wumpus> oh sure, but in that case you're handling everything manually anyway
19:38:29 <provoostenator> Well, that makes the sendrawtransaction node's mempool is responsible?
19:38:35 <wumpus> yes
19:38:49 <MarcoFalke> You'd still want your node to broadcast at least once (even if at the time of ATMP you were offline)
19:39:09 <sipa> right now if you use sendrawtransaction, it gets submitted to the mempool/network directly, from which your own wallet may learn it, who will then take over rebroadcasting
19:39:21 <sipa> because sendrawtransaction is a node RPC not a wallet RPC afaik
19:39:28 <wumpus> correct
19:39:44 <wumpus> there's no addrawwallettransaction or something like that
19:40:11 <wumpus> sendrawtransaction will unconditionally broadcast the transaction as well, so it's sometimes used for manual rebroadcast
19:40:56 <MarcoFalke> sendrawtransaction should mention that this is privacy leaking, maybe?
19:41:44 <wumpus> yes, the help could mention that
19:42:25 <sipa> amiti: what do you think about the "ever broadcast" flag idea?
19:42:29 <provoostenator> From the gist: "The wallet will attempt to resubmit unconfirmed transactions to the node on a scheduled timer" - does the node remember previously dropped txs?
19:42:44 <sipa> provoostenator: the wallet always remembers all its own transactions
19:42:49 <amiti> sipa: sounds great! noted.
19:42:59 <sipa> the mempool is completely neutral and doesn't treat our own txn different from anyone else's
19:43:09 <provoostenator> sipa: yes, but wouldn't this behavior just cause the node to do a fresh broadcast of all wallet transactions?
19:43:12 <amiti> well. if we add the flag, it wont be completely neutral anymore
19:43:16 <MarcoFalke> sipa: I like it. It sounds even orthogonal to amiti's proposed change
19:43:22 <sipa> MarcoFalke: indeed
19:43:32 <sipa> amiti: good point
19:43:48 <sipa> but at some point we have to treat our own txn different our they wouldn't be broadcast at all :)
19:43:51 <jnewbery_> sipa: we're wondering if the wallet rebroadcasting txs that it learns from the mempool is also true for txs received over p2p
19:44:07 <amiti> but, given the circumstances harding pointed out, it seems worth it
19:44:09 <jnewbery_> ie that your wallet can be dust-attacked and it'll start rebroadcasting the dust txs
19:44:20 <MarcoFalke> jnewbery_: It should
19:44:34 <MarcoFalke> s/should/probably does/
19:44:43 <sipa> jnewbery_: i think a tx learned through the network (wallet or not) should not be treated differently
19:44:57 <sipa> only things learned from the wallet or rpc, and never broadcast before
19:45:12 <MarcoFalke> jnewbery_:  I think this has been done in the past
19:45:13 <amiti> provoostenator: if I understand your question correctly, the node will not remember the txns it previously dropped. it would rely on the wallet to resubmit if needed
19:45:38 <MarcoFalke> Oh, no. It has been done to get the coinselection include the dust
19:45:58 <jnewbery_> I guess we want this flag to be saved to mempool.dat so we don't rebroadcast our own txs every time we restart
19:46:03 <sipa> jnewbery_: yeah
19:46:26 <sipa> that's scary because mempool saving is only done periodically (or even only at shutdown)
19:46:43 <sipa> so an unclean shutdown could result in unnecessary rebroadcast
19:46:47 <MarcoFalke> -nopersistmempool :eyses:
19:47:06 <provoostenator> Unnecessary rebroadcast as a result of a crash doesn't seem like a huge issue.
19:47:40 <MarcoFalke> rebroadcast on every start because you don't persist the mempool does sound like an issue
19:47:50 <harding> You could put the flag on the transaction in the wallet instead?  was_relayed_to_at_least_one_peer
19:48:08 <sipa> harding: a bit of a layer violation but yeah
19:48:23 <MarcoFalke> harding: That wouldn't work where the wallet is separate from the mempool (two nodes)
19:48:25 <sipa> it means that the "submit to mempool" function needs to return a bool broadcast or not
19:48:33 <sipa> oh right, it doesn't work for RPC
19:48:34 <provoostenator> Maybe the wallet could ask the node "Do you have this in your mempool?"
19:49:16 <provoostenator> And maybe also "Put in your mempool, but skip initial broadcast"
19:49:37 <sipa> right but it needs to work even when there is no wallet involved at all
19:49:42 <provoostenator> That moves responsibility to the wallet, which maybe makes sense because it cares about its own privacy.
19:50:03 <provoostenator> sipa: true, that's the downside
19:50:44 <MarcoFalke> We should remove broadcast logic from the wallet and the rpc and tell users to copy-paste the tx into a block explorer over tor
19:51:16 <wumpus> at least if their node is not connected to tor already
19:51:17 <sipa> ha
19:51:18 <provoostenator> Node->WalletTransactionBroadcastDelegate
19:51:39 <wumpus> but yes, this was kind of my point with -walletbroadcast=0
19:51:55 <sipa> do we have other topics? :p
19:52:40 <wumpus> #topic bitcoinbuilds.org (jonasschnelli)
19:52:45 <hugohn> question: if there are empty blocks (could be consecutive), will every node rebroadcast top of the mempool?
19:52:52 <jonasschnelli> It's a custom built open source CI that is/can-be-further tailored to our needs. Super slim.
19:52:55 <MarcoFalke> hugohn: I think so
19:52:58 <jonasschnelli> bitcoinbuilds.org
19:53:02 <jonasschnelli> Feature wise its on the same level then travis. Builds fast or even faster then travis on a 50EUR/month machine.
19:53:07 <jonasschnelli> Additionally, one can download the build results and it logs times per task (install/compile-depends/configure/compile/run-tests/etc.)
19:53:10 <wumpus> jonasschnelli: nice !
19:53:13 <jonasschnelli> Sources are here: https://github.com/jonasschnelli/bitcoin-core-ci
19:53:17 <jonasschnelli> Intention is not to replace travis. Just to have a backup option for times when we need it.
19:53:17 <wumpus> so we can trash travis now? :)
19:53:23 <wumpus> oh
19:53:38 <jonasschnelli> Maybe at some point.. but not now
19:53:44 <jonasschnelli> I added a github hook.
19:53:48 <wumpus> github integration is probably the most difficult part
19:53:54 <jonasschnelli> So it builds are PRs (master after merges soon)
19:54:01 <jonasschnelli> Integration with github is easy
19:54:03 <wumpus> (e.g. reporting the status on github)
19:54:23 <wumpus> oh! it used to be pretty much impossible for custom tools
19:54:24 <jonasschnelli> In general... I was surprised how easy it is to "clone travis"
19:54:48 <MarcoFalke> reply from travis: "Thank you for getting in touch and for raising this issue as well. I apologise for the frustration caused over the last month regarding the problems, and I can assure you we are committed to improving your overall experience while using the platform."
19:54:49 <jonasschnelli> (though tailored)
19:55:20 <jonasschnelli> However,.. feel free to check your PR build on bitcoinbuilds.org and contribute to futher extend it to our needs.
19:55:43 <meshcollider> Currently it just compiles I guess, are you planning on adding test execution?
19:55:44 <jonasschnelli> cfields more detailed dependency cache would certainly be a build-performance booster (for some types of builds)
19:55:50 <wumpus> MarcoFalke: hopefully that means anything
19:55:56 <jonasschnelli> meshcollider; it runs the test on linux64/32
19:56:07 <MarcoFalke> wumpus: I'd guess its a template response
19:56:16 <meshcollider> Oh nice :)
19:56:17 <jonasschnelli> I have also plans to allow running tests on other machines over the internet (like run the ARM tests on a odroid or so)
19:56:42 <MarcoFalke> Nice
19:56:49 <jonasschnelli> Contributions welcome...
19:57:04 <jnewbery_> jonasschnelli: does it use the same travis.yaml format for configuration?
19:57:12 <jonasschnelli> almost...
19:57:24 <jonasschnelli> https://github.com/jonasschnelli/bitcoin-core-ci/blob/master/default.yml
19:57:32 <jonasschnelli> It's static for now to not pollute our git
19:58:08 <wumpus> oh that's neat!
19:58:21 <sipa> ideally our travis.yml doesn't really contain any logic apart from "invoke CI step 1", "invoke CI step 2.a", and caching ... which are implemented as a shell script
19:58:50 <jonasschnelli> yes
19:58:53 <jnewbery_> sipa: for logic yes, but there's various config in there too
19:58:55 <MarcoFalke> Some of the variables in the script are travis specific, but it shouldn't be too hard to replace them
19:59:05 <sipa> right
19:59:18 <MarcoFalke> Happy to review a pull if someone wants to pull them out
19:59:42 <jonasschnelli> We could use the .travis folder in the custom CI,.. sure.
19:59:56 <jnewbery_> jonasschnelli: do you plan to update https://github.com/jonasschnelli/bitcoin-core-ci/blob/master/default.yml if the travis.yml file changes
20:00:01 * sipa -> lunch
20:00:11 <jonasschnelli> jnewbery_: I could..
20:00:16 * MarcoFalke -> tea
20:00:17 <jonasschnelli> or we add one in our github
20:00:23 <jonasschnelli> or we load .travis
20:00:29 <jonasschnelli> *dong*
20:00:40 <wumpus> #endmeeting