1 2013-11-15 00:00:58 <Luke-Jr> sipa: key id isn't any more honest, it's just wrong :p
2 2013-11-15 00:01:24 <Luke-Jr> there's nothing wrong with invoice id
3 2013-11-15 00:01:35 <sipa> not going to discuss this :)
4 2013-11-15 00:02:15 <Luke-Jr> only old addresses, with pre-HD wallets, can the address be said to be a key id of a sort
5 2013-11-15 00:03:40 <sipa> they're a hash of a public key
6 2013-11-15 00:03:45 <sipa> how is that not a key id?
7 2013-11-15 00:04:08 <sipa> and for P2SH, they're the hash of a bitcoin-script-public-key
8 2013-11-15 00:04:40 <sipa> invoice implies it's being used for an invoice, which is not true for e.g. change
9 2013-11-15 00:05:16 <Luke-Jr> well, I didn't mean change "addresses" should be referred to any more than they currently are
10 2013-11-15 00:05:24 <Luke-Jr> users should never be exposed to those
11 2013-11-15 00:05:51 <gulli> Wondering what is the best way to make BitcoinJ communicate with Bitcoind. Should I just implement my own RPC code or does BitcoinJ help you in anyway. At first glance it seems to me BitcoinJ has nothing you can use to connect to Bitcoind
12 2013-11-15 00:06:06 <sipa> gulli: the P2P protocol...?
13 2013-11-15 00:06:17 <sipa> Luke-Jr: to be clear: i wasn't talking about what we're exposing to users as transaction destination
14 2013-11-15 00:06:34 <Luke-Jr> sipa: well, that's what I'm talking about ;p
15 2013-11-15 00:06:40 <gulli> you meen I should connect to bitcoind localhost like it was a peer?
16 2013-11-15 00:06:43 <sipa> Luke-Jr: i was talking about the base58 strings that encode public key or script hashes
17 2013-11-15 00:06:46 <Luke-Jr> scriptPubKey or hashCheck works fine for the low-level terminology
18 2013-11-15 00:06:48 <sipa> gulli: it IS a peer
19 2013-11-15 00:06:59 <Luke-Jr> same thing
20 2013-11-15 00:07:08 <gulli> Yeah I know
21 2013-11-15 00:07:32 <Luke-Jr> base58 strings are only transaction destinations*, not low-level stuff (* not talking about or dismissing other non-address base58 use)
22 2013-11-15 00:07:39 <gulli> ok lol, yup it is kinda obvious now
23 2013-11-15 00:08:23 <sipa> Luke-Jr: a key can be used as the destination of a payment, in which case it's an address
24 2013-11-15 00:08:23 <sipa> Luke-Jr: here's how I see it: the bitcoin system internally has keys, and coins get assigned to keys (abstracting ecdsa-key vs bitcoin-script-key now)
25 2013-11-15 00:08:46 <sipa> but for example a change output is not a payment, it's only an assignment of a coin to a key
26 2013-11-15 00:09:06 <Luke-Jr> but the key isn't base58, and shouldn't be represented in base58..
27 2013-11-15 00:09:12 <sipa> fair enough
28 2013-11-15 00:09:22 <Luke-Jr> base58 only makes sense for addresses/invoiceids
29 2013-11-15 00:09:38 <sipa> right, ok, i was confusing things maybe
30 2013-11-15 00:10:02 <sipa> i wasn't talking about the base58 encoded strings themself, i was talking about the data we're currently encoding in those (=key hashes)
31 2013-11-15 00:10:16 <Luke-Jr> ah
32 2013-11-15 00:10:36 <sipa> anyway, what i suggest is that we stop using the term "address" for anything that isn't intended as a destination of a payment
33 2013-11-15 00:10:52 <sipa> and use "key id
34 2013-11-15 00:11:01 <sipa> " instead if we're talking about transaction outputs
35 2013-11-15 00:11:29 <sipa> with the payment protocol, an address could be a URL
36 2013-11-15 00:11:33 <Luke-Jr> ACTION prefers scriptPubKey there, but whatever
37 2013-11-15 00:11:54 <Luke-Jr> my only concern is destination-of-payment terminology, as that's what is presently problematic
38 2013-11-15 00:35:40 <owowo> Luke-Jr: pm?
39 2013-11-15 00:50:01 <lianj> any plans on starting testnet4 anytime soon?
40 2013-11-15 00:50:23 <gmaxwell> lianj: it's been mentioned. Do you see a need?
41 2013-11-15 00:51:09 <lianj> hm not really. just thought it could rip out all the useless blocks and only carry over real test txs :)
42 2013-11-15 00:51:32 <lianj> testnet3 is at 140k now and about 130mb - that not a real reason though
43 2013-11-15 00:55:08 <gmaxwell> lianj: there are a bunch of useful tests scattered in the chain now, so before we can do that we need to go gather up those test cases.
44 2013-11-15 00:55:22 <gmaxwell> lianj: if you happen to have a list of txn you've found interesting it would be helpful to keep track of them.
45 2013-11-15 01:00:07 <lianj> apart from filtering for all nonstandard and looking at them, with the risk of missing some standard but interesting ones, i don't really have a list. but totally agree that the good gist of testnet3 should be found and put into testnet4 and maybe some in blocktester first.
46 2013-11-15 01:23:55 <skinnkavaj> gmaxwell: Whats your opinion about Yifu and Mike Hearn madness?
47 2013-11-15 01:35:36 <BlueMatt> skinnkavaj: since when is mike involved in the coin validation stuff?
48 2013-11-15 01:35:45 <BlueMatt> aside from some posts supporting some kind of taint tracking system
49 2013-11-15 01:36:15 <skinnkavaj> taint tracking system haha
50 2013-11-15 01:36:20 <skinnkavaj> let me tell you how stupid that is
51 2013-11-15 01:36:25 <BlueMatt> I dont disagree
52 2013-11-15 01:36:32 <BlueMatt> but thats what its called...
53 2013-11-15 01:36:55 <gmaxwell> lianj: yea, anything testnet does that blocktester doesn't should be fixed.
54 2013-11-15 01:37:21 <skinnkavaj> Mike hearn must have lost it
55 2013-11-15 01:37:30 <skinnkavaj> Had a lot of respect for him
56 2013-11-15 01:37:46 <BlueMatt> skinnkavaj: unless you have a pointer to something he actually /did/, please stop now
57 2013-11-15 01:38:28 <skinnkavaj> he is supporting a system tracking coins
58 2013-11-15 01:39:17 <gmaxwell> This discussion isn't really productive.
59 2013-11-15 01:40:06 <skinnkavaj> It's very important that we don't start tracking dirty money, there is no dirty money. Only bad people.
60 2013-11-15 01:41:16 <Coincide_> Coins will be tracked, regardless of what the community thinks about it. Whether it's the NSA, FBI or companies selling consumer behavior data. The real issue isn't tracking, it's fungibility...that is making some coins worth more/less than others. The better question is, how can we guarantee fungibility through the protocol.
61 2013-11-15 01:43:06 <BlueMatt> skinnkavaj: if you bother to read the thread on the foundation forums, you find a reasonable discussion of the issues, including people being reasonable, vs the line of argument you're taking, which isnt to have a discussion, but only an argument
62 2013-11-15 01:46:32 <skinnkavaj> This post on Reddit explains how in 1749, a court sided with the Royal Bank of Scotland in its legal challenge to a request for such a blacklist. The RBS argument was that making money responsible for the acts of its previous holders would "render the Notes absolutely useless":
63 2013-11-15 01:46:33 <skinnkavaj> http://www.reddit.com/r/Bitcoin/comments/1le87j/bitcoin_core_dev_on_stolen_coins_and_transaction/cbycmhk
64 2013-11-15 01:47:15 <skinnkavaj> BlueMatt: Bitcoins should not be assessed according to where they have been. That would ruin their fungibility and require coin blacklists that would create a central authority.... But I guess this is what the Bitcoin Foundation wants?
65 2013-11-15 01:47:39 <BlueMatt> skinnkavaj: if you insist on not reading the thread which you're basing your accusations on, please go away
66 2013-11-15 01:49:40 <skinnkavaj> BlueMatt: Stop refering to some thread on some bitcoin foundation forum, tell me why i am wrong
67 2013-11-15 02:04:35 <MC1984> Coincide_: tracking and fingibility are inexorably linked
68 2013-11-15 02:51:03 <Skaag> I'm probably not the first person to consider this, so I figured I'd ask: Anyone thought about breaking down the database to small chunks that can be distributed among users, bittorrent style?
69 2013-11-15 02:51:25 <Skaag> with nodes offering 'tracker' services for chunks
70 2013-11-15 02:52:37 <BlueMatt> it already is broken into small chunks....
71 2013-11-15 02:52:48 <BlueMatt> and there are torrents around (look for bootstrap.dat)
72 2013-11-15 02:54:57 <Luke-Jr> sipa: is there already a spec for a recurring invoice id via HD derivation?
73 2013-11-15 04:30:53 <lianj> wth is https://coinvalidation.com/img/validated-small.png
74 2013-11-15 04:31:48 <kjj> probably a PNG, but the webserver will give the exact MIME type when you ask for the file.
75 2013-11-15 04:32:04 <lianj> â¦
76 2013-11-15 04:46:48 <Luke-Jr> kjj: lol
77 2013-11-15 06:20:38 <s4lt> Can anyone reference me to a place where target calculation is clearly explained.
78 2013-11-15 06:20:54 <Luke-Jr> I'm not sure it can be explained clearly and in detail
79 2013-11-15 06:21:23 <s4lt> I understand the concept well and its relation to difficulty, and that it is related to timestamps on blocks and number of blocks solved in a 2016 block period.
80 2013-11-15 06:21:37 <s4lt> But, I can't find a clear reference to the actual calculation.
81 2013-11-15 06:21:42 <Luke-Jr> the source code?
82 2013-11-15 06:22:14 <s4lt> Was looking for some discussion of it before I went there.
83 2013-11-15 06:22:20 <s4lt> But, yes, I'll check that out.
84 2013-11-15 06:23:53 <Luke-Jr> sipa: is it safe to share a hash of the master-public-key, to someone who might know some of the derived keys?
85 2013-11-15 06:23:58 <Luke-Jr> derived public keys*
86 2013-11-15 06:39:23 <davec> s4lt:
87 2013-11-15 06:40:03 <davec> https://github.com/conformal/btcchain/blob/master/difficulty.go is pretty well commented, might be worth a look
88 2013-11-15 06:40:31 <davec> calcNextRequiredDifficulty in particular
89 2013-11-15 06:40:51 <gmaxwell> Luke-Jr: why not just use the pubkey part of the master public key as the identifier?
90 2013-11-15 06:40:57 <gmaxwell> e.g. without the chaining code
91 2013-11-15 06:41:21 <gmaxwell> Luke-Jr: but yes, a hash is fine.
92 2013-11-15 06:41:34 <davec> or if you prefer bitcoind source: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1028-L1088
93 2013-11-15 06:42:13 <Luke-Jr> gmaxwell: I'm thinking for stats
94 2013-11-15 06:42:21 <gmaxwell> Luke-Jr: I guessed.
95 2013-11-15 06:44:01 <justusranvier> Luke-Jr: Is the bitcoind-9999 ebuild in the Bitcoin overlay abandoned? The sys_leveldb patch hasn't applied in forever.
96 2013-11-15 06:44:20 <Luke-Jr> justusranvier: it needs redoing.
97 2013-11-15 06:44:21 <BlueMatt> god, cc60b1f899ec0a69b7c3f25ddf32c4524096a9c5b01cbd84c6d0312a0c478984 (and others like it), broke at least 3 script implementations
98 2013-11-15 06:44:35 <Luke-Jr> justusranvier: and will probably need constant redoing every week or so until autoconf settles down
99 2013-11-15 06:44:42 <Luke-Jr> BlueMatt: ?
100 2013-11-15 06:45:12 <BlueMatt> I know at least 3 non-bitcoind script engines that marked that tx as invalid, though it is not
101 2013-11-15 06:45:24 <Luke-Jr> why?
102 2013-11-15 06:45:29 <gmaxwell> because good is stupid.
103 2013-11-15 06:45:33 <Luke-Jr> â¦
104 2013-11-15 06:45:43 <Luke-Jr> I mean technically
105 2013-11-15 06:45:53 <gmaxwell> Luke-Jr: some didn't think checksig could fail, or didn't gracefully handle its failure.
106 2013-11-15 06:45:57 <BlueMatt> it relies on OP_CHECKSIG pushing 0 on the stack when you try to validate a signature of 0 length
107 2013-11-15 06:46:12 <BlueMatt> several implementations missed it, because unlike other checksig failure modes, it pushes 0, not fails hard
108 2013-11-15 06:46:20 <Luke-Jr> lol
109 2013-11-15 06:46:23 <gmaxwell> (e.g. effectively treaded OP_CHECKSIG like OP_CHECKSIGVERIFY )
110 2013-11-15 06:46:41 <BlueMatt> (ie too-short stack and for multisig any kind of invalid parameters dont get 0-pushes, they fail the tx)
111 2013-11-15 06:47:06 <gmaxwell> which is actually a pretty horriffic bug, considering its totally valid to construct such a script. E.g. Luke had actually proposed a script that would have done that recently!
112 2013-11-15 06:47:28 <BlueMatt> yep, just goes to show that alternate script/validation engines are faar from being non-beta
113 2013-11-15 06:47:57 <Luke-Jr> gmaxwell: I wonder what would have happened if we deployed that
114 2013-11-15 06:48:05 <BlueMatt> sad, but thats just how the nature of this kind of thing is
115 2013-11-15 06:48:21 <gmaxwell> it required {a and b} or {a and c and d} or {b and c and d} and did some counting, including of checksig failures to get there.
116 2013-11-15 06:48:37 <Luke-Jr> btw, I guess I should post this here too just fyi: http://www.reddit.com/r/Bitcoin/comments/1qocdj/miners_time_to_deprioritisefilter_address_reuse/
117 2013-11-15 06:49:03 <gmaxwell> Luke-Jr: would have tried it on testnet, been happy with it, and then forked off those alt implementations when we tried a non- A&&B redeem on mainnet.
118 2013-11-15 06:49:12 <jgarzik> Luke-Jr, never be ashamed of upvote trolling, for a good cause!
119 2013-11-15 06:49:15 <gmaxwell> So no worse than what actually happened.
120 2013-11-15 06:50:04 <jgarzik> "if it's from luke, it can't be any good" -- rofl. I take it that is for conman and kano ;p
121 2013-11-15 06:50:18 <jgarzik> next time just write "conman, check this option"
122 2013-11-15 06:51:18 <jgarzik> BlueMatt, make sure that test case is in bitcoind's json tests
123 2013-11-15 06:51:26 <jgarzik> as the root of all test case data
124 2013-11-15 06:51:41 <BlueMatt> jgarzik: yes...I pushed that change to bitcoinj, just havent pushed it to bitcoind yet
125 2013-11-15 06:51:55 <BlueMatt> (it has a big fat TODO(Matt): Add more tests like this for MULTISIG, so I want to do that first)
126 2013-11-15 06:52:44 <Luke-Jr> jgarzik: there's a lot of trolls out there - I was hoping that would be a catchall for them
127 2013-11-15 07:01:30 <s4lt> davec: Thanks, great resource.
128 2013-11-15 07:47:38 <Plarkplark_> question on the new patch by Luke-Jr (good idea imho) - what happends if someone sends transaction (by accident f/a) to an empty already used address?
129 2013-11-15 07:47:42 <Plarkplark_> blackhole btc?
130 2013-11-15 07:49:36 <Luke-Jr> Plarkplark_: for now, nothing; it doesn't block anything, just delay it
131 2013-11-15 07:53:29 <Plarkplark_> ok. The idea is good though.
132 2013-11-15 07:55:10 <Plarkplark_> Maybe a) make Bitcoin-qt client warn you if address already contains coins (do not re-use address warning) and b) make the block delay increase in time. (1 block now, 2 blocks next month) to discurrage.
133 2013-11-15 08:00:02 <gmaxwell> Plarkplark_: so long as its only 15% of the hashpower the effect is not that agressive. e.g. even if it blocked reuse forever it would only make you fall to the next block 15% of the time.
134 2013-11-15 08:08:11 <Plarkplark_> still, this address registration crap is going to hurt the network/design/idea of bitcoin
135 2013-11-15 08:08:23 <Plarkplark_> Luke-Jr: +1
136 2013-11-15 08:10:07 <kuzetsa> it hurts fungibility to reuse addresses
137 2013-11-15 08:10:27 <kuzetsa> but blocking or throttling reused addresses hurts fungibility too
138 2013-11-15 08:10:45 <kuzetsa> oh wait, no I got that wrong
139 2013-11-15 08:10:57 <kuzetsa> reusing addresses doesn't hurt fungibility
140 2013-11-15 08:11:10 <kuzetsa> companies demanding registered addresses does, but that's another issue entirely
141 2013-11-15 08:11:32 <kuzetsa> companies / governments (either way)
142 2013-11-15 08:17:06 <Plarkplark_> so now what.
143 2013-11-15 08:29:15 <abrkn> should i be worried if importprivkey takes more than a minute?
144 2013-11-15 08:33:25 <K1773R> abrkn: did you specify rescan to false? if not it rescans the blockchain for missing transactions
145 2013-11-15 08:35:27 <gmaxwell> kuzetsa: I'd hope that it just takes very mild discouraging to switch 95% of the activity to non-reusing, and then a censors/whitelisters job is much harder... but we'll see.
146 2013-11-15 08:37:55 <wumpus> abrkn: no, by default it does a rescan which can take quite a while
147 2013-11-15 08:39:57 <bitnumus> my client is stuck on 26902
148 2013-11-15 08:40:13 <bitnumus> seems to have happened since i copied the blockchain elsewhere
149 2013-11-15 08:41:28 <bitnumus> restarted sorted it, but weird bug ?
150 2013-11-15 08:42:23 <bitnumus> no wonder it doesn't work on RPI if there is a bug/reason for it not working on a decent spec machine
151 2013-11-15 08:45:05 <BlueMattBot> Project Bitcoin build #457: FAILURE in 40 min: http://jenkins.bluematt.me/job/Bitcoin/457/
152 2013-11-15 08:53:03 <Plarkplark_> Luke-Jr: Could you make enforce fee on re-using addreses in time?
153 2013-11-15 08:53:43 <Luke-Jr> abrkn: you should note importprivkey is not safe on untrusted data
154 2013-11-15 08:55:38 <Luke-Jr> Plarkplark_: I don't know what you mean.
155 2013-11-15 08:57:57 <gmaxwell> Luke-Jr: he's suggesting additional fees for reuse.
156 2013-11-15 08:58:09 <Luke-Jr> oh
157 2013-11-15 08:58:38 <Luke-Jr> Plarkplark_: the code to deal with that is a mess, and fixing it would be a major effort that I don't really have time for :/
158 2013-11-15 08:58:51 <Luke-Jr> and implementing that kind of change on top of it as it is would be annoying too
159 2013-11-15 08:59:05 <Plarkplark_> ok bummer.
160 2013-11-15 08:59:06 <Luke-Jr> unless I do it a bit hacky
161 2013-11-15 09:21:34 <petertodd> Luke-Jr: the anti-addr-reuse patch mines the highest fee/kb tx if there are multiple conflicting right?
162 2013-11-15 09:29:25 <Luke-Jr> petertodd: not this one
163 2013-11-15 09:29:48 <petertodd> Luke-Jr: potential DoS attack there
164 2013-11-15 09:31:43 <gmaxwell> hah wallet bug
165 2013-11-15 09:31:47 <kinlo> even highest fee would introduce a dos attack no?
166 2013-11-15 09:31:56 <petertodd> kinlo: yes, but an expensive one!
167 2013-11-15 09:32:14 <kinlo> if you want to send someone 500 btc, I'd just keep sending 0.001 btc with fee
168 2013-11-15 09:32:21 <kinlo> true
169 2013-11-15 09:32:56 <gmaxwell> oh not not a bug.
170 2013-11-15 09:33:15 <petertodd> gmaxwell: yeah, just a pedantic academic break :P
171 2013-11-15 09:33:17 <gmaxwell> I was confused having several consecutive immature coins in a row in my wallet.
172 2013-11-15 09:33:36 <gmaxwell> petertodd: nah, I was talking to myself. your comments, yea, aware of that. not super exciting.
173 2013-11-15 09:34:05 <petertodd> gmaxwell: ...but it would be super-exciting if someone decided to attack my donation address that way, just saying...
174 2013-11-15 09:34:14 <gmaxwell> hahaha
175 2013-11-15 09:34:56 <kinlo> petertodd: well, if I'd attack you by sending the minimum amount, the cost I would make would be in mining fee, not in sending you money
176 2013-11-15 09:35:19 <petertodd> kinlo: but the attention would make me feel special
177 2013-11-15 09:35:38 <kinlo> you are special, didn't they teach you that in kindergarden? :)
178 2013-11-15 09:36:09 <petertodd> kinlo: nah, I was homeschooled
179 2013-11-15 09:40:56 <oneman> I think if coinvalidator says your coins are tainted, they could sell you a blow stamp to put on the transaction to cleanse it
180 2013-11-15 09:42:36 <Apocalyptic> $ bitcoind --deamon
181 2013-11-15 09:42:36 <Apocalyptic> Segmentation fault (core dumped)
182 2013-11-15 09:42:54 <Apocalyptic> interesting...
183 2013-11-15 09:43:05 <Arnavion> Spelling of daemon
184 2013-11-15 09:43:18 <Arnavion> But still
185 2013-11-15 09:43:37 <gmaxwell> Arnavion: what OS? what version of bitcoin built how by whom when?
186 2013-11-15 09:43:48 <Arnavion> Apocalyptic*
187 2013-11-15 09:43:50 <Apocalyptic> Arnavion, right
188 2013-11-15 09:44:11 <Apocalyptic> it's a port build on Freebsd 8.3 RELEASE
189 2013-11-15 09:45:15 <Apocalyptic> $ bitcoind --daemon
190 2013-11-15 09:45:15 <Apocalyptic> Bitcoin server starting
191 2013-11-15 09:45:20 <Apocalyptic> thanks Arnavion !
192 2013-11-15 09:45:36 <Arnavion> I'd still investigate the segfault though
193 2013-11-15 09:46:08 <Apocalyptic> I don't have time to play with it, I can send you the coredump if you want though
194 2013-11-15 09:46:27 <Arnavion> Not me, I'm an innocent bystander
195 2013-11-15 09:47:46 <Apocalyptic> i spoke too soon, looks like it crashed just after
196 2013-11-15 09:53:58 <Plarkplark_> what is best practice for compiling bitcoind on debian stable (wheezy) ?
197 2013-11-15 09:59:47 <JyZyXEL> is there a RPC command that lists all the receiving addresses?
198 2013-11-15 10:03:54 <JyZyXEL> from all accounts
199 2013-11-15 10:39:06 <melvster> happen accidentally when nodes running 0.7 were subtly incompatible
200 2013-11-15 10:39:06 <melvster> If a group of nodes decides on an even subtly different protocol than
201 2013-11-15 10:39:06 <melvster> Ryan Fugger on Bitcoin (today): Think about it this way: in order for Bitcoin to work,
202 2013-11-15 10:39:06 <melvster> there has to be a general global consensus on how the protocol works.
203 2013-11-15 10:39:06 <melvster> the rest, there could be a blockchain fork. We saw how this might
204 2013-11-15 10:39:07 <melvster> with the 0.8 nodes, and how it took global coordination of Bitcoin
205 2013-11-15 10:39:08 <melvster> nodes and leadership by the Bitcoin developers to avoid a fork. The
206 2013-11-15 10:39:10 <melvster> Bitcoin network is dependent on this meta-consensus of participating
207 2013-11-15 10:39:13 <melvster> nodes in order to keep functioning.
208 2013-11-15 10:39:33 <melvster> oops ... sorry for line breaks
209 2013-11-15 10:41:12 <melvster> there's been some questioning over solution to the double spend problem of consensus vs proof of work ...
210 2013-11-15 10:41:44 <gmaxwell> please take that ripple crap someplace else.
211 2013-11-15 10:41:46 <gmaxwell> :P
212 2013-11-15 10:44:37 <melvster> gmaxwell: read the text, there was not one mention of ripple ;) but as you wish ...
213 2013-11-15 10:44:49 <sipa> well, he's right
214 2013-11-15 10:45:01 <sipa> bitcoin's rules are determined by those that run the network
215 2013-11-15 10:45:06 <sipa> does that surprise anyone?
216 2013-11-15 10:45:41 <sipa> the software only implements the rules the system aims to enforce, and by using it, you agree to those rules
217 2013-11-15 10:45:57 <melvster> sipa: ben laurie wrote a paper about this too ... there's an element of longest chain wins and an element of meta consensus
218 2013-11-15 10:46:23 <gmaxwell> Ben laurie is a bum. He was unresponsive to any commentary or criticism about his paper.
219 2013-11-15 10:46:30 <sipa> http://bitcoin.stackexchange.com/questions/9986/how-is-a-hard-fork-resolved
220 2013-11-15 10:46:54 <sipa> melvster: the rule is: the longest _valid_ chain wins
221 2013-11-15 10:47:04 <sipa> if nodes disagree about what is valid, you have a hard fork
222 2013-11-15 10:47:09 <melvster> sipa: very good point, thanks for the clarification
223 2013-11-15 10:47:22 <sipa> and yes, the only way to solve that is meta-consensus if that's how you want to call it
224 2013-11-15 10:47:34 <sipa> consensus at a human level, rather than at a software level
225 2013-11-15 10:48:18 <melvster> sipa: but i sometimes wonder what would happen if there was a longer chain that was constructed in secret by some entity with massive computing power, and unleashed at some point ... what would we do? (I know that becomes less likely every day due to the hash rate increases)
226 2013-11-15 10:48:38 <sipa> do you mean a valid one or not?
227 2013-11-15 10:48:45 <melvster> sipa: yes a valid one
228 2013-11-15 10:48:57 <melvster> say they forked something from the genesis block or later
229 2013-11-15 10:49:06 <melvster> i know the genesis is hard coded
230 2013-11-15 10:49:24 <gmaxwell> melvster: well, it would prove that bitcoin could not continue in its current form so long as the situation remained static.
231 2013-11-15 10:49:28 <sipa> i'm not sure we could do much
232 2013-11-15 10:49:56 <gmaxwell> sure people could go muddle up their consenus manually to flip back and ignore it, but they could do it again.. or more importantly do short reorgs constantly on the tip of the chain.
233 2013-11-15 10:50:13 <gmaxwell> the long reorg would be easy to human reject but the short ones not so.
234 2013-11-15 10:50:18 <wumpus> the whole concept of proof of work would have to be changed
235 2013-11-15 10:51:09 <wumpus> if someone has that much computation power, and is willing to invest it in destroying things, then the idea of mining based proof of work is invalidated
236 2013-11-15 10:51:19 <gmaxwell> It's sort of like asking how do you protect the USD it china nukes washington and drives their tanks over fort knox. "You don't, you might give a heroic effortâ but you'll probably die trying."
237 2013-11-15 10:52:44 <gmaxwell> I'm sure some closed shell of bitcoin might remain, a couple of big companies who only let each other mine, swearing that they'll play fair (until they're forced not to)... or the like, but well, the result wouldn't have anything in common with the original vision except the name.
238 2013-11-15 10:53:06 <melvster> if one chain was clearly fraudulent and an attack, you could have a meta consensus to have a hard check point after the fork I guess ... but of course this would be highly controversial ...
239 2013-11-15 10:53:22 <gmaxwell> melvster: it would just be pointless, less than controversial.
240 2013-11-15 10:53:41 <stonecoldpat0> mailing list is on fire today
241 2013-11-15 10:53:43 <gmaxwell> You could do that, and they'll do it again. And next time the reorg will be so short that it _is_ controversial. Then what?
242 2013-11-15 10:54:13 <warren> Maybe sunnyking would license his solution ...
243 2013-11-15 10:54:19 <gmaxwell> lol
244 2013-11-15 10:54:32 <warren> other coins have purchased it from him. =P
245 2013-11-15 10:54:38 <gmaxwell> as I said: "the result wouldn't have anything in common with the original vision except the name"
246 2013-11-15 10:55:04 <gmaxwell> "Decenteralized systems are hard, lets go shopping^W^W^Wtake my signed blocks"
247 2013-11-15 10:55:19 <warren> You see, it isn't centralized because the users can opt out of following the broadcast checkpoint.*
248 2013-11-15 10:55:24 <warren> (just ignore what the pools do)
249 2013-11-15 10:55:41 <gmaxwell> and the merchants, and the lite clients and the ... :P
250 2013-11-15 10:55:51 <gmaxwell> warren: oh did sunnyking actually try to defend it to you?
251 2013-11-15 10:55:55 <sipa> "It isn't centralized because you can fork the software"
252 2013-11-15 10:56:11 <warren> gmaxwell: No, that's Feathercoin's excuse.
253 2013-11-15 10:56:16 <melvster> gmaxwell: such a fork would cost billions to achieve, if one was fended off, you could have a 'negative' checkpoint showing clients what we believe to be a fork attack, and let them decide, if you lost billions in your first attack, you'd probably not try again ... that said, you'd probably not try the first time with the hash rate what it is now
254 2013-11-15 10:56:31 <gmaxwell> melvster: it wouldn't (currently) cost billions to achieve.
255 2013-11-15 10:56:50 <melvster> gmaxwell: depends how far back you go?
256 2013-11-15 10:57:11 <gmaxwell> And yes, that kind of metaconsensus answer to something so laughably easy to exclude is why no one would bother with that particular attack, but the same capability could do attacks not so easy to fix.
257 2013-11-15 10:57:15 <gmaxwell> melvster: no it doesn't.
258 2013-11-15 10:57:15 <melvster> in the bitcoin paper satoshi shows it gets exponentially harder to attack the network
259 2013-11-15 10:57:23 <gmaxwell> (not currently)
260 2013-11-15 10:59:03 <melvster> if you forked at block 1, the cost would be enormous
261 2013-11-15 10:59:11 <gmaxwell> No, sadly it wouldn't e.
262 2013-11-15 10:59:17 <melvster> hmmm
263 2013-11-15 10:59:31 <gmaxwell> melvster: ~55.6 days of work for the network today to replace the whole chain.
264 2013-11-15 10:59:44 <sipa> http://bitcoin.sipa.be/powdays-50k.png
265 2013-11-15 10:59:52 <sipa> ACTION says: 42
266 2013-11-15 10:59:54 <gmaxwell> (at the current difficulty, so actually somewhat less, but I don't remember how to get a good hashrate estimate out of gribble)
267 2013-11-15 11:00:00 <gmaxwell> okay, there you go.
268 2013-11-15 11:00:01 <gribble> 4602522.39347
269 2013-11-15 11:00:01 <sipa> ;;nethash
270 2013-11-15 11:00:31 <gmaxwell> melvster: and now $3/gh miners are offered for sale...
271 2013-11-15 11:00:57 <melvster> wow that's cheap!
272 2013-11-15 11:01:28 <sipa> $3 per gram hour?
273 2013-11-15 11:01:29 <sipa> :p
274 2013-11-15 11:02:16 <gmaxwell> well, too be delivered when the stars align, the cheapest that is actually orderable with nearterm shipping is more like $20/gh.
275 2013-11-15 11:05:18 <melvster> but if you had that hashing power you're obviously better off mining ...
276 2013-11-15 11:05:41 <gmaxwell> melvster: maybe.
277 2013-11-15 11:06:15 <gmaxwell> melvster: were these folks? https://bitcointalk.org/index.php?topic=327767.0
278 2013-11-15 11:06:24 <gmaxwell> melvster: and what if you can short bitcoin? :P
279 2013-11-15 11:09:29 <melvster> true
280 2013-11-15 11:17:30 <melvster> gmaxwell: that's a very good point ... I've never really had an opinion on the price of btc, but other things being equal, I had preferred it to go DOWN as it gives more people a chance to participate ... actually we should want it to go UP, because it makes it less cost effective to attack, right?
281 2013-11-15 11:18:10 <gmaxwell> well, it pays people to more to mine. I think they're paid enough now, the difficulty needs to catch up to their preorders.
282 2013-11-15 11:32:57 <CodeShark> the biggest obstacle to more people participating isn't the price - it's the fact it's so complicated, expensive, tedious, and time consuming to process fiat transactions to and from exchanges
283 2013-11-15 11:37:16 <melvster> CodeShark: yes, but there's ATMs now so should be easy enough for most people
284 2013-11-15 11:41:11 <edcba> is it hard to buy btc from mtgox etc ?
285 2013-11-15 11:41:44 <CodeShark> processing a USD deposit or withdrawal is a less-than-wonderful experience
286 2013-11-15 11:43:50 <CodeShark> the only thing the exchanges are currently any good for is speculating
287 2013-11-15 11:44:05 <CodeShark> and even then, there's a lot to be desired :)
288 2013-11-15 11:48:33 <melvster> CodeShark: exchanges serve another purpose ... the last traded price that people use to calculate a conversion rate for merchants
289 2013-11-15 13:50:40 <BlueMattBot> Project Bitcoin build #458: FIXED in 45 min: http://jenkins.bluematt.me/job/Bitcoin/458/
290 2013-11-15 13:50:40 <BlueMattBot> Yippie, build fixed!
291 2013-11-15 14:12:09 <SomeoneWeird> who broke it!
292 2013-11-15 14:26:18 <wumpus> it wasn't really broken AFAIK, seems that there was a pull tester failure
293 2013-11-15 14:40:41 <Plarkplark_> is this legit? https://bitcointalk.org/index.php?topic=334520.0
294 2013-11-15 14:40:44 <Plarkplark_> Gavin?
295 2013-11-15 14:40:55 <Plarkplark_> gavinandresen:
296 2013-11-15 14:40:56 <Plarkplark_> ?
297 2013-11-15 14:43:21 <_ingsoc> I highly doubt that's real.
298 2013-11-15 14:43:34 <TD> lol
299 2013-11-15 14:43:52 <TD> "leak" from a forum anyone can view by joining the organisation
300 2013-11-15 14:44:01 <_ingsoc> "Mike Hearn should be casted away into oblivion." xD
301 2013-11-15 14:44:44 <wumpus> oh god
302 2013-11-15 14:44:46 <TD> i'm sure it's just an html zip of posts from the forum
303 2013-11-15 14:45:48 <_ingsoc> TD: That's definitely a guilty mind speaking.
304 2013-11-15 14:45:51 <wumpus> is there some hallucinogen in the air today? it's as if everyone is on drugs
305 2013-11-15 14:46:05 <TD> i guess some of them actually are
306 2013-11-15 14:46:40 <wumpus> mikehearn is corrupted! we need a new blockchain!
307 2013-11-15 14:46:53 <t7> lol
308 2013-11-15 14:47:06 <sipa> we need to hardfork him
309 2013-11-15 14:47:46 <wumpus> THEY are destroying the sacred work of satoshi!
310 2013-11-15 14:48:00 <TD> it's too bad that there aren't any other people researching these topics openly (i know it happens genuinely "behind the scenes", e.g. the people approaching sarah). but then you see all the personal attacks that get posted to these threads
311 2013-11-15 14:48:01 <Musk> O_o
312 2013-11-15 14:48:09 <petertodd> sipa: what's the term where you take part of the blockchain where they make good bug fixes and write a nice client library and leave the evil bits behind? :P
313 2013-11-15 14:48:10 <TD> and it's not really surprising
314 2013-11-15 14:49:33 <wumpus> lol petertodd
315 2013-11-15 14:49:36 <helo> just about everyone is failing to realize this was just a discussion starter, rather than a discussion prompt... it amounts to subconscious organic censorship attempts :/
316 2013-11-15 14:49:51 <helo> err... "rather than an endorsement"
317 2013-11-15 14:50:50 <petertodd> helo: sometimes a discussion starter smells rather like endorsement: http://www.reddit.com/r/Bitcoin/comments/1qnsng/mike_hearn_did_not_push_for_blacklists/cdeoq4f
318 2013-11-15 14:51:44 <TD> no, it doesn't. it "smells" like that to people who can't read and/or deliberately want to create trouble.
319 2013-11-15 14:52:05 <TD> petertodd: like that john dillon character. what an asshole this guy is. half the time i see him post he's just trying to create outraged megathreads.
320 2013-11-15 14:52:26 <TD> petertodd: i'd love to meet him in person one day and tell him to stop being a politician and write code
321 2013-11-15 14:52:58 <helo> people will believe anything if they are afraid it might be true... a dev with bad intentions is pretty frightenting.
322 2013-11-15 14:53:30 <wumpus> TD: I've noticed that too, he's always the one that tries to get mobs together with torches and pitchforks, like back then with the minimum/dust change
323 2013-11-15 14:53:37 <t7> wow asrock bitcoin mining mobo
324 2013-11-15 14:53:52 <petertodd> helo: yup, only natural to see that kind of thing blow up. But equally, people need to understand that Bitcoin, if used properly, shouldn't have to be vulnerable to even outright malicious devs.
325 2013-11-15 14:53:53 <wumpus> I don't think I've ever seen a pull request by him though
326 2013-11-15 14:54:18 <petertodd> wumpus: lol, jdillon's idea of coding is to pay someone else to do it :P
327 2013-11-15 14:54:26 <TD> petertodd: have you met him?
328 2013-11-15 14:54:38 <petertodd> wumpus: though he really seems to understand the theory well
329 2013-11-15 14:54:56 <petertodd> TD: nope
330 2013-11-15 14:55:00 <wumpus> petertodd: well paying people to do things is better than just opening topics and complaining, which tbh is the only thing I've seen from him
331 2013-11-15 14:55:16 <TD> you signed his key, you're the only one who has, actually
332 2013-11-15 14:55:24 <TD> i assumed you'd done a key signing party
333 2013-11-15 14:55:58 <petertodd> TD: I also signed michagogo's key...
334 2013-11-15 14:56:19 <wumpus> petertodd: yes, he understands it quite well, unlike the forum trolls he tries to recruit to his 'cause' whatever it may be :/
335 2013-11-15 14:56:30 <helo> at least the counterarguments to white/black-listing are fresh now, and extant for all of the new users we've taken on
336 2013-11-15 14:56:36 <petertodd> wumpus: well, complaining can be effective. Dark Wallet's getting momentum, and this latest round of controversy is helping.
337 2013-11-15 14:56:57 <wumpus> so, what is another wallet app going to change?
338 2013-11-15 14:57:14 <petertodd> helo: yup, and adam back improved on them IMO - his latest posts are convincing even without any desire for privacy
339 2013-11-15 14:57:41 <petertodd> wumpus: dark wallet itself? doesn't excite me. But their inititives to figure out what's the right way to add privacy to wallets, that's worthwhile.
340 2013-11-15 14:57:44 <wumpus> what's so private about it, they'll implement coinjoin? we can implement coinjoin in bitcoin-qt too
341 2013-11-15 14:57:56 <petertodd> wumpus: Hive's paying my expenses to go to the Dec meetup
342 2013-11-15 14:58:05 <helo> it's a browser plugin, so it has that going for it, at least
343 2013-11-15 14:58:13 <TD> complaining is not effective. coding is effective. both you and dillon should do a lot more of it.
344 2013-11-15 14:58:15 <petertodd> wumpus: absolutely, and IMO dark wallet should have done that - smarter politically, but whatever
345 2013-11-15 14:58:35 <petertodd> but I'll bbl
346 2013-11-15 15:03:51 <TD> wumpus: AFAICT dark wallet doesn't really have any privacy features at the moment, except SSL, but then that leads to the question of who you are encrypting to
347 2013-11-15 15:05:05 <helo> an spv wallet with built in tor would be kind of neat
348 2013-11-15 15:05:17 <TD> well, bitcoinj is about to get a new network stack that supports SOCKS
349 2013-11-15 15:05:31 <TD> so you could use tor with apps based on that then. although it doesn't currently have any support for the hidden-services-as-ipv6 trick
350 2013-11-15 15:05:37 <helo> the tor part needs to be built in... almost nobody is going to install/configure tor
351 2013-11-15 15:05:47 <helo> particularly windows users
352 2013-11-15 15:05:47 <TD> that's hard. tor isn't actually a library. it's only provided as an app.
353 2013-11-15 15:06:04 <c0rw1n> so we'd end up with one torlib for each package? :(
354 2013-11-15 15:06:15 <helo> well, at least that makes implementation mistakes less likely
355 2013-11-15 15:06:21 <TD> also it's not obviously a clear win. you scramble traffic on the wire, but then you end up with a giant MITM between you and the network. or if you use hidden services, they could all be running on the same box.
356 2013-11-15 15:06:43 <TD> bitcoin has the /16 rule to try and make sybils slightly more expensive. it's not great but it's better than nothing
357 2013-11-15 15:06:55 <TD> tor breaks that heuristic. so .... you gain some things and lose some things
358 2013-11-15 15:07:40 <helo> hmm... yeah, ssl-by-default would be nice, but peers won't have CA-issued certs even :
359 2013-11-15 15:09:19 <TD> yeah. SSL can be useful for things like connecting over wifi and stuff. but it's complicated, you have to remember keys and figure out what to do if suddenly you can't reach any nodes except new ones you never saw before (MITM).
360 2013-11-15 15:09:33 <TD> and if the NSA were to start 10,000 nodes, who are we to say they shouldn't do that? central control rears its head once more.
361 2013-11-15 15:09:59 <TD> it's a lot more complicated than for websites where it's a clear beneft
362 2013-11-15 15:10:22 <TD> stuff like bloom filtering is better because then the remote node learns fewer secrets.
363 2013-11-15 15:10:41 <TD> and it doesn't matter if the node is a MITM (in a p2p network there isn't even a clear "middle" to begin with)
364 2013-11-15 15:23:21 <wumpus> helo: yes, something like a bitcoin tor bundle would be nice, similar to the tor browser bundle
365 2013-11-15 15:23:23 <TD> lol: http://stackoverflow.com/questions/4456438/how-can-i-pass-the-string-null-through-wsdl-soap-from-actionscript-3-to-a-co?rq=1
366 2013-11-15 15:24:07 <wumpus> LOL
367 2013-11-15 15:24:19 <roconnor> okay, I'm going to ask a naive question: What' the purpose of the P2P network? Why not have clients register with all the mining operations and send transactions to them and get block from them?
368 2013-11-15 15:24:28 <roconnor> I suspect I've forgotten something.
369 2013-11-15 15:25:17 <roconnor> I certainly understand the historical purpose when almost everyone was a miner.
370 2013-11-15 15:25:49 <TD> miners come and go
371 2013-11-15 15:27:07 <wumpus> the purpose of the P2P network is to distribute transactions as well as share the blockchain, if only miners were full nodes then they'd have to take the blockchain distribution on their shoulders as well
372 2013-11-15 15:27:43 <TD> roconnor: are you the roconnor who implemented bitcoin in haskell?
373 2013-11-15 15:27:48 <roconnor> yes
374 2013-11-15 15:28:02 <TD> i thought i recognized your nick. then i suspect your question is rhetorical and the start of an interesting train of thought
375 2013-11-15 15:28:32 <TD> as the reason it exists is obvious. so, i suspect you are thinking about other ways to do the same thing?
376 2013-11-15 15:29:39 <roconnor> That's a good way of looking at my question. If we can identify exactly what we need from the P2P network, there may be other easier ways of doing the same.
377 2013-11-15 15:30:20 <roconnor> using a P2P network to distribute transactions seems weird to me.
378 2013-11-15 15:31:12 <danneu> what do you propose and how would you coordinate trust
379 2013-11-15 15:31:17 <roconnor> I suppose it could be useful if you want to start spending your unconfirmed income, but still even all you really need is communiation between sender, receiver and the miners.
380 2013-11-15 15:32:00 <wumpus> but if every client would connect directly to the miners, wouldn't they become overloaded?
381 2013-11-15 15:32:02 <sipa> roconnor: as a receiver you want to be able to validate an incoming payment, which pretty much means being aware of all existing blocks, and preferrably some part of unconfirmed transactions
382 2013-11-15 15:32:30 <roconnor> danneu: I propose that miners advertise their serives, and clients configure there servers to connect to all miners that they have accepted solicitations from.
383 2013-11-15 15:32:47 <sipa> maybe that's a model we'll need in the future
384 2013-11-15 15:33:11 <roconnor> danneu: clients send transactions to all the miners they have registered and receives new blocks from said miners.
385 2013-11-15 15:33:33 <sipa> roconnor: it also removes the ability to mine anonymously
386 2013-11-15 15:34:43 <TD> well that's pretty much the P2P network with miner IPs in the coinbase, isn't it
387 2013-11-15 15:34:48 <TD> which was proposed a bunch of times
388 2013-11-15 15:34:54 <TD> i'd like IP multicast, if it worked. but it doesn't ...
389 2013-11-15 15:35:57 <roconnor> sipa: Interesting point, how do anonymous miners post their new blocks currently?
390 2013-11-15 15:36:19 <danneu> broadcast
391 2013-11-15 15:36:32 <sipa> tor is certainly one option, but it impacts propagation speed
392 2013-11-15 15:36:47 <roconnor> oh, toring
393 2013-11-15 15:36:54 <roconnor> oh, torring into the P2P network?
394 2013-11-15 15:37:10 <sipa> otherwise, just connect to some random nodes
395 2013-11-15 15:37:18 <sipa> you don't need a discoverable IP address to mine
396 2013-11-15 15:37:24 <sipa> yes
397 2013-11-15 15:37:29 <wumpus> yes, they can connect to any node (through tor or some other proxy system) and push the block
398 2013-11-15 15:37:46 <roconnor> well you divulge your IP when you connect to random nodes in the P2P network.
399 2013-11-15 15:38:17 <wumpus> you divulge *some* ip address, but it doesn't have to be one that you're reachable on
400 2013-11-15 15:38:21 <c0rw1n> you'd divulge the IP of yout tor exit node
401 2013-11-15 15:38:24 <roconnor> sure sure
402 2013-11-15 15:38:36 <sipa> or to hidden service bitcoin nodes
403 2013-11-15 15:38:36 <sipa> which are connected to the public P2P network
404 2013-11-15 15:39:02 <phantomcircuit> sipa, indeed having one is probably not a good idea
405 2013-11-15 15:39:04 <phantomcircuit> roconnor, if you're worried about that it's fairly trivial to setup a node on another server that you -connect to
406 2013-11-15 15:39:07 <phantomcircuit> sipa, not optimal for a miner given that propagation times would take an instant hit of ~500ms
407 2013-11-15 15:39:45 <roconnor> phantomcircuit: connecting to another server doesn't really help anonymity. But anyhow, Tor is a satisfatory answer.
408 2013-11-15 15:40:01 <phantomcircuit> roconnor, sure it does if it's your server held anonymously
409 2013-11-15 15:40:15 <phantomcircuit> unless you're worried about someone tapping the line
410 2013-11-15 15:40:33 <phantomcircuit> but then you're worried about the NSA which is probably a global observer that tor doesn't effectively protect against
411 2013-11-15 15:42:09 <roconnor> phantomcircuit: well, I'm not an anonymous miner, but I would be worried about investigation leading from that server's operator back to me via subpoena.
412 2013-11-15 15:42:37 <TD> an investigation into what?
413 2013-11-15 15:42:40 <phantomcircuit> roconnor, if you're worried about that then the 500ms tor delay is not significant
414 2013-11-15 15:42:49 <roconnor> right
415 2013-11-15 15:42:51 <phantomcircuit> TD, i assume he's talking about if mining becomes illegal
416 2013-11-15 15:43:03 <phantomcircuit> which is like all kinds of unlikely
417 2013-11-15 15:43:09 <TD> i think then you have bigger problems than TCP/IP
418 2013-11-15 15:43:15 <TD> given the need for special hardware, etc
419 2013-11-15 15:43:38 <phantomcircuit> not to mention that it's exceptionally unlikely to be illegal everywhere
420 2013-11-15 15:46:42 <roconnor> sipa: still seems kinda weird to have an entire p2p network to support anonymous miners.
421 2013-11-15 15:47:21 <sipa> i guess that's not the original reason
422 2013-11-15 15:47:42 <TD> it seems simpler than a lot of alternatives
423 2013-11-15 15:47:45 <roconnor> I've inferred that the original reason was that everyone was going to be a miner.
424 2013-11-15 15:48:15 <TD> no, i don't think so
425 2013-11-15 15:48:17 <helo> and that we want to capitalize on the whole "information is easy to share, hard to stifle"
426 2013-11-15 15:48:36 <sipa> having any kind of 0-conf security also relies on being able to broadcast, which i think was also a reason initially
427 2013-11-15 15:48:41 <TD> the model is "everyone knows all transactions"
428 2013-11-15 15:48:54 <TD> the most obvious way to do that is p2p broadcast
429 2013-11-15 15:49:02 <TD> then you need to order the broadcasts canonically, hence, mining
430 2013-11-15 15:50:58 <roconnor> TD: I don't think I follow your argument, If we need transactions ordered by miners, why do we still need to use a p2p network to broadcast unordered transactions?
431 2013-11-15 15:51:40 <sipa> roconnor: unconfirmed transaction security relies on the network (not just miners, which may have different incentives) knowing transactions
432 2013-11-15 15:51:48 <sipa> roconnor: even though i doubt that is enforcable long-term
433 2013-11-15 15:51:48 <TD> right. unconfirmed transactions are useful
434 2013-11-15 15:52:02 <TD> also, what's the alternative again? some complicated registration process?
435 2013-11-15 15:52:05 <roconnor> oh okay
436 2013-11-15 15:52:16 <TD> it doesn't seem better
437 2013-11-15 15:52:52 <roconnor> TD: I can't be easily syblied if I am only connecting to "known" people rather than random people.
438 2013-11-15 15:53:10 <sipa> roconnor: you can still connect to known trusted peers
439 2013-11-15 15:53:10 <TD> you can of course still do that with a p2p protocol. the android wallet even has a trusted node feature
440 2013-11-15 15:53:13 <TD> though it's a bit buggy
441 2013-11-15 15:53:14 <roconnor> sipa: I know
442 2013-11-15 15:53:27 <sipa> a single honest peer is enough to avoid sybil
443 2013-11-15 15:53:33 <roconnor> I'm quite pleased that I can personally implement my idea within the current framework.
444 2013-11-15 15:54:28 <roconnor> okay, so people like unconfirmed transactions.
445 2013-11-15 15:54:36 <roconnor> That is a pretty good reason... I guess
446 2013-11-15 15:54:37 <jgarzik> speaking of, my satellite project still hovers in the background. I think I might get it properly spec'd out.
447 2013-11-15 15:54:44 <sipa> roconnor: i think people like them more than they should
448 2013-11-15 15:55:03 <sipa> roconnor: but i think it is a reason of why we p2p model was chosen initially
449 2013-11-15 15:55:13 <roconnor> sipa: thanks
450 2013-11-15 15:55:17 <roconnor> thanks everyone
451 2013-11-15 15:55:33 <roconnor> Something to think about.
452 2013-11-15 15:55:35 <helo> people like unconfirmed transactions because they are the first layer of protection against double spends, aren't they?
453 2013-11-15 15:55:51 <TD> roconnor: what is your idea?
454 2013-11-15 15:56:28 <roconnor> TD: only connect to miners that you want to do business with.
455 2013-11-15 15:59:15 <danneu> roconnor: so, directly to some btcguild/ghash.io coordination point?
456 2013-11-15 15:59:22 <helo> if someone only connected to miners, and those miners didn't broacast the transactions they received, it would take a lot longer for an individual to begin to gain confidence that a tx to them is likely to be confirmed
457 2013-11-15 16:01:04 <helo> do spv nodes verify that they receive each transaction to them from all of the nodes they connect to?
458 2013-11-15 16:01:43 <helo> or at least that they dont receive conflicting txes
459 2013-11-15 16:02:07 <TD> bitcoinj records how many peers announced a tx yes
460 2013-11-15 16:02:19 <TD> and it has some code to handle conflicts. that code is a bit incomplete/buggy but the API is there
461 2013-11-15 16:02:32 <TD> the android wallet will highlight double-spent/dead/conflicting transactions in red and put a warning next to them
462 2013-11-15 16:02:43 <TD> though i don't think andreas tests this functionality much so it could be broken by now
463 2013-11-15 16:03:59 <helo> or if they are only received by one peer? i wonder what's normal percentage of peers to see eventually-confirmed transactions from.
464 2013-11-15 16:04:38 <helo> received *from one peer
465 2013-11-15 16:06:42 <TD> whenever i use android wallet, i tend to see all peers announce
466 2013-11-15 16:13:03 <petertodd> roconnor: keep in mind that without a P2P layer distributing transactions you get centralization pressure where larger miners get more fees because people don't bother sending txs to small ones; nasty problem
467 2013-11-15 16:15:13 <petertodd> roconnor: re: sybil, one of the good things about electrum, is that you connect to electrum servers with relatively well known identities, so anonymous sybil's aren't a risk. Electrum also connects to multiple servers to fetch block headers, and verifies transactions SPV style - though it'd be good if electrum clients also participated in the P2P relay network as another source of header data
468 2013-11-15 16:18:58 <jgarzik> gah. initial wallet creation looks like it syncs the disk for each key generated.
469 2013-11-15 16:19:10 <jgarzik> or big keypool refill
470 2013-11-15 16:19:34 <petertodd> jgarzik: ha, explains why making 10k keys takes so long...
471 2013-11-15 16:19:40 <Belxjander> jgarzik: it buids and writes each key sequentially? not as a complete complex object chain in memory first ?
472 2013-11-15 16:19:51 <phantomcircuit> jgarzik, yeah it does i always create my giant wallets on a tmpfs and then copy them
473 2013-11-15 16:20:16 <phantomcircuit> Belxjander, each key is it's own key/value pair in the db
474 2013-11-15 16:20:18 <phantomcircuit> so no
475 2013-11-15 16:20:43 <jgarzik> Belxjander, it just doesn't need to sync BDB for each key, just at the end of the series
476 2013-11-15 16:20:51 <jgarzik> all other operations are valid and necessary
477 2013-11-15 16:21:02 <jgarzik> BDB transactions work fine for this
478 2013-11-15 16:21:13 <phantomcircuit> jgarzik, for the most part im not sure it really matters, how often are people actually generating huge keypools?
479 2013-11-15 16:21:25 <phantomcircuit> otoh if it's easy to fix
480 2013-11-15 16:21:45 <Belxjander> jgarzik: that is what I would think is true too
481 2013-11-15 16:23:12 <jgarzik> phantomcircuit, nod
482 2013-11-15 16:23:41 <jgarzik> hum
483 2013-11-15 16:23:49 <jgarzik> 'keypoolrefill new-size' is now broken
484 2013-11-15 16:24:48 <jgarzik> no, it does, I'm just an idiot.
485 2013-11-15 16:26:40 <phantomcircuit> jgarzik, heh i was about to say
486 2013-11-15 18:26:01 <shamoon> i'm trying to modify the difficulty of 1 in the source code to something easier. i think it's: static CBigNum bnProofOfWorkLimit(~uint256(0) >> 32);
487 2013-11-15 18:26:07 <shamoon> that sets the initial difficulty
488 2013-11-15 18:26:56 <ryan-c> https://github.com/brainwallet/brainwallet.github.com/pull/27 < brainwallet.org hates security.
489 2013-11-15 18:48:00 <BlueMatt> shamoon: try regtest mode
490 2013-11-15 18:49:20 <shamoon> i'm using an older source
491 2013-11-15 18:49:21 <shamoon> without regtest
492 2013-11-15 18:49:28 <shamoon> trying to understand the mechanics of the code
493 2013-11-15 18:49:33 <BlueMatt> theres a patch for that lying around somewhere
494 2013-11-15 18:49:58 <shamoon> is that where the initial difficulty is set?
495 2013-11-15 18:50:02 <shamoon> bnProofOfWorkLimit?
496 2013-11-15 18:50:07 <BlueMatt> yea, iirc
497 2013-11-15 18:50:17 <BlueMatt> it changes what "diff1" is defined as
498 2013-11-15 18:50:20 <shamoon> high is easy or low?
499 2013-11-15 18:50:40 <shamoon> it's using all 1's and shifting right
500 2013-11-15 18:50:42 <BlueMatt> if you shift less, it gets easier
501 2013-11-15 18:50:47 <shamoon> is that the target or diff?
502 2013-11-15 18:50:49 <shamoon> gotcha
503 2013-11-15 18:50:53 <shamoon> so >> 1 will be SUPER easy
504 2013-11-15 18:50:56 <BlueMatt> yep
505 2013-11-15 18:50:59 <shamoon> thanks!
506 2013-11-15 18:51:01 <BlueMatt> (thats what regtest mode uses)
507 2013-11-15 18:51:15 <shamoon> so then i should be able to mine almost instantly
508 2013-11-15 18:51:18 <shamoon> welll.. at least faster
509 2013-11-15 18:51:23 <shamoon> starting from the genesis
510 2013-11-15 18:51:27 <BlueMatt> until the first retarget, yes
511 2013-11-15 18:51:42 <shamoon> static const int64 nTargetSpacing = 1 * 60;
512 2013-11-15 18:51:58 <shamoon> for faster blocks
513 2013-11-15 18:52:48 <BlueMatt> that will keep diff down on retargets, if you set it low, yes
514 2013-11-15 18:53:00 <shamoon> awesome sauce
515 2013-11-15 18:53:26 <shamoon> weird - i've been running for like 10 min and still no blocks
516 2013-11-15 18:53:43 <shamoon> 3.5MH/s
517 2013-11-15 18:53:55 <BlueMatt> if you shift 1 you can get a block with 1H/s
518 2013-11-15 18:54:05 <shamoon> static CBigNum bnProofOfWorkLimit(~uint256(0) >> 1);
519 2013-11-15 18:54:06 <BlueMatt> (you literally get a block 1 out of every 2 hashes...)
520 2013-11-15 18:54:09 <shamoon> with that, right?
521 2013-11-15 18:54:19 <shamoon> that's what i would have thought - but alas
522 2013-11-15 18:54:21 <shamoon> not happening
523 2013-11-15 18:54:39 <BlueMatt> your mining software may be confused
524 2013-11-15 18:54:44 <BlueMatt> is probably confused, that is
525 2013-11-15 18:54:51 <shamoon> confused?
526 2013-11-15 18:54:55 <shamoon> by what?
527 2013-11-15 18:55:04 <BlueMatt> mining software doesnt understand a really easy powlimit
528 2013-11-15 18:55:10 <BlueMatt> its designed for the standard powlimit
529 2013-11-15 18:55:13 <BlueMatt> use the built-in miner
530 2013-11-15 18:55:20 <shamoon> i am using the built in
531 2013-11-15 18:55:23 <shamoon> setgenerate true
532 2013-11-15 18:55:34 <BlueMatt> hmm, well I dont know
533 2013-11-15 18:55:57 <shamoon> static CBigNum bnProofOfWorkLimit(~uint256(0));
534 2013-11-15 18:56:01 <shamoon> will literally always hash
535 2013-11-15 18:56:06 <shamoon> to something that works
536 2013-11-15 18:56:07 <shamoon> right?
537 2013-11-15 18:56:11 <BlueMatt> in theory
538 2013-11-15 18:56:16 <BlueMatt> before first retarget, yes
539 2013-11-15 18:57:20 <shamoon> and my first regarget would happen in 2014 blocks
540 2013-11-15 18:57:45 <BlueMatt> yes
541 2013-11-15 18:57:50 <shamoon> well - 20,000 blocks in my case
542 2013-11-15 18:57:54 <shamoon> since i have a 1 min block