1 2014-06-21 00:26:20 <jtimon> is SHA256 used in hash.h slower than SHA256Transform in miner.cpp?
2 2014-06-21 00:26:20 <jtimon> what's the reason why ScanHash_CryptoPP hashes with everything reversed while CBlockHeader::getHash doesn't?
3 2014-06-21 00:38:18 <jtimon> if so, does anybody care about bitcoind's mining efficiency?
4 2014-06-21 00:39:49 <gmaxwell> jtimon: no, absolutely not, it's already like 4x slower than more efficient cpu miner code. It's only really useful for regtest/testnet.
5 2014-06-21 00:41:34 <jtimon> so if I simplify miner.cpp maybe with some performance cost nobody will care, great
6 2014-06-21 00:42:34 <gmaxwell> (Personally I'd like to remove the miner completely, and start bundling bfgminer in our binary releases (since I think it's important that we continue to ship a complete implementation of the bitcoin system and not ghettoize mining by removing it).)
7 2014-06-21 00:42:56 <gmaxwell> (perhaps with some minor enhancement to bfgminer so it can automatically read a bitcoin.conf like p2pool does)
8 2014-06-21 00:43:02 <jtimon> putting the blockheader in a struct with all fields reversed seems very ugly
9 2014-06-21 00:43:45 <jtimon> I think it's interesting to have it for regtest and educational purposes
10 2014-06-21 00:44:05 <jtimon> thought if it's going to be inneficient it could be at least readable
11 2014-06-21 00:45:15 <jtimon> this variable is set but never read directly, what an ugly hack:
12 2014-06-21 00:45:15 <jtimon> unsigned int& nBlockTime = *(unsigned int*)(pdata + 64 + 4);
13 2014-06-21 00:46:16 <gmaxwell> whatever you do, be mindful of: https://github.com/bitcoin/bitcoin/pull/4100
14 2014-06-21 00:53:35 <gmaxwell> I suspect it may be redundant with some of what you're looking at, if soâ would be helpful if you could give it a review and an ack.
15 2014-06-21 00:55:00 <jtimon> thanks
16 2014-06-21 01:04:54 <Luke-Jr> [00:42:56] <gmaxwell> (perhaps with some minor enhancement to bfgminer so it can automatically read a bitcoin.conf like p2pool does) <-- that's a good idea.
17 2014-06-21 01:05:21 <Luke-Jr> gmaxwell: I don't like bundling though. Maybe we should just distribute a "Bitcoin installer" that offers to download and install things with gitian checks.
18 2014-06-21 01:07:35 <gmaxwell> Luke-Jr: even independantly of any group dist you should probably add the conf reading so you can do local block submission by default, for gbt users where there is already a bitcoind running on the same host.
19 2014-06-21 01:07:55 <Luke-Jr> gmaxwell: yes, it seems like a good idea
20 2014-06-21 01:08:10 <Luke-Jr> I wonder how practical it is to find bitcoin.conf though
21 2014-06-21 01:08:32 <gmaxwell> p2pool is fairly effective, should look at what it does.
22 2014-06-21 01:08:53 <gmaxwell> Petertodd's dustbegone does too, though I think I suggested he pattern it after p2pool.
23 2014-06-21 01:10:18 <Luke-Jr> p2pool has a giant Python standard library to lean on ;)
24 2014-06-21 01:17:19 <andytoshi> my coinjoin client just copied exactly what bitcoind does
25 2014-06-21 01:29:52 <lechuga_> lol@ghettoize mining
26 2014-06-21 01:35:03 <Luke-Jr> it would be pretty neat if someone made an installer that could decide the best setup for the user based on simple questions and do it
27 2014-06-21 01:35:24 <Luke-Jr> eg, if they have storage/bandwidth/CPUtime, always install bitcoind even if they use Electrum as the wallet sw
28 2014-06-21 01:35:38 <Luke-Jr> (and configure Electrum to use localhost as its node)
29 2014-06-21 01:37:00 <mr_burdell> Luke-Jr: electrum server is a pretty big overhead for a desktop though
30 2014-06-21 01:37:20 <Luke-Jr> mr_burdell: is it? :|
31 2014-06-21 01:37:23 <mr_burdell> and definitely not designed for turning on and off
32 2014-06-21 01:37:32 <Luke-Jr> I thought it was just any bitcoin node
33 2014-06-21 01:37:32 <mr_burdell> it has to keep the utxo db
34 2014-06-21 01:37:35 <mr_burdell> so an extra 5 gb
35 2014-06-21 01:37:38 <Luke-Jr> meh
36 2014-06-21 01:38:01 <mr_burdell> which is why electrum can look up utxo's much faster than other lite clients
37 2014-06-21 01:38:11 <Luke-Jr> still, could be a framework with Bitcoin-Qt vs Armory at first, and let the other wallets adapt :p
38 2014-06-21 01:38:23 <mr_burdell> true
39 2014-06-21 01:38:39 <mr_burdell> and reduce options for new users
40 2014-06-21 01:38:52 <mr_burdell> ppl don't like to make decisions
41 2014-06-21 01:39:14 <lechuga_> sometimes i do but i have a tough time deciding when
42 2014-06-21 01:43:34 <dsnrk> Luke-Jr: electrum also talks to multiple servers for censorship resistance
43 2014-06-21 01:44:56 <Luke-Jr> dsnrk: there's no need for that if you ran the server yourself
44 2014-06-21 01:48:09 <dsnrk> I mean it's not an option to turn it off
45 2014-06-21 01:48:29 <Luke-Jr> that's kinda lame :p
46 2014-06-21 01:57:32 <mr_burdell> dsnrk: it is
47 2014-06-21 01:57:45 <mr_burdell> there's a command line option
48 2014-06-21 01:58:57 <mr_burdell> plus it gets the list of servers from the server you're connected to, so if you connect to your own isolated server, it shouldn't find any others
49 2014-06-21 01:59:30 <kazcw> what's the point of connecting to multiple servers if it gets the server list from the first server it sees??
50 2014-06-21 01:59:51 <mr_burdell> oh, yeah... it does have a default list
51 2014-06-21 01:59:59 <mr_burdell> so I guess it runs through that
52 2014-06-21 02:00:13 <mr_burdell> not sure... I'd have to go look at it again
53 2014-06-21 02:01:07 <dsnrk> mr_burdell: not in the gui is what I mean.
54 2014-06-21 02:08:45 <mr_burdell> hmmm... I guess that could be a bug, not sure a better way to do it... doesn't bitcoind do something similar?
55 2014-06-21 02:09:00 <mr_burdell> gets a peer from dns? or gets a bunch?
56 2014-06-21 02:09:10 <mr_burdell> and then connects and asks for more peers
57 2014-06-21 02:48:07 <cfields> sipa: yea, it's free. I did secp256k1 first as a test, to see if it's well received. Hoping to do it for bitcoin if it goes well.
58 2014-06-21 03:27:43 <fanquake> ;;blocks
59 2014-06-21 03:27:43 <gribble> 306939
60 2014-06-21 09:03:39 <petertodd> dsnrk: not quite - the message I was seeing was ProcessMessages(tx, 1 bytes), so transactions rather than pings. haven't seen the ping variant either (though these nodes are mainnet, not testnet)
61 2014-06-21 09:03:54 <petertodd> dsnrk: oh, reminds, me, I need to put some replace-by-fee nodes on testnet :)
62 2014-06-21 09:58:30 <warren> anyone know of statistics of how often N-block reorgs happen on the network?
63 2014-06-21 10:08:10 <Luke-Jr> LOL, is this really necessary? http://openport8333.com/
64 2014-06-21 10:15:30 <gmaxwell> potentially counter productive... listening on residental broadband with a bufferbloaty router can cause really bad performance when one or two people stary yanking the blockchain from you, might make you switch off a full node entirely.
65 2014-06-21 10:16:36 <wumpus> gmaxwell: yes, that's well known :)
66 2014-06-21 10:17:08 <gmaxwell> (was commenting on luke's link which nags you to open the port)
67 2014-06-21 10:17:34 <wumpus> I know why we can't do it 'yet', but bandwidth controls on the full node would be really nice
68 2014-06-21 10:17:43 <gmaxwell> yep. Soon!
69 2014-06-21 10:17:54 <dizko> is there a simple way to build bitcoind with most of the libs statically linked the way they are in the reference binary? or was that done manually
70 2014-06-21 10:18:02 <dizko> like, using autoconf, etc
71 2014-06-21 10:18:06 <wumpus> Port 8333 is OPEN! woohoo
72 2014-06-21 10:20:16 <wumpus> dizko: use gitian
73 2014-06-21 10:20:37 <wumpus> there is no simple way to do that because it's definitely not simple in the first place
74 2014-06-21 10:20:55 <warren> using gitian is simpler than building on fedora =)
75 2014-06-21 10:21:14 <warren> btw, what's going on with merging libsecp256k1?
76 2014-06-21 10:21:25 <wumpus> there are many crazy and frustrating edge cases if you try do do it manually, for example you need to compile all the dependency libraries using -fPIC otherwise they cannot be statically-linked into a position-independent binary
77 2014-06-21 10:21:36 <Luke-Jr> warren: cfields hasn't fixed it to NOT embed a copy yet :/
78 2014-06-21 10:21:48 <wumpus> (which meant that you cannot use the statically linked ilbs provided by the distro)
79 2014-06-21 10:22:00 <warren> Luke-Jr: that sounds desireable to me
80 2014-06-21 10:22:01 <wumpus> Luke-Jr: we had that discusson on github - IMO it should embed a copy
81 2014-06-21 10:22:37 <dizko> wumpus: ok thanks for the tip
82 2014-06-21 10:22:45 <wumpus> Luke-Jr: I'm fine with an *option* to use an external copy, but there are tons of reasons to not depend on some obscure new library with interface in heavy flux as external dependency
83 2014-06-21 10:22:59 <gmaxwell> Well we're certantly not going to do anything but embed while the API is totally unfinished and not released yet.
84 2014-06-21 10:23:11 <wumpus> anyhow -- let's keep that discussion in the github request, no need to repeat it here
85 2014-06-21 10:23:13 <Luke-Jr> wumpus: at least it should be a submodule instead of a copy
86 2014-06-21 10:23:31 <Luke-Jr> copies are ugly :<
87 2014-06-21 10:23:39 <wumpus> Luke-Jr:we use *subtree* instead of submodule
88 2014-06-21 10:23:48 <Luke-Jr> subtree is braindead. sorry.
89 2014-06-21 10:23:52 <warren> where's the github discussion?
90 2014-06-21 10:23:55 <wumpus> according to many people it's superior this way, I don't want to argue really
91 2014-06-21 10:24:17 <wumpus> warren: on the pull request that does the integration maybe ?:p
92 2014-06-21 10:24:45 <gmaxwell> Luke-Jr: submodule is also braindead. In any case, doing it this way lets us have perfect control over consensus critical code. Less needed for libsecp256k1 since we're the primary user, but it's reasonable hyigine.
93 2014-06-21 10:24:49 <wumpus> also we already use subtree in many places, way to make it some inconsistent frankenstein monster if we now start using submodule
94 2014-06-21 10:24:58 <Luke-Jr> wumpus: subtree worksaround various shortcomings in submodule's current git-client-side implementation, but it's still an ugly hack
95 2014-06-21 10:25:15 <Luke-Jr> gmaxwell: submodule gives just as much control, just has some rough edges
96 2014-06-21 10:25:51 <wumpus> I'm really, really sick of all these arguments where there is technology A and technolgy B and they are pretty much indistinguishable except some small technical detail, and there are big arguments every time to switch to the other
97 2014-06-21 10:26:06 <wumpus> tldr; no
98 2014-06-21 10:26:26 <gmaxwell> bigger stuff to worry about. majority preference is the way it's working now.
99 2014-06-21 10:26:26 <Luke-Jr> sigh
100 2014-06-21 10:26:45 <gmaxwell> and the subtree stuff was a big improvement for leveldb, using two things would be less good.
101 2014-06-21 10:27:07 <wumpus> thi is just a waste of time, let's agree that we want the same thing, integrate secp256k1
102 2014-06-21 10:27:59 <Luke-Jr> fine, as long as it *can* use a shared lib when available
103 2014-06-21 10:28:17 <wumpus> submit a pull by then, if it looks sane it will be merged
104 2014-06-21 10:29:30 <Luke-Jr> k, I'll wait until after this gets merged
105 2014-06-21 10:29:47 <wumpus> and until a stable API peters out
106 2014-06-21 10:30:14 <gmaxwell> Luke-Jr: libsecp256k1 is going to be explicitly labled don't package until the api is done... so it'll be a little bit.
107 2014-06-21 10:30:41 <Luke-Jr> wumpus: libraries don't need stable APIs. that's why they're versioned..
108 2014-06-21 10:31:08 <wumpus> also we have to be really careful with distributions, as it is a security and consensus-critical library we can't have jokes like the bitcoind 0.3.xx in Ubuntu stable...
109 2014-06-21 10:31:32 <gmaxwell> Luke-Jr: not just ABI, but the whole API needs redesign... really rude to get people using a library and then basically change it out from under them.
110 2014-06-21 10:31:37 <wumpus> people will only be frustrated 'how do I get a newer version of this dep!!!'
111 2014-06-21 10:32:01 <Luke-Jr> wumpus: distributions *will* strip the library out and do this regardless; if we don't support it, it means third-party patching
112 2014-06-21 10:32:20 <wumpus> Luke-Jr: that's their problem
113 2014-06-21 10:32:59 <wumpus> it's open source, people can mutilate it any way they want and make it do things that ewren't meant to... with openssl that already went very wrong once... :/
114 2014-06-21 10:33:20 <Luke-Jr> better not to force them to
115 2014-06-21 10:33:25 <gmaxwell> In any case, libsecp256k1 is still too far from production for this discussion.
116 2014-06-21 10:33:53 <gmaxwell> Supporting a argument makes sense, and we'll do itâ though it may need to wait for libsecp256k1 to be packagable.
117 2014-06-21 10:33:56 <wumpus> strange definition of 'force'
118 2014-06-21 10:34:39 <Luke-Jr> ACTION wonders when/if Fedora will get over secp256k1 (the curve)
119 2014-06-21 10:35:41 <warren> Perhaps Fedora wants a NIST-only coin...
120 2014-06-21 10:36:42 <Luke-Jr> it would be nice if GBT2 could use secp256k1 for authentication
121 2014-06-21 10:38:29 <petertodd> gmaxwell: re: dust-b-gone, what did you mean by "pattern it after p2pool"?
122 2014-06-21 10:38:58 <gmaxwell> Heh.. noticed the p2pool graphs on my p2pool node here showing the number of hashes the pool calculated in the last month "1.49 ZH" .. pretty sure this is the first time I've noticed the zetta- si prefix in actual use measuring something real.
123 2014-06-21 10:39:09 <gmaxwell> petertodd: just the locations it checks.
124 2014-06-21 10:39:19 <petertodd> gmaxwell: ?
125 2014-06-21 10:39:34 <gmaxwell> petertodd: the context was automatically finding bitcoin.conf
126 2014-06-21 10:39:56 <petertodd> gmaxwell: ah, ok! I think I implemented that actually
127 2014-06-21 10:40:14 <petertodd> gmaxwell: I thought you meant strucure it like p2pool share chain somehow... which had me confused
128 2014-06-21 10:40:37 <gmaxwell> you did. I suggested luke look at p2pool and at your code, then commented that maybe yours is just like p2pool because I thought I suggested you look at how p2pool does it.
129 2014-06-21 10:41:35 <petertodd> gmaxwell: ah, yeah, I didn't read enough of the context. In any case, the clever thing i do need to do is make it automatically add the dust txouts to other peoples' ANYONECANPAY txs... that and get other people to make ANYONECANPAY txs :P
130 2014-06-21 10:42:33 <gmaxwell> needs wallet integration, I'm not sure how to handle integrating things that need a 'server'â for essential services I wouldn't want that, but I think a serverful dust be gon is fine so long as it doesn't allow client enumeration.. e.g. tor only.
131 2014-06-21 10:42:38 <Luke-Jr> ACTION adds to his todo file before he forgets
132 2014-06-21 10:43:49 <Luke-Jr> I suppose I'll have to special-case bitcoind to try getnewaddress when one isn't provided too :x
133 2014-06-21 10:45:12 <petertodd> gmaxwell: well, the interesting thing with it is that a sufficiently smart miner would strip out all the dust-b-gone inputs that paid fees less than their acceptance threshold - might as well just get rid of the dust on a per-txout basis, and ideally with the option of other peopl's txs
134 2014-06-21 10:46:31 <Luke-Jr> ACTION notes dust-b-gone could conceivably just be a p2p extension to relay "forfeit" signatures
135 2014-06-21 10:46:54 <gmaxwell> petertodd: perhaps, carrying it all around in the flooding network isn't so elegant considering that its very low priority.
136 2014-06-21 10:47:07 <petertodd> Luke-Jr: well we already have that extension - each dust-b-gone txin is valid
137 2014-06-21 10:47:52 <petertodd> see, if you're going to be doing SIGHASH_ANYONECANPAY txs, you want to drop txins that pay really low fees automatically anyway, least it become a DoS attack to tack on low-value txins
138 2014-06-21 10:50:17 <Luke-Jr> actually, scratch the p2p dust-b-gone idea. it's a bad idea.
139 2014-06-21 10:50:40 <Luke-Jr> the whole reason they're dust is because they'd be a DoS risk.
140 2014-06-21 10:51:07 <gmaxwell> yea, well it could be made less wasteful, but probably not worth the complexity.
141 2014-06-21 10:51:11 <petertodd> Luke-Jr: indeed - what's good about dust-b-gone isn't making the UTXO set smaller, it's making deanonymization spam downright counterproductive
142 2014-06-21 10:51:23 <Luke-Jr> petertodd: did any of that confirm?
143 2014-06-21 10:51:32 <Luke-Jr> I have a ton in my wallet, but they're all unconfirmed
144 2014-06-21 10:51:44 <gmaxwell> though to throughly break the deanonymization spam it needs to become coinjoins and not SIGHASH_ANYONECANPAY.
145 2014-06-21 10:51:46 <petertodd> Luke-Jr: oh, the process to get rid of the dust is manual, one sec...
146 2014-06-21 10:52:39 <petertodd> gmaxwell: sort of, if it's just SIGHASH_ANYONECANPAY but not SIGHASH_NONE it's still coinjoin you know
147 2014-06-21 10:53:05 <gmaxwell> yea, still, really identifyable as a failed attempt vs standard behavior
148 2014-06-21 10:53:17 <gmaxwell> I agree thats its better than not dustbegoining.
149 2014-06-21 10:53:39 <petertodd> Luke-Jr: try resending your dust
150 2014-06-21 10:53:45 <Luke-Jr> petertodd: ?
151 2014-06-21 10:53:57 <Luke-Jr> send unconfirmed dust?
152 2014-06-21 10:54:08 <Luke-Jr> what's the point?
153 2014-06-21 10:54:32 <gmaxwell> petertodd: luke is telling you that he had dust payments to him which never confirmed.
154 2014-06-21 10:54:32 <petertodd> gmaxwell: well, the thing is we can also expect users of various things to be adding small inputs to transactions themselves for fee bumping reasons, which makes dust vs. that be an anonymity set
155 2014-06-21 10:54:50 <petertodd> gmaxwell, Luke-Jr: ah, I get it, I thought you meant you'd run dust-b-gone
156 2014-06-21 10:55:05 <petertodd> I just checked and no-one's sent it dust for a few months
157 2014-06-21 10:55:32 <gmaxwell> I've not recieved any unsoliticed dust lately at all, except some of the p2pool donations were a bit small.
158 2014-06-21 10:55:42 <gmaxwell> I suspect whatever was doing a bunch of it stopped.
159 2014-06-21 10:56:16 <petertodd> well until recently fees and min txout amounts had made it kinda expensive
160 2014-06-21 10:57:28 <Luke-Jr> I don't think *any* of the spam ever confirmed for me
161 2014-06-21 10:57:53 <Luke-Jr> and dust I acquired through other means got hand-picked into transactions :p
162 2014-06-21 11:09:41 <dsnrk> just of note regarding dust outputs, a user posted a transaction recently that was made using vanilla bitcoin qt that had some very small sub-dust outputs in it. I was under the impression that > dust outputs would just be rolled into the fee? is it a regression that this user ended up with them in their transaction?
163 2014-06-21 11:13:18 <petertodd> dsnrk: remember that the definition of dust changed recently
164 2014-06-21 11:13:24 <Luke-Jr> dsnrk: you mean inputs?
165 2014-06-21 11:14:53 <sipa> dust outputs shouldn't be created using the normal wallet transaction creation code
166 2014-06-21 11:15:02 <sipa> but they are very small these days
167 2014-06-21 11:15:07 <sipa> with default relay fee
168 2014-06-21 11:15:51 <dsnrk> ah yes, I had the value of the dust output size off by a few
169 2014-06-21 11:17:12 <dsnrk> does the coin selection routine avoid dust as well?
170 2014-06-21 11:18:11 <gmaxwell> dsnrk: yes unless your wallet is absolutely flooded with it
171 2014-06-21 11:49:11 <chichov> does the reference implementation currently only allow 2^32-1 as the transaction sequence number?
172 2014-06-21 11:50:59 <sipa> no
173 2014-06-21 11:51:03 <sipa> any number is acceptable
174 2014-06-21 11:51:55 <sipa> but if all input's sequence numbers are 2^32-1, the transaction is automatically final
175 2014-06-21 11:52:35 <chichov> does the transaction have to be final?
176 2014-06-21 11:52:55 <chichov> (in the reference implementation)
177 2014-06-21 11:54:22 <chichov> nevermind, just found https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L504
178 2014-06-21 11:54:30 <chichov> does appear to be so
179 2014-06-21 11:54:57 <sipa> every transaction in a block must be final; this is a consensus rule
180 2014-06-21 11:55:28 <chichov> what about relaying?
181 2014-06-21 11:56:14 <chichov> standardness rules seems to deny relaying to non-final transactions, correct?
182 2014-06-21 11:56:55 <dsnrk> chichov: https://github.com/bitcoin/bitcoin/blob/b8b98d5642faf7b6acb88be9106a22512fc6020c/src/main.cpp#L504
183 2014-06-21 11:57:05 <gmaxwell> otherwise they make for a trivial DOS attack.
184 2014-06-21 11:57:32 <chichov> dsnrk: same link that I've posted, heh
185 2014-06-21 11:58:03 <dsnrk> chichov: if it's not standard it won't be relayed.
186 2014-06-21 11:58:19 <chichov> alright, that's clear
187 2014-06-21 11:59:03 <chichov> funny, so nLockTime can be 0 and then the sequence numbers can be chosen arbitrarily
188 2014-06-21 13:08:48 <SomeoneWeird> is there a doc somewhere with details on the p2p protocol?
189 2014-06-21 13:09:50 <gribble> Protocol specification - Bitcoin - Bitcoin Wiki: <https://en.bitcoin.it/wiki/Protocol_specification>; Protocol rules - Bitcoin - Bitcoin Wiki: <https://en.bitcoin.it/wiki/Protocol_rules>; API reference (JSON-RPC) - Bitcoin - Bitcoin Wiki: <https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)>
190 2014-06-21 13:09:50 <sipa> ;;google bitcoin protocol wiki
191 2014-06-21 13:10:05 <SomeoneWeird> c_c
192 2014-06-21 13:10:06 <sipa> (hardly upntondate or extensive)
193 2014-06-21 13:10:12 <sipa> up to date
194 2014-06-21 13:10:16 <SomeoneWeird> yeah
195 2014-06-21 13:10:21 <SomeoneWeird> nothing better than that?
196 2014-06-21 13:10:32 <gribble> bitcoin/bitcoin · GitHub: <https://github.com/bitcoin/bitcoin>; Bitcoin · GitHub: <https://github.com/bitcoin>; schildbach/bitcoin-wallet · GitHub: <https://github.com/schildbach/bitcoin-wallet>
197 2014-06-21 13:10:32 <sipa> ;;google github bitcoin
198 2014-06-21 13:10:38 <SomeoneWeird> yeah yeah :P
199 2014-06-21 13:10:43 <SomeoneWeird> thanks, heh
200 2014-06-21 13:11:00 <sipa> oh, the new dev documentation on bitcoin.org maybe
201 2014-06-21 13:11:31 <SomeoneWeird> links to the wiki page
202 2014-06-21 13:12:07 <sipa> https://bitcoin.org/en/developer-guide
203 2014-06-21 13:15:00 <SomeoneWeird> yeah, the protocol spec in that links to the wiki :)
204 2014-06-21 13:18:10 <sipa> right ok
205 2014-06-21 14:21:53 <Aquilano> Where would the world wide web be without domain name servers?
206 2014-06-21 14:24:28 <sipa> offtopic
207 2014-06-21 14:24:39 <Aquilano> lol
208 2014-06-21 14:24:49 <Aquilano> sorry perhaps it is
209 2014-06-21 14:25:14 <SpicyShibe> Aquilano: Then it would be like phones are now. You would need to look up the number, or be told it.
210 2014-06-21 14:28:29 <Aquilano> Imagine a resolution service that can shorthand bitcoin public keys, so instead of authorizing bitcoin to 1xkLLHW26h2AMKK9kWSqHhthtz24p6yvW, you couldauthorizing to "autobodyservice"
211 2014-06-21 14:29:37 <dabura667> Namecoin
212 2014-06-21 14:29:42 <sipa> payment protocol
213 2014-06-21 14:29:54 <dabura667> any other plethora of ways, really.
214 2014-06-21 14:30:15 <dabura667> it's just that adoption hasn't been taken up that much
215 2014-06-21 14:32:13 <Aquilano> No that I think of it, coinbase already does this with email addresses.
216 2014-06-21 14:32:32 <Aquilano> "I think"
217 2014-06-21 14:33:56 <mr_burdell> the problem with that is phishing and name squatting
218 2014-06-21 14:34:09 <dabura667> I personally think Bitcoin will eventually get to the point where we can have decentralized e-mail like aliases that can be chosen by the user, via Namecoin etc... It's possible now, just there doesn't seem to be a lot of movement in that direction. All people that tend to move towards the "making it easier for newbs" approach all go for centralized approaches. While Payment protocol is great, it still requires owning a server
219 2014-06-21 14:34:09 <dabura667> to serve up the certificates etc.
220 2014-06-21 14:34:35 <GAit> sipa: do you find it likely that a merchant would not want tx from prevouts that themselves have no confirms yet? has someone started thinking about how to tell in advance preferences?
221 2014-06-21 14:34:58 <Aquilano> I spent all day yesterday hitting the pavement and trying to educate local shop owners. My hope was to get them to seriously consider adopting bitcoin as a payment system. The biggest problem I encountered was the complexity of the public key.
222 2014-06-21 14:35:20 <mr_burdell> dabura667: but how many ppl are going to run namecoin nodes? If namecoin had an SPV client, it would help
223 2014-06-21 14:35:40 <GAit> Aquilano: do you think amex has to explain to merchant about this stuff? yet their services do use some public/private key mechanism
224 2014-06-21 14:35:51 <dabura667> yeah... a look-up only SPV for namecoin
225 2014-06-21 14:36:41 <GAit> Aquilano: I am not sure the right way to start a bitcoin conversation with merchant is with an introduction to cryptography
226 2014-06-21 14:36:47 <dabura667> mr_burdell: do you have to run a node to look it up?
227 2014-06-21 14:37:09 <mr_burdell> well, there are dns proxies, but then you trust the server
228 2014-06-21 14:37:10 <dabura667> So do .bit websites require viewers to run Namecoin nodes?
229 2014-06-21 14:37:16 <dabura667> oh ok
230 2014-06-21 14:37:24 <mr_burdell> like "dnschain"
231 2014-06-21 14:37:30 <dabura667> ic
232 2014-06-21 14:37:44 <Aquilano> GAit: lol, I didn't even scratch the surface of cryptography.
233 2014-06-21 14:38:01 <mr_burdell> it would be better to do lookups directly on the network, but i'm not sure if servers index it in a way that would work
234 2014-06-21 14:38:32 <mr_burdell> and then you would need to do the spv verification, which I'm not sure how that extends to namecoin
235 2014-06-21 14:39:04 <dabura667> hmm, maybe Hive etc. have it right. I mean, we all use e-mail clients like Gmail to obfuscate our friends' e-mail addresses anyways.
236 2014-06-21 14:39:20 <mr_burdell> have you looked at breadwallet for iphone?
237 2014-06-21 14:39:21 <dabura667> might as well just do the same and register addresses with Hive etc...
238 2014-06-21 14:39:30 <mr_burdell> i like that it doesn't even explain how it's rotating keys
239 2014-06-21 14:39:49 <GAit> Aquilano, you mentioned public key, maybe to avoid crypto you could have said something along the lines of IBAN/swift-like code :)
240 2014-06-21 14:39:55 <dabura667> yes, sounds great... currently jailbroken on 6.1.4 so can't download it
241 2014-06-21 14:40:03 <mr_burdell> right now, everyone has their own version of it though: coinbase, pheeva, hive, onename, nameid
242 2014-06-21 14:40:19 <mr_burdell> probably more
243 2014-06-21 14:40:29 <mr_burdell> greenaddress probably has one?
244 2014-06-21 14:40:48 <dabura667> I think we need a decentralized static address protocol that generates new keys every transaction... Stealth Addresses minus the stealth.
245 2014-06-21 14:41:11 <mr_burdell> well, would a bip32 pubkey chain work?
246 2014-06-21 14:41:26 <dabura667> security risk
247 2014-06-21 14:41:29 <mr_burdell> i guess you would get reuse once in a while if multiple people were paying you at once
248 2014-06-21 14:41:41 <mr_burdell> is it? just don't give out your private keys
249 2014-06-21 14:42:06 <dabura667> security risk #1 = if somehow they EVER got their hands on 1 of your private keys, all your money is gone.
250 2014-06-21 14:42:47 <dsnrk> look into stealth addresses. you should take this to #bitcoin, it's off topic for this channel.
251 2014-06-21 14:45:26 <mr_burdell> seems like usability of bitcoin is always offtopic
252 2014-06-21 14:46:07 <buZz> yes its offtopic here
253 2014-06-21 14:46:23 <mr_burdell> it's a development issue in my opinion
254 2014-06-21 14:46:41 <dabura667> This place is less of a "What should we do?" and more of a "How should we implement it in code?"
255 2014-06-21 14:47:33 <Aquilano> From what I can see at git, it seems more of "How can we make the code more reliable"
256 2014-06-21 14:48:57 <dabura667> Ok, so bitcoin-dev is basically /bitcoin/bitcoin git development discussion, and not helpdesk for SPV mobile clients etc...
257 2014-06-21 14:49:22 <dsnrk> yes. ambling topics about features you want are off topic.
258 2014-06-21 14:50:04 <dabura667> developer discussion for things besides /bitcoin/bitcoin...? Not ok?
259 2014-06-21 14:51:49 <dsnrk> assume that every core developer reads the entire log to make sure they haven't missed anything important. that's impossible if it's always full of whatever weird ideas people want others to write.
260 2014-06-21 17:02:54 <G_Qu> Afternoon everyone.
261 2014-06-21 17:04:10 <G_Qu> I was wondering if anyone could help me understand why I continually get the same JSON error prompt when I believe I'm following the correct format for createrawtransaction?
262 2014-06-21 17:04:20 <G_Qu> in bash
263 2014-06-21 17:18:29 <pigeons> G_Qu: p
264 2014-06-21 17:18:35 <pigeons> 0bin it
265 2014-06-21 17:19:11 <G_Qu> hi pigeons thanks for answering. i'm new to this, so i'm not sure how to do that :p
266 2014-06-21 17:19:52 <sipa> you go to 0bin, paste it, give the link here
267 2014-06-21 17:20:15 <G_Qu> oh haha sorry. i thought you were referring to a command in bash. one sec
268 2014-06-21 17:20:34 <jcorgan> is the contrib/debian setup used for anything officially?
269 2014-06-21 17:38:42 <G_Qu> pigeons: here it is http://0bin.net/paste/1BQd6u3D8qOsr+Uv#UDb0Oy863x+469xo5i3MuFHKGwH4NjOTis+y8r4XV/o=
270 2014-06-21 17:40:12 <sipa> G_Qu: paste the command you're sending; not the error you get
271 2014-06-21 17:48:30 <G_Qu> ok thank sipa