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: 02 https://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) 02 https://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) 02 https://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) 02 https://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