1 2014-01-08 00:00:15 <shesek> tho I'm not sure if that works only on text or on byte streams too, never tried it
  2 2014-01-08 00:00:49 <michagogo> cloud|shesek: I know what sed is
  3 2014-01-08 00:01:04 <michagogo> cloud|But which files are you referring to?
  4 2014-01-08 00:01:09 <michagogo> cloud|You can't just substitute all instances of netmagic
  5 2014-01-08 00:01:21 <shesek> you'll need a way to tell apart magic bytes from other places it randomly appears as part of something else
  6 2014-01-08 00:01:29 <michagogo> cloud|Because it may occur within a block
  7 2014-01-08 00:01:47 <shesek> ... yeah, its probably best to use something that actually understands the blockchain's structure
  8 2014-01-08 00:02:09 <michagogo> cloud|shesek: easiest way is just to use linearize.py, I'd imagine
  9 2014-01-08 00:03:19 <michagogo> cloud|Just change the line for the new magic
 10 2014-01-08 00:06:28 <michagogo> cloud|Hmm, linearize.py probably requires that you be running git master, right?
 11 2014-01-08 00:07:47 <michagogo> cloud|super3: how hard would it actually be to generate a list of parameters from each altcoin on coingen?
 12 2014-01-08 00:14:31 <atian> test
 13 2014-01-08 00:14:33 <atian> !oubg
 14 2014-01-08 00:14:33 <gribble> Error: "oubg" is not a valid command.
 15 2014-01-08 01:28:56 <super3> michagogo|cloud, what do you mean
 16 2014-01-08 01:29:12 <super3> also its seems like coingen.io just got picked up by the guardian
 17 2014-01-08 01:29:13 <super3> http://www.theguardian.com/technology/2014/jan/07/bitcoin-me-how-to-make-your-own-digital-currency
 18 2014-01-08 01:29:24 <super3> and slashdot
 19 2014-01-08 01:29:25 <super3> http://news.slashdot.org/story/14/01/07/2134242/how-to-create-your-own-cryptocurrency
 20 2014-01-08 03:04:46 <warren> Ryan52: ping
 21 2014-01-08 04:50:00 <lechuga__> does a notion of max_txns per template still make sense?
 22 2014-01-08 04:50:03 <lechuga__> misfire
 23 2014-01-08 05:24:58 <michagogo> cloud|super3: I mean, a list of all the coingen coins and what their parameters are
 24 2014-01-08 05:25:36 <michagogo> cloud|)
 25 2014-01-08 05:25:36 <michagogo> cloud|(PoW, port, source included, as well as the blockchain params
 26 2014-01-08 06:11:04 <super3> yeah thats in the roadmap
 27 2014-01-08 06:11:35 <super3> michagogo|cloud, unless i sell it tonight, already have a decent offer
 28 2014-01-08 06:16:22 <michagogo> cloud|super3: heh, trading hands quite a bit
 29 2014-01-08 06:16:51 <michagogo> cloud|How much did you pay for it?
 30 2014-01-08 06:16:54 <super3> heh its like pandoras box
 31 2014-01-08 06:18:53 <michagogo> cloud|super3: is there a chance you could generate a one-off list, even if you don't end up adding the params to the status page?
 32 2014-01-08 06:19:41 <michagogo> cloud|I'm really curious to see how many leave the parameters untouched, leaving then as exact bitcoin clones
 33 2014-01-08 06:19:45 <michagogo> cloud|Them*
 34 2014-01-08 06:20:02 <super3> i'd have to get all the old stats from matt
 35 2014-01-08 06:21:12 <super3> lol, enough
 36 2014-01-08 06:22:15 <super3> michagogo|cloud, you seem pretty intrested in it. i can offer it to you as well if you want.
 37 2014-01-08 06:24:32 <michagogo> cloud|Meh, I don't really have much time to advance it or update it or work on it
 38 2014-01-08 06:26:02 <michagogo> cloud|(Also, I'm not too familiar with Bitcoin's source and I don't know C++, so I wouldn't really know how to make changes
 39 2014-01-08 06:26:12 <michagogo> cloud|)
 40 2014-01-08 07:58:29 <warren> sipa: I've confirmed with 95% certainty that the upgrade to boost-1.54 introduced some kind of networking failure issue on some windows machines.
 41 2014-01-08 07:58:58 <warren> preliminary tests suggests that boost-1.55 isn't better
 42 2014-01-08 07:59:05 <warren> downgrading to 1.50 seems to fix it
 43 2014-01-08 08:44:14 <paavo> are there any people interested in creating a voting system based on bitcoin like technologies?
 44 2014-01-08 08:49:19 <gmaxwell> paavo: offtopic for this channel, though it's a oft repeated (in my opinion) bad idea. There is a vast body of literature on cryptographic voting systems and blockchains do not solve any of their problems (and, in fact, a bunch more serious ones of their own).
 45 2014-01-08 08:50:12 <gmaxwell> paavo: you might want to talk to justanotheruser though, as I was recently trying to convince them that they were all-things-are-nailsing it with similar thinking and I don't know if I was successful.
 46 2014-01-08 08:51:00 <gmaxwell> paavo: though I beg you to conserve your time by searching and reading the existing cryptographic voting literature first. (e.g. google cryptographic voting)
 47 2014-01-08 08:51:02 <paavo> i understand your sentiment...
 48 2014-01-08 08:51:54 <paavo> was simply looking here for sources or connections to similar thinking
 49 2014-01-08 08:52:08 <paavo> the next logical step
 50 2014-01-08 08:52:23 <justanotheruser> gmaxwell: yeah, pretty much. I think it was petertodd who linked me to some voting scheme that solved the same problems my idea would have
 51 2014-01-08 08:52:34 <justanotheruser> plus it was peer reviewed
 52 2014-01-08 08:52:55 <paavo> politicians are to voting is what banks are to money
 53 2014-01-08 08:53:23 <justanotheruser> paavo: I can give politicians 1 vote and that vote will get compounding interest?
 54 2014-01-08 08:53:32 <paavo> exactly
 55 2014-01-08 08:53:35 <justanotheruser> lol
 56 2014-01-08 08:53:41 <paavo> they can now vote for whatever they want once theyre in
 57 2014-01-08 08:53:44 <gmaxwell> I've seen it proposed at least two dozen times, but every time I believe the person proposing it was confused— or just hadn't thought through— what problems bitcoin solves, what problems voting systems have, and weren't at all informed about the extensive work that has gone on in that space.
 58 2014-01-08 08:54:17 <gmaxwell> so no, I don't have any citations to it, but really I think if you go read up on cryptographic voting you'll be in a much better position to ask good questions.
 59 2014-01-08 08:54:17 <justanotheruser> gmaxwell: what problems do you think can be solved by bitcoin that aren't financial?
 60 2014-01-08 08:54:23 <paavo> we need a system to dismantle decision making from select few to the masses
 61 2014-01-08 08:54:35 <justanotheruser> other than being data storage (nmc)
 62 2014-01-08 08:55:12 <gmaxwell> justanotheruser: well, thats a tricky question, because it's not clear that POW consensus works outside of narrow economic incentives! though even ignoring that I could try to answer the question.
 63 2014-01-08 08:56:23 <paavo> using a specific pgp-like unique key could every us citizen vote for a bill going through congress?
 64 2014-01-08 08:56:44 <paavo> remove politicians and have an open platform for discussion
 65 2014-01-08 08:56:49 <justanotheruser> gmaxwell: merged mining with a little incentive for solving each block could make a blockchain work though
 66 2014-01-08 08:56:50 <paavo> with reddit like upvoting
 67 2014-01-08 08:56:56 <gmaxwell> — first bitcoin gives you a consensus, but not a strongly censorship resistant one... so whatever applications have to need a consensus. Secondly, bitcoin like systems are global (it's not clear if POW works on a localized basis! since indifferent hashpower from elsewhere might be bought to attack) ... so it has to be a consensus which operates at a scale where sharing it globally is viable.
 68 2014-01-08 08:57:19 <gmaxwell> justanotheruser: but where does the incentive come from and what form does it take? who provides it?   Bitcoin can provide its own, which is somewhat special.
 69 2014-01-08 08:58:15 <gmaxwell> justanotheruser: so _naming_ (not data storage) actually does need a consensus, and if the namespace is a global one, then you meet the above criteria.  (except for the incentives stuff, I don't think we really know how to make incentives work there, nmc is kind of a falure wrt that)
 70 2014-01-08 08:58:32 <paavo> how about a decentralized system of pgp registry
 71 2014-01-08 08:58:35 <gmaxwell> (you need a consensus for naming in order to resolve zooko's triangle)
 72 2014-01-08 08:58:55 <gmaxwell> paavo: pgp doesn't appear to need a consensus. Seems to work okay without one today at least.
 73 2014-01-08 08:58:55 <justanotheruser> gmaxwell: some how doing the PoW for this altchain would have to give you payment in bitcoins. Perhaps using bitcoin scripts (including disabled scripts) you could determine if a block was solved in this altchain
 74 2014-01-08 08:59:20 <gmaxwell> justanotheruser: yea, maybe. (I note that the same mechenism we talked about for the 2-way-peg could accomplish that)
 75 2014-01-08 08:59:20 <justanotheruser> ofcourse that means someone would have to pay for this system to function
 76 2014-01-08 08:59:35 <gmaxwell> justanotheruser: right which means you need to have a way to gather those funds.
 77 2014-01-08 08:59:38 <paavo> for example: store unique key alongside identity verification in blockchain
 78 2014-01-08 08:59:40 <gmaxwell> which excludes some applications.
 79 2014-01-08 09:00:00 <gmaxwell> paavo: thats not an application, its a mechenism. What goal do you hope to provide?
 80 2014-01-08 09:00:23 <paavo> decentralized voting for implementing general law
 81 2014-01-08 09:00:55 <paavo> an alternative to politician based lawmaking
 82 2014-01-08 09:01:26 <paavo> im hoping to generate blood flow in this area
 83 2014-01-08 09:01:35 <gmaxwell> paavo: see what I said before, I don't think voting is an application that you need or want any technology from bitcoin for... there is other neat technology for voting unrelated to bitcoin which people have been working on for 20 years.
 84 2014-01-08 09:01:54 <paavo> hmm i guess im impatient
 85 2014-01-08 09:01:56 <paavo> lol
 86 2014-01-08 09:02:01 <paavo> ok will go read some
 87 2014-01-08 09:02:01 <sipa> how do you prevent people from creating two identities, and voting twice?
 88 2014-01-08 09:02:16 <sipa> how do you prevent miners from censoring votes?
 89 2014-01-08 09:02:24 <paavo> i know thats a problem but blockchain did some remarkable things for trustless value
 90 2014-01-08 09:02:33 <wumpus> gmaxwell: I think people only look at the sorry state of current voting machines, not at all the research that other people did and didn't get actually implemented :/
 91 2014-01-08 09:02:52 <paavo> im continuing the optimistic thread
 92 2014-01-08 09:03:02 <justanotheruser> gmaxwell: why is namecoin a failure in that regard? They are $8 a piece. It costs significantly less than the block reward to merged mine them
 93 2014-01-08 09:03:37 <justanotheruser> paavo: even if you had this system running, a direct democracy usually doesn't work
 94 2014-01-08 09:03:47 <paavo> example?
 95 2014-01-08 09:04:22 <wumpus> it looks to me that at this stage the challenge is getting governments to adapt the ideas/technologies, not so much developing the ideas
 96 2014-01-08 09:04:33 <justanotheruser> paavo: I mean that on a national scale
 97 2014-01-08 09:05:23 <paavo> a general concensus is bad?
 98 2014-01-08 09:05:24 <gmaxwell> justanotheruser: because the name database has been stuffed full of people mass registering like every typable string. Almost no one cares about it for name resolution, almost no one is using it for name resolution, e.g. it's just another litecoin right now.
 99 2014-01-08 09:05:42 <paavo> wumpus: its not about what governments want... its about what people want
100 2014-01-08 09:05:48 <gmaxwell> wumpus: yea, cryptographic voting has basically nothing to do with the electronic voting machines that are deployed in the US at least.
101 2014-01-08 09:06:00 <justanotheruser> paavo: when you have 51% of people telling 49% of people what to do it is a problem.
102 2014-01-08 09:06:16 <sipa> please no political discussion in hete
103 2014-01-08 09:06:22 <sipa> in here
104 2014-01-08 09:06:26 <paavo> when you have 1% of politicians telling 99% of people what to do thats a problem
105 2014-01-08 09:06:28 <wumpus> gmaxwell: exactly...
106 2014-01-08 09:06:32 <justanotheruser> #bitcoin-politics if you want to discuss this further
107 2014-01-08 09:06:55 <paavo> im not here to discus politics
108 2014-01-08 09:07:52 <sipa> regardless of that, i agree with gmaxwell that a blockchain is a completely wrong tool for dealing with voting
109 2014-01-08 09:08:04 <paavo> i want ideas on generating unique internet identities that correlate to real human beings without double spend voting
110 2014-01-08 09:08:27 <sipa> you start off by having human identities
111 2014-01-08 09:08:28 <justanotheruser> gmaxwell: Is there a way to prevent the mass registration problem? Like making only 500 new domains registerable per day?
112 2014-01-08 09:09:03 <sipa> there is no need for the humongous overhead a blockchain adds if the jdentities are known in advance
113 2014-01-08 09:09:30 <paavo> but imagine a baby is born... a unique ssn-like key is created
114 2014-01-08 09:09:36 <paavo> thats their *voting key
115 2014-01-08 09:09:41 <paavo> no one else can use it
116 2014-01-08 09:09:49 <justanotheruser> paavo: who determines who controls their key?
117 2014-01-08 09:09:58 <justanotheruser> and issues their key
118 2014-01-08 09:10:04 <paavo> parents or given agency
119 2014-01-08 09:10:09 <paavo> just like ssn
120 2014-01-08 09:10:28 <gmaxwell> justanotheruser: NMC used fixed transaction fees, but then they got irritated with the pump and dumping and in the hardfork they upped the schedule for them to go down. That didn't stop the pump/dump much but it did encourage mass registration.
121 2014-01-08 09:11:09 <justanotheruser> "upped the schedule for them to go down." what?
122 2014-01-08 09:11:11 <sipa> aaaaargh if you have an single (or few) known instances handing out the identities, what do you need a blockchain for?
123 2014-01-08 09:11:37 <paavo> difficult to say
124 2014-01-08 09:11:39 <sipa> people seem to see it as this solves-everything uncensorable data storage and communjcation system
125 2014-01-08 09:11:51 <paavo> this discussion probably more likely to take place in a few more decades
126 2014-01-08 09:11:55 <sipa> it is horribly bad at those things
127 2014-01-08 09:12:10 <paavo> sipa dont be closed minded
128 2014-01-08 09:12:11 <gmaxwell> justanotheruser: they had a foo-flation schedule for the fixed fees to register a domain such that the cost went down over time. when they hardforked to add merged mining they changed it to make it go down much much faster.
129 2014-01-08 09:12:20 <paavo> the possibility is there
130 2014-01-08 09:12:21 <sipa> paavo: please
131 2014-01-08 09:12:32 <sipa> of course the possibility is there
132 2014-01-08 09:12:33 <paavo> there is a way for everything
133 2014-01-08 09:12:39 <gmaxwell> paavo: it's not a "closed minded" thing, Bitcoin is very technically poor for those purposes.
134 2014-01-08 09:12:42 <sipa> it just doesn't gain you anything
135 2014-01-08 09:12:51 <paavo> im not talking about bitcoin
136 2014-01-08 09:12:59 <paavo> im talking about related technologies
137 2014-01-08 09:13:07 <gmaxwell> paavo: it's like saying why don't we do evoting via world of warcraft. Surely there is a way to accomplish that, but what did you gain?
138 2014-01-08 09:13:07 <paavo> thought you people would be interesting to talk to
139 2014-01-08 09:13:08 <sipa> s/Bitcoin/blockchains/
140 2014-01-08 09:14:17 <paavo> ok you're right we shouldnt discus this
141 2014-01-08 09:14:33 <paavo> let's forget solving problems
142 2014-01-08 09:14:40 <paavo> its kinda hard rn
143 2014-01-08 09:14:48 <paavo> so probably not worth it
144 2014-01-08 09:14:56 <paavo> bye
145 2014-01-08 09:15:06 <sipa> being hard is a bad reason for not solving it
146 2014-01-08 09:15:18 <justanotheruser> gmaxwell: seems silly to automatically lower the price of registration. You cannot predict that the price will rise over time, but that is the only reason I could see for lowing the price in namecoins for registration
147 2014-01-08 09:16:10 <gmaxwell> justanotheruser: well part of the idea was to help distribute the names in an economically efficient way by giving people willing the pay the most namecoins first dibbs.
148 2014-01-08 09:16:34 <gmaxwell> if all people who ever would use namecoin all heard of it at once this might have been a pretty good strategy.
149 2014-01-08 09:16:52 <gmaxwell> e.g. "we don't care what it's worth, when the price matches what you'll pay— then you get a name"
150 2014-01-08 09:17:43 <gmaxwell> other alternatives like starting an auction when someone tries to grab a name have other annoying failure modes.
151 2014-01-08 09:17:44 <justanotheruser> seems like it would be better to set a registration limit to either a set number, or a value based on the transaction fee sum
152 2014-01-08 09:18:00 <gmaxwell> this is really #wizards talk
153 2014-01-08 09:18:51 <gmaxwell> justanotheruser: join -wizards. :P
154 2014-01-08 09:19:07 <justanotheruser> oh, I didn't even realize I wasn't in there
155 2014-01-08 10:05:10 <wumpus> I'd really appreciate if some people helped testing https://github.com/bitcoin/bitcoin/pull/3493, it makes initialization/shutdown user friendlier, and may solve the ubuntu menu issues due to timeouts
156 2014-01-08 10:06:43 <warren> https://github.com/bitcoin/bitcoin/issues/3494#issuecomment-31817423   <--- boost-1.54 upgrade seems to cause networking failures, relevant because bitcoin master has this now.
157 2014-01-08 11:34:57 <sipa> warren: the boost problem may be indirect, where somehow it maybe causes a deadlock in block processing or rpc, and the result is that p2p processing can't get a lock anymore
158 2014-01-08 11:35:10 <sipa> warren: but the p2p code itself doesn't use anything boost at all, afaik
159 2014-01-08 11:37:06 <warren> sipa: I had similar thoughts
160 2014-01-08 11:37:23 <warren> sipa: this is another one of those bugs that I can't reproduce on any machines i have access to
161 2014-01-08 12:23:21 <guysoft42> hey all, is there anyone that could guide me how to fix this qt dialog? https://github.com/bitcoin/bitcoin/issues/1629
162 2014-01-08 12:36:07 <wumpus> guysoft42: the dialog is already a lot different in master
163 2014-01-08 12:36:16 <wumpus> guysoft42: so I suggest building master first
164 2014-01-08 12:36:34 <wumpus> then decide whether there is still something to fix...
165 2014-01-08 12:37:45 <sipa> also, the logic about determining the minimum relay fee is about to change significantly
166 2014-01-08 12:38:17 <sipa> and about being able to bypass it: absolutely, but only when the client can actually deal with non-confirming transactions (which is a bug on its own, right now)
167 2014-01-08 12:40:19 <wumpus> how would it ideally deal with non-confirming transactions?
168 2014-01-08 12:40:31 <wumpus> time them out after a while and stop showing/broadcasting them?
169 2014-01-08 12:41:09 <sipa> actually have a dependency graph of transactions in the wallet
170 2014-01-08 12:41:34 <sipa> and not consider them all ultimately valid, even if they conflict with eachother or with the blockchain
171 2014-01-08 12:41:58 <wumpus> sure, but that would not get rid of non-confirming transactions
172 2014-01-08 12:42:09 <sipa> it would make the client deal with it
173 2014-01-08 12:42:22 <sipa> by being able to disable/delete them after some time
174 2014-01-08 12:42:28 <wumpus> it would still be impossible to re-spend the coins held up in the non-confirming transaction, for example
175 2014-01-08 12:42:48 <sipa> sorry, i'm thinking a step ahead
176 2014-01-08 12:43:00 <sipa> the point is of course being able to delete transactions from the wallet
177 2014-01-08 12:43:08 <sipa> or at least mark them inactive
178 2014-01-08 12:43:14 <wumpus> right
179 2014-01-08 12:43:33 <sipa> or even do so automatically if they are found to conflict with the blockchain
180 2014-01-08 12:43:59 <sipa> right now, the data structures just don't allow that
181 2014-01-08 12:44:10 <wumpus> yes, after doing double-spend detection of some kind
182 2014-01-08 12:44:15 <sipa> as we keep a flag for each wallet txout to remember whether it is sprnt or not
183 2014-01-08 12:44:40 <wumpus> another problem with the wallet data structures, add it to the list :/
184 2014-01-08 12:45:07 <sipa> that should just go away and be replaced with dependency analysis: if no active wallet tx exists that spends an IsMine() txout, it is available
185 2014-01-08 12:45:37 <wumpus> I'm more and more thinking that the best would be to entirely rewrite a wallet from scratch
186 2014-01-08 12:45:55 <wumpus> with new-fangled requirements for data structures, storage, determinism, etc
187 2014-01-08 12:46:01 <sipa> yep
188 2014-01-08 12:46:21 <sipa> with some modularization, it should not be hard to have both an old and a new wallet implementation
189 2014-01-08 12:47:14 <wumpus> yes, that was what, among other things, triggered my post-0.9 modularization idea
190 2014-01-08 12:47:17 <sipa> i figured
191 2014-01-08 12:51:32 <sipa> now add a REST interface for everything non-wallet, and we can drop RPC too
192 2014-01-08 12:51:53 <sipa> and start over with a clean wallet implementation and consistent interface to it...
193 2014-01-08 12:51:56 <wumpus> indeed
194 2014-01-08 12:53:33 <wumpus> and drop the 'accounts' functionality, everyone wants something else anyway, it should be a layer on top not part of the wallet
195 2014-01-08 12:54:09 <sipa> if it is retained, it should be at least optional and not intermingled with something else (labels)
196 2014-01-08 12:54:38 <wumpus> it's too confusing, people not only confuse it with labels, but also with groups of addresses and inputs
197 2014-01-08 12:55:17 <wumpus> multiwallet would be a better solution to most people's uses
198 2014-01-08 12:55:25 <sipa> absolutely
199 2014-01-08 12:55:49 <sipa> multiwallet should be much higher priority than anything that tries to replace accounts (if anything)
200 2014-01-08 12:56:28 <sipa> also a current problem with the wallet interface is that there is really no middle ground
201 2014-01-08 12:56:39 <wumpus>  multiwallet would be pretty easy to do even from the current starting point, biggest thing holding it back is the RPC interface (and how to handle the storage, right now all the wallets have to be in one directory because bdb)
202 2014-01-08 12:56:54 <sipa> either you have coin tracking, tx construction, maintaining a ledger, ... done bitcoind
203 2014-01-08 12:57:10 <sipa> or you do pretty much everything yourself using raw tx interface
204 2014-01-08 12:59:15 <wumpus> if the wallet would run in a seperate process, it'd be even easier to do multiwallet, just spin up multiple wallet daemons
205 2014-01-08 13:00:21 <wumpus> they couldn't share a bdb environment in that case, but heh...
206 2014-01-08 13:36:32 <guysoft42> wumpus, will do :)
207 2014-01-08 13:37:56 <guysoft42> wumpus, i can't seem to get qmake to build, only bitcoin-cli any recent documents about how going around that?
208 2014-01-08 13:41:24 <wumpus> guysoft42: there is no qmake anymore in master, it's all based on autoconf
209 2014-01-08 13:41:34 <wumpus> guysoft42: documentation is in doc/build-unix.md
210 2014-01-08 14:33:14 <nightlingo> guys... what is the best way to calculate the transaction fee ?
211 2014-01-08 14:53:15 <helo> nightlingo: i don't think anyone knows :/
212 2014-01-08 14:53:46 <CodeShark> yeah, it's actually one of the "harder" problems I've been facing in building wallets
213 2014-01-08 14:53:48 <CodeShark> lol
214 2014-01-08 14:54:08 <CodeShark> that and coin selection are probably the two least well-defined problems
215 2014-01-08 14:54:51 <CodeShark> as for setting a fee, at the very least make sure the transaction gets relayed by bitcoind
216 2014-01-08 14:55:24 <CodeShark> it might take a long time to confirm if the fee is very low but at least it will most likely confirm sooner or later
217 2014-01-08 14:57:31 <helo> it's a weird one-side-blind orderbook... it is easy to see ~all of the bids in the order book, but only individual miners know only their asks.
218 2014-01-08 14:58:09 <guysoft42> wumpus, ok compiled bitcoin-qt from master, there is a huge "this is a pre-release build" warning. How do I test the the transfer dialog without messing up my wallet?
219 2014-01-08 14:58:35 <sipa> guysoft42: use testnet?
220 2014-01-08 14:58:47 <guysoft42> sipa, there is a test net?
221 2014-01-08 14:58:53 <sipa> yes, run with -testnet
222 2014-01-08 14:59:03 <sipa> and google for testnet faucet if you need some testnet coins
223 2014-01-08 14:59:07 <guysoft42> sipa, oo its green :)
224 2014-01-08 15:01:23 <guysoft42> sipa, ok, no receive address and its syncing 83 weeks
225 2014-01-08 15:02:20 <nightlingo> thanks guys
226 2014-01-08 15:02:49 <nightlingo> I was wodering...   can you see the transaction fees paid by inspecting the blockchain ?
227 2014-01-08 15:02:55 <nightlingo> using bitcoind commands ?
228 2014-01-08 15:03:44 <michagogo> cloud|nightlingo: Sort of
229 2014-01-08 15:04:02 <michagogo> cloud|It won't tell you the fee, but (if you have txindex on) you can subtract outputs from inputs to get the fee
230 2014-01-08 15:05:13 <nightlingo> oh so the formula is: I  sum up all the outputs of a transaction and subtract them from the sum of all the inputs ?
231 2014-01-08 15:05:35 <Ry4an> s/them from/from them/
232 2014-01-08 15:06:01 <michagogo> cloud|Ry4an: no
233 2014-01-08 15:06:04 <michagogo> cloud|nightlingo: yes
234 2014-01-08 15:06:10 <nightlingo> cool thanks :)
235 2014-01-08 15:07:37 <michagogo> cloud|So if a transaction spends an output of 100000000 satoshis and creates an output of 99900000 satoshis, that transaction has a fee of 100000 satoshis
236 2014-01-08 15:10:41 <nightlingo> michagogo|cloud great :)
237 2014-01-08 15:11:30 <Ry4an> ah, yeah, I misread.  Sorry :|
238 2014-01-08 16:00:33 <michagogo> cloud|If a datadir is being used with v0.8.6, does running current git master make any changes that would make anything in the datadir incompatible with going back to v0.8.6?
239 2014-01-08 16:03:57 <sipa> michagogo|cloud: no
240 2014-01-08 16:04:08 <michagogo> cloud|Okay, thanks.
241 2014-01-08 16:04:12 <jgarzik> no
242 2014-01-08 16:04:14 <michagogo> cloud|(didn't think so...)
243 2014-01-08 16:04:55 <sipa> if headersfirst goes it, the format will likely change
244 2014-01-08 16:20:05 <guysoft42> dont seem to be getting testnet coins from tpfaucet
245 2014-01-08 16:20:57 <guysoft42> is there a way to view the testnet blockchain?
246 2014-01-08 16:22:41 <helo> i can give you some, send me your address
247 2014-01-08 16:33:57 <guysoft42> nevrmind, it came though. I am rich! now lets make a bug that will make me loose all the netcoins and become a legend
248 2014-01-08 17:56:37 <gmaxwell> sipa: hashrate is off your charts again
249 2014-01-08 17:57:03 <gmaxwell> (and/or you've stopped updating, it can be hard to tell)
250 2014-01-08 17:57:32 <devrandom> maybe he likes it that way - "it's off the charts!" :)
251 2014-01-08 18:21:58 <sipa> "It's *LITERALLY* off the charts!!!!111"
252 2014-01-08 18:22:18 <sipa> updating
253 2014-01-08 18:31:24 <michagogo> cloud|Hmm, something just occurred to me re:coingen coins having Bitcoin's parameters and genesis block, with just magic bytes changed
254 2014-01-08 18:32:29 <michagogo> cloud|I'd been thinking that you could attack them by using linearize.py and just changing the bytes that it inserts
255 2014-01-08 18:32:44 <michagogo> cloud|But another way just occurred to me
256 2014-01-08 18:33:07 <maaku> michagogo|cloud: yes, this was discussed here or on -wizards yesterday
257 2014-01-08 18:33:37 <michagogo> cloud|maaku: I know
258 2014-01-08 18:33:44 <michagogo> cloud|About 19-20 hours ago
259 2014-01-08 18:34:00 <maaku> at the very least for any coin you can snag the first 4032 blocks
260 2014-01-08 18:34:16 <michagogo> cloud|I just realized you can do it by using the output of getblock to feed to submit block
261 2014-01-08 18:34:43 <michagogo> cloud|(Talking about feeding the altcoin Bitcoin's chain)
262 2014-01-08 18:35:05 <michagogo> cloud|also, I meat submitblock
263 2014-01-08 18:35:11 <michagogo> cloud|(Autocorrect)
264 2014-01-08 18:35:26 <maaku> yeah, that'd be easy to script up
265 2014-01-08 18:35:28 <michagogo> cloud|Meant*
266 2014-01-08 18:35:45 <michagogo> cloud|A 1-liner, even
267 2014-01-08 18:38:47 <michagogo> cloud|(1..270000).each { |n| `altcoind submitblock #{`bitcoind getblock #{`bitcoind getblockhash #{n}`}`}`}
268 2014-01-08 18:48:47 <jgarzik> 
ACTION builds 0.8.6...  man, this build system is soooo ancient!

269 2014-01-08 18:50:18 <sipa> it's cutting edge 1977 technolgy
270 2014-01-08 18:51:26 <TheLordOfTime> heh
271 2014-01-08 18:52:03 <wumpus> autotools really works a lot better, I'm glad we made the switch
272 2014-01-08 18:52:28 <gmaxwell> heh our old make files had gnuisms, so we didn't even get the 1970s compatibility.
273 2014-01-08 18:53:20 <wumpus> make without gnuisms is even more masochistic
274 2014-01-08 18:59:59 <jgarzik> hrm
275 2014-01-08 19:00:05 <jgarzik> wallet format changes in 0.9???
276 2014-01-08 19:00:21 <jgarzik> 0.8.6 pukes on my git HEAD testnet wallet
277 2014-01-08 19:01:53 <wumpus> any messages in debug.log?
278 2014-01-08 19:04:00 <jgarzik> wumpus, none.  entire process stops with message about wallet.dat corruption to stderr
279 2014-01-08 19:04:41 <jgarzik> it also stops with a message about block database corruption, and suggests -reindex, which I added.  wallet.dat complaint appeared after adding -reindex and restarting.
280 2014-01-08 19:06:15 <jgarzik> 
ACTION wonders if old build system is suddenly picking up a different BDB

281 2014-01-08 19:07:36 <wumpus> if there are any wallet format changes they should be minor, certainly not result in loss of backward compatibility with 0.8.6
282 2014-01-08 19:07:53 <wumpus> yes, a BDB version conflict is most likely
283 2014-01-08 19:09:22 <warren> jgarzik: there was a known format incompatibility a few months ago that was later fixed
284 2014-01-08 19:10:23 <wumpus> from what I see: the 'purpose' was added for address book entries (a41d5fe01947f2f878c055670986a165af800f9a)
285 2014-01-08 19:11:15 <wumpus> not sure if the wallet birthday stuff is already in 0.8.x
286 2014-01-08 19:11:56 <sipa> jgarzik: did you run any headersfirst version at some point?
287 2014-01-08 19:12:32 <jgarzik> sipa, yes, but not on this machine with this wallet
288 2014-01-08 19:13:25 <sipa> oh, the wallet problem and reindex problem are likely completely independent
289 2014-01-08 19:20:46 <warren> wumpus: wallet birthday was never in 0.8
290 2014-01-08 19:20:59 <warren> wumpus: that came a bit after the first key refactor stuff, we didn't include that in litecoin
291 2014-01-08 19:21:39 <jgarzik> sipa, agree
292 2014-01-08 19:22:09 <jgarzik> anybody have any testnet coins?   mhHAk5xqRvApJD55ibMDjJLFaQSJ7etL94
293 2014-01-08 19:22:42 <matjeh> how many you want?
294 2014-01-08 19:22:42 <warren> jgarzik: I'm unable to run my testnet wallet because petertodd ruined it with too many tx
295 2014-01-08 19:22:49 <warren> jgarzik: want this wallet.dat? =)
296 2014-01-08 19:22:59 <jgarzik> ummm... 100 tBTC?
297 2014-01-08 19:23:25 <jgarzik> need several times 1.0 BTC, for testing around the decimal point
298 2014-01-08 19:23:37 <maraoz> jgarzik: I just sent you 4 :P
299 2014-01-08 19:24:43 <jgarzik> maraoz, thanks
300 2014-01-08 19:25:02 <jgarzik> warren, appreciated, but importing wallet.dat would seem unwise ATM :)
301 2014-01-08 19:25:08 <matjeh> 5k on its way
302 2014-01-08 19:25:27 <jgarzik> got it, I think I have plenty now :)
303 2014-01-08 19:29:44 <michagogo> cloud|jgarzik: if I were home, I could point my erupter at you for a block or two
304 2014-01-08 19:30:13 <jgarzik> michagogo|cloud, were I at home, I would do same :)
305 2014-01-08 19:31:06 <michagogo> cloud|jgarzik: hmm, which machine are you on?
306 2014-01-08 19:31:22 <michagogo> cloud|You could just mine a block or two on there
307 2014-01-08 19:31:30 <jgarzik> michagogo|cloud, at diff 256?
308 2014-01-08 19:31:45 <jgarzik> michagogo|cloud, 4 threads on this OSX machine got nothing after a couple hours
309 2014-01-08 19:31:46 <michagogo> cloud|jgarzik: no, at diff 1
310 2014-01-08 19:31:57 <matjeh> testnet is at diff 256 right now
311 2014-01-08 19:32:01 <michagogo> cloud|Just set the clock ahead 20 mins
312 2014-01-08 19:32:12 <jgarzik> heh
313 2014-01-08 19:32:25 <jgarzik> dunno why I never thought of that
314 2014-01-08 19:33:11 <matjeh> michagogo|cloud: sounds like you've done this before :)
315 2014-01-08 19:33:20 <michagogo> cloud|matjeh: indeed
316 2014-01-08 19:44:53 <jgarzik> curse you, fees!  I'm pissing away tnBTC like it's worthless, or something!
317 2014-01-08 19:45:39 <matjeh> i'm glad i messed up my raw transactions and sent a 50 BTC fee on testnet a few times before i did it live
318 2014-01-08 19:49:55 <lechuga__> does bfgminer care if its talking to a testnet node?
319 2014-01-08 19:50:05 <helo> hooray! hear the opposite case much more often :)
320 2014-01-08 19:50:05 <lechuga__> doesnt seem to afaict
321 2014-01-08 19:51:09 <matjeh> lechuga__: nope, but bitcoind cant keep up getwork responses if the hashrate is too fast for the diff
322 2014-01-08 19:51:42 <lechuga__> k thx
323 2014-01-08 19:51:50 <michagogo> cloud|lechuga__: bfgminer works with testnet, yeah
324 2014-01-08 19:52:24 <michagogo> cloud|lechuga__: you may want to use gbt rather than get work
325 2014-01-08 19:52:25 <lechuga__> im actually looking @ gbt specifically
326 2014-01-08 19:52:37 <michagogo> cloud|Do that by giving it the command-line option --coinbase-address
327 2014-01-08 19:52:52 <lechuga__> trying to figure it out, i get it but now im looking into details
328 2014-01-08 19:52:52 <michagogo> cloud|addr, not address
329 2014-01-08 19:53:06 <michagogo> cloud|lechuga__: it's also in the readme
330 2014-01-08 19:53:16 <lechuga__> just to experiment i tried connecting to eligius' gbt interface but the replies seemed weird
331 2014-01-08 19:53:31 <lechuga__> didn't seem to match what the code in bitcoind would do in response to a gbt
332 2014-01-08 19:53:52 <lechuga__> guess i need to connect to my testnet node and figure out why
333 2014-01-08 19:54:08 <michagogo> cloud|lechuga__: yeah, it won't match
334 2014-01-08 19:54:14 <lechuga__> y not
335 2014-01-08 19:54:18 <michagogo> cloud|lechuga__: have you read the gbt BIP?
336 2014-01-08 19:54:25 <lechuga__> not word for word
337 2014-01-08 19:54:36 <lechuga__> skimmed mostly
338 2014-01-08 19:54:36 <michagogo> cloud|Basically, it's a protocol
339 2014-01-08 19:54:49 <lechuga__> nod
340 2014-01-08 19:55:12 <lechuga__> one discrepncy seemed to be that bitcoind looks liek it always returns a hash for each txn in the "transactions" list when it returns txns
341 2014-01-08 19:55:14 <michagogo> cloud|Pools will do it differently, use different parts of it, than a solo-mining node will
342 2014-01-08 19:55:24 <lechuga__> but in these replies i only saw the "data" filled out
343 2014-01-08 19:55:40 <lechuga__> k i better run this against my own node to figure it out better
344 2014-01-08 19:58:07 <lechuga__> this may seem like a noob question but are txns in a block always guarenteed to be in order when transmitting over the wire?
345 2014-01-08 19:58:39 <CodeShark> the block message is defined such that this is the case
346 2014-01-08 19:58:52 <CodeShark> (although the ordering is really done at the TCP layer, not at the wire layer)
347 2014-01-08 20:01:25 <lechuga__> k
348 2014-01-08 20:03:22 <lechuga__> hmm
349 2014-01-08 20:03:33 <lechuga__> but tcp will only guarentee the stream remains ordered
350 2014-01-08 20:03:41 <lechuga__> a protocol rule would have to dictate they are written in order
351 2014-01-08 20:04:03 <lechuga__> was trying to find that protocol rule
352 2014-01-08 20:07:24 <maaku> lechuga__: it's just how the code works
353 2014-01-08 20:08:14 <lechuga__> ok i guess its safe to assume it then
354 2014-01-08 20:16:25 <cr3pe> hi
355 2014-01-08 20:19:45 <michagogo> cloud|lechuga__: if they're not in order, you have a different lock
356 2014-01-08 20:20:47 <michagogo> cloud|A block's identity is its hash. If you reorder transactions, the data changes and the hash is different
357 2014-01-08 20:22:42 <lechuga__> well theoretically i coudl get the block message and all the txns could be out of order even though they were hashed in order
358 2014-01-08 20:23:04 <lechuga__> just wondering if i needed ot be super anal and make sure the list returned was sorted
359 2014-01-08 20:23:44 <lechuga__> also i didnt mean for that to be a declaratice statement
360 2014-01-08 20:23:50 <lechuga__> it seems like that is theoretically possible
361 2014-01-08 20:23:57 <lechuga__> declarative*
362 2014-01-08 20:25:42 <CodeShark> without any additional clues, the recipient of the block message wouldn't really know how to compute the merkle root for the transactions if the transactions weren't in order
363 2014-01-08 20:26:15 <CodeShark> in other words, the ordering information is solely conveyed by the order in which they appear in the message
364 2014-01-08 20:27:19 <lechuga__> heh yup
365 2014-01-08 20:27:25 <lechuga__> just noticed there is no oredering information
366 2014-01-08 20:27:38 <lechuga__> so it must be implciilty determined from order in the msg
367 2014-01-08 20:27:39 <lechuga__> thx
368 2014-01-08 20:27:50 <sipa> it is
369 2014-01-08 20:28:31 <lechuga__> trying to figure out how to merge txns from multiple gbt replies
370 2014-01-08 20:28:40 <lechuga__> this issue seems to make it problematic
371 2014-01-08 20:29:20 <CodeShark> merge transactions?
372 2014-01-08 20:29:41 <lechuga__> lets say i talk to 2 different nodes and they give me gbt replies
373 2014-01-08 20:29:59 <lechuga__> and i want to merge them both into my work set
374 2014-01-08 20:30:02 <lechuga__> for mining
375 2014-01-08 20:30:15 <lechuga__> the ordering issue seems like a problem
376 2014-01-08 20:31:15 <lechuga__> liek if i want to take eligius' txns returned in gbt response
377 2014-01-08 20:31:26 <lechuga__> and also incorporate bitminer's txns returned in a response to a gbt call to them
378 2014-01-08 20:31:32 <CodeShark> if you're looking to construct your own blocks from transactions you get from peers, you might want to try getrawmempool
379 2014-01-08 20:31:46 <lechuga__> but i thought this was sort of the point of gbt
380 2014-01-08 20:32:06 <lechuga__> to dyanmically assemble block material
381 2014-01-08 20:32:07 <CodeShark> the only strict requirements are that the coinbase transaction must be first and dependencies must come before dependents
382 2014-01-08 20:32:22 <sipa> lechuga__: in the GBT response, the dependencies are given explicitly
383 2014-01-08 20:32:26 <gmaxwell> CodeShark: uhhh and that there be no conflicts.
384 2014-01-08 20:32:36 <CodeShark> gmaxwell: that goes without saying :p
385 2014-01-08 20:32:48 <sipa> welll he just said it!
386 2014-01-08 20:32:56 <gmaxwell> I would have thought dependencies must come before dependents would too. :P
387 2014-01-08 20:33:23 <CodeShark> the ordering is arbitrary - but conflicts are not :)
388 2014-01-08 20:33:41 <CodeShark> anyhow...
389 2014-01-08 20:33:44 <lechuga__> dependencies must come before dependents = salient point
390 2014-01-08 20:34:00 <CodeShark> I think it would be better to order them by hash :P
391 2014-01-08 20:34:50 <lechuga__> ahh ok
392 2014-01-08 20:34:58 <lechuga__> gbt does address this with "depends" field
393 2014-01-08 20:35:31 <sipa> you must also make sure not to exceed the total max byte size (1000000) of the block, or the max sigops (20000, iirc)
394 2014-01-08 20:35:55 <zone117x> can someone please provide me the latest json response from getblocktemplate? I'm testing out my node-stratum pool server
395 2014-01-08 20:35:58 <CodeShark> that's not an ordering requirement - but yes, sipa :)
396 2014-01-08 20:36:22 <CodeShark> and the inputs must connect and the signatures must be valid, yada yada :p
397 2014-01-08 20:36:39 <CodeShark> outputs cannot exceed inputs
398 2014-01-08 20:37:13 <sipa> CodeShark: that's implied by GBT (well, as long as you trust the server)
399 2014-01-08 20:39:00 <lechuga__> this is cool i think i can totally merge these then
400 2014-01-08 20:39:22 <sipa> that is a cool application actually, a GBT proxy that merges results from several GBT servers
401 2014-01-08 20:39:35 <sipa> (you must also make sure their coinbase requirement don't contradict)
402 2014-01-08 20:39:36 <lechuga__> i was doing it in libblkmaker per luke's suggestion
403 2014-01-08 20:39:45 <lechuga__> right
404 2014-01-08 22:01:41 <lechuga__> zone117x: are u still looking for a getblocktemplate response example?
405 2014-01-08 22:01:47 <lechuga__> i have one serialized if u want to see it
406 2014-01-08 22:01:49 <lechuga__> from testnet
407 2014-01-08 22:03:05 <lechuga__> http://www.onegrandcircle.com/~andy/gbt.txt