< btcdrak> looks like https://travis-ci.org/bitcoin/bitcoin/builds/238932256 needs of two jobs which stall-errored
< gmaxwell> wumpus: https://blog.minio.io/accelerating-sha256-by-100x-in-golang-on-arm-1517225f5ff4 those are some pretty impressive numbers.
< luke-jr> can people check their positions on https://en.bitcoin.it/wiki/Segwit_support and fill in any blanks? thanks
< 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
< spudowiar> Right, petertodd?
< spudowiar> *celebrates*
< bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/098b01dc58ff...400fdd08cc95
< bitcoin-git> bitcoin/master 5f672ca Pavlos Antoniou: net: Denote some CNode functions const
< bitcoin-git> bitcoin/master 400fdd0 Pieter Wuille: Merge #10471: Denote functions CNode::GetRecvVersion() and CNode::GetRefCount() as const...
< bitcoin-git> [bitcoin] sipa closed pull request #10471: Denote functions CNode::GetRecvVersion() and CNode::GetRefCount() as const (master...master) https://github.com/bitcoin/bitcoin/pull/10471
< bitcoin-git> [bitcoin] sipa opened pull request #10526: Force on-the-fly compaction during pertxout upgrade (master...compactrange) https://github.com/bitcoin/bitcoin/pull/10526
< spudowiar> GAHH
< spudowiar> It signed it, it sent it back to Core and Core failed the verification
< spudowiar> On one hand, it's failing the verification
< spudowiar> On the other, it's doing a valid transaction that sendrawtransaction can broadcast
< spudowiar> Oh, FML
< spudowiar> I did IsHardwareWallet && !CallHardwareWallet
< spudowiar> Which means if it's successful, it will carry on and fail :(
< spudowiar> (It will do the else part)
< spudowiar> Yes! Hardware wallet support works!
< spudowiar> sipa: I ended up doing a signrawtransaction-esque API https://github.com/saleemrashid/bitcoin/blob/hardware-wallet/src/wallet/wallet.cpp#L1489-L1527
< spudowiar> But instead of privkeys, it does the hdKeypath
< spudowiar> And it adds a transaction key to each of the prevtxs with the raw transaction
< spudowiar> jonasschnelli, luke-jr, NicolasDorier: ^^
< jonasschnelli> 75 lines?
< 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"
< spudowiar> I shouldn't have to reverse it
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/10512 | Rework same-chain from abusing DoS banning, to explicit checks by luke-jr · Pull Request #10512 · bitcoin/bitcoin · GitHub