1 2014-01-30 00:25:23 <alex_fun> hello :) how do I calculate how much say 100 btc transaction takes in KB?
2 2014-01-30 00:25:42 <sipa> the amount is irrelevant
3 2014-01-30 00:25:44 <Apocalyptic> depends on the inputs/outputs, not the amount
4 2014-01-30 00:26:07 <sipa> try the listunspent RPC
5 2014-01-30 00:26:25 <sipa> you need to find enough inputs to cover the amount to send + fees
6 2014-01-30 00:26:47 <alex_fun> well i been told that each transaction aka inputs and outputs take certain %of kb which makes sense
7 2014-01-30 00:28:02 <alex_fun> The "raw transaction API" was introduced with Bitcoin-Qt/bitcoind version 0.7. It gives developers or very sophisticated end-users low-level access to transaction creation and broadcast. Nice
8 2014-01-30 00:28:41 <sipa> every transaction input costs 148-190 bytes
9 2014-01-30 00:28:56 <sipa> for normal pay-to-pubkeyhash outputs
10 2014-01-30 00:29:45 <alex_fun> so say people playing dice make chain larger? and amount of transaction does not matter?
11 2014-01-30 00:30:17 <sipa> outputs cost 34 bytes
12 2014-01-30 00:30:25 <sipa> every transaction makes the chain larger
13 2014-01-30 00:30:29 <alex_fun> I have read a bit that Maaku seems to came up with some ways to prune chain, yet to understand
14 2014-01-30 00:31:23 <sipa> that's a misunderstanding
15 2014-01-30 00:31:45 <sipa> pruning the blockchain on disk is possible, and relatively easy to do
16 2014-01-30 00:31:55 <sipa> but it has nothing to do with what he's working on
17 2014-01-30 00:32:59 <alex_fun> so I see static const unsigned int MAX_BLOCK_SIZE = 1000000; that means 1 block can fit quiet alot of transactions
18 2014-01-30 00:35:04 <alex_fun> 5260 inputs approx, so what happens if people play alot of dice and trade alot, some inputs will have to wait for new block?
19 2014-01-30 00:35:14 <sipa> s/inputs/transactions/
20 2014-01-30 00:35:18 <sipa> and that's already the case
21 2014-01-30 00:35:23 <sipa> miners decide what they put in blocks
22 2014-01-30 00:35:28 <nsh> (there was a block of 700k a hour or so ago, which is 70% of that limit)
23 2014-01-30 00:36:08 <alex_fun> sipa and how its possible to prune chain on disk? run local electrum on your pc? or some more elegant ways?
24 2014-01-30 00:36:56 <alex_fun> if it somehow just store merkel hash of previous blocks but then how to verify coins ownership?
25 2014-01-30 00:37:12 <sipa> not at all
26 2014-01-30 00:37:15 <sipa> it's really easy
27 2014-01-30 00:37:22 <sipa> just don't save it on disk
28 2014-01-30 00:37:27 <sipa> download and verify all blocks
29 2014-01-30 00:37:31 <sipa> but don't remember them
30 2014-01-30 00:37:42 <sipa> you don't actually need the block data afterwards anymore
31 2014-01-30 00:37:53 <alex_fun> ok so just use dabatase?
32 2014-01-30 00:37:58 <sipa> we already do
33 2014-01-30 00:38:04 <sipa> we don't need the block data for anything
34 2014-01-30 00:38:07 <alex_fun> haha so simple and clever
35 2014-01-30 00:38:12 <sipa> ... except for giving it to others
36 2014-01-30 00:38:19 <sipa> which is the reason why we don't implement that yet
37 2014-01-30 00:38:32 <sipa> as others need a way to find peers that have the right blocks still
38 2014-01-30 00:40:05 <alex_fun> so is transactions wont fit all in 1 block then 1 confirm can take ages - depending on total amount of transcations wanted to be confirmed?
39 2014-01-30 00:40:40 <sipa> if your transaction can't fit in, you'll need to pay more fee
40 2014-01-30 00:41:06 <alex_fun> so software auto priorities based on fee?
41 2014-01-30 00:41:11 <sipa> miners do
42 2014-01-30 00:41:26 <alex_fun> most miners now days just download win qt and run it
43 2014-01-30 00:41:34 <sipa> lol
44 2014-01-30 00:41:38 <alex_fun> :)
45 2014-01-30 00:41:42 <sipa> there are very few solo miners
46 2014-01-30 00:41:51 <alex_fun> true most are pool
47 2014-01-30 00:41:59 <alex_fun> ooooo
48 2014-01-30 00:42:08 <sipa> yeah, but in any case, the reference client will priorize based on fee per byte
49 2014-01-30 00:42:12 <sipa> when building blocks
50 2014-01-30 00:42:21 <sipa> it's a bit more complex than that
51 2014-01-30 00:42:31 <alex_fun> hahah so clever
52 2014-01-30 00:43:12 <alex_fun> as 5260 inputs arent alot, if 10,000 people play dice non stop
53 2014-01-30 00:43:33 <alex_fun> ok then dice have to pay more else winners wait longer
54 2014-01-30 00:43:54 <sipa> it may just become not feasible to do really cheap transactions anymore
55 2014-01-30 00:44:04 <alex_fun> but some people can transact with each other to slow down chain
56 2014-01-30 00:44:27 <alex_fun> they can keep sending btc at min low fee and else would have to pay more
57 2014-01-30 00:45:48 <alex_fun> what if some people recompile software with really low fee like 1 satoshi, then they can transact with each other and spam network
58 2014-01-30 00:45:55 <alex_fun> how do u get rid of them?
59 2014-01-30 00:46:17 <alex_fun> or they can even remove fee all together
60 2014-01-30 01:04:09 <alex_fun> and whats the function of `dsn` seeder, it seems to allow clients to read A records of seed, but what else it can do? :)
61 2014-01-30 01:04:30 <alex_fun> it is handy to update just a records while keeping domain name as tag :)
62 2014-01-30 01:14:20 <Ademan> http://www.peercointalk.org/index.php?topic=1956.15 In case anyone is as curious as I am about proof-of-stake
63 2014-01-30 01:20:49 <safeman> When a wallet passphrase is introduced, does Bitcoin use the system's encoding?
64 2014-01-30 01:21:30 <alex_fun> seems so
65 2014-01-30 01:21:57 <alex_fun> once encrypted u gotta know password else coins are gone, it updates private key
66 2014-01-30 01:22:57 <safeman> Yes, but if I encrypt on a system with ASCII, then try to decrypt on a UTF-8 system, it will not be correct
67 2014-01-30 01:23:00 <safeman> Right?
68 2014-01-30 01:23:09 <alex_fun> that I dont know
69 2014-01-30 01:23:55 <andytoshi> UTF-8 is a superset of ascii
70 2014-01-30 01:23:58 <safeman> Right
71 2014-01-30 01:24:05 <andytoshi> so in that specific case you're ok :P
72 2014-01-30 01:24:09 <safeman> What are some other locales though?
73 2014-01-30 01:25:04 <safeman> My real question is this... I encrypted a wallet on Ubuntu 12.04 live, but the passphrase that I recorded is not correct. Is there any chance that Ubuntu 12.04 used some non UTF-8 encoding?
74 2014-01-30 01:25:21 <safeman> The live cd I mean
75 2014-01-30 01:25:48 <andytoshi> good question, but i highly doubt it. i haven't seen anything except utf-8 in many many years
76 2014-01-30 01:26:06 <andytoshi> are you using bitcoin-qt?
77 2014-01-30 01:26:17 <andytoshi> you can probably right-click on the text input and change the encoding
78 2014-01-30 01:26:35 <safeman> Hmm
79 2014-01-30 01:26:57 <lechuga_> hmm
80 2014-01-30 01:27:10 <lechuga_> i shud get a walletnofity whenever i see a txn involving one of my addresses right?
81 2014-01-30 01:27:22 <lechuga_> looks that way from wallet.cpp
82 2014-01-30 01:27:39 <lechuga_> never seems to fire
83 2014-01-30 01:28:20 <lechuga_> and im an idiot
84 2014-01-30 01:28:24 <lechuga_> nm
85 2014-01-30 01:32:10 <safeman> I know RTFM right.. but is there a quicker way to test wallet decryption than to send messages to the bitcoin server?
86 2014-01-30 01:35:39 <andytoshi> what do you mean by bitcoin server?
87 2014-01-30 01:37:39 <safeman> So the fastest ways of testing wallet decryption that I can find online involves sending "walletpassphrase" messages to bitcoind
88 2014-01-30 01:38:08 <EasyAt> safeman: Do you have a general idea of what the password is?
89 2014-01-30 01:38:10 <andytoshi> ok cool, that's right. but bitcoind is local, there is no overhead in sending messages to it.
90 2014-01-30 01:38:30 <andytoshi> s/no/negligible compared to the passphrase hash rounds/
91 2014-01-30 01:38:33 <safeman> Yeah, but wouldn't it be quicker to check manually
92 2014-01-30 01:39:09 <safeman> So, the decryption algorithm is naturally that slow?
93 2014-01-30 01:39:15 <safeman> like 10 per second?
94 2014-01-30 01:39:20 <safeman> EasyAt: Yes
95 2014-01-30 01:39:33 <andytoshi> that's right, it does however many rounds it needs to to hit 0.1s on the system you encrypted it with
96 2014-01-30 01:39:53 <safeman> So, if you encrypted it on a slow machine...
97 2014-01-30 01:40:02 <andytoshi> it also has a minimum
98 2014-01-30 01:40:02 <safeman> In the case of a CD-rom..?
99 2014-01-30 01:40:15 <andytoshi> but it's the cpu that'll be the bottleneck here, the CDROM doesn't matter
100 2014-01-30 01:40:23 <safeman> Yeah nevermind I see
101 2014-01-30 01:40:40 <safeman> That is scrypt right?
102 2014-01-30 01:41:23 <EasyAt> I've done something similar. Ended up writing a little cracker. I had switched a capital/non capital letter in the exact same place twice in a row
103 2014-01-30 01:42:06 <safeman> I tried out the cracker that somebody wrote in ruby
104 2014-01-30 01:42:12 <safeman> Ran it for a day but no luck
105 2014-01-30 01:43:08 <EasyAt> https://en.bitcoin.it/wiki/Wallet_encryption
106 2014-01-30 01:52:15 <EasyAt> I am curious why the reference client adjust the number of rounds based on the computer you are on when you encrypted. The attack most likely won't be using you rmachine to crack it
107 2014-01-30 01:52:15 <EasyAt> s/attack/attacker
108 2014-01-30 01:53:35 <Emcy> in what way does it do that
109 2014-01-30 01:53:53 <Emcy> number of AES rounds?
110 2014-01-30 01:55:13 <Emcy> oh....so wallets crpyted on weak machines are weaker?
111 2014-01-30 01:55:53 <EasyAt> From the wiki
112 2014-01-30 01:55:53 <EasyAt> This master key is then encrypted with AES-256-CBC with a key derived from the passphrase using SHA512 and OpenSSL's EVP_BytesToKey and a dynamic number of rounds determined by the speed of the machine
113 2014-01-30 01:57:04 <EasyAt> Number of sha rounds, no?
114 2014-01-30 01:59:18 <gmaxwell> EasyAt: yes, up to a limit.
115 2014-01-30 01:59:21 <gmaxwell> er Emcy
116 2014-01-30 01:59:32 <andytoshi> EasyAt: the idea is to get the highest number of rounds possible without irritating the user, i suppose
117 2014-01-30 01:59:41 <Emcy> hmm
118 2014-01-30 01:59:42 <andytoshi> Emcy: i mean
119 2014-01-30 01:59:43 <gmaxwell> andytoshi: yep.
120 2014-01-30 01:59:46 <Emcy> lol
121 2014-01-30 01:59:58 <Emcy> i assume the numbers mean "weaker" is irrelevant in this context
122 2014-01-30 02:00:07 <gmaxwell> EasyAt: one of you is going to have to change your name. I suggest asyAtEay:
123 2014-01-30 02:00:33 <Emcy> just tab on two letters lazy bones
124 2014-01-30 02:00:47 <EasyAt> srsly
125 2014-01-30 02:01:55 <gmaxwell> Emcy: there is a minimum number of 25,000 rounds which I think was basically the number we got on the slowest pratical desktop machine we could find. (like, some atom somthing another).. so if you're on a really slow machine it'll just get slow instead of less secure.
126 2014-01-30 02:03:06 <Ademan> alex_fun: sorry I didn't see your PM (for the future, I prefer not to receive PMs)
127 2014-01-30 02:03:33 <alex_fun> well also POS if offtopic here
128 2014-01-30 02:03:34 <alex_fun> :D
129 2014-01-30 02:03:40 <gmaxwell> I'd kinda wanted to split it into two steps, e.g. a second step that gets done only the first time during a session that you unlock it, then a 100ms step based on the memory cached copy of the first.. but there is basically no limit to how much you can overdesign this sort of thing.
130 2014-01-30 02:03:43 <alex_fun> so how to discuss it with you then?
131 2014-01-30 02:03:57 <alex_fun> *is
132 2014-01-30 02:04:11 <Emcy> i dont understand why you need more than one run thru of AES
133 2014-01-30 02:04:16 <Emcy> what about the protons......
134 2014-01-30 02:04:45 <Ademan> gmaxwell: If you have a moment, do you mind looking at http://www.peercointalk.org/index.php?topic=1956.msg17697#msg17697 ? It appears that it's only rational to mine other chains if you can be certain(?) that you won't end up as the end-of-chain. At first glance that seems like a pretty solid defense. Do you have any thoughts on that?
135 2014-01-30 02:04:54 <Emcy> oh it relates to how fast you can crack an unknown pass, i bet
136 2014-01-30 02:05:00 <EasyAt> Emcy: It's multiple sha rounds... to make password cracking slower. Not multiple AES rounds
137 2014-01-30 02:05:03 <Ademan> alex_fun: true, right now when people are actually talking I probably shouldn't have brought it up...
138 2014-01-30 02:05:15 <andytoshi> Emcy: yeah, user passphrases don't have nearly as much entropy as the full aes keyspace
139 2014-01-30 02:05:26 <Emcy> righto
140 2014-01-30 02:05:30 <alex_fun> Ademan well do u want to talk about it in PM? :D
141 2014-01-30 02:05:37 <andytoshi> ACTION has patched his client to output the number of rounds out of curiosity..
142 2014-01-30 02:05:44 <EasyAt> andytoshi: hehe
143 2014-01-30 02:05:54 <Ademan> alex_fun: I'd like to involve as many people as possible, maybe #peercoin?
144 2014-01-30 02:05:59 <alex_fun> oki
145 2014-01-30 02:06:24 <Emcy> does the crypto take salt from anywhere?
146 2014-01-30 02:06:29 <Emcy> mouse noise or something
147 2014-01-30 02:06:52 <EasyAt> If hash rounds are dependant on the machine is a salt necessary anymore?
148 2014-01-30 02:08:07 <alex_fun> also who here knows how exacty diff adjustment managed to calculate timestamps to adjust itself?
149 2014-01-30 02:08:14 <Luke-Jr> EasyAt: those solve two unrelated problems
150 2014-01-30 02:08:15 <alex_fun> *manages
151 2014-01-30 02:08:28 <andytoshi> 118856 rounds with my old laptop (core 2 duo). will reencrypt with an i7..
152 2014-01-30 02:08:38 <Luke-Jr> alex_fun: it doesn't. miners choose timestamps.
153 2014-01-30 02:08:57 <alex_fun> Luke-Jr: but then they can chear
154 2014-01-30 02:08:59 <alex_fun> cheat
155 2014-01-30 02:09:24 <andytoshi> 258382 rounds, more than double
156 2014-01-30 02:09:24 <EasyAt> Luke-Jr: Well I could have 2 wallets I am cracking on. Normally a salt is added to the pw so that 1 attempt can't be applied to both wallets. Since they have a different number of rounds won't that serve the same purpose
157 2014-01-30 02:09:36 <alex_fun> I read before its possible to cheat if you submit time stamps a bit earlier
158 2014-01-30 02:10:29 <Luke-Jr> alex_fun: they could, yes, but not in a way that's very useful
159 2014-01-30 02:10:45 <Luke-Jr> EasyAt: no.
160 2014-01-30 02:10:54 <gmaxwell> EasyAt: no the entropy of the round counts is very low, its not a good salt. The bitcoin wallet encryption has a (IIRC) 128 bit random salt in any case.
161 2014-01-30 02:11:02 <Luke-Jr> alex_fun: making the timestamps earlier makes difficulty go UP, not down
162 2014-01-30 02:11:11 <EasyAt> gmaxwell: That makes sense
163 2014-01-30 02:11:11 <Emcy> andytoshi is that all IPC improvement
164 2014-01-30 02:11:12 <alex_fun> true
165 2014-01-30 02:11:29 <Luke-Jr> plus, 100 rounds includes 50 rounds half way through..
166 2014-01-30 02:11:40 <Emcy> i benchmarked an athlon xp against an i7 afew days ago, same clocks the i7 had double the IPC
167 2014-01-30 02:11:53 <alex_fun> Luke-Jr: so when there is new get work issued - how node knows whether to increase diff of POW solution or keep it same?
168 2014-01-30 02:11:55 <Luke-Jr> alex_fun: and if you put your timestamp more than 2 hours in the future, nodes won't accept it until it's within 2 hours
169 2014-01-30 02:11:59 <Emcy> and that was just one core
170 2014-01-30 02:12:00 <gmaxwell> Luke-Jr: true, though its common to include the parameters in the input to prevent that kind of truncation
171 2014-01-30 02:12:26 <Luke-Jr> gmaxwell: well, then it's just using it as a (weak) salt too
172 2014-01-30 02:12:42 <gmaxwell> I dunno if the openssl evp stuff does that, but that was one of the changes that I had that encrypted bip32 master seed thing make.
173 2014-01-30 02:12:52 <andytoshi> Emcy: not sure. the 4th gen i-series has some cool ipc stuff but this i think is a consequence of having 8 cores instead of 2
174 2014-01-30 02:13:15 <Emcy> i found my old seti@home folder, i used to put out a unit in ~70hrs on a pentium, the i7 did one in 40 mins, so nominally ~10 mins per unit.
175 2014-01-30 02:13:19 <Emcy> such nostalgia
176 2014-01-30 02:17:38 <Emcy> i dont think the haswells are much mroe efficient than ivy bridge....intel seems to have let thier foot off the pedal since AMD flubbed thier chip
177 2014-01-30 02:18:12 <Emcy> but id like to see what AMD can really do with the APU stuff and heterogenous compute
178 2014-01-30 02:25:26 <alex_fun> Luke-Jr: ok I think I figured it out. - when diff rises and max it can rise in code is set to say 4x, it needs self adjust many times, as per y blocks that it uses for time stamp samples. so what if diff mad adjustment is set to sat 100000x and adjusts every 9 blocks, then after 9 blocks it simply reaches its natural maximum? can it be that simple? :)
179 2014-01-30 02:26:31 <alex_fun> this way it can be more accurate in terms of rewards per hash submitted :)
180 2014-01-30 05:00:07 <jcorgan> what's with the random nicks that just joined #bitcoin
181 2014-01-30 05:00:16 <jcorgan> ah, sorry, that was for ops
182 2014-01-30 05:23:10 <swulf--> jgarzik: would you approve me for the bitcoin mailing list?
183 2014-01-30 05:24:01 <michagogo> cloud|swulf--: I don't think it needs approval, does it?
184 2014-01-30 05:24:15 <michagogo> cloud|(It didn't for me, afaicr...)
185 2014-01-30 05:24:23 <swulf--> i subscribed but it said... "Your subscription request has been received, and will soon be acted upon. Depending on the configuration of this mailing list, your subscription request may have to be first confirmed by you via email, or approved by the list moderator."
186 2014-01-30 05:24:32 <swulf--> and since I haven't receied an email, I presume a moderator has to approve the request?
187 2014-01-30 05:24:43 <michagogo> cloud|I don't think so
188 2014-01-30 05:24:56 <swulf--> hrm...
189 2014-01-30 05:25:06 <michagogo> cloud|I don't think it sends another email
190 2014-01-30 05:26:39 <swulf--> All right, thanks
191 2014-01-30 05:31:26 <swulf--> hmm
192 2014-01-30 05:31:32 <swulf--> seems like all my requests to subscribe are ignored
193 2014-01-30 05:32:13 <swulf--> In the past, at one time I got dropped because my mailserver was offline for some time. I got some bitcoin-development-bounces email that I had be unsubscribed. Can't seem to re-sub
194 2014-01-30 05:43:28 <swulf--> ah, finally
195 2014-01-30 06:48:18 <maaku> how do you force acceptance of a non-standard transaction type into the mempool?
196 2014-01-30 08:44:46 <Luke-Jr> wumpus: FYI, KB does exist as 1024 ;)
197 2014-01-30 08:44:54 <wumpus> Luke-Jr: officially?
198 2014-01-30 08:45:00 <Luke-Jr> yes
199 2014-01-30 08:45:16 <wumpus> wikipedia doesn't mention it :(
200 2014-01-30 08:45:52 <Luke-Jr> Wikipedia has biases
201 2014-01-30 08:46:13 <Luke-Jr> https://en.wikipedia.org/wiki/Binary_prefix does mention it, though
202 2014-01-30 08:46:19 <Luke-Jr> at least in the table on the right, JEDEC standard
203 2014-01-30 08:46:49 <wumpus> yes it has certainly biases, also against bitcoin, but for something like unit's you'd expect they would get over themselves
204 2014-01-30 08:46:58 <wumpus> right
205 2014-01-30 08:49:22 <wumpus> in any case, feel free to update that RPC documentation, 1024 versus 1000 is a much smaller issue than people thinking the settxfee is *for the total transaction*, I re-did that change because it was lost along the way, I didn't intend to make it a controversial point...
206 2014-01-30 08:53:25 <Luke-Jr> wumpus: nah, not arguing at all - just wanted to let you know the standard does exist :p
207 2014-01-30 09:04:33 <abrkn> swulf: did you get a chance to review my bip32 code? i'm hesitant to put it into production. would suck to lose private keys...
208 2014-01-30 09:06:36 <sneak> please don't use the power of 2 values for the value prefixes
209 2014-01-30 09:07:06 <sneak> it's anachronistic and is not what those prefixes mean. it's a "standard" that should have died years ago but computer people love meaningless tradition
210 2014-01-30 09:07:38 <sneak> if you must refer to those values use "kibi" "mebi" "gibi" etc, but don't even do that if you can avoid it
211 2014-01-30 09:08:06 <sneak> abide by SI, it will serve you well
212 2014-01-30 09:08:33 <wumpus> stop preaching to the choir
213 2014-01-30 09:09:16 <sneak> that's like, my trademark
214 2014-01-30 09:09:31 <wumpus> we're all a fan of SI sanity here, why do you think we just went for mBTC, μBTC instead of funny names
215 2014-01-30 09:14:46 <sturles> We could give mBTC a more easily pronounced common name. E.g. millicoins or just millis. Like the Euro has cents (hundreds) instead of centieuro.
216 2014-01-30 09:15:17 <wumpus> obviously
217 2014-01-30 09:15:28 <wumpus> you can call it everything you like :)
218 2014-01-30 09:17:31 <wumpus> but what I mean is, see for example the ethereum paper, they try to do funny non-SI denoninations
219 2014-01-30 09:21:25 <sturles> That's just silly. This is Bitcoin, not Doge.
220 2014-01-30 09:22:00 <sneak> sturles: ?
221 2014-01-30 09:22:27 <magbo> I want to debug my bitcoin entity parser (I have a bug in script parsing). Is there a transaction dissecter that accepts hex representation and spits out dissected entity?
222 2014-01-30 09:23:00 <sturles> sneak: ?
223 2014-01-30 09:23:12 <sneak> sturles: i was just confused what you were replying to
224 2014-01-30 09:23:16 <sneak> don't mind me
225 2014-01-30 09:32:53 <magbo> Oh, found the bug but the question still exists: is there a good repl-dissector?
226 2014-01-30 09:52:39 <TD> good morning
227 2014-01-30 10:53:28 <michagogo> cloud|8:48:17 <maaku> how do you force acceptance of a non-standard transaction type into the mempool?
228 2014-01-30 10:53:38 <michagogo> cloud|You change the software.
229 2014-01-30 10:53:58 <michagogo> cloud|11:09:30 <wumpus> we're all a fan of SI sanity here, why do you think we just went for mBTC, μBTC instead of funny names
230 2014-01-30 10:54:12 <michagogo> cloud|*cough*Luke*cough*
231 2014-01-30 10:56:25 <swulf--> abrkn: I look over it, but I haven't tested it. It looks fine TBH but also, I'm not a cryptographer :)
232 2014-01-30 10:56:38 <swulf--> It'd be awesome to get gmaxwell to review both of our projects:)