1 2014-06-13 02:41:03 <Luke-Jr> if I have a pre-compressedkey wallet.db, will upgrading it void the keypool?
2 2014-06-13 02:41:12 <Luke-Jr> sipa: ^
3 2014-06-13 04:33:14 <aphoriser> Ang1 have any idea why bdb is in th mix
4 2014-06-13 04:33:17 <aphoriser> ?
5 2014-06-13 04:35:55 <aphoriser> Just trying to understand the original rational... any RDMS + licensing perhaps? - it just seems like over kill for is seemingly a simple document model.
6 2014-06-13 04:36:07 <aphoriser> what is*
7 2014-06-13 04:52:30 <Luke-Jr> aphoriser: bdb is not a RDMS
8 2014-06-13 04:59:32 <aphoriser> Luke-Jr, I know that I ment perhaps they thought of its future processing / reuse?.... as I said I am looking for a justification why simple / raw serialised io would not be as good?
9 2014-06-13 05:09:01 <Luke-Jr> aphoriser: bdb was originally used for 2 different things. now just the wallet. the wallet plans to migrate away eventually aslo
10 2014-06-13 05:09:03 <Luke-Jr> also*
11 2014-06-13 07:00:40 <sipa> Luke-Jr: not afaik
12 2014-06-13 07:01:10 <Luke-Jr> hrm, wonder how I can get a compressed pubkey then :x
13 2014-06-13 07:12:37 <michagogo> Luke-Jr: reencrypt the wallet
14 2014-06-13 07:12:43 <michagogo> That voids the pool
15 2014-06-13 07:12:53 <michagogo> Or just make a new wallet
16 2014-06-13 07:15:19 <sipa> if it's encrypted, it already flushed the keys it had before
17 2014-06-13 07:15:26 <sipa> and you don't unencrypt/reencrypt
18 2014-06-13 07:26:37 <michagogo> sipa: I thought that you can flush the keypool by reencrypting by changing the passphrase
19 2014-06-13 07:32:01 <sipa> that does not re-encrypt
20 2014-06-13 07:32:12 <sipa> only changes the master key record
21 2014-06-13 07:32:56 <sipa> the master key itself (and the private keys encrypted with it) remain the same
22 2014-06-13 07:35:46 <michagogo> Really?
23 2014-06-13 07:36:16 <michagogo> I would have thought it would change for the same reason that keypool is regenerated when you encrypt
24 2014-06-13 07:37:00 <michagogo> So that you don't have any new keys that were ever stored in a way other than the current one
25 2014-06-13 07:37:13 <gwillen> michagogo: unencrypted -> encrypted means your old keys are vulnerable and needs to be regenerated
26 2014-06-13 07:37:19 <gwillen> a password change doesn't necessarily mean that
27 2014-06-13 07:37:35 <michagogo> So that if e.g. the passphrase is compromised or very weak
28 2014-06-13 07:38:00 <michagogo> s/very //
29 2014-06-13 07:38:06 <gwillen> also, a password change doesn't mean that anything is being stored differently; in pretty much any such system, the pasword encrypts a master key, and _that_ encrypts the data
30 2014-06-13 07:38:16 <gwillen> that's also how encrypted disks are, so you don't have to re-encrypt the whole disk on every password change
31 2014-06-13 07:38:33 <michagogo> gwillen: right, but I mean I would have assumed the master key would be changed
32 2014-06-13 07:38:47 <gwillen> well, with an encrypted disk that's obviously infeasible
33 2014-06-13 07:38:54 <gwillen> since you'd be re-encrypting potentially terabytes
34 2014-06-13 07:39:19 <gwillen> I suppose I could see flushing the keypool when changing password
35 2014-06-13 07:39:26 <gwillen> since it's a much cheaper operation than re-encrypting a disk
36 2014-06-13 07:39:30 <michagogo> gwillen: of course
37 2014-06-13 07:39:36 <michagogo> But for a wallet...
38 2014-06-13 07:39:40 <michagogo> Yeah
39 2014-06-13 07:57:58 <Luke-Jr> hm, wonder what would happen if I try to import a compressed key into a wallet with an old version
40 2014-06-13 07:58:46 <michagogo> Luke-Jr: But importing keys is bad !!!!1!!111!1!!!eleventyone!11!!
41 2014-06-13 07:59:08 <michagogo> ACTION runs
42 2014-06-13 07:59:11 <Luke-Jr> michagogo: but so are uncompressed keys! :<
43 2014-06-13 08:01:46 <dsnrk> Luke-Jr: can we bug Armory Electrum Multibit Bc.i about it? really really they shouldn't be using them at all.
44 2014-06-13 08:01:56 <Luke-Jr> dsnrk: please do
45 2014-06-13 08:02:15 <Luke-Jr> dsnrk: someone should set up a certification process for wallets ;)
46 2014-06-13 08:02:33 <dsnrk> ACTION glances at bc.i
47 2014-06-13 08:02:57 <Luke-Jr> bc.i is hopeless, I wouldn't waste too much breath on them <.<
48 2014-06-13 08:03:07 <dsnrk> well I know who's failing every single checkbox. no bip32, no compressed keys, useless KDF
49 2014-06-13 08:03:50 <michagogo> dsnrk: pretty sure the KDF is fixable
50 2014-06-13 08:03:52 <wumpus> dsnrk: brainwallet.org?
51 2014-06-13 08:04:18 <michagogo> IIRC there's a radio buttons in the settings
52 2014-06-13 08:04:30 <michagogo> wumpus: bc.i
53 2014-06-13 08:04:31 <dsnrk> wumpus: didn't include it because we know the author is a thief.
54 2014-06-13 08:05:02 <dsnrk> michagogo: nobody changes defaults. anybody smart enough to change the setting to not use 25 rounds of PBKDF2 is smart enough not to use a web wallet.
55 2014-06-13 08:05:37 <michagogo> Well, I only know that because I recently was paid by someone who insisted on doing it by giving me a bc.i wallet ID and password
56 2014-06-13 08:06:10 <michagogo> I figured, if I'm forced to have a bc.i wallet, however temporarily, may as well poke around and see what it does
57 2014-06-13 08:06:32 <dsnrk> what, why would anybody do that? that's by far the dumbest thing I've heard today.
58 2014-06-13 08:07:12 <michagogo> dsnrk: yep
59 2014-06-13 08:07:26 <gribble> http://takemybitcoins.tv/
60 2014-06-13 08:07:26 <michagogo> ;;lucky take my bitcoins
61 2014-06-13 08:07:28 <michagogo> ^
62 2014-06-13 08:08:05 <michagogo> I've asked a couple times why, haven't really gotten a useful answer
63 2014-06-13 08:08:25 <michagogo> One excuse was "it's for newbs"
64 2014-06-13 08:08:40 <dsnrk> michagogo: what on earth is that site?
65 2014-06-13 08:09:03 <michagogo> dsnrk: a game show with bitcoin prizes
66 2014-06-13 08:11:04 <dsnrk> michagogo: right. expected something else.
67 2014-06-13 08:11:37 <michagogo> dsnrk: like what?
68 2014-06-13 08:13:31 <dsnrk> er there's another one. it's like shouldibehandelingotherpeoplesmoney.com or something, but I can never remember the real URL.
69 2014-06-13 08:13:57 <dsnrk> it just prints "no" in stoic punk letters.
70 2014-06-13 08:14:06 <dsnrk> *pink
71 2014-06-13 08:19:03 <michagogo> dsnrk: ah, that's mine
72 2014-06-13 08:19:11 <michagogo> canibuildasitehandlingotherpeoplesmoney.com
73 2014-06-13 08:21:24 <dsnrk> that's the one
74 2014-06-13 09:23:28 <amincd> Hi, can I run bitcoind and bitcoind-testnet at the same time
75 2014-06-13 09:28:19 <dsnrk> yes.
76 2014-06-13 09:30:27 <amincd> dsknrk, I'm getting this error when trying: Error: An error occurred while setting up the RPC port 2000 for listening on IPv4: Address already in use. Anyway I can fix that?
77 2014-06-13 09:33:02 <dsnrk> why are you changing the ports? testnet defaults to different ones than mainnet.
78 2014-06-13 09:33:06 <chichov> are P2SH transactions correctly included by the wallet as unspent outputs?
79 2014-06-13 09:33:25 <amincd> dsnrk: I didn't change the ports. I started testnet, tried to start bitcoind mainnet, and got this error message
80 2014-06-13 09:34:14 <dsnrk> sure you're not using an altcoin there? 2000 isn't a port bitcoin ever uses
81 2014-06-13 09:34:22 <amincd> dsnrk: I'm sure
82 2014-06-13 09:34:33 <dsnrk> bitcoin uses 8332, 8333 for mainnet and 18332, 18333 for testnet
83 2014-06-13 09:34:42 <amincd> dsnrk: I know..
84 2014-06-13 09:35:10 <amincd> mainnet bitcoind works fine when I don't start testnet first
85 2014-06-13 09:37:06 <dsnrk> doesn't make sense to me
86 2014-06-13 09:46:27 <chichov> I have a transaction that is somehow stuck in my wallet as permanently unconfirmed, how do I get rid of that?
87 2014-06-13 09:48:12 <gmaxwell> there is zapwallettx to blow out the wallet transactions and relearn from the networkâ but you can just ignore it too, it's harmless.
88 2014-06-13 09:54:56 <chichov> it's a strange situation though, I've created a raw transaction trying to spend a P2SH multisig output and it got accepted like that into the wallet
89 2014-06-13 09:55:12 <chichov> but, it seems like it wasn't relayed anywhere
90 2014-06-13 09:56:52 <chichov> and although I have one of the private keys and the multisig address in my wallet, the output I'm trying to spend is not in the unspent output list
91 2014-06-13 10:00:24 <aphoriser> Does make install do anything? I dont see any /etc/init.d or default boot level start script
92 2014-06-13 10:20:25 <chichov> is there a place where I can check what's wrong with a raw transaction?
93 2014-06-13 10:21:14 <Jouke> What do you mean with "wrong"?
94 2014-06-13 10:22:05 <chichov> I have a raw transaction that I've just signed myself, got a "complete" flag afterwards, but when sending it to the network it is rejected
95 2014-06-13 10:23:08 <chichov> one of the inputs is for some strange reason not listed in my unspent list (it's a P2SH 1-of-2 multisig), although I have one of the keys
96 2014-06-13 10:23:32 <chichov> so I want to find out why it's constantly being rejected
97 2014-06-13 10:25:08 <Jouke> In bitcoind you can do a decoderawtransaction to see if the transaction is well formed. Most of the time transactions are rejected because an input is allready spent or you created dust outputs that your node will not accept. Have you tried pushing the transaction elsewhere?
98 2014-06-13 10:25:56 <chichov> yep, without success
99 2014-06-13 10:26:04 <chichov> I checked both inputs, both are unspent
100 2014-06-13 10:26:33 <chichov> strangely, blockchain.info says that the number of arguments in scriptSig is wrong
101 2014-06-13 10:26:56 <chichov> although it looks valid
102 2014-06-13 10:27:18 <chichov> do you want to take a look at it yourself?
103 2014-06-13 10:27:45 <Jouke> sure
104 2014-06-13 10:32:13 <sipa> chichov: bitcoind only considers multisig coins yours if you have *all* the keys
105 2014-06-13 10:32:26 <sipa> chichov: because it doesn't deal well with shared ownership
106 2014-06-13 10:32:38 <chichov> huh, so in a 1-of-2 where I only have one, he won't see that?
107 2014-06-13 10:32:42 <sipa> no
108 2014-06-13 10:32:44 <chichov> pity
109 2014-06-13 10:32:50 <sipa> it's really just proof of concept
110 2014-06-13 10:33:11 <elichai2> heyy
111 2014-06-13 10:33:17 <sipa> real multisig needs much more infrastructure anyway, e.g. to pass the partially signed transactions around
112 2014-06-13 10:33:27 <elichai2> you doing something about Ghash.io?
113 2014-06-13 10:33:42 <chichov> I created a transaction spending some coins to a 1-of-2 multisig address, where the first pubkey is mine and the second one is gibberish
114 2014-06-13 10:34:00 <chichov> I tried to sign it and everything appeared to work, also got a "complete" flag
115 2014-06-13 10:34:04 <sipa> chichov: what error does sendrawtransaction give you?
116 2014-06-13 10:34:12 <chichov> Tx rejected (-22)
117 2014-06-13 10:34:22 <elichai2> sipa: Ghash.io got 50%!!
118 2014-06-13 10:34:40 <sipa> chichov: which version?
119 2014-06-13 10:34:43 <sipa> elichai2: help!
120 2014-06-13 10:34:45 <chichov> newest, 0.9.1
121 2014-06-13 10:34:56 <sipa> strange, it should tell you what's wrong with it
122 2014-06-13 10:35:19 <chichov> wait a sec.
123 2014-06-13 10:35:26 <chichov> just zapped all the transactions and now he has accepted it
124 2014-06-13 10:35:38 <elichai2> sipa: there is any technical sulotion?
125 2014-06-13 10:36:01 <chichov> it seems like there was some conflict with an unconfirmed transaction hanging in the air
126 2014-06-13 10:36:19 <sipa> elichai2: no
127 2014-06-13 10:36:26 <chichov> lets wait if it will be relayed through the network though
128 2014-06-13 10:38:29 <chichov> this is truly odd: he didn't relay it but gave me a transaction id back
129 2014-06-13 10:38:40 <sipa> how do you know it didn't relay?
130 2014-06-13 10:38:43 <chichov> and if I try to push it on blockr.io, he gives me an error
131 2014-06-13 10:38:49 <chichov> I check it on blockchain.info
132 2014-06-13 10:38:51 <sipa> DIE
133 2014-06-13 10:38:54 <chichov> typically it appears within a few seconds
134 2014-06-13 10:39:10 <chichov> heh, anything gravely wrong with this approach?
135 2014-06-13 10:39:12 <sipa> there's a difference between your node not relaying it
136 2014-06-13 10:39:17 <sipa> and the network not relaying it
137 2014-06-13 10:39:38 <sipa> you said there was a conflicting tx in your mempool... likely others have that conflicting one in their mempool too
138 2014-06-13 10:39:46 <chichov> alright, how would you suggest to investigate further?
139 2014-06-13 10:39:54 <sipa> what is there to investigate?
140 2014-06-13 10:40:08 <sipa> from the point of view of the network, you're doing a double spend
141 2014-06-13 10:40:28 <chichov> the outputs I'm trying to claim are marked everywhere as "unspent"
142 2014-06-13 10:40:43 <sipa> ah
143 2014-06-13 10:40:46 <sipa> oh
144 2014-06-13 10:41:02 <sipa> i just realized: it's only in git head that sendrawtransaction reports errors
145 2014-06-13 10:41:12 <sipa> can you give me the hex raw tx?
146 2014-06-13 10:41:16 <chichov> strange, not anymore
147 2014-06-13 10:42:05 <chichov> yea, one moment
148 2014-06-13 10:42:27 <chichov> blockchain just removed the "unspent" flag
149 2014-06-13 10:42:57 <sipa> does it see your transaction now?
150 2014-06-13 10:43:01 <chichov> nope
151 2014-06-13 10:43:06 <sipa> or is it spent by another transaction?
152 2014-06-13 10:43:10 <sipa> according to them?
153 2014-06-13 10:43:30 <chichov> I'll give you the raw transaction, then you'll see
154 2014-06-13 10:43:30 <elichai2> sipa: really? nothing? so we can say goodbye to bitcoin? :(
155 2014-06-13 10:43:55 <sipa> elichai2: yep, sell all your coins to me, i'll give you 1 USD for each
156 2014-06-13 10:44:04 <chichov> hehe
157 2014-06-13 10:44:07 <elichai2> lol
158 2014-06-13 10:44:31 <elichai2> sipa: if they'll pass the 51%-52% and nobody will try to stop them, i will sell my coins
159 2014-06-13 10:44:50 <hearn> elichai2: it's fair to say that proof of work was an experiment that has been tried and failed
160 2014-06-13 10:45:02 <hearn> satoshi did not anticipate that mining and running fully validating nodes would become disconnected
161 2014-06-13 10:46:03 <aphoriser> sudo useradd bitcoind -c "Bitcoin Daemon" -d /home/bitcoind -m -s /bin/bash -r <--- is this needed ? & shou,dnt /home/bitcoind be my ~/.bitcoin/bootstrap.dat etc?
162 2014-06-13 10:46:50 <sipa> aphoriser: #bitcoin
163 2014-06-13 10:47:17 <elichai2> hearn: there is any other proof that isn't exposed to 51% attack?
164 2014-06-13 10:49:57 <hearn> IMHO none of the candidates for a PoW based block chain algorithm are convincing
165 2014-06-13 10:50:23 <elichai2> or maybe isn't exposed to pools minning
166 2014-06-13 10:50:25 <hearn> ultimately, a 51% attack is fundamental - bitcoin is a way that the majority agree on things. the problem with bitcoin is that "the majority" is determined exclusively by CPU power
167 2014-06-13 10:50:39 <hearn> there are schemes available that break pooled mining. however it evolved for a reason
168 2014-06-13 10:50:59 <hearn> CPU power is a very poor match for what we *really* want, which is a majority of *people*
169 2014-06-13 10:51:08 <elichai2> yeah
170 2014-06-13 10:51:18 <elichai2> we need node minning not CPU/GPU/ASIC
171 2014-06-13 10:51:28 <sipa> not nodes, people
172 2014-06-13 10:51:31 <t7> hearn: then you need an authority on what a person is, say goodbye to decentralization
173 2014-06-13 10:51:44 <rubensayshi> so mining should be based on filling in kitty capchas?
174 2014-06-13 10:51:47 <elichai2> that everyone that runs full node gets the reward
175 2014-06-13 10:51:47 <hearn> we already said goodbye to decentralisation.
176 2014-06-13 10:51:49 <sipa> if it's nodes, you just run an extra node to get more voting power
177 2014-06-13 10:51:55 <elichai2> sipa: there is no way to do people
178 2014-06-13 10:51:58 <dsnrk> rubensayshi: computers are better than that.
179 2014-06-13 10:52:00 <sipa> hearn: it's still possible to complete
180 2014-06-13 10:52:02 <hearn> "one cpu one vote" has never been really decentralised anyway. we started with two CPU manufacturers, intel and amd
181 2014-06-13 10:52:11 <hearn> then we migrated to two GPU manufacturers, except really only ATI was competitive
182 2014-06-13 10:52:17 <hearn> then we migrated briefly to one or two FPGA vendors
183 2014-06-13 10:52:30 <hearn> we probably have more decentralised hardware than ever, with ASICs, ironically. but it's still ultimately rooted in a handful of companies
184 2014-06-13 10:52:50 <hearn> sipa: complete?
185 2014-06-13 10:52:56 <sipa> hearn: compete
186 2014-06-13 10:52:59 <hearn> ah
187 2014-06-13 10:53:18 <sipa> a new manufacturer or new hosting provider or more smaller scale ones can pop up
188 2014-06-13 10:53:21 <hearn> t7: anyway i have been researching how to solve the "what is a person" problem, hence my talks on zkSNARK proofs of passport
189 2014-06-13 10:53:34 <spy_29r47602> "so mining should be based on filling in kitty capchas" lol interesting idea
190 2014-06-13 10:53:54 <hearn> (actually any proof of identity, but it so happens that this one is standardised)
191 2014-06-13 10:54:10 <hearn> sipa: sure, we see real competition in the ASIC space.
192 2014-06-13 10:54:37 <hearn> sipa: but it's worthless if all the ASIC owners sell their votes. on reddit there are posts from people using cex.io or ghash.io - they basically say "hey it's profitable for me, and i trust them not to double spend, so why should i change?"
193 2014-06-13 10:55:20 <hearn> tying coin rewards to mining is elegant within the PoW framework, but it leads to serious distortions like this one. an interesting thing about a hypothetical ZKPOP based coin is that seignorage could be issued via a random lottery
194 2014-06-13 10:55:29 <hearn> like, literally anyone could find themselves the winner of new coins
195 2014-06-13 10:55:58 <t7> sounds different :)
196 2014-06-13 10:56:03 <hearn> it's very different
197 2014-06-13 10:56:09 <hearn> i haven't figured out most of the details yet
198 2014-06-13 10:56:18 <t7> but how do you limit lottery entrees?
199 2014-06-13 10:56:29 <hearn> it's a #wizards level discussion. plus the full zkSNARKS framework isn't open source. only the core code was released yesterday
200 2014-06-13 10:56:39 <hearn> they are fighting to open source it but i think their universities want to commercialise it ....
201 2014-06-13 10:57:42 <hearn> t7: each time new coins are issued, they're simply assigned to a random anonymous identity, derived from the passport. so each person can enter only once, and they can enter themselves just by pushing a button in their wallet (and/or taking part in the chain building process - i didn't decide yet if it makes sense to tie them together .... judging from ghash, maybe not)
202 2014-06-13 10:58:33 <t7> "so each person can enter only once" how?
203 2014-06-13 10:59:16 <hearn> i need to write up the ZKPOP idea
204 2014-06-13 10:59:22 <hearn> somewhere other than reddit
205 2014-06-13 10:59:28 <hearn> let me dig up the last explanation i wrote of this
206 2014-06-13 11:00:31 <hearn> http://www.reddit.com/r/Bitcoin/comments/26pynt/mike_hearn_nbc_talk_no_na%C3%AFve_optimism_here/chtvvrs
207 2014-06-13 11:02:43 <t7> i think you are chasing a pipe dream
208 2014-06-13 11:03:07 <t7> you need someone to issue these passports
209 2014-06-13 11:03:25 <t7> this is a huge weakness
210 2014-06-13 11:03:47 <hearn> those "someones" already exist and have already done it
211 2014-06-13 11:03:53 <hearn> it's no more of a weakness than needing someone to make CPUs or ASICs for bitcoin
212 2014-06-13 11:04:03 <petertodd> t7: indeed, governments have well oiled procedures to issue fake passports when needed - to think they'd refrain from doing something as benign as signing fake signatures to attack an unwanted system is crazy
213 2014-06-13 11:04:25 <petertodd> t7: doesn't cost them a cent either, whereas ASICs at least have well-defined costs
214 2014-06-13 11:05:00 <t7> ASICs would be a lot harder if the proof of work scheme was changed
215 2014-06-13 11:05:03 <hearn> of all objections, that is by far the most stupid. people brought it up in the early days of bitcoin too: what if the US government mines and becomes a 51% attacker?!?
216 2014-06-13 11:05:43 <hearn> it never happened. governments don't work that way. moreover, governments take forging of their passports by other governments very seriously. it's quite easy to split things up so if a citizen of country X mines a block, the next one has to be from a different country (or two or three)
217 2014-06-13 11:06:12 <hearn> t7: no, people tried that. scrypt ASICs got built anyway, or at least people started.
218 2014-06-13 11:06:20 <t7> maybe something requiring building an AST for some turing complete language and ensuring that it returns some result within n operations
219 2014-06-13 11:06:41 <hearn> t7: if you build a PoW algorithm that's "ASIC resistant" that means it's not application specific anymore, which means it'sa CPU
220 2014-06-13 11:07:00 <hearn> if you have a CPU, then you can be outrun by botnets
221 2014-06-13 11:07:04 <petertodd> t7: initially they'd be harder, unfortunately every scheme that people have come up with just makes the NRE costs to make the first ASIC go up, which perversely increases the centralization of ASICs. (remember that chip fabs operate on a contract basis)
222 2014-06-13 11:07:06 <t7> hearn: yeah i hope there is a safe way to encode that
223 2014-06-13 11:07:36 <petertodd> hearn: obviously I'm talking about a government forging their own passports, like I say there are well-oiled procedures for doing so for the use of police and intelligence services.
224 2014-06-13 11:08:18 <hearn> yes, but like i said, (a) practical experience shows that we have to fear community based "attackers" a lot more than intelligence agencies when it comes to consensus interference and (b) there are ways to mitigate that by requiring an international spread, anyway
225 2014-06-13 11:08:36 <hearn> so i am not too worried about this
226 2014-06-13 11:08:41 <hearn> there are much more practical difficulties with the idea :-)
227 2014-06-13 11:09:03 <petertodd> indeed, upgrading standards comes to mind, that is consensus-critical...
228 2014-06-13 11:09:12 <elichai2> there is any channel for Ghash.io??
229 2014-06-13 11:09:19 <hearn> like, how do you do a block chain based on signatures at all
230 2014-06-13 11:09:43 <petertodd> hearn: your proof of work is obviously just signing repeatedly
231 2014-06-13 11:09:57 <t7> proof of work is finding the private key :D
232 2014-06-13 11:10:01 <petertodd> hearn: I mean, we're assuming they'd never issue a key in hardware other than a passport...
233 2014-06-13 11:10:18 <hearn> eh?
234 2014-06-13 11:10:20 <petertodd> ACTION is really looking forward to liquid nitrogen cooled passport overclockers
235 2014-06-13 11:10:23 <hearn> passports do not reliably contain private keys
236 2014-06-13 11:10:29 <hearn> you didn't read anything i wrote on the topic, did you?
237 2014-06-13 11:10:35 <hearn> please go read what i've been proposing before commenting on it further
238 2014-06-13 11:10:55 <aphoriser> when running bitcoind should it at least verbose something?
239 2014-06-13 11:11:35 <petertodd> hearn: don't be so sensitive; obviously that's a semi-joke...
240 2014-06-13 11:11:55 <berndj-blackout> aphoriser: bitcoind -debug & tail -f $HOME/.bitcoin/debug.log
241 2014-06-13 11:12:34 <hearn> let's put the question of how we bind a key to a person to one side. as there are multiple ways and zkpops are only one.
242 2014-06-13 11:12:53 <hearn> let's say each person has a key. now, how do we build a block chain of that? require majority to sign? but the full set of people taking part is fluid, so it doesn't work.
243 2014-06-13 11:12:56 <elichai2> petertodd is doing nothing against ghash.io :(
244 2014-06-13 11:13:04 <hearn> how do you limit the block rate? do you even need a block-based structure at all?
245 2014-06-13 11:13:24 <aphoriser> berndj-blackout, do you know if I can set that in rc.local if I wanted to run at boot / restart? - & is there argument for specifying absolute path of /home/myid/.bitcoin/bootstrap.dat ?
246 2014-06-13 11:13:33 <elichai2> hearn: we need to think of technology that won't allow pools
247 2014-06-13 11:13:38 <petertodd> hearn: solve it and you've solved proof-of-stake...
248 2014-06-13 11:13:58 <hearn> indeed
249 2014-06-13 11:14:18 <berndj-blackout> aphoriser, i don't know, try bitcoind -help
250 2014-06-13 11:14:19 <petertodd> elichai2: http://www.reddit.com/r/Bitcoin/comments/281ftd/why_i_just_sold_50_of_my_bitcoins_ghashio/ has two reasonable suggestions
251 2014-06-13 11:15:12 <elichai2> petertodd: you sold your bitcoins?!
252 2014-06-13 11:15:30 <petertodd> elichai2: half of them - you never sell everything
253 2014-06-13 11:16:28 <elichai2> lol
254 2014-06-13 11:16:31 <berndj-blackout> right now i'm guessing there are more people who actively think cryptocurrencies are stupid than bitcoin users. so rent those people's passports in order to win all the lotteries
255 2014-06-13 11:17:27 <petertodd> berndj-blackout: I suggested the previous time this came up that even in the absence of faked passports you'd just find law enforcement and other high personel organizations require borrowing your passport as a condition of your employment on occasion
256 2014-06-13 11:17:28 <hearn> berndj-blackout: in the unlikely event of lots of people handing over their passports to a random stranger on the internet, it would still be no worse than what we have now, where people rent their ASICs to ghash
257 2014-06-13 11:17:58 <petertodd> hearn: there's no cost to handing over your passport - all your doing is proving posession of a key after all, and that can be done remotely
258 2014-06-13 11:18:48 <petertodd> anyway, this really is a -wizards topic...
259 2014-06-13 11:18:52 <hearn> yeah
260 2014-06-13 11:23:24 <elichai2> ghash.io got to 51%%%%%%%% https://blockchain.info/pools?timespan=24hrs
261 2014-06-13 11:26:39 <sipa> please, not here
262 2014-06-13 11:27:16 <elichai2> ok....
263 2014-06-13 11:35:21 <amincd> How do I set the listening port for bitcoin testnet?
264 2014-06-13 11:35:30 <amincd> in the configuration file I mean
265 2014-06-13 11:40:03 <elichai2> petertodd: i think that we need to make even hard fork to make something that will kill ghash.io
266 2014-06-13 11:41:19 <petertodd> elichai2: I strongly suspect that's politically impossible; better to continue researching pool-proof/solo-miner-friendly crypto-coin tech
267 2014-06-13 11:42:51 <elichai2> why? why it's so impossible? today most of the users uses light wallets, so the won't even notice
268 2014-06-13 11:44:02 <hearn> their blocks can't be reliably identified anyway.
269 2014-06-13 11:44:03 <petertodd> elichai2: I mean, even if it were a true soft-fork it'd be politically impossible until we see a serious disaster, though hopefully I'm wrong
270 2014-06-13 11:44:56 <elichai2> petertodd: but they can do doublespend without anyone will even notice
271 2014-06-13 11:44:59 <hearn> the fact that graphs like the blockchain one are even possible, is because mining pools don't mind their existence
272 2014-06-13 11:45:56 <petertodd> elichai2: no, people will notice. what that means though is as-yet unknown. much more likely is this leading to regulation, not killing off bitcoin directly.
273 2014-06-13 11:47:02 <petertodd> elichai2: keep in mind, I'm a pretty cautious guy - me selling 50% of my bitcoins doesn't mean I'm sure it's going to fail, it means I think there is a reasonable probability it will, and I'd rather have the money in a bank account to buy me time to help fix the problem
274 2014-06-13 11:47:08 <Hasimir> amincd, default config is port=18333 and rpcport=18332
275 2014-06-13 11:47:24 <Hasimir> amincd, basically the same as main + 10000
276 2014-06-13 11:48:18 <elichai2> https://bitcointalk.org/index.php?topic=327767.0
277 2014-06-13 11:48:31 <amincd> Hasimir: thanks
278 2014-06-13 11:48:48 <Hasimir> np
279 2014-06-13 11:55:44 <petertodd> elichai2: yes, I said "notice" - whether or not they do anything is another matter. heck, in that specific case trying to pin blame on ghash.io sets a bad precident, hence why I've implemented replace-by-fee and am working to have it implemented
280 2014-06-13 12:05:10 <berndj-blackout> does the ghash/cex business model work if mining is reliably unprofitable?
281 2014-06-13 12:12:01 <petertodd> berndj-blackout: I can't see centralized hashing power competing against decentralized hashing power given the physical constraints of cooling, but that's very much "in theory" - in practice they can out-market decentralized hashing power
282 2014-06-13 12:14:19 <berndj-blackout> petertodd, i could still see scope for centralized mining to compete by being a "load of last resort" to absorb load dumps from the electricity grid
283 2014-06-13 12:14:47 <berndj-blackout> but yeah, once (optimistic?) people heat their homes with miners, it's a different game
284 2014-06-13 12:14:57 <petertodd> berndj-blackout: sure, but even that usage is relatively decentralized world wide - those loads are most useful when spread all around the grid
285 2014-06-13 12:17:44 <belcher> people will heat their homes with heat pumps
286 2014-06-13 12:17:47 <berndj-blackout> petertodd, re unprofitable, i meant that there are people who are pretty invested in bitcoin, and that 50% pools could represent a threat to their investment. i don't know if it's too early to tell or not, but if mining at a loss costs them less than the existence of >50% pools does, that's a feedback signal we want
287 2014-06-13 12:17:57 <belcher> more efficent than miners where only 100% of the electricity goes to heat
288 2014-06-13 12:18:46 <berndj-blackout> belcher, air conditioning has been around for many decades now, yet people still burn electrons to heat their homes. definitely where i live
289 2014-06-13 12:19:05 <rubensayshi> so right now the consensus of the network is that we trust ghash to be in control xD
290 2014-06-13 12:19:08 <belcher> how odd, ok then
291 2014-06-13 12:20:10 <petertodd> belcher: heat pumps don't work so well in colder climates unless you put a lot of money towards getting a good heat source (e.g. geothermal)
292 2014-06-13 12:20:25 <petertodd> berndj-blackout: yeah, that's an unknown, and probably not sustainable long-term
293 2014-06-13 12:20:27 <belcher> okay
294 2014-06-13 12:20:28 <berndj-blackout> belcher, your objection remains valid though; if people aren't switching from burning electrons to to more efficient heat pumps, i don't know that they'd switch to mining bitcoin
295 2014-06-13 12:21:08 <petertodd> berndj-blackout: well, I've actually done the math, and where my parents live burning bitcoin makes financial sense, as an example
296 2014-06-13 12:21:19 <hearn> sipa: is there a specific place other than the giant ProcessMessage method where message handling functions should go?
297 2014-06-13 12:21:42 <dabura667> Just double checking, new dust limit is 564 satoshis, correct?
298 2014-06-13 12:21:52 <berndj-blackout> petertodd, i hear you, but "makes financial sense" != "best available option" (in the general case)
299 2014-06-13 12:22:01 <petertodd> dabura667: about 5% of the hashing power is mining that fwiw
300 2014-06-13 12:22:11 <dabura667> haha true.
301 2014-06-13 12:22:29 <dabura667> but it is the "new rule" that no one follows.
302 2014-06-13 12:22:41 <hearn> right
303 2014-06-13 12:23:09 <petertodd> dabura667: that said, some of the big pools were ignoring the dust rule alltogether, so in practice if you're paying a reasonable fee you might find it's a lot more than 5%
304 2014-06-13 12:23:17 <dabura667> cool cool. Thanks Peter. 500 bits @changetipIRC
305 2014-06-13 12:23:33 <petertodd> dabura667: oh, and actually, I think eligius ignores the dust rule, so you've got at least 8% right there
306 2014-06-13 12:23:43 <elichai2> petertodd: sorry, i wasn't here, what is "replace-by-fee"?
307 2014-06-13 12:23:47 <dabura667> petertodd: awesome
308 2014-06-13 12:24:00 <dabura667> 8%.... I like those odds...
309 2014-06-13 12:24:19 <dabura667> not as good as.......... 51% though.
310 2014-06-13 12:24:33 <thaReal> heh
311 2014-06-13 12:24:35 <petertodd> elichai2: https://bitcointalk.org/index.php?topic=645120.0
312 2014-06-13 12:25:07 <hearn> dabura667: odds of what? double spending?
313 2014-06-13 12:26:05 <dabura667> no, I mean getting a "dust" ouput mined
314 2014-06-13 12:26:14 <hearn> ag
315 2014-06-13 12:26:20 <dabura667> the 51% was a jab at GHash
316 2014-06-13 12:26:20 <hearn> *ah right
317 2014-06-13 12:26:25 <hearn> yeah
318 2014-06-13 12:26:50 <dabura667> so yeah, segway... anyone else SLIGHTLY nervous?
319 2014-06-13 12:26:52 <hearn> sometimes i think the whole notion of dust was a mistake. perhaps we should have preferred to keep the rules consistent and simple, and have larger blocks.
320 2014-06-13 12:27:12 <petertodd> dust had nothing to do with blocks
321 2014-06-13 12:28:02 <hearn> alright. min relay fee.
322 2014-06-13 12:28:04 <hearn> from which dust limit is derived
323 2014-06-13 12:28:14 <hearn> the complexity it adds to everything is pretty phenomenal
324 2014-06-13 12:28:17 <sipa> dust prevention is to prevent utxo set clutter
325 2014-06-13 12:28:23 <sipa> not block size
326 2014-06-13 12:28:38 <hearn> dust limit predates ultraprune, i think? i'm forgetting
327 2014-06-13 12:28:38 <sipa> hearn: not really no
328 2014-06-13 12:28:43 <sipa> no
329 2014-06-13 12:28:51 <sipa> dust limit is 0.8.1 or so
330 2014-06-13 12:28:58 <petertodd> sipa: indeed, dust was my idea
331 2014-06-13 12:29:12 <hearn> oh, right, it was introduced because of satoshidice wasn't it
332 2014-06-13 12:29:12 <sipa> there was the cent rule that is much older though
333 2014-06-13 12:29:44 <petertodd> anyway, TXO commitments could make dust concerns obsolete
334 2014-06-13 12:30:03 <hearn> in hindsight given the rise in value, i'm thinking utxo db size is probably much less of an issue than all the associated complexity that came with the lowered fungibility
335 2014-06-13 12:30:21 <hearn> certainly micropayment channels got more complicated because of the dust limit
336 2014-06-13 12:31:07 <petertodd> hearn: well, submit a pull-req getting rid of it, I'd happily ACK that given how confident I am that TXO commitments work
337 2014-06-13 12:32:17 <petertodd> made colored coins a lot more complex until we realized our padding designs were bonkers
338 2014-06-13 12:32:26 <dabura667> petertodd: TXO commitments? any links?
339 2014-06-13 12:34:05 <sipa> hearn: i have some vague idea about adding signal handlers for every message in net, and allow different pieces of code to register to them
340 2014-06-13 12:34:23 <hearn> petertodd: my last attempt to fix fees went pretty wrong, didn't it? there doesn't seem any point trying to simplify fees further until mining gets less broken. until then we're just writing code people don't upgrade to
341 2014-06-13 12:34:23 <sipa> but ideally, you have asynchronous handling
342 2014-06-13 12:34:43 <hearn> indeed don't even announce whether they have upgraded, or whether they plan to
343 2014-06-13 12:34:45 <sipa> for example, when a blocknis requested, there is no need to wait inside the (single threaded!) message handler
344 2014-06-13 12:34:50 <hearn> sipa: well i was thinking just for unit testing
345 2014-06-13 12:34:54 <hearn> sipa: as a first base :)
346 2014-06-13 12:35:32 <petertodd> dabura667: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas <- there's a writeup on bitcointalk by gmaxwell too, but my googlefu is failing
347 2014-06-13 12:36:11 <dabura667> petertodd: thanks! if you ever need any Japanese googlefu, let me know ;-)
348 2014-06-13 12:36:12 <petertodd> hearn: it went wrong because it cost miners money; I've had pool ops tell me it was a reason not to upgrade to 0.9
349 2014-06-13 12:36:28 <hearn> which pool ops?
350 2014-06-13 12:37:05 <petertodd> hearn: most of the conversations I've had have been ones where they ask to be confidental, but low double digits of hashing power
351 2014-06-13 12:37:23 <petertodd> hearn: dunno what btcguild thinks, for instance
352 2014-06-13 12:37:36 <hearn> see? this is pretty broken. when basic things like block inclusion policies are considered confidential, it's no wonder bitcoin is going wrong
353 2014-06-13 12:37:52 <petertodd> meh, that's decentralized trustless systems for you
354 2014-06-13 12:38:26 <hearn> mining isn't trustless is it? miners trust pools to run Core in the "right" way, but they won't even discuss what they're doing
355 2014-06-13 12:38:42 <hearn> this also leads to the question of what happens with floating fees
356 2014-06-13 12:38:59 <petertodd> that trust is part of the reason why they don't upgrade immediately - I've had miners say they don't trust all the new code in 0.9
357 2014-06-13 12:39:02 <hearn> if miners will only allow them to float upwards, bitcoin can quickly end up more expensive than credit cards
358 2014-06-13 12:39:36 <petertodd> bitcoin already is as a system; transactions cost around $50
359 2014-06-13 12:39:43 <hearn> eh, part of the reason 0.9 took a long time is there weren't many changes going in fast
360 2014-06-13 12:40:51 <hearn> though as mining is probably now only slightly easier to enter as a market than credit card processing .... i guess it's not unexpected the same cartel-like rents appear
361 2014-06-13 12:41:36 <petertodd> it's a decentralized system; it'll never be as efficient as centralized system
362 2014-06-13 12:41:39 <petertodd> *systems
363 2014-06-13 12:42:37 <waxwing> "only slightly easier to enter as a market than credit card processing" ... hmm a bit much don't you think.
364 2014-06-13 12:42:47 <dabura667> petertodd: Some of the most inaccurate statements in history started with "it'll never"
365 2014-06-13 12:43:00 <hearn> profit center
366 2014-06-13 12:43:00 <hearn> that seems like a broad assertion unsupported by fact. the reason fees have got so high is that mining isn't a decentralised system. we're only supposed to be using fees for load control, essentially, because the theory says that miners would prefer to pick up paying transactions than leave them on the table. in practice it only takes a few people to decide not to follow the theory and fees end up only rising to become an actual
367 2014-06-13 12:43:28 <petertodd> dabura667: heh, I know. that's a great example because there's so many systems you can build on top of bitcoin to drive fees down in practice, equally *maybe* something like tree chains can pull that stunt off
368 2014-06-13 12:43:29 <hearn> waxwing: well i'm not sure how hard it is to create a new pool, but i guess by now you need a pretty hefty investment in expensive hardware to get started. otherwise people won't mine on your pool. there's an initial hump you have to get over
369 2014-06-13 12:43:39 <hearn> waxwing: evidence suggests new pools don't come along every day at least
370 2014-06-13 12:44:00 <waxwing> hearn, it needs a lot of money to be sure, and some skills. but it's not like starting a bank, for example.
371 2014-06-13 12:44:14 <petertodd> hearn: look, you're gonna need something like tree chains that has a scalability/security tradeoff to make such ideas make sense. fundementally having data distributed across tens of thousands of decentralized nodes is gonna be expensive
372 2014-06-13 12:44:20 <hearn> credit card processors are not banks, however. sure, it's still easier to create a pool than a bank. but banks are the worst case scenario for creation of new businesses
373 2014-06-13 12:44:26 <michagogo> 15:26:58 <dabura667> so yeah, segway... anyone else SLIGHTLY nervous? <-- I think I might be a little bit nervous using a Segway for the first time, yeah.
374 2014-06-13 12:44:35 <hearn> the UK issued its first new banking license in 150 years, recently
375 2014-06-13 12:44:53 <hearn> i can't think of any industries as bad as that
376 2014-06-13 12:44:57 <dabura667> michagogo: The first time I used a segway, I freaked out.
377 2014-06-13 12:45:01 <hearn> (i mean other industries)
378 2014-06-13 12:45:07 <petertodd> hearn: I suggest you work more on hub-and-spoke micropayment channels - I spoke to a whole whack of people about them during the conf and the weeks after, and there's a lot of interest in getting cross-platform systems designed to make use of it. also, micropayments happen to work nicely for wallet security
379 2014-06-13 12:45:36 <michagogo> hearn: money printing?
380 2014-06-13 12:46:05 <hearn> ok, maybe x86 CPU production is as bad :)
381 2014-06-13 12:46:44 <hearn> petertodd: that's basically just banking, sped up
382 2014-06-13 12:47:14 <hearn> i mean if you want to abandon the notion of block chains entirely, might as well just use secure hardware a la mintchip. the hardware was proven to work pretty well over the past couple of decades in EMV.
383 2014-06-13 12:47:21 <hearn> but then it can't be decentralised anymore.
384 2014-06-13 12:47:43 <hearn> i'm going to ignore it for a while and see what ghash.io comes up with, if anything.
385 2014-06-13 12:47:51 <petertodd> hearn: huh? hub and spoke is trustless; it's micropayment channels
386 2014-06-13 12:48:27 <hearn> if they just sit pretty whilst miners collectively lemming themselves off a cliff, then i guess it's time to think about more radical solutions
387 2014-06-13 12:48:42 <hearn> petertodd: actually i have a feeling someone told me they're working on it already. there were a few people recently who were playing with the example code in bitcoinj
388 2014-06-13 12:48:49 <hearn> i know this cuz they reported bugs to me :)
389 2014-06-13 12:49:11 <petertodd> good, I'd sure hope so, I probably convinced 2x or 3x companies to look into it at least
390 2014-06-13 12:49:13 <michagogo> hearn: what would *they* do?
391 2014-06-13 12:49:16 <hearn> but it needs malleability fixes to be properly secure. also, ideally, reactivation of the original nLockTime/replacement semantics so channels can be bi-directional
392 2014-06-13 12:49:26 <michagogo> Kick miners out of the pool?
393 2014-06-13 12:49:40 <hearn> michagogo: ghash? well, they could do what they said they'd do back in january and allow cex.io renters to point their rented rigs at other pools
394 2014-06-13 12:49:44 <petertodd> bi-directionality works just fine with two single-directional channels...
395 2014-06-13 12:49:52 <hearn> it's hardly fixing mining but would potentially rebalance things a bit
396 2014-06-13 12:49:54 <michagogo> Ah, forgot about cex
397 2014-06-13 12:50:01 <hearn> or yes, raise fees (though they ruled that out, i think, stupidly)
398 2014-06-13 12:50:33 <hearn> there was a recent interview with this jeremey smith character which didn't look good though. he basically said, "we're the best and it's not our fault if everyone wants to mine on us". so who knows.
399 2014-06-13 12:50:37 <michagogo> Hm, I wonder how much of their hashpower is cex
400 2014-06-13 12:50:43 <hearn> 75% they claim
401 2014-06-13 12:50:47 <hearn> 25% is their own rigs
402 2014-06-13 12:50:51 <hearn> oh, no, sorry
403 2014-06-13 12:51:13 <hearn> 75% is "other miners" and 25% is bitfury asics. or something. i dunno. they're opaque and not trustworthy, imo, so who knows.
404 2014-06-13 13:04:21 <dsnrk> their january letter says 40% is theirs
405 2014-06-13 13:06:49 <teaspoon> hello
406 2014-06-13 13:07:09 <teaspoon> I wanted to ask about a possible solution the the mining pools that exist now
407 2014-06-13 13:07:14 <teaspoon> is this the right place to do it?
408 2014-06-13 13:08:36 <hearn> we've been going around this for some time already. so...... probably not. short answer: nobody has a solution
409 2014-06-13 13:08:57 <teaspoon> ok, then you should be able to dismiss my question quite quickly
410 2014-06-13 13:10:35 <teaspoon> if the problem is variance then is it possible to split the proof of work problem up into say 1000 proof of work problems with 1000 less difficulty, only allow a block to be added once all of these are solved and pay out each party who solves the sub problem?
411 2014-06-13 13:10:46 <hearn> that's what pools do
412 2014-06-13 13:10:54 <teaspoon> is the problem with this that all miners might be working of blocks that have different transactions in them?
413 2014-06-13 13:11:20 <teaspoon> yeah, but is it not possible to build what the pools do into the core code?
414 2014-06-13 13:11:54 <hearn> there has been occasional talk of putting p2pool into Bitcoin Core, but the problem is that mining keeps getting more and more abstracted from the process of actually making a block
415 2014-06-13 13:12:10 <hearn> when bitcoin was young, anyone could make blocks and earn coins by just checking a menu item in the gui
416 2014-06-13 13:12:25 <hearn> then people started writing custom assembly versions of SHA256 and staying even took a bit more work
417 2014-06-13 13:12:35 <hearn> then GPUs came and people started pooling, which outsourced block creation
418 2014-06-13 13:12:50 <hearn> now we have cex.io where people don't even own their own hardware. they buy and sell ASIC rigs on an exchange.
419 2014-06-13 13:13:04 <hearn> so they neither run their hardware nor software, yet, they are paying for increased hashrate
420 2014-06-13 13:13:04 <teaspoon> I heard that it was only 25% of the hashing power
421 2014-06-13 13:13:38 <hearn> who knows what it is. but "only" 25% of hash power being (nominally) controlled by people who neither run software or hardware is pretty bad.
422 2014-06-13 13:13:53 <hearn> so it doesn't really matter what we put into new versions of bitcoin at this point. people aren't going to be using it
423 2014-06-13 13:13:57 <teaspoon> well that would only be 12.5% of the total power
424 2014-06-13 13:14:23 <hearn> the problem is more fundamental than that
425 2014-06-13 13:14:37 <teaspoon> so it's not just a variance problem?
426 2014-06-13 13:14:46 <hearn> the problem is that the bar for being a miner kept being raised because of the hashing arms race. so naturally you get outsourcing and centralisation, economies of scale
427 2014-06-13 13:15:11 <hearn> the nature of things is that they tend to centralise over time. normally it's not considered a problem. you get mergers of companies and markets consolidate as the tech gets harder
428 2014-06-13 13:15:19 <hearn> bitcoin tries to swim against this tide but at the moment it's not succeeding
429 2014-06-13 13:15:39 <hearn> variance is one issue. but there are ways to pool and reduce variance whilst still running your own node and formatting your own blocks
430 2014-06-13 13:15:46 <hearn> miners generally don't use them
431 2014-06-13 13:15:57 <teaspoon> what are the other ways?
432 2014-06-13 13:16:22 <hearn> for example running p2pool, or getblocktemplate based pools. maybe others. i'm not really a mining expert.
433 2014-06-13 13:16:41 <teaspoon> yeah me neither :(
434 2014-06-13 13:16:51 <teaspoon> thanks for your time to explain
435 2014-06-13 13:17:11 <hearn> no problem
436 2014-06-13 13:19:53 <teaspoon> what proportion of the problem would you say variance plays? what about an open source platform that mirrors what ghash.io does in terms of ease of use and then just allow people to spawn copies of that? if people are using ghash.io because it's easy of use (or whatever else) benefits them, this service should be able to be replicated no?
437 2014-06-13 13:21:07 <dsnrk> people seem to have the idea that the biggest pool gives the biggest income.
438 2014-06-13 13:21:41 <SomeoneWeird> well
439 2014-06-13 13:21:49 <SomeoneWeird> it gives you a more stable income
440 2014-06-13 13:21:50 <SomeoneWeird> kind of
441 2014-06-13 13:22:52 <petertodd> dsnrk: well, the thing is it *does*, but we're talking small single digit % points
442 2014-06-13 13:22:54 <hearn> teaspoon: and who would write this platform? ghash has lots of features because it's a commercial operation. it's very common for open source software to be outcompeted by proprietary solutions
443 2014-06-13 13:23:01 <teaspoon> so are the advantages of using gnash.io illusionary or are there any real advantages? (as an independant miner)
444 2014-06-13 13:23:18 <petertodd> dsnrk: something people keep bringing up is how ghash.io is attractive for having four different merge-mined chains too
445 2014-06-13 13:23:37 <hearn> teaspoon: they have zero fees (though other pools match this), and they have a nice ui, and they merge mine with some alt coins hardly anyone cares about. and they have cex.io
446 2014-06-13 13:23:42 <dsnrk> petertodd: not to the level people assume. the skim of most pools could go above 5% with nobody noticing.
447 2014-06-13 13:23:44 <teaspoon> yes, getting contributions would be an issue, but it could be a projects that runs parallel to the bit coin core project
448 2014-06-13 13:23:54 <hearn> teaspoon: that project exists! it is p2pool
449 2014-06-13 13:24:02 <hearn> teaspoon: it has not met with any large success
450 2014-06-13 13:24:03 <petertodd> teaspoon: if they're honest then yes, you really do earn slightly more at ghash.io, and decreased cognitive costs are a real issue
451 2014-06-13 13:24:10 <dsnrk> petertodd: I don't think that's a problem. most people on eligius don't even enable the NMC payouts.
452 2014-06-13 13:24:58 <petertodd> teaspoon: p2pool has huge costs to run in practice for real miners - just setting it up sucks up time for instance, and it's design means that those with lower latency than others get an unfair advantage
453 2014-06-13 13:25:22 <petertodd> dsnrk: yes, but again, marketting is everything - eligius has a very different audience than ghash.io
454 2014-06-13 13:25:42 <teaspoon> so p2pool isn't as 'cool' as ghash.io?
455 2014-06-13 13:25:48 <petertodd> teaspoon: yup
456 2014-06-13 13:25:48 <teaspoon> or as user friendly?
457 2014-06-13 13:25:52 <petertodd> teaspoon: that too
458 2014-06-13 13:26:05 <rubensayshi> people pick the biggest because they asume they;re the biggest for a reason, without investigating much
459 2014-06-13 13:26:09 <petertodd> teaspoon: also, ghash.io advertises 24/7 support
460 2014-06-13 13:26:09 <tjopper1> teaspoon its more cool, less user friendly
461 2014-06-13 13:26:13 <teaspoon> and that can't be fixed without some money put into the project?
462 2014-06-13 13:26:34 <hearn> teaspoon: there's a more fundamental, deeper problem at work. miners don't care about anything beyond the money they earn.
463 2014-06-13 13:26:36 <petertodd> teaspoon: it's harder than it sounds - you really need a PR company working on it
464 2014-06-13 13:26:41 <dsnrk> most of ghash.io's size isn't miners mining at their pool. it's their own hardware.
465 2014-06-13 13:26:50 <petertodd> teaspoon: and picking a PR company when you know nothing about PR is non-trivial
466 2014-06-13 13:26:52 <hearn> teaspoon: e.g. you could make p2pool just as good as ghash, and still many miners would say "why change? why should i care?"
467 2014-06-13 13:27:10 <hearn> and yes the fact that they built giant farms for themselves is an issue as well of course
468 2014-06-13 13:27:20 <petertodd> not to mention the dark horse of the fact that p2pool is easily attacked - e.g. the recently revealed block withholding attack on eligius
469 2014-06-13 13:27:21 <teaspoon> if it performed in exactly the same way and they got just as much mining from it
470 2014-06-13 13:27:25 <teaspoon> they would care
471 2014-06-13 13:27:29 <petertodd> *eligius and btc guild
472 2014-06-13 13:27:57 <petertodd> teaspoon: no, they'd say "why do I need to get this big blockchain thing? why's all my bandwidth being used up?"
473 2014-06-13 13:28:05 <teaspoon> teaspoon: if they're honest then yes, you really do earn slightly more at ghash.io, and decreased cognitive costs are a real issueâ¦. what allows them to allow miners to earn slightly more with them?
474 2014-06-13 13:28:12 <hearn> teaspoon: well, that's what we all used to think. that's the basic assumption satoshi made way back when. it doesn't hold. miners do _not_ care.
475 2014-06-13 13:28:23 <hearn> ACTION is painting with a broad brush. some care.
476 2014-06-13 13:28:27 <hearn> but it seems not enough
477 2014-06-13 13:29:05 <hearn> the original vision of bitcoin was that individuals would all mine at home, with their cpus. that's why mining had a GUI at the start.
478 2014-06-13 13:29:08 <petertodd> teaspoon: so basically the thing is a pool will never orphan themselves, which means given a x% orphan rate, the pool with 50% hashing power has x/2% higher revenue
479 2014-06-13 13:29:12 <teaspoon> petertodd: teaspoon: no, they'd say "why do I need to get this big blockchain thing? why's all my bandwidth being used up?"⦠don't independent miners still have to do this even with gnash.io?
480 2014-06-13 13:29:16 <hearn> so there would be tens of thousands of independent miners
481 2014-06-13 13:29:49 <hearn> teaspoon: no, with pools like that you don't run your own copy of Bitcoin Core. hence the problem. you don't know what you're mining.
482 2014-06-13 13:29:53 <petertodd> teaspoon: miners != hashers - someone with hashing equipment just runs some tiny program that can almost run on a rasberry pi - they'll selling their hashing power to ghash.io and have nothing to do with block selection
483 2014-06-13 13:30:07 <hearn> teaspoon: there's a protocol called getblocktemplate that lets people pool whilst still building their own blocks, using their own Core. but it's not been a success.
484 2014-06-13 13:30:17 <dsnrk> ACTION remembers back to solo mining
485 2014-06-13 13:30:17 <teaspoon> I see
486 2014-06-13 13:30:29 <hearn> ACTION remembers mining a block or two with his laptop
487 2014-06-13 13:30:46 <dsnrk> heh, last year I worked out my time to block as being two weeks and just went for it
488 2014-06-13 13:30:49 <hearn> and asking satoshi why he had to wait for the coins to become spendable ..... good times :)
489 2014-06-13 13:30:51 <petertodd> I just can't see getblocktemplate catching on given it's higher bandwidth
490 2014-06-13 13:30:55 <Jouke> ACTION remembers mining a block with his phone.
491 2014-06-13 13:30:59 <Jouke> Too bad it was on testnet :(
492 2014-06-13 13:31:15 <hearn> dsnrk: what happened? i used to think asics would result in more solo mining as heck, if you just dropped 20k on a rig you're pretty serious and can afford to wait
493 2014-06-13 13:31:19 <teaspoon> so if you ignore the extra income they make with ghash.io then you still need to fund server for all the spawned instance?
494 2014-06-13 13:31:41 <hearn> petertodd: why is it higher bandwidth? i don't know much about it. you have to keep refetching a new template every few seconds or something?
495 2014-06-13 13:31:47 <petertodd> teaspoon: yup, that alone is a serious problem
496 2014-06-13 13:32:18 <teaspoon> ok, I'm getting a picture
497 2014-06-13 13:32:24 <teaspoon> nothing is possible without funding
498 2014-06-13 13:32:26 <petertodd> hearn: the templates are inherently much larger than shares
499 2014-06-13 13:32:29 <dsnrk> hearn: I got a block in about 150% of the time I expected. I was just about to give up when it cracked a block. I was pretty on edge waiting for the first blocks to be built on mine, I was terrified I was going to have it become stale.
500 2014-06-13 13:33:07 <petertodd> dsnrk: excellent point - mining is scary with high variance "Is it working?!"
501 2014-06-13 13:33:11 <hearn> dsnrk: how long could you have solo mined for without breaking your financial tolerances?
502 2014-06-13 13:33:32 <dsnrk> I did something bad actually, I return falsed the whole mempool section so I would make super tiny blocks that had a lower chance of being stale :(
503 2014-06-13 13:33:36 <teaspoon> is there a way satoshi can contribute without de-anonymizing himself? :P
504 2014-06-13 13:34:09 <dsnrk> hearn: at the time I would have been screwed if I didn't mine back the cost. bought the thing and then ran out of money for other reasons.
505 2014-06-13 13:34:09 <petertodd> teaspoon: satoshi was just a guy you know, he had some brilliant ideas, some good ones, and some aweful ones.
506 2014-06-13 13:34:13 <teaspoon> i.e. the bit coins mined at the beginning set up structures to save bit coin from itself later down the road
507 2014-06-13 13:34:54 <dsnrk> there's really nothing to say anything but the first block and the one sent to hal finney are Satoshi's at all
508 2014-06-13 13:35:03 <hearn> petertodd: isn't the response just a header plus coinbase, essentially?
509 2014-06-13 13:35:10 <teaspoon> have the bit coin core devs ever hinted at satoshi further funding the development project from his coins at a steady rate?
510 2014-06-13 13:36:27 <petertodd> hearn: for stratum, yeah, for getblocktemplate, particularly with pooled-solo mode, no.
511 2014-06-13 13:36:30 <hearn> teaspoon: funding is important but it's not the only issue
512 2014-06-13 13:36:45 <hearn> petertodd: i am reading https://en.bitcoin.it/wiki/Getblocktemplate and the example response doesn't seem very big?
513 2014-06-13 13:37:00 <teaspoon> but if you had funding you could mirror and multiply ghash.io services
514 2014-06-13 13:37:01 <hearn> teaspoon: i'm working on an app that would let us (the bitcoin community) more easily pool our funds, using assurance contracts.
515 2014-06-13 13:37:32 <petertodd> hearn: again, compare it to stratum
516 2014-06-13 13:37:36 <hearn> teaspoon: ghash.io does have competitors, and some of those have full time staff. it's not as simple as just finding money and then the problem gets solved. the question is: what are the solutions?
517 2014-06-13 13:38:09 <teaspoon> ok, that's a point
518 2014-06-13 13:38:42 <hearn> teaspoon: e.g. if everyone switched to using getblocktemplate, the issue would go away, largely. but see the criticism section of https://en.bitcoin.it/wiki/Stratum
519 2014-06-13 13:39:34 <teaspoon> I need to go and read about this orphan rate stuff any good sources for that?
520 2014-06-13 13:39:39 <hearn> teaspoon: in that case the community DID develop a better solution, and it didn't work out. whether that's because slush's pool didn't use it or because of bandwidth i can't say. but obviously this stuff doesn't just boil down simply
521 2014-06-13 13:39:55 <teaspoon> I want to understand why the largest pools can benefit their miners more
522 2014-06-13 13:40:45 <hearn> petertodd: i don't get it. stratum looks like a json based protocol as well as gbt (gah, json). where does the extra bandwidth go? are we talking about something fundamental here or something stupid like http headers?
523 2014-06-13 13:41:36 <petertodd> the bandwidth goes to the list of transactions, which is required if getblocktemplate is going to be of any value over stratum
524 2014-06-13 13:43:11 <hearn> ah. i see: the example has an empty transactions array i didn't spot. that's not a very helpful example.
525 2014-06-13 13:43:39 <hearn> i thought it allowed you to select your own list of transcations
526 2014-06-13 13:43:44 <hearn> am i getting confused with some other protocol?
527 2014-06-13 13:44:27 <petertodd> selecting your own list means you have to send them in the other direction with shares; even worse if you're allowed to select transactions the pool may not know about
528 2014-06-13 13:44:30 <teaspoon> when you talk about p2pool you aren't talking about this are you? http://p2pool.org/
529 2014-06-13 13:45:02 <hearn> right. this boils down to the same problem as reducing latency on block relay, doesn't it?
530 2014-06-13 13:45:22 <hearn> e.g. you could send just hashes and try to synchronize the memory pool
531 2014-06-13 13:45:25 <hearn> but still ..... blocks are small
532 2014-06-13 13:45:42 <hearn> and bandwidth seems cheap compared to the electricity cost of running a rig.
533 2014-06-13 13:46:07 <hearn> teaspoon: p2pool.in
534 2014-06-13 13:46:11 <petertodd> this stuff doesn't have to be entirely rational to matter... and of course, many get free electricity
535 2014-06-13 13:46:36 <petertodd> anyway, just having hashes isn't very useful unless you run a node, which ups costs even more
536 2014-06-13 13:47:01 <teaspoon> so are http://p2pool.org/ some scammers that try to benefit from the name?
537 2014-06-13 13:47:46 <hearn> it's perhaps some misguided people who don't understand the point of p2pool
538 2014-06-13 13:47:51 <hearn> i am not sure it's a scam, per se
539 2014-06-13 13:48:31 <dsnrk> teaspoon: yes
540 2014-06-13 13:48:53 <hearn> teaspoon: if you want to work on it, probably making a single one-click bundle that has a Bitcoin Core (with pre-downloaded/indexed chain!) and is set up to use getblocktemplate with a supported pool .... that *might* help.
541 2014-06-13 13:49:16 <hearn> teaspoon: for people where their bandwidth/cpu is just fine, but they're basically lazy
542 2014-06-13 13:49:50 <dsnrk> hearn: distributing pre-indexed blocks sets an ugly precedent
543 2014-06-13 13:50:40 <hearn> it makes no difference. unless you're reproducing the build, you're running an opaque binary anyway. given that this product would be designed for "lazy people" they're not gonna reproduce the build anyway
544 2014-06-13 13:50:48 <tjopper1> teaspoon: http://p2pool.in/ or contact forrestv
545 2014-06-13 13:51:27 <hearn> anyway, battery is going to die. ciao for now.
546 2014-06-13 13:52:00 <dsnrk> hearn: if people start downloading "ready to go" chainstates you can get into a position where a large number of nodes have fake entries in their UXTO
547 2014-06-13 13:52:19 <teaspoon> thanks for the answers
548 2014-06-13 13:52:25 <teaspoon> ciao
549 2014-06-13 13:52:30 <dsnrk> o/
550 2014-06-13 14:26:46 <chichov> is it possible to make P2SH with 1-of-5 multisig transactions right now?
551 2014-06-13 14:27:22 <chichov> or even m-of-5
552 2014-06-13 14:27:56 <chichov> or if there is still the hard limit of m-of-3
553 2014-06-13 14:32:08 <dabura667> limit for n is 16
554 2014-06-13 14:32:19 <dabura667> any config is possible if you can get it mined.
555 2014-06-13 14:32:37 <dabura667> the widely accepted ones are 2 of 2 and 2 of 3
556 2014-06-13 14:33:21 <dabura667> and the one you have to worry about getting accepted is not sending TO the 9 of 16, it's sending FROM the 9 of 16.
557 2014-06-13 14:34:05 <dabura667> 16 is a hard limit on the number of bytes able to be put into ScriptSig
558 2014-06-13 14:34:57 <dabura667> err scriptPubkey?
559 2014-06-13 14:35:04 <dabura667> I mix those up a lot...
560 2014-06-13 14:45:38 <Guest14473> chichov: there is no hard limit
561 2014-06-13 14:48:25 <elichai2> petertodd: i just read what 'replace-by-fee' is, and you really think it's a good idea to create a tool like that?
562 2014-06-13 14:51:22 <chichov> not entirely true guys
563 2014-06-13 14:51:52 <waxwing> dabura667, the limit is 15 not 16 I believe
564 2014-06-13 14:52:24 <chichov> let me point out some code, mom
565 2014-06-13 14:53:58 <dsnrk> you're limited by the maximum transaction size. the limit is partly based on your pubkeys being compressed or not.
566 2014-06-13 14:54:13 <chichov> scriptSig is currently limited to 500 bytes, which is intended to be 1650 bytes (see https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L528)
567 2014-06-13 14:54:46 <dabura667> waxwing meh, somewhere around there. 33 bytes times 15 is 495....... seems legit
568 2014-06-13 14:55:37 <sipa> chichov: please distinguish standardness rules and consensus rules :)
569 2014-06-13 14:56:03 <chichov> and in script.cpp IsStandard checks whether n <= 3
570 2014-06-13 14:56:47 <waxwing> the relevant limit for N (in M of N) is the 520 byte redeemscript limit
571 2014-06-13 14:59:03 <chichov> there's more than just that
572 2014-06-13 14:59:55 <chichov> are transactions with n > 3 currently non-standard?
573 2014-06-13 15:00:28 <sipa> raw multisig, yes
574 2014-06-13 15:00:34 <sipa> for p2sh that rule isn't enforced
575 2014-06-13 15:00:42 <chichov> oh, that's interesting
576 2014-06-13 15:01:17 <chichov> then we are only left with scriptSig size (500 bytes)
577 2014-06-13 15:01:27 <sipa> for now
578 2014-06-13 15:01:36 <chichov> yep, soon to be 1650
579 2014-06-13 15:02:27 <waxwing> isn't the 520 byte rule still going to be enforced sipa ? i seem to remember you telling me that was not going to change.
580 2014-06-13 15:02:34 <sipa> yes
581 2014-06-13 15:02:41 <sipa> the 520 byte limit is a consensus rule
582 2014-06-13 15:02:45 <sipa> it would require a hard fork
583 2014-06-13 15:02:52 <waxwing> yes, so the limit is 15 for N
584 2014-06-13 15:03:01 <sipa> s15 or 16, indeed
585 2014-06-13 15:03:23 <sipa> 15, sorry
586 2014-06-13 15:03:29 <sipa> waxwing: but only for p2sh
587 2014-06-13 15:03:57 <waxwing> right
588 2014-06-13 15:04:00 <sipa> raw multisig (which is by isstandard limited to n-of-3) can go up to 20-of-20 wrt consensus rules
589 2014-06-13 15:04:03 <chichov> waxwing: once scriptSig is allowed to be 1650 bytes, you can use scripts of up to 520 bytes
590 2014-06-13 15:07:00 <chichov> I see that at the moment we can manage at best 4-of-4 or 1-of-12
591 2014-06-13 15:07:32 <chichov> for signatures of 73 bytes and pubkeys of 33 bytes
592 2014-06-13 15:07:32 <waxwing> chichov, are you talking about p2sh or raw msig?
593 2014-06-13 15:07:38 <chichov> p2sh of course
594 2014-06-13 15:07:57 <waxwing> then you can do more than 4/4 or 1/12
595 2014-06-13 15:08:01 <chichov> as sipa pointed out, for raw multisig we have the standardness rule of n <= 3
596 2014-06-13 15:08:17 <waxwing> i've done 8 of 15 for example
597 2014-06-13 15:08:20 <chichov> nope, scriptSig size is 500 bytes maximum in 0.9.1
598 2014-06-13 15:08:38 <chichov> which version?
599 2014-06-13 15:08:48 <waxwing> not standard of course; via eligius
600 2014-06-13 15:08:55 <chichov> my bad, 0.9.0* I see here
601 2014-06-13 15:09:07 <chichov> oh well, I'm talking about standard transactions
602 2014-06-13 15:09:28 <waxwing> but now with this new 1650 thing, i don't see why you wouldn't be able to do the same on that?
603 2014-06-13 15:09:43 <chichov> I think you're mistaking some things
604 2014-06-13 15:10:13 <sipa> tell me 1) consensus or standardness 2) raw or p2sh 3) 0.9 or head
605 2014-06-13 15:10:14 <chichov> look, for example version 0.9.0 restricts the scriptSig size to 500 bytes
606 2014-06-13 15:10:17 <sipa> and i'll tell you the limit :)
607 2014-06-13 15:10:55 <chichov> could you point out the difference between consensus and standardness?
608 2014-06-13 15:11:27 <sipa> standardness: whether the reference client will relay/mine it
609 2014-06-13 15:11:35 <sipa> consensus: whether it's valid inside a block
610 2014-06-13 15:11:42 <chichov> ah yea, that way
611 2014-06-13 15:11:47 <sipa> standardness is policy
612 2014-06-13 15:11:53 <sipa> consensus is validity
613 2014-06-13 15:11:58 <chichov> alright, noted
614 2014-06-13 15:12:21 <chichov> for 1) standardness 2) p2sh 3) 0.9 then
615 2014-06-13 15:12:31 <chichov> and for 1) standardness 2) p2sh and 3) head
616 2014-06-13 15:12:32 <michagogo> 500 bytes