1 2017-06-04 01:46:47	0|btcdrak|looks like https://travis-ci.org/bitcoin/bitcoin/builds/238932256 needs of two jobs which stall-errored
  2 2017-06-04 04:41:34	0|gmaxwell|wumpus: https://blog.minio.io/accelerating-sha256-by-100x-in-golang-on-arm-1517225f5ff4  those are some pretty impressive numbers.
  3 2017-06-04 05:07:37	0|luke-jr|can people check their positions on https://en.bitcoin.it/wiki/Segwit_support and fill in any blanks? thanks
  4 2017-06-04 12:31:25	0|spudowiar|What's your preference for starting a process and piping data?
  5 2017-06-04 12:31:29	0|spudowiar|fork, pipe, dup2?
  6 2017-06-04 12:31:44	0|spudowiar|I mean pipe, fork , dup2
  7 2017-06-04 12:32:16	0|spudowiar|popen won't work because it only supports one direction
  8 2017-06-04 12:53:33	0|spudowiar|Actually, Boost dependency was updated to 1.64.0 which has boost::process
  9 2017-06-04 15:09:03	0|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 :/
 10 2017-06-04 17:18:24	0|BlueMatt|luke-jr: you appear to have seemingly removed nearly all nuance
 11 2017-06-04 17:18:43	0|BlueMatt|luke-jr: you should have a category like "Fine, iff there is massive community consensus that doesnt nearly yet exist"
 12 2017-06-04 17:18:54	0|BlueMatt|then you could probably drop almost everyone into that category
 13 2017-06-04 17:43:26	0|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"?
 14 2017-06-04 17:44:07	0|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"
 15 2017-06-04 17:44:41	0|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"
 16 2017-06-04 17:44:50	0|luke-jr|I was thinking "wanting" as in "I think it is wanting for support"; alternative table-fitting words?
 17 2017-06-04 17:45:10	0|luke-jr|BlueMatt: people against BIP148 on their own are a very small group
 18 2017-06-04 17:45:28	0|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.
 19 2017-06-04 17:47:37	0|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
 20 2017-06-04 17:49:21	0|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"
 21 2017-06-04 17:49:36	0|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.
 22 2017-06-04 17:50:07	0|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
 23 2017-06-04 17:50:07	0|luke-jr|BlueMatt: not doing BIP148 is objectively riskier than BIP148 itself, which has no risk at all given sufficient support.
 24 2017-06-04 17:50:48	0|BlueMatt|luke-jr: that is your opinion. other equally-well-informed minds strongly disagree
 25 2017-06-04 17:53:48	0|BlueMatt|luke-jr: and, key to your point is "given sufficient support", but, then, "given sufficient support" nearly any consensus change becomes incredibly easy
 26 2017-06-04 17:54:11	0|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
 27 2017-06-04 17:55:05	0|luke-jr|it already has it; the only potential risk is people blindly following "Core" who think "Core" is opposed
 28 2017-06-04 17:57:50	0|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.
 29 2017-06-04 17:58:13	0|luke-jr|midnightmagic: ? referring to what
 30 2017-06-04 17:59:10	0|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.
 31 2017-06-04 18:05:29	0|sipa|luke-jr: also don't equate "against merging support for BIP148 in core" with "against BIP148"
 32 2017-06-04 18:07:23	0|sipa|the bar for the first is far higher than personal preferences
 33 2017-06-04 18:07:50	0|luke-jr|sipa: are you of a position that BIP148 should not be merged, but you don't oppose it personally?
 34 2017-06-04 18:07:59	0|luke-jr|(the wiki page is intended to be the latter)
 35 2017-06-04 18:08:24	0|sipa|if there were pervasive support for BIp148, i would encourage it
 36 2017-06-04 18:09:14	0|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
 37 2017-06-04 18:09:40	0|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
 38 2017-06-04 18:10:37	0|sipa|*admittedly
 39 2017-06-04 18:13:23	0|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
 40 2017-06-04 18:13:52	0|luke-jr|aside from BIP148, it would be helpful to get positions on the other proposals on the page
 41 2017-06-04 18:15:23	0|luke-jr|(and feel free to edit descriptions/colours/add new categories/etc if you think it helps improve clarity)
 42 2017-06-04 18:21:38	0|spudowiar|Hmm, either this transaction is totally messed up or EncodeHexTx is totally messing it up
 43 2017-06-04 18:22:08	0|spudowiar|Or python-bitcoinlib is messed up
 44 2017-06-04 18:23:37	0|spudowiar|Right, decoderawtransaction is working fine on this tx
 45 2017-06-04 18:25:21	0|spudowiar|Oh, wait, this is a SegWit tx
 46 2017-06-04 18:25:36	0|spudowiar|I assume that python-bitcoinlib doesn't handle SegWit
 47 2017-06-04 18:25:38	0|spudowiar|Right, petertodd?
 48 2017-06-04 18:29:30	0|spudowiar|*celebrates*
 49 2017-06-04 18:32:31	0|bitcoin-git|13bitcoin/06master 145f672ca 15Pavlos Antoniou: net: Denote some CNode functions const
 50 2017-06-04 18:32:31	0|bitcoin-git|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/098b01dc58ff...400fdd08cc95
 51 2017-06-04 18:32:32	0|bitcoin-git|13bitcoin/06master 14400fdd0 15Pieter Wuille: Merge #10471: Denote functions CNode::GetRecvVersion() and CNode::GetRefCount()  as const...
 52 2017-06-04 18:33:02	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #10471: Denote functions CNode::GetRecvVersion() and CNode::GetRefCount()  as const (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/10471
 53 2017-06-04 18:49:17	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #10526: Force on-the-fly compaction during pertxout upgrade (06master...06compactrange) 02https://github.com/bitcoin/bitcoin/pull/10526
 54 2017-06-04 18:58:17	0|spudowiar|GAHH
 55 2017-06-04 18:58:27	0|spudowiar|It signed it, it sent it back to Core and Core failed the verification
 56 2017-06-04 19:17:39	0|spudowiar|On one hand, it's failing the verification
 57 2017-06-04 19:17:52	0|spudowiar|On the other, it's doing a valid transaction that sendrawtransaction can broadcast
 58 2017-06-04 19:20:03	0|spudowiar|Oh, FML
 59 2017-06-04 19:20:12	0|spudowiar|I did IsHardwareWallet && !CallHardwareWallet
 60 2017-06-04 19:20:21	0|spudowiar|Which means if it's successful, it will carry on and fail :(
 61 2017-06-04 19:20:31	0|spudowiar|(It will do the else part)
 62 2017-06-04 19:21:43	0|spudowiar|Yes! Hardware wallet support works!
 63 2017-06-04 19:26:13	0|spudowiar|sipa: I ended up doing a signrawtransaction-esque API https://github.com/saleemrashid/bitcoin/blob/hardware-wallet/src/wallet/wallet.cpp#L1489-L1527
 64 2017-06-04 19:26:23	0|spudowiar|But instead of privkeys, it does the hdKeypath
 65 2017-06-04 19:26:37	0|spudowiar|And it adds a transaction key to each of the prevtxs with the raw transaction
 66 2017-06-04 19:28:30	0|spudowiar|Here's the plugin: https://github.com/saleemrashid/bitcoin/blob/hardware-wallet/contrib/bitcoin-hww-trezor
 67 2017-06-04 19:28:47	0|spudowiar|jonasschnelli, luke-jr, NicolasDorier: ^^
 68 2017-06-04 19:29:13	0|jonasschnelli|75 lines?
 69 2017-06-04 19:29:48	0|jonasschnelli|Can you make it vendor independent? :)
 70 2017-06-04 19:29:58	0|spudowiar|You need another script for each vendor :)
 71 2017-06-04 19:30:14	0|jonasschnelli|I guess we need a standard
 72 2017-06-04 19:30:19	0|luke-jr|jonasschnelli: the whole point is that the script is the interface
 73 2017-06-04 19:30:34	0|spudowiar|The command is `src/qt/bitcoin-qt -testnet -hardwarewallet=contrib/bitcoin-hww-trezor`
 74 2017-06-04 19:30:53	0|spudowiar|Or bitcoind if that floats your boat :)
 75 2017-06-04 19:31:05	0|jonasschnelli|ah. I see.
 76 2017-06-04 19:31:15	0|jonasschnelli|I though the script is the only thing you need
 77 2017-06-04 19:31:41	0|spudowiar|You have a script for each hardware wallet, and you set -hardwarewallet= to the script
 78 2017-06-04 19:32:09	0|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
 79 2017-06-04 19:32:35	0|sipa|that sounds pretty bad :)
 80 2017-06-04 19:32:41	0|luke-jr|could be worse
 81 2017-06-04 19:32:47	0|luke-jr|but definitely something to fix
 82 2017-06-04 19:32:49	0|spudowiar|luke-jr, always optimistic
 83 2017-06-04 19:33:01	0|spudowiar|There are issues about moving stuff off the UI thread so I didn't bother with it at the moment
 84 2017-06-04 19:33:15	0|spudowiar|When CreateTransaction gets moved off the UI thread, this will fix itself
 85 2017-06-04 19:34:05	0|luke-jr|spudowiar: you mean sign?
 86 2017-06-04 19:34:25	0|luke-jr|IMO we should prompt in GUI for fee/etc before trying to sign
 87 2017-06-04 19:34:26	0|spudowiar|Well, CreateTransaction calls the signature stuff
 88 2017-06-04 19:35:50	0|spudowiar|Whoops, need to add CallHardwareWallet into CWallet::SignTransaction as well
 89 2017-06-04 19:36:03	0|spudowiar|Anyway, one issue is that it's not doing change addresses right ATM
 90 2017-06-04 19:36:14	0|spudowiar|So, it sees them as an extra output
 91 2017-06-04 19:36:30	0|sipa|is that a problem?
 92 2017-06-04 19:36:38	0|spudowiar|Yes, but it's one I can fix :)
 93 2017-06-04 19:36:52	0|spudowiar|Because the hardware wallet isn't meant to show the change addresses
 94 2017-06-04 19:37:02	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #10527: Use parentheses to clarify intended precedence when using bitwise operations (06master...06clarify-precedence) 02https://github.com/bitcoin/bitcoin/pull/10527
 95 2017-06-04 19:37:22	0|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
 96 2017-06-04 19:40:02	0|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"
 97 2017-06-04 19:40:55	0|spudowiar|Also, this doesn't look good https://github.com/saleemrashid/bitcoin/blob/hardware-wallet/contrib/bitcoin-hww-trezor#L54
 98 2017-06-04 19:41:20	0|spudowiar|I shouldn't have to reverse it
 99 2017-06-04 19:42:39	0|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)
