1 2014-03-27 02:46:06 <siculars> hey gang. so i cant get bitcoinqt 0.9.0 to send with a 0.00001 tx fee. either with the gui or with sendtoaddress <addr> <amt>. i've put 0.00001 in the gui preferences and in .conf file via paytxfee=0.00001. thoughts?
  2 2014-03-27 02:46:24 <Apocalyptic> siculars, it's like you sent it with 0 fee
  3 2014-03-27 02:46:48 <Apocalyptic> or has the minfee been changed in 0.9 ?
  4 2014-03-27 02:47:34 <siculars> Apocalyptic: i thought this was the new tx fee, 0.00001, no? It sends the tx with a 0.0001 fee.
  5 2014-03-27 02:48:10 <siculars> according to the changelog 0.00001 is the new fee
  6 2014-03-27 02:49:19 <Apocalyptic> I missed that
  7 2014-03-27 03:06:48 <Luke-Jr> is 0.9.0 supposed to require a reindex?
  8 2014-03-27 03:13:40 <flound1129> siculars: paytxfee is per kb
  9 2014-03-27 03:13:51 <flound1129> iirc
 10 2014-03-27 03:14:06 <torokun> i'm just starting to look at the source code
 11 2014-03-27 03:14:19 <Apocalyptic> flound1129, it is
 12 2014-03-27 03:14:20 <torokun> i am staggered by the complexity of the build scripts.
 13 2014-03-27 03:14:28 <siculars> flound1129: true. but the min fee for it was changed to 0.00001 in the 0.9 release according to the changelog .
 14 2014-03-27 03:14:37 <torokun> does it really have to be that crazy?
 15 2014-03-27 03:14:45 <torokun> o_o
 16 2014-03-27 03:15:04 <flound1129> the makefiles?
 17 2014-03-27 03:15:16 <torokun> the whole autogen thing
 18 2014-03-27 03:15:28 <flound1129> end users shouldn't have to run autogen
 19 2014-03-27 03:15:39 <torokun> of course not
 20 2014-03-27 03:15:51 <flound1129> even end users compiling from source I mean
 21 2014-03-27 03:16:15 <flound1129> ./configure.sh at the most
 22 2014-03-27 03:16:18 <torokun> well, i just downloaded the source from github and that's how the docs tell you to build it.
 23 2014-03-27 03:16:24 <flound1129> well that's borken
 24 2014-03-27 03:16:26 <flound1129> *broken
 25 2014-03-27 03:16:51 <torokun> hmm.  i don't think the makefile.in files are in the repo
 26 2014-03-27 03:16:52 <flound1129> or at least, contrary to convention for building things from source for the past 15 years
 27 2014-03-27 03:16:55 <torokun> so you have to
 28 2014-03-27 03:16:56 <flound1129> at least
 29 2014-03-27 03:17:02 <flound1129> autogen is a developer tool
 30 2014-03-27 03:17:33 <torokun> yes, but the autogen script seems to be humongous
 31 2014-03-27 03:18:22 <LarsLarsen> the makefiles are there
 32 2014-03-27 03:18:45 <LarsLarsen> makefile.unix is probably what you're looking for
 33 2014-03-27 03:18:48 <LarsLarsen> in /src/
 34 2014-03-27 03:18:59 <torokun> so who is supposed to use autogen and who is not?
 35 2014-03-27 03:19:32 <torokun> you don't even need it to build from scratch?
 36 2014-03-27 03:20:19 <torokun> if autogen is supposed to be the tool used to generate the makefiles, a clean build should use it, right?
 37 2014-03-27 03:20:39 <torokun> could be changes to it periodically
 38 2014-03-27 03:20:48 <LarsLarsen> yes
 39 2014-03-27 03:21:20 <warren> Luke-Jr: I'm trying to find a point in testnet that causes the failure in 0.8.7rc1, then I'll try 0.9
 40 2014-03-27 03:23:51 <torokun> random question: why are error strings and such hardcoded?
 41 2014-03-27 03:24:21 <Luke-Jr> torokun: uh, because you have to hardcode something?
 42 2014-03-27 03:24:53 <torokun> i mean, why don't you put all the strings in a separate file (like a resource file) which can be more easily localized?
 43 2014-03-27 03:25:08 <Luke-Jr> because it's just as easy to localise hardcoded strings
 44 2014-03-27 03:25:35 <flound1129> beause T_PAAMAYIM_NEKUDOTAYIM
 45 2014-03-27 03:25:37 <torokun> then your strings are strewn all through the code rather than being in one place.
 46 2014-03-27 03:25:59 <Luke-Jr> torokun: problem?
 47 2014-03-27 03:26:03 <torokun> lol
 48 2014-03-27 03:26:34 <Luke-Jr> it's good for code readability this way too
 49 2014-03-27 03:26:42 <Luke-Jr> there's really no advantage to moving the strings out
 50 2014-03-27 03:26:53 <flound1129> yeah then you can have 1 if statement per language
 51 2014-03-27 03:27:04 <flound1129> easy stuff
 52 2014-03-27 03:27:08 <torokun> It's readable but not a great design
 53 2014-03-27 03:27:18 <flound1129> 1 if statement per language per string
 54 2014-03-27 03:27:30 <flound1129> just remember, if in doubt goto fail
 55 2014-03-27 03:27:50 <Luke-Jr> torokun: it's the best design
 56 2014-03-27 03:28:07 <Luke-Jr> flound1129: why any? that's what the localisation engine is for
 57 2014-03-27 03:28:22 <torokun> No, it's much better imho to have all the strings in one file.
 58 2014-03-27 03:28:56 <Luke-Jr> torokun: well, you're entitled to your opinion, but you've failed to back it up with reasons
 59 2014-03-27 03:29:40 <torokun> i haven't tried yet.
 60 2014-03-27 03:29:47 <torokun> i'm just expressing my opinion.
 61 2014-03-27 03:30:02 <siculars> ok gang got the min tx fee set to 0.00001. according to the changelog, https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.9.0.md, there are two potential settings to set (i set 4 diff settings in my bitcoin.conf. i set paytxfee, settxfee, mintxfee and minrelaytxfee all to 0.00001. haven’t tested which one is actually the winner. but its working now.
 62 2014-03-27 03:30:42 <Luke-Jr> siculars: no, that's just for relaying.
 63 2014-03-27 03:30:54 <Luke-Jr> siculars: if you don't pay a reasonable fee, it still won't get mined.
 64 2014-03-27 03:31:33 <siculars> hmmm well i sent it out. ill see if it gets mined or not. or just sits on the floor
 65 2014-03-27 03:31:54 <Luke-Jr> I guess we're getting closer to the point where fixing stuck sends is possible..
 66 2014-03-27 03:31:58 <shadders> Is there a 4 byte field in either tx or txin that wasn't always in the protocol?  I'm thinking sequence or locktime?  Parsing old blocks and after parsing 1 txin the cursor is 4 bytes ahead of where it should be.
 67 2014-03-27 03:32:03 <torokun> For one, it's much easier to verify that each string use is consistent when they are all together.  It's easier to verify that language usage is consistent.  It's easier to write code to process strings in a single file.  It's easier to give the file to other tools to process...
 68 2014-03-27 03:32:34 <Luke-Jr> shadders: not in this blockchain
 69 2014-03-27 03:32:41 <torokun> It's easier to find strings you want to change.
 70 2014-03-27 03:32:44 <torokun> etc.
 71 2014-03-27 03:33:00 <Luke-Jr> torokun: good thing the localisation is all together
 72 2014-03-27 03:33:10 <Luke-Jr> also, git grep is your friend.. :P
 73 2014-03-27 03:33:34 <shadders> there's never been any changes to message format for tx's or txin's?
 74 2014-03-27 03:33:44 <Luke-Jr> shadders: not in this blockchain.
 75 2014-03-27 03:36:34 <siculars> why doesnt sendtoaddress allow you to set the tx fee? something like sendtoaddress <addr> <amt> <fee> where fee could just default but could also be overridden on a tx by tx basis…
 76 2014-03-27 03:37:15 <Luke-Jr> siculars: because RPC is not well-designed
 77 2014-03-27 03:39:47 <siculars> Luke-Jr: according to the changelog it looks like bitcoind and bitcoin gui will be separated. if i wanted to look into putting together a pull request for adding fee to sendtoaddress where would you recommend i start looking?
 78 2014-03-27 03:41:39 <jeffj> not strictly on topic, but hoping to get the right eyes: since bitcoin pull request 2124 (multiple wallets) got abandoned before 0.9, how are people with hundreds of thousands of users handling this use case? lots of instances of bitcoind and a few thousands addresses per wallet/instance?
 79 2014-03-27 03:43:47 <Luke-Jr> siculars: I don't suggest you do that right now. The plan is to revamp RPC entirely for 0.10 I think
 80 2014-03-27 03:44:16 <Luke-Jr> jeffj: all your users should be using the same shared wallet(s)
 81 2014-03-27 03:44:49 <olalonde> so it seems someone did record all transactions http://arxiv.org/pdf/1403.6676v1.pdf
 82 2014-03-27 03:45:10 <olalonde> anyone else read the paper?
 83 2014-03-27 03:46:34 <olalonde> seems legit except it would be nice if they released their data (using bittorrent maybe?)
 84 2014-03-27 03:47:29 <Luke-Jr> olalonde: I don't think anyone really believes malleability was MtGox's problem at this point :P
 85 2014-03-27 03:47:59 <Luke-Jr> also, off-topic here
 86 2014-03-27 03:51:25 <num1> <Luke-Jr> I guess we're getting closer to the point where fixing stuck sends is possible..
 87 2014-03-27 03:51:26 <num1> how?
 88 2014-03-27 03:51:41 <Luke-Jr> num1: well, we have the zap stuff now
 89 2014-03-27 03:51:45 <Luke-Jr> even if it is a bit broken
 90 2014-03-27 03:52:09 <num1> Luke-Jr, sorry, I don't know what you're referring to
 91 2014-03-27 03:52:28 <num1> googling for "bitcoin zap" doesn't help either
 92 2014-03-27 03:53:09 <Luke-Jr>   -zapwallettxes         Clear list of wallet transactions (diagnostic tool; implies -rescan)
 93 2014-03-27 03:53:34 <olalonde> Luke-Jr: yea I know... but it's interesting to have some hard data
 94 2014-03-27 03:53:58 <num1> thank you kindly
 95 2014-03-27 03:53:59 <olalonde> I find it curious they had the foresight to record all transactions since 2013. I guess they had another type of analysis in mind
 96 2014-03-27 03:54:27 <Luke-Jr> olalonde: all transactions are already recorded in the blockchain
 97 2014-03-27 03:55:03 <olalonde> Luke-Jr: those guys apparently recorded transactions that didn't make it to the blockchain (failed transaction malleability attempts for example)
 98 2014-03-27 03:56:38 <Luke-Jr> I wonder how they managed to do any analysis while still suffering from the misunderstanding that bitcoin addresses have balances O.o
 99 2014-03-27 03:58:42 <olalonde> do they? I don't think they mentioned anything about addresses in their paper
100 2014-03-27 03:59:15 <dgenr8> Having recently familiarized myself with the source (somewhat)
101 2014-03-27 03:59:20 <jeffj> Luke-Jr: is there a practical limit to # of addresses in a wallet from a development standpoint?
102 2014-03-27 03:59:33 <dgenr8> I was impressed with the practical choices made
103 2014-03-27 03:59:47 <Luke-Jr> olalonde: they did
104 2014-03-27 03:59:55 <dgenr8> Such as in-line strings and no overuse of classes
105 2014-03-27 03:59:59 <num1> multitude of owners. They collectively implement a replicated ledger that tracks
106 2014-03-27 03:59:59 <num1> the address balances of all users"
107 2014-03-27 03:59:59 <num1> "The Bitcoin network is a distributed network of computer nodes controlled by a
108 2014-03-27 04:01:13 <olalonde> their methodology seemed to make sense to me
109 2014-03-27 04:05:02 <olalonde> in the real world, address balance is often used as a shortcut to "balance controlled by the private key that generated the address" :)
110 2014-03-27 04:05:18 <olalonde> but I know I will never convince you of that :P
111 2014-03-27 04:06:06 <olalonde> oops, the private key that generated the public key that is hashed
112 2014-03-27 04:06:10 <olalonde> haha
113 2014-03-27 04:06:39 <Luke-Jr> olalonde: I know that, but it's meaningless and confuses users to speak of it that way
114 2014-03-27 04:06:55 <Luke-Jr> they start to think addresses *really* have balances
115 2014-03-27 04:07:10 <Luke-Jr> and that by reusing addresses, they're helping bitcoin or saving fees
116 2014-03-27 04:07:12 <torokun> actually, i think users would be more confused to have anything at all about how it actually works explained to them.
117 2014-03-27 04:07:45 <olalonde> I concede that it's misleading to newbies
118 2014-03-27 04:08:06 <Luke-Jr> torokun: which is why "how it actually works" should be kept separate from "how you use it"
119 2014-03-27 04:08:44 <torokun> well, it depends on the software you use
120 2014-03-27 04:09:00 <torokun> if people use blockchain.info, they do effectively have balances per address.
121 2014-03-27 04:09:08 <Luke-Jr> sigh
122 2014-03-27 04:09:22 <Luke-Jr> let's pretend non-sane software doesn't exist, ok? :P
123 2014-03-27 04:09:31 <torokun> paper wallets
124 2014-03-27 04:09:47 <Luke-Jr> the only paper wallets I acknowledge are HD wallets! :P
125 2014-03-27 04:09:55 <torokun> HD?
126 2014-03-27 04:10:03 <dgenr8> If someone wrote a wallet called "keybag" that didnt hide change addreses etc, i would tell my grandma to use it
127 2014-03-27 04:10:10 <Luke-Jr> torokun: yes, like Armory makes
128 2014-03-27 04:10:21 <torokun> ah
129 2014-03-27 04:10:30 <Luke-Jr> dgenr8: that would be a bad idea right now for political reasons :x
130 2014-03-27 04:11:29 <dgenr8> Some grandmas matter more than others
131 2014-03-27 04:13:29 <olalonde> my paper wallet is my electrum seed phrase , does that count? :P
132 2014-03-27 04:13:48 <olalonde> don't think they implement HD yet though
133 2014-03-27 04:14:14 <Luke-Jr> olalonde: eh, is it a real wallet, or just a single address? :p
134 2014-03-27 04:14:24 <olalonde> real wallet :P
135 2014-03-27 04:14:43 <Luke-Jr> k *stamp of approval*
136 2014-03-27 04:14:49 <olalonde> haha
137 2014-03-27 04:26:56 <jedunnigan> is anyone keeping a publicly accessible log of all txs that have been in the mempool but never made it into blocks?
138 2014-03-27 04:44:04 <Emcy_> why would you do that
139 2014-03-27 04:49:42 <Emcy_> First double-spend relay and detection. Detecting attempted double-spends as soon as possible is great for low-value, in-person transactions, and we should do more to support that use case.
140 2014-03-27 04:49:42 <Emcy_> On top of all that is a long list of new features and improvements Id like to see get into a 0.9 release; the highest priorities on my wish list are:
141 2014-03-27 04:49:57 <Emcy_> did that get into 0.9, or did it get pushed back
142 2014-03-27 04:50:41 <Luke-Jr> Emcy_: nobody cares
143 2014-03-27 04:51:02 <Luke-Jr> this is not #please-do-things-I-want
144 2014-03-27 04:51:36 <Emcy_> im asking if it happened im not asking you to do it
145 2014-03-27 04:51:37 <jedunnigan> no, I was curious if anyone ahs because it was something i was considering doing myself. thanks though
146 2014-03-27 04:52:37 <Emcy_> i know the floating fee got pushe dback in the end. Im just asking christ
147 2014-03-27 04:53:30 <Luke-Jr> Emcy_: it was never merged, probably in part because it's a mere false sense of security
148 2014-03-27 04:54:32 <Emcy_> for anything over probably low double digit dollar value thats probably true
149 2014-03-27 04:54:44 <Emcy_> ok thanks
150 2014-03-27 04:55:19 <Luke-Jr> Emcy_: no really, it provides negative security improvement
151 2014-03-27 04:56:38 <Emcy_> assuming well diversely connected nodes i dont see how
152 2014-03-27 04:57:11 <Emcy_> should be one of those defense in depth things ie youd be dumb to soley rely on it but it helps
153 2014-03-27 04:57:24 <Luke-Jr> Emcy_: because transactions never need to be relayed to be mined
154 2014-03-27 04:57:32 <Luke-Jr> Emcy_: because it's easy to create transactions that *won't* be relayed
155 2014-03-27 04:59:08 <Luke-Jr> and unless you're 100% secure, there is a penalty for people assuming/believing they are protected
156 2014-03-27 04:59:21 <Emcy_> the theory on that is it wont be economical to pay a miner to shadymine your doublespend on $15 movie tickets
157 2014-03-27 04:59:41 <Emcy_> i dont know if that holds up mind
158 2014-03-27 05:00:11 <Luke-Jr> well, you don't have to pay the miner to doublespend, any more than a normal spend
159 2014-03-27 05:00:20 <Luke-Jr> and obviously you get the $15 back
160 2014-03-27 05:01:19 <Emcy_> is the general assumption that miners are mainly going to go off the grid in future?
161 2014-03-27 05:01:46 <Luke-Jr> off the grid?
162 2014-03-27 05:02:21 <Emcy_> not accpet or relay txns to or from normal nodes, perhaps not even run the p2p at all
163 2014-03-27 05:02:54 <Luke-Jr> unlikely
164 2014-03-27 05:04:09 <Emcy_> so it will be specialist shady miners that will do the quiet DS blocks with txns no one saw until they saw it in a block?
165 2014-03-27 05:04:17 <sipa> torokun: when you download a source tarball, it has autogen preapplied
166 2014-03-27 05:04:35 <sipa> Luke-Jr: no, 0.9 shouldn't require a reindex (going back to 0.8 might)
167 2014-03-27 05:05:18 <Emcy_> how about a node wont accept a block as valid unless its seen all the txs floating around in unconfirmed state beforehand?
168 2014-03-27 05:05:24 <Luke-Jr> Emcy_: no, just miners who mine transactions that aren't relayed by a majority of nodes
169 2014-03-27 05:05:31 <Luke-Jr> Emcy_: then bitcoin falls apart
170 2014-03-27 05:05:32 <torokun> sipa: yeah - i'm trying to read and build the source myself to get familiar with it.
171 2014-03-27 05:05:39 <torokun> sipa: and eventually contribute
172 2014-03-27 05:07:59 <sipa> torokun: \o/
173 2014-03-27 05:08:24 <torokun> sipa: finally did manage to build it - yay. ;)
174 2014-03-27 05:08:58 <Emcy_> so a tx has ten minutes (avg) to get around into mempools before the nodes will accept it in a block
175 2014-03-27 05:09:08 <Emcy_> under my little scheme
176 2014-03-27 05:09:43 <Emcy_> if some mempool syncing work was done so that they were a little more persistent against node churn
177 2014-03-27 05:09:49 <Emcy_> is ten minutes really not enough?
178 2014-03-27 05:10:15 <sipa> Emcy_: requiring block transactions to be in the mempool would require consistent synchronization of mempools in order to avoid forks
179 2014-03-27 05:10:23 <sipa> Emcy_: which... would require a block chain, really
180 2014-03-27 05:10:49 <Luke-Jr> Emcy_: so now you've broken: consensus(!), SPV nodes, antispam, non-public-key scripts, miners' rights, etc..
181 2014-03-27 05:12:00 <Luke-Jr> oh, and offline wallets
182 2014-03-27 05:13:11 <Emcy_> so there is no way to enforce miners not being secretive sods
183 2014-03-27 05:15:02 <Emcy_> i mean if there was wouldnt that fix the selfish miner thing too
184 2014-03-27 05:15:21 <Luke-Jr> Emcy_: if there was, we *wouldn't need mining at all*
185 2014-03-27 05:16:20 <Emcy_> sigh i used to be better at this
186 2014-03-27 05:25:46 <LarsLarsen> Emcy_: Miners are allowed to mine completely empty block (except for the coinbase),  it is by design.  Its not a problem.
187 2014-03-27 05:26:07 <LarsLarsen> Emcy_: Its a feature.
188 2014-03-27 05:26:14 <Emcy_> i didnt propose to stop that
189 2014-03-27 05:27:34 <LarsLarsen> I see,  but how is it a problem that transactions are first seen in blocks?  Thats the first place they really matter
190 2014-03-27 05:27:59 <LarsLarsen> the only reason to see them before them is for including them in blocks (or facilitating others who do)
191 2014-03-27 05:28:14 <LarsLarsen> before then
192 2014-03-27 05:28:34 <Emcy_> to make first DS relay somewhat worth doing and save small transactions from bitpay etc skimming
193 2014-03-27 05:28:48 <Emcy_> i dont actually think it affects selfish miner
194 2014-03-27 05:29:07 <LarsLarsen> I see,  you're saying there is no incentive for a node to be good
195 2014-03-27 05:29:22 <Emcy_> ?
196 2014-03-27 05:29:34 <LarsLarsen> That there is no incentive to run a node
197 2014-03-27 05:29:38 <LarsLarsen> and relay
198 2014-03-27 05:30:10 <Emcy_> in general? Theres an abstract incentive
199 2014-03-27 05:30:30 <LarsLarsen> sure
200 2014-03-27 05:30:36 <sipa> if you use that abstract incentive as an argument, no one would ever try to steal bitcoin
201 2014-03-27 05:30:50 <Emcy_> wait how does that relate to this ds relay thing
202 2014-03-27 05:31:10 <sipa> (not saying it is wrong to an extent, but it shouldn't matter for reasoning about incentives and attacks)
203 2014-03-27 05:31:42 <Emcy_> sipa youre right, i know it doesnt seem to mean anything to people
204 2014-03-27 05:31:50 <sipa> i'm unsure about DS relaying
205 2014-03-27 05:32:04 <sipa> it makes it easier to detect (the simplest type of) attacks
206 2014-03-27 05:32:07 <sipa> on 0-conf
207 2014-03-27 05:32:24 <sipa> but it also makes it easier for miners to just go pick the highest-fee-paying one of the two relayed
208 2014-03-27 05:32:30 <sipa> effectively reducing 0-conf security
209 2014-03-27 05:32:31 <Emcy_> as luke said it doesnt work being you can mine txs into blocks in secret and the netowrk doesnt mind
210 2014-03-27 05:32:42 <sipa> yes, that's always an option
211 2014-03-27 05:33:07 <sipa> but with DS relaying it doesn't even require a special OOB request from payer to miner
212 2014-03-27 05:33:33 <LarsLarsen> Yeah I'm not addressing the solution you're proposing,  I'm simply addressing whatever problems it attempts to solve.
213 2014-03-27 05:33:52 <Emcy_> well remember the aim is just to be able to sound an alarm, of course you cant stop the DS if someone tried it
214 2014-03-27 05:34:10 <Emcy_> but you might know pretty quick if they screwed you
215 2014-03-27 05:34:10 <LarsLarsen> I mean,  you'll get plenty of miners who accept your blocks (especially if you pay)
216 2014-03-27 05:34:45 <Emcy_> just a harebrtained attempt to resolve the secret tx mining luke said
217 2014-03-27 05:35:02 <LarsLarsen> I see... so you want to be able to check
218 2014-03-27 05:35:05 <sipa> i don't see secret tx mining as a problem
219 2014-03-27 05:35:08 <Emcy_> i don know why he thought it does away with empty blocks though
220 2014-03-27 05:35:22 <sipa> i'm not convinced the broadcast-all-transactions-to-everyone will scale anyway
221 2014-03-27 05:36:08 <LarsLarsen> I think thats the choke point of the network,  the network
222 2014-03-27 05:36:14 <Emcy_> i think the maths says it doesnt but it depends on bitcoin uptake vs bandwidth
223 2014-03-27 05:36:38 <sipa> well with limited block sizes everything scales, as transaction rates are O(1)
224 2014-03-27 05:37:02 <Emcy_> LarsLarsen thats interesting, ive seen a sort of trend towards people seeing and speaking about bitcoins core strengths as liabilities
225 2014-03-27 05:37:20 <Emcy_> all this does just go away if we stick it on a server ofc
226 2014-03-27 05:38:43 <LarsLarsen> I agree that with the current UTXO db rolling database chain system space is only a bandwith issue
227 2014-03-27 05:38:51 <LarsLarsen> and thats why I say the network is the limit
228 2014-03-27 05:39:01 <Emcy_> sipa thats true. I think we just hope the politics stays out of the blocksize thing and its managed based on technical criteria only
229 2014-03-27 05:39:05 <Emcy_> if thats even possible
230 2014-03-27 05:41:35 <Emcy_> LarsLarsen you are right
231 2014-03-27 05:41:55 <LarsLarsen> Emcy_: nobody stops to think why things are they way they are.... they just replace it with something they already know :)
232 2014-03-27 05:43:01 <Emcy_> im just saying the network is a strength, even if it has its drawbacks. Some people see it as a burden i think. Perhaps not you or anyone else here, elsewhere though.
233 2014-03-27 05:44:16 <LarsLarsen> Scaling isnt a problem yet but when it is we'll know for sure.  :)
234 2014-03-27 05:44:34 <Emcy_> oh well this is kind of generic proselytising so ill stop there
235 2014-03-27 05:44:48 <LarsLarsen> concur
236 2014-03-27 05:47:52 <Emcy_> oh yeah i meant to ask is anyone had reviewed that paper that claims fees can never support mining
237 2014-03-27 05:48:14 <Emcy_> and calls for a tax to be built into the protocol or some shit
238 2014-03-27 05:48:53 <Emcy_> i always assumed fees would just end up fairly sky high and people would have to pools txs
239 2014-03-27 06:27:42 <Alina-malina> hmmm how to create a test bitcoin multisig operation ?
240 2014-03-27 07:25:15 <kadoban> OP_VERIFY, is it important in some way that False is not removed from the stack?  Execution ends and the transaction is invalidated anyway, right?
241 2014-03-27 08:23:57 <warren> Anyone can help me do gitian builds?
242 2014-03-27 08:24:24 <wumpus> sure
243 2014-03-27 08:24:39 <warren> they're not standard bitcoin
244 2014-03-27 08:24:52 <warren> wumpus: https://github.com/litecoin-project/gitian.sigs.omg  (Bitcoin 0.8.x backport)
245 2014-03-27 08:25:06 <warren> v0.8.7-OMG12 tag
246 2014-03-27 08:29:26 <wumpus> well as long as it uses the same inputs I dont mind
247 2014-03-27 08:36:59 <warren> wumpus: same inputs as 0.8
248 2014-03-27 08:37:09 <wumpus> it's already building
249 2014-03-27 08:37:12 <warren> thanks
250 2014-03-27 08:56:06 <serphacker> hi, the new coin control feature allow to send from an address right ? is it a GUI only feature ?
251 2014-03-27 08:56:37 <serphacker> is it planned to have a rpc sendfromaddress or something like that ?
252 2014-03-27 08:57:18 <Apocalyptic> there is no "from" address
253 2014-03-27 08:57:28 <serphacker> from tx if you prefer
254 2014-03-27 08:58:13 <Apocalyptic> you can achieve what you want with raw transactions
255 2014-03-27 08:58:20 <AmThatsMe> Hi everyone !
256 2014-03-27 08:58:26 <serphacker> yes I know there is no from address, but I just wanted to know if it was planned to restrict to "from address"
257 2014-03-27 08:58:33 <serphacker> Apocalyptic: yep, that's already what 'im doing
258 2014-03-27 09:00:27 <Emcy_> im still really surprised they merged coin control
259 2014-03-27 09:00:32 <wumpus> use listunspent, then build your transaction using raw transactions API
260 2014-03-27 09:00:40 <serphacker> wumpus: already doing that
261 2014-03-27 09:00:43 <wumpus> Emcy_: why? it's very useful
262 2014-03-27 09:01:00 <Emcy_> can you fuck up coin control options to a point where you lose money? will bt core let you do that?
263 2014-03-27 09:01:33 <wumpus> well you can lose money by paying a lot of fees by building very large transactinons
264 2014-03-27 09:01:39 <wumpus> but that should be the only way
265 2014-03-27 09:02:07 <wumpus> there should be no holes through which coins can disappear, many people have used the code for a long time, then again, no guarantees
266 2014-03-27 09:02:13 <Emcy_> but that would tak the effort of a determined idiot right?
267 2014-03-27 09:02:28 <wumpus> well all kinds of large numbers and red text will appear
268 2014-03-27 09:02:48 <Emcy_> so you cannot send most of your change into a black hole or anything
269 2014-03-27 09:02:52 <warren> sendrawtransaction will block high fees =)
270 2014-03-27 09:03:11 <wumpus> you can send change to an arbitrary address
271 2014-03-27 09:03:17 <wumpus> so if that is a black hole, sure
272 2014-03-27 09:03:34 <Emcy_> yes but like does the client check if it controls said address
273 2014-03-27 09:03:46 <wumpus> it checks but doesn't enforce it
274 2014-03-27 09:03:51 <wumpus> (so it warns if not)
275 2014-03-27 09:04:00 <wumpus> any way why don't you just try it
276 2014-03-27 09:04:10 <wumpus> I can discuss an existing feature all day or try to work on new stuff
277 2014-03-27 09:04:46 <Emcy_> i-im not f-forcing you
278 2014-03-27 09:06:22 <Emcy_> i was just surprised because not only is the concept of coin control obscure, using it for any given txn takes some personal research i think if you are to actually gain a privacy benefit
279 2014-03-27 09:07:20 <wumpus> it's disabled by default
280 2014-03-27 09:07:53 <wumpus> but most devs and advanced users prefer to use it, which is a sizeable part of the people that still use bitcoin-qt
281 2014-03-27 09:10:57 <Emcy_> yes but i mean hopefully that wont be the case forever. its just been leapfrogged in the usability stakes.
282 2014-03-27 09:11:12 <wumpus> newbies wil likely use something like multibit or the android wallet, so we can focus on the more advanced use cases
283 2014-03-27 09:12:22 <Emcy_> i wouldnt agree with that attitude
284 2014-03-27 09:12:35 <wumpus> it's been leapfrogged and it is impossible to keep up, we shouldn't even want to keep up, commercial interests are much better at making user friendly UIs
285 2014-03-27 09:13:15 <Emcy_> and almost none of them are actually bitcoin
286 2014-03-27 09:13:40 <wumpus> if you disagree, please show that by contributing code instead of arguing
287 2014-03-27 09:14:05 <Emcy_> im not arguing as such
288 2014-03-27 09:14:18 <Emcy_> and im not bright enough to code instead
289 2014-03-27 09:15:14 <wumpus> there's a lot of duplication happening, it's better if different projects have their own focus
290 2014-03-27 09:16:42 <wumpus> I'm just trying to be realistic, we have only very few people working on the project and should do best with what we have, and that's not focusing on UI
291 2014-03-27 09:16:45 <Emcy_> ordinarily that is sound advice
292 2014-03-27 09:17:24 <wumpus> but if someone would suddenly start contributing lots of usability improvements ofcourse they wouldn't' be rejected :)
293 2014-03-27 09:17:46 <Emcy_> im just saying all the engineering work wont mean much if no one runs it anyway due to usability
294 2014-03-27 09:18:19 <Emcy_> and i do agree that bc core devteam is too small and that annoys me given the value coming into bitcoin now
295 2014-03-27 09:18:38 <wumpus> 'we should abandon the UI completely' is an option, but not one I'm willing to consider yet, as it is many people are using it fine
296 2014-03-27 09:18:49 <Emcy_> i think even jeff has been put to work on yet another implementation for bitpay now
297 2014-03-27 09:19:47 <Emcy_> that actually might turn out a decent option if it means another team can pick up the UI baton entirely and leave gavin et al working on core
298 2014-03-27 09:20:07 <wumpus> also there certainly are contributions to it, it's improving, just not as fast as a hipness-of-the-day project could
299 2014-03-27 09:20:12 <Emcy_> but only if the result can still be packaged as one complete reference client
300 2014-03-27 09:20:14 <Emcy_> imo
301 2014-03-27 09:21:12 <wumpus> everyone is free to package a headless bitcoind+SPV client already
302 2014-03-27 09:21:17 <warren> wumpus: did the build work?
303 2014-03-27 09:21:22 <wumpus> that's sort of what armory does
304 2014-03-27 09:21:38 <wumpus> warren: yes, it works
305 2014-03-27 09:22:02 <Emcy_> what the hell is armoury though, see what i mean?
306 2014-03-27 09:22:07 <wumpus> warren: linux has been built,  windows was lacking inputs so I have to build those first
307 2014-03-27 09:22:24 <warren> thanks
308 2014-03-27 09:22:25 <Emcy_> people generally need 1 thing called according to one well known brand to install and use
309 2014-03-27 09:22:44 <wumpus> Emcy_: that just won't happen for a decentralized project
310 2014-03-27 09:23:11 <Emcy_> ive tried to warnt he tox people not to start giving every module of a working tox install its own nifty little name if you really want to take down skype
311 2014-03-27 09:24:17 <wumpus> Emcy_: armory is one of the chohices here https://bitcoin.org/en/choose-your-wallet
312 2014-03-27 09:25:17 <Emcy_> i know what armoury is im just giving an example perhaps of user thought process
313 2014-03-27 09:25:36 <wumpus> for those users, multibit is best
314 2014-03-27 09:25:42 <wumpus> (also recommended at the top there)
315 2014-03-27 09:26:29 <skinnkavaj> Can .msg files contain viruses?
316 2014-03-27 09:28:27 <wumpus> skinnkavaj: how does that relate to bitcoin in any way?
317 2014-03-27 09:29:07 <wumpus> in principle any file that is parsed in some way can contain viruses, targeting some buggy parser
318 2014-03-27 09:34:18 <skinnkavaj> wumpus: Rarfiles also? If you just open a rarfile but never open anything it
319 2014-03-27 09:34:26 <skinnkavaj> in it*
320 2014-03-27 09:36:05 <wumpus> yes there have been known cases of exploits in RAR extractors
321 2014-03-27 09:36:44 <wumpus> viruses wil usually target an old version of some well-known software, but you can never answer the 'can it contain viruses' with a reassuring no.
322 2014-03-27 09:37:48 <wumpus> create a one-use VM and extract it in there :)
323 2014-03-27 09:39:38 <wumpus> warren: "mv build/out/bitcoinomg-deps-0.0.5.zip inputs/" there is no bitcoinomg-deps :p
324 2014-03-27 09:43:24 <warren> wumpus: huh... good catch.  I guess the other people didn't point out that error because it uses the same deps as bitcoin.
325 2014-03-27 09:44:55 <skinnkavaj> warren: Is a new version of Bitcoin OMG out?
326 2014-03-27 09:45:43 <warren> skinnkavaj: testing it now
327 2014-03-27 09:45:53 <warren> skinnkavaj: it is worse than 0.9 in every way.  there's no reason to use it.
328 2014-03-27 09:53:31 <wumpus> warren: https://download.visucore.com/bitcoin/laanwj-sigs-0.8.7-OMG12.tar.gz   (don't feel like cloning the repo and creating a pull req)
329 2014-03-27 10:10:40 <warren> wumpus: ok thanks
330 2014-03-27 10:11:00 <fanquake> ;;blocks
331 2014-03-27 10:11:00 <gribble> 292695
332 2014-03-27 10:24:38 <wumpus> we really need more people that review and test pull requests on github
333 2014-03-27 10:27:41 <jaromil> might be a fun activity, while playing out loud "careful with that axe Eugene"
334 2014-03-27 10:29:45 <wumpus> hehe
335 2014-03-27 10:39:58 <shadders> are there any 32 byte strings that are known to be impossible to produce with a sha256 hash?
336 2014-03-27 10:41:23 <wumpus> no, any string should be just as likely
337 2014-03-27 10:42:17 <shadders> bugger... I'm looking  for a null marker for a sha256 placeholder.  I guess I'll have to add an extra byte
338 2014-03-27 10:42:37 <Alina-malina> someone promissd me to send me som testnet bitcoins, is that someone still here?
339 2014-03-27 10:42:42 <Alina-malina> and ready to send some testnet coins?
340 2014-03-27 10:43:11 <ribasushi> Alina-malina: how many do you need and which address
341 2014-03-27 10:43:22 <Alina-malina> list a litle to test multisig app
342 2014-03-27 10:43:32 <Alina-malina> here is my testnet address: mz9RPWQ15y6FF62LZHKtKxSLC5Aqm73E7A
343 2014-03-27 10:43:35 <ribasushi> Alina-malina: then just use https://tpfaucet.appspot.com/
344 2014-03-27 10:43:45 <ribasushi> Alina-malina: 50btc per day or somesuch
345 2014-03-27 10:43:53 <Alina-malina> hmmm
346 2014-03-27 10:43:58 <Alina-malina> is that hard to install?
347 2014-03-27 10:44:04 <ribasushi> sorry *7 btc
348 2014-03-27 10:44:16 <ribasushi> hm used to be higher iirc ;)
349 2014-03-27 10:44:18 <ribasushi> Alina-malina: you just... enter your address
350 2014-03-27 10:44:20 <ribasushi> it's a webform ;)
351 2014-03-27 10:44:24 <Alina-malina> oh
352 2014-03-27 10:44:26 <Alina-malina> heh
353 2014-03-27 10:44:27 <Alina-malina> sorry
354 2014-03-27 10:44:27 <wumpus> Alina-malina: sent some
355 2014-03-27 10:44:34 <Alina-malina> ok thank you:)
356 2014-03-27 10:44:40 <ribasushi> Alina-malina: "When you are done, please send your TestNet Bitcoins back to: mimoZNLcP2rrMRgdeX5PSnR7AjCqQveZZ4"
357 2014-03-27 10:44:49 <Alina-malina> oki
358 2014-03-27 10:45:09 <wumpus> does the faucet still work at all?
359 2014-03-27 10:45:18 <Alina-malina> it says that the coins are on its way
360 2014-03-27 10:45:21 <Alina-malina> but i still have 0.00
361 2014-03-27 10:45:26 <Alina-malina> i hope it will arrive soonish hehe
362 2014-03-27 10:45:28 <ribasushi> wumpus: it did for me
363 2014-03-27 10:45:50 <ribasushi> Alina-malina: give it 60~120 sec or so ;)
364 2014-03-27 10:46:03 <Alina-malina> hmmm k
365 2014-03-27 10:46:10 <Alina-malina> waiting for them, cant wait to get some:)
366 2014-03-27 10:46:15 <Alina-malina> for testing
367 2014-03-27 10:48:27 <Alina-malina> ribasushi, hmm is it going to download the entire block chain?
368 2014-03-27 10:48:30 <Alina-malina> how long it will take?
369 2014-03-27 10:51:28 <ribasushi> Alina-malina: note - until a block is mined (1 confirmation) most clients will not display anything at all
370 2014-03-27 10:51:29 <Alina-malina> ribasushi, hmmmm  it says this: "balance" : 0.00000000, and"blocks" : 38063,
371 2014-03-27 10:53:04 <ribasushi> Alina-malina: no I meant until the transaction(s) that sent stuff to your address are included in at least one block, they are entirely unconfirmed, so many API calls will not display the balance at all
372 2014-03-27 10:53:27 <Alina-malina> hmm so when do i expect the btc on the address?
373 2014-03-27 11:03:01 <HaltingState> while MtGox claimed to have lost 850,000 bitcoins due to malleability attacks, we merely observed a total of 302,000 bitcoins ever being involved in malleability attacks.
374 2014-03-27 11:51:18 <adawddaddw> Anyone familiar with PoS coins?
375 2014-03-27 11:52:44 <sipa> adawddaddw: off topic
376 2014-03-27 13:22:04 <Zoop_> http://arxiv.org/abs/1403.6676
377 2014-03-27 13:22:09 <Zoop_> peer review please?
378 2014-03-27 13:22:57 <Diablo-D3> Zoop_: well, for what its worth
379 2014-03-27 13:22:59 <Diablo-D3> I already knew it
380 2014-03-27 13:23:12 <Diablo-D3> it was just something mtgox made up to try to get away with it
381 2014-03-27 13:23:14 <Zoop_> we all kinda knew
382 2014-03-27 13:23:38 <Zoop_> but now we have some proof through analysis
383 2014-03-27 13:23:53 <Zoop_> (where are all the devs?)
384 2014-03-27 13:25:48 <epscy> secret dev meeting
385 2014-03-27 13:25:53 <Diablo-D3> yeah
386 2014-03-27 13:25:56 <Diablo-D3> even says so on the door
387 2014-03-27 13:26:26 <epscy> they are all dressed up in robes, like in eyes wide shut
388 2014-03-27 13:26:46 <epscy> i believe they plan to sacrafice some farmyard animals too
389 2014-03-27 13:26:50 <wumpus> mtgox, yawn, what was that again?...
390 2014-03-27 13:28:22 <stonecoldpat> should this not be in #bitcoin-wizards ? (isn't that were research is discussed?)
391 2014-03-27 13:28:51 <sturles> Diablo-D3: Ehm..  Did you read the paper?  They "forgot" about the transactions with invalid (easily fixable) transactions which never got accepted by other nodes, but were published with signatures through their API.
392 2014-03-27 13:29:26 <Diablo-D3> sturles: I didnt read it
393 2014-03-27 13:29:34 <sturles> Diablo-D3: I.e. The Bug(TM)
394 2014-03-27 13:30:02 <sturles> They haven't understood the problem.  Another worthless bitcoin paper.  Sigh.
395 2014-03-27 13:39:23 <maraoz> Are there any problems related to address reuse other than privacy problems?
396 2014-03-27 13:39:45 <stonecoldpat> if you have a bad random number generator, can lead to your coins being stolen
397 2014-03-27 13:41:22 <maraoz> Good point. If a business or charity wanted to show all the transactions they made, for transparency, is there a way that doesn't involve reusing the same address every time?
398 2014-03-27 13:42:32 <stonecoldpat> someone here will recommend a better method, but all transactions are linked, so as long as they publicly disclose their addresses - you can follow the chain of transactions
399 2014-03-27 13:58:32 <Alina-malina> hmmm
400 2014-03-27 13:58:41 <Alina-malina> why i receive this error? error: Error parsing JSON:'[037ac39debe2
401 2014-03-27 14:07:51 <helo> maraoz: sure, see https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
402 2014-03-27 14:10:24 <maraoz> helo: thanks
403 2014-03-27 14:55:49 <ft__> ering if there would be a way for me to quickly access all the blockchain data from outside the c++ program ? if yes, how ? thank you.
404 2014-03-27 14:55:49 <ft__> hello everyone, I just have a quick question regarding the blockchain. I'm trying to read all the blocks and transactions from a Java application. I tried the json rpc, but it becomes very slow once I reach blocks > 150k, because I need to do 1 request for each tx. now, I added an rpc method which returns a range of blocks including all the transactions within them, but it seems like it's losing a lot of time in json serialization, so I was wond
405 2014-03-27 15:26:01 <maraoz> ft__: you can read block data directly from the files. Those can be found in bitcoin's data directory (~/.bitcoin in linux)
406 2014-03-27 15:37:17 <helo> 
ACTION wonders what he is actually trying to do

