1 2014-08-12 01:04:55 <jiffe> sipa: thanks for the tip on computing recid, that's much more faster than looping through verifies
2 2014-08-12 04:56:18 <ben_vulpes> hey sipa, are you around?
3 2014-08-12 05:37:15 <sipa> ben_vulpes: sometimes, why?
4 2014-08-12 05:40:57 <ben_vulpes> was curious if you'd built the watch-only-wallets branch lately.
5 2014-08-12 05:41:00 <ben_vulpes> wallets/addresses.
6 2014-08-12 05:50:48 <sipa> no
7 2014-08-12 05:51:10 <sipa> well, it is merged, so i'm building it all the time probably
8 2014-08-12 05:51:17 <sipa> but not used it
9 2014-08-12 05:53:27 <ben_vulpes> where can i learn some more about using watch-only-wallets?
10 2014-08-12 05:54:07 <ben_vulpes> i'm totally lost on that front
11 2014-08-12 05:56:50 <phantomcircuit> it's a bit self evident
12 2014-08-12 05:58:47 <drei> hey folks
13 2014-08-12 05:59:58 <ben_vulpes> phantomcircuit: color me a moron, then. what do i do? `echo 1MyAddr ~./bitcoin/wallet.dat` ?
14 2014-08-12 06:00:06 <ben_vulpes> phantomcircuit: color me a moron, then. what do i do? `echo 1MyAddr >> ~./bitcoin/wallet.dat` ?
15 2014-08-12 06:00:09 <drei> I was looking into customizing QT background color it I did search via hex code of the color yet to see where to change it :D
16 2014-08-12 06:00:12 <drei> any ideas?
17 2014-08-12 06:00:14 <drei> win qt
18 2014-08-12 06:02:58 <drei> hehehe
19 2014-08-12 06:03:54 <phantomcircuit> ben_vulpes, https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29 importaddress
20 2014-08-12 06:06:27 <drei> :D
21 2014-08-12 06:06:27 <drei> phantomcircuit: have u played with win qt alot?
22 2014-08-12 06:10:37 <ben_vulpes> phantomcircuit: is it just me or is that not even documented?
23 2014-08-12 06:10:46 <phantomcircuit> ben_vulpes, "help"
24 2014-08-12 06:11:14 <ben_vulpes> >.<
25 2014-08-12 06:11:19 <ben_vulpes> ffs.
26 2014-08-12 06:11:26 <ben_vulpes> ACTION dies of embarrasment
27 2014-08-12 06:36:01 <drei> lol
28 2014-08-12 06:41:49 <drei> :D
29 2014-08-12 06:41:49 <drei> so no ideas about QT?
30 2014-08-12 06:41:51 <wumpus> drei: background color of what?
31 2014-08-12 06:42:02 <drei> windows wallet
32 2014-08-12 06:42:15 <drei> I played with it a bit in QT creator :)
33 2014-08-12 06:42:32 <wumpus> I believe you can change global colors and such in QPalette
34 2014-08-12 06:42:39 <drei> yes so I though
35 2014-08-12 06:42:51 <wumpus> drei: http://qt-project.org/forums/viewthread/25802
36 2014-08-12 06:43:45 <wumpus> that shows how to make the fusion theme dark, but making it pink would work the same way
37 2014-08-12 06:43:52 <drei> yes
38 2014-08-12 06:43:54 <drei> reading
39 2014-08-12 06:44:22 <drei> ty
40 2014-08-12 06:45:35 <wumpus> you can also change some global colors (that can't be set through the palette) with qApp->setStyleSheet
41 2014-08-12 06:46:28 <wumpus> these are hacks, the official way to do this would be to create your own theme, but that's not worth it if you're just playing around
42 2014-08-12 06:46:40 <drei> https://github.com/bitcoin/bitcoin/search?q=QPalette&ref=cmdform
43 2014-08-12 06:47:11 <drei> yes I was setting to overwrite palette with stylesheet
44 2014-08-12 06:47:17 <drei> thinking :D
45 2014-08-12 06:52:32 <drei> oki time to sleep a bit
46 2014-08-12 13:09:52 <wumpus> jgarzik: can you reiterate what your actual issues with #4150 are? note that it's NOT a softfork
47 2014-08-12 13:10:52 <wumpus> I hope you're not just trying to be difficult
48 2014-08-12 13:13:04 <jgarzik> wumpus, My issue is process
49 2014-08-12 13:13:44 <wumpus> as I see it, all the issues raised about that pull were fixed
50 2014-08-12 13:14:12 <wumpus> there were only remarks that it could be done differently (doing full resource accounting etc) but that doesn't exclude merging this first, until someone actually implements that
51 2014-08-12 13:15:11 <hearn> i'm not sure requiring >1 signoff makes sense
52 2014-08-12 13:15:32 <jgarzik> Yes, it needs more than one ACK on anything non-trivial. That's the rule.
53 2014-08-12 13:15:39 <wumpus> hearn: well it should be clear that people looked at it
54 2014-08-12 13:15:56 <wumpus> and that's clear, people went over it, made comments, those were addressed, then it's ok with me
55 2014-08-12 13:16:13 <hearn> right. review is important
56 2014-08-12 13:16:13 <jgarzik> wumpus, Upon reorg, do we dump all non-standard transactions?
57 2014-08-12 13:16:16 <wumpus> anyhow feel free to merge it again when you feel happy about it, I'll pull my hands off it
58 2014-08-12 13:16:23 <sipa> jgarzik: "dump" ?
59 2014-08-12 13:16:27 <jgarzik> forget
60 2014-08-12 13:16:41 <sipa> they don't move to our mempool, no
61 2014-08-12 13:16:54 <jgarzik> ok, then same consequence here.
62 2014-08-12 13:17:02 <jgarzik> ok with ACK'ing
63 2014-08-12 13:17:05 <wumpus> but that's already the case, nothing changes there
64 2014-08-12 13:18:15 <wumpus> after a reorg there is no difference to the mempool for 'old' transactions and 'new' transactions
65 2014-08-12 13:18:18 <jgarzik> wumpus, it has 3 ACKs now
66 2014-08-12 13:18:21 <wumpus> they could still be miend, though
67 2014-08-12 13:18:42 <hearn> are these rules written down anywhere?
68 2014-08-12 13:18:46 <jgarzik> after a reorg, all non-standard etc. transactions are forgotten.
69 2014-08-12 13:18:54 <jgarzik> and must be re-mined without relay.
70 2014-08-12 13:19:05 <wumpus> indeed
71 2014-08-12 13:19:42 <wumpus> hearn: there is something in the readme file under development process
72 2014-08-12 13:20:00 <wumpus> but no specific rules, no
73 2014-08-12 13:22:23 <jgarzik> hearn, I will track people down and yell at them if non-trivial things are merged without >1 signoff from "core devs"
74 2014-08-12 13:22:41 <jgarzik> hearn, that's important in case people are wrong-headed, under duress, etc. etc. byzantine etc.
75 2014-08-12 13:22:42 <sipa> i'm fine with people yelling from time to time
76 2014-08-12 13:23:02 <jgarzik> Important for project health and decentralization.
77 2014-08-12 13:23:39 <hearn> ah yes, and the process for becoming a core dev is .... ?
78 2014-08-12 13:23:47 <wumpus> I'm fine with yelling, but I'm not convinced of the reason here, but anyhow I don't feel like dwelling on it either
79 2014-08-12 13:24:41 <wumpus> I'm ok with it if you think I made a judgement error here, and as said feel free to merge the patch again when you think it's properly reviewed
80 2014-08-12 13:25:21 <wumpus> as said, proper review is important
81 2014-08-12 13:25:36 <sipa> hearn: that's not a reasonable argument; the decision to make changes in any open source project is done by the maintainers of that software - and things get forked or reimplemented if that mechanism doesn't work
82 2014-08-12 13:26:09 <sipa> hearn: it's different when it is about consensus changes to the network, where i don't believe bitcoin core devs should have a privileged position in deciding
83 2014-08-12 13:26:47 <wumpus> sure, for consensus changes it is always required to have discussion on the mailing list
84 2014-08-12 13:26:50 <jgarzik> wumpus, my objection was purely process, not content-based
85 2014-08-12 13:27:03 <jgarzik> kinda like pushing a binary with just one gitian sig
86 2014-08-12 13:27:09 <jgarzik> easily remedied
87 2014-08-12 13:27:10 <hearn> i don't think i was making an argument, no? i was asking how this "jeff yells at people" process is supposed to work. because this "process" is news to me.
88 2014-08-12 13:27:20 <hearn> and i really don't think new processes should be made up on the fly like this
89 2014-08-12 13:27:31 <wumpus> in principle anyone can yell at any moment hearn :)
90 2014-08-12 13:27:42 <wumpus> that's not jeff's privileged position
91 2014-08-12 13:27:43 <sipa> hearn: apologies if i misinterpreted
92 2014-08-12 13:28:07 <hearn> right. i mean, requiring multiple signoff for "non trivial" changes with a small group of people seems like design by committee to me.
93 2014-08-12 13:28:15 <hearn> i had some bad experiences with such things in my last job
94 2014-08-12 13:28:17 <wumpus> although if it was a random person I'd not have reverted as soon
95 2014-08-12 13:28:27 <hearn> sure, i understand that. not worried about this particular change.
96 2014-08-12 13:29:32 <wumpus> but it's ok for everyone to speak up if you think something is going wrong
97 2014-08-12 13:32:07 <wumpus> hearn: yes, absolutely me experience too, too much focus on checklists of rules tends to cost a lot of time in itself and distract people from what matters ("I just need to run around and collect signoffs")
98 2014-08-12 13:45:13 <jgarzik> >1 signoffs from "sane people" for "network facing/impacting changes" is not an unreasonable hurdle.
99 2014-08-12 13:45:43 <jgarzik> Given the amount of value at stake, the number of clueful people readily available, and the consequences of getting it wrong.
100 2014-08-12 13:46:31 <jgarzik> As noted, you have to assume an ACK might be wrongheaded, be sponsored by the wrong people or incentives, might be under duress.
101 2014-08-12 13:46:41 <chichov> any way to directly initialize a CKey from a char vector or similar?
102 2014-08-12 13:48:30 <jgarzik> chichov, .Set()
103 2014-08-12 13:48:47 <chichov> well, then I have to first initialize an empty CKey, but alright
104 2014-08-12 13:49:39 <jgarzik> chichov, can certainly add another constructor variant, if that's called for.
105 2014-08-12 13:49:56 <chichov> I don't need it that badly, thank you
106 2014-08-12 13:49:59 <sipa> chichov: i'm sure you can construct 100 million empty CKey's per second
107 2014-08-12 13:50:21 <chichov> sipa: in that case it barely makes any difference then, thanks
108 2014-08-12 15:18:54 <da2ce7> 20 btc: for a good programer who has some spare time and wants to help the open source community: https://bitcointalk.org/index.php?topic=735985
109 2014-08-12 15:30:55 <jrick> fyi, bip0044 specifiec the hd path to be m/44'/cointype'/ where cointype is 0 for mainnet, and 1 for testnet. For our wallet we also want to support simnet, and were thinking of using 2. Obviously this is a non-standard network, but is there any recommended way to "reserve" these types?
110 2014-08-12 15:31:21 <jrick> or we could use something like 115 (s) which is less likely to collide with other's additions
111 2014-08-12 15:31:47 <wumpus> jrick: is simnet an altcoin or something that has to do with bitcoin?
112 2014-08-12 15:32:01 <jrick> it's an alt bitcoin network designed for simulation testing
113 2014-08-12 15:32:09 <jrick> similar to regtest
114 2014-08-12 15:32:45 <wumpus> if it's a public bitcoin-related project, requesting a number is entirely valid
115 2014-08-12 15:33:06 <jrick> I can't link to the specific parameters, but search for SimNetParams here http://godoc.org/github.com/conformal/btcnet
116 2014-08-12 15:33:13 <wumpus> if it's just some internal thing, make up a number
117 2014-08-12 15:33:34 <wumpus> (that's why regtest has no number assigned; everyone's regtest is different, so sharing anumber makes no sense)
118 2014-08-12 15:34:25 <jrick> right, well simnet is similar but isn't just for single node tests
119 2014-08-12 15:34:49 <wumpus> neither is regtest, the tests usually create about 4 nodes
120 2014-08-12 15:34:53 <wumpus> but there is no global network
121 2014-08-12 15:37:34 <jrick> in btcd there's specific checks when running in simnet mode, which don't exist with regtest, to prevent the network from becomming public
122 2014-08-12 15:37:45 <jrick> getaddrs are ignored, for example
123 2014-08-12 15:39:27 <jrick> and there's no automatic node discovery
124 2014-08-12 15:39:41 <jrick> (only connects to the specific nodes you specify)
125 2014-08-12 15:39:54 <sipa> any other differences?
126 2014-08-12 15:40:13 <jrick> different ports but no I think that's it
127 2014-08-12 15:40:36 <sipa> seems like your version of regtest to me, then :)
128 2014-08-12 15:43:39 <wumpus> yes, seems exactly like regtest
129 2014-08-12 15:44:32 <jrick> oh and the difficulty is different
130 2014-08-12 15:44:44 <davec> Yeah, it's like regtest, but slightly different. regtest needs a few special non-standard things for the pull tester to work and uses the same parameters for address, hd extended keys, etc as testnet. Simnet has the same difficulty as regtet, but, as jrick said, it actively stops address propagation...
131 2014-08-12 15:45:08 <sipa> stopping address propagation makes sense for regtest too
132 2014-08-12 15:45:08 <wumpus> so, just make up a number, the outside world won't ever see it anyhow
133 2014-08-12 15:45:15 <davec> has unique addresses, doesn't allow fuzzing that regtest does, etc
134 2014-08-12 15:45:22 <sipa> though all automatic testing tolls already run with it command line flags to prevent it from connecting out
135 2014-08-12 15:45:26 <jrick> wumpus: ok
136 2014-08-12 15:45:34 <sipa> fuzzing?
137 2014-08-12 15:45:58 <jrick> regtest uses the testnet3 encoding magics
138 2014-08-12 15:46:33 <sipa> what do you mean by fuzzing?
139 2014-08-12 15:49:42 <davec> well, regtest has to allow malformed messages without disconnecting
140 2014-08-12 15:50:01 <sipa> oh that, right
141 2014-08-12 15:50:23 <sipa> those should all just individual command line flags imho, rather than network parameters
142 2014-08-12 15:51:25 <davec> it also pushes blocks without them being requested (which I know isn't a problem in bitcoind since it accepts that without complaint)
143 2014-08-12 15:58:45 <davec> but I still contend that processing block and tx data from remote peers that you didn't request via an inv first isn't a good idea in general. I realize the intent with bloom filters is to cut down on the round trip, but bypassing the way the protocol is intended to work is meh
144 2014-08-12 15:59:29 <davec> I could have already requested it from another peer, it could be locally cached already, etc
145 2014-08-12 15:59:46 <sipa> why would you require an inv first, if you *know* nobody else has it?
146 2014-08-12 15:59:56 <sipa> (because you just mined it yourself)
147 2014-08-12 16:00:19 <sipa> you don't gain anything by rejecting early
148 2014-08-12 16:00:31 <sipa> unless, i guess, you process the block header before the entire block is received
149 2014-08-12 16:00:35 <sipa> which is possible in theory
150 2014-08-12 16:01:27 <davec> correct
151 2014-08-12 16:03:42 <hearn> woot: bitcoinj now has a pluggable tx signing framework. along with married hd key chains this is what we need for an initial risk analysed wallet
152 2014-08-12 16:07:39 <michagogo> Looks like bitcoin has hit the 7 day threshold on http://people.canonical.com/~ubuntu-archive/pending-sru.html \o/
153 2014-08-12 16:12:53 <michagogo> I think it should (finally!) get removed tonight