< kallewoof>
#proposedmeetingtopic how should signet params be prefixed? currently "signet_<..>" e.g. "signet_challenge"
< jonatack>
kallewoof: i suppose signetchallenge, as that's how all the others are (except reindex-chainstate that uses lispy kebab-case)
< gleb>
What's the real expectation between blocksonly-mode/block-relay-only-conns and RELAY permission? If a blocksonly-node assignes the permission to a peer, this peer *is allowed* to relay transactions (we won't disconnect them like we do without permission). However, in practice, they would never do, because blocksonly-node tells them not to
< gleb>
(fRelay=false in the VERSION message).
< bitcoin-git>
[bitcoin] ajtowns closed pull request #15502: p2p: Speed up initial connection to p2p network (master...201902-trytoavoiddns) https://github.com/bitcoin/bitcoin/pull/15502
< bitcoin-git>
[bitcoin] robot-dreams opened pull request #19967: test: Replace (dis)?connect_nodes globals with TestFramework methods (master...connect-nodes) https://github.com/bitcoin/bitcoin/pull/19967
< bitcoin-git>
[bitcoin] robot-dreams opened pull request #19968: doc: make it easier to work out size of bloom filter (master...bloom-doc) https://github.com/bitcoin/bitcoin/pull/19968
< sdaftuar_>
gleb: if A sends B a version message where frelaytxes=false, that means that B should not announce transactions to A
< sdaftuar_>
it does not mean that A will not announce transactions to B
< sdaftuar>
the reason that is in the protocol is to support light-clients that might need a window of time to send over a bloom filter to B, to avoid their bandwidth being flooded in between sending a version and sending the filter
< sdaftuar>
(i believe)
< sdaftuar>
we piggy-backed off that functionality being present when -blocksonly mode was added
< sdaftuar>
and then again when block-relay-only peers were added
< gleb>
sdaftuar: That's a different thing, I'm talking about sending txs from B->A. It should not announce transactions, and we will disconnect if they do. Except the case if we re-allow it with RELAY permission
< gleb>
Then it's allowed to send transactions B->A and A will process them just fine.
< gleb>
But node B running Bitcoin Core currently doesn't employ this ability, because it doesn't know it's permitted.
< sdaftuar>
gleb: ah i see
< sdaftuar>
so in general B has no way of knowing that A has given it those permissions
< sdaftuar>
hmm. what happens if you connect to a node that is running in blocksonly mode?
< vasild>
I have an excellent idea about renaming sendaddrv2 to a generic capabilities and making it possible to include various options inside it. Like capabilities(send me addrv2, I participate in gossip, whatnot, my favorite color is blue)
< vasild>
"excellent"... until somebody shoots it down :)
< wumpus>
things like that were proposed before, though never in the for of a BIP afaik, but I think that's out of scope of BIP155
< wumpus>
I think it'd be good to keep sendaddrv2's prameters restricted to things concerning, well, network addresses and address gossiping
< vasild>
I agree it is out of scope, but I also think "I participate in gossip" is out of scope for bip155, if we consider that its purpose is to support larger than 16 byte addresses
< sipa>
wumpus: agree
< sipa>
vasild: maybe...
< wumpus>
the deadlines for 0.21 are also getting closer, in case that's what you were aiming for
< vasild>
yeah
< wumpus>
vasild: well at least it's still close enough, proposing a general capability message is a can of worms
< jnewbery>
moot time
< sipa>
hi.
< vasild>
I was just thinking - if we make it sendaddrv2(your address is X, I participate in gossip) we may as well s/sendaddr/capabilities/ :)
< wumpus>
it also brings back the discussion of when to send it, for example, for a lot of capabilities you'd want to know them at connection time and not at some point later
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Sep 17 19:01:00 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< gribble>
https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
< luke-jr>
although it looks like I already have 2 there, the ramifications of missing 0.21 with this is pretty annoying
< wumpus>
I'm still not sure about the writable configuration files (didn't we have two conflicting systems now?) but in any case, added
< wumpus>
not the time to have that discussion now
< wumpus>
#topic Endomorphism optimization in libsecp256k1 (sipa)
< vasild>
I have never seen such dual configs in any other software...
< sipa>
hi!
< sipa>
this is mostly a short announcement so it doesn't cause any surprise
< sipa>
libsecp256k1 started out as an experiment to see how much secp256k1 EC operations could be made by using the GLV endomorphism optimization, which it was specifically designed to support, but not actually implemented anywhere
< luke-jr>
vasild: that's kinda the point; it reduces to one config format
< fjahr>
hi
< sipa>
as it turned out that there is some risk it is encumbered by a patent, the GLV optimization was made optional, and defaults to off (and has been off in every bitcoin core release)
< sipa>
it looks like that patent is expiring on september 25th, and blockstream had a patent attorney verify that (i'm happy to share their findings, if anyone cares)
< wumpus>
yay!
< cfields>
wooo!
< luke-jr>
sipa: how sure can we be that it can't break consensus?
< sipa>
so the plan is to switch it to default on after that date, or even rip out the non-GLV code
< sipa>
luke-jr: good question
< luke-jr>
is it provable? :x
< sipa>
libsecp256k1' CI has always tested with both endomorphism enabled and disabled
< sipa>
including our exhaustive tests, which are probably as close to a mathemetical proof we can get for real software - at least for some aspects
< sipa>
fwiw, that's a test where the library is compiled with a slightly different curve equation that makes it trivially insecure, and only leaves 12 valid private/public keys
< sipa>
and in that mode, we can test literally every combination of signature/pubkey/private key
< wumpus>
nice
< sipa>
so i think that given that, it shouldn't be any more invasive than regular code changes to libsecp256k1
< luke-jr>
has it been proven on a mathematical level? (not saying it's a problem if not, just asking)
< sipa>
luke-jr: for some parts of the code we have actual proofs (some hand-written, some automatic); though admittedly not the part touched by the endomorphism
< wumpus>
I think he means in mathetmatical theory, not so much the specific code
< luke-jr>
right
< sipa>
wumpus: for the group arithmetic, there is a transliteration of the C code to python, which is then symbolically executed and can be automatically proven correct
< provoostenator>
Very cool, somewhat scary, but how much of a speedup is this?
< sipa>
the conversion from C to Python (or its semantics) of course aren't, but the algorithms at a slightly higher level are proven
< wumpus>
sipa: that's a very interesting approach
< sipa>
provoostenator: 27% for ecdsa verification
< provoostenator>
Ok, that's worth some code review time alright.
< wumpus>
very hard to say no to that :)
< sipa>
well
< sipa>
arguably, libsecp256k1 originally _only_ had the GLV mode
< sipa>
the mode where GLV was disabled (which is now default) was added later
< wumpus>
yes it was added out of patent concerns
< sipa>
yes
< sipa>
but all changes since 2013 have always kept both GLV and non-GLV working, and tested
< meshcollider>
Interesting, I didn't know that
< luke-jr>
was the GLV mode ever released in Core?
< wumpus>
no
< sipa>
luke-jr: it's a compile time option, and it was never enabled in (default) builds of core
< sipa>
you could always enable it yourself with --enable-endomorphism
< luke-jr>
right, not sure how many people actually did that tho :p
< wumpus>
some people did it for benchmarking at times
< wumpus>
apart from that, dunno
< sipa>
luke-jr: i assume nobody
< vasild>
If there are concernts, what about doing all calculus in both and comparing they produce the same result?
< luke-jr>
we do have a USE flag for it in Gentoo, but no metrics on usage
< sipa>
vasild: that's arguably what the unit tests are doing
< sipa>
if they differed, at least one would fail
< luke-jr>
vasild: you mean in real-world use? what's the point?
< meshcollider>
sipa: why not just test it out on all secp256k1 keys to make sure ;)
< sipa>
meshcollider: that's what the exhaustive test mode does
< luke-jr>
meshcollider: :D
< vasild>
I mean, in real life, in production, for e.g. 6 months. But I am not suggesting that, just saying "if there are concerns" :)
< sipa>
vasild: i believe that is pointless
< vasild>
ok, I can't judge
< sipa>
due to the cryptographic nature of things, actual correct _random_ usage is never going to trigger an edge case if one existed
< luke-jr>
I think you could just build with it enabled, and do a full sync
< wumpus>
trying completely random input is very likely not going to find anything
< wumpus>
right
< luke-jr>
if anything deviates, the sync should fail, right?
< sipa>
luke-jr: in theory it could be accepting invalid signatures, which wouldn't be caught by such a test
< sipa>
though again, this is true for every change to the cryptographic code
< luke-jr>
sipa: but vasild's suggestion wouldn't detect that either
< sipa>
luke-jr: indeed
< sipa>
the exhaustive test likely would though
< sipa>
or at least, has a reasonable chance to - it depends on the nature of the hypothetical bug
< wumpus>
I'd assume you have 100% code coverage of that code in the test? (not that that proves anything, of course, but at least all paths are being exercised)
< sipa>
wumpus: i believe we have code coverage of everything that isn't impossible to reach, but i'll go verify that
< wumpus>
sipa: thanks!
< sipa>
so, expect a libsecp256k1 update shortly after september 25th
< wumpus>
thanks for the announcement sipa, let's move to next topic
< sipa>
discussion on testing and whatnot can still happen in the PR
< sipa>
that's all from me
< jnewbery>
that's great news sipa!
< wumpus>
#topic How should signet params be prefixed? (kallewoof)
< jonatack>
i suppose signetchallenge, as that's how all the others are, except reindex-chainstate that uses lispy kebab-case
< wumpus>
I didn't like _ in command line parameters, - would be ok-ish with me (because it matches the - symbol at the beginning), but our convention seems to be to just concatentate
< sipa>
it looks like all 3 styles are used; there is -rpcpport, there is -reindex-chainstate, there is -output_csv (to bench)
< sipa>
my preference is the first (just squeeze things), but apart from that i don't care, and i don't think it's worth much discussion time :)
< wumpus>
_ is definitely the worst to me at least, it's harder to type too
< luke-jr>
why not -signet=<param>
< wumpus>
I do think it is good to be consistent and come up with a standard way also for future arguments
< achow101>
traditionally we just stick them together without any separator, so just do that?
< wumpus>
luke-jr: because there may be other signet arguments in the future
< sipa>
there are several alredy
< wumpus>
and it's more consistent with -regtest -testnet to have it as a boolean anyhow
< wumpus>
yes
< wumpus>
achow101: +1
< jnewbery>
ACK squeezecase
< wumpus>
okay, the sentiment here seems to be clear, if no one else is going to weigh in, we're going to next topic
< wumpus>
#topic Size limit for data-driven unit tests (sipa)
< sipa>
hi!
< luke-jr>
o hai thar sipa?
< sipa>
in #19953 i've recently added a unit test with randomly-generated transaction validation success/failure cases, minimized using the fuzzing framework (it's not an actual fuzzer, all input is generated by a python script, but just minimized using the fuzz build)
< sipa>
which i think is an interesting approach as it permits getting the kind of coverage you get by running the python functional test for days... weeks...
< sipa>
it's 250 kB now, which seems in line with some of the other tests we have
< sipa>
but i could extend this to test more things, and in particular more validation flags
< luke-jr>
does that create a dep on fuzzing stuff for normal tests? :x
< sipa>
luke-jr: nope, just a json file
< sipa>
with the output of the whole fuzzing procedure
< luke-jr>
aha
< sipa>
anyway, trying to extend this, using the same approach, leaves me with things in the 1-2 MB range
< wumpus>
I think we should be careful to not add too much data for tests to the repository, git is not that great for bulk data storage, though 250kB seems fine to me
< sipa>
and i was wondering if that's acceptable
< sipa>
there are many more tradeoffs possible, which can reduce that - or extend it - in exchange for coverage/development time
< sipa>
but if people are like "1 MB is just fine", that would simplify things
< wumpus>
another drawback of large files is that it generates huge diffs, and this isn't really reviewable
< jonasschnelli>
I guess the runtime memory requirements are unchanged for that?
< sipa>
jonasschnelli: yes, it's just a (very simple) unit test
< wumpus>
jonasschnelli: yes, it's only used at test time
< sipa>
it's also 1 MB of json which is presumably compressed quite a bit by git
< cfields>
sipa: does it compress at all in git?
< vasild>
the json contains ascii hex, what if we save it in binary? would be 2x reduce
< cfields>
hah
< wumpus>
but as it's part of a unit test it also can't easily be moved to another repository like the fuzz dataset one
< sipa>
vasild: yes, possible - but if git compresses it already in a similar degree, leaving it in a more readable form has advantages
< luke-jr>
is there a reason not to just make this part of the fuzzer build?
< sipa>
luke-jr: it's not a fuzzer
< sipa>
you can't run it as a fuzzer
< sipa>
(it would immediately fail, as it's not testing random inputs)
< vasild>
sipa: right, I guess disk space when checked out is irrelevant for such sizes
< luke-jr>
sipa: but can't the 250k be generated at test-time?
< wumpus>
jnewbery: yes, that's what I meant, the only thing is that it takes an extra step then
< sipa>
luke-jr: to be clear, this is a test that _already_ runs as a functional test, but only for 1 minute
< wumpus>
someone who wants to read the test also needs that erpository checked out -- not a problem for the CI at leat
< sipa>
luke-jr: the approach to extract a very-good-coverage unit test from it makes it a bit more accessible and reusable, and gives the same coverage as running the functional test 1000s of times
< sipa>
wumpus: that's reasonable, i guess
< sipa>
skip the test if the json file isn't found
< sipa>
or something like that
< wumpus>
sipa: yes, sounds fair to me
< * luke-jr>
glares at boost for not supporting skips still (last I checked)
< wumpus>
though there are already some ~250kB json files in the repo, for the tests, I don't think one more is that bad... but let's not make a habit out of it, and also, you're planning to add more data in the future
< ryanofsky>
I like the qa assetts idea. Skipping the test if input not found is also similar to what we do for backwards compatibility tests
< sipa>
luke-jr: "return true;" works great
< wumpus>
yes
< luke-jr>
sipa: except it gives the impression it passed?
< ryanofsky>
No objection to 250kb either, though
< sipa>
luke-jr: "make check" also doesn't run the fuzz tests; does that give the impression they passed? :)
< sipa>
there could be a "notice: qa-assets not found, so large data-driven tests are skipped"
< luke-jr>
sipa: boost explicitly says the tests pass..
< sipa>
luke-jr: in aggregate
< luke-jr>
sipa: individually
< luke-jr>
sipa: this is a problem for another test already IIRC
< wumpus>
ok, I think we've given sipa quite some input on this for now, decision doesn't need to be made in the meeting, only ~20 minutes left, and 1 or 2 topics
< wumpus>
#topic AssertLockHeld PRs (ryanofsky)
< ryanofsky>
Debug lockerorder test is a test that passes if skipped, but minor one
< ryanofsky>
If anyone is interested in AssertLockHeld improvements but confused by the multiple PRs, page summarizes them
< sipa>
ryanofsky: thanks for that
< jonatack>
ryanofsky: v nice
< * sipa>
is quite overwhelmed by it
< wumpus>
yes good to have an overview
< ryanofsky>
Sure, that's all I have for the topic
< wumpus>
what would "WeaklyAssertLockHeld" do compared to the normal assert?
< vasild>
indeed! (confusing name)
< ryanofsky>
They both do the same thing at runtime, which is why my preference is to have one assert instead of two
< sipa>
and the difference is that one also does a compile-check (if supported) and the other doesn't?
< wumpus>
it sounds really weird to me a lock is held or not :)
< ryanofsky>
But if we can't have one assert, there are cases where the stronger assert isn't accepted at compile time and you need to use the weaker one
< vasild>
btw, one of the clang people suggested that we don't annotate AssertLockHeld() with any compile time attributes and leave it pure run time.
< wumpus>
oh, like that
< luke-jr>
I don't get why one would use Assert* instead of EXCLUSIVE_LOCKS_REQUIRED
< luke-jr>
outside of perhaps a conditional
< wumpus>
it's an assertion that existed way before the lock annotations did
< sipa>
lock annotations also only work in clang
< wumpus>
ouch
< luke-jr>
oh :/
< sipa>
and can't be used for some of the more complex cases, i assume
< vasild>
luke-jr: runtime asserts work always, compile time _warnings_ - only for clang and if you compile with --enable-werror and if clang does not have bugs etc
< ryanofsky>
luke-jr, infrequently there are cases where the compile can't know EXCLUSIVE_LOCKS_REQUIRED is satisfied and you have to tell it that
< sipa>
vasild: well, they only work in -DDEBUG_LOCKORDER mode, which you don't want to use for production :)
< ryanofsky>
that is what assert is useful for
< sipa>
so they're overlapping but one is not a subset of the other, in terms of what they can detect
< ryanofsky>
the other thing assert is useful for (i don't think very useful) is when compile time checks are unavailable or disabled or buggy
< wumpus>
apparently they're clang only so they're often not available
< wumpus>
i'm fairly sure most people compile with gcc, at least on linux
< ryanofsky>
right but they run on CI
< ryanofsky>
and if you are compiling with gcc, you have to enable run time checks and execute the code and hope an assert is hit to see any benefit from it
< wumpus>
yes
< vasild>
having CI as the sole protection seems uncomfortable to me - it does not run manual tests
< vasild>
developers do on their machines
< luke-jr>
ideally all tests would exist in the automated form ;)
< ryanofsky>
vasild, compile time checks check correctness at compile time they have no effect on runtime generated code
< wumpus>
i wonder how many developers are compiling with DEBUG_LOCKORDER anyway, well probably those that are working on locking changes do
< ryanofsky>
there's 0 benefit to compiling with compiling checks and then running bitcoind locally
< vasild>
wumpus: it is enabled bug --enable-debug
< vasild>
19954 is only about when bitcoin core creates a tor hidden service automatically via the tor control connection -- it would start creating torv3 with that PR
< jonatack>
i certainly only see a v3 local address with 19954
< luke-jr>
I prefer to add features, and remove others, in separate PRs ;)
< sipa>
luke-jr: fwiw, perhaps i misunderstood your question earlier; the concept of the endomorphism optimization is easy to prove (it's a standard result in algebraic geometry) - so we know that if implemented correctly, it works
< luke-jr>
sipa: great, that's what I meant
< jonatack>
vasild: ok i'll look into what happens with the proxy and 19954
< sipa>
luke-jr: in slightly more detail, it's similar to how we know that -(x,y) = (x,-y) for elliptic curve points
< luke-jr>
>implying I understand EC :p
< sipa>
luke-jr: "negating a point negates the Y coordinate"
< sipa>
does that sounds familiar?
< luke-jr>
no
< sipa>
ok!
< sipa>
luke-jr: you know how compressed public keys consist of 0x02 or 0x03, followed by 32 bytes X coordinate?
< luke-jr>
sure
< michaelfolkson>
With my untrained eye Signet and Tor v3 both seem to be a rush to get in for October. What is the history of new features like that needing updates in minor versions because they weren't fully cooked for the major version they were part of?
< sipa>
luke-jr: the 0x02 indicates whether the Y coordinate is odd or even; that works because for every point, a point with the same X coordinate but opposite Y coordinate exists (and modulo p, negating changes odd to even and the other way around)
< luke-jr>
sipa: btw don't feel like you need to explain it to me - I'm sure if I read through gmax's educational material I'd understand
< sipa>
ok
< luke-jr>
michaelfolkson: for software in general, there's a general idea that .0 will have bugs :P
< michaelfolkson>
Haven't seen any gmax educational material teaching EC. Any links?!
< michaelfolkson>
Ok luke-jr. So it is kind of expected that Signet and Tor might need to be cleaned up in minor versions
< wumpus>
michaelfolkson: it's often been done
< vasild>
michaelfolkson: so far torv3 has been going very steadily (no rush so far)
< luke-jr>
michaelfolkson: crap, I think I lost it
< michaelfolkson>
Yeah definitely not so far vasild. Just projecting forward
< vasild>
that does not mean it is not going to be rushed from here :)
< wumpus>
we've had much more rushed things in .0 major releases, signet and torv3 have been going on for a while and don't seem super hurried
< sipa>
right, there is a difference between prioritizing and rushing
< wumpus>
obviously I didn't mean "it needs to be in 0.21 at all costs", that's not how our releases work
< michaelfolkson>
Ah ok never mind. Thanks for looking luke-jr
< michaelfolkson>
And then to stir the pot, ideally we would have Signet in 0.21 to encourage Taproot testing on Signet?
< wumpus>
signet is entirely opt-in, it's not that bad if it's still somewhat experimental, the important thing is that it doesn't break non-signet use
< michaelfolkson>
No because it woulds still need to be a custom Signet for Taproot testing
< michaelfolkson>
And the 0.21 release will be the default Signet (hopefully)
< sipa>
taproot can be soft-forked into signet if the signers decide so
< wumpus>
the Tor changes should definitely be correct in one go, it would be really bad to break Tor support, but we have a lot of interest and testing for that so I'm not too afraid
< michaelfolkson>
Ok so (hopefully) Signet in 0.21 and then Taproot could be soft forked into Signet by the signers in a minor release or the next major Core release?
< sipa>
kallewoof, aj: would it be useful to have different terms between signet (as in the bitcoind mode that enables signet configuration/rules) and signet (the default global testnet run by you two)
< michaelfolkson>
Soft forking Signet for Taproot testing should be a given. That obviously doesn't mean anything in terms of a final community decision on Taproot activation etc for mainnet
< aj>
sipa: "default signet", "custom signets" are the terms to distinguish the the one kallewoof and i sign from what anyone else might set up
< sipa>
aj: that sounds embarassingly sane
< michaelfolkson>
I think I proposed "main signet" lol
< michaelfolkson>
What is your latest thinking on updating proposed soft forks for mainnet that are already on Signet aj? Still effective hard forks?
< aj>
michaelfolkson: updates to not-activated-on-testnet/mainnet or not-merged-to-master consensus changes might well be hard forks from vN to v(N+1) (or commit xxxxx^ to xxxxx), question is just how to deal with that
< aj>
ryanofsky: "AJA" is precisely "2A" except calling it "LOCK_ALREADY_HELD" instead of "WeaklyAssertLock"
< elichai2>
luke-jr: fwiw I'm running with endomorphism for at least a year while updating each release and IBDing with assumevalid=0
< instagibbs>
elichai2, "hello, policia?".gif
< instagibbs>
what was the overall difference?
< elichai2>
I didn't test the differences actually, but I think I got something like ~4 hours for full ibd with assumevalid=0 last time, I should retry without redownloading
< elichai2>
But my point was about "is anyone using this" and "sync will fail if it's wrong" :)
< elichai2>
Hehe yeah I'm sure they wanna sue me for patent infringement lol
< elichai2>
(about the topic, it might be a bit late but I personally would love to see those ifdefs on endo being removed :) I think it will even potentially increase the security of the code because of less preprocessor complexity and compile options)
< * jonatack>
elichai2 hears an early-morning knock at the door
< jonatack>
elichai2: pretty cool that you've been testing it. i wondered what that was, TIL
< elichai2>
Yeah it's a great perf boost :)
< jonatack>
my 4 cores of cpu will be happy about that
< instagibbs>
IIRC the endomorphism was the inspiration for libsecp
< instagibbs>
sipa tried it out then got rabbit holed
< sipa>
instagibbs: yes, read meeting log from today :)
< elichai2>
I'm also testing with libgmp although that will hopefully won't be needed anymore very soon🙏
< jonatack>
vasild: Ok now have the node advertising both torv2 and torv3 local addresses...just needed to set proxy=127.0.0.1:9050 rather than letting bitcoin core create a tor HS automatically, as you mentioned
< jonatack>
(d'oh--and all good)
< jonatack>
i'm fairly confident with respect to PR 19845. will move on to proper review of 19954.
< aj>
hm, would it be crazy to allow - and/or _ in config options the same way gmail allows . in addresses? ie just treat -signet-challenge and -signetchallenge (and -s-i-g-n-e-t-c-h-a-l-l-e-n-g-e) as aliases? i find squeezecase a pain to read
< * sipa>
suggests: spaces
< sipa>
./src/bitcoind "-signet challenge=51"
< sipa>
aj: we already allow - and -- for everything, i think
< luke-jr>
aj: might be exploitable
< luke-jr>
"just run the Fun Draw Transaction RPC"
< luke-jr>
(not command line, but there may be comparable cases now or in the future)
< sipa>
-fun roll loops
< aj>
luke-jr: you could do that exploit already
< luke-jr>
?
< luke-jr>
oh, maybe, but it's a lot more problematic if you make it explicitly innocent
< aj>
luke-jr: "just run the Fun Draw Transaction RPC -fundrawtransaction"
< luke-jr>
-fun-draw-transaction is a lot more dangerous than -fundrawtransaction IMO