1 2012-10-16 01:20:03 <amiller> ugh i have a blk000*.dat that seems to have an error in it or at least a disk corruption
2 2012-10-16 01:20:33 <amiller> i tried to use bitcointools to find it but got stuck because bitcointools relies on blkindex.dat and i'm not sure if that's where the error is
3 2012-10-16 01:21:05 <amiller> so now i'm finally switching to pynode for my serialization and block scanning needs
4 2012-10-16 01:22:08 <amiller> i'm hoping i can find the offending chunk of data and just overwrite it with better bits
5 2012-10-16 01:22:57 <phantomcircuit> amiller, good bits
6 2012-10-16 01:24:14 <amiller> only the finest bits
7 2012-10-16 01:54:45 <gmaxwell> There, testnet now has a block with 6287 transactions.
8 2012-10-16 02:30:09 <alexmat`goBRONCO> wts 500$ newegg giftcard for 300$, also selling bitcoins at 10$ a pop, cheapest in the market. Bulk buyers invited! also selling nba2k13 for 25$ a pop have 10
9 2012-10-16 02:31:37 <alexmat`goBRONCO> wts 500$ newegg giftcard for 300$, also selling bitcoins at 10$ a pop, cheapest in the market. Bulk buyers invited! also selling nba2k13 for 25$ a pop have 10
10 2012-10-16 02:46:25 <jgarzik> gmaxwell: if you're poking at testnet... a block with the largest transaction possible would be useful
11 2012-10-16 02:46:43 <jgarzik> As close as one can get to 1MB
12 2012-10-16 02:46:58 <gmaxwell> jgarzik: well, was really poking at p2pool, testnet was a side effect. But I'll add one of those too.
13 2012-10-16 02:47:16 <jgarzik> thanks
14 2012-10-16 02:48:00 <amiller> jgarzik, pynode's serialization is all your own code, right?
15 2012-10-16 02:48:31 <amiller> what would you think about packaging it up with a setup.py and __init__ and such for use as a blockchain scanning/correction tool?
16 2012-10-16 02:49:32 <jgarzik> amiller: Original author was ArtForz. He wrote all the ser/deser code for the major data structures, and then wrapped an asyncore "half a node" around it. Posted it on pastebin, with a public domain license.
17 2012-10-16 02:49:42 <amiller> ahh.
18 2012-10-16 02:49:51 <jgarzik> amiller: yes, the bitcoin/ directory was designed to be packaged eventually
19 2012-10-16 02:50:19 <Diablo-D3> http://boingboing.net/2012/10/15/winners-of-the-pirate-flix-vid.html
20 2012-10-16 02:50:24 <jgarzik> amiller: hoped to call it "python-bitcoin", and make it a separate repo from pynode
21 2012-10-16 02:50:49 <jgarzik> amiller: then any number of apps may use python-bitcoin for core encoding, signature and script work, ...
22 2012-10-16 02:51:19 <spreelanka> where is the bitcoind main() ? is it hidden in a boost macro?
23 2012-10-16 02:51:40 <amiller> jgarzik, it reads blk00*.dat but notably has absolutely nothing to say about bdb blkindex.dat
24 2012-10-16 02:51:55 <amiller> that's in contrast to bitcointools
25 2012-10-16 02:52:08 <amiller> is that an artifact of your selection from artforz's pastebin?
26 2012-10-16 02:52:35 <jgarzik> amiller: don't understand last question. See pynode's README, first paragraph.
27 2012-10-16 02:52:45 <jgarzik> amiller: check out "mini-node" branch to see original-ish code
28 2012-10-16 02:53:20 <jgarzik> README links to original pastebin
29 2012-10-16 02:53:23 <amiller> ACTION rtfm
30 2012-10-16 02:53:41 <doublec> spreelanka: init.cpp
31 2012-10-16 02:54:17 <spreelanka> doublec: AppInit() right?
32 2012-10-16 02:54:23 <spreelanka> kk, thx
33 2012-10-16 02:54:38 <doublec> np
34 2012-10-16 02:54:45 <doublec> spreelanka: main calls that, yes
35 2012-10-16 02:58:54 <gmaxwell> hm.. decoderaw transaction doesn't like it when ou call it with really long scriptpubkeys..
36 2012-10-16 02:59:59 <Diablo-D3> gmaxwell: ^ boingboing url
37 2012-10-16 03:00:00 <Diablo-D3> watch video
38 2012-10-16 03:01:03 <amiller> i'm sure this is a dumb question, but it looks like there's 8 bytes of bullshit in between the blocks in blk*.dat? blkindex skips over it
39 2012-10-16 03:01:10 <amiller> nvm i'll just check how bitcoind writes it
40 2012-10-16 03:02:51 <gmaxwell> It's the capture token. ('version bytes')
41 2012-10-16 03:03:57 <amiller> (i'll just guess that a capture token means what i think it means)
42 2012-10-16 03:04:14 <amiller> my guess is it's equivalent to the sync markers used in apache sequence files
43 2012-10-16 03:04:40 <amiller> if you have local corruption you can skip over a bunch of data by scanning for the next 'capture token' and keep reading frm there
44 2012-10-16 03:06:21 <gmaxwell> yep.
45 2012-10-16 03:07:22 <amiller> i don't suppose any bitcoind code makes use of that?
46 2012-10-16 03:07:45 <amiller> if an error in blk*.dat is detected, an efficient way to recover would be to ask a peer for a fresh copy and just append
47 2012-10-16 03:08:25 <amiller> i meant to say blk0*.dat to exclude blkindex.dat
48 2012-10-16 03:11:58 <amiller> besides apache sequence files, http uses a similar scheme for multipart encodings
49 2012-10-16 03:12:15 <amiller> 'capture token' returns no hits.. there has to be a generic name for this?
50 2012-10-16 03:20:47 <gmaxwell> darnit.. 65414 nops before I get 'bitcoind: Argument list too long'
51 2012-10-16 03:21:25 <gmaxwell> and that txn is only a bit over a half meg.
52 2012-10-16 03:23:24 <maaku> Luke-Jr why do you have to be so unconforming?
53 2012-10-16 03:23:36 <maaku> tabs in a Python file.. what heresy! ;)
54 2012-10-16 03:39:49 <gmaxwell> https://xkcd.com/
55 2012-10-16 03:40:08 <gmaxwell> https://xkcd.com/1121/ (better link, for the logs)
56 2012-10-16 03:41:36 <gmaxwell> 0_o
57 2012-10-16 03:41:37 <gmaxwell> 10/16/12 05:41:15 ERROR: CTxMemPool::accept() : not enough fees 43aa7e69262e1899230f4fae378cf36af5d272760a863cc896d6eb5d5a0129bf, 100000000 < 2100000000000000
58 2012-10-16 03:43:39 <jgarzik> gmaxwell: heh, was that the mega-fat testnet tx?
59 2012-10-16 03:45:41 <gmaxwell> okay, I have a 999999 byte transaction in my mempool now.. thats the largest it would take. but it's not minable. :-/
60 2012-10-16 03:46:45 <gmaxwell> well this is sort of annoying. I can't just reduce the size until it take it because it'll take things that can't be mined.
61 2012-10-16 03:47:18 <gmaxwell> this is also a "you can create a txn that can't possibly be confirmed" 'vulnerability' but fortunately the normal fee rules are protective.
62 2012-10-16 03:49:11 <gmaxwell> well crap, now its in my wallet too. Okay. will worry about this tomorrow.
63 2012-10-16 03:49:43 <gmaxwell> (I decided to put all the bloat in the scriptpubkey since it should be useful as an ultraprune test too)
64 2012-10-16 05:52:56 <jeremias> would it make more sense for the importprivkey command to return the bitcoin address if the operation was successful
65 2012-10-16 05:53:04 <jeremias> now it returns nothing
66 2012-10-16 06:18:32 <sipa> amiller: -loadblock uses those markers
67 2012-10-16 09:53:35 <Luke-Jr> maaku: I conform to common sense? :P
68 2012-10-16 09:54:39 <Luke-Jr> gmaxwell: is there any reason to prefer pow(2, floor(log2(ma, 2))) vs using integer bitshift ops to implement the same without FPU?
69 2012-10-16 09:56:06 <_dr> the former is much slower :)
70 2012-10-16 09:57:38 <_dr> pow will translate into exp, and the gcc version sucks, uses like 150 flops
71 2012-10-16 09:58:12 <sipa> Luke-Jr: is that code to strip all bit the highest bit from an integer?
72 2012-10-16 09:58:18 <sipa> *but
73 2012-10-16 09:58:32 <Luke-Jr> sipa: more or less, rounds down to nearest power of two
74 2012-10-16 09:58:44 <Luke-Jr> _dr: ouch
75 2012-10-16 09:59:46 <sipa> http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2
76 2012-10-16 10:06:25 <JyZyXEL> is there any description of the current coinbase format in wiki?
77 2012-10-16 10:07:13 <Luke-Jr> BIP 32
78 2012-10-16 10:12:58 <sipa> 34
79 2012-10-16 10:13:26 <JyZyXEL> 34 describes some modifications but it doesn't have the full description of the format
80 2012-10-16 10:13:47 <sipa> there are no restrictions except for what BIP34 says, and the network rules
81 2012-10-16 10:14:00 <sipa> (and the network rules say: at least 2 bytes, at most 100 bytes)
82 2012-10-16 10:15:06 <senseless> When I send a transaction from my wallet; does that transaction get broadcast to every connected peer simultaneously, one by one, or how does that work?
83 2012-10-16 10:38:18 <kjj_> senseless: one by one. there is no other way it could be on a unicast system
84 2012-10-16 10:39:00 <Luke-Jr> kjj_: well, it would be nice if bitcoind did it async
85 2012-10-16 10:39:46 <senseless> Is there any way to set a priority on addresses for communication currently?
86 2012-10-16 10:41:09 <kjj_> Luke-Jr: multicast would be nice too, but for the foreseeable future, it will remain sequential
87 2012-10-16 10:41:30 <kjj_> senseless: no
88 2012-10-16 10:44:01 <_dr> doing it async seems like a good idea
89 2012-10-16 10:44:42 <senseless> My thing is just that i'm running a node on a server that all my miners and what not connect to
90 2012-10-16 10:44:50 <senseless> and it's got a couple hundred peers
91 2012-10-16 10:45:07 <senseless> I'd like it to send me new block notifications and transaciton notifications before everyone else
92 2012-10-16 10:45:09 <senseless> and vice versa
93 2012-10-16 10:45:25 <senseless> I might end up taking extra time to download a new block from a peer in antartica
94 2012-10-16 10:46:08 <senseless> And end up with a bunch of stale shares which may have been winners on the new block, or winners on the old block
95 2012-10-16 10:46:28 <senseless> Instead of downloading it from the peer with a 5ms ping
96 2012-10-16 10:47:46 <senseless> either unicast or multicast would solve that problem as well
97 2012-10-16 10:50:28 <kjj_> well, the code to relay new blocks starts around line 1919 of main.cpp
98 2012-10-16 10:51:07 <gmaxwell> Luke-Jr: personally I prefer to CLZ to reond own to the nearest power of two. Certantly doing it with float is weird and potentially problematic. Is the code you're asking about performance critical? If so: 1<<sizeof(int)*8-__builtin_clz(x)-1 (in a macro, with ifdefs to get the windows builtin and an ansi c fallback (search opus code for EC_ILOG) is what you want, since the clz is single cycle on x86.
99 2012-10-16 10:51:41 <kjj_> looks like BOOST_FOREACH has a fixed order, so if you want to add a priority value, a method to set it, and a way to sort the list, it should do what you want
100 2012-10-16 10:53:12 <gmaxwell> senseless: running a couple hundred peers on a node isn't a grand iea.
101 2012-10-16 10:53:17 <gmaxwell> er idea either.
102 2012-10-16 10:54:44 <senseless> My thought was that the more peers I have, the faster I will be notified of transactions or new blocks
103 2012-10-16 10:54:47 <senseless> Is that incorrect?
104 2012-10-16 10:56:47 <gmaxwell> senseless: Blocks spread exponentially in the network, I expect there to be greatly diminishing marginal returns from more peers. At the same time, we relay sequentially, and so the chances that you'll hit a slow peer early on and be greatly delayed in realying are increased.
105 2012-10-16 10:57:32 <gmaxwell> You'll also burn more cpu time chattering with nodes and feeding network edges. ... and if you've hacked the code to increase the output count you're also harming the network.
106 2012-10-16 10:57:52 <kjj_> gmaxwell: for incoming notifications, more probably is better
107 2012-10-16 10:58:12 <Luke-Jr> gmaxwell: it's not, I was just curious <.<
108 2012-10-16 10:59:15 <gmaxwell> kjj_: "more probably is better" isn't incompatible with "greatly diminishing marginal returns" .. and it depends on what you're doing.
109 2012-10-16 10:59:54 <kjj_> heh, I'm just saying the slow node problem only hits for outgoing. for incoming connections, having more of them increases the chances that you'll be early in one of their lists
110 2012-10-16 11:00:06 <kjj_> er, incoming messages rather
111 2012-10-16 11:00:29 <gmaxwell> My mining nodes run ~7 connections. Connections to each other, connections to several known miners, and connections to my public nodes which are normal listerns and have on the order of 80 connections these days.
112 2012-10-16 11:01:57 <gmaxwell> kjj_: Yes, it increases it, but it should increase it only slightly, while at the same time burning a lot more bandwidth and cpu, and making outbound problems more likely (very important if mining).
113 2012-10-16 11:09:56 <gmaxwell> I noticed in the latest rust language announcement they mention that they've changed all their hashtables to use something calle siphash (apparently a fast hash function optimized for small inputs), e.g. for complexity attack avoidance.
114 2012-10-16 11:10:16 <gmaxwell> Perhaps something we should use the next time we need a fast hash function.
115 2012-10-16 11:11:07 <gmaxwell> (e.g. for things like addrman's usage, PRF in coin-selection, or attack vulnerable hash tables)
116 2012-10-16 11:17:03 <Matt_von_Mises> In the miner tests, do the blocks get added to the genesis block? https://github.com/bitcoin/bitcoin/blob/master/src/test/miner_tests.cpp
117 2012-10-16 12:13:10 <gmaxwell> http://www.schneier.com/blog/archives/2012/10/studying_zero-d.html "We also find that a typical zero-day attack lasts 312 days on average and that, after vulnerabilities are disclosed publicly, the volume of attacks exploiting them increases by up to 5 orders of magnitude."
118 2012-10-16 12:36:38 <spreelanka> where are blocks created?
119 2012-10-16 12:38:44 <gmaxwell> spreelanka: everwhere. Can you clarify your question some?
120 2012-10-16 12:39:47 <spreelanka> gmaxwell: i'm looking for places where the nonces are added that the miner looks for
121 2012-10-16 12:41:05 <gmaxwell> Er. perhaps this page will be informative to you: https://en.bitcoin.it/wiki/Block_hashing_algorithm
122 2012-10-16 12:41:11 <spreelanka> thx
123 2012-10-16 12:41:41 <gmaxwell> But nonces aren't added, they are fields in varrious locations that get incremented until the hashed header value is low enough to meet the target difficulty.
124 2012-10-16 12:59:43 <spreelanka> gmaxwell: ok, thanks, i got caught up reading. that was really helpful, i need to read all the articles in https://en.bitcoin.it/wiki/Category:Technical eventually
125 2012-10-16 12:59:55 <spreelanka> but i kinda want to learn a bit, experiment, learn a bit, etc
126 2012-10-16 13:00:36 <spreelanka> so when this happens: if (hash <= hashTarget)
127 2012-10-16 13:01:01 <spreelanka> we "solved" it, pending CheckWork()?
128 2012-10-16 13:01:19 <spreelanka> and we go to attempt to claim credit by some means
129 2012-10-16 13:02:03 <Luke-Jr> O.o
130 2012-10-16 13:02:06 <Luke-Jr> no
131 2012-10-16 13:02:16 <Luke-Jr> CheckWork = (hash <= hashTarget)
132 2012-10-16 13:02:19 <spreelanka> please, edify me
133 2012-10-16 13:02:27 <Luke-Jr> and you claim credit BEFORE you start hashing
134 2012-10-16 13:02:35 <Luke-Jr> it's the first transaction in the block
135 2012-10-16 13:02:41 <Luke-Jr> you just write it to pay yourself
136 2012-10-16 13:02:50 <Luke-Jr> then when that block becomes valid, you have it
137 2012-10-16 13:15:48 <spreelanka> luke-jr: i'm looking at it, but it's probably just better to ask: main.cpp:3891 means the miner "succeeded" gains reward, new block on the blockchain?
138 2012-10-16 13:16:11 <graingert> spreelanka: Lu[press tab]
139 2012-10-16 13:16:31 <spreelanka> Luke-Jr: ping
140 2012-10-16 13:16:32 <Luke-Jr> spreelanka: bitcoind is not a miner
141 2012-10-16 13:18:17 <spreelanka> Luke-Jr: i just assumed it could because of void static BitcoinMiner(CWallet *pwallet)
142 2012-10-16 13:18:29 <spreelanka> Luke-Jr: and -gen
143 2012-10-16 13:19:03 <Luke-Jr> spreelanka: meh, that's deprecated and probably should be removed
144 2012-10-16 13:19:15 <Luke-Jr> it never finds blocks. maybe on testnet, but even then it's inefficient
145 2012-10-16 13:19:37 <spreelanka> inefficient is fine, i'm just learning
146 2012-10-16 13:20:41 <sipa> Luke-Jr: it works fine on testnet
147 2012-10-16 13:20:59 <sipa> it works fine on mainnet as well, though it probably takes ages on any existing hardwre
148 2012-10-16 13:22:28 <spreelanka> sipa: ok, cool, i'll start from there then, thanks for the help
149 2012-10-16 13:22:47 <sipa> spreelanka: what is on main.cpp:3891?
150 2012-10-16 13:23:18 <spreelanka> sipa: if (hash <= hashTarget)
151 2012-10-16 13:23:24 <spreelanka> sipa:
152 2012-10-16 13:24:07 <spreelanka> sipa: the nearby // Found a solution
153 2012-10-16 13:24:16 <sipa> well, what luke said is right: you try to produce a block which pays out to yourself; if the block happens to be valid, it gets broadcasted, and hopefully accepted by the network
154 2012-10-16 13:24:26 <sipa> there is no "reward" mechanism after block mining
155 2012-10-16 13:24:54 <Luke-Jr> spreelanka: yes, (hash <= hashTarget) is the goal
156 2012-10-16 13:25:50 <gmaxwell> 'Mining produces its own reward.'
157 2012-10-16 13:25:52 <spreelanka> right, you do confirm it locally before broadcasting though, right
158 2012-10-16 13:26:28 <Luke-Jr> spreelanka: bitcoind accepts your own block as if it's any other untrusted peer
159 2012-10-16 13:26:36 <spreelanka> once you get below difficulty, you know you have a valid block, and you broadcast it, and if you were first the network accepts it?
160 2012-10-16 13:26:39 <Luke-Jr> it doesn't *need* to, but that helps resist bugs
161 2012-10-16 13:26:52 <spreelanka> ok
162 2012-10-16 13:27:03 <Luke-Jr> above difficulty, below the target; otherwise, yes
163 2012-10-16 13:27:16 <spreelanka> right, right
164 2012-10-16 13:27:29 <spreelanka> ok, thanks
165 2012-10-16 13:45:15 <helo> do you have to be first? i.e. if you are second your height is the same as the "first" height, right?
166 2012-10-16 13:47:34 <gmaxwell> helo: what does 'first' mean?
167 2012-10-16 13:47:51 <gmaxwell> The perception of ordering is not a universal thing; if it were we wouldn't need mining.
168 2012-10-16 13:48:16 <helo> gmaxwell: most peers have accepted a different miner's block already
169 2012-10-16 13:48:43 <gmaxwell> helo: then they'll ignore the 'second' one unless it becomes part of the longest chain.
170 2012-10-16 13:49:43 <gmaxwell> helo: nodes use that blocks that are part of the longest (sum difficulty) chain. If there are compeating forks with the same length they stick with whatever they heard first..
171 2012-10-16 13:49:44 <helo> so the second one will be ignored because it is not longer, even though it is the same?
172 2012-10-16 13:50:31 <gmaxwell> but in your example you said "most peers" not "all" so it's possible under the most peers assumption that the 'second' to be created might ultimately end up in the longest chain instead of the first.
173 2012-10-16 13:51:20 <gmaxwell> e.g. if most but not all nodes heard the other one first, then some may take the second instead... If a subsiquent block is found first against the second then that chain becomes longest and the network reorgs onto it.
174 2012-10-16 13:51:58 <helo> right... thanks
175 2012-10-16 14:18:45 <jgarzik> gavinandresen: how are we looking for 0.7.1 release? I only see that one potential locking bug, in the -rc1 thread.
176 2012-10-16 14:19:07 <jgarzik> https://bitcointalk.org/index.php?topic=117874.msg1273313#msg1273313
177 2012-10-16 14:20:38 <gavinandresen> I don't see how any of the .1 changes could have introduced that bug (do you?), so I'm inclined to promote rc1 to final.
178 2012-10-16 14:21:17 <gavinandresen> I sent email to Arklan and Steve to see if they have objections... I was hoping to be able to test out a more formal QA process. Ah well.
179 2012-10-16 14:21:53 <jgarzik> I dunno, as it involves GUI
180 2012-10-16 14:21:57 <jgarzik> I'm fine for releasing 0.7.1
181 2012-10-16 14:23:17 <gmaxwell> Has anyone started a new node from start on 0.7.1rc without bootstrap.dat? Thats one test I didn't bother performing that I've historically done; partially because I expected the people who said they were doing testing to do it and it's sort of a pain because it takes a while.
182 2012-10-16 14:27:01 <jgarzik> gmaxwell: sure, WFM all the time
183 2012-10-16 14:27:43 <jgarzik> versus using a fast localhost node, the speed is pretty much the same as a file
184 2012-10-16 14:28:17 <rdponticelli> kwr
185 2012-10-16 14:28:58 <gmaxwell> jgarzik: okay, just making sure that someone bothered doing it! :P I have some nodes running that code... just hadnt purged their chains.
186 2012-10-16 14:58:32 <jgarzik> Man, this MPOE-PR sure is an ass. Would never use his exchange, given the unprofessional behavior, and the other stuff hosted on that site.
187 2012-10-16 14:59:00 <QuantumQrack> Is it possible to send btc via a google phone #?
188 2012-10-16 15:14:13 <midnightmagic> jgarzik: What other stuff?
189 2012-10-16 15:48:30 <jgarzik> midnightmagic: crazy pr0n
190 2012-10-16 15:54:31 <gmaxwell> I recommend using people who have negative rated me on OTC as a strong metric of incompetence. :P
191 2012-10-16 16:01:21 <jeremias> I don't understand why to store porn and a btc stock exchange at the same site :D
192 2012-10-16 16:01:32 <jeremias> sure improves the image
193 2012-10-16 16:02:12 <gribble> WARNING: Currently not authenticated. User gmaxwell, rated since Mon Jul 25 10:49:45 2011. Cumulative rating 39, from 19 total ratings. Received ratings: 16 positive, 3 negative. Sent ratings: 7 positive, 12 negative. Details: http://bitcoin-otc.com/viewratingdetail.php?nick=gmaxwell
194 2012-10-16 16:02:12 <vampireb_> ;;getrating gmaxwell
195 2012-10-16 16:12:28 <MC1984> 7.1 already?
196 2012-10-16 16:15:30 <BlueMatt> jeremias: save server space - put everything on one server! :)
197 2012-10-16 16:31:08 <Diablo-D3> http://www.romneytaxplan.com/
198 2012-10-16 16:36:49 <sipa> ;;bc,nethash
199 2012-10-16 16:36:52 <gribble> 23234.92473805663
200 2012-10-16 16:38:17 <helo> http://eprint.iacr.org/2012/584.pdf bitcoin transaction history analysis by Dorit Ron and Adi Shamir
201 2012-10-16 16:40:43 <gmaxwell> helo: yes, it's also somewhat incorrect.
202 2012-10-16 16:40:49 <gmaxwell> Though still interesting.
203 2012-10-16 16:41:21 <helo> the "78% of bitcoin in savings accounts" kind of misleading
204 2012-10-16 16:42:05 <gmaxwell> E.g. they go on and on the incorrect point that all inputs in a transaction _must_ be owned by the same person by rule of the system.
205 2012-10-16 16:42:52 <gmaxwell> Not only is that by no means been a rule of the system, it's not even been a safe rule of thumb ever since shared wallet multiuser systems (exchanges and webwallets) have existed.
206 2012-10-16 16:43:31 <sipa> not to mention explicit coin mixers
207 2012-10-16 16:43:41 <midnightmagic> jgarzik: Oh? But also: so?
208 2012-10-16 16:44:50 <helo> they are not owned by the same person, but they are controlled by the same person
209 2012-10-16 16:45:11 <graingert> helo: not even true
210 2012-10-16 16:45:24 <graingert> helo: you can have a mixing system that multiple people can take part in
211 2012-10-16 16:45:35 <midnightmagic> helo: That is not true, anymore.
212 2012-10-16 16:45:39 <sipa> helo: since multisig that is certainly not true anymore
213 2012-10-16 16:45:48 <helo> what percentage of transactions are multisig?
214 2012-10-16 16:45:58 <sipa> negligable
215 2012-10-16 16:46:13 <helo> right... irrelevant from a perspective of how bitcoin is used, because it isn't used in that way
216 2012-10-16 16:46:19 <midnightmagic> helo: In fact, it is possible for tx which aren't even muiltisig to be created in concert with many people.
217 2012-10-16 16:46:35 <TD> many things are _possible_ which are not done today
218 2012-10-16 16:46:48 <TD> so the papers analysis technique can be both reasonable for today and worthless tomorrow
219 2012-10-16 16:46:51 <midnightmagic> TD: I (now that I was taught how) do them all the time.
220 2012-10-16 16:47:11 <TD> the widespread usage of share wallets does seem to be a probllem for the authors. also, scraping block explorer. ew.
221 2012-10-16 16:47:26 <midnightmagic> I do not share my wallet, either.
222 2012-10-16 16:47:46 <midnightmagic> That is, my privkeys are my own and only I can use them to sign.
223 2012-10-16 16:47:47 <helo> the analysis they did is pretty valid, given that it says "this is how things worked over this period of time"
224 2012-10-16 16:48:59 <helo> i don't think they're trying to predict anything
225 2012-10-16 16:49:21 <sipa> but if they equate "coins controlled by the same entity" with "saving accounts", their analysis is worthless
226 2012-10-16 16:49:24 <midnightmagic> helo: They "downloaded" the entire analysis which they say consisted of 180,000 HTML files. blockexplorer does not interpret everything correctly.
227 2012-10-16 16:49:41 <helo> midnightmagic: yeah, that part is kind of silly
228 2012-10-16 16:51:57 <helo> it's good to see such a big name looking at bitcoin, at least
229 2012-10-16 16:52:11 <gmaxwell> helo: they assert that it's a rule of the system. This is _flatly_ untrue. And if you're talking about usage and who owns what, the practice of shared wallets is relevant. So it fails for either kind of usage.
230 2012-10-16 16:52:18 <midnightmagic> helo: It would have been better had this "Big Name" not operated in what appears to be a vacuum.
231 2012-10-16 16:53:11 <sipa> hmm, gavinandresen apparently built the BDB version of ultraprune
232 2012-10-16 16:53:17 <sipa> which failed because of not maintained
233 2012-10-16 16:53:50 <gavinandresen> I didn't try to build the BDB version...
234 2012-10-16 16:54:19 <midnightmagic> helo: It's interesting that such a large number of bitcoins are not in active circulation.
235 2012-10-16 16:54:40 <gavinandresen> sipa: I did build with USE_IPV6=0 USE_LEVELDB=1 USE_UPNP=-
236 2012-10-16 16:55:15 <sipa> gavinandresen: bitcoind or bitcoin-qt ?
237 2012-10-16 16:55:24 <gavinandresen> sipa: bitcoind
238 2012-10-16 16:55:53 <sipa> gavinandresen: i fixed the tab issue, by the way, but i assume you fixed that too?
239 2012-10-16 16:56:18 <helo> midnightmagic: they appear to be making an error in claiming "only 32% of bitcoin are in circulation because 78% are at addresses that have never been sent from"
240 2012-10-16 16:56:26 <gavinandresen> sipa: ah, I see what the problem is: I have a custom makefile that compile *.cpp
241 2012-10-16 16:56:56 <gavinandresen> (I think?)
242 2012-10-16 16:57:04 <sipa> ah, yes that would explain it
243 2012-10-16 16:57:14 <sipa> i suppose you can just delete txdb-bdb.cpp
244 2012-10-16 16:57:20 <helo> that's not verbatim, btw ;)
245 2012-10-16 16:59:24 <gavinandresen> sipa: now I get ...src/leveldb-1.5.0/libmemenv.a: No such file or directory
246 2012-10-16 16:59:48 <gavinandresen> .... looks like another makefile.osx bug
247 2012-10-16 17:00:04 <sipa> gavinandresen: with a custom makefile still?
248 2012-10-16 17:00:20 <sipa> gavinandresen: ooh, i see the bug
249 2012-10-16 17:00:22 <sipa> sec
250 2012-10-16 17:01:50 <gavinandresen> away, back later
251 2012-10-16 17:05:03 <gmaxwell> helo: https://en.bitcoin.it/wiki/Real_peer_review
252 2012-10-16 17:05:52 <sipa> gavinandresen: should/could be fixed
253 2012-10-16 17:06:20 <sipa> helo: haven't read the paper but 32%+78% sounds like an excessively large value of 100%
254 2012-10-16 17:07:04 <helo> gmaxwell: nice
255 2012-10-16 17:08:37 <helo> sipa: hopefully i'm misunderstanding something in the paper... if i have 50btc, and i send my friend 16btc, the reference client sends my change to a new address which has never been sent from. so that 50btc, even if i just sent it, isn't counted as "in circulation"
256 2012-10-16 17:09:32 <helo> err, sorry my (50 - 16) btc isn't in circulation
257 2012-10-16 17:09:35 <gmaxwell> helo: define 'have'?
258 2012-10-16 17:09:58 <gmaxwell> You can 'have' 50 btc and send 16 btc without creating any change at all.
259 2012-10-16 17:10:32 <helo> hmm... yeah
260 2012-10-16 17:10:45 <QuantumQrack> changing ownership makes more sense than "sending" or "receiving"
261 2012-10-16 17:11:36 <sipa> it's like saying during an election that 5% of voters switched from party A to party B, while in realy 50% switched one way and 45% switched the other way
262 2012-10-16 17:11:48 <sipa> well... the opposite actually
263 2012-10-16 17:12:18 <gmaxwell> If you spend a 50 BTC coin and generate change it is not possible to confidently identify which outputs are payments (0, 1, or both) and which outputs are change (0, 1, or neither) or if the whole thing wasn't a self send (for mixing, to move coins between walltets, or to accounts at services that you own)
264 2012-10-16 17:16:37 <helo> i'd like to see the distribution of bitcoin among txouts
265 2012-10-16 17:16:55 <sipa> just amount/txout ?
266 2012-10-16 17:17:10 <helo> yes
267 2012-10-16 17:17:38 <sipa> how do you want the data?
268 2012-10-16 17:18:04 <helo> csv is fine, whatever's convenient :D
269 2012-10-16 17:18:45 <sipa> i have a function already that iterates over all unspent txouts, so i can easily write some code
270 2012-10-16 17:18:50 <graingert> gmaxwell: with is it possible to have a tx with multiple owners using SIGHASH_ALL ?
271 2012-10-16 17:20:16 <graingert> gmaxwell: is it possible to have a tx with multiple owners using SIGHASH_ALL ? *
272 2012-10-16 17:21:12 <sipa> graingert: 'owners' of an output is defined by its output script; SIGHASH_ALL is more about who can modify the transaction
273 2012-10-16 17:21:32 <gmaxwell> graingert: sure!
274 2012-10-16 17:22:34 <gmaxwell> graingert: the signatures on a transaction don't tell you who 'authored' it, or even who owned the funds its spending, no matter what sighash type is in use.
275 2012-10-16 17:23:05 <gmaxwell> graingert: do you have a unspent coin you control that you can tell me the txid and vout index for?
276 2012-10-16 17:23:22 <gmaxwell> (I can demonstrate)
277 2012-10-16 17:31:10 <graingert> gmaxwell: what does that mean?
278 2012-10-16 17:31:15 <graingert> gmaxwell: I do
279 2012-10-16 17:31:15 <sipa> helo: http://pastebin.com/qA3BSS6w
280 2012-10-16 17:31:31 <helo> sipa: neet... thank you
281 2012-10-16 17:31:47 <graingert> gmaxwell: I'd probably have to make a new tx, which envolves a trek to the vault
282 2012-10-16 17:31:58 <sipa> helo: in satoshis, of course
283 2012-10-16 17:36:55 <gmaxwell> graingert: hah then don't worry about it, too much trouble for a demo then. I was going to author a transaction which jointly spent some coins of yours and mine, signed it, and handed it to you.
284 2012-10-16 17:37:10 <graingert> :(
285 2012-10-16 17:37:30 <graingert> I'd need to sign that somehow right?
286 2012-10-16 17:37:56 <graingert> I'd sign the new output with my unspent output
287 2012-10-16 17:38:00 <graingert> 's key
288 2012-10-16 17:38:03 <gmaxwell> right, its not valid until you sign it. There is a signrawtransaction command in bitcoin for this. (available at the CLI or GUI console)
289 2012-10-16 17:38:24 <graingert> and that would not be distinguishable from a "regular" tx
290 2012-10-16 17:38:45 <gmaxwell> with sighash all the signatures cover everything except the other signatures. And yes, it _would_ be a "regular" tx as far as anyone could tell.
291 2012-10-16 17:38:55 <graingert> gmaxwell: so the paper is wrong
292 2012-10-16 17:39:04 <gmaxwell> Yes, the paper is wrong.
293 2012-10-16 17:39:19 <gmaxwell> Now??? it's true that this isn't a _common_ practice, at least not yet.
294 2012-10-16 17:39:26 <graingert> gmaxwell: I'm waiting for my account to activate
295 2012-10-16 17:39:30 <gmaxwell> But it doesn't even require special software anymore.
296 2012-10-16 17:39:45 <graingert> gmaxwell: it could remove a lot of unspent outputs
297 2012-10-16 17:40:15 <graingert> gmaxwell: if every so often everyone dumped all of their ouputs into one in one huge tx
298 2012-10-16 17:40:40 <graingert> although it would be a pain to orchestrate
299 2012-10-16 17:41:06 <graingert> also great of laundering
300 2012-10-16 17:44:04 <sipa> graingert: account to activate...?
301 2012-10-16 17:44:27 <graingert> sipa: on iacr.org
302 2012-10-16 17:44:33 <sipa> ah
303 2012-10-16 17:45:11 <graingert> sipa: is there a wiki page describing the one tx "laundering" scheme