1 2014-07-24 00:02:28 <Nick____> for example, for dogecoin it looks like this: dogecoin: { address_version: '1e', p2sh_version: '16', p2sh_char: 'A', privkey_compression_flag: '01', privkey_version: '9e', extended_privkey_version: "02fac398", extended_pubkey_version: "02facafd", compressed_wif_chars: %w(Q), uncompressed_wif_chars: %w(6), protocol_version: 70002 },
2 2014-07-24 00:03:07 <jrick> chainparams.{h,cpp}
3 2014-07-24 00:08:35 <Nick____> jrick: thank you!
4 2014-07-24 03:45:04 <Luke-Jr> thoughts on adding a nice fat warning when you try to send to an address you've sent to before?
5 2014-07-24 03:46:38 <gwillen> doesn't seem like it would usually be within the sender's control
6 2014-07-24 03:46:49 <Luke-Jr> eh? of course it is
7 2014-07-24 03:46:55 <Luke-Jr> and that's why it's a warning - in case it isn't.
8 2014-07-24 03:47:48 <Luke-Jr> something like "Warning! You have already sent bitcoins to this address before. Using an address more than once is not guaranteed to work, and may cause them to be lost. Only continue if you are sure the recipient is capable of receiving multiple payments to the same address. Send? Yes/Cancel"
9 2014-07-24 03:57:40 <gmaxwell> Luke-Jr: yea, I suggested something like that previously. (in particular, there have been a number of incidents where someone made a payment twice and the reciever laughed and walked away)
10 2014-07-24 03:57:57 <Luke-Jr> gmaxwell: was it rejected for some reason?
11 2014-07-24 03:58:01 <Luke-Jr> or just never got to writing it?
12 2014-07-24 03:58:17 <gwillen> oh, I understand
13 2014-07-24 03:58:29 <gmaxwell> no, but no one was super excited either. I think wumpus thought it was a bit sneaky. Though just hammering the don't reuse wasn't really my main goal in that proposl.
14 2014-07-24 03:58:33 <gmaxwell> er proposal.
15 2014-07-24 03:58:33 <gwillen> this isn't an "address reuse bad" warning, this is a "your recipient may have given you a one-use address" warning
16 2014-07-24 03:58:40 <gmaxwell> gwillen: yes.
17 2014-07-24 03:58:42 <gwillen> this seems like a pretty useful warning to have.
18 2014-07-24 03:58:51 <gwillen> I've definitely seen people get bit by that.
19 2014-07-24 03:59:05 <gmaxwell> yea, recipent might have given you a one use, or you already made this transaction.
20 2014-07-24 03:59:17 <gwillen> ahhh. Yeah the latter is likely if the amounts match, in particular.
21 2014-07-24 03:59:53 <gmaxwell> the notice should list the datetime txid:vout and amount for all of the prior ones, tooâ perhaps.
22 2014-07-24 04:29:59 <Luke-Jr> etotheipi_: poke
23 2014-07-24 04:30:39 <etotheipi_> Luke-Jr: what's up?
24 2014-07-24 04:31:00 <Luke-Jr> etotheipi_: some user is saying Armory is doing silly things like claiming addresses have balances :<
25 2014-07-24 04:31:57 <etotheipi_> Luke-Jr: I don't know what you mean
26 2014-07-24 04:34:00 <PRab> etotheipi_: There is a big debate about address reuse going on. On the Wallet Properties screen, it has a balance column broken down by address. People claim that the balance encourages address reuse.
27 2014-07-24 04:41:35 <etotheipi_> PRab: it's nothing new, and Armory has done that for forever... yes I agree that address reuse should be minimized, but I'm not sure it's worth removing a feature that helps you understand what's going on in your wallet
28 2014-07-24 04:42:06 <etotheipi_> there are legitimate reason to know which private keys in your wallet protect money
29 2014-07-24 04:44:26 <etotheipi_> for apps that try to make it possible for grandma to use Bitcoin, removing that abstraction may make sense ... for a power tool like Armory mostly used by advanced/power users, that is useful
30 2014-07-24 04:44:31 <gmaxwell> etotheipi_: because all keys in an armory wallet are generated via the homomorpic derrivation, they all protect money if any do.
31 2014-07-24 04:44:55 <gmaxwell> (I suppose imported keys are an exception there)
32 2014-07-24 04:46:00 <etotheipi_> great... but the marginal improvement that users *might* reuse addresses less if I remove a feature that many other people consider useful, is not compelling
33 2014-07-24 04:46:14 <gmaxwell> (I'm not arguing that it shouldn't have the ability to show sums of utxo per address, but I think the argument given for it there was concerning.)
34 2014-07-24 04:46:44 <gmaxwell> (e.g. if people really are treating the private keys of addresses with 0 by them with less care then thats bad)
35 2014-07-24 04:47:19 <etotheipi_> btw, as painful as it is... one of our large clients, working with auditors and compliance officers... have decided that everything is 100% address based
36 2014-07-24 04:47:33 <etotheipi_> they hate the fact that Armory does everything by wallets
37 2014-07-24 04:47:45 <etotheipi_> because they have an *obligation* to control every transaction
38 2014-07-24 04:47:49 <etotheipi_> and report per-address transactions
39 2014-07-24 04:47:59 <etotheipi_> so they can match up buys and sells for tax reporting, etc
40 2014-07-24 04:48:21 <etotheipi_> I told them that that makes Bitcoin basically unusable
41 2014-07-24 04:48:39 <etotheipi_> and they kind of agreed... but said that's how they are currently bound
42 2014-07-24 04:50:21 <etotheipi_> they've been requesting custom export features to match their reporting requirements (basically per-address histories and balances)
43 2014-07-24 04:50:41 <etotheipi_> (correlated with historical prices)
44 2014-07-24 04:56:18 <wumpus> gmaxwell: fyi that was never rejected, it's still open https://github.com/bitcoin/bitcoin/issues/3266
45 2014-07-24 04:56:20 <Luke-Jr> etotheipi_: that smells like someone who doesn't understand bitcoin explained it to their officers
46 2014-07-24 04:56:47 <Luke-Jr> etotheipi_: which can be dangerous for others :/
47 2014-07-24 04:57:23 <gmaxwell> tracking _transactions_ and doing the historical price stuff sounds reasonable.
48 2014-07-24 04:57:25 <wumpus> gmaxwell: I thought it's a bit sneaky but also a good idea, there was another guy that completely crazy
49 2014-07-24 04:57:31 <wumpus> +went
50 2014-07-24 04:58:28 <gmaxwell> since then I've seen more instances of people making errors that would be potentially helped by this: e.g. failing to copy and sending to the last address you sent to
51 2014-07-24 04:58:48 <gmaxwell> obviously in the long run the manual address handling should become less common.
52 2014-07-24 04:59:49 <etotheipi_> yeah, and unfortunately for them, coin-control and custom change behavior is required for every transaction
53 2014-07-24 05:00:41 <Luke-Jr> someone should set up a certification process for wallet sw that includes things like "doesn't confuse users with 'address balance' nonsense" <.<
54 2014-07-24 05:01:17 <wumpus> gmaxwell: at the time there was no way to store data per-output, since then I've added the *DestData stuff to wallet so a 'when was the last send, and what amount was used' can be easily added
55 2014-07-24 05:01:18 <gmaxwell> Luke-Jr: I don't think, e.g. coin-control is bad, it just shouldn't be a primary user interface. Do you disagree?
56 2014-07-24 05:01:35 <Luke-Jr> gmaxwell: coin control isn't bad. but displaying an entirely meaningless number as an "address balance" certainly is.
57 2014-07-24 05:01:59 <Luke-Jr> wumpus: is there no way to easily tell if we've ever sent to an address before?
58 2014-07-24 05:02:02 <wumpus> coin control is great, especially as an educational interface
59 2014-07-24 05:02:13 <gmaxwell> Luke-Jr: yea, so sometimes the kind of complaint you had with armory could be resolved by adding more functionality vs removing some.
60 2014-07-24 05:02:19 <Luke-Jr> ACTION notes he rebased coin control for Core for a while :p
61 2014-07-24 05:02:26 <etotheipi_> I disagree: there is a tangible meaning to the "balance" of an address, even if we'd prefer users not to inspect their wallet to that level
62 2014-07-24 05:02:29 <wumpus> Luke-Jr: apart from scanning all transactions? no
63 2014-07-24 05:02:34 <Luke-Jr> etotheipi_: there isn't, though.
64 2014-07-24 05:02:44 <Luke-Jr> etotheipi_: the spending of the TXO is not related to the address in any way
65 2014-07-24 05:02:50 <wumpus> Luke-Jr: we don't keep a per-output index, it would be kind of a silly thing
66 2014-07-24 05:03:06 <gmaxwell> Well it has a well defined meaning, it's just not one which has much significance to the system itselfâ and this is often a point of confusion.
67 2014-07-24 05:03:07 <Luke-Jr> wumpus: I mean just for the wallet
68 2014-07-24 05:03:08 <etotheipi_> you may disagree with the way people use the feature, but it's still meaningful in a literal sense
69 2014-07-24 05:03:23 <wumpus> Luke-Jr: no, we don't have one just for the wallet either
70 2014-07-24 05:03:50 <sipa> we already iterate through all wallet transactions for pretty much everything...
71 2014-07-24 05:03:58 <gmaxwell> I was about to say.
72 2014-07-24 05:04:04 <wumpus> sigh, okay
73 2014-07-24 05:04:32 <sipa> (not saying we should therefore necessarily just continue that practice...)
74 2014-07-24 05:04:37 <wumpus> I still think storing data per destination makes more sense, but heh
75 2014-07-24 05:04:46 <sipa> yeah
76 2014-07-24 05:04:48 <gmaxwell> As an ontopic aside, someone in #bitcoin today was complaining that their bitcoind was suddenly using 100% cpu. Their wallet was also 30MBytes. Some people in the channel were making the (AFAICT) weakly informed speculation that their cpu use might have been due to their wallet size.
77 2014-07-24 05:05:03 <Luke-Jr> etotheipi_: please tell me, how is it meaningful to display.. the sum of bitcoins received using a given address, minus bitcoins spent in completely unrelated transactions?
78 2014-07-24 05:05:29 <sipa> with coin-control, those transactions are not necessarily completely unrelated
79 2014-07-24 05:05:30 <gmaxwell> Luke-Jr: it's not x-y, its the sum of unspent utxo that are spendable by the cooresponding private key.
80 2014-07-24 05:05:32 <Luke-Jr> sipa: wumpus: maybe we ought to add wallet indexes to avoid the iteration in common cases?
81 2014-07-24 05:05:42 <sipa> Luke-Jr: pull requests welcome
82 2014-07-24 05:05:49 <Luke-Jr> heh
83 2014-07-24 05:05:49 <wumpus> Luke-Jr: I just gave asolution in my first messgae about it to gmaxwell
84 2014-07-24 05:06:08 <wumpus> Luke-Jr: <wumpus> gmaxwell: at the time there was no way to store data per-output, since then I've added the *DestData stuff to wallet so a 'when was the last send, and what amount was used' can be easily added
85 2014-07-24 05:06:42 <Luke-Jr> sipa: you're the only one daring enough to modify wallet code thought! *ducks*
86 2014-07-24 05:06:47 <Luke-Jr> though*
87 2014-07-24 05:07:17 <sipa> Luke-Jr: i'd like to focus more on core stuff, and on getting rid of the wallet than extending it further...
88 2014-07-24 05:07:25 <wumpus> sipa: me too
89 2014-07-24 05:07:37 <gmaxwell> Luke-Jr: though I suppose if you want to be pedantic (and since you are luke, you do) all the the private keys for a single chain are damn near equivalentâ so maybe my argument above falls down.
90 2014-07-24 05:07:39 <wumpus> gmaxwell: hah, *another* reason why the wallet and node should be separate
91 2014-07-24 05:07:50 <wumpus> gmaxwell: at least then you can see what uses the CPU! :p
92 2014-07-24 05:08:14 <gmaxwell> well you don't have to convince me that they should be seperate processes.
93 2014-07-24 05:08:50 <wumpus> gmaxwell: I know, but that seems the only sane solution to that, apart from informing people that a full node can use lots of CPU during initial sync
94 2014-07-24 05:10:11 <gmaxwell> "attach gdb"
95 2014-07-24 05:10:14 <gmaxwell> :P
96 2014-07-24 05:10:20 <wumpus> hehe
97 2014-07-24 05:10:30 <wumpus> try that as non-root on a modern system :(
98 2014-07-24 05:10:58 <gmaxwell> hm? are systems breaking gdb -p now?! works fine on fedora.
99 2014-07-24 05:11:06 <wumpus> ubuntu blocks attaching to other processes by default
100 2014-07-24 05:11:18 <Luke-Jr> really?
101 2014-07-24 05:11:18 <wumpus> I know why, but it can be annoying, and needs a kernel setting to change
102 2014-07-24 05:11:22 <gmaxwell> I .. can see some advantages, but .. ouch.
103 2014-07-24 05:11:24 <Luke-Jr> weird
104 2014-07-24 05:11:39 <Luke-Jr> I knew Mac required root to run gdb (at all), but I didn't know Ubuntu was doing it too
105 2014-07-24 05:11:52 <sipa> wumpus: i must have changed that setting a long time ago then, because it just works here
106 2014-07-24 05:12:25 <gmaxwell> the annoying thing about a lot of this stuff is that it habituates users to running things with root permissions...
107 2014-07-24 05:12:39 <wumpus> I wonder what new vulnerabilities they introduce by having to run gdb as root, I'm sure it has a few holes too, there used to be one in the DWARF evaluation a long time back for example
108 2014-07-24 05:12:47 <poutine> you don't have to run gdb as root
109 2014-07-24 05:12:52 <poutine> http://stackoverflow.com/questions/9132826/stop-developer-tools-access-needs-to-take-control-of-another-process-for-debugg
110 2014-07-24 05:13:01 <gmaxwell> would be better if they just got a popup: "Is it okay to attach a debugger to <X>? If unsure, say no."
111 2014-07-24 05:13:59 <gmaxwell> (and then we find out apple has patented askingâ¦)
112 2014-07-24 05:14:32 <wumpus> sipa: you probably change /proc/sys/kernel/yama/ptrace_scope then
113 2014-07-24 05:14:35 <Luke-Jr> wtf https://blockchain.info/en/address/3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy
114 2014-07-24 05:14:43 <gmaxwell> wumpus: yea, gdb is not something I'd normally want to run as root.
115 2014-07-24 05:15:00 <Luke-Jr> is that right?
116 2014-07-24 05:15:17 <gmaxwell> Luke-Jr: yes, you didn't see the #bitcoin-wizards discussion the other day? bc.i has been totally busted wrt that for a long time.
117 2014-07-24 05:15:18 <Luke-Jr> no, it isn't..
118 2014-07-24 05:15:23 <wumpus> gmaxwell: it would be possible to run a gdb *host* as root and connect to it as if it is remote, but thinking about it that would be even worse as it has no authentication :-)
119 2014-07-24 05:15:24 <Luke-Jr> gmaxwell: ah, no
120 2014-07-24 05:15:33 <Luke-Jr> gmaxwell: is it that address specifically?
121 2014-07-24 05:15:48 <wumpus> gmaxwell: so you'd effectively have a process that allows hijacking any other, hehe
122 2014-07-24 05:15:58 <gmaxwell> Luke-Jr: basically it was previously treating <p2sh:hash160_x> identically to <p2pkh:hash160_x>
123 2014-07-24 05:16:13 <Luke-Jr> gmaxwell: O.o
124 2014-07-24 05:16:31 <Luke-Jr> oh, so that's 68 BTC sent to an unspendable p2pkh
125 2014-07-24 05:16:36 <gmaxwell> Luke-Jr: wallets too, though it's fixed now.
126 2014-07-24 05:16:37 <Luke-Jr> MtGox maybe >_<
127 2014-07-24 05:16:44 <Luke-Jr> gmaxwell: well, that page isn't fixed ..
128 2014-07-24 05:16:54 <gmaxwell> yea, its supposted to be fixed going forward.
129 2014-07-24 05:17:02 <Luke-Jr> (that address is an anyone-can-spend null script P2SH fwiw)
130 2014-07-24 05:17:11 <gmaxwell> Luke-Jr: it's the ripemd160('') but there are another 6 btc or so sent to other unspendable p2pkh.
131 2014-07-24 05:18:14 <gmaxwell> based on an assumption that if a p2pkh utxo exists whos hash160 was sent to as a p2sh the p2pkh is unspendable.
132 2014-07-24 05:18:31 <gmaxwell> Apparently coinpunk 'supported' p2sh by just ignoring the version byte. :(
133 2014-07-24 05:18:46 <wumpus> but yeah it could be some capability dealt out through systemd/policykit after asking, that'd be better, although the thing with popups is that clueless users will always click 'yes' on them
134 2014-07-24 05:18:50 <gmaxwell> and this combined well with users checking bc.i to see their 'balance'. :(
135 2014-07-24 05:19:07 <Luke-Jr> ACTION facepalms
136 2014-07-24 05:19:42 <gmaxwell> wumpus: I dunno if anything in policykit does it now but there should be a "must type yes" dialog... though ultimately those same users will sudo programname or the like in any case.
137 2014-07-24 05:22:05 <wumpus> gmaxwell: or restrict 'dangerous' applications such as the webbrowser from ptracing, like webbrowsers, but not gdb if manually executed from a terminal
138 2014-07-24 05:22:33 <wumpus> apparmor can probably do that
139 2014-07-24 05:23:02 <gmaxwell> I think the selinux policy in fedora already does that, in fact. (since fedora 17 or so)
140 2014-07-24 05:25:54 <gmaxwell> it does, though it looks like the browser isn't confined with it, lots of processes are, however.
141 2014-07-24 05:28:02 <wumpus> application isolation is one thing that's done better on android
142 2014-07-24 05:28:23 <phantomcircuit> wumpus, bleh but the permissions system is useless
143 2014-07-24 05:28:35 <wumpus> and with that it's still possible to debug (through only from the host, not from the device itself)
144 2014-07-24 05:29:37 <wumpus> phantomcircuit: well it suffers from permission inflation as you have to agree with all permissions when you download the application or upgrade it, if not you may not use it, it should be more granular and possible to deny/allow specific permissions later
145 2014-07-24 05:30:10 <phantomcircuit> wumpus, they should provide for all the api calls that have permissions to return false data
146 2014-07-24 05:30:22 <phantomcircuit> would allow for 100% compatibility
147 2014-07-24 05:32:17 <gmaxwell> yea, false data would also prevent things from asking for more permissions than they really need and holding you hostage.
148 2014-07-24 05:32:17 <wumpus> phantomcircuit: yes
149 2014-07-24 05:34:49 <wumpus> but anyhow, on an OS with mostly open source software like ubuntu that's not as much of a problem... not many open source authors would hold you hostage to get more permissions to allow advertising companies to spy on you
150 2014-07-24 05:35:01 <wumpus> and if so it'd just be removed :P
151 2014-07-24 05:36:34 <phantomcircuit> wumpus, something something amazon search bar
152 2014-07-24 05:36:53 <gmaxwell> https://github.com/bitcoin/bitcoin/pull/4581 0_o
153 2014-07-24 05:36:56 <phantomcircuit> gmaxwell, nom nom chips running with all cores at full blast
154 2014-07-24 05:37:07 <phantomcircuit> a bit toasty though
155 2014-07-24 05:37:42 <phantomcircuit> gmaxwell, wait
156 2014-07-24 05:37:47 <phantomcircuit> that is
157 2014-07-24 05:37:48 <phantomcircuit> wat
158 2014-07-24 05:37:55 <wumpus> rebroad does it again
159 2014-07-24 05:38:24 <wumpus> 'a lot of CPU is wasted dealing with superfluous getblocks' ok man, show me the profiling results
160 2014-07-24 05:38:51 <gmaxwell> now we get to spend N hours trying to figure out if he's found an actual bug, e.g. making getblock requests we don't really need to make, which he's fixing in the worst possible wayâ ignoring requests from peers. :P
161 2014-07-24 05:39:32 <phantomcircuit> there's basically no way to know...
162 2014-07-24 05:39:46 <wumpus> gmaxwell: right
163 2014-07-24 05:42:54 <wumpus> so how does the linux kernel developer team handle cases like this?
164 2014-07-24 05:43:22 <phantomcircuit> wumpus, lol rudely
165 2014-07-24 06:05:45 <wumpus> ACTION is very close to banning rebroad from the github project
166 2014-07-24 06:07:01 <Luke-Jr> maybe warn him then
167 2014-07-24 06:07:33 <wumpus> yes
168 2014-07-24 06:14:04 <phantomcircuit> gmaxwell, nom nom voltage trim
169 2014-07-24 06:14:08 <phantomcircuit> NOM
170 2014-07-24 06:24:46 <Diablo-D3> [01:38:57] <gmaxwell> now we get to spend N hours trying to figure out if he's found an actual bug, e.g. making getblock requests we don't really need to make, which he's fixing in the worst possible wayâ ignoring requests from peers. :P
171 2014-07-24 06:24:53 <Diablo-D3> thats how I'd debug it
172 2014-07-24 06:25:00 <Diablo-D3> no-op the handler, see if cpu time goes down
173 2014-07-24 06:29:03 <phantomcircuit> Diablo-D3, just count identical requests...
174 2014-07-24 06:29:18 <Diablo-D3> phantomcircuit: not even worth it
175 2014-07-24 06:29:23 <Diablo-D3> lets find out if its even an issue to begin with
176 2014-07-24 06:29:31 <Diablo-D3> if cpu usage doesnt go down in any reasonable amount
177 2014-07-24 06:29:34 <Diablo-D3> its not an issue
178 2014-07-24 06:29:39 <phantomcircuit> im thinking no
179 2014-07-24 06:29:47 <phantomcircuit> since i've profiled like
180 2014-07-24 06:29:50 <phantomcircuit> all the things
181 2014-07-24 06:30:03 <phantomcircuit> maybe it matters for an otherwise entirely idle node
182 2014-07-24 06:30:08 <phantomcircuit> but srsly who cares
183 2014-07-24 06:30:58 <wumpus> better to look for more serious DoSes
184 2014-07-24 06:32:10 <Diablo-D3> I mean, maybe if we had bitcoind running on an arm
185 2014-07-24 06:32:13 <Diablo-D3> and not even a new arm
186 2014-07-24 06:32:16 <Diablo-D3> it'd metter
187 2014-07-24 06:32:21 <wumpus> I have it running on ARM - works fine
188 2014-07-24 06:32:30 <Diablo-D3> wumpus: well
189 2014-07-24 06:32:31 <Diablo-D3> there
190 2014-07-24 06:32:32 <Belxjander> wumpus: you have an ARM based miner?
191 2014-07-24 06:32:37 <wumpus> Belxjander: no, a node.
192 2014-07-24 06:32:38 <Diablo-D3> problem solved
193 2014-07-24 06:32:42 <Belxjander> wumpus: or an ARM based BitCoinD node?
194 2014-07-24 06:32:49 <Diablo-D3> maybe we need like
195 2014-07-24 06:32:50 <Belxjander> wumpus: RPi for that?
196 2014-07-24 06:32:52 <Diablo-D3> a wrt54g
197 2014-07-24 06:33:03 <Diablo-D3> some balls slow mips running at 2xx mph
198 2014-07-24 06:33:05 <Diablo-D3> er mhz
199 2014-07-24 06:33:08 <Diablo-D3> heh mph
200 2014-07-24 06:33:26 <Diablo-D3> Ive never made that typo and I hope I make it more often
201 2014-07-24 06:33:35 <wumpus> Belxjander: a cubox and cubox-i
202 2014-07-24 06:34:00 <Belxjander> I have a PowerPC running at 667MHz on my desk
203 2014-07-24 06:34:06 <Diablo-D3> Belxjander: too powerful
204 2014-07-24 06:34:28 <Diablo-D3> thats like a 1.2ghz p3
205 2014-07-24 06:34:30 <wumpus> I have them for video driver related development, but the boxes are great for running nodes, though ofc they need an external storage for the block chain (I simply use large USB sticks)
206 2014-07-24 06:34:44 <Diablo-D3> which is like as fast as a ~800mhz new arm
207 2014-07-24 06:35:07 <Diablo-D3> wumpus: man, when tiny arm dev boards start shipping with usb3
208 2014-07-24 06:35:08 <Diablo-D3> <3
209 2014-07-24 06:35:27 <phantomcircuit> wumpus, arm is le, which is easy
210 2014-07-24 06:35:30 <phantomcircuit> try with mips
211 2014-07-24 06:35:33 <phantomcircuit> then cry
212 2014-07-24 06:35:39 <Diablo-D3> phantomcircuit: notice where I said
213 2014-07-24 06:35:41 <Diablo-D3> 200mhz mips
214 2014-07-24 06:36:01 <Belxjander> so the bitcoind node codebase has had endianness issues clarified?
215 2014-07-24 06:36:18 <wumpus> Belxjander: no.
216 2014-07-24 06:36:19 <phantomcircuit> Belxjander, modern arm is little endian
217 2014-07-24 06:36:23 <phantomcircuit> no correction needed
218 2014-07-24 06:36:32 <phantomcircuit> do NOT RUN BITCOIND ON BIG ENDIAN SYSTEMS
219 2014-07-24 06:36:33 <Diablo-D3> yeah I think theres still long standing big endian issues
220 2014-07-24 06:36:33 <wumpus> modern MIPS is little-endian too
221 2014-07-24 06:36:49 <Luke-Jr> wumpus: what? really? :/
222 2014-07-24 06:36:49 <phantomcircuit> wumpus, depends on how you define modern
223 2014-07-24 06:36:58 <Luke-Jr> MIPS is certainly LE-capable, but AFAIK everything runs it in BE mode
224 2014-07-24 06:37:01 <phantomcircuit> commonly available and cheap are all big endian
225 2014-07-24 06:37:16 <Diablo-D3> mips-le is basically dead
226 2014-07-24 06:37:22 <Diablo-D3> no major linux distro supports it anymore
227 2014-07-24 06:37:26 <phantomcircuit> Luke-Jr, if you try to switch the ones that are available to LE all the drivers crash like instantly
228 2014-07-24 06:37:28 <Diablo-D3> not enough mips-le machines ever shipped
229 2014-07-24 06:37:42 <phantomcircuit> it's kind of hilarious actually
230 2014-07-24 06:37:45 <Diablo-D3> and a lot of code that has mips paths just automatically assumes its be
231 2014-07-24 06:38:05 <Luke-Jr> ACTION needs a MIPS system with PCI-e so he can test PCI-e code on BE <.<
232 2014-07-24 06:38:15 <Diablo-D3> Luke-Jr: do not want
233 2014-07-24 06:38:16 <wumpus> I'm pretty sure my gcw zero (base on Ingenic JZ4770 MIPS processor) is little endian
234 2014-07-24 06:38:28 <Luke-Jr> Diablo-D3: ?
235 2014-07-24 06:38:43 <Diablo-D3> Luke-Jr: pci-e has a higher clock than some mips systems
236 2014-07-24 06:38:48 <Belxjander> wumpus: it may bootstrap from LE to BE as part of the firmware setup
237 2014-07-24 06:39:02 <Luke-Jr> Diablo-D3: personally, I'd prefer replacing my desktop machine with MIPS if I could get one powerful enough :P
238 2014-07-24 06:39:13 <wumpus> I'm pretty sure all Ingenic XBurst processors only support LE
239 2014-07-24 06:39:24 <wumpus> BE is dead, face it
240 2014-07-24 06:39:33 <Luke-Jr> nooooooooo
241 2014-07-24 06:39:54 <Diablo-D3> Luke-Jr: they used to make huge motherfucker mips machines
242 2014-07-24 06:40:02 <Diablo-D3> sadly, my nexus 5 is more powerful
243 2014-07-24 06:40:04 <Luke-Jr> wumpus: LM32 is BE :p
244 2014-07-24 06:40:17 <Diablo-D3> wumpus: be isnt dead if you're on mips
245 2014-07-24 06:40:18 <Belxjander> wumpus: well PPC starts with BE as the default bootstrap option with LE as a runtime switch option
246 2014-07-24 06:40:26 <Diablo-D3> Belxjander: not quite
247 2014-07-24 06:40:33 <Luke-Jr> PPC is more dead than MIPS..
248 2014-07-24 06:40:40 <Diablo-D3> ppc supporting hardware requires le support
249 2014-07-24 06:40:46 <Diablo-D3> you'll never find this in common ppc machines
250 2014-07-24 06:40:54 <Diablo-D3> like, a mac will never be le.
251 2014-07-24 06:41:01 <Belxjander> Diablo-D3: and what do you define as "common" for a ppc system?
252 2014-07-24 06:41:05 <Diablo-D3> macs.
253 2014-07-24 06:41:09 <Diablo-D3> game consoles.
254 2014-07-24 06:41:10 <Diablo-D3> cars.
255 2014-07-24 06:41:12 <Luke-Jr> Diablo-D3: I think PPC can do both BE and LE in the same OS
256 2014-07-24 06:41:17 <Diablo-D3> tvs, bluray players, other set top boxes.
257 2014-07-24 06:41:20 <Luke-Jr> eg, kernel BE but programX LE
258 2014-07-24 06:41:22 <Belxjander> Luke-Jr: yes it does
259 2014-07-24 06:41:23 <Diablo-D3> Luke-Jr: in theory, but its never been tried.
260 2014-07-24 06:41:42 <Diablo-D3> well, not successfully used in real shipping code tried
261 2014-07-24 06:41:44 <Belxjander> Diablo-D3: I'm actively working on something akin to that at the moment
262 2014-07-24 06:41:54 <wumpus> yes I was talking about the mips processors that are sometimes used in cheaper tablets and phones, not the old dinosaur MIPS
263 2014-07-24 06:41:58 <Belxjander> trying to get some LE based processing done within a BE host
264 2014-07-24 06:42:03 <Luke-Jr> wumpus: every MIPS I've seen is BE
265 2014-07-24 06:42:06 <Diablo-D3> wumpus: those mipses suck too
266 2014-07-24 06:42:09 <Luke-Jr> wumpus: like all routers..
267 2014-07-24 06:42:43 <wumpus> Diablo-D3: I know, I developed for one, especially memory bandwidth is horrible
268 2014-07-24 06:42:59 <Belxjander> Luke-Jr: not all routers...Ive run across some routers which were a series of models and they didn't all use the same processor family
269 2014-07-24 06:43:06 <Diablo-D3> wumpus: like, they could take a mips64, scale it up to huge-scale
270 2014-07-24 06:43:09 <Diablo-D3> and ship it
271 2014-07-24 06:43:11 <Diablo-D3> and they never do
272 2014-07-24 06:43:22 <Diablo-D3> mips on 28nm or smaller, drool
273 2014-07-24 06:43:59 <wumpus> Diablo-D3: but they're cheap, so cheap, so vendors love them
274 2014-07-24 06:44:12 <Diablo-D3> yes, but arms are cheap too
275 2014-07-24 06:44:25 <wumpus> Diablo-D3: combined with el cheapo slow ram, and then they still expect 3D performance :P
276 2014-07-24 06:44:35 <Diablo-D3> yeah thats just idiotic
277 2014-07-24 06:44:56 <phantomcircuit> Luke-Jr, ps 1 hash/clock/core
278 2014-07-24 06:44:57 <phantomcircuit> nom
279 2014-07-24 06:45:11 <Luke-Jr> wumpus: Avalon2/3 use both MIPS and LM32 ;p
280 2014-07-24 06:45:29 <Diablo-D3> wumpus: seriously like what happened to mips64.
281 2014-07-24 06:46:22 <phantomcircuit> Diablo-D3, they wouldn't be cheap at 28nm
282 2014-07-24 06:46:28 <phantomcircuit> they're be like $50/chip
283 2014-07-24 06:46:44 <Diablo-D3> phantomcircuit: Im chasing after shit like high end cell phones here
284 2014-07-24 06:46:45 <wumpus> Luke-Jr: ok :p and those are still BE?
285 2014-07-24 06:46:48 <Luke-Jr> phantomcircuit: if they can replace my Intel processor, I'll do it
286 2014-07-24 06:46:59 <Luke-Jr> wumpus: LM32 is *only* BE. pretty sure the MIPS runs in BE too
287 2014-07-24 06:47:09 <Diablo-D3> phantomcircuit: like, a sufficiently large mips or arm could actually make arm and intel shit their pants
288 2014-07-24 06:48:01 <phantomcircuit> Diablo-D3, a little tiny 28nm chip is like $25 at cost
289 2014-07-24 06:48:06 <phantomcircuit> double the price for NRE
290 2014-07-24 06:48:40 <phantomcircuit> Diablo-D3, intel for example is currently waging a materials war
291 2014-07-24 06:48:51 <Diablo-D3> I mean like, image an 8 core aarch64 with 2x ALUs and huge L2 and L3 caches
292 2014-07-24 06:48:54 <phantomcircuit> all their chips are pushing the limits of the process nodes
293 2014-07-24 06:49:10 <phantomcircuit> Diablo-D3, shit would be super expensive actually
294 2014-07-24 06:49:19 <phantomcircuit> unless you ordered like
295 2014-07-24 06:49:22 <phantomcircuit> TONS of them
296 2014-07-24 06:49:24 <Diablo-D3> it'd be cheaper than an i7-477x.
297 2014-07-24 06:49:27 <Diablo-D3> and smaller.
298 2014-07-24 06:49:29 <Diablo-D3> and lower power.
299 2014-07-24 06:49:35 <phantomcircuit> maybe
300 2014-07-24 06:49:37 <phantomcircuit> maybe not
301 2014-07-24 06:49:54 <wumpus> Luke-Jr: me too. I'd love to go all-ARM. But I need a fast machine for compiling, so that's probably still some time away
302 2014-07-24 06:50:06 <Diablo-D3> and I could deploy billions of them in a datacenter <3
303 2014-07-24 06:50:15 <phantomcircuit> lol
304 2014-07-24 06:50:23 <Luke-Jr> wumpus: I don't like ARM. It's the most proprietary architecture.
305 2014-07-24 06:51:24 <wumpus> although using distributed make and a cluster of boxes would be fun too, compile each source file on a different machine :-)
306 2014-07-24 06:51:42 <phantomcircuit> wumpus, suggestion: dont do dat
307 2014-07-24 06:52:15 <Luke-Jr> wumpus: distcc is ugly code
308 2014-07-24 06:52:15 <phantomcircuit> unless the systems are 100% identical to the system you're building for it will break
309 2014-07-24 06:52:24 <wumpus> phantomcircuit: I know, too much i/o overhead, they had something like that at my last employer (lots of build servers)
310 2014-07-24 06:52:26 <Luke-Jr> phantomcircuit: nah, you just preprocess on the main one
311 2014-07-24 06:52:34 <wumpus> phantomcircuit: everything was always hanging
312 2014-07-24 06:52:39 <phantomcircuit> Luke-Jr, still doesn't work right with inline asm
313 2014-07-24 06:52:48 <Luke-Jr> phantomcircuit: why not?
314 2014-07-24 06:52:50 <wumpus> phantomcircuit: cross-compilers are easy
315 2014-07-24 06:53:10 <phantomcircuit> lol sure
316 2014-07-24 06:53:17 <phantomcircuit> the cross compiler itself is easy
317 2014-07-24 06:53:23 <Luke-Jr> phantomcircuit: this is something Gentoo at least had working years ago
318 2014-07-24 06:53:30 <phantomcircuit> now get all the library versions to match correctly with all the ABIs matching
319 2014-07-24 06:53:32 <Luke-Jr> the code sucks, but it does work
320 2014-07-24 06:53:33 <wumpus> although what we did there was build for some obscure PPC architecture on another obscure PPC architecture, but it worked!
321 2014-07-24 06:53:43 <Luke-Jr> phantomcircuit: linking isn't distributed, just compiling
322 2014-07-24 06:53:50 <wumpus> phantomcircuit: well all the libraries were just in some 'sysroot' path, no problem
323 2014-07-24 06:54:09 <phantomcircuit> wumpus, keeping those correct is difficult in itself
324 2014-07-24 06:54:27 <phantomcircuit> Luke-Jr, yeah but it's still going to need specific symbols
325 2014-07-24 06:54:36 <phantomcircuit> which often change between lib versions
326 2014-07-24 06:54:50 <phantomcircuit> probably 90% of my gentoo build failures were distcc related
327 2014-07-24 06:54:54 <Luke-Jr> â¦
328 2014-07-24 06:54:59 <Luke-Jr> it always just worked for me
329 2014-07-24 06:55:21 <Luke-Jr> I even had my N810 using distcc to get my desktop PC cross-compiling for it
330 2014-07-24 06:55:23 <phantomcircuit> Luke-Jr, shrug
331 2014-07-24 06:55:27 <Luke-Jr> (yes, my N810 runs Gentoo.)
332 2014-07-24 06:55:41 <phantomcircuit> neat
333 2014-07-24 06:55:51 <phantomcircuit> Luke-Jr, my bitcoin miner runs busybox
334 2014-07-24 06:55:53 <phantomcircuit> hehe
335 2014-07-24 06:56:07 <wumpus> every small linux embedded device runs busybox
336 2014-07-24 06:56:10 <Luke-Jr> otoh, *linking* qtwebkit on 128 MB RAM is.. not fun
337 2014-07-24 06:56:28 <phantomcircuit> wumpus, you'd be surprised
338 2014-07-24 06:56:29 <Luke-Jr> using small embedded devices for mining is nasty :/
339 2014-07-24 06:56:36 <phantomcircuit> most miners run a FULL debian environment
340 2014-07-24 06:56:53 <phantomcircuit> Luke-Jr, which is why i wrote my own client
341 2014-07-24 06:57:00 <phantomcircuit> 10usec max per main loop
342 2014-07-24 06:57:02 <phantomcircuit> guaranteed
343 2014-07-24 06:57:04 <Belxjander> phantomcircuit: I'm trying to work out essentials for a minimal stripped down Linux install here
344 2014-07-24 06:57:17 <Luke-Jr> phantomcircuit: no matter what you do, you won't be able to produce headers fast enough for 1 MB blocks with 300 kB generation txns
345 2014-07-24 06:57:22 <wumpus> although 'embedded' can also mean high-performance servers in industrial machines, but for consumer hardware it's true
346 2014-07-24 06:57:44 <phantomcircuit> Luke-Jr, i can go from stratum job to work in <6usec
347 2014-07-24 06:57:55 <Luke-Jr> phantomcircuit: not for full blocks as I just described.
348 2014-07-24 06:58:06 <phantomcircuit> Luke-Jr, it's ~2usec/hash
349 2014-07-24 06:58:13 <Luke-Jr> phantomcircuit: not for 300 kB hash
350 2014-07-24 06:58:24 <phantomcircuit> oh
351 2014-07-24 06:58:25 <phantomcircuit> yeah
352 2014-07-24 06:58:27 <phantomcircuit> i dont do that
353 2014-07-24 06:59:01 <phantomcircuit> indeed a coinbase that long will trigger an abort()
354 2014-07-24 06:59:26 <phantomcircuit> although actually i can think of at least one way to support such a long coinbase tx
355 2014-07-24 06:59:35 <phantomcircuit> Luke-Jr, ps midstate copy
356 2014-07-24 06:59:45 <Luke-Jr> phantomcircuit: if the extranonce is near the end, yes
357 2014-07-24 07:00:01 <phantomcircuit> Luke-Jr, so put it near the end and abort if its not
358 2014-07-24 07:00:06 <Luke-Jr> actually, Avalon2 has a stupid low limit of 6 kB gen txn :/
359 2014-07-24 07:00:06 <phantomcircuit> shrug
360 2014-07-24 07:00:24 <phantomcircuit> Luke-Jr, we have two miners being coded in parallel
361 2014-07-24 07:00:32 <phantomcircuit> one which is optimal for our pool software
362 2014-07-24 07:00:39 <phantomcircuit> and one for cgminer which is well
363 2014-07-24 07:00:41 <phantomcircuit> you know
364 2014-07-24 07:00:46 <Luke-Jr> a bad idea?
365 2014-07-24 07:00:51 <phantomcircuit> maybe that
366 2014-07-24 07:00:58 <Luke-Jr> phantomcircuit: bfgminer --benchmark --stratum-port 3333
367 2014-07-24 07:01:08 <phantomcircuit> Luke-Jr, que
368 2014-07-24 07:01:10 <Luke-Jr> phantomcircuit: line 5018 defines coinbase_sz
369 2014-07-24 07:01:17 <phantomcircuit> oh
370 2014-07-24 07:01:24 <Luke-Jr> easy way to test stuff ;)
371 2014-07-24 07:01:25 <phantomcircuit> coinbase for our pool is tiny
372 2014-07-24 07:01:32 <phantomcircuit> it's hard coded to a single output
373 2014-07-24 07:01:38 <phantomcircuit> which you know :P
374 2014-07-24 07:02:23 <Luke-Jr> phantomcircuit: you should really lart them and make them upgrade to BFGMiner ;)
375 2014-07-24 07:02:42 <phantomcircuit> Luke-Jr, the real time requirements are too tight
376 2014-07-24 07:02:48 <Belxjander> lart?
377 2014-07-24 07:03:00 <phantomcircuit> thermal shutdown is like 100 usec or your're pushing it
378 2014-07-24 07:03:17 <phantomcircuit> probably explains why 21e6 fried all their chips
379 2014-07-24 07:03:18 <phantomcircuit> twice
380 2014-07-24 07:03:21 <Luke-Jr> phantomcircuit: I don't follow. cgminer isn't going to do that any better than BFGMiner O.o
381 2014-07-24 07:03:34 <phantomcircuit> Luke-Jr, no but my custom mini miner will
382 2014-07-24 07:03:48 <phantomcircuit> temp shutdown takes ~1usec
383 2014-07-24 07:03:54 <phantomcircuit> it's a single spi write
384 2014-07-24 07:04:05 <Luke-Jr> phantomcircuit: why couldn't you do that in BFGMiner? O.o
385 2014-07-24 07:04:16 <phantomcircuit> polling interval
386 2014-07-24 07:04:20 <Luke-Jr> ?
387 2014-07-24 07:04:27 <Luke-Jr> you have your own thread to run as you like
388 2014-07-24 07:04:29 <phantomcircuit> the main networking thread provides a guaranteed response time of like 500ns
389 2014-07-24 07:04:41 <phantomcircuit> eh too complicated...
390 2014-07-24 07:04:44 <Luke-Jr> lol
391 2014-07-24 07:04:55 <phantomcircuit> no srsly
392 2014-07-24 07:05:02 <phantomcircuit> consider the locking constraints
393 2014-07-24 07:05:16 <phantomcircuit> it takes like 20ms to acquire a thread lock when there is extreme contention
394 2014-07-24 07:05:27 <phantomcircuit> by that time you're screwed
395 2014-07-24 07:05:54 <phantomcircuit> all of this really better suits a true realtime kernel
396 2014-07-24 07:05:56 <Luke-Jr> how is that any different from what you just described? O.o
397 2014-07-24 07:06:07 <Luke-Jr> oh, you're actually putting it in the kernel?
398 2014-07-24 07:06:17 <phantomcircuit> parts of it yeah
399 2014-07-24 07:06:53 <phantomcircuit> tbh looking at the code others are using has been lol hilarious
400 2014-07-24 07:07:00 <phantomcircuit> so many fundamental errors
401 2014-07-24 07:07:33 <Luke-Jr> jgarzik will be pleased
402 2014-07-24 07:08:45 <phantomcircuit> Luke-Jr, yeah we've been doing fpga revisions to fix issues that cause cpu time issues
403 2014-07-24 07:09:00 <phantomcircuit> basically everything is correctly interrupt driven now
404 2014-07-24 07:09:29 <phantomcircuit> of course the biggest problem is coming up with a thermal limiting algorithm that works
405 2014-07-24 07:09:35 <phantomcircuit> which is pretty complicated
406 2014-07-24 08:05:05 <Luke-Jr> wumpus: btw, I figured it was obvious, but just to be clear: laws/court orders come before dnsseed-policy, correct?
407 2014-07-24 08:05:56 <wumpus> Luke-Jr: no, IMO you should stop hosting the DNS seed in that case
408 2014-07-24 08:06:20 <wumpus> Luke-Jr: seemingly it's not possible to host one according to the requirements in your locale, then
409 2014-07-24 08:06:54 <Luke-Jr> wumpus: well, if they demand I turn over DNS query logs (which don't exist, FWIW), I would have to comply even if I shutdown the node at the same time
410 2014-07-24 08:07:10 <wumpus> Luke-Jr: sure - you may have to give off information once in that case
411 2014-07-24 08:07:41 <wumpus> Luke-Jr: the rules are not 'respond with violence to defend your server' :P
412 2014-07-24 08:07:51 <Luke-Jr> :D
413 2014-07-24 08:09:11 <wumpus> personal safety comes first, but anyhow, that's a good reason why having centralized DNS seeds is a flawed concept, it creates easy places to apply pressure
414 2014-07-24 08:09:27 <Belxjander> Luke-Jr: I would give them an empty file..and state that is the total content of any logging on the system by the original configuration
415 2014-07-24 08:13:47 <wumpus> anyhow; no list of guidelines wil protect against law enforcements or organized crime, but it may protect against advertising companies or privacy-violating research
416 2014-07-24 08:15:49 <gmaxwell> wumpus: I was contemplating a replacement.. HTTPseed. The server serves a quasi-static kitten picture, distributable via cdns/etc. The picture is a valid jpg but has signed seed data stuffed in the end. Nodes log the most recent seed responses. The signatures can prove if a seed is giving partition-inducing data, the fact that its a kitten picture means it can be embedded in random pages to provide cover traffic.
417 2014-07-24 08:16:15 <gmaxwell> The thing I got stuck on was that it's very hard to make a http request that is indistinguishable from a real browser. :(
418 2014-07-24 08:16:53 <wumpus> gmaxwell: wonderful idea :)
419 2014-07-24 08:17:45 <gmaxwell> I asked around the office and it was pointed out to me that future firefox useragents are predictable, so thats not so bad, but if the server responds with weird headers in any way it can easily distinguish a trivial http client and a real browser.
420 2014-07-24 08:18:53 <wumpus> gmaxwell: it could interface to a real browser to do the request
421 2014-07-24 08:19:13 <wumpus> gmaxwell: although, requiring a browser to be present on every system running bitcoind is proabbly a bit overkill :p
422 2014-07-24 08:19:17 <gmaxwell> Luke-Jr: wrt orders, the guidelines would have you minimizing keeping logs, obviously if ordered you comply but unless you can't, you should also take down the service.
423 2014-07-24 08:19:35 <wumpus> gmaxwell: (and insecure too, we'd get any holes in the browser for free)
424 2014-07-24 08:19:49 <gmaxwell> wumpus: hm. well if not it could fall back (the what is my ip code does a trivial http request already).. insecure is ugly though.
425 2014-07-24 08:21:54 <wumpus> but in general - yes, the solution would be to put the node data in a place where a lot of other data is too, to hide in the traffic
426 2014-07-24 08:22:21 <gmaxwell> yea, I thought about putting it in varrious pre-existing places, but they all have the quering party is identifyable problem.
427 2014-07-24 08:22:59 <wumpus> I wonder if there is other software that would benefit from something like this as well, if it couuld be generalizable it wouldn't identify bitcoin anymore per-ce
428 2014-07-24 08:23:33 <gmaxwell> Even if we can't solve the privacy, changing may be useful simply because signed seed messages would remove some attacks.
429 2014-07-24 08:23:36 <wumpus> can't we piggyback on bittorrent somehow? so many of that traffic on the internet
430 2014-07-24 08:24:14 <gmaxwell> bt DHT introduction basically has the same problem we do, clients just hardcode a couple initial hosts... and are completely dependant on them being honest.
431 2014-07-24 08:24:25 <gmaxwell> same for most other 'p2p' networks.
432 2014-07-24 08:24:33 <wumpus> sure, but if those hosts are used for other things too, it wuldn't be too identifying
433 2014-07-24 08:24:51 <gmaxwell> the other issue is needing non-trivial code to talk to things.
434 2014-07-24 08:25:07 <wumpus> right now we have hosts specific to bitcoin, so nothing to hide between
435 2014-07-24 08:25:09 <wumpus> right
436 2014-07-24 08:25:29 <gmaxwell> I contemplated using the tor directories.
437 2014-07-24 08:26:11 <wumpus> bootstrap-from-tor would be nice too, at least as option
438 2014-07-24 08:26:30 <gmaxwell> could probably code seed data into the exit descriptors and the directories can be fetched over 'plain https' but kinda ugly and easily censorable by the tor project.
439 2014-07-24 08:26:42 <gmaxwell> yes, if you actually have tor running then we can do much better things.
440 2014-07-24 08:27:13 <gmaxwell> We probably should come preloaded with some onionseeds. right now bootstrapping a onlynet=onion host basically doesn't work.
441 2014-07-24 08:27:25 <wumpus> good idea
442 2014-07-24 08:27:59 <gmaxwell> And thats alread authenticated and private, though the authenciation isn't recordable so it doesn't produce a transferable proof if a seed starts giving bad results. (though the strong privacy makes it harder for it to usefully attack without being detectable)
443 2014-07-24 08:28:38 <gmaxwell> yea, I'll do the onionseeds part soon.
444 2014-07-24 08:28:56 <gmaxwell> wumpus: fwiw I redid the external ip patch, and its much smaller now, just need to setup a testbed to see if it works.
445 2014-07-24 08:29:46 <wumpus> hm what would be a good unbiased way to get a list of hidden service node?
446 2014-07-24 08:29:58 <wumpus> just looking through my nodes' addr.dat?
447 2014-07-24 08:30:37 <phantomcircuit> Luke-Jr, if you receive threats related to dns seeds
448 2014-07-24 08:30:40 <Luke-Jr> ACTION wonders if IPv6 anycast is accessible enough to just have all bitcoin nodes act as anycast DNS seeds
449 2014-07-24 08:30:42 <phantomcircuit> send them my way
450 2014-07-24 08:30:48 <gmaxwell> Luke-Jr: not at all.
451 2014-07-24 08:30:57 <wumpus> gmaxwell: great, yes last time it stranded on some comments about moving around around, and lack of people interested in testing :/
452 2014-07-24 08:31:02 <drizztbsd> Luke-Jr: not yet
453 2014-07-24 08:31:12 <Luke-Jr> phantomcircuit: I doubt anyone will, there isn't any info to be gained they can't get at the ISP level
454 2014-07-24 08:31:35 <Luke-Jr> it's not like DNS seeds are encrypted or anything
455 2014-07-24 08:31:53 <phantomcircuit> Luke-Jr, true... but it would be something useful to fight against
456 2014-07-24 08:32:04 <phantomcircuit> especially since the intent is to obvious
457 2014-07-24 08:45:04 <stonecoldpat> from my understand, spv clients only receive blocks? (not just block headers, but the block itself)
458 2014-07-24 08:45:33 <stonecoldpat> or is it just block header + transaction id
459 2014-07-24 08:48:01 <Luke-Jr> just headers I think
460 2014-07-24 08:48:21 <wumpus> just headers, and filtered blocks
461 2014-07-24 08:48:24 <Luke-Jr> the "I think" is regarding whether they even need headers. I'd have to review bitcoin.pdf :p
462 2014-07-24 08:49:03 <wumpus> they need headers to keep up to date with the best chain
463 2014-07-24 08:49:49 <Luke-Jr> wumpus: I'd think they can use skiplists
464 2014-07-24 08:50:00 <stonecoldpat> it has me a bit confused, if it downloads block header only, how does it know a transaction id was accepted ?
465 2014-07-24 08:50:11 <stonecoldpat> itll have a merkle tree root, but thats just a hash
466 2014-07-24 08:50:28 <wumpus> stonecoldpat: it sets a bloom filter and received filtered blocks with tranactions that apply to it
467 2014-07-24 08:50:32 <Luke-Jr> stonecoldpat: it gets the merkle links too
468 2014-07-24 08:50:40 <wumpus> Luke-Jr: yup
469 2014-07-24 08:51:01 <wumpus> a filtered block also contains the merkle tree fragment needed to verify the transactions in it
470 2014-07-24 08:51:22 <stonecoldpat> ah ok i understand then, so it gets just enough information to create the merkle tree
471 2014-07-24 08:51:33 <wumpus> yes
472 2014-07-24 08:52:51 <wumpus> ugh, the peers.dat of none of my nodes contains any IsTor addresses
473 2014-07-24 08:53:33 <Luke-Jr> don't you only save addresses for networks you can reach?
474 2014-07-24 08:54:31 <wumpus> ... that may be the problem, though one of the peers.dat I checked is from a node that runs on tor (but not onlynet=onion)
475 2014-07-24 08:56:21 <wumpus> oh that one has 0 addresses in peers.dat at all, okay
476 2014-07-24 08:57:03 <Luke-Jr> lol
477 2014-07-24 09:02:01 <sipa> Luke-Jr: those skiplists are a very recent invention
478 2014-07-24 09:03:25 <Luke-Jr> sipa: I know ;)
479 2014-07-24 09:05:07 <sipa> it requires headers that are structured in a different way
480 2014-07-24 09:05:49 <Luke-Jr> sipa: I was there, remember? :p
481 2014-07-24 09:06:37 <sipa> Luke-Jr: they were invented by amiller a while before that
482 2014-07-24 09:07:00 <sipa> (for the purpose of synchronizing SPV nodes faster; our application was different)
483 2014-07-24 09:07:08 <gmaxwell> well maybe, amiller keeps insisting on the weird almost correct form that doesn't work. :P
484 2014-07-24 09:07:18 <sipa> i'm not convinced it doesn't
485 2014-07-24 09:07:25 <sipa> (but not that it does either)
486 2014-07-24 09:07:50 <gmaxwell> well it makes a very different proof, e.g. not of the actual work in the chain as we'd normally measure it.
487 2014-07-24 09:14:31 <Luke-Jr> I suppose one thing we *could* do today, is skip the prevblock part of the header for all but the first block header
488 2014-07-24 09:14:59 <gmaxwell> oh to make the responses smaller?
489 2014-07-24 09:15:04 <sipa> yup, we could
490 2014-07-24 09:15:23 <sipa> also, we could drop the pointless vtx count (=0) at the end of headers
491 2014-07-24 09:15:44 <sipa> ;;calc 33*[blocks]
492 2014-07-24 09:15:45 <gribble> 10304217
493 2014-07-24 09:15:56 <gmaxwell> (it's a ~bug that number isn't included in the data hashed... alas)
494 2014-07-24 09:16:05 <gmaxwell> thats pretty good.
495 2014-07-24 09:16:07 <sipa> in fact, we could also drop nBits
496 2014-07-24 09:16:31 <gmaxwell> yes, and time could be reduced to a much smaller amount if you don't mind a variable length encoding.
497 2014-07-24 09:16:45 <gmaxwell> likewise for version.
498 2014-07-24 09:17:01 <sipa> those together could probably save 6 extra bytes
499 2014-07-24 09:17:06 <gribble> 12177711
500 2014-07-24 09:17:06 <sipa> ;;calc 39*[blocks]
501 2014-07-24 09:17:20 <chichov> what's the precise encoding scheme used in bitcoin signatures?
502 2014-07-24 09:17:22 <gmaxwell> seems not terribly important compared to $gigs.
503 2014-07-24 09:17:26 <sipa> chichov: DER
504 2014-07-24 09:17:27 <chichov> ASN.1? DER?
505 2014-07-24 09:17:32 <chichov> sipa: thanks
506 2014-07-24 09:17:42 <sipa> chichov: see BIP62 for a reference
507 2014-07-24 09:18:02 <Luke-Jr> sipa: we could make nTime a 16-bit offset too :P
508 2014-07-24 09:18:05 <Luke-Jr> ..maybe
509 2014-07-24 09:18:30 <gmaxwell> Luke-Jr: I said this above, it could be variable length. Probably would fit in <16 bits most of the time.
510 2014-07-24 09:18:45 <Luke-Jr> ah, missed that
511 2014-07-24 09:19:29 <gmaxwell> but, doesn't seem super useful, ... I mean, if you suddenly care about overhead, the the skiplist commitments are much more fruitful.
512 2014-07-24 09:19:37 <Luke-Jr> guess I'm overdue for bed
513 2014-07-24 09:38:37 <sipa> a simple VARINT based encoding uses 12147677 bytes
514 2014-07-24 09:39:12 <sipa> ;;calc 12147677 / 312251
515 2014-07-24 09:39:13 <gribble> 38.9035647604
516 2014-07-24 09:44:09 <gmaxwell> sipa: for time are you subtracting off the median?
517 2014-07-24 09:45:52 <sipa> gmaxwell: good idea; let's see if that makes a difference
518 2014-07-24 09:46:11 <sipa> probably bitpacking the version and that adjusted difference into one integer would save more
519 2014-07-24 09:47:14 <gribble> 38.9226041787
520 2014-07-24 09:47:14 <sipa> ;;calc 12153661 / 312252
521 2014-07-24 09:47:39 <sipa> i need a better encoding for negative numbers too
522 2014-07-24 09:51:01 <gmaxwell> if you use the median of the last ten there will never be a negative number.
523 2014-07-24 09:51:16 <gmaxwell> er 11.
524 2014-07-24 09:52:10 <sipa> oooh!
525 2014-07-24 09:53:06 <gmaxwell> (thats what I originally meant. :P )
526 2014-07-24 09:55:00 <gribble> 39.0015115996
527 2014-07-24 09:55:00 <sipa> ;;calc 12178300 / 312252
528 2014-07-24 09:55:31 <sipa> i think the direct difference (with negative number support) is better because it's more frequently just one byte
529 2014-07-24 09:55:41 <sipa> the difference with the median of the last 11 very rarely is
530 2014-07-24 10:02:25 <gmaxwell> sipa: well you could handle negative numbers by coding zero and then the value differenced with the median, then offset your prediction to get the best size.
531 2014-07-24 10:06:49 <sipa> ;;calc 11951145 / 312253
532 2014-07-24 10:06:50 <gribble> 38.273915703
533 2014-07-24 10:06:52 <sipa> \o/
534 2014-07-24 10:07:46 <sipa> wait
535 2014-07-24 10:08:02 <gmaxwell> why are we hypermiling headers in any case?
536 2014-07-24 10:08:20 <sipa> because squeezing the last bits out of something is fun?
537 2014-07-24 10:08:27 <Jouke_> :)
538 2014-07-24 10:09:06 <gmaxwell> sipa: oh well, if thats the goal, you need a proper entropy encoder, and a mining loop to recover the last 8 bits of the nonce. :P
539 2014-07-24 10:09:24 <sipa> gmaxwell: been there, done that
540 2014-07-24 10:09:32 <sipa> well, not the nonce grinding
541 2014-07-24 10:10:42 <sipa> but using varints and conditions in an encoding may be (might be? pretty please?) acceptable on the P2P protocol; an entropy codes would be a bridge too far
542 2014-07-24 10:10:49 <sipa> or s/bridge/bit/
543 2014-07-24 10:12:19 <gmaxwell> next you're going to say we can't replace INV's with optimal polynominal-ratio set reconciliation?
544 2014-07-24 10:13:36 <gmaxwell> sadly most of those improvements go away for skiplist header proofs.
545 2014-07-24 10:15:15 <kazcw> "here's some data stem cells, use them to replace whatever you happen to be missing"
546 2014-07-24 10:15:40 <Jouke_> :}
547 2014-07-24 10:16:11 <petertodd> sipa: as someone who is implementing CMerkleBlock and friends right now, just keep it !@#$ simple...
548 2014-07-24 10:16:25 <sipa> petertodd: :D
549 2014-07-24 10:16:34 <wumpus> gmaxwell: I went through this list https://en.bitcoin.it/wiki/Fallback_Nodes#Tor_nodes and found 8 working hidden service nodes
550 2014-07-24 10:17:28 <gmaxwell> one of the reasons we need to have multiple p2p protocols is so that you can implement very efficient transports and when someone whines 'complex to implement!' you can respond "so? like I care?"
551 2014-07-24 10:17:40 <petertodd> gmaxwell: +1
552 2014-07-24 10:18:17 <petertodd> and when the complex one inevitably turns out to be riddled with bugs the simple one will get the data relayed anyway
553 2014-07-24 10:18:47 <wumpus> A P2P network of P2P networks!
554 2014-07-24 10:19:02 <sipa> wumpus: i have 17 hidden service nodes that have >50% 30d availability
555 2014-07-24 10:19:08 <sipa> (my crawler)
556 2014-07-24 10:19:25 <wumpus> sipa: okay, cool, can you send me those?
557 2014-07-24 10:19:39 <drizztbsd> do you know any vps hosting that permits tor?
558 2014-07-24 10:19:48 <petertodd> wumpus: violating the DNS seed policy already... tsk tsk
559 2014-07-24 10:20:05 <wumpus> petertodd: he's not logging DNS requests
560 2014-07-24 10:20:12 <petertodd> wumpus: I'm kidding :)
561 2014-07-24 10:20:16 <wumpus> petertodd: results from crawling can be used for anything
562 2014-07-24 10:20:19 <wumpus> petertodd: oh okay :)
563 2014-07-24 10:20:35 <petertodd> wumpus: but that is a good example why that distinction is important!
564 2014-07-24 10:20:51 <gmaxwell> I was sure to make that distinction for that kind of reason.
565 2014-07-24 10:20:51 <wumpus> also you can easily run a crawler without running a dns seed
566 2014-07-24 10:21:01 <petertodd> yup, I've done that before myself
567 2014-07-24 10:21:20 <wumpus> drizztbsd: unless you want to run an exit node it's usually not a problem in my experience
568 2014-07-24 10:21:41 <sipa> wumpus: http://0bin.net/paste/28HvtEt2xPFXHJF6#EuiF4u-lgWWOkM/74Wu+JtnPeUzfMRN9o2vrsjiKaJv
569 2014-07-24 10:21:52 <petertodd> drizztbsd: if you're really worried, buy your vps service with bitcoins...
570 2014-07-24 10:22:13 <wumpus> drizztbsd: I've had complains about connecting to IRC from vps'es, but never about tor
571 2014-07-24 10:22:21 <drizztbsd> ok, thanks
572 2014-07-24 10:22:29 <drizztbsd> and sorry for the slight ot :)
573 2014-07-24 10:22:47 <sipa> wumpus: my VPS is in Amsterdam, and i'm connected to irc from it
574 2014-07-24 10:24:08 <wumpus> sipa: well it's completely anecdotal and a long time ago, I suspect they were being used as launch pad for DoS attacks or spam and eventually decided to forbid IRC usage entirely
575 2014-07-24 10:24:38 <wumpus> sipa: thanks for the list
576 2014-07-24 10:25:00 <gmaxwell> on networks without nickserv and such it used to be adventagious to DOS attack people you didn't like off the network so you could take their names, or become ops in channels they were in.
577 2014-07-24 10:25:31 <gmaxwell> (the latter was usually more a motivation to attack servers, but on small channels users worked too)
578 2014-07-24 10:26:36 <wumpus> sipa: so your crawler crawls tor too?
579 2014-07-24 10:27:28 <wumpus> sipa: I quickly looked at the dns-seeder code and didn't see anything with tor so I assumed it didn't, but I supposedly didn't look good enough
580 2014-07-24 10:28:24 <petertodd> wumpus: -o <ip:port> Tor proxy IP/Port
581 2014-07-24 10:28:40 <wumpus> petertodd: ok
582 2014-07-24 10:29:18 <gmaxwell> sipa: only 17? we need more of those.
583 2014-07-24 10:29:45 <wumpus> ok, eliminiating the duplicates I have 23 now
584 2014-07-24 10:29:52 <petertodd> easiest might be to make the ubuntu packages depend on tor, and have a small compile script to setup the hidden service
585 2014-07-24 10:30:15 <wumpus> + my own that just added as hidden service
586 2014-07-24 10:30:45 <drizztbsd> petertodd: some isp filters tor
587 2014-07-24 10:30:50 <sipa> i have 24 that are considered well-reachable
588 2014-07-24 10:30:51 <drizztbsd> you have to use a bridge
589 2014-07-24 10:30:56 <sipa> but that's a more short-term criterion
590 2014-07-24 10:31:17 <petertodd> drizztbsd: I'm not suggesting we ship bitcoind Tor-only, suggesting we use both to connect
591 2014-07-24 10:31:34 <petertodd> drizztbsd: this is particularly important with stuff like fee estimation that assumes you aren't being sybil attacked
592 2014-07-24 10:32:07 <wumpus> sipa: do you have testnet hidden services too?
593 2014-07-24 10:32:33 <wumpus> I wouldn't think anyone would bother to run that, but heh, to be consistent
594 2014-07-24 10:33:43 <sipa> i don't have anything testnet, no
595 2014-07-24 10:33:45 <gmaxwell> I do, but doubt my testnet node would meet a 50% test.
596 2014-07-24 10:33:54 <sipa> not permanently running at least
597 2014-07-24 10:34:04 <gmaxwell> I could setup a reliable testnet hidden service node.
598 2014-07-24 10:35:57 <wumpus> well if we hardcode onionseeds, having at least one for testnet would be useful
599 2014-07-24 10:39:36 <wumpus> oh, we don't have normal pnSeeds for testnet either
600 2014-07-24 10:40:00 <sipa> move those to chainparams...
601 2014-07-24 10:41:10 <wumpus> they are in chainparams
602 2014-07-24 10:41:24 <wumpus> there are just none for testnet
603 2014-07-24 10:42:30 <gmaxwell> we don't.. perhaps we should also change how pnseeds work and have them unconditionally dump into addrman if its size 0 at start, would increase strenght against unfriendly dnsseeds..
604 2014-07-24 10:44:31 <iwilcox> Is it intentional that onlynet=tor still contacts seeds via exit nodes?
605 2014-07-24 10:46:30 <wumpus> shouldn't it be onlynet=onion anyway?
606 2014-07-24 10:46:41 <wumpus> ah, no , it's' still onlynet=tor
607 2014-07-24 10:47:40 <gmaxwell> iwilcox: it has no initilization method at all absent the seeds, so.. wumpus is fixing that now, however.
608 2014-07-24 10:48:27 <iwilcox> I'd imagine folks sufficiently motivated to use tor would be happy to put addnode/seednode in their config
609 2014-07-24 10:49:18 <iwilcox> I'm just annoyed way beyond reason/proportion that bitcoind never gives up trying to contact dnsseed.bitcoin.dashjr.org â dunno why that gets to me, it just does.
610 2014-07-24 10:49:41 <gmaxwell> considering how many times people have complained about it not working even with the dnsseed going on... doubt that, but with the internal list it would be more reasonable.
611 2014-07-24 10:49:42 <wumpus> iwilcox: try jgarzik's don't-use-dnsseeds-if-not-needed patch, it's great
612 2014-07-24 10:51:36 <iwilcox> Oh, I'll look that one up, thanks
613 2014-07-24 10:53:17 <wumpus> I think it makes sense to replace pnSeeds with IPv6,port pairs instead, so that it can be used for IPv6 seed nodes as well once we have those (onion is just a subset of IPv6 for us)
614 2014-07-24 10:53:25 <arioBarzan> could someone give an example of a txCopy on testnet for explaining "what should be signed" for Hashtype SIGHASH_ANYONECANPAY? I have been unsuccessful with 01000000-01-6df783b57b5827102159dbbcd96ecf36d8ea8cbeedfb983c5f21bf5c31c589e1-01000000-19-76a914154fa19034d0024497a45c70f19fc428594ecafa88ac-ffffffff-01-a03e8a0000000000-19-76a91487282ccf16c001afad5f593694ff1357c7cf9b1f88ac-00000000-80000000
615 2014-07-24 10:55:29 <wumpus> meh just going to add a pnSeed6 for now
616 2014-07-24 12:01:22 <arioBarzan> know any website for pushing a testnet raw transaction?
617 2014-07-24 12:08:13 <elichai2> arioBarzan: what's wrong with bitcoin-cli?
618 2014-07-24 12:09:16 <arioBarzan> elichai2: I don't have a synced node on testnet.
619 2014-07-24 12:10:02 <elichai2> i don't think there is a site
620 2014-07-24 12:10:53 <elichai2> but i just got an idea, why not sombody will get a good server and run on it bitcoind and give the RPC prefs to anyone who need?
621 2014-07-24 12:11:56 <arioBarzan> tbtc.blockr.io/tx/push does push tx on testnet, and I have used it for few transactions, but I have one raw tx that they don't accept it.
622 2014-07-24 12:12:32 <elichai2> so maybe it's invaild :P
623 2014-07-24 12:12:42 <elichai2> give it to me, i'll try push it
624 2014-07-24 12:12:49 <elichai2> (i have fully synced node to testnet)
625 2014-07-24 12:13:07 <arioBarzan> thanks a lot
626 2014-07-24 12:13:08 <arioBarzan> 01000000019B156F4B35672DDEB209E5DFF44471DD347A0DFED5FCCEB3795510BCA8C5E67800000000B5493046022100F214C8614EAF83B03AE2936039A1F2F0E63698A64025055CCB8FD38820F3680E022100ED22788583243184E89D1144409F67786FF2539C477596F9A6742EB7CF76ECA601483045022100D50880576FF6A86573B62C76F136FEB21346C8ECAED2996ACCBB6C2F2A5F9FE20220642B9CD1810669EDEA86E3C4655D13C4540F7FAB1E4C3F9996006E003F1AA9DD012102CEF2A85A1F45F62AD5A896CB5FC93FB1A87232955D0BD4D1B124527
627 2014-07-24 12:13:08 <arioBarzan> 0A0C12AD6FFFFFFFF01C08C8A00000000001976A91487282CCF16C001AFAD5F593694FF1357C7CF9B1F88AC00000000
628 2014-07-24 12:13:12 <elichai2> wait
629 2014-07-24 12:13:14 <elichai2> pastebin it
630 2014-07-24 12:14:00 <elichai2> arioBarzan: ?
631 2014-07-24 12:15:03 <arioBarzan> elichai2: couldn't pastebin it
632 2014-07-24 12:15:15 <drizztbsd> whynot?
633 2014-07-24 12:15:49 <elichai2> why not?
634 2014-07-24 12:15:55 <elichai2> you are on linux?
635 2014-07-24 12:16:02 <arioBarzan> tried but failed, just concatenate the two parts I sent please.
636 2014-07-24 12:16:11 <elichai2> if yes so pipe the output to pastebinit tool
637 2014-07-24 12:24:19 <arioBarzan> elichai2: I've put it @ meighti.cu.cc/rawtx.txt
638 2014-07-24 12:28:04 <arioBarzan> elichai2: did your bitcoind also reject it? I'm not sure if it is valid
639 2014-07-24 12:30:31 <arioBarzan_> elichai2: I've put it @ http://meighti.cu.cc/rawtx.txt
640 2014-07-24 12:30:53 <arioBarzan_> elichai2: did your bitcoind also reject it? I'm not sure if it is valid
641 2014-07-24 12:39:27 <arioBarzan> elichai2: are you still there?
642 2014-07-24 12:46:08 <rdponticelli> arioBarzan: Yes, bitcoind is rejecting it
643 2014-07-24 12:47:47 <arioBarzan> rdponticelli: thanks. I was trying to create a tx with an input with hashtype SIGHASH_ANYONECANPAY, apparently still no success.
644 2014-07-24 12:49:22 <arioBarzan> the wiki says that "The txCopy input vector is resized to a length of one. The subScript (lead in by its length as a var-integer encoded!) is set as the first and only member of this vector."
645 2014-07-24 13:02:53 <elichai2> arioBarzan: sorry.... i went to do something.... i'm here now
646 2014-07-24 13:03:40 <elichai2> make sure the subscript isn't longer than 500 bits
647 2014-07-24 13:04:08 <arioBarzan> elichai2: no problem, the tx was rejected on rdponticelli's node.
648 2014-07-24 13:09:01 <petertodd> arioBarzan: read the source; the wiki has some subtle bugs
649 2014-07-24 13:10:43 <petertodd> arioBarzan: that said, >0.9 made SignatureHash() *way* harder to understand; read the 0.8 source instead
650 2014-07-24 13:11:24 <arioBarzan> petertodd: thanks
651 2014-07-24 13:11:25 <petertodd> arioBarzan: also, python-bitcoinlib's implementation is correct and easy to read: https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/core/script.py#L879
652 2014-07-24 13:13:38 <sipa> petertodd: the original 0.8 code is still in the unit tests
653 2014-07-24 13:14:03 <petertodd> sipa: what's the function name called again? I was just looking for that
654 2014-07-24 13:25:55 <elichai2> petertodd: there is any way to deBug the transaction vaild check?
655 2014-07-24 13:26:55 <sipa> recent bitcoind will tell you what went wrong, when you use sendrawtransaction
656 2014-07-24 13:27:18 <elichai2> sipa: mines just tell me: 'error: {"code":-22,"message":"TX rejected"}'
657 2014-07-24 13:27:25 <sipa> what version bitcoind?
658 2014-07-24 13:29:25 <elichai2> sipa: just a sec...
659 2014-07-24 13:41:27 <kruug> so, working on setting up gitian-builder per the debian instructions, I get this for an error: http://pastebin.com/85206Hxv
660 2014-07-24 13:41:39 <elichai2> sipa: Bitcoin RPC client version v0.9.1.0-g026a939-beta
661 2014-07-24 13:43:47 <wumpus> kruug: did you install vmbuilder from source as mentioned in the guide
662 2014-07-24 13:44:08 <kruug> yes
663 2014-07-24 13:44:17 <kruug> I followed the instructions via copy+paste
664 2014-07-24 13:44:54 <wumpus> I'm *sure* that last time I followed those instructions, they worked
665 2014-07-24 13:44:58 <kruug> I'm building on LMDE
666 2014-07-24 13:45:07 <kruug> not sure if that is an issue.
667 2014-07-24 13:45:35 <wumpus> that may be the reason, probably it is some version conflict somewhere
668 2014-07-24 13:45:56 <wumpus> maybe if you google for the error it bring up some hits
669 2014-07-24 13:46:14 <kruug> no, it only brought up the same error tag with a different module
670 2014-07-24 13:46:35 <kruug> and google searching for hte module, and it brings up code that references the module
671 2014-07-24 13:46:57 <kruug> I'll just spin up a debian virtual machine...
672 2014-07-24 13:47:15 <wumpus> the curious thing is that register_hypervisor_plugin is an internal module part of VMbuilder
673 2014-07-24 13:47:33 <wumpus> so you downloaded and installed it already, how can it fail importing it?
674 2014-07-24 13:48:33 <wumpus> does the file exist?
675 2014-07-24 13:50:35 <kruug> wumpus: how can I check?
676 2014-07-24 13:58:13 <kruug> wumpus: all of the files from the Traceback are present
677 2014-07-24 14:04:55 <wumpus> kruug: I cannot help you with the details of python debugging
678 2014-07-24 14:05:24 <kruug> ugh...I wish there was an actual gitian support network instead of relying on bitcoin devs...
679 2014-07-24 14:05:37 <wumpus> but there are various ways, from fully-fledged UI debuggers to simple tracing
680 2014-07-24 14:05:54 <wumpus> kruug: well, start one! :)
681 2014-07-24 14:06:22 <kruug> I would, but I'm on the side of needing help instead of the side of offering help...
682 2014-07-24 14:07:07 <wumpus> we're all on both sides
683 2014-07-24 14:11:25 <sipa> elichai2: try 0.9.2.1
684 2014-07-24 14:19:56 <rdponticelli> elichai2, sipa: I got -25, which is RPC_TRANSACTION_ERROR on a recent 0.9.99
685 2014-07-24 14:30:04 <elichai2> sipa: ok.... maybe i'll just use the master?
686 2014-07-24 14:37:24 <wumpus> you could, although master is less tested than the releases so you must be prepared to debug issues
687 2014-07-24 14:37:51 <elichai2> but master won't do problems to me?
688 2014-07-24 14:38:03 <wumpus> it could.
689 2014-07-24 14:38:04 <elichai2> because of the fact that isStandard is diffrent?
690 2014-07-24 14:38:21 <elichai2> and it can accept some tx's that miners won't accept?
691 2014-07-24 14:38:25 <kruug> wumpus: created ##gitian. Now taking applications for ops
692 2014-07-24 14:38:27 <kruug> :)
693 2014-07-24 14:38:44 <wumpus> kruug: heh
694 2014-07-24 14:38:55 <sipa> elichai2: master may format your harddrive, use at your own risk
695 2014-07-24 14:39:07 <elichai2> sipa: whhhhhaaaattttt?!?!?!?!?!?!?
696 2014-07-24 14:39:13 <elichai2> why would it???
697 2014-07-24 14:39:16 <wumpus> kruug: do invite devrandom, he created gitian :)
698 2014-07-24 14:39:20 <sipa> elichai2: because it's not well tested
699 2014-07-24 14:39:38 <sipa> of course, it's exceedingly unlikely that it will do something like that
700 2014-07-24 14:39:45 <sipa> but i won't promise you that it won't
701 2014-07-24 14:39:46 <elichai2> sipa: ohhh lol
702 2014-07-24 14:39:57 <elichai2> you really trying to make people crazy, ha?
703 2014-07-24 14:40:03 <wumpus> of course, releases may also format your harddisk, there is never any guarantee, but much more people have tried them
704 2014-07-24 14:40:23 <sipa> elichai2: i'm just trying to explain to you that you should be cautious, and that we can't promise anything
705 2014-07-24 14:40:31 <sipa> master may or may not work; no promises
706 2014-07-24 14:40:32 <elichai2> btw, if i don't give it root access it can only rm my home dir
707 2014-07-24 14:40:49 <wumpus> elichai2: which is usually where the most important files are :p
708 2014-07-24 14:40:59 <elichai2> yeah lol
709 2014-07-24 15:07:22 <arioBarzan> guys do you have any example transaction which one of its inputs is signed by hashtype SIGHASH_ANYONECANPAY ?
710 2014-07-24 15:11:04 <kruug> wumpus: it had to have been an issue with something on LMDE...I have Debian 7.4 running and everything is working