1 2013-08-26 00:47:55 <jgarzik> heh, cute. Under 10 lines of code.
2 2013-08-26 00:48:04 <jgarzik> /rest/block/template.(dat}txt)
3 2013-08-26 00:48:12 <jgarzik> /rest/block/template.(dat|txt)
4 2013-08-26 00:48:20 <jgarzik> obtains a miner block template via HTTP REST
5 2013-08-26 00:48:32 <Luke-Jr> should txt be json?
6 2013-08-26 00:48:53 <jgarzik> Luke-Jr, no, that would be /rest/block/template.json
7 2013-08-26 00:49:01 <jgarzik> Luke-Jr, .txt is hex-encoded binary
8 2013-08-26 00:49:29 <Luke-Jr> bleh, what happened to using HTTP standards? :P
9 2013-08-26 00:50:15 <jgarzik> Luke-Jr, it does use http standards -- in a way that is more compatible with http-download tools
10 2013-08-26 00:51:23 <jgarzik> Luke-Jr, current implementation does not include /rest/block/template.json, because I was undecided how to mesh that with BIP 22
11 2013-08-26 00:51:36 <lianj> what just happened, 30 minutes no blocks and then 3 in 4 minutes with the newst an older timestamp than the one before
12 2013-08-26 00:51:47 <lianj> seems like they were all pushed at the same time
13 2013-08-26 00:52:18 <lianj> ah nevermind about the timestamp???
14 2013-08-26 00:52:22 <jgarzik> Luke-Jr, regardless, I am /not/ pushing this into the HTTP REST pull req
15 2013-08-26 00:52:32 <jgarzik> it would be a separate pull req, if it ever makes it that far
16 2013-08-26 00:52:47 <jgarzik> I'm thinking the binary format will be nice for my C++ poolserver
17 2013-08-26 02:29:06 <gmaxwell> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/2905#issuecomment-23243152
18 2013-08-26 02:29:12 <gmaxwell> Are you on this poolowner's mailing list?
19 2013-08-26 02:29:32 <gmaxwell> And is that just someone who is totally blinking clueless and thinks that bitcoind not using getwork prevents them from serving getwork miners?
20 2013-08-26 02:32:21 <k9quaint> has someone made a haskell implementation of the bitcoin client yet?
21 2013-08-26 02:32:49 <doublec> gmaxwell: I'm that clueless pool owner
22 2013-08-26 02:33:08 <gmaxwell> sweet.
23 2013-08-26 02:33:23 <doublec> gmaxwell: my comment was answering if anyone used getwork
24 2013-08-26 02:33:31 <gmaxwell> doublec: is there an actual issue here for you? Does not going getwork to bitcoin prevent you from serving getwork to users?
25 2013-08-26 02:33:35 <doublec> gmaxwell: I have no problem with getwork being removed
26 2013-08-26 02:33:38 <gmaxwell> Ah!
27 2013-08-26 02:33:49 <doublec> gmaxwell: but until I make the code changes I need to stick to an older bitcoind obviously
28 2013-08-26 02:34:11 <doublec> gmaxwell: and I was askiing if security patches would be provided/backported to a getwork supporting bitcoind
29 2013-08-26 02:34:59 <doublec> gmaxwell: I asked this because 0.8.2+ seem to have deadlocks with high usage of getwork
30 2013-08-26 02:35:04 <gmaxwell> doublec: oh, you don't support getwork based miners by generating getwork responses from GBT?
31 2013-08-26 02:35:07 <doublec> gmaxwell: and I hadn't upgraded from 0.8.1 as a result
32 2013-08-26 02:35:21 <doublec> gmaxwell: no, my code predates that and I've not invested time in getwork since then
33 2013-08-26 02:35:55 <gmaxwell> Fair enough. (this, in fact, means you're not clueless. :P)
34 2013-08-26 02:36:35 <doublec> I also acknowledged that this might be problematic due to lack of development resources and desire not to reveal the security issue
35 2013-08-26 02:37:01 <doublec> I'm fine with doing the extra work - just need to bump it up to my "need to do now" queue.
36 2013-08-26 02:37:06 <doublec> or drop all getwork miners
37 2013-08-26 02:37:09 <doublec> which is tempting
38 2013-08-26 02:39:04 <doublec> k9quaint: roconnor worked on one but I don't know if development is continuing
39 2013-08-26 02:39:09 <gmaxwell> If you're running 0.8.1 you're already exposed to easily exploited issues. I suggest not exposing that node to the public network and you're fine.
40 2013-08-26 02:39:15 <gmaxwell> Also... you really should report your deadlocks. :(
41 2013-08-26 02:39:28 <doublec> k9quaint: here's a github import of it https://github.com/laanwj/Purecoin
42 2013-08-26 02:39:42 <doublec> gmaxwell: I discussed it here a while back and got "probably shouldn't use getwork" as a response
43 2013-08-26 02:40:02 <doublec> gmaxwell: I've been backporting the issues I know of to my 0.8.1
44 2013-08-26 02:40:28 <gmaxwell> well, thats true too. And I admit, now I'd rather remove it then investigate the issue. Though its a little surprising the same issue doesn't exist for gbt.
45 2013-08-26 02:40:46 <doublec> I don't think gbt gets the workout that getwork does
46 2013-08-26 02:40:54 <gmaxwell> fair point.
47 2013-08-26 02:41:03 <gmaxwell> doublec: for all I know something that was a fix is the cause of that deadlock. :(
48 2013-08-26 02:41:05 <doublec> my getwork server is a dumb proxy that just forwards direct to getwork on bitcoind after some bsaic cheks
49 2013-08-26 02:41:18 <gmaxwell> oh wow.
50 2013-08-26 02:41:19 <doublec> and does the accounting for the pool of course
51 2013-08-26 02:41:25 <doublec> I wrote it a long time ago :)
52 2013-08-26 02:41:39 <gmaxwell> I'm surprised you don't get dos attacked to death. Hurray for having a low profile.
53 2013-08-26 02:42:14 <doublec> it handled 2 thash/s with that approacah so it wasn't too bad
54 2013-08-26 02:43:11 <gmaxwell> I'm impressed, IIRC solo mining I had to have a stack of patches on bitcoind to get getwork up to handling just 40GH/s though that was a long time ago.
55 2013-08-26 02:43:54 <doublec> my proxy, written in ATS, does a bunch of queuing, etc to be nice to bitcoind
56 2013-08-26 02:44:12 <doublec> it's definitly not the way to go now though
57 2013-08-26 02:45:17 <doublec> I'll clarify in that github issue that I'm not opposed to it being removed
58 2013-08-26 02:49:08 <gmaxwell> so wrt backporting, you can be handled here easily enough??? actually I suspect all of the 0.8.4 patches except the leveldb one would just apply mostly cleanly on your code. I can walk through whichever ones don't if you try.
59 2013-08-26 02:49:28 <doublec> Yep, gavin suggested that so I'll try it.
60 2013-08-26 02:49:43 <doublec> I'll try and do a test case for the getwork hang and see if I can reproduce it on gbt.
61 2013-08-26 02:50:00 <gmaxwell> But a problem with staying back is that sometimes things get fixed as a side effect of hardening things generally and we may not be aware of all issues we've fixed. So I still would generally recommend isolating any backport nodes from the public network.
62 2013-08-26 02:50:30 <doublec> I agree - I want to stay on a supported (ie. one that gets fixes) branch when possible.
63 2013-08-26 02:51:25 <gmaxwell> (and in generally I would strongly recommend isolating mining nodes from the public network, connecting only outbound to your own trusted nodes and other nodes you think are unlikely to dos attack you.)
64 2013-08-26 02:53:35 <doublec> I was doing that a while back. I had my mining node behind another node, just connected to that.
65 2013-08-26 02:53:49 <doublec> Unfortunately I had issues where the mining node wouldn't send blocks on to the connected node.
66 2013-08-26 02:54:03 <doublec> about 1 in 50 times. And this would result in an orphan.
67 2013-08-26 02:54:23 <doublec> I couldn't narrow down why the error was happening
68 2013-08-26 02:54:27 <gmaxwell> erk.
69 2013-08-26 02:54:30 <doublec> (whether it was my code or bitcoins)
70 2013-08-26 02:54:48 <doublec> at that time I was paying orphans so I had to change back until I investigated further
71 2013-08-26 02:55:57 <gmaxwell> My own stuff, and what I've recommended to other people is to have run one or more public nodes and have your mining node -connect your public nodes, as well as several other stable well known nodes (e.g. ones run by pools, jgarzik's, etc).. should give a reasonable robustness to failure...
72 2013-08-26 02:56:42 <doublec> right, that's what I had. Now I have a non-listening mining node with addnodes to a bunch of others.
73 2013-08-26 02:56:46 <JyZyXEL> shouldn't "poolowning" be discouraged because it adds centralization?
74 2013-08-26 02:57:03 <doublec> my stratum server also forwards to block to multiple bitcoinds that I run in different locations too - just to be paranoid.
75 2013-08-26 02:59:11 <doublec> JyZyXEL: poolowning is definitely problematic for some reasons, but advantageous for others (for example the recovery from the blockchain fork a while back)
76 2013-08-26 02:59:33 <gmaxwell> JyZyXEL: I can't fathom what you're thinking there. Yes, pools are risky points of failure as they exist today (though centeralization has some benefits), they don't have to be quite so risky.. but that has nothing to do with them having operators or not.
77 2013-08-26 03:01:09 <gmaxwell> doublec: Without disagreeing generally, I'm highly skeptical of that specific example. Had 0.8 nodes been an actual majority in the network then the fork would have mostly just taken care of itself... arguably part of the problem there was that most of the hashpower was consolidated in a few hands, and they were running something differnet from the network at large (only something like 20% of visiable nodes had upgraded)
78 2013-08-26 03:01:46 <gmaxwell> (but >>50% of the hashpower had upgraded by virtue of just having three or four parties upgrade. :( )
79 2013-08-26 03:01:49 <doublec> gmaxwell: true
80 2013-08-26 03:02:17 <gmaxwell> doublec: have you seen the coinbase pooling proposal that I'm fond of?
81 2013-08-26 03:02:33 <doublec> for me running a pool was an interesting programming problem to test scalability of the technologies I use. I've gone through about three different programming language rewrites.
82 2013-08-26 03:02:41 <doublec> gmaxwell: no, I haven't seen that
83 2013-08-26 03:03:07 <doublec> from Mozart/Oz -> Ur/Web -> ATS
84 2013-08-26 03:03:07 <gmaxwell> Maybe petertodd or luke had written it up better someplace, as its something we came up with during the conference; but I repeated it here: https://bitcointalk.org/index.php?topic=279017.msg3008168#msg3008168
85 2013-08-26 03:04:26 <doublec> gmaxwell: that is nice
86 2013-08-26 03:04:29 <gmaxwell> basically I suggest we should have miner software that supports doing a GBT against a local bitcoind, and then merging it with a coinbase from a pool. Then the miner submits shares to the pool and the pool pays based on that. (plus perhaps some sanity checking of the shares). This pools the coinbase, but not the consensus decision. Obviously not a complete replacement for classical mining, but it does decenteralize it more.
87 2013-08-26 03:05:18 <gmaxwell> it'll be a little easier to move forward with once we get the resources needed to run bitcoind trimmed down a bit more.
88 2013-08-26 03:05:22 <doublec> there will always be miners who don't want to run a bitcoind but for those that do that's a good options.
89 2013-08-26 03:05:34 <gmaxwell> Indeed.
90 2013-08-26 03:06:05 <gmaxwell> Another point there is that, potentially miners could pull their GBT from some other bitcoin that isn't the party that pools their payments. No need to connect the two events.
91 2013-08-26 03:06:29 <doublec> right. Pools could provide the GBT and the coinbase but users can pick either from different pools.
92 2013-08-26 03:07:07 <k9quaint> I thought that whole fork issue with 0.8 turned out to be a good thing because it provided an example of the process for resolving such a disagreement in the clients
93 2013-08-26 03:08:34 <gmaxwell> k9quaint: I dunno about that. In theory, if mining was really diverse the "least common denominator" chain would naturally win, as the one that most of the hashpower would tolerate. Here we had to manually achieve that by getting a couple big miners to move manually.
94 2013-08-26 03:10:04 <k9quaint> it gives you a concrete example of conflict resolution, you can point at it and say "we can just do that again" or say "god, no, we would have to do that again!"
95 2013-08-26 03:10:18 <k9quaint> its nice to have an example of what might happen
96 2013-08-26 03:10:53 <k9quaint> and there was no harm done, which is a risk when stuff like that happens
97 2013-08-26 03:10:59 <gmaxwell> k. well you could also look at the value overflow fork if you want that.
98 2013-08-26 03:12:16 <k9quaint> also, my beer bottle is empty, I now go to resolve this conflict
99 2013-08-26 03:27:07 <Krellan> I think it's just a huge stroke of luck that the March 2013 bug/fork took place before the April 2013 public breakthrough of Bitcoin into the mainstream media.
100 2013-08-26 03:27:13 <Krellan> Imagine if those two dates had been reversed...!
101 2013-08-26 03:27:51 <gmaxwell> Krellan: uhh. Bitcoin was heavily covered by the mainstream media in 2011.
102 2013-08-26 03:29:44 <gmaxwell> I admit, I didn't realize that there was so much more in april: http://www.google.com/trends/explore?q=bitcoin#q=bitcoin&cmpt=q
103 2013-08-26 03:32:37 <Krellan> True, it was, but nothing like the April 2013 spike. Embarrasingly I didn't get into Bitcoin when first hearing about it back in 2011, took me until 2013 to wake up.
104 2013-08-26 03:33:04 <k9quaint> wow, that trend graph is compelling
105 2013-08-26 04:12:00 <Diablo-D3> so
106 2013-08-26 04:12:02 <Diablo-D3> I tried emacs
107 2013-08-26 04:12:06 <Diablo-D3> not for me =/
108 2013-08-26 04:12:33 <Diablo-D3> btw, when did bitcoin hit >$200? in april?
109 2013-08-26 04:20:31 <sipa> gmaxwell: from what I hear, there have been occasional reports of deadlocking RPC under high load, ever since the thread refactor... getwork is probable the easiest way to trigger it
110 2013-08-26 04:33:35 <Krellan> gmaxwell: There, I found some time today to work on my ping patch a little more. Updated the commit in the pull req.
111 2013-08-26 04:36:44 <Diablo-D3> sipa: honestly, this is why I hate threads
112 2013-08-26 04:36:49 <Diablo-D3> sipa: they're just too problematic to ever use
113 2013-08-26 04:46:33 <gmaxwell> doublec: does your getwork load that deadlocks bitcoin result in concurrent access to the RPC?
114 2013-08-26 04:49:08 <doublec> gmaxwell: yes
115 2013-08-26 04:51:24 <sipa> maybe http keeping connections open plays a role
116 2013-08-26 04:52:42 <gmaxwell> I've seen a number of reports of making a whole bunch of connections then seeing some stalling, but I don't recall hearing about outright deadlocks?
117 2013-08-26 04:56:12 <doublec> sipa: If I use a client that uses keep-alive other clients would hang when all the available connections to bitcoind were busy
118 2013-08-26 04:56:32 <doublec> sipa: but even with keep alive disabled I'd get the occasional deadlock
119 2013-08-26 04:56:43 <sipa> hmm
120 2013-08-26 04:57:11 <doublec> so if I used a libcurl based client with keep-alive enabled, using one connection only but reusing it, other clients couldn't use bitcoind rpc
121 2013-08-26 04:58:06 <doublec> this was with 0.8.2 - I since moved away from keep-alive based connections to avoid that but didn't retry on 0.8.3+
122 2013-08-26 04:58:52 <doublec> so I pass CURLOPT_FORBID_REUSE, when using libcurl now
123 2013-08-26 04:59:41 <gmaxwell> that sounds like an easily fixed bug..
124 2013-08-26 04:59:48 <gmaxwell> or at least easily reproduced!
125 2013-08-26 05:01:58 <doublec> let me see if I can do a quick test case with libcurl
126 2013-08-26 05:19:39 <doublec> ok, got it
127 2013-08-26 05:20:20 <doublec> gmaxwell: http://cd.pn/test.c
128 2013-08-26 05:20:40 <doublec> run that with: test http://127.0.0.1;8332/ user:password
129 2013-08-26 05:20:45 <doublec> I run four instances
130 2013-08-26 05:20:53 <doublec> then do a 'bitcoind getinfo'
131 2013-08-26 05:21:09 <doublec> the latter hangs
132 2013-08-26 05:21:43 <doublec> I guess there's a limit to 4 concurrent connections
133 2013-08-26 05:22:20 <doublec> ACTION tries to duplicate deadlock without keep-alive
134 2013-08-26 05:24:16 <gavinandresen> doublec: '4' is the -rpcthreads default.
135 2013-08-26 05:25:34 <doublec> I wonder if it's worth keeping one thread non keep-alive so there's always a connection available
136 2013-08-26 05:27:05 <doublec> if I use CURLOPT_FORBID_REUSE and run remove the sleep call then all four clients run for about 30 seconds
137 2013-08-26 05:27:11 <sipa> didn't you say that even without keep-alive, you'd deadlock?
138 2013-08-26 05:27:17 <doublec> then bitcoind stops responding to rpc requests
139 2013-08-26 05:27:33 <doublec> sipa: yes. I'm trying to reproduce that.
140 2013-08-26 05:27:41 <doublec> but it might be on getwork submission only.
141 2013-08-26 05:28:01 <sipa> it's been untested for a really long time, so not sure it even compiles anymore, but can you build bitcoin with deadlock detection?
142 2013-08-26 05:28:12 <doublec> sipa: what's the option for that?
143 2013-08-26 05:28:24 <sipa> -DDEBUG_LOCKORDER
144 2013-08-26 05:29:11 <doublec> I don't know if I'll be able to reproduce the deadlock. It'd happen on the pool intermittently - sometimes taking hours.
145 2013-08-26 05:29:15 <doublec> I'll give it a go though.
146 2013-08-26 05:32:13 <doublec> another change I noticed when switching to 0.8.x was the urls for the RPC had to have a trailing slash. Prior to that it didn't matter.
147 2013-08-26 05:32:22 <doublec> I forget what 'x' brought that in
148 2013-08-26 05:37:53 <doublec> ok, I'll run a test for a few hours and see if it deadlocks
149 2013-08-26 05:38:48 <sipa> i don't expect much of it; it seems interaction with the asio/boostthread stuff, which doesn't use bitcoin'd sync mechanism
150 2013-08-26 05:40:12 <phantomcircuit> gavinandresen, it's more than that though, something about the way rpc calls work causes a deadlock if you make rpcthreads - 1 concurrent requests
151 2013-08-26 05:40:25 <phantomcircuit> the issue isn't with locks explicitly acquired in bitcoin code
152 2013-08-26 05:40:36 <phantomcircuit> it's something about the way boost asio is happening
153 2013-08-26 05:44:33 <doublec> isn't that because each thread is kept busy with the keep-alive connection and there are no more threads to service other requests?
154 2013-08-26 05:45:49 <gmaxwell> running boost asio inside gdb made me want to commit suicide.
155 2013-08-26 05:46:14 <gmaxwell> Rubegoldburg would be proud of the execution flow there.
156 2013-08-26 05:53:26 <phantomcircuit> doublec, that doesn't explain why it's rpcthreads -1
157 2013-08-26 11:08:58 <mrkent> What's the standard/prefered method of listening for when (if ever) customer has paid to a given address?
158 2013-08-26 11:24:48 <Luke-Jr> mrkent: scan new blocks every block, with 6 block delay
159 2013-08-26 11:24:57 <Luke-Jr> so when block 7 is found, you scan block 1
160 2013-08-26 11:36:56 <helo> when block 7 is orphaned, and the transaction moves to block 6, you put on your tacticool gear and take some rage out on the local squirrel population
161 2013-08-26 11:52:41 <Luke-Jr> helo: that never happens
162 2013-08-26 11:53:02 <Luke-Jr> helo: block 7 being "orphaned" means there is a new block 7 and 8 ;)
163 2013-08-26 12:03:33 <helo> err yeah, i meant "when 1 is orphaned, and the transaction moves to block 2"
164 2013-08-26 12:04:04 <helo> but that "never" happens too ofc :)
165 2013-08-26 12:14:28 <jgarzik> mornin'
166 2013-08-26 12:55:46 <runeks> mornin' Jeff
167 2013-08-26 12:56:21 <gmaxwell> dunno if people noticed, but seems someone finally caught on to the rest of the android rng issue: http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/
168 2013-08-26 13:05:10 <lianj> gmaxwell: yea, that was a nice post
169 2013-08-26 13:18:01 <jgarzik> gmaxwell, makes sense, but is a good reminder
170 2013-08-26 13:18:14 <jgarzik> gmaxwell, particularly since I'm building a forking pool server ;p
171 2013-08-26 13:18:27 <jgarzik> (not that pool servers need much randomness, I think)
172 2013-08-26 13:38:38 <jgarzik> gmaxwell, had a random idea while reading CoinJoin
173 2013-08-26 13:38:55 <jgarzik> gmaxwell, "bitcoin swap meet"
174 2013-08-26 13:39:44 <jgarzik> gmaxwell, until automated p2p mixing and other fun exists, run a weekly forum thread where people contribute to building transactions with fixed-amount outputs, e.g. 10 people collaborate on a transaction that outputs 10x 1.0 BTC outputs
175 2013-08-26 13:41:26 <jgarzik> gmaxwell, <vendor hat: on> BitPay definitely thinks fungibility is important, as is party-party privacy. You don't want your business competitors snooping transactions you wish to keep private.
176 2013-08-26 13:41:52 <gmaxwell> Sounds great! I'm not sure how much interest there is in manual participation as it is a bit of a PITA. I'd kind of hoped for the taint-rich thread to do some of that before, but perhaps another effort would be good.
177 2013-08-26 13:42:00 <jgarzik> especially in today's world of <cough ahem> well known countries engaging in industrial espionage
178 2013-08-26 13:43:01 <jgarzik> gmaxwell, would it be possible to create a simple set of human, English instructions for people to collaborate together on transactions? I don't know how well our system currently handles cat'ing together and signing things
179 2013-08-26 13:43:31 <jgarzik> instructions are free speech, and enable anyone to run a swap meet
180 2013-08-26 13:43:44 <jgarzik> you could even have bitcoin swap meets in these Satoshi Squares, where people meet to trade
181 2013-08-26 13:43:52 <jgarzik> just need Push Here Dummy instructions
182 2013-08-26 13:44:28 <gmaxwell> We do not currently have a tool for merging independantly signed transactions. Well, petertodd may actually. But otherwise we have the required tools, if not the desired userfriendlyness.
183 2013-08-26 13:44:31 <jgarzik> could become another geek activity like pgp keysigning parties
184 2013-08-26 13:44:43 <jgarzik> bitcoin mixing
185 2013-08-26 13:45:02 <jgarzik> or, heh, have a "bitcoin mixer" -- come drink beer and mix bitcoins
186 2013-08-26 13:46:11 <jgarzik> gmaxwell, I hope that txtool will be able to do this, soon. All this wonderful JS toolitude is blocked on my finishing P2SH support, which justmoon's bitcoinjs-server never had. I really should be working on that, not a pool server ;p
187 2013-08-26 13:47:02 <jgarzik> txtool, with bitcoind's help, already does multi-party transaction signing, where multiple parties pass around hex-encoded binary transactions, partially signed, for signing.
188 2013-08-26 13:47:16 <jgarzik> soon, it will not be bound to bitcoind's wallet
189 2013-08-26 13:47:20 <gmaxwell> I was pretty surprised by the couple "there is nothing that needs improving" responses in the thread.
190 2013-08-26 13:47:23 <gmaxwell> speaking of that
191 2013-08-26 13:48:13 <jgarzik> gmaxwell, few seem to be jumping on P2SH :/
192 2013-08-26 13:48:32 <jgarzik> gmaxwell, even TD is unenthused and not motivated to add it to bitcoinj
193 2013-08-26 13:49:39 <Belxjander> P2SH?
194 2013-08-26 13:49:46 <gmaxwell> It's also quite old at this point, and there are still many things that won't send to it, it makes me wonder about how successful we can be at advancing the art...
195 2013-08-26 13:50:53 <jgarzik> gmaxwell, You know how it works? :) Nobody updates anhything until a big site starts testing/using the feature. Then it breaks everybody, and everybody upgrades in 24 hours.
196 2013-08-26 13:50:53 <petertodd> gmaxwell: I don't yet, but I will soon
197 2013-08-26 13:51:10 <jgarzik> *anything
198 2013-08-26 13:51:49 <gmaxwell> I wonder if when the reference software gets a BIP32 determinstic wallet mode if it shouldn't just always emit p2sh addresses.
199 2013-08-26 13:51:49 <jgarzik> hopefully BitPay wanting to use P2SH will push Bitcoin Wallet (bitcoinj-based) to support them
200 2013-08-26 13:52:08 <jgarzik> (conversely, we cannot put them into general use without that!)
201 2013-08-26 13:52:09 <petertodd> gmaxwell: +1
202 2013-08-26 13:52:14 <jgarzik> :(
203 2013-08-26 13:53:04 <jgarzik> Belxjander, pay to script hash. pay to hash, and provide script + signature as input to the later spend.
204 2013-08-26 13:53:05 <Belxjander> speaking of "BitCoin Wallet"s...
205 2013-08-26 13:54:06 <Belxjander> jgarzik: so this allows for external encryption options as well for the keys?
206 2013-08-26 13:54:09 <Belxjander> and to sign them using scripting?
207 2013-08-26 13:54:16 <Belxjander> or am I mis-understanding something?
208 2013-08-26 13:54:55 <gmaxwell> Belxjander: it moves control of the redemption rules to the reciever rather than the sender. It doesn't have anything to do with encryption.
209 2013-08-26 13:55:17 <Belxjander> gmaxwell: that kinda makes sense
210 2013-08-26 13:55:25 <gmaxwell> This makes things like the reciever of the funds able to choose to use multisignature accounts.
211 2013-08-26 13:55:32 <Belxjander> since the person who received the "money" is the one who will eventually "redeem" it
212 2013-08-26 13:55:49 <Belxjander> by using it for a purchase
213 2013-08-26 13:55:57 <jgarzik> Belxjander, Normal transactions provide redemption rules. Redemption TX provides a signature. P2SH transactions provide hash(redemption rules). P2SH redemption TX provides signature + redemption rules.
214 2013-08-26 14:02:00 <sturles> Strange.. I use walletnotify for notification of new transactions to my wallet. I just got a transaction where I got a notify at 0 confirmations (first spotted) and then at 2 confirmations! No notify for first confirmation. How can this happen?
215 2013-08-26 14:02:27 <Luke-Jr> sturles: reorg
216 2013-08-26 14:04:12 <gmaxwell> "Quantum tunneling"
217 2013-08-26 14:05:43 <sturles> Ah, right. So it wasn't confirmed on my side of the chain. Then the other side grew one block longer, my client fetched both blocks and notify runs after all known blocks are downloaded?
218 2013-08-26 14:08:08 <jgarzik> Comments of the day: 1. I hate boost. 2. I'm too old for this shit.
219 2013-08-26 14:08:58 <jgarzik> This pool server uses pipes, i.e. not sockets, so I need to either (a) get boost to listen to non-socket file descriptor using boost.asio's io_service, or (b) write an entire network engine, like I've done several times before.
220 2013-08-26 14:09:24 <sturles> I think you should invent quantum multicast for the task.
221 2013-08-26 14:09:25 <jgarzik> boost.asio is such crap. things are much harder, require far more LOC than they should.
222 2013-08-26 14:10:14 <gmaxwell> But in exchange for all those lines of code, you get binaries which are bloated and take a long time to execute!
223 2013-08-26 14:10:22 <jgarzik> it's wonderfully async and data type neutral thanks to templates and very powerful? and yet even the most simple TCP echo server requires 100-200 lines
224 2013-08-26 14:10:40 <jgarzik> and requires nutty buffer schemes
225 2013-08-26 14:10:52 <Luke-Jr> jgarzik: could port Eloipool's networkserver
226 2013-08-26 14:11:00 <gmaxwell> "and demands 12 mbytes of L2 cache for good performance."
227 2013-08-26 14:11:48 <jgarzik> I'm leaning towards writing my own network engine. Already did so several times in C, and in C++ it does make a few things easier. but bleh.
228 2013-08-26 14:18:42 <jgarzik> why must the world of software sucketh so?
229 2013-08-26 14:19:09 <gmaxwell> jgarzik: to achieve full employment for programmers.
230 2013-08-26 14:19:20 <Luke-Jr> jgarzik: because most programmers suck?
231 2013-08-26 14:20:11 <jgarzik> I'll rant tomorrow about runaway framework-itis, and iterating within one's sandbox to a myopically ridiculous degree
232 2013-08-26 14:23:13 <petertodd> jgarzik: if it makes you feel any better in electronics design the software sucks too
233 2013-08-26 14:27:58 <k9quaint> jgarzik: what is the difference between software and hardware?
234 2013-08-26 14:28:38 <k9quaint> If you run hardware enough times, it eventually breaks. If you run software enough times, it eventually works
235 2013-08-26 14:29:03 <maaku> k9quaint: software is supposed to abstract hardware, making it simpler not more complex
236 2013-08-26 14:29:12 <gmaxwell> k9quaint: or you lose your mind and decide that all behavior qualifies as "works"
237 2013-08-26 14:29:21 <gmaxwell> maaku: HAHAHAHAH
238 2013-08-26 14:30:18 <k9quaint> there are no bugs, only unscheduled features
239 2013-08-26 14:31:17 <gmaxwell> We have much more powerful development and debugging tools and software is cheaper and easier to deploy and upgrade, as a result we produce software which has complexity far beyond anything else mankind produces. "Oh that? yea. That thing has 40 million active components."
240 2013-08-26 14:31:51 <k9quaint> more complex even than women?
241 2013-08-26 14:32:31 <gmaxwell> Well, industrial goods at least. I wasn't counting ourselves.
242 2013-08-26 14:32:44 <k9quaint> men aren't complex :P
243 2013-08-26 14:33:38 <k9quaint> and fix the custom hardware forum, don't make me file a bug
244 2013-08-26 14:33:51 <gmaxwell> computer system which can be mass produced by unskilled labor."
245 2013-08-26 14:33:51 <gmaxwell> "Man is the lowest cost, 150 pound, nonlinear, all-purpose
246 2013-08-26 14:34:12 <k9quaint> lowest cost? babies are freaking expensive :(
247 2013-08-26 14:34:45 <gmaxwell> well, it was true in the 1950s or so when that quote comes from. :P
248 2013-08-26 14:35:25 <k9quaint> touche
249 2013-08-26 14:35:37 <k9quaint> tis still a good quote
250 2013-08-26 14:59:27 <petertodd> k9quaint: heh, although something a lot of people don't appreciate is we can build hardware that has no wear mechanisms. For instance when a piston in a modern car engine does a cycle, there really isn't any wear: the tolerances are so good now that if there were any atoms getting dislodged or moved every cycle, pistons would wear out much faster than they actually do.
251 2013-08-26 15:00:09 <k9quaint> particulate matter getting into the engine is what ruins them AFAIK
252 2013-08-26 15:00:11 <petertodd> k9quaint: There are second order effects of course with quantum tunneling weirdness, but at the more basic level under controlled conditions we really can make mechanical things that last forever to a first approximation.
253 2013-08-26 15:00:18 <petertodd> k9quaint: Exactly!
254 2013-08-26 15:00:32 <petertodd> k9quaint: Hence why maintenance, oil changes, filters etc. is so important.
255 2013-08-26 15:01:50 <petertodd> k9quaint: Another simple example is quartz oscillators: they really do have a little bit of quartz crystal, that's actually moving, yet the lifespan of that mechanical process is infinite to a first approximation.
256 2013-08-26 15:02:52 <k9quaint> sure, but corrosion can take place etc
257 2013-08-26 15:03:18 <k9quaint> we actually have very little data on how modern materials function past 100 years
258 2013-08-26 15:03:22 <petertodd> k9quaint: Well, again, we have materials these days where to a first approximation corrosion doesn't take place.
259 2013-08-26 15:03:55 <k9quaint> can you make semi-conductors out of them?
260 2013-08-26 15:04:09 <petertodd> k9quaint: That's actually not really true because we can analyze things to see if they have changed at all at the atomic level - if they don't change at all after 10 years, they aren't 0*10 still == 0
261 2013-08-26 15:04:37 <petertodd> k9quaint: Semi-conductors are another example where you can have materials that don't wear out at all... although usually we push them hard enough that they do.
262 2013-08-26 15:05:14 <k9quaint> the question becomes, how do you keep the oxidizers out
263 2013-08-26 15:05:47 <k9quaint> ACTION gets his dioxygen difluoride
264 2013-08-26 15:06:00 <sturles> And temperature and radiation. Not much will survive for long in space.
265 2013-08-26 15:06:02 <petertodd> k9quaint: Seal things with materials that are already oxidized for instance.
266 2013-08-26 15:06:12 <petertodd> sturles: Counter-example: Voyager probe
267 2013-08-26 15:06:34 <sturles> Voyager was very analog and deigned specially for space.
268 2013-08-26 15:06:43 <sturles> Not much consumer electronics there.
269 2013-08-26 15:06:53 <petertodd> sturles: Anyway the effects of radiation are discrete - if the radiation can't overcome the minimum energy required to damage the material, nothing happens.
270 2013-08-26 15:06:58 <k9quaint> well, out in space you don't worry so much about oxidizers and more about cosmic radiation
271 2013-08-26 15:07:42 <theorbtwo> In space, no-one can hear your free electrons scream?
272 2013-08-26 15:08:01 <sturles> A well placed nautron will make the atom into something it was not intended to be.
273 2013-08-26 15:08:03 <petertodd> sturles: It's quite possible to design with consumer electronics and wind up with space-rated stuff, you just need to pick your electronics more carefully. Oddly too consumer stuff tends to be more reliable than "mil-spec" and "space-rated" parts because the inspection process does more damage than it finds. :(
274 2013-08-26 15:08:43 <petertodd> sturles: Sure, which is why I keep on saying "to a first approximation" - quantum tunneling eventually makes everything melt, but the timescales are crazy.
275 2013-08-26 15:10:18 <k9quaint> petertodd: if only you made my washing machine ;)
276 2013-08-26 15:10:39 <petertodd> k9quaint: how much money ya got? :P
277 2013-08-26 15:11:18 <k9quaint> all the money on earth, geologically speaking
278 2013-08-26 15:12:16 <petertodd> well... in that case I can make you a pretty good washing machine. But it'll only be able to wash one bikini at a time and will weigh 10 tonnes. It will however last forever.
279 2013-08-26 15:12:57 <sturles> Will it work in space? :-)
280 2013-08-26 15:12:59 <petertodd> *forever defined by my own lifespan
281 2013-08-26 15:13:25 <petertodd> sturles: Not guaranteed to actually clean clothes if the boiling point of water is below ambient.
282 2013-08-26 15:13:59 <k9quaint> do I get to pick the person who will wear the bikini?
283 2013-08-26 15:14:28 <theorbtwo> I actually was wondering the other day, vaugely relatedly -- they say that exposing clothes to vaccuum does a great job cleaning them, which is how they do it on the ISS. Would it be useful/reasonable to do that on Earth, or does it need "zero g", too?
284 2013-08-26 15:14:55 <petertodd> theorbtwo: they expose clothes to vaccuum on the ISS? link?
285 2013-08-26 15:15:13 <petertodd> At best I'd expect that to just make them smell less by letting volitiles evaporate away.
286 2013-08-26 15:18:23 <gmaxwell> petertodd: maybe the volitiles boiling off lubricate the dirt enough to release it too.
287 2013-08-26 15:19:22 <theorbtwo> Or, perhaps, getting rid of the volitiles is the best they can do.
288 2013-08-26 15:19:36 <theorbtwo> A little bit of googling, however, suggests that I'm just crazy.
289 2013-08-26 15:19:49 <gmaxwell> maybe you dreamed it. I do that sometimes.
290 2013-08-26 15:20:02 <petertodd> http://www.popsci.com/technology/article/2011-11/nasa-commissions-laundry-machine-international-space-station
291 2013-08-26 15:20:25 <petertodd> also, as a Canadian I have to link to this: http://www.youtube.com/watch?v=4Wcl6ZXrbj4
292 2013-08-26 15:20:31 <theorbtwo> They just keep wearing them for several days at a stretch -- and then literally throw it away, mostly, on a Progress rocket that will burn up on reentry.
293 2013-08-26 15:21:50 <petertodd> Sounds about right - I mean I've worn clothing for way longer than I should admit to on hikes.
294 2013-08-26 15:40:23 <sytse> 'grime-encrusted nauts will wear underwear for 3-4 days and other items of clothing for months, before disposing of the dirty laundry by hurling it into the atmosphere to burn up in old Progress cargo capsules, attempting to wash it in a plastic bag or even - yuck - using it to grow plants in.'
295 2013-08-26 15:40:28 <sytse> hmm
296 2013-08-26 15:43:57 <gmaxwell> CoinJoin bounty address is up: https://bitcointalk.org/index.php?topic=279249.msg2983911#msg2983911
297 2013-08-26 15:45:55 <Luke-Jr> ACTION notes BC signature is useless for sipa's :P
298 2013-08-26 15:46:21 <Luke-Jr> and could give people the wrong impression that it can be validly used like that
299 2013-08-26 15:48:49 <gmaxwell> Luke-Jr: yea, sipa will give a pgp signature when he can.
300 2013-08-26 15:51:07 <gmaxwell> Luke-Jr: any idea why BC.i thinks your transaction is "strange" ?
301 2013-08-26 15:51:21 <Luke-Jr> gmaxwell: ?
302 2013-08-26 15:52:21 <gmaxwell> weird, its not saying it on reload.
303 2013-08-26 15:52:55 <gmaxwell> the transaction to the coinjoin bounty that I could tell came from you because of the spending bfgminer donations
304 2013-08-26 15:54:02 <Luke-Jr> gmaxwell: yes, I intentionally picked those coins :p
305 2013-08-26 15:54:22 <BTCOxygen> lol
306 2013-08-26 15:54:40 <Cusipzzz> i also picked 'grimey', mixed coins to send :)
307 2013-08-26 15:55:23 <Ry4an> Does anyone track really old coin-moves? I've got something that hasn't moved since the $0.24 days that I'm going to consolidate and if it causes a ripple I wanted to watch. :)
308 2013-08-26 15:56:01 <gmaxwell> Ry4an: someone might notice someone moving a bunch of old unmoved blocks... otherwise I doubt it.
309 2013-08-26 15:56:35 <Cusipzzz> Ry4an: i monitor unspent block rewards from < 70k
310 2013-08-26 15:57:51 <petertodd> gmaxwell: gah, P2SH multisig with non-sorted pubkeys! other than that though, cool!
311 2013-08-26 15:58:05 <gmaxwell> petertodd: huh? i sorted them.
312 2013-08-26 15:58:22 <gmaxwell> do you not like my lexical sorting?
313 2013-08-26 15:58:29 <Ry4an> cool, I't about 0.5 BTC worth, so it's nothing that would show up on blockreward scale. Just finally firing up an old archive drive.
314 2013-08-26 15:59:31 <petertodd> gmaxwell: lol, yeah I guess it's sorted, lexically rather than numerically...
315 2013-08-26 16:09:50 <sipa> Luke-Jr: indeed, no access to my GPG key now
316 2013-08-26 16:10:17 <sipa> Luke-Jr: i realized myself that the signature is useless, apart from proving that *someone* does have the private key for that pubkey
317 2013-08-26 16:10:43 <gmaxwell> sipa: I did a signmessage myself with my own key before building it... but then figured the best way to test was with a transaction.
318 2013-08-26 16:11:09 <gmaxwell> I didn't put up the address until I successfully made a redeem txn (with Theymos).
319 2013-08-26 16:21:01 <arioBarzan> Currently bitcoin chooses the longer Block Chain. Could we have an optional feature that force miners (specially pools) to notify new blocks only with a kind of pre-specified unique identifier for that miner so that in future majority of users have the option to willfully block one specific miner ?
320 2013-08-26 16:21:51 <lianj> what sense does that make?
321 2013-08-26 16:23:04 <arioBarzan> It would help in cases like a powerful attacker tries to gain total control of network or in future tries to force arbitrary rules (for e.g. tx fee=0.5BTC)
322 2013-08-26 16:23:27 <sturles> I just thought of a new scaling problem. In 2100, there ought to be colonies on Mars. One of the first things they will do is obviously to mine. Bitcoins. The maximum distance between Earth and Mars is 21 light minutes. There is bound to be a lot of chain forking then, and the forks can become quite long before a consensus is reached.
323 2013-08-26 16:24:08 <Ry4an> sturles: new to you maybe. People have written speculative articles about interstellar block chain behavior. You can probably track them down.
324 2013-08-26 16:24:16 <gmaxwell> Your message advocates a
325 2013-08-26 16:24:17 <gmaxwell> approach to fighting majority hashpower attack. Your idea will not work. Here is why it won't work.
326 2013-08-26 16:24:17 <gmaxwell> (x) technical ( ) legislative ( ) market-based (x) vigilante
327 2013-08-26 16:24:20 <gmaxwell> (One or more of the following may apply to your particular idea)
328 2013-08-26 16:24:22 <gmaxwell> (x) attackers can't be made to cooperate with your scheme.
329 2013-08-26 16:24:42 <Cusipzzz> +kb gmaxwell spam :)
330 2013-08-26 16:24:46 <Ry4an> gmaxwell: Ha! You have a form based on the spam .... yeah that.
331 2013-08-26 16:24:57 <sturles> Ry4an: Cool! Otherwise this would be an interesting problem for some altcoin to solve.
332 2013-08-26 16:25:44 <Ry4an> sturles: how come everyone goes "idea" -> "altcoin implementation"? The world needs more people who go "idea" -> "document / BIP"
333 2013-08-26 16:26:32 <sturles> Ry4an: I guess because it is easier to try out new concepts in an altcoin first.
334 2013-08-26 16:26:33 <arioBarzan> gmaxwell: if attacker with majority hashpower would not cooperate, then majority of nodes (obviously with less hashpower) will ignore node of attacker willfully
335 2013-08-26 16:27:00 <gmaxwell> ... arioBarzan How do you identify the attacker?
336 2013-08-26 16:27:35 <Cusipzzz> majority hashpower wins. it's not just a good idea, it's the law.
337 2013-08-26 16:28:40 <arioBarzan> gmaxwell: As I said by adding a new feature that forces all miners to first acquire a unique mining identity (maybe from majority of other nodes or something else) to be able to announce valid new blocks
338 2013-08-26 16:29:24 <gmaxwell> oh, so step one you centeralize the system. Why not dispense with mining entirely then and just allow unique id holders to each produce one block in sequence round robbin style?
339 2013-08-26 16:29:55 <Cusipzzz> maybe the bitcoin foundation<tm> could assign miner IDs<r>!
340 2013-08-26 16:30:40 <arioBarzan> I am more worried about the transaction fees rather than 51% attack. A consortium of pools could put arbitrary transaction fees that could essentially block users from spending their coins with a reasonable fee.
341 2013-08-26 16:31:00 <sipa> And how is that not a 51% attack?
342 2013-08-26 16:31:14 <sipa> If they're not colluding, they cannot prevent the 49% from allowing lower fees.
343 2013-08-26 16:31:27 <arioBarzan> in 51% attack I would be worried for double-spending.
344 2013-08-26 16:31:30 <sipa> If they are, it is an attack and they are exploiting their majority hashrate.
345 2013-08-26 16:31:42 <arioBarzan> but now my question is about the fees
346 2013-08-26 16:32:15 <Luke-Jr> Ry4an: not everyone
347 2013-08-26 16:32:30 <gmaxwell> arioBarzan: okay, sure, thats bothered me in the past too... less now. But regardless, a concern doesn't imply that there is a solution. Anything where you assign IDs could itself be a replacement for mining as a consensus system.
348 2013-08-26 16:32:53 <Ry4an> arioBarzan: if that's what the people who are actually processing transactions think that's what they want to be paid to processes transactions then the people who want to get transactions through need to either (1) pay it or (2) run their own processing systems that charge less. In the later case any barrier you put in place to make it harder to become a miner (need to get a unique id from the current cartel) makes things worse not better.
349 2013-08-26 16:33:02 <Luke-Jr> arioBarzan: that's by design (miners being able to set fees)
350 2013-08-26 16:34:05 <gmaxwell> so, I think bc.i calls all payments to p2sh addresses "strange" when they show up on the realtime view.
351 2013-08-26 16:34:26 <michagogo> gmaxwell: bc.i calls a *lot* of things "strange".
352 2013-08-26 16:34:37 <jgarzik> gah
353 2013-08-26 16:34:38 <michagogo> Pretty much anything but "pay to this address"
354 2013-08-26 16:34:40 <jgarzik> json_spirit sucks too
355 2013-08-26 16:34:49 <gmaxwell> jgarzik: you already knew this.
356 2013-08-26 16:35:02 <jgarzik> objects -- fundamentally key/value -- are internally represented as vector<Pair>
357 2013-08-26 16:35:07 <michagogo> Hmm, how often are addr packets sent?
358 2013-08-26 16:35:37 <jgarzik> one must perform an iteration, just to look up a value inside a json_spirit::Object
359 2013-08-26 16:36:01 <jgarzik> surely "value = obj[key]" would be a form worth supporting, but no.
360 2013-08-26 16:37:34 <sipa> jgarzik: depends what container the object uses
361 2013-08-26 16:37:41 <sipa> you can customize that, afaik
362 2013-08-26 16:37:49 <sipa> but if it's a list, sure
363 2013-08-26 16:38:07 <sipa> (not saying this is a good design choice, but it's at least an understandable result of it)
364 2013-08-26 16:38:52 <jgarzik> sipa, even with a list, value=obj[key] is an API worth supporting
365 2013-08-26 16:40:06 <sipa> jgarzik: that doesn't make sense
366 2013-08-26 16:40:19 <sipa> if you want value=obj[key[, then use a type that supports it
367 2013-08-26 16:40:35 <sipa> afaik the default is using vector, and json-spirit cannot change the definition of vector
368 2013-08-26 16:43:35 <jgarzik> sipa, a JSON Object is a fundamentally a key/value container. What doesn't make sense is json_spirit::Object not supporting a key/value lookup in the API.
369 2013-08-26 16:44:16 <sipa> jgarzik: json_spirit::Object is whatever you say it is
370 2013-08-26 16:44:19 <sipa> and by default it's a vector
371 2013-08-26 16:44:20 <jgarzik> one may change json_spirit's internal implementation to std::map, but that doesn't change the brokenness: one must still dive into the guts of json_spirit::Value's implementation to perform a lookup
372 2013-08-26 16:44:30 <sipa> there is no 'internal' implementation
373 2013-08-26 16:44:36 <sipa> you chooise the container yourself
374 2013-08-26 16:45:06 <sipa> (again, not saying this degree of flexibility is a good design, but it explains your observation)
375 2013-08-26 16:45:42 <jgarzik> sure it is, Pair_impl etc. that is the internal implementation.
376 2013-08-26 16:45:56 <sipa> you're talking about Value, not Object
377 2013-08-26 16:46:19 <sipa> the default implementation for Object is std::vector<Value>
378 2013-08-26 16:47:57 <jgarzik> one may change json_spirit's internal implementation from std::vector<Value> to std::map, but that doesn't change the brokenness
379 2013-08-26 16:48:14 <jgarzik> you still don't have an easy object[key]=value nor value=object[key].
380 2013-08-26 16:48:16 <sipa> well, it's a choice for extreme flexibility at the cost of features
381 2013-08-26 16:48:42 <jgarzik> Object is key/value, yet json_spirit does not provide a key/value API
382 2013-08-26 16:48:54 <sipa> and i think the reason is so you can immediately parse into your own container type
383 2013-08-26 16:48:55 <jgarzik> it's a pretty standard feature
384 2013-08-26 16:49:18 <sipa> instead of parsing into some standard library types, and then converting (what we're doing)
385 2013-08-26 16:50:21 <sipa> but perhaps they could provide a more feature-rich container type that does support that
386 2013-08-26 16:50:50 <sipa> hey, they do!
387 2013-08-26 16:51:17 <sipa> Config_map
388 2013-08-26 16:52:16 <sipa> ... with the downside that it doesn't preserver order of key-value pairs in objects
389 2013-08-26 16:53:20 <sipa> mConfig
390 2013-08-26 16:53:44 <sipa> so, use mValue, mObject and mArray
391 2013-08-26 16:53:46 <sipa> done!
392 2013-08-26 16:54:39 <jgarzik> ACTION goes to see if Debian enabled those...
393 2013-08-26 16:54:45 <sipa> 'enabled' ?
394 2013-08-26 16:55:16 <sipa> it's just template magic
395 2013-08-26 16:55:20 <arioBarzan> follow-up question regarding possible mandatory ID for miners. Could it be like miners would have to introduce a new block with a special coinbase message (which is currently any arbitrary data) which should hash to a digest smaller than a predefined number? It would make hard for a mining attacker to constantly introduce new mined blocks with different identities to prevent other nodes from block
396 2013-08-26 16:55:20 <arioBarzan> ing him
397 2013-08-26 16:55:43 <sipa> why do you want miners to have identities?
398 2013-08-26 16:56:01 <sipa> and how would your solution prevent them from creating as many identities as they want?
399 2013-08-26 16:56:21 <arioBarzan> because users have ability to block a hostile miner.
400 2013-08-26 16:56:45 <sipa> no they don't
401 2013-08-26 16:56:59 <arioBarzan> at least it make expensive to calculate new IDs
402 2013-08-26 16:57:34 <petertodd> arioBarzan: yeah, maybe some kind of proof-of-work function, like a sha256^2 hash
403 2013-08-26 16:57:41 <sipa> LOL
404 2013-08-26 17:00:08 <arioBarzan> Currently the technology used by miners is dominated by western countries and if you guys want to mandate any transaction fee, then rest of countries have to accept that.
405 2013-08-26 17:00:21 <Luke-Jr> arioBarzan: lolwut
406 2013-08-26 17:00:44 <petertodd> THE RENT IS TOO DAMN HIGH!
407 2013-08-26 17:00:46 <sipa> unless miners collude to block other miners, they cannot force any fee
408 2013-08-26 17:01:12 <gmaxwell> ^ a majority, in fact
409 2013-08-26 17:01:32 <sipa> and making it harder to start as a new miner will only worsen that situation
410 2013-08-26 17:01:40 <sipa> (which is what you're proposing)
411 2013-08-26 17:02:42 <gmaxwell> and then if you decide you want to get rid of one, how do you get all users to do that atomically (if you don't the chain forks...). You'd need a consensus mechenism.. I know, you could use a POW blockchain...
412 2013-08-26 17:03:07 <gmaxwell> Yo Dawg, we used a POW Blockchain to build consensus for participation in your POW blockchain.
413 2013-08-26 17:03:52 <arioBarzan> gmaxwell: I hoped with such an ID people kick that hostile miner to his personal fork of blockchain even if his chain is longer.
414 2013-08-26 17:04:05 <Luke-Jr> ???
415 2013-08-26 17:05:36 <michagogo> gmaxwell: Yo Dawg, I heard you liked POW Blockchains so I used a POW blockchain for consensus for your POW blockchain so you can use a POW blockchain to use a POW blockchain.
416 2013-08-26 17:05:44 <Luke-Jr> arioBarzan: so we should ID miners by requiring someone to validate their government issued photo id?
417 2013-08-26 17:06:50 <arioBarzan> Luke-Jr: no, they would need to choose a unique coinbase which its hash should have a pre-defined feature
418 2013-08-26 17:06:58 <Luke-Jr> ???
419 2013-08-26 17:07:03 <arioBarzan> A POW coinbase
420 2013-08-26 17:07:15 <Luke-Jr> hmm
421 2013-08-26 17:07:28 <arioBarzan> in contrast with current coinbase which is any arbitrary data
422 2013-08-26 17:08:05 <arioBarzan> for example BTCGuild now writes "This is mined by BTCGuild" in its coinbase tx
423 2013-08-26 17:08:05 <gmaxwell> arioBarzan: awesome. So now I start adding your token. Sweet.
424 2013-08-26 17:08:26 <Luke-Jr> gmaxwell: well, it could be a hash of a key and require a signature
425 2013-08-26 17:08:41 <gmaxwell> arioBarzan: so do I. (Or do I?)
426 2013-08-26 17:13:22 <Luke-Jr> arioBarzan: in any case, what you're proposing (ignoring specific miners) *is* a 51% attack
427 2013-08-26 17:15:14 <arioBarzan> Luke-Jr: I did not thought about 51% before, since I was specifically concerned about tx fees.
428 2013-08-26 17:15:54 <Luke-Jr> arioBarzan: but your "concern" is what Bitcoin was designed to do
429 2013-08-26 17:18:02 <arioBarzan> I think if such a rule is put in place, it would not be necessarily a 51% attack. Because it it would only make expensive for a miner to find a new POW-valid ID if his current ID is blocked by other nodes.
430 2013-08-26 17:18:29 <sipa> You would also make it harder for new miners to enter the mining market.
431 2013-08-26 17:19:30 <sipa> And since you're concerned about a politically-centralized cartel overtaking the mining business, it seems to me that you should make sure entering that market is as easy as possible.
432 2013-08-26 17:20:23 <arioBarzan> A reasonable level of difficulty would be rational. In recent two days at difficulty 1 I could mine 300 blocks (I forked my chain) on my laptop. So I should be able to also make a valid ID without so much difficulty
433 2013-08-26 17:21:00 <sipa> ... you suggest that creating a new ID is a million times easier than creating a block?
434 2013-08-26 17:21:04 <arioBarzan> however a hostile miner would need to repeat that POW effort over and over, and that would make it hard for him
435 2013-08-26 17:21:19 <gmaxwell> fortune cookie I just got "only tears can bring a dreamer back to earth"
436 2013-08-26 17:22:13 <Luke-Jr> arioBarzan: and what if I am a good miner, but I don't want to participate in your collusion?
437 2013-08-26 17:23:36 <arioBarzan> Luke-Jr: It would be a feature like P2SH, if others accept it, then you (as a good miner who disagrees) also would be forced to accept
438 2013-08-26 17:25:24 <gmaxwell> man, and you think the centeralization of pools is bad today.
439 2013-08-26 17:25:41 <arioBarzan> Luke-Jr: I am not suggesting that the ID checkpoint be verified always, but the nodes themselves would have the option to willfully separate themselves with their own fork from an unwanted chain, even if that chain is longer
440 2013-08-26 17:25:48 <gmaxwell> arioBarzan: in any case you've continually ignored that even once you have your identifers, acting on them safely requires a consensus mechenism.
441 2013-08-26 17:25:56 <sipa> ^
442 2013-08-26 17:26:02 <sipa> you can't just ignore a block
443 2013-08-26 17:26:10 <Luke-Jr> arioBarzan: such separation infers a centralized decision
444 2013-08-26 17:26:11 <sipa> unless you find 51% of hashing power to do so along with you
445 2013-08-26 17:26:25 <sipa> which would mean it requires a collusion attack on the network
446 2013-08-26 17:26:39 <sipa> so all you're doing is (assuming it were possible) making it harder to mine anonymously
447 2013-08-26 17:26:50 <gmaxwell> sipa: 51% hashpower, or rather "~100% of users"
448 2013-08-26 17:28:59 <arioBarzan> Let's say there are 2 million users in poland and then BFL & Avalon provide US miners with a powerful mining tech. So Users in poland would have to willfuly separater their fork from US miners and avoid an unfair transaction fee which could be like 1BTC per transaction
449 2013-08-26 17:29:18 <sipa> how is that 'unfair' ?
450 2013-08-26 17:29:38 <sipa> it may be expensive, and it may be unwanted
451 2013-08-26 17:29:48 <arioBarzan> it dould be polish nodes' decision
452 2013-08-26 17:29:59 <Luke-Jr> arioBarzan: they are deciding to not use Bitcoin
453 2013-08-26 17:30:00 <gmaxwell> I am giggling at avalon being your example of consolidation in the "west"
454 2013-08-26 17:30:06 <Cusipzzz> sounds like they want PolandCoin
455 2013-08-26 17:30:10 <Luke-Jr> gmaxwell: I know, right? :p
456 2013-08-26 17:30:21 <sipa> ^ PolandCoin is what you want
457 2013-08-26 17:30:29 <michagogo> Odd... I've had wireshark running with a capture filter of "port 8333 or port 18333" since before starting my nodes, and in 310k packets I haven't had anything matching "bitcoin.addr"
458 2013-08-26 17:31:10 <arioBarzan> who cares if they decide to go their way. The polish mining pools might only charge a 0.01BTC tx fee so they may prefer to move to that chain as a cheaper market.
459 2013-08-26 17:31:39 <sipa> so, they can
460 2013-08-26 17:31:49 <Luke-Jr> they can do that without miner id
461 2013-08-26 17:31:56 <Luke-Jr> just use a new genesis block and magic
462 2013-08-26 17:32:06 <sipa> bitcoin offers a global consensus, which means a global marker
463 2013-08-26 17:32:19 <sipa> that means globalization, but probably also a more useful payment system
464 2013-08-26 17:32:27 <sipa> if you want a more localized one, feel free to do so
465 2013-08-26 17:32:53 <Luke-Jr> you can even back your local-coin with Bitcoin
466 2013-08-26 17:33:52 <Cusipzzz> or gold /cue tinfoil hatters
467 2013-08-26 17:36:19 <arioBarzan> A more localized one wouldn't be desired obviously. I'm sorry if I mis-spoke with wrong examples. My idea was about ignoring just one miner which other nodes globally might agree that the hostile node should be blacklisted. it could be for 24hours or 1 week
468 2013-08-26 17:36:55 <Luke-Jr> arioBarzan: how do you decide globally that he should be blacklisted?
469 2013-08-26 17:37:46 <sipa> and how do you make everyone agree on it?
470 2013-08-26 17:37:48 <arioBarzan> If all miners have unique ID, then since the blockchain is public all people could see who is doing nasty stuff
471 2013-08-26 17:38:01 <sipa> you're not answering Luke-Jr's question
472 2013-08-26 17:38:06 <Luke-Jr> I'm going to make 100000 ids just to vote every other miner out
473 2013-08-26 17:38:51 <arioBarzan> Gavin could send an alert to nodes, and ask them to not accept blocks from that ID for let say 1 week
474 2013-08-26 17:38:52 <Cusipzzz> Luke-Jr: well, there would be a PoW, and...
475 2013-08-26 17:39:05 <Luke-Jr> arioBarzan: ah, so King Gavin is the new Fed
476 2013-08-26 17:39:28 <sipa> arioBarzan: and you don't like centralization??
477 2013-08-26 17:39:28 <sipa> _every_ node has to agree, eventually, about the block history
478 2013-08-26 17:39:28 <sipa> i think you fail to understand that bitcoin is a consensus system
479 2013-08-26 17:40:04 <arioBarzan> King Gavin could ask, then we would evaluate his suggestion and agree if we like
480 2013-08-26 17:40:14 <Cusipzzz> "damn these guys are getting too many blocks, they need a 24hr timeout"
481 2013-08-26 17:40:18 <sipa> how do you know everyone agree?
482 2013-08-26 17:40:25 <sipa> in particular, how does the attacker agree?
483 2013-08-26 17:40:30 <Luke-Jr> arioBarzan: and if you are wrong, then you lose all your own blocks
484 2013-08-26 17:41:56 <arioBarzan> the attacker will maybe get scared of poeple rising and stop charging us crazy fees like 1BTC per tx
485 2013-08-26 17:42:08 <arioBarzan> :)
486 2013-08-26 17:42:57 <sipa> if people are able to amass a 51% vote to ignore him
487 2013-08-26 17:43:05 <Luke-Jr> I'm going to take my gun, go to King Gavin's house where I know he's defenseless because Australia prohibits self defense, and force him to issue an alert saying "we've basically already decided to ban gigavps, so agree or you lose out"
488 2013-08-26 17:43:06 <sipa> why can't they just mine themself with that power?
489 2013-08-26 17:43:44 <Luke-Jr> (hypothetically!)
490 2013-08-26 17:44:13 <sipa> and accept reasonable fees
491 2013-08-26 17:44:18 <Cusipzzz> Luke-Jr: he has pretty good aim with a boomerang I hear
492 2013-08-26 17:44:23 <Luke-Jr> Cusipzzz: lol
493 2013-08-26 17:44:50 <gmaxwell> yea, they don't need guns in .au, the wildlife will kill you.
494 2013-08-26 17:44:58 <sipa> and the dropbears
495 2013-08-26 17:45:01 <sipa> and hoop snakes
496 2013-08-26 17:45:22 <Luke-Jr> ok, I'm the US governemnt.
497 2013-08-26 17:45:31 <gmaxwell> Luke-Jr: why not be the chinese one?
498 2013-08-26 17:45:33 <Luke-Jr> I threaten Gavin to "accidentally" his house if he doesn't comply.
499 2013-08-26 17:45:40 <Luke-Jr> ???
500 2013-08-26 17:45:46 <Luke-Jr> this is all BESIDES THE POINT <.<
501 2013-08-26 17:46:02 <gmaxwell> yea, this stopped being productive like hours ago.
502 2013-08-26 17:46:27 <gmaxwell> arioBarzan wants to fight centeralization with arioBarzan /and slight of hand!/
503 2013-08-26 17:46:41 <gmaxwell> er with centeralization... stupid paste!
504 2013-08-26 17:46:49 <Cusipzzz> he almost had me until Miner IDs :)
505 2013-08-26 17:47:06 <Luke-Jr> gmaxwell: now I'm curious what you were pasting from! :P
506 2013-08-26 17:47:25 <gmaxwell> there is all sorts of awesome problem solving you can do if you only add centeralization.
507 2013-08-26 17:47:49 <sipa> like not needing miners
508 2013-08-26 17:48:04 <gmaxwell> but if you're willing to do that you can just squint a little harder and eliminate mining. exactly.
509 2013-08-26 17:48:05 <arioBarzan> A POW coinbase wouldn't kill anybody. It could be only be optional feature for those who want to be in a whitelist. Then nodes who as majority of users do not have hash power could make a consensus based on their evaluation, not only on a rule of longer chain.
510 2013-08-26 17:48:32 <Luke-Jr> ???
511 2013-08-26 17:48:33 <Cusipzzz> O_o
512 2013-08-26 17:48:40 <gmaxwell> you've still failed to state a consensus mechenism.
513 2013-08-26 17:48:43 <Luke-Jr> arioBarzan: do you know what 'consensus' means?
514 2013-08-26 17:49:24 <arioBarzan> consensus mechanism would be = longer chain - (blocks of hostile miner)
515 2013-08-26 17:49:42 <Luke-Jr> arioBarzan: you need a consensus to DEFINE "hostile miner"
516 2013-08-26 17:50:33 <sipa> and collude against him
517 2013-08-26 17:50:33 <sipa> you need at least 51% of the hash power to agree that the miner is hostile
518 2013-08-26 17:50:43 <sipa> and if you don't know whether you have that 51% (hint: you never do), you risk losing your own blocks against him
519 2013-08-26 17:50:49 <Luke-Jr> you need 100%, if you don't want to hurt other unrelated innocent parties
520 2013-08-26 17:50:52 <sipa> please stop this
521 2013-08-26 17:52:20 <Luke-Jr> finally, how do you even know the miner's fee policy?
522 2013-08-26 17:52:28 <Luke-Jr> you going to trust him to tell you the truth?
523 2013-08-26 17:54:33 <arioBarzan> Luke-Jr: for example BTCGuild doesn't accept transactions with less fee than 0.0001 but Eligius last time I checked had loser conditions on fees
524 2013-08-26 17:54:40 <arioBarzan> looser*
525 2013-08-26 17:54:54 <Luke-Jr> arioBarzan: you know that because we publish them
526 2013-08-26 17:54:59 <Luke-Jr> arioBarzan: we could just as easily lie
527 2013-08-26 17:55:17 <sipa> or worse, specifially block your transactions
528 2013-08-26 17:55:26 <jgarzik> Is eligius the only pool [with any amount of hashpower] that accepts non-standard transactions?
529 2013-08-26 17:55:34 <Luke-Jr> sipa: well, that's a miner's right too :p
530 2013-08-26 17:55:45 <Luke-Jr> jgarzik: I think midnightmagic might on his p2pool node too
531 2013-08-26 17:55:49 <Luke-Jr> and petertodd
532 2013-08-26 17:55:52 <sipa> Luke-Jr: agree, but it does mean you're unlikely to want to support them
533 2013-08-26 17:55:57 <sipa> (which is also your right)
534 2013-08-26 17:56:41 <gmaxwell> Luke-Jr: I'm pretty sure that mm, pt, and I combined are now <1% hashpower.
535 2013-08-26 17:56:47 <Luke-Jr> :/
536 2013-08-26 17:56:58 <gmaxwell> so not meeting jgarzik's "with any amount"
537 2013-08-26 17:57:30 <Luke-Jr> BTCGuild recently refused to prioritise someone's transaction for a bounty, because they "run pure"
538 2013-08-26 17:57:32 <Luke-Jr> O.o
539 2013-08-26 17:58:24 <arioBarzan> for now the miners have 25 BTC reward. later they will charge much more, then bitcoin will become centralized and instead of federal reserve we would probably have mining pool consortium that would charge any fee that they like
540 2013-08-26 17:59:08 <sipa> if miners charge exuberant fees, then others have all reason to start up their own mining operations to avoid those
541 2013-08-26 17:59:35 <gmaxwell> jgarzik: getting in the txn priority rpc stuff might be a good halfstep... e.g. even if a pool doesn't take non-standards if they could just RPC to poke a txn into their mempool, some would.
542 2013-08-26 17:59:36 <sipa> now please take this discussion elsewhere
543 2013-08-26 17:59:46 <jgarzik> indeed. -> #bitcoin
544 2013-08-26 18:00:12 <Luke-Jr> gmaxwell: priority stuff doesn't make you accept transactions you won't otherwise :/
545 2013-08-26 18:00:15 <arioBarzan> but if we add ID feature we could separate ourself even if we don't have as big hash power as that consortium would have.
546 2013-08-26 18:00:18 <gmaxwell> Luke-Jr: I wonder if the code to do that were standard if they'd have been more willing.
547 2013-08-26 18:00:18 <Luke-Jr> maybe it should
548 2013-08-26 18:00:21 <gmaxwell> Luke-Jr: I know, it could though.
549 2013-08-26 18:00:33 <gmaxwell> Luke-Jr: I suppose you'd want that to be a flag. :-/
550 2013-08-26 18:00:54 <Luke-Jr> gmaxwell: I don't think so?
551 2013-08-26 18:01:24 <Luke-Jr> if you're prioritising it, you presumably want it to confirm
552 2013-08-26 18:01:48 <gmaxwell> consider the case where you setup a webpage where people can solve captchas to get priority.. you really don't want that picking crazy ass transactions, and you also don't want to reproduce the sanity checking logic.
553 2013-08-26 18:02:01 <Luke-Jr> hm
554 2013-08-26 18:02:49 <gmaxwell> so I think "take this no matter what" and "up priortize this if I would have already taken it" are distinct cases.
555 2013-08-26 18:06:55 <petertodd> Hmm... so how non-standard are we talking about?
556 2013-08-26 18:09:51 <gmaxwell> even luke doesn't take arbritary transactions.
557 2013-08-26 18:10:49 <petertodd> Exactly, his accept-non-standard patch still filters out a lot of stuff - for instance nLocktime > 2*31-1, or nVersion!=1
558 2013-08-26 18:22:45 <petertodd> reddit coinjoin link: http://www.reddit.com/r/Bitcoin/comments/1l4t2l/coinjoin_bounty_fund_launched_to_make_bitcoin/
559 2013-08-26 18:51:21 <helo> cue debate on using the bitcoin p2p network to arrange coinjoin transactions
560 2013-08-26 18:52:35 <gmaxwell> helo: It's been suggested, but I think using a parallel topology makes more sense. ... simply because the nodes with wallets and the nodes generally serving the network don't have big overlap.
561 2013-08-26 18:53:30 <gmaxwell> also, "in the bitcoin network" implies that we first pick just one way to do it, and I think that creates an unnecessary consensus bottleneck.
562 2013-08-26 18:56:47 <helo> the frequency of transactions per person is probably so low that you have to have quite a big group of people participating in a coinjoin collective for anyone to be able to readily send joint transactions
563 2013-08-26 18:58:54 <helo> addressing the DOS part seems to dovetail nicely with the need for a widely used trust system
564 2013-08-26 19:00:28 <helo> but that kind of thing seems to be going nowhere
565 2013-08-26 19:00:41 <helo> particularly a decentralized one
566 2013-08-26 19:02:57 <gmaxwell> I don't think that the dos stuff is that interesting. It's only a hardish problem in a fully decenteralized CoinJoin. As much as I love cryptowank I feel that decenteralized CoinJoin is unlikely to materalize soon, but I'll happily eat crow if someone shows up with one.
567 2013-08-26 19:07:56 <helo> ruling out decentralized coinjoin, the need to readily find others that want to send a transaction in a similar timeframe means completely centralized will happen.
568 2013-08-26 19:08:41 <helo> so i'm betting that bounty will go to the NSA when they build such a service :)
569 2013-08-26 19:08:55 <c0rw1n> why? it's a ledger, like an exchange
570 2013-08-26 19:08:57 <gmaxwell> helo: what do you mean by completely centralized? coinjoin is financial zero-trust inherently.
571 2013-08-26 19:09:35 <c0rw1n> with nlocktimed contracts you could announce them through bitcoin
572 2013-08-26 19:10:02 <gmaxwell> c0rw1n: uh?
573 2013-08-26 19:10:48 <helo> completely centralized as in, someone releases a "tor coinjoin bundle" that connects to a hidden service that acts as a matchmaker for grouping transactions
574 2013-08-26 19:11:16 <Luke-Jr> +b jedunnigan?
575 2013-08-26 19:11:20 <gmaxwell> helo: k sure, the only thing an evil server could do there is remember the input/output correspoance.
576 2013-08-26 19:11:26 <c0rw1n> why would that service be centralized? it can be reading a blockchain, or a subset (colored coins)
577 2013-08-26 19:11:37 <TheLordOfTime> ;;op
578 2013-08-26 19:11:42 <gmaxwell> c0rw1n: I think you have no idea whats being talked about here.
579 2013-08-26 19:11:46 <gmaxwell> TheLordOfTime: all yours
580 2013-08-26 19:11:50 <helo> where that hidden service is the centralized entity that keeps track of reputations to avoid dos
581 2013-08-26 19:12:14 <TheLordOfTime> gmaxwell, sorry for the random op, i don't normally op outside of -otc :P
582 2013-08-26 19:12:26 <TheLordOfTime> but... broken IRC users? I have no issue banforwarding :P
583 2013-08-26 19:12:27 <TheLordOfTime> unless they evade
584 2013-08-26 19:12:35 <TheLordOfTime> ACTION bnroke the ban then.
585 2013-08-26 19:13:03 <TheLordOfTime> ... stupid keyboard not working right...
586 2013-08-26 19:13:24 <TheLordOfTime> there we go.
587 2013-08-26 19:14:36 <Diablo-D3> lolwhat
588 2013-08-26 19:22:13 <helo> pushed to the extreme, each block could be replaced by a single coinjoin transaction?
589 2013-08-26 19:23:23 <helo> can you spend outputs in the same transaction that they are created?
590 2013-08-26 19:24:16 <Luke-Jr> no
591 2013-08-26 19:24:39 <Luke-Jr> you don't know the txid (for the input) until the transaction is made
592 2013-08-26 19:24:48 <helo> hah good point
593 2013-08-26 19:24:56 <Luke-Jr> so it's not so much a rule, as it is a "you just.. can't.. do it."
594 2013-08-26 19:25:30 <gmaxwell> well, if you might have done that then you could just skip the inner transaction.
595 2013-08-26 19:25:47 <Luke-Jr> true
596 2013-08-26 19:25:48 <helo> right
597 2013-08-26 19:25:59 <gmaxwell> might be need to have some "transaction reassignment" stuff go along with coinjoin.
598 2013-08-26 19:26:51 <gmaxwell> E.g. some convention where you pay someone and they're like 'oh, I'm spending it here right away, feel free to skip over me' and you compute a replacement transaction which just reaches the same ultimate state...
599 2013-08-26 19:27:18 <helo> sounds ripplish
600 2013-08-26 19:27:24 <Luke-Jr> helo: that's not bad
601 2013-08-26 19:27:27 <gmaxwell> a really smart kind of child pay for parent could handle that replacement.
602 2013-08-26 19:27:50 <gmaxwell> "oh this group of txn achieves the same final state as this other, and it pays more fee per byte"
603 2013-08-26 19:32:54 <sipa> gmaxwell: and let me guess, it's NP-complete?
604 2013-08-26 19:33:43 <helo> are the motivations of miners in line with users regarding coinjoin?
605 2013-08-26 19:33:56 <helo> miners want a small blockchain, but they presumably want a lot of tx fees
606 2013-08-26 19:34:33 <helo> i guess above all they want widespread use of bitcoin
607 2013-08-26 19:34:55 <gmaxwell> helo: the maximum reduction is not huge in any case, and besides: miners can't really do anything about this. The transactions look normal.
608 2013-08-26 19:35:02 <helo> which something like coinjoin could aid
609 2013-08-26 19:35:04 <Luke-Jr> helo: offer the same fee for the reduced size
610 2013-08-26 19:35:17 <Luke-Jr> if it concerns you
611 2013-08-26 19:35:21 <helo> gmaxwell: i was thinking more along the lines of miners taking a role in performing coinjoin services
612 2013-08-26 19:35:35 <gmaxwell> helo: I think it's generally in their interest.
613 2013-08-26 19:36:49 <gmaxwell> sipa: approximate solutions are good enough.
614 2013-08-26 19:38:29 <gmaxwell> I suppose that kind of makes another argument for using near time locked transactions... you could use the locking window to perform transaction cut-through.
615 2013-08-26 19:39:44 <gmaxwell> e.g. if there is a transaction whos inputs are pending unconfirmed, and who has outputs which are pending unconfirmed.. and the inner transaction author consents, the original authors could just coinjoin a replacement for the inner transaction that cuts through it.
616 2013-08-26 19:45:31 <gmaxwell> would be interesting to parse through the chain and see how much compression you could get if you assume all txn in a block could have been cut-through.
617 2013-08-26 19:45:55 <gmaxwell> Probably not much because sane wallets don't normally spend unconfirmed inputs.
618 2013-08-26 19:49:57 <helo> s/in a block/ever/
619 2013-08-26 19:51:41 <gmaxwell> well.. ever would let you compress the whole blockchain to like 300mbytes. :P
620 2013-08-26 19:52:18 <sipa> gmaxwell: significantly more, i think
621 2013-08-26 19:52:27 <helo> "bytes_serialized" : 238056559 ?
622 2013-08-26 19:52:42 <sipa> as the utxo format is much more space-efficient
623 2013-08-26 19:52:43 <helo> plus coinbase transactions, i guess?
624 2013-08-26 19:52:48 <sipa> and only contains outputs
625 2013-08-26 19:53:53 <sipa> hmm, i guess the fully-cut-through version would be one transaction consuming all coinbase outputs, and sending everything to its utxo state outputs
626 2013-08-26 19:54:07 <sipa> broken up to not exceed block limits
627 2013-08-26 19:54:26 <gmaxwell> yea, I was ignoring block limits.
628 2013-08-26 19:55:02 <gmaxwell> it would just be one transaction that consumes all the consumed blocks, and pays to all the outputs. :P and yea, it would be somewhat larger than ultraprune, but waaaay smaller than the blockchain.
629 2013-08-26 19:57:59 <Scrat> why is the lereddit CoinJoin post getting downvotes? lol
630 2013-08-26 19:58:26 <gmaxwell> Scrat: yea, blows my mind.
631 2013-08-26 19:58:53 <Cusipzzz> Scrat: people are morons
632 2013-08-26 19:59:45 <gmaxwell> Scrat: some of the response on bitcointalk suggests to me that CoinJoin violates some people's preferred position that bitcoin is already uberanonymous.
633 2013-08-26 20:01:21 <sipa> people disliked the payment protocol because it violated that model as well
634 2013-08-26 20:01:36 <sipa> even though if anything, it's a huge win for privacy
635 2013-08-26 20:05:57 <Scrat> wrt privacy: cloudflare must have a really nice address-to-IP list by now
636 2013-08-26 20:06:07 <Scrat> who doesn't check their address on b.i? :p
637 2013-08-26 20:06:13 <Scrat> address(es)
638 2013-08-26 20:07:45 <lianj> probably to incompetent to actually track them :P
639 2013-08-26 20:07:46 <lianj> *too
640 2013-08-26 20:09:43 <phantomcircuit> Scrat, well me for one