407 2014-03-27 15:43:52 <ft__> maraoz, yes I did consider that but it seems like there are different cases to handle for parsing the blockchain directly and I believe it would be difficult to maintain it in the future.
408 2014-03-27 15:44:09 <ft__> if I don
409 2014-03-27 15:44:17 <ft__> 't have any other choice, I think this is what I
410 2014-03-27 15:44:21 <ft__> ll end up doing.
411 2014-03-27 15:45:36 <ft__> helo, do you mean what I'm trying to do ?
412 2014-03-27 16:01:55 <maraoz> What's your application? What are you trying to parse the blockchain for?
413 2014-03-27 16:02:14 <ft__> maraoz, to put all the txs in a graph (neo4j db).
414 2014-03-27 16:08:31 <maraoz> You should definitely be reading block data files IMO
415 2014-03-27 16:09:26 <ft__> maraoz, I think that's what I'm going to do. I just didn't wanted to reimplement the blockchain parsing, but anyways I'll try to figure something out.
416 2014-03-27 17:07:33 <kadoban> is it important somehow that OP_VERIFY removes True but not False from the stack?  I mean if it's False, the transaction is invalid and there's no reason to continue execution, right?  Just checking I'm not missing something basic.
417 2014-03-27 17:15:23 <sipa> kadoban: no
418 2014-03-27 17:15:27 <sipa> kadoban: doesn't matter
419 2014-03-27 17:19:03 <kadoban> Thanks
420 2014-03-27 17:49:48 <maaku> kadoban: that why it doesn't remove false - because it doesn't matter if it did
421 2014-03-27 17:49:54 <maaku> (small efficiency optimization)
422 2014-03-27 18:03:19 <kadoban> maaku: Ahh, I see, thanks.
423 2014-03-27 18:17:34 <dexX7> http://bitcoindev.us.to/en/developer-guide#block-header << "The time value must be greater than the time of the previous block. No peer will accept a block with a time currently more than two hours in the future according to the peer’s clock." -- is that correct? i assumed that the "time value must be within +- 2 hours of the median time of the last 11 blocks"?
424 2014-03-27 18:18:20 <sipa> it's not correct
425 2014-03-27 18:18:28 <sipa> it must be strictly after the median of the past 11 blocks
426 2014-03-27 18:18:35 <gmaxwell> wtf why does it say that? :(
427 2014-03-27 18:18:36 <sipa> and less than 2 hours in the future
428 2014-03-27 18:18:37 <gmaxwell> fix fix
429 2014-03-27 18:18:57 <dexX7> ah thanks
430 2014-03-27 18:19:02 <gmaxwell> (this is not something I've often seen people get wrong, except that it surprises some developers here and there)
431 2014-03-27 18:20:54 <dexX7> <sipa> and less than 2 hours in the future << are blocks which are more than 2 hours in the past allowed?
432 2014-03-27 18:21:25 <sipa> yes
433 2014-03-27 18:21:35 <sipa> if that's after the median of the past 11 blocks
434 2014-03-27 18:22:00 <sipa> (if more than 2 hours in the past wasn't allowed, syncing from scratch would be pretty impossible!)
435 2014-03-27 18:22:21 <dexX7> good point
436 2014-03-27 19:02:16 <bdhuser> From my reading of the wiki spec of the script language, is there ever a point to having more than one OP_ELSE as a branch of an OP_IF?
437 2014-03-27 19:05:42 <kazcw> it would be the same as putting the stuff in the second else before the first else (i.e. it would stick it to the end of the test==true case)
438 2014-03-27 19:07:49 <kazcw> because it's implemented by inverting the truthiness of the if's condition
439 2014-03-27 19:08:35 <midnightmagic> Hrm. ProcessBlock() calls CheckBlock() -> inside CheckBlock theres: fail if: GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60, GetAdjustedTime() is current time + GetTimeOffset() (which is the median of the network time). So rule #1 is no blocks newer than two hours past the network time. Rule #2 is in AddBlock, fail if: GetBlockTime() <= pindexPrev->GetMedianTimePast(), GetMedianTimePast() is the median of the *prior* 11 blocks.
440 2014-03-27 19:08:41 <midnightmagic> Therefore, at most since the last 11 blocks highest stretch is by two hours each, the greatest backwards-in-time stamp is..  10 hours then, if the last 11 blocks all differed by two hours plus, each?
441 2014-03-27 19:08:47 <bdhuser> kazcw: sorry, not sure I understood that. My problem is, the wiki suggests that an OP_ELSE can run when a preceeding OP_ELSE has failed, I dont get how that can happen