100 2017-06-04 19:42:53	0|sipa|as a result, the hex string is in the opposite order from the actual bytes
101 2017-06-04 19:43:07	0|spudowiar|I know, but this isn't a hex string
102 2017-06-04 19:43:13	0|spudowiar|I *think*
103 2017-06-04 19:43:45	0|spudowiar|Yeah, it's not a hex string
104 2017-06-04 19:44:04	0|sipa|hmm
105 2017-06-04 19:44:14	0|sipa|still may be some LE/BE confusion
106 2017-06-04 19:44:39	0|spudowiar|Maybe, I'll have a look at my code again another day, do a bit of refactoring
107 2017-06-04 19:45:00	0|spudowiar|gtg
108 2017-06-04 20:11:19	0|BlueMatt|luke-jr: ehh, I'm more of the "not really ok with the idea, also considers it to have insufficient community support" view
109 2017-06-04 20:11:51	0|luke-jr|BlueMatt: how is that not "No"?
110 2017-06-04 20:12:43	0|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
111 2017-06-04 20:13:13	0|BlueMatt|luke-jr: I dunno, your putting folks into buckets idea loses all nuance
112 2017-06-04 20:13:22	0|BlueMatt|luke-jr: you should create a separate category for everyone :)
113 2017-06-04 20:13:51	0|luke-jr|BlueMatt: thoughts on BIP 149, Segwit2x, and COOP? :P
114 2017-06-04 20:14:10	0|BlueMatt|bye andrew :(
115 2017-06-04 20:17:40	0|luke-jr|?
116 2017-06-04 20:18:20	0|BlueMatt|andytoshi left
117 2017-06-04 22:05:18	0|aj|luke-jr: wow, your bip148 branch got complicated
118 2017-06-04 22:17:25	0|luke-jr|aj: it now has bugfixes applicable to softforks in general, not specific to BIP148
119 2017-06-04 22:17:29	0|luke-jr|(and not required for BIP148)
120 2017-06-04 22:18:26	0|aj|luke-jr: yep, i found #10512. sounds like an improvement
121 2017-06-04 22:18:27	0|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