< spudowiar>
What's your preference for starting a process and piping data?
< spudowiar>
fork, pipe, dup2?
< spudowiar>
I mean pipe, fork , dup2
< spudowiar>
popen won't work because it only supports one direction
< spudowiar>
Actually, Boost dependency was updated to 1.64.0 which has boost::process
< spudowiar>
One issue I have is that waiting for the output of the command is run on the UI thread, so Bitcoin Core appears to hang :/
< BlueMatt>
luke-jr: you appear to have seemingly removed nearly all nuance
< BlueMatt>
luke-jr: you should have a category like "Fine, iff there is massive community consensus that doesnt nearly yet exist"
< BlueMatt>
then you could probably drop almost everyone into that category
< luke-jr>
BlueMatt: that's kinda chicken-and-egg. people are deferring to dev pessimism as a reason to not consent themselves. but if you have a suggestion to get more nuance on the wiki page, we can do that anyway. Perhaps a yellow "Wanting" defined as "it is acceptable, only with more community acceptance"?
< BlueMatt>
luke-jr: i didnt say "want", i said "fuck no, not without a massive consensus success, which appears to have about zero chance at this moment"
< BlueMatt>
luke-jr: and, no, while some rando folks are deferring to devs there, a lot are not, and are flat out saying "this is stupid"
< luke-jr>
I was thinking "wanting" as in "I think it is wanting for support"; alternative table-fitting words?
< luke-jr>
BlueMatt: people against BIP148 on their own are a very small group
< gmaxwell>
luke-jr: perhaps you should take it seriously when many people are telling you that this is a lot like Bitcoin XT or Bitcoin Classic's hardfork, but you've just defined yourself into a corner.
< BlueMatt>
luke-jr: people against classic and xt initially were a very small group, fwiw, its only after it became clear that there was a lack of consensus and serious technical concern that folks started jumping ship
< BlueMatt>
luke-jr: a series of people saying "this is too risky, I cannot support" (and i mean not just dev folks, also several biz folks have made similar noise) should not imply "ok, full steam ahead, they'll come around"
< luke-jr>
there is no comparison. Classic/XT were hardfork proposals with serious technical problems and done by trolls who wanted to "fire Core". BIP148 is a softfork proposal with no real technical problems, and widespread community support.
< BlueMatt>
luke-jr: I was told my several of the most ardent 148 supporters last week that 148 will "fire core" cause core is now getting in the way
< luke-jr>
BlueMatt: not doing BIP148 is objectively riskier than BIP148 itself, which has no risk at all given sufficient support.
< BlueMatt>
luke-jr: that is your opinion. other equally-well-informed minds strongly disagree
< BlueMatt>
luke-jr: and, key to your point is "given sufficient support", but, then, "given sufficient support" nearly any consensus change becomes incredibly easy
< BlueMatt>
luke-jr: and most of what I'm telling you is that bip 148 can not, and will not, get sufficient support in the current community
< luke-jr>
it already has it; the only potential risk is people blindly following "Core" who think "Core" is opposed
< midnightmagic>
Don't use language that guarantees people can't work together anymore after the resolution becomes clear. There are *actually* bad people sharpening their knives watching.
< luke-jr>
midnightmagic: ? referring to what
< midnightmagic>
This escalation that's going on in here right now, and jerkoffs who are going to attempt to use it to harm you all in the near future.
< sipa>
luke-jr: also don't equate "against merging support for BIP148 in core" with "against BIP148"
< sipa>
the bar for the first is far higher than personal preferences
< luke-jr>
sipa: are you of a position that BIP148 should not be merged, but you don't oppose it personally?
< luke-jr>
(the wiki page is intended to be the latter)
< sipa>
if there were pervasive support for BIp148, i would encourage it
< sipa>
right now, i think it is too risky (for a combination of technical reasons, too short timeframe, and me not seeing the degree of support i believe is necessary to make it a success) to encourage anyone to run it
< sipa>
but i'm not opposed to it in principle... in particular, i'd like be proven wrong on the degree of support which is admitted hard to measure
< sipa>
*admittedly
< luke-jr>
okay, I've updated the wiki page with two new categories Deficient and Wanting, and reclassified BIP148 for Matt as Deficient and sipa as Wanting; hope this is accurate
< luke-jr>
aside from BIP148, it would be helpful to get positions on the other proposals on the page
< luke-jr>
(and feel free to edit descriptions/colours/add new categories/etc if you think it helps improve clarity)
< spudowiar>
Hmm, either this transaction is totally messed up or EncodeHexTx is totally messing it up
< spudowiar>
Or python-bitcoinlib is messed up
< spudowiar>
Right, decoderawtransaction is working fine on this tx
< spudowiar>
Oh, wait, this is a SegWit tx
< spudowiar>
I assume that python-bitcoinlib doesn't handle SegWit
< jonasschnelli>
Can you make it vendor independent? :)
< spudowiar>
You need another script for each vendor :)
< jonasschnelli>
I guess we need a standard
< luke-jr>
jonasschnelli: the whole point is that the script is the interface
< spudowiar>
The command is `src/qt/bitcoin-qt -testnet -hardwarewallet=contrib/bitcoin-hww-trezor`
< spudowiar>
Or bitcoind if that floats your boat :)
< jonasschnelli>
ah. I see.
< jonasschnelli>
I though the script is the only thing you need
< spudowiar>
You have a script for each hardware wallet, and you set -hardwarewallet= to the script
< spudowiar>
One issue with this patch is that it runs on the UI thread so Bitcoin-Qt hangs while you confirm it on the hardware wallet
< sipa>
that sounds pretty bad :)
< luke-jr>
could be worse
< luke-jr>
but definitely something to fix
< spudowiar>
luke-jr, always optimistic
< spudowiar>
There are issues about moving stuff off the UI thread so I didn't bother with it at the moment
< spudowiar>
When CreateTransaction gets moved off the UI thread, this will fix itself
< luke-jr>
spudowiar: you mean sign?
< luke-jr>
IMO we should prompt in GUI for fee/etc before trying to sign
< spudowiar>
Well, CreateTransaction calls the signature stuff
< spudowiar>
Whoops, need to add CallHardwareWallet into CWallet::SignTransaction as well
< spudowiar>
Anyway, one issue is that it's not doing change addresses right ATM
< spudowiar>
So, it sees them as an extra output
< sipa>
is that a problem?
< spudowiar>
Yes, but it's one I can fix :)
< spudowiar>
Because the hardware wallet isn't meant to show the change addresses
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10527: Use parentheses to clarify intended precedence when using bitwise operations (master...clarify-precedence) https://github.com/bitcoin/bitcoin/pull/10527
< spudowiar>
e.g. I sent 0.7 tBTC and I had 1.3 tBTC, so the TREZOR asked me to send 1.299 tBTC when it should have said 0.7 tBTC
< sipa>
right; i guess you should have a way to tell the hardware "output X is to derivation path Y, which is yours; don't include it in the amount"
< sipa>
for historical reasons, bitcoin treats txids as little-endian 256-bit numbers, and when printing them for human consumption, uses big-endian (because that's how we format numbers)
< sipa>
as a result, the hex string is in the opposite order from the actual bytes
< spudowiar>
I know, but this isn't a hex string
< spudowiar>
I *think*
< spudowiar>
Yeah, it's not a hex string
< sipa>
hmm
< sipa>
still may be some LE/BE confusion
< spudowiar>
Maybe, I'll have a look at my code again another day, do a bit of refactoring
< spudowiar>
gtg
< BlueMatt>
luke-jr: ehh, I'm more of the "not really ok with the idea, also considers it to have insufficient community support" view
< luke-jr>
BlueMatt: how is that not "No"?
< BlueMatt>
luke-jr: taken separately: I'm ok going along with lots of things that I think are technically not good, if there is real community support for them. 148 falls into that category. Separately, I dont think 148 has or will get sufficient community support
< BlueMatt>
luke-jr: I dunno, your putting folks into buckets idea loses all nuance
< BlueMatt>
luke-jr: you should create a separate category for everyone :)
< luke-jr>
BlueMatt: thoughts on BIP 149, Segwit2x, and COOP? :P
< BlueMatt>
bye andrew :(
< luke-jr>
?
< BlueMatt>
andytoshi left
< aj>
luke-jr: wow, your bip148 branch got complicated
< luke-jr>
aj: it now has bugfixes applicable to softforks in general, not specific to BIP148
< luke-jr>
(and not required for BIP148)
< aj>
luke-jr: yep, i found #10512. sounds like an improvement