1 2013-02-27 01:18:00 <gmaxwell> jgarzik: hm. Do you think that merging performance improvements like the stuff in 0.8 was ultimately counterproductive since it only forstalls the loop closing on inefficient usage?
2 2013-02-27 01:23:53 <muhoo> possibly OT, but i wonder if there's any way for BTC to survive an attack like this, if one comes: http://www.slate.com/blogs/future_tense/2013/02/25/six_strikes_copyright_enforcement_system_launches_will_throttle_your_bandwidth.html
3 2013-02-27 01:30:29 <andytoshi> muhoo: if there is some way to get 1Mb/10mins bandwidth, bitcoin can survive
4 2013-02-27 01:31:52 <muhoo> aye, good point. with bloom filters, runs just fine on EDGE now :-)
5 2013-02-27 01:33:12 <jgarzik> gmaxwell: heh
6 2013-02-27 01:33:17 <jgarzik> gmaxwell: who knows
7 2013-02-27 01:34:25 <gmaxwell> jgarzik: your comment just made me wonder a bit. I guess its at least something to ponder.
8 2013-02-27 01:36:45 <jgarzik> gmaxwell: oh hell which comment was that ;p
9 2013-02-27 01:37:55 <gmaxwell> the evoorhees subthread.
10 2013-02-27 01:38:06 <gmaxwell> "Miners (and the network) will not see the impact as long as the block reward far exceeds other network costs, like unspent transaction output set (UTXO) storage."
11 2013-02-27 01:48:57 <andytoshi> i have a dumb network question: how do other nodes connect to me?
12 2013-02-27 01:49:04 <andytoshi> if i telnet to my public IP on 8333, i get blocked
13 2013-02-27 01:49:30 <gmaxwell> andytoshi: you mean for your tor node?
14 2013-02-27 01:49:46 <andytoshi> yes, and my bitcoin node -- i'm actually confused about both
15 2013-02-27 01:50:07 <andytoshi> (though i understand how hidden services work, using only my own outbound connections)
16 2013-02-27 01:50:26 <gmaxwell> well if things can't connect to 8333 on your public IP then you can't have v4 inbound.
17 2013-02-27 01:50:37 <gmaxwell> if you're running a hidden service??? thats going to be connecting to 127.0.0.1
18 2013-02-27 01:51:01 <gmaxwell> so it's perfectly possible for that to work while the public ipv4 is firewalled off.
19 2013-02-27 01:51:20 <andytoshi> right, but most people don't punch holes in their router -or- run a tor node
20 2013-02-27 01:51:30 <andytoshi> so how does bitcoin have a working p2p network?
21 2013-02-27 01:51:46 <gmaxwell> andytoshi: right, so two reasons: one is that many people do forward ports.
22 2013-02-27 01:51:53 <gmaxwell> (or run nodes that are not behind nat)
23 2013-02-27 01:52:10 <gmaxwell> the other is that bitcoin support UPNP to tell nat-routers to foward the port.
24 2013-02-27 01:52:20 <gmaxwell> and UPNP is on by default in the gui version.
25 2013-02-27 01:52:40 <andytoshi> ah, that's what i'm missing
26 2013-02-27 01:52:45 <HM> it's a shame the protocol isn't UDP (1 reason against many), or it could use hole punching
27 2013-02-27 01:52:58 <gmaxwell> HM: hole punching is pretty unreliable.
28 2013-02-27 01:53:07 <andytoshi> does tor also do upnp?
29 2013-02-27 01:53:10 <HM> not in my experience
30 2013-02-27 01:53:20 <phantomcircuit> andytoshi, tor/upnp is nonsensical
31 2013-02-27 01:53:22 <gmaxwell> andytoshi: tor requires you to forward the ports if you are to have inbound.
32 2013-02-27 01:53:44 <andytoshi> oh, i've been running a useless tor node for several months now then :{
33 2013-02-27 01:54:14 <andytoshi> phantomcircuit: why?
34 2013-02-27 01:54:41 <phantomcircuit> andytoshi, upnp is about NAT transversal
35 2013-02-27 01:54:45 <phantomcircuit> there isn't any NAT with tor
36 2013-02-27 01:54:48 <andytoshi> oh, i do have tor set up properly :P i just forgot
37 2013-02-27 01:55:04 <HM> that's not entirely true
38 2013-02-27 01:55:12 <andytoshi> phantomcircuit: there is a NAT between my tor node and the public internet
39 2013-02-27 01:55:14 <gmaxwell> HM: having written VoIP software ... I'm pretty confident in saying its unreliable. I mean??? sure, better than nothing when you have no other choice. But as you note, thats basically the one advantage among many disadvantages.
40 2013-02-27 01:55:33 <gmaxwell> If someone wanted to build an alternative udp based transport for bitcoin, that would be peachy though.
41 2013-02-27 01:55:37 <HM> gmaxwell: what makes it unreliable in your experience? NAT timeouts?
42 2013-02-27 01:56:30 <HM> oh my no, i wouldn't recommend UDP
43 2013-02-27 01:57:00 <gmaxwell> HM: nested nats, crazy port restrictions in nats, symmetric nats that break stun etc.
44 2013-02-27 01:57:18 <gmaxwell> (not having access to working stun/turn services)
45 2013-02-27 01:57:25 <gmaxwell> etc.. lots of things to go kablooy.
46 2013-02-27 01:58:39 <HM> Networking: it's always worse than youe xpect
47 2013-02-27 01:58:41 <HM> expect*
48 2013-02-27 02:01:56 <andytoshi> gmaxwell: thanks, i was worried that i was misunderstanding something fundamental
49 2013-02-27 02:02:01 <andytoshi> but i just need to research upnp..
50 2013-02-27 02:02:53 <HM> I hate NAT
51 2013-02-27 02:02:58 <HM> My ISP forces it upon me
52 2013-02-27 02:03:55 <andytoshi> HM: by giving you too few IP addresses, or something more?
53 2013-02-27 02:04:34 <HM> 1 IP
54 2013-02-27 02:04:45 <HM> they just have NAT built right in to the cable modem, and you can't disable it
55 2013-02-27 02:04:53 <HM> the best you can do is DMZ
56 2013-02-27 02:04:59 <gmaxwell> andytoshi: ISPs are starting to put customers behind nat. Worse, they're particular uninspired port restricted nats. It's pretty ubiquitious in the mobile space already.
57 2013-02-27 02:05:17 <gmaxwell> Go go IPv4 scarcity.
58 2013-02-27 02:05:31 <HM> this isn't scarcity, it's just incompetence and shitty hardware
59 2013-02-27 02:07:33 <HM> sometimes i want to break their equipment with a flaming sledgehammer
60 2013-02-27 02:13:17 <andytoshi> wth, there is a while loop implemented with goto in the tor source
61 2013-02-27 02:14:08 <andytoshi> http://pastebin.com/hBTkW7uV
62 2013-02-27 02:17:34 <HM> a "do {} while" loop would be more appropriate
63 2013-02-27 02:18:57 <andytoshi> yeah, very strange for a codebase that (presumably) gets read pretty carefully
64 2013-02-27 02:20:02 <HM> they probably just had something else there and cleaned it out
65 2013-02-27 02:20:11 <HM> the tor codebase is surprisingly readable i find
66 2013-02-27 02:20:23 <HM> some long ass C files though
67 2013-02-27 02:21:01 <andytoshi> i agree, it's easy to get answers to high-level questions like "how are the specific nodes in a circuit chosen?"
68 2013-02-27 02:21:20 <andytoshi> the answer is in choose_good_entry_server() and choose_good_middle_server() :)
69 2013-02-27 02:22:09 <andytoshi> and is basically: choose at random, don't repeat nodes, don't use the exit node, don't use your own node
70 2013-02-27 02:23:17 <HM> i believe there's some IP checking in there as well
71 2013-02-27 02:23:23 <HM> to try and spread nodes across subnets
72 2013-02-27 02:23:47 <andytoshi> i read that somewhere too, but it's not jumping out at me
73 2013-02-27 02:23:57 <andytoshi> the real choosing happens in router_choose_random_node()
74 2013-02-27 02:24:24 <HM> one thing i found surprising is that addresses are only 80 bits
75 2013-02-27 02:24:51 <HM> i'd say that's borderline for being able to brute force a colliding name
76 2013-02-27 02:24:55 <andytoshi> hidden service addresses you mean?
77 2013-02-27 02:25:00 <HM> yes
78 2013-02-27 02:25:32 <andytoshi> i'd say 66 is borderline, 80 will be maybe borderline by my end-of-life
79 2013-02-27 02:25:44 <HM> lol why 66
80 2013-02-27 02:26:36 <andytoshi> i dunno, just "64 plus a bit"
81 2013-02-27 02:27:11 <HM> you only have to generate a valid rsa keypair and then hash it once to check for a collision
82 2013-02-27 02:27:36 <HM> i think you can do the former quite efficiently
83 2013-02-27 02:28:04 <andytoshi> well, i only have experience with CPUs, which are pretty bad at stupidly-parallelizable problems
84 2013-02-27 02:28:13 <andytoshi> so probably i am way overestimating how difficult things are
85 2013-02-27 02:29:38 <andytoshi> but i do a fair bit of work in ramsey theory, where problems are usually along the lines of "try to brute-force this, see how feasible it is"
86 2013-02-27 02:29:44 <gmaxwell> HM: the keypair doesn't need to be secure either.
87 2013-02-27 02:29:50 <andytoshi> then we make conjectures about whether our recursion trees have infinite depth :P
88 2013-02-27 02:30:04 <gmaxwell> though even if yu want secure??? the gpu onion searcher now does like 500m attempts per second on a low end gpu.
89 2013-02-27 02:30:10 <gmaxwell> (much faster than bitcoin mining)
90 2013-02-27 02:30:15 <gmaxwell> also, sha1 is saddness.
91 2013-02-27 02:30:48 <andytoshi> i think, the tor people had an idea that .onions should be memorizable
92 2013-02-27 02:31:12 <andytoshi> e.g., one of the libraries has their address printed in 4-character blocks and says "memorize one each day" :P
93 2013-02-27 02:31:13 <gmaxwell> andytoshi: they're still a bit too long for that.
94 2013-02-27 02:31:18 <andytoshi> agreed
95 2013-02-27 02:32:03 <gmaxwell> andytoshi: I think it was more like "okay, can't use the public key??? too gigantic. lets hash it.. how much security do we need? okay!" but who knows.
96 2013-02-27 02:32:57 <HM> they could have used the public key if they'd used EC instead of RSA
97 2013-02-27 02:32:58 <HM> maybe
98 2013-02-27 02:34:28 <HM> seems to me tor could benefit from something like namecoin
99 2013-02-27 02:34:30 <HM> but perhaps simpler
100 2013-02-27 02:35:22 <andytoshi> hopefully i will have time this summer to write a refrence client for my high-latency darknet
101 2013-02-27 02:35:55 <HM> andytoshi: do you have any unique ideas?
102 2013-02-27 02:36:24 <andytoshi> HM: i don't think so, just think it's a better time to go for it than it was 5 years ago
103 2013-02-27 02:36:34 <andytoshi> when mixmaster, mixminion, etc, were used
104 2013-02-27 02:36:45 <andytoshi> or rather, when they were maintained
105 2013-02-27 02:39:17 <andytoshi> the high-level premise is: your node creates a bunch of connections, every 10-60 minutes (at random) it drops one, creates one
106 2013-02-27 02:39:47 <HM> what's the advantage?
107 2013-02-27 02:40:00 <andytoshi> these connections maintain a constant traffic, usually just zeros, though the first frame contains random bits
108 2013-02-27 02:40:12 <HM> :|
109 2013-02-27 02:40:19 <andytoshi> but if you want to actually connect somewhere, then you do an onion route
110 2013-02-27 02:40:46 <andytoshi> tell some guy A, "help me handshake to B", then tell B "help me handshake to C", etc
111 2013-02-27 02:41:19 <andytoshi> (and there are also massive delays between the handshakes)
112 2013-02-27 02:42:30 <andytoshi> therefore, somebody monitoring the network can't see any correlation between the logical circuits and the actual bits-on-the-wire circuits
113 2013-02-27 02:43:14 <andytoshi> i'm not sure what you mean by, "what's the advantage?" --- what are you comparing to?
114 2013-02-27 04:48:00 <swulf--1> hopefully easy q: what incentive is there for a miner (or standard client for that matter) to rebroadcast a transaction once its been received?
115 2013-02-27 04:51:57 <swulf--1> in fact, isn't there an incentive to not broadcast the knowledge about a tx, especially if the fees in the tx are high? "If nobody else (or fewer nodes) know about it, then there's a higher chance that I'll get the fees in this tx?"
116 2013-02-27 04:52:12 <swulf--1> nodes could even corroborate and only send txns within a specific subnet
117 2013-02-27 04:52:17 <swulf--1> or am I missing something?
118 2013-02-27 05:09:28 <reeep> there's no incentive to rebroadcast transactions
119 2013-02-27 05:09:37 <reeep> but most of the people broadcasting transactions are not also mining them
120 2013-02-27 05:11:19 <jgarzik> well no incentive beyond making bitcoin useful
121 2013-02-27 05:11:33 <reeep> assuming selfishness ;)
122 2013-02-27 05:11:50 <reeep> hey jgarzik have you had time to look at that ledger idea peter todd posted on the mailing list
123 2013-02-27 05:16:55 <reeep> i don't understand how clients can verify the ledger is redeeming withdrawals.. if they look at the UTXO set for unspent requests, how would anyone but ledger auditors be able to know if the request itself is valid
124 2013-02-27 05:17:11 <reeep> maybe you're trying to withdraw spent coins in the chain. you need the whole chain to verify that
125 2013-02-27 05:17:20 <reeep> whereas double-spends are easy to prove
126 2013-02-27 05:17:39 <Luke-Jr> they are? O.o
127 2013-02-27 05:17:45 <reeep> and what about invalid transactions the ledger puts in the chain, those also need to be checked in the fidelity bond
128 2013-02-27 05:18:06 <reeep> Luke-Jr: well if you have two transactions that conflict, i have just proven to you that a double-spend took place
129 2013-02-27 05:18:14 <Luke-Jr> reeep: but how do you get both?
130 2013-02-27 05:18:55 <Luke-Jr> and what if I, an unrelated third party, am behind the double spend?
131 2013-02-27 05:19:08 <reeep> well let's say the transaction that i'm given from the ledger is signed by the ledger
132 2013-02-27 05:19:23 <reeep> and then another transaction which is broadcasted is also signed at the ledger, both at the same height in the chain
133 2013-02-27 05:19:36 <reeep> i'm talking of course of a private ledger chain, not a proof-of-work blockchain
134 2013-02-27 05:20:18 <reeep> all you need is both conflicting "blocks" to prove the ledger double-spent
135 2013-02-27 05:22:20 <reeep> it's just not trivial to prove the ledger isn't honoring withdrawal requests
136 2013-02-27 05:36:23 <petertodd> Luke-Jr: The ledger has a responsibility to not allow double-spends to happen at all.
137 2013-02-27 05:36:55 <petertodd> Luke-Jr: Two transactions with the same inputs signed by the *ledger* is the proof of a double-spend, and it's the ledger that is punished for it.
138 2013-02-27 05:37:09 <petertodd> Luke-Jr: (in fidelity-bonded ledgers that is, obvious Bitcoin proper is another matter)
139 2013-02-27 05:38:19 <petertodd> Yes, withdrawal requests are the hardest part. For fidelity-bonded banks I was assuming that there would be a "public place" where anyone could post a fraud notice consisting of essentially "why won't you give my money back?" and whose rebuttle is "well, here is the transaction on the blockchain showing I did so"
140 2013-02-27 05:39:19 <petertodd> Fidelity-bonded ledgers could work the same way, although blockchain rules could equally allow specially marked transactions to pull that off in conjuction with transactions locked for a certain time. (IE, confirmed in chain, but with a scriptPubKey containing a "how many confirmations deep is this tx?" opcode.
141 2013-02-27 06:04:12 <reeep> petertodd: wouldn't it be simpler to have a both a height and 'id' (??) field in each block, instead of forming a concrete chain
142 2013-02-27 06:07:29 <reeep> two blocks of the same height signed by ledger? double spend
143 2013-02-27 06:08:14 <reeep> and what about invalid transactions that the ledger signs
144 2013-02-27 06:10:38 <muhoo> ;;ticker
145 2013-02-27 06:10:39 <gribble> BTCUSD ticker | Best bid: 31.27899, Best ask: 31.29999, Bid-ask spread: 0.02100, Last trade: 31.30000, 24 hour volume: 40021.59861634, 24 hour low: 30.22822, 24 hour high: 31.69900, 24 hour vwap: 31.17321
146 2013-02-27 06:12:47 <petertodd> reeep: Well actually you don't need a chain at all.
147 2013-02-27 06:13:30 <petertodd> Transactions imply a directed acyclic graph however, so you need some kind of structure, but the validation machinery in Bitcoin doesn't have to care about any of that.
148 2013-02-27 06:14:19 <petertodd> Now for the sake of detecting double-spends, different ledger implementations can take different approaches, and a publicly visible chain might be the right approach for some. But I'm not going to say it's the only possible approach.
149 2013-02-27 06:25:48 <el_muteh> anyone have any experience compiling vanitygen on a mac?
150 2013-02-27 06:26:28 <el_muteh> I did it, then it told me to upgrade my openssl and rebuild, so I did that, but maybe I didn't do it right, because now it won't build at all
151 2013-02-27 06:27:28 <el_muteh> Undefined symbols for architecture x86_64: "_PKCS5_PBKDF2_HMAC", referenced from: _vg_protect_crypt in util.o
152 2013-02-27 06:27:46 <el_muteh> Bwild: symbol(s) not found for architecture x86_64
153 2013-02-27 06:27:48 <el_muteh> say whut?
154 2013-02-27 06:27:54 <el_muteh> sorry if this isn't the channel for that
155 2013-02-27 06:34:43 <Luke-Jr> el_muteh: it's probably never been done before
156 2013-02-27 06:41:22 <el_muteh> funny cuz it compiled with the version they DIDN'T want me to use
157 2013-02-27 07:03:10 <reeep> brilliant
158 2013-02-27 09:01:58 <davout> hi all, what's the best way to remove a bogus tx from my wallet.dat and claim the spent funds that never got confirmed ? (the wallet is very large so exporting all private keys and reimporting them into a pristine one would take ages)
159 2013-02-27 09:08:00 <Luke-Jr> davout: AFAIK there's no good way
160 2013-02-27 09:08:26 <Luke-Jr> davout: there's a new -salvagewallet option, but I think it basically just imports all the privkeys into a new wallet
161 2013-02-27 09:08:34 <jouke> make a double spend with rawtransaction.
162 2013-02-27 09:09:07 <davout> jouke: sweet, i'll try that
163 2013-02-27 09:09:20 <davout> Luke-Jr: see, there is one :)
164 2013-02-27 09:09:34 <Luke-Jr> uh, I don't see how
165 2013-02-27 09:09:45 <Luke-Jr> doublespending won't delete anything
166 2013-02-27 09:09:46 <jouke> nah, it won't be easy I am afraid as the wallet won't tell you the unspent transactions.
167 2013-02-27 09:10:20 <jouke> Luke-Jr: it will make it void once the other transaction is accepted in a block right?
168 2013-02-27 09:10:26 <Luke-Jr> jouke: nope
169 2013-02-27 09:10:29 <davout> Luke-Jr: i guess i should have emphasized the part about claiming the funds
170 2013-02-27 09:10:36 <Luke-Jr> davout: well, it might do that..
171 2013-02-27 09:10:47 <davout> Luke-Jr: in my specific case it does not matter if the transaction is actually deleted
172 2013-02-27 09:10:57 <Luke-Jr> davout: it does if it has change
173 2013-02-27 09:11:12 <Luke-Jr> the client will eventually attempt to spend it, even at 0 confirms
174 2013-02-27 09:12:00 <davout> I have the txid but i'm not sure how to read the outs that it spent in order to manually make my double spend
175 2013-02-27 09:33:27 <davout> Luke-Jr: looks like the salvagewallet option might be the most practical option after all, does it just run in autopilot when passing it at startup and end up with a clean wallet ?
176 2013-02-27 09:36:09 <Luke-Jr> davout: sorry, I'm not familiar with the details at all
177 2013-02-27 09:36:25 <davout> Luke-Jr: no worries, found the pull request that added it
178 2013-02-27 09:36:32 <davout> looks pretty straightforward
179 2013-02-27 09:38:07 <Diablo-D3> are wallets still bdb in the land of leveldb?
180 2013-02-27 09:38:29 <sipa> yeah
181 2013-02-27 09:38:31 <sipa> unfortunately
182 2013-02-27 09:38:37 <Diablo-D3> also
183 2013-02-27 09:38:46 <Diablo-D3> that rhymes with "land of make believe"
184 2013-02-27 09:39:15 <Diablo-D3> well, maybe not rhyme, but has the same number of beats
185 2013-02-27 09:39:20 <Diablo-D3> that scares me.
186 2013-02-27 09:39:46 <sipa> le-vel-d-b vs make be-lieve
187 2013-02-27 09:39:55 <sipa> 4 vs 3
188 2013-02-27 09:40:01 <Diablo-D3> sipa: be leave
189 2013-02-27 09:40:17 <sipa> ACTION won't leave
190 2013-02-27 09:41:23 <Diablo-D3> lol
191 2013-02-27 09:41:24 <Diablo-D3> anyhow
192 2013-02-27 09:41:40 <Diablo-D3> I have discovered a horrid horrid feature of osx
193 2013-02-27 09:41:47 <Diablo-D3> home does not go to the beginning of the line
194 2013-02-27 09:41:51 <Diablo-D3> it goes to the beginning of the document
195 2013-02-27 09:51:39 <_dr> try CTRL-A,
196 2013-02-27 09:52:11 <_dr> anyway, to edit documents you use vi! ;)
197 2013-02-27 09:53:26 <davout> Diablo-D3: ???+??? ?
198 2013-02-27 09:54:25 <Diablo-D3> _dr: this is in xchat
199 2013-02-27 09:54:33 <Diablo-D3> I have no clue why they ever thought this was acceptable
200 2013-02-27 09:55:02 <Diablo-D3> davout: meh, thats kinda lame
201 2013-02-27 09:55:45 <davout> Diablo-D3: i don't even have a home key :D
202 2013-02-27 09:56:25 <Diablo-D3> davout: non-apple keyboard
203 2013-02-27 09:56:46 <davout> Diablo-D3: blasphemy
204 2013-02-27 09:57:42 <Diablo-D3> Im not a macfag, so those mind tricks dont work on me
205 2013-02-27 09:57:48 <Diablo-D3> hell, Im not even typing this from the mbp
206 2013-02-27 09:57:53 <Diablo-D3> Im typing it TO the mbp from linux
207 2013-02-27 09:58:05 <Diablo-D3> fuck yeah synergy remote control
208 2013-02-27 09:58:10 <davout> Diablo-D3: you are a convoluted person
209 2013-02-27 09:59:26 <Diablo-D3> davout: I needed three things
210 2013-02-27 09:59:38 <Diablo-D3> a new laptop, a retina screen, and an osx box for software dev reasons
211 2013-02-27 09:59:58 <Diablo-D3> no one makes a retina desktop monitor yet, although there are laptops that come wtih retina screens that arent apple
212 2013-02-27 10:00:16 <Diablo-D3> (like the new pixel)
213 2013-02-27 10:00:29 <Diablo-D3> but I didnt want to spend money on one of those mac minis
214 2013-02-27 10:00:50 <Diablo-D3> ended up spending $1269 on this
215 2013-02-27 10:01:02 <Diablo-D3> its factory refurbished, but lets face it, it never touched human hands
216 2013-02-27 10:05:55 <_dr> Diablo-D3: oh, i see. but yeah, the home stuff is really annoying
217 2013-02-27 10:06:24 <_dr> i wonder if it might be time to find out whether irssi finally got a 'set -o vi' option :)
218 2013-02-27 10:06:32 <Diablo-D3> heh
219 2013-02-27 10:06:44 <Diablo-D3> also, why the hell are there no good fixed width terminal fonts for osx
220 2013-02-27 10:07:01 <_dr> oh, there are. monaco menlo are very nice
221 2013-02-27 10:07:18 <_dr> but only crisp when using black text on white background
222 2013-02-27 10:07:44 <_dr> using aliasing with white on black makes fonts unbearable to read, because they are too fat
223 2013-02-27 10:07:56 <Diablo-D3> I hate monaco and menlo
224 2013-02-27 10:08:03 <Diablo-D3> they're very fat and hard to read
225 2013-02-27 10:08:10 <Diablo-D3> I dont even know why apple even shipped them to begin wtih
226 2013-02-27 10:08:14 <_dr> i can recommend 'envy code pro' as a monospaced, non aliased terminal font
227 2013-02-27 10:08:16 <Diablo-D3> Im on courier new atm
228 2013-02-27 10:08:32 <Diablo-D3> Ive tried envy on linux, I wonder if its better on osx + retina
229 2013-02-27 10:08:38 <_dr> Diablo-D3: yeah, the 'fat' issue might be due to white on black, but i agree, it's inacceptable
230 2013-02-27 10:08:43 <Diablo-D3> a LOT of fixed width fonts just fall apart
231 2013-02-27 10:09:02 <Diablo-D3> I use an actual honest to god bitmap font in linux
232 2013-02-27 10:09:42 <_dr> hah
233 2013-02-27 10:10:02 <_dr> good look with that on mac, they're so fast at discarding stuff, mountain lion can no longer deal with bitmap fonts
234 2013-02-27 10:10:36 <Ferroh> Are difficulty changes limited to 25% downwards only, or also 25% upwards?
235 2013-02-27 10:10:54 <sipa> Ferroh: limited in both directions
236 2013-02-27 10:10:58 <Ferroh> thanks
237 2013-02-27 10:11:08 <sipa> Ferroh: so to [0.25*olddiff,4*olddiff]
238 2013-02-27 10:11:24 <_dr> Diablo-D3: i went to a great lot of trouble to get a nice font. i even tried creating a bitmap font using a nicely aliased font by linux, but ney, no bitmap fonts for mac
239 2013-02-27 10:11:31 <Ferroh> you mean 0.75*old diff sipa?
240 2013-02-27 10:11:46 <Diablo-D3> _dr: I dont expect bitmaps to even work on retina
241 2013-02-27 10:12:13 <sipa> Ferroh: no
242 2013-02-27 10:12:21 <Ferroh> ok thanks :)
243 2013-02-27 10:12:22 <Diablo-D3> I'd have to switch to the native res of my retina, which is, I think 2880x1600
244 2013-02-27 10:12:39 <Diablo-D3> or was it 2560x1600?
245 2013-02-27 10:12:41 <Diablo-D3> its something
246 2013-02-27 10:13:00 <Diablo-D3> the whole point of bitmap fonts is 1:1 pixel to pixel drawing
247 2013-02-27 12:22:08 <Luke-Jr> jgarzik: how big (filesize) is the Avalon firmware you were sent?
248 2013-02-27 12:31:51 <eckey> sipa: ping
249 2013-02-27 12:35:04 <sipa> eckey: yes?
250 2013-02-27 12:37:02 <eckey> sipa: wanted to tell you that the problem with the bitcoin-qt process hanging aroung for 10 minutes after termination was resolved with v0.8. thank you for your help.
251 2013-02-27 12:37:26 <sipa> eckey: good to hear!
252 2013-02-27 14:24:33 <jaakkos> perhaps the wiki could describe how the authoritative proof-of-work chain is really chosen, because it's not just about length
253 2013-02-27 14:24:42 <jaakkos> satoshi's paper doesn't describe it either
254 2013-02-27 14:25:26 <gavinandresen> jaakkos: good idea. It is sum of target difficulty. You know the great thing about a wiki is anybody can edit it....
255 2013-02-27 14:25:27 <jaakkos> eg., to answer the question why an arbitrary low-difficulty chain is not chosen
256 2013-02-27 14:25:46 <jaakkos> yeah i wanted to fix something once but couldn't, i even created account :)
257 2013-02-27 14:26:18 <gavinandresen> jaakkos: logout and log back in, you'll get an anti-spam-send-bitcoins-here-address
258 2013-02-27 14:26:29 <jaakkos> ah ok
259 2013-02-27 14:26:49 <gavinandresen> jaakkos: I'd be happy to pay for you if you promise to make the wiki better.
260 2013-02-27 14:28:02 <jeremias> how long I get the edit rights for one payment
261 2013-02-27 14:28:09 <gavinandresen> forever
262 2013-02-27 14:28:11 <jaakkos> atm i mostly learn from the wiki, no the other way around yet ;)
263 2013-02-27 14:28:19 <gavinandresen> it is purely a deter-spammers measure.
264 2013-02-27 14:28:21 <sipa> technically, it is sum of expected work, where work is defined as 2^256/target for each block
265 2013-02-27 14:28:28 <jaakkos> but there are things here and there i could fix
266 2013-02-27 14:28:30 <sipa> as 'difficulty' doesn't exist at the protocol level
267 2013-02-27 14:29:28 <jaakkos> i see
268 2013-02-27 14:29:34 <gavinandresen> listen to sipa, he's much better at being precise than me
269 2013-02-27 14:30:29 <sipa> there may be some -1 somewhere, i'd need to check
270 2013-02-27 14:31:04 <jaakkos> what stops an attacker from dossing the network by sending an infinite crap chain because hey, how do you know the sum of works is not largest in that chain if you don't know the whole chain yet
271 2013-02-27 14:31:51 <sipa> there are several stages in accepting a block
272 2013-02-27 14:32:32 <sipa> 1) context-less checks (just see if the block is viable, without knowing/checking its ancestry)
273 2013-02-27 14:32:58 <sipa> 2) chain chekcs (its parents until genesis are known, PoW/difficulty are correct, ...)
274 2013-02-27 14:33:14 <sipa> 3) connection checks: only done when the block seems to be part of the new best chain
275 2013-02-27 14:34:02 <sipa> and only after passing 3, a block is relayed
276 2013-02-27 14:35:34 <gavinandresen> And there's a specific "is this blocks PoW plausible" check that is done early, and if you try to spam with low-PoW blocks you'll get disconnected and banned.
277 2013-02-27 14:36:27 <jaakkos> is retargetting done by looking at UTC timestamps?
278 2013-02-27 14:36:36 <sipa> yes
279 2013-02-27 14:36:51 <sipa> so all data to calculate the new target is part of the past chain
280 2013-02-27 14:37:21 <jaakkos> 2) sounds like it could be defeated if the attacker can generate enough blocks to retarget, then low difficulty is "correct"
281 2013-02-27 14:38:41 <jaakkos> and the attacker can even choose the new target by choosing the timestamps... anyway this acceptance process must be quite sophisticated, i think i'll study the source
282 2013-02-27 14:39:56 <sipa> 1) is ProcessBlock / CheckBlock, 2) is AcceptBlock, 3) is ConnectBlock
283 2013-02-27 14:39:58 <sipa> afaik
284 2013-02-27 14:41:56 <jaakkos> thanks
285 2013-02-27 14:45:10 <TD_> good morning gavin
286 2013-02-27 14:45:31 <gavinandresen> hey mike
287 2013-02-27 14:48:37 <petertodd> gavinandresen: Does the foundation yet have an official position on it's goals in relation to the decentralization and censorship reistance of Bitcoin?
288 2013-02-27 14:49:04 <petertodd> gavinandresen: We can't really be arguing about block sizes without a position on that issue.
289 2013-02-27 14:49:53 <TD> the foundations position is that highly centralized systems prone to censorship are highly desirable
290 2013-02-27 14:50:07 <gavinandresen> lol
291 2013-02-27 14:50:10 <petertodd> TD: Good to know Mike. :P
292 2013-02-27 14:50:30 <petertodd> TD: Can I quote you on that? (preferably inaccurately)
293 2013-02-27 14:50:31 <gmaxwell> jaakkos: though we do have some vulnerability to crap chain flooding right now. We can basically eliminate it with hearder first fetching, but the hurestic checks are enough to make it not a trivial attack
294 2013-02-27 14:50:50 <TD> hah
295 2013-02-27 14:50:51 <gavinandresen> Official Position(???) ?
296 2013-02-27 14:51:07 <TD> i'm not a part of the foundation beyond being a member
297 2013-02-27 14:51:13 <petertodd> TD: Same
298 2013-02-27 14:51:25 <gavinandresen> I think everybody on the board thinks that more decentralized and more censorship resistant is better.
299 2013-02-27 14:51:58 <gmaxwell> petertodd: Will you next ask them on their position on the goodness of babies and apple pie? :P
300 2013-02-27 14:52:04 <petertodd> gavinandresen: Ok, but "better" is vague; there should be defined engineering goals, so we can weigh solutions against that.
301 2013-02-27 14:52:12 <gavinandresen> ??? but you seem to be pushing for an "absolutely decentralized and absolutely censorship resistant is the #1 overriding priority"
302 2013-02-27 14:52:17 <petertodd> gmaxwell: AMARICA FUCK YAH!
303 2013-02-27 14:52:24 <petertodd> gmaxwel: s/amarica/canada/
304 2013-02-27 14:52:34 <gmaxwell> petertodd: The bitcoin foundation isn't in charge of anything, so I think framing a discussion around BF's goals is misguided in any case.
305 2013-02-27 14:52:46 <gmaxwell> (and not a path we want to start down)
306 2013-02-27 14:53:00 <gavinandresen> yes, what "the foundation" thinks isn't really relevant
307 2013-02-27 14:53:06 <petertodd> gavinandresen: Hey, I've always been open to increasing the block size, but after we know how to keep sufficient decentralization.
308 2013-02-27 14:53:54 <helo> personal note: the foundation unofficially thinks babies go down well with ice cream
309 2013-02-27 14:54:01 <helo> *apple pie
310 2013-02-27 14:54:05 <petertodd> gavinandresen: Probably what I most disagree with is the idea that computers will keep getting faster at the same rate that the scaling problem grows. (and I haven't seen much interest in inflation proofing to get around the issue)
311 2013-02-27 14:54:20 <gavinandresen> petertodd: so, I always say "scaling issues are a good problem to have." It means we're being successful. I think engineers tend to worry about things that they THINK might happen in 20 years, when they should really be worrying about what will happen in the next six months.
312 2013-02-27 14:55:47 <petertodd> gavinandresen: ..but, Bitcoin is a consensus thing, so as it gets bigger issues may be harder to solve, not easier. We can't bake into assumptions that blow up in our faces years down the line, which includes mechanisms for block sizes to grow without bound.
313 2013-02-27 14:56:03 <gavinandresen> It is really easy to get into big, theoretical, angels-dancing-on-pinheads debates about what will happen after we're all dead.
314 2013-02-27 14:56:23 <petertodd> I'm young, I won't be dead for 50 odd years.
315 2013-02-27 14:56:25 <gavinandresen> Who is proposing that block sizes grow without bounds?
316 2013-02-27 14:57:51 <petertodd> Lots of people. People have proposed fixed rules that increase block size on a fixed schedule, say doubling every 18 months. You proposed a voting mechanism that I think would due to perverse incentives.
317 2013-02-27 14:58:11 <gavinandresen> I haven't proposed anything yet, I've thrown out some half-baked ideas.
318 2013-02-27 14:58:49 <petertodd> I don't mean "officially proposed"; I mean, what I've proposed with fidelity-foo's is at this point a half-baked idea too.
319 2013-02-27 14:59:58 <TD> i've proposed a floating block size limit before, i think
320 2013-02-27 15:00:03 <TD> i don't remember the first time
321 2013-02-27 15:00:08 <TD> probably ages ago
322 2013-02-27 15:00:24 <petertodd> Regardless of exactly who, it is an idea that comes up over and over again.
323 2013-02-27 15:00:57 <TD> petertodd: so, to put it bluntly, the people who are arguing bitcoin will scale just fine have actually sat down and done maths to show it. the assumptions those calculations are based on are amazingly reasonable, so reasonable they assume virtually no hardware improvements at all, even though those improvements are practically guaranteed
324 2013-02-27 15:00:59 <petertodd> gavinandresen: In any case, you have said you want the mechanism to be automatic however it happens.
325 2013-02-27 15:01:03 <gavinandresen> I still think miners will self-regulate the block size. But we'll see in the next few months, average block size is getting close to 250K. I already see people complaining that low-fee transactions are taking a long time to confirm
326 2013-02-27 15:01:17 <TD> petertodd: your argument that it's not possible isn't based on any actual back-of-the-envelope calculations
327 2013-02-27 15:01:47 <petertodd> TD: But they do assume increased centralization. They also assume, in particularly on the wiki, that you'll no longer be able to run a full validating node behind censorship-resistant web conncections.
328 2013-02-27 15:02:41 <petertodd> gavinandresen: Well, I noticed the conversation on IRC logs with that pool op, and I get the feeling he is right and being a pool up is a hobby thing. That said, fees in USD are up to $2K/day, so...
329 2013-02-27 15:02:58 <TD> no, they make no such assumptions. *you* are the one putting such assumptions into the mouths of people who are arguing bitcoin can scale. i actually assume the number of nodes will continue to grow at the same time that traffic grows
330 2013-02-27 15:03:26 <TD> also, "censorship resistant web connections" can work just fine, assuming the technologies you're using to avoid censorship also scale up and perform well
331 2013-02-27 15:03:27 <gavinandresen> petertodd: what's the typical bandwidth for a censorship-resistant connection?
332 2013-02-27 15:03:27 <petertodd> TD: Well, here is a good one: I'm running an instrumented tor-using node to work out what the existing orphan rate for mining will be.
333 2013-02-27 15:04:04 <TD> so what? i don't care about bitcoin behind tor. seriously! if a government wants to censor bitcoin, the way they are going to do it is by visiting any merchant who is reported to be accepting bitcoins, have some agent offer to buy their wares for bitcoin, and then jail them when they say yes
334 2013-02-27 15:04:19 <TD> trying to screw about with traffic analysis just isn't the right way to ban bitcoin
335 2013-02-27 15:04:42 <gavinandresen> (I agree with TD here, but I'm still curious to know bandwidth of a typical tor circuit)
336 2013-02-27 15:04:42 <petertodd> TD: Right... but, as I've said, with calculations and physical arguments, Moores law isn't likely to keep scaling, and neither will network bandwidth. A really simple argument re: the latter is it doesn't make sense to make more bandwidth to the home than you need for a few multiples of HD video streams, until something else happens. (holodecks?)
337 2013-02-27 15:05:06 <kinlo> isn't the main reason to do bitcoin behind tor to get anonymity about who sends who coins?
338 2013-02-27 15:05:19 <petertodd> TD: Government already has tried doing something very similar with drugs, and it's been a huge failure. Why would Bitcoin be any more vulnerable?
339 2013-02-27 15:05:33 <gmaxwell> ...
340 2013-02-27 15:05:34 <gavinandresen> petertodd: ummm???. you know that lots of people have been wrong for a long time betting against continued technological progress.....
341 2013-02-27 15:05:48 <gmaxwell> petertodd: I agree basically with TD on that particular point. Money is not like drugs.
342 2013-02-27 15:05:54 <petertodd> gavinandresen: I've done some direct experiments there, and get ~50KiB/s to 200KiB/second, if you are lucky.
343 2013-02-27 15:06:08 <TD> petertodd: number of cores is still increasingly pretty happily year over year
344 2013-02-27 15:06:31 <petertodd> gavinandresen: Sort of. An interesting one is clock speeds: the ability to per form a single-threaded task fast hasn't actually increased for about a decade now.
345 2013-02-27 15:06:37 <TD> petertodd: as has ops per core, actually, though not as dramatically as it once did. i mean the latest chips coming out of intel are still faster than previous chips, even though it got hard to scale clock speeds up years ago
346 2013-02-27 15:06:43 <gmaxwell> Unlawful drugs still get you high (or whatever they're supposted to do) even if no one elses uses them. Money gets its value from being easily tradable and widely accepted. Making a money like thing unlawful is much more disruptive than drugs. (Likewise: an illicitly copied movie still is fun to watch)
347 2013-02-27 15:06:43 <TD> it has, actually
348 2013-02-27 15:07:41 <petertodd> gmaxwell: It's a good argument, money doesn't have it as easily as drugs, but equally then look at another example, countries where using anything but the official currency is verboten. Again, black market currencies get used widely anyway.
349 2013-02-27 15:07:41 <TD> clock speeds stayed similar but better features on the chip (smarter branch predictors etc) have managed to keep actual performance growing quite nicely. regardless, for bitcoin, it parallelizes perfectly so it's really cores that we care about
350 2013-02-27 15:08:07 <gavinandresen> 50KiB/s would be something like 20 transactions per second, or 3x current block size, today. Current estimates are bandwidth increasing at 50% per year....
351 2013-02-27 15:08:25 <petertodd> TD: Only to the extent that it turned out that many tasks were semi-parallizable. That's why those mechanisms don't scale anywhere near as well as over all transistors.
352 2013-02-27 15:09:00 <petertodd> gavinandresen: But that's it, what's the physical basis for bandwitth cost increasing? Like it or not, you hit physcial limits.
353 2013-02-27 15:09:01 <TD> but we're not talking about computation in general. we're talking about bitcoin specifically, which can saturate as many cores as you give it when it has enough traffic.
354 2013-02-27 15:09:19 <TD> we're nowhere near hitting physical limits on bandwidth
355 2013-02-27 15:09:26 <TD> the bottleneck on bandwidth today is routing speed
356 2013-02-27 15:09:34 <TD> and sometimes crappy last-mile wires
357 2013-02-27 15:09:35 <gavinandresen> 50KiB/s is awfully small??? you could bloom filter N tor connections to parallelize bandwidth, right?
358 2013-02-27 15:09:46 <petertodd> TD: Yes, and as I argued quite clearly, the cost of those cores isn't going to keep going down without a different way of scaling transistors.
359 2013-02-27 15:10:05 <gmaxwell> petertodd: In any case, good technical robustness discourages silly extralegal fun and games. An unfriendly regualtor might ask their partners in industry to voluntarily block it, creating huge disruption. Without actually going through the legal process which actually respects people's rights. So being technically robust is still good even if I don't buy the idea that you can actually be blocking immune.
360 2013-02-27 15:10:14 <gavinandresen> ??? and that's not even considering some type of censorship-resistant read-only broadcast mesh network thingie.....
361 2013-02-27 15:10:23 <petertodd> gavinandresen: Yes, fraud proofs is the really big thing that makes it possible - then mining headers only is pretty safe while still providing real security.
362 2013-02-27 15:10:45 <gavinandresen> ??? maybe jgarzik will broadcast the chain from one of his spaceships....
363 2013-02-27 15:10:52 <SomeoneWeird> lol
364 2013-02-27 15:10:54 <petertodd> gmaxwell: Yes. 51% attacks are a really good example. Sure in theory anyone with money can launch one, but the fact that you have is proven.
365 2013-02-27 15:11:25 <TD> if the world runs out of CPUs and can't run bitcoin anymore, i will one day owe you a big frothing beer
366 2013-02-27 15:11:27 <petertodd> gmaxwell: Centralizaiton on the other hand... you just find big pools, with their large datacenters, and pressure them into only accepting certain transactions bit by bit.
367 2013-02-27 15:11:35 <petertodd> TD: Good, because it will.
368 2013-02-27 15:12:16 <TD> ok :)
369 2013-02-27 15:12:59 <petertodd> TD: I think I've said it before it: I work as an analog elecronics designer, and that field *has* hit physical limits for a broad swath of techniques. It's why my designs have 10 year old parts in them.
370 2013-02-27 15:13:12 <petertodd> (or even 40 year old parts...)
371 2013-02-27 15:13:44 <gmaxwell> petertodd: lies. You just want an excuse to play with liquid helium.
372 2013-02-27 15:13:46 <petertodd> Recently I was consulting a textbook written in tesla's time, and the information in it was still up to date for the *hardware*
373 2013-02-27 15:14:03 <petertodd> gmaxwell: I'm sitting next to ~100 litres of it right now. :P
374 2013-02-27 15:14:40 <petertodd> gmaxwell: ...and speaking of, my morning coffee is done, so back to the soldering iron...
375 2013-02-27 15:18:12 <TD> ACTION afk meeting
376 2013-02-27 15:18:31 <gavinandresen> Never sure how to respond to emails like this: "Does bitcoin, need someone to represent in Central Florida" ....
377 2013-02-27 15:20:24 <monkeynipples> gavinandresen: "Sure, why not"
378 2013-02-27 15:20:56 <gavinandresen> monkeynipples: lol, my actual response was "Probably. Sure! Go for it!"
379 2013-02-27 15:21:12 <monkeynipples> nicely done :D
380 2013-02-27 15:22:23 <jgarzik> gavinandresen: 3000 BTC and I'll broadcast the blockchain from space
381 2013-02-27 15:22:27 <gmaxwell> gavinandresen: at least we're not getting unsolicited resumes yet.
382 2013-02-27 15:22:39 <gavinandresen> I should have told him or her that they were now the Official Central Florida Bitcoin Representative. And sent a video of the secret handshake and Official Silly Walk.
383 2013-02-27 15:22:39 <jgarzik> gmaxwell: who is this "we" to which you refer? :)
384 2013-02-27 15:23:05 <gmaxwell> jgarzik: people who's email addresses are on bitcoin.org and end up in those CC lists ??? or are you getting them?
385 2013-02-27 15:23:33 <jgarzik> gmaxwell: definitely have received a few resumes during my tenure on the bitcoin.org posterboard
386 2013-02-27 15:23:47 <jgarzik> gmaxwell: "I want to work for your Bitcoin corporation" etc.
387 2013-02-27 15:24:07 <jgarzik> gmaxwell: and a few emails assuming I am bitcoin-rich, and need a new investment target
388 2013-02-27 15:24:23 <sipa> i liked this mail:
389 2013-02-27 15:24:25 <sipa> I read some information about bitcoin, said to close the Currency, is that true?
390 2013-02-27 15:25:18 <gmaxwell> jgarzik: yea, I got my first of those recently (actually due to people looking at large txn on blockchain.info though).
391 2013-02-27 15:25:19 <jgarzik> gavinandresen: Demand an initiation rite of some sort, like a video of new recruits drinking alpaca pee
392 2013-02-27 15:25:30 <sipa> petertodd: do you have anything against a rule: increase max once to X, after that, increase slowly exponentially
393 2013-02-27 15:25:37 <jgarzik> (c.f. people making Nigerian scammers post pictures of themselves doing silly things)
394 2013-02-27 15:26:00 <abracadabra> hmm
395 2013-02-27 15:26:09 <abracadabra> would the video also have to show the collection of said pee?
396 2013-02-27 15:26:24 <abracadabra> someone could fake it with just yellow water
397 2013-02-27 15:26:31 <abracadabra> unless alpaca pee is not yellow
398 2013-02-27 15:26:34 <gmaxwell> sipa: he will. I do too I think. But petertodd will because his opinion of continued growth in computing resources is very pessimistic.
399 2013-02-27 15:26:43 <abracadabra> would have to do some reasearch on the subject i guess
400 2013-02-27 15:27:07 <sipa> gmaxwell: and you because?
401 2013-02-27 15:27:46 <jgarzik> <petertodd> gavinandresen: Well, I noticed the conversation on IRC logs with that pool op, and I get the feeling he is right and being a pool up is a hobby thing. That said, fees in USD are up to $2K/day, so...
402 2013-02-27 15:27:52 <gmaxwell> sipa: only because I don't think we can pick the right exponent in advance (not as pessimistic as petertodd, but setting the parameter is hard)
403 2013-02-27 15:27:57 <jgarzik> fees for any one pool surely are not $2K/day
404 2013-02-27 15:28:04 <gmaxwell> sipa: I suppose I could be convinced along the lines of increase once, slowly continue to increase if and only if the difficulty increases faster.. for some definition of faster.
405 2013-02-27 15:28:07 <jgarzik> petertodd: ^
406 2013-02-27 15:29:04 <phantomcircuit> gmaxwell, as long as the verification process is largely concurrent there is likely to be continued growth in the average nodes available computing resources
407 2013-02-27 15:29:10 <phantomcircuit> if it's not then it's unlikely
408 2013-02-27 15:29:18 <phantomcircuit> but it largely is now
409 2013-02-27 15:30:14 <gmaxwell> phantomcircuit: what you are saying is not inconsistent with the position I just took.
410 2013-02-27 15:30:43 <phantomcircuit> gmaxwell, i was mostly commenting on
411 2013-02-27 15:30:44 <phantomcircuit> <gmaxwell> sipa: he will. I do too I think. But petertodd will because his opinion of continued growth in computing resources is very pessimistic.
412 2013-02-27 15:31:12 <gmaxwell> Continued growth doesn't say how much, and a small error in the exponent makes it get out of wack quickly. I offered my unfortunately complicated alternative, becuase if moores law holds difficulty will increase too. And so we could use that to constrain an exponent error from getting out of hand.
413 2013-02-27 15:31:30 <sipa> gmaxwell: where is your proposal?
414 2013-02-27 15:31:46 <gmaxwell> phantomcircuit: petertodd's argument there is very physical and has to do with heat dissapation being perportional to surface area, while potential computation is proportional to volume.
415 2013-02-27 15:33:22 <gmaxwell> sipa: I was referring to what I just said on IRC??? slow growth of the maximum, bounded to be less than (by some factor?) the difficulty growth. I did also mention this on bitcoin talk, but it was completely ignored in the flood of half crazy stuff. (block fee variance capping?!)
416 2013-02-27 15:33:43 <BlueMatt> gmaxwell: wait, bitcoin is taking resumes now??? one sec lemme dig mine up
417 2013-02-27 15:34:39 <gmaxwell> BlueMatt: what you do is hash it, and make that a hash locked transaction. If someone spends it??? then they needed exactly your skills, and you're hired.
418 2013-02-27 15:34:40 <gavinandresen> gmaxwell: I went looking for estimates of bandwidth growth rate yesterday, and looks like it's about 50%/yr right now: http://www.nngroup.com/articles/nielsens-law-of-internet-bandwidth/
419 2013-02-27 15:35:00 <jgarzik> as predicted, the blocksize discussion becomes "how can we fundamentally change bitcoin (the way I think it should have always worked)?"
420 2013-02-27 15:35:06 <jgarzik> due to hard fork necessity
421 2013-02-27 15:35:16 <gavinandresen> gmaxwell: ??? since moore's law for CPU is 50%/yr, bandwidth will bottleneck assuming trends continue
422 2013-02-27 15:35:21 <BlueMatt> gmaxwell: lol, ok
423 2013-02-27 15:35:24 <gavinandresen> ^50^60
424 2013-02-27 15:35:49 <jgarzik> bandwidth and the speed of light will bottleneck before cpu/disk
425 2013-02-27 15:35:51 <phantomcircuit> gmaxwell, hmm linking transaction count to mining power is an interesting idea
426 2013-02-27 15:35:56 <jgarzik> and general network latency
427 2013-02-27 15:36:05 <gmaxwell> gavinandresen: http://download.broadband.gov/plan/fcc-omnibus-broadband-initiative-%28obi%29-technical-paper-broadband-performance.pdf Page 4.
428 2013-02-27 15:36:08 <gmaxwell> "Since 1997, consumer-purchased broadband connection speeds have doubled roughly every four years, with advertised fixed broadband download speeds growing at a 20% annual rate"
429 2013-02-27 15:36:45 <gavinandresen> ? how does doubling every 4 years and 20% annual rate make sense?
430 2013-02-27 15:37:04 <gmaxwell> gavinandresen: though all these figures are fuzzy... switch speed is mostly bounded by memory density and power usage. But because networks are fixed infrastructures they have a fair amount of inertia that slows them down.
431 2013-02-27 15:37:31 <gmaxwell> gavinandresen: 1.2^4 ~= 2.
432 2013-02-27 15:38:45 <gmaxwell> All bandwidth usage figures are also somewhat distorted by changing usage. E.g. the introduction of video streaming justifies a higher growth than what the technology gave you for free, 'cause adding the new service has a better return than just adding more of the old service.
433 2013-02-27 15:40:25 <gavinandresen> okey dokey. I calculate my wimpy DSL connection could, today, easily keep up with 10MB blocks. I'm still really curious to see what happens to average block size when we hit 250K/block (we're not there yet: http://blockchain.info/charts/avg-block-size )
434 2013-02-27 15:41:41 <gmaxwell> Well, all exponential scaling laws are good news if they're true. 20% is slower than 50%.. but they'll both become enormous changes in time.
435 2013-02-27 15:41:57 <gavinandresen> sure??? and this isn't a suicide pact, right?
436 2013-02-27 15:42:54 <gavinandresen> ??? if the future versions of us decide that X% was too high or too low, and it is really obvious they are right, then it can be changed. (I assume we'll all be retired and living on jeff's spaceships or something)
437 2013-02-27 15:43:18 <gmaxwell> As you see, there is a pretty substantial resistance to change. :)
438 2013-02-27 15:43:54 <gmaxwell> Sure??? my only concern is that it not get ahead of whats 'comfortable'. Keep up with isn't quite the right criteria, I think??? the criteria is keep up with without it being a decision you have to weigh heavily. Maybe being able to handle it at all on a smaller link is a good proxy for that? Not sure.
439 2013-02-27 15:44:35 <gavinandresen> how small? running a fully validating node behind one slow tor link seems like the wrong criteria.
440 2013-02-27 15:45:57 <gmaxwell> I am unsure. I mean, if it's "you have to give up privacy to validate bitcoin" then that isn't good... though that isn't implied by that as you could always get the blocks non-tor. Tor actually has pretty great throughput in any case, just cruddy latency.
441 2013-02-27 15:47:02 <gavinandresen> mmm. block size doesn't matter if it is a latency issue.
442 2013-02-27 15:47:33 <gmaxwell> Well, of course it matters at some point as you run out of bandwidth??? but adding tor to the question is irrelevant I think.
443 2013-02-27 15:47:57 <sipa> it's all about how easy it is to get into each of these successive groups: 1) be an SPV node and make transactions 2) be a fully validating node 3) be a miner
444 2013-02-27 15:48:21 <sipa> in the absolute worst case scenario with infinity block sizes, everyone is in 1), and almost nobody is in 2 or 3
445 2013-02-27 15:48:53 <gmaxwell> with infinte block sizes you can't be spv either, well, you can but you can't validate transactions. :P
446 2013-02-27 15:48:55 <sipa> in the absolute worst case scenario with very limit block sizes, everyone is in 2 and 3, and nobody is in 1
447 2013-02-27 15:48:59 <gmaxwell> (I mean not even your own)
448 2013-02-27 15:49:28 <sipa> bandwidth concerns probably make the disctinction between who can get into 2 or 3
449 2013-02-27 15:49:40 <jgarzik> pretty much
450 2013-02-27 15:50:14 <gavinandresen> bandwidth and latency, if you had 10-minute latency you wouldn't be a very successful miner.
451 2013-02-27 15:50:34 <sipa> gavinandresen: indeed
452 2013-02-27 15:51:09 <gmaxwell> sipa: how much do you think that fraud proofs play into this thinking? Today I can construct a compact proof that a block is invalid because it doublespends an input (it's just two spv fragements). With a minor protocol modification we could construct compact proofs that a miner has taken excess subsidy. This makes the trust model much stronger in a world where most nodes are (1).
453 2013-02-27 15:51:13 <gavinandresen> I'm going to regret this???. but I did some relevant back-of-the-envelope calculations that are almost certainly very wrong: https://gist.github.com/gavinandresen/5044482
454 2013-02-27 15:52:07 <sipa> gmaxwell: right, "herd immunity" - not doing any validation or trusting the one you get the information from, but trust that you'd from those who do validation
455 2013-02-27 15:52:25 <sipa> which is pretty much the security model for the software itself
456 2013-02-27 15:52:35 <gmaxwell> Indeed. Most people aren't reviewing the code.
457 2013-02-27 15:55:01 <gavinandresen> gmaxwell: I really like the idea of extending the protocol to broadcast negative proofs.
458 2013-02-27 15:55:09 <gmaxwell> sipa: Its interesting to contemplate what the security of bitcoin would be if there was only one miner but he could never fork and would not DOS (but might attack in other ways). I think it is no less secure in that model if everyone is spv, so long as there are fraud proofs for every rule.
459 2013-02-27 15:56:44 <gmaxwell> gavinandresen: I have a partial implementation of a hardforking subsidy proof now (I changed the hash tree to accomidate it, but I don't act on the proofs yet). I need to add support for it to bitcoinj/multibit so I can actually demo it.
460 2013-02-27 15:56:56 <jgarzik> heh, herd immunity
461 2013-02-27 15:58:35 <jgarzik> gavinandresen: RE costs... there is a cost to a miner, maintaining their own bitcoind / alt client with special rules, versus staying with the herd
462 2013-02-27 15:58:55 <jgarzik> gavinandresen: thus at present, the two paths of least resistance are stick-with-inhouse-version or use-upstream-latest
463 2013-02-27 15:59:02 <gmaxwell> even more powerful, in that it's a communicable immune system. You become immune to a bad block once only one peer anywhere in the world catches it, so long as there is an honest path between you and them.
464 2013-02-27 15:59:22 <jgarzik> Therefore, miners have increased costs for anything the stock client does not make easy to do
465 2013-02-27 15:59:36 <jgarzik> There are many variables to bother reasoning about
466 2013-02-27 15:59:41 <jgarzik> er
467 2013-02-27 15:59:45 <jgarzik> There are too many variables to bother reasoning about
468 2013-02-27 15:59:52 <jgarzik> (to a rational miner today)
469 2013-02-27 16:00:21 <jgarzik> Very few, worryingly few miners seem to take an active interest in network policy
470 2013-02-27 16:00:28 <jgarzik> or making a market
471 2013-02-27 16:00:45 <gmaxwell> including it being rational to take zero fee txn from earnest new users in order to encourage bitcoin adoption...
472 2013-02-27 16:01:07 <jgarzik> [tycho] has said as much (and I agree)
473 2013-02-27 16:01:13 <gmaxwell> jgarzik: I like to point out that after p2sh took effect 50BTC (now the ~largest pool) produced invalid blocks for about a month.
474 2013-02-27 16:01:47 <jgarzik> most core network functions -- including pool operation -- is not really sustainable beyond hobby level yet
475 2013-02-27 16:01:52 <gavinandresen> So what do we think we'll see when the 250K/block soft limit is hit?
476 2013-02-27 16:02:24 <QM> just wanted to mention while lurking that people behind Tor could do partial validation and help with broadcasting fraud proofs, if bandwidth becomes restrictive for them. That way they're not being left out completely.
477 2013-02-27 16:02:25 <TD> BlueMatt: re your comment, why would it make a difference? it's just not deleting data.
478 2013-02-27 16:02:29 <gavinandresen> ??? I predict most miners will be too lazy to build bigger blocks, but if transaction fees rise high enough (I have no idea how high "high enough" is) then they will get less lazy.
479 2013-02-27 16:02:50 <jgarzik> ATM, most miners will follow upstream, as long as upstream is reasonable
480 2013-02-27 16:03:04 <jgarzik> (or stick with current, broken, older version)
481 2013-02-27 16:03:10 <jgarzik> FSVO $current
482 2013-02-27 16:03:15 <TD> hmm
483 2013-02-27 16:03:21 <gmaxwell> QM: yea, if we implement the fraud proof stuff??? it's not entirely clear. Some of it will need disruptive protocol changes and all of it is somewhat risky because it's tricky code that will never get executed except by tests.
484 2013-02-27 16:03:41 <gavinandresen> Default behavior of 'upstream' is something else we could debate; I'd be tempted to leave it at "soft default 250K blocks" forever.
485 2013-02-27 16:03:42 <gmaxwell> jgarzik: we have a switch, swtting that isn't hard.
486 2013-02-27 16:04:26 <jgarzik> gmaxwell: debateable FAVO "lazy"
487 2013-02-27 16:04:30 <gmaxwell> gavinandresen: I think upstreams value should be the smallest value that people might leave alone. Setting it to something tiny and having them always adjust it is, meh. might as well make it 0. :)
488 2013-02-27 16:05:25 <gavinandresen> zero is too small??? leaving it at 250K because that's the way it has been "forever" should give a certain set of people the warm fuzzies.
489 2013-02-27 16:05:30 <gmaxwell> gavinandresen: well, if your calculations are correct (I haven't read past the beginning) then people shouldn't increase it unless the 250th KB transaction has a fee of 25 cents.
490 2013-02-27 16:05:36 <jgarzik> Upstream should be reasonable for a miner to immediately deploy -- that creates the most positive, self-reinforcing behavior
491 2013-02-27 16:05:49 <gavinandresen> gmaxwell: 0.25 cents (0.0025 dollars)
492 2013-02-27 16:05:56 <BlueMatt> TD: I think in some cases it does (some of the coding was lazy and just assumed it would be headers-only) in any case it breaks the api if it does so (why not just a block.isHeader() ? block : block.cloneAsHeader())
493 2013-02-27 16:06:02 <gmaxwell> I must be vzn today.
494 2013-02-27 16:06:06 <jgarzik> tangent
495 2013-02-27 16:06:15 <jgarzik> nobody complained when I posted about raising fees on dust
496 2013-02-27 16:06:17 <BlueMatt> TD: means less thought required and the same optimization result :)
497 2013-02-27 16:06:55 <sipa> gmaxwell: i actually like the fraud proof idea a lot... it means i'd also feel more confortable with a 'only validate 10% of transactions' setting or so
498 2013-02-27 16:07:43 <gmaxwell> speaking of dust... is there any philosophical opposition to autosweeping up dust inputs? The txout set is bloating fast and I think we could stem the bleeding some if the default wallet behavior agressively tried to pull in tiny outputs.
499 2013-02-27 16:08:00 <TD> BlueMatt: there is no isHeader :)
500 2013-02-27 16:08:08 <TD> but yes, ok, i'll see about fixing it
501 2013-02-27 16:08:09 <gavinandresen> gmaxwell: no philosophical opposition from me.
502 2013-02-27 16:08:13 <BlueMatt> TD: well, isnt it block.transaction == null
503 2013-02-27 16:08:58 <TD> ok
504 2013-02-27 16:08:59 <gavinandresen> I'd like to get the payment protocol done and implemented, convince SatoshiDice to switch to it, and make dust outputs non-standard.
505 2013-02-27 16:09:29 <TD> BlueMatt: that fixes a unit test i broke without realizing, too :)
506 2013-02-27 16:09:33 <gmaxwell> I suspect the order of those operations is permuted a bit. (they won't even deploy compressed pubkeys)
507 2013-02-27 16:09:39 <gavinandresen> Or maybe make dust ouputs non-standard and then convince SD to switch....
508 2013-02-27 16:09:41 <TD> gavinandresen: satoshidice may be hard to convince, but you might have more heft than me
509 2013-02-27 16:09:46 <jgarzik> gmaxwell: I think the forum could use someone posting graphs and numbers about dust
510 2013-02-27 16:09:52 <BlueMatt> TD: heh, ok well atleast there was a unit-test for it
511 2013-02-27 16:10:04 <jgarzik> gmaxwell: right now it's just a couple devs yapping, maybe they are just odd ducks
512 2013-02-27 16:10:17 <BlueMatt> TD: well, if they're non-standard and the dust outputs never get confirmed....
513 2013-02-27 16:10:24 <BlueMatt> (btw, why are dust outputs not yet non-standard?
514 2013-02-27 16:10:36 <gmaxwell> BlueMatt: because the definition of dust is hard.
515 2013-02-27 16:10:46 <TD> gavinandresen: then they'll just use "whatever the smallest output allowed" is. i think we put way too much random stuff into IsStandard. I'd rather we just allow zero-valued outputs that are marked for immediate pruning
516 2013-02-27 16:10:53 <BlueMatt> dust == whatever sd currently pays for its dust outputs ;)
517 2013-02-27 16:11:10 <TD> gavinandresen: in fact, if you use petertodds patch for making insta-pruned outputs, SD can change their code to use zero-valued outputs for messaging
518 2013-02-27 16:11:15 <gmaxwell> The best definition I have is "so small they'd never be economically rational to include in your txn" ... but that presumes knowing what future fees would look like.
519 2013-02-27 16:11:17 <gavinandresen> TD: even better idea
520 2013-02-27 16:11:45 <gmaxwell> it's not a better idea... a pruned txn still has perpetual cost!
521 2013-02-27 16:11:46 <TD> gavinandresen: which of course is still lame, but it's just one tweak to their code. the only issue would be, thanks to IsStandard, those transactions wouldn't propagate :(
522 2013-02-27 16:11:47 <jgarzik> I was surprised SatoshiDICE did not object to
523 2013-02-27 16:11:51 <jgarzik> (dated Dec 12, 2012)
524 2013-02-27 16:11:53 <gavinandresen> RE: peter's idea for immediately pruned outputs: allow OP_INVALID followed by some-reasonable-amount-of-arbitrary-data ?
525 2013-02-27 16:11:57 <jgarzik> RFC: Updating dust output definition, and default fees
526 2013-02-27 16:11:58 <jgarzik> https://bitcointalk.org/index.php?topic=130450.0
527 2013-02-27 16:12:03 <jgarzik> https://github.com/bitcoin/bitcoin/pull/2100
528 2013-02-27 16:12:17 <TD> gavinandresen: why not OP_RETURN? just because it gives you heebie-jeebies? i can't say i'm wild about abusing invalid opcodes
529 2013-02-27 16:12:52 <gmaxwell> Certantly a pruned output is signficantly better than an unpruned one... if you want to enable messaging, enable relaying some kind of txn that will never get mined.
530 2013-02-27 16:12:57 <gavinandresen> TD: because it would be really easy for somebody to think that scriptSig == OP_1, scriptPubKey = OP_RETURN ??? should be valid?
531 2013-02-27 16:13:02 <gmaxwell> At least then its not a perpetual cost.
532 2013-02-27 16:13:14 <jgarzik> On dust: making it non-standard would be nice
533 2013-02-27 16:13:17 <jgarzik> or at least cost more
534 2013-02-27 16:13:30 <jgarzik> I don't object to SD in general... just the losing bets being dust-spam
535 2013-02-27 16:13:39 <gavinandresen> agreed
536 2013-02-27 16:13:45 <gmaxwell> jgarzik: the litecoin people are using a rule where the fee is multiplied by the jaggedness of coins as they've had big problems with dust.
537 2013-02-27 16:14:27 <jgarzik> <EVorhees> Roughly 3/4 of SD transactions are financial transactions, and 1/4 is "information".
538 2013-02-27 16:14:29 <sipa> gavinandresen: OP_RETURN is implemented a direct 'return false;' in EvalScript... hard to feel more safe about it
539 2013-02-27 16:14:32 <TD> gavinandresen: people who don't understand script but are still making custom non-standard transactions probably aren't going to be stopped by something like that
540 2013-02-27 16:14:35 <jgarzik> ACTION cheers that he finally admitted it
541 2013-02-27 16:14:44 <gavinandresen> TD: ??? and why do you say using OP_INVALID for a "can never be valid scriptPubKey" is abuse?
542 2013-02-27 16:15:02 <gavinandresen> ACTION wonders what else OP_INVALID might be for....
543 2013-02-27 16:15:02 <TD> there is no OP_INVALID.
544 2013-02-27 16:15:07 <gmaxwell> jgarzik: I'm not fine with the txn inefficient behavior funded by clueless users more generally. (the dust isn't the only part of it, though its clearly the worst).. though I consider it all mostly self correcting.
545 2013-02-27 16:15:11 <gavinandresen> 0xff is OP_INVALID
546 2013-02-27 16:15:17 <gavinandresen> (if I recall correctly)
547 2013-02-27 16:15:21 <TD> https://en.bitcoin.it/wiki/Script
548 2013-02-27 16:15:39 <TD> oh you mean OP_INVALIDOPCODE
549 2013-02-27 16:15:54 <jgarzik> gmaxwell: Well, losing bets cost SD (though certainly users fund SD)
550 2013-02-27 16:16:02 <jgarzik> Consider if dust fee was 1.0 BTC
551 2013-02-27 16:16:05 <gavinandresen> sorry, yes, OP_INVALIDOPCODE
552 2013-02-27 16:16:07 <gavinandresen> https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L250
553 2013-02-27 16:16:10 <jgarzik> at some point it's fine, cost-wise
554 2013-02-27 16:16:14 <TD> it'd be weird for accepted behavior to rely on "invalid opcodes" when OP_RETURN is exactly the semantics required
555 2013-02-27 16:16:50 <jgarzik> at a high fee cost, the behavior is accepted while also incentivizing alt-solutions
556 2013-02-27 16:17:53 <gmaxwell> jgarzik: then you keep crazy messaging behaviors that result in perpetual storage, but just ones where they pay a 1 BTC fee and produce 255 1e-8 outputs which is then backed up by rightious "I paid for my messaging, you don't get to complain"
557 2013-02-27 16:18:08 <gmaxwell> so, meh. Better than doing nothing.
558 2013-02-27 16:18:42 <gmaxwell> I'd favor something more like: estimate the rational fees/byte and don't relay or mine txn which create outputs which would not be rational to redeem.
559 2013-02-27 16:18:54 <TD> gmaxwell: it's a pragmatic approach. the payment protocol gives them exactly what they need. however, deployment won't be overnight by any means
560 2013-02-27 16:19:02 <TD> gmaxwell: heck deployment of a new addition to IsStandard will take ages too
561 2013-02-27 16:19:25 <TD> doing both seems rational
562 2013-02-27 16:19:32 <gmaxwell> TD: AFAIK they're totally uninterested in a payment protocol, so the deployment time of that is moot.
563 2013-02-27 16:19:43 <sipa> the real solution to dust is incorporating UTXO set size changes into priority calculations, and then adapting coin selection to optimize for that
564 2013-02-27 16:19:46 <gavinandresen> TD: I suppose I'd feel less heebie-jeebie-ish about using OP_RETURN if we renamed OP_RETURN OP_RETURN_0
565 2013-02-27 16:20:11 <petertodd> For the record, my proposal isn't to make OP_INVALID <data> IsStandard() or anything, I just want to define the right way for things like P2Pool and what not to create data outputs and make them non-prunable; basically I expect only a few miners to allow such monsters at all.
566 2013-02-27 16:20:18 <jgarzik> sipa: that solution is still cleaning up users, on behalf of a spammy upstream transaction output provider
567 2013-02-27 16:20:22 <gmaxwell> sipa: I'd suggested just making the priority purely utxo based, as a simplest possible change.
568 2013-02-27 16:20:30 <jgarzik> sipa: it's an after-the-fact cleanup solution for bad behavior
569 2013-02-27 16:20:40 <TD> there are a bunch of uses for zero-valued outputs
570 2013-02-27 16:21:00 <petertodd> Basically, P2Pool doesn't have a choice, they have to use invalid outputs for technical reasons, so what's the best way to do that?
571 2013-02-27 16:21:01 <TD> gavinandresen: ok
572 2013-02-27 16:21:13 <gmaxwell> well, a bunch of parasitic uses that potentially devaule bitcoin as a currency...
573 2013-02-27 16:21:14 <TD> gavinandresen: i guess so. i mean, existing software will still render something appropriate and can be updated later.
574 2013-02-27 16:21:18 <gavinandresen> I like the idea of an IsStandard, immediately-prunable, zero-value scriptPubKey
575 2013-02-27 16:21:21 <petertodd> (back to work...)
576 2013-02-27 16:21:33 <jgarzik> petertodd: p2pool creates coinbase, no way to stuff it in there?
577 2013-02-27 16:21:54 <gavinandresen> I also like gmaxwell's idea of a will-never-be-mined broadcast message, if we can figure out how to make it immune from spam
578 2013-02-27 16:22:14 <gavinandresen> (err, how to make it impossible to USE to spam)
579 2013-02-27 16:22:26 <TD> you mean like the old pubsub system?
580 2013-02-27 16:22:30 <gmaxwell> gavinandresen: I'm fine with the idea of the instant prunable outputs, but it is _not_ good to use that for messaging. Because the data still has perpetual lifetime, it's just not perpetual lifetime in the most expensive possible storage.
581 2013-02-27 16:22:46 <TD> gmaxwell: nobody disagrees there. hence the payment protocol
582 2013-02-27 16:23:03 <sipa> anyway, i have no problem with adding a check in CScript::IsGuaranteedInvalid(), and use that to instant-prune newly added outputs
583 2013-02-27 16:23:04 <gmaxwell> TD: ::nods:: I'm just harping because it got brought up for messaging purposes here.
584 2013-02-27 16:23:07 <gavinandresen> payment protocol doesn't have the privacy that a satoshidice user might want, though
585 2013-02-27 16:23:13 <forrestv> jgarzik, having the data at the end of the transaction is useful because you can use midstate compression instead of knowing the entire transaction
586 2013-02-27 16:23:25 <TD> in the context of "until they're using the real solution this is slightly better than the current abuse"
587 2013-02-27 16:23:27 <TD> gavinandresen: how so?
588 2013-02-27 16:23:44 <gmaxwell> sipa: in theory we could just go ahead and implement ... they're already unspendable.
589 2013-02-27 16:23:52 <gmaxwell> (we'd reject any chain that spent them)
590 2013-02-27 16:24:05 <gavinandresen> TD: to get the "you lost" message, you need to connect directly to SD's web server, giving up your IP address (assuming you're not a geek and use tor)
591 2013-02-27 16:24:34 <gavinandresen> (speaking of which??? writing that code is next on my TODO list)
592 2013-02-27 16:24:59 <TD> gavinandresen: *shrug* their IPs probably appear on blockchain too. i'm all for easy to use tor integration in clients ....
593 2013-02-27 16:25:02 <gmaxwell> ^ and if they were willing to do that, they could just operatre like ragecoin... and only make two txn per payment session. They don't need a payment protocol, they need a webpage. But they have one but choose not to use it for this.
594 2013-02-27 16:26:02 <gmaxwell> TD: blockchain has a direct interface to SD transactions ... when I looked before about 1/3rd of sd transactions were created from there, and that hides the ip. :P
595 2013-02-27 16:26:06 <sipa> gmaxwell: exactly
596 2013-02-27 16:26:30 <TD> gavinandresen: which code?
597 2013-02-27 16:26:34 <TD> gavinandresen: uploading payments
598 2013-02-27 16:26:37 <TD> ?
599 2013-02-27 16:26:53 <sipa> gmaxwell: the discussion is more about which such rule would be standard
600 2013-02-27 16:27:09 <gavinandresen> TD: actually, fetching a payment request from a bitcoin:????request=http??? URI, and then submitting a Payment message to a webserver
601 2013-02-27 16:27:15 <TD> cool
602 2013-02-27 16:27:30 <sipa> is there a way to recognize p2pool's unspendable outputs?
603 2013-02-27 16:27:52 <sipa> (the current ones, not to add that as a special rule)
604 2013-02-27 16:28:09 <gmaxwell> p2pools outputs are spendable right now.
605 2013-02-27 16:28:20 <TD> by who?
606 2013-02-27 16:28:22 <gmaxwell> and a couple times people have groomed some of them.
607 2013-02-27 16:28:23 <gmaxwell> anyone.
608 2013-02-27 16:28:27 <sipa> gmaxwell: in theory or in practice?
609 2013-02-27 16:28:29 <sipa> oh
610 2013-02-27 16:28:37 <TD> they're 1satoshi outputs?
611 2013-02-27 16:28:42 <gmaxwell> they're anyone can spend zero value outputs.
612 2013-02-27 16:28:45 <TD> oh
613 2013-02-27 16:28:56 <TD> forrestv: wanna fix that?
614 2013-02-27 16:29:00 <TD> gmaxwell: well, that's easy to fix then
615 2013-02-27 16:29:17 <forrestv> they're just a constant. if a rule is added to bitcoin to discard outputs, i'll make p2pool take advantage of it
616 2013-02-27 16:29:19 <TD> gmaxwell: p2pool starts using the new standard insta-prune format, then somebody just makes a tx that deletes all the old ones
617 2013-02-27 16:29:22 <TD> cool
618 2013-02-27 16:29:27 <sipa> forrestv: ok, great
619 2013-02-27 16:29:32 <gmaxwell> it doesn't need to be standard.
620 2013-02-27 16:29:44 <gmaxwell> (er, do you mean IsStandard?)
621 2013-02-27 16:30:06 <sipa> i'm in favor of limiting the number of "guaranteed unspendable" rules
622 2013-02-27 16:30:18 <sipa> or people might expect logic to work in the generic case
623 2013-02-27 16:30:30 <gmaxwell> well, both the return and the invalid are already '"guaranteed unspendable" rules' but I see your argument.
624 2013-02-27 16:30:59 <gmaxwell> limiting "guaranteed unspendable" that will be autopruned to prevent the assumption that all "guaranteed unspendable" rules are autopruned.
625 2013-02-27 16:31:18 <sipa> gmaxwell: indeed
626 2013-02-27 16:31:21 <TD> gmaxwell: i meant in that sentence "standard as in universally agreed"
627 2013-02-27 16:32:12 <gmaxwell> I don't know how to decide it. I have a mild preference for OP_RETURN but I don't believe that there is any real hard argument to be made.
628 2013-02-27 16:32:27 <sipa> indeed
629 2013-02-27 16:32:42 <sipa> both have exactly the same implemented semantics
630 2013-02-27 16:32:49 <sipa> i don't care either way
631 2013-02-27 16:33:21 <petertodd> alright, I'm voting for op_return, because we might want to use the invalid opcodes for other things via my "check_script_version" mechanism I proposed (or similar)
632 2013-02-27 16:33:31 <gmaxwell> maybe we should stage a big dramatic argument over it so that it will take the place of the dramatic argument over things that matter? :P
633 2013-02-27 16:33:32 <petertodd> sipa is right
634 2013-02-27 16:33:34 <BlueMatt> ACTION votes OP_RETURN is cleaner
635 2013-02-27 16:33:34 <gavinandresen> TD seems to care, so we should make it OP_RETURN.
636 2013-02-27 16:34:02 <gmaxwell> Luke-Jr: you're prone to caring about minutia, do you have an opinion here?
637 2013-02-27 16:34:03 <gavinandresen> I'll suppress my OCD and won't insist on renaming it OP_RETURN_0, gotta save those keystrokes....
638 2013-02-27 16:34:25 <gavinandresen> How big are the p2pool 0-value outputs?
639 2013-02-27 16:34:35 <gmaxwell> to be clear, I understand this as "the script begins with OP_RETURN with nothing before it"
640 2013-02-27 16:34:41 <sipa> gmaxwell: indeed
641 2013-02-27 16:34:47 <petertodd> gmaxwell: yup
642 2013-02-27 16:34:58 <gavinandresen> ??? if we do an IsStandard OP_RETURN <push some number of bytes of data> how big should some number be?
643 2013-02-27 16:34:58 <gmaxwell> does this actually work for the p2pool case?
644 2013-02-27 16:35:23 <gavinandresen> (I know p2pool doesn't need them to be IsStandard....)
645 2013-02-27 16:35:28 <petertodd> gavinandresen: big enough to fit a fidelity bonded tx? :P
646 2013-02-27 16:35:30 <BlueMatt> gavinandresen: there is already a limit
647 2013-02-27 16:35:40 <BlueMatt> gavinandresen: dont remember it though...2XX bytes?
648 2013-02-27 16:35:43 <petertodd> gavinandresen: I think jgarzik's arguments were fine before
649 2013-02-27 16:35:54 <sipa> gavinandresen: in the case of a provably-and-by-standard-autoprunable output, the template doesn't matter at all - just limit the size of the script
650 2013-02-27 16:35:58 <gmaxwell> gavinandresen: 20 bytes. But! I reeeeellly don't think we should do that, instead we should IsStandard something that won't get mined.
651 2013-02-27 16:36:27 <BlueMatt> 520 bytes is current maximum
652 2013-02-27 16:37:17 <gmaxwell> yea, as sipa says, ignore the template the criteria should be the size, and it shouldn't be longer than a hash, because thats all you could get throw the dumb way. And pratically all use cases that are sane just need to commit a hash.
653 2013-02-27 16:37:40 <gmaxwell> Also, a txn shouldn't by IsStandard if it has a bunch of those outputs. Only one(?) per tx.
654 2013-02-27 16:38:01 <BlueMatt> gmaxwell: I agree with the non-mining of txn like this, though
655 2013-02-27 16:38:10 <BlueMatt> gmaxwell: and, yes, no more than a hash seems sane
656 2013-02-27 16:38:15 <gmaxwell> keeping in mind: prunable still means perpetual storage... just not perpetual fast storage.
657 2013-02-27 16:39:05 <petertodd> BlueMatt: there is no limit on scriptPubKey size other than the blocksize limit, there is a limit on the size of a script that gets executed, and that's 10,000 bytes
658 2013-02-27 16:39:07 <gavinandresen> ok, no consensus on IsStandard. y'all go figure out how to broadcast a not-minable transaction without making it possible to spam the network, then....
659 2013-02-27 16:39:32 <BlueMatt> petertodd: there is a limit of 520 bytes of any individual push in a script
660 2013-02-27 16:39:34 <petertodd> BlueMatt: I inserted a bunch of just under 1MB tx's on testnet...
661 2013-02-27 16:39:49 <BlueMatt> you can push as many of those 520-byte blocks as you want
662 2013-02-27 16:39:54 <petertodd> BlueMatt: Only if the script is executed
663 2013-02-27 16:40:04 <BlueMatt> ahh, yes, thats right
664 2013-02-27 16:40:16 <BlueMatt> anyway....even 520 seems overkill if you're encoding random data
665 2013-02-27 16:40:41 <sipa> more than 32 bytes makes no sense
666 2013-02-27 16:40:42 <petertodd> gavinandresen: You can always require a PoW with the same algorithm as the bitcoin PoW whose difficulty is related to the block reward...
667 2013-02-27 16:41:00 <sipa> as that gives you a hash with the highest security level we have anywhere
668 2013-02-27 16:41:17 <gmaxwell> gavinandresen: lol, well I can give you one. Just allow a non-final txn with its nlock time set maximally far in the future. Then your ability to send is limited by the number of spendable coins you have. :P
669 2013-02-27 16:41:25 <jgarzik> I wish there was a viable merge-mined alt-chain
670 2013-02-27 16:41:28 <petertodd> sipa: I agree, fidelity bonded tx sacrifices can be done with a separate rule that actually checks the data is a valid tx, or just rely on sending the publish tx to eligus...
671 2013-02-27 16:41:38 <jgarzik> maybe I need to start "tempcoin", with coins that expire after 12 months if unspent
672 2013-02-27 16:41:48 <jgarzik> an alt-chain testnet
673 2013-02-27 16:42:02 <gmaxwell> jgarzik: I think the discussion here indicated that it should be named SCAMCOIN.
674 2013-02-27 16:42:20 <gmaxwell> (this being the hypothetical testnet altchain that has all the science project expirements in it)
675 2013-02-27 16:43:08 <helo> macscoin?
676 2013-02-27 16:43:27 <sipa> lotsocoin
677 2013-02-27 16:43:29 <jgarzik> gmaxwell: <shrug> well without an alternate outlet, people will keep dumping info into the main chain
678 2013-02-27 16:43:43 <jgarzik> ACTION always wanted a data chain
679 2013-02-27 16:43:45 <gavinandresen> gmaxwell: limited by number of spendable coins: good idea, except there might be a chicken-and-egg problem of incentivizing dust spam before the network switches to rejecting it
680 2013-02-27 16:43:57 <gmaxwell> jgarzik: alternatives exist now, people don't use them. Go use namecoin??? it has key value pair things that expire.
681 2013-02-27 16:44:25 <helo> it's hard to get data worth as much as a bitcoin uxto
682 2013-02-27 16:44:35 <helo> utxo
683 2013-02-27 16:45:03 <jgarzik> gmaxwell: namecoin is already worthless
684 2013-02-27 16:45:15 <gmaxwell> gavinandresen: yea, didn't say it was a great idea. Another possiblity is to just ratelimit. And then if it gets spammed 'oh well'.
685 2013-02-27 16:45:26 <gmaxwell> jgarzik: mostly due to a lack of non-spamming incentives.
686 2013-02-27 16:45:29 <jgarzik> and they actively discourage use as a general timestamping service
687 2013-02-27 16:45:51 <gmaxwell> jgarzik: they do? huh? You sure about that?
688 2013-02-27 16:46:06 <gmaxwell> though, if you just want timestamping that should be done O(1) style.
689 2013-02-27 16:46:43 <gmaxwell> But, really, no one cares about timestamping. Otherwise someone would be running chronobit.
690 2013-02-27 16:49:12 <gmaxwell> gavinandresen: I guess the thing to do would be to have a rate limit per unspent txin with the limit proportional to value.
691 2013-02-27 16:49:22 <gmaxwell> gavinandresen: thus there is no dust creation incentive.
692 2013-02-27 16:49:32 <gmaxwell> And no checking for double spends on those special txn, I guess.
693 2013-02-27 16:50:06 <gavinandresen> gmaxwell: sounds reasonable, can you write it up?
694 2013-02-27 16:50:18 <gmaxwell> yes.
695 2013-02-27 16:51:38 <gavinandresen> I think transaction-connected messaging across the p2p network would add a tremendous amount of potential value
696 2013-02-27 16:53:10 <TD> you can already stuff arbitrary data after a tx and it'll be relayed
697 2013-02-27 16:53:15 <TD> nobody uses that feature today, though
698 2013-02-27 16:54:22 <gavinandresen> That's because we haven't done anything spiffy like have the client display pop up a message box if the transaction is to them and the data is provably from the person sending them the transaction
699 2013-02-27 16:54:41 <gmaxwell> it doesn't have that property.
700 2013-02-27 16:54:51 <gmaxwell> (data tacked on the end isn't signed)
701 2013-02-27 16:55:18 <TD> doesn't have what property?
702 2013-02-27 16:55:35 <gmaxwell> "the data is provably from the person sending them the transaction"
703 2013-02-27 16:55:55 <gavinandresen> just arbitrary data tacked on somewhere along the way would be a bad idea, spammers would have a field day
704 2013-02-27 16:55:55 <TD> did anyone claim it did?
705 2013-02-27 16:56:31 <gmaxwell> < TD> nobody uses that feature today, though < gavinandresen> That's because[...] and the data is provably from the person sending them the transaction.
706 2013-02-27 16:56:42 <TD> right, time to head out.
707 2013-02-27 17:04:24 <midnightmagic> jgarzik: It's not worthless yet..
708 2013-02-27 17:12:07 <gmaxwell> I wonder about making the definition of instant prunable be 'zero value'.
709 2013-02-27 17:30:41 <gmaxwell> gavinandresen: https://en.bitcoin.it/wiki/User:Gmaxwell/mtx a very rough sketch
710 2013-02-27 17:32:25 <gavinandresen> gmaxwell: cool. I'll start thinking about whether or not that can replace the Payment Protocol Payment/PaymentACK mechanism
711 2013-02-27 18:03:59 <BlueMatt> gmaxwell: hey, you guys finally did a xiph episode 2, nice!
712 2013-02-27 18:07:27 <gmaxwell> BlueMatt: Yea. (http://xiph.org/video/vid2.shtml for those who haven't seen it)
713 2013-02-27 18:15:03 <Luke-Jr> gmaxwell: I think scriptPubKey[0] == OP_RETURN sounds great
714 2013-02-27 18:36:57 <grau> I was asking the bitcoin foundation for non-monetary support of my work and it was turned down. I am curious why.
715 2013-02-27 18:37:34 <gmaxwell> grau: what did you ask for?
716 2013-02-27 18:40:44 <grau> "I ask primarily for non-monetary support for this project. Please provide your opinion and guidance for testing and once this is deemed production quality provide the sufficient publicity for it. "
717 2013-02-27 18:41:19 <grau> alternatives are not wanted
718 2013-02-27 18:41:22 <grau> seemingly
719 2013-02-27 18:41:26 <grau> fuck
720 2013-02-27 18:41:32 <petertodd> grau: It's a grant process - it's for money, not other stuff.
721 2013-02-27 18:41:50 <grau> publicity is worth money
722 2013-02-27 18:41:58 <grau> but costs nothing to them
723 2013-02-27 18:42:17 <gmaxwell> petertodd: even a grant process that gives out non-monetary things needs a concrete proposal. Can't great unspecified benefits. :)
724 2013-02-27 18:42:28 <HM> Don't sweat it dude, if you make something awesome people will hear about it
725 2013-02-27 18:42:29 <gmaxwell> s/great/grant/
726 2013-02-27 18:42:32 <petertodd> I dunno, publicity is cheap with the forums, we're a small community.
727 2013-02-27 18:44:42 <grau> If the problem was that it was not specific, then they might have asked what exactly I would want. I just got a note from Lindsay not more than : "I'm sorry to let you know that your grant request for a bitcoin protocol targeted to merchants was not awarded. Thank you for the effort you put into your proposal and for your interest in improving and promoting bitcoin."
728 2013-02-27 18:45:07 <gmaxwell> hm.
729 2013-02-27 18:45:18 <gmaxwell> grau: it certantly does cost something to them though??? e.g. if your project goes poorly it would hurt their credibility. (Not that I think yours is likely to)
730 2013-02-27 18:46:33 <grau> read again what I asked : " Please provide your opinion and guidance for testing and once this is deemed production quality provide the sufficient publicity for it. "
731 2013-02-27 18:47:33 <gmaxwell> ::nods::
732 2013-02-27 18:48:08 <grau> I am done with them. Happy for not being a "lifetime member"
733 2013-02-27 18:49:50 <gavinandresen> grau: who is "them" ?
734 2013-02-27 18:50:19 <grau> I guess one is you
735 2013-02-27 18:50:31 <HM> what you working on grau?
736 2013-02-27 18:50:43 <gavinandresen> mmm. Yeah, I'm pretty busy changing the tires of the reference implementation car as we careen down the road at 100 miles an hour
737 2013-02-27 18:51:27 <grau> Since I started working I get nothing but heat and mock. Although I belive contributing value
738 2013-02-27 18:51:30 <gavinandresen> I voted "discuss" on your grant proposal, and after discussion the Board didn't see a credible way we could commit to "providing guidance" because we're all crazy busy with what we're doing already
739 2013-02-27 18:53:03 <grau> HM: https://github.com/bitsofproof/supernode/wiki
740 2013-02-27 18:55:20 <grau> gavinandresen: I believe you are busy, me too. If the proposal was not specific or actionable, you could have said that. Not to be rejected.
741 2013-02-27 18:56:00 <gavinandresen> give Lindsay a bit of a break, she's crazy busy too and has to send out 20 grant proposal "sorry" letters
742 2013-02-27 18:56:58 <grau> ok, I cool down.
743 2013-02-27 18:57:35 <gavinandresen> thanks. If you have constructive ideas for how we can do things better next time around???.
744 2013-02-27 18:59:20 <HM> std::system_error is quite a thing
745 2013-02-27 18:59:59 <HM> convert errno to an exception... std::system_error(errno, std::system_category()); ...verbosity -_-
746 2013-02-27 19:15:33 <Luke-Jr> jgarzik: how big (filesize) is the Avalon firmware you were sent? can you get a lsmod of it?
747 2013-02-27 20:16:55 <cjd> Hi guys, I see the bitcoin foundation is accepting btc donations, last I recall there was some concern about 501c3's accepting btc, does anyone know if things were clarified or what doctrine the foundation is operating under?
748 2013-02-27 20:41:47 <gmaxwell> foundation isn't a 501c3, fwiw.
749 2013-02-27 20:42:23 <BTCTrader2> nonprofit wikipedia chapters accept bitcoins
750 2013-02-27 20:44:32 <etotheipi_> if you install bitcoin-qt from the Ubuntu PPA, does it put bitcoind on your system?
751 2013-02-27 20:44:46 <etotheipi_> I couldn't find it, and not sure how to check
752 2013-02-27 20:51:29 <etotheipi_> if not, can I lobby to have it included by default?
753 2013-02-27 20:51:45 <grau> sipa: have a question on BIP38
754 2013-02-27 20:51:59 <gmaxwell> etotheipi_: if it doesn't it's broken, but I'm pretty sure it does.
755 2013-02-27 20:52:56 <gmaxwell> Did BIP_0038 ever get discussed anywhere or is another one of the only-Casascius bips?
756 2013-02-27 20:53:08 <grau> sipa: I think the case deriving public from public has a typo since it says Kn is equal to IL*Kpar. but Kn is a point not a number
757 2013-02-27 20:53:16 <grau> gmaxwell: sorry BIP32
758 2013-02-27 20:53:23 <grau> I work on that now.
759 2013-02-27 20:54:05 <grau> I implemented BIP38 BTW I think it is handy to store private key in database since WIF is unsecure
760 2013-02-27 20:56:40 <jouke> etotheipi_: "whereis bitcoind" Does that tell you where it is?
761 2013-02-27 20:57:37 <grau> etotheipi: I installed the package longer ago it put it into /usr/bin/bitcoind
762 2013-02-27 20:58:44 <etotheipi_> jouke: why did I not know about the "whereis" command? thanks
763 2013-02-27 20:59:11 <etotheipi_> I wonder why I have copies in /usr/bin/X11
764 2013-02-27 20:59:48 <etotheipi_> it's shown up in different places for me
765 2013-02-27 21:00:05 <etotheipi_> /usr/lib/bitcoin, /usr/bin, now /usr/lib/X11
766 2013-02-27 21:00:13 <etotheipi_> but last time I installed I didn't see it at all
767 2013-02-27 21:07:00 <jouke> etotheipi_: while working with your offline wallet construction, you have to transfer the transaction by USB to the cold wallet for signing right? Is that transaction in the same format as how one would build a transaction with the raw transaction api of bitcoind?
768 2013-02-27 21:07:15 <etotheipi_> jouke: no
769 2013-02-27 21:07:31 <etotheipi_> it is https://en.bitcoin.it/wiki/BIP_0010
770 2013-02-27 21:07:57 <etotheipi_> it includes not only the transaction to be signed, but also every supporting transaction supplying inputs to it, so the offline computer can reliably compute the tx fee
771 2013-02-27 21:08:28 <jouke> Ah. Hmmm, interesting.
772 2013-02-27 21:08:35 <jouke> Thanks, I know enough for now :)
773 2013-02-27 21:09:14 <etotheipi_> thank/blame gmaxwell for that :) he's the one that convinced me it was worth "bloating" that format to avoid the "attacker can send all your funds to tx fee" attack
774 2013-02-27 21:09:52 <jouke> Well, "attacker", or some noob transaction-maker like me that just screws it up ;)
775 2013-02-27 21:10:30 <etotheipi_> in reality, it was a good idea, but it pains me to see potentially 100 kB of supporting tx getting tacked on just so the offlien computer can verify 8 bytes
776 2013-02-27 21:13:51 <jouke> Yeah, you can hardly fit it on a floppy that way.
777 2013-02-27 21:17:05 <BlueMatt> etotheipi_: it doesnt
778 2013-02-27 21:17:08 <BlueMatt> its a separate package
779 2013-02-27 21:17:33 <BlueMatt> (the bitcoind package vs bitcoin-qt)
780 2013-02-27 21:18:11 <BlueMatt> (and the bitcoind package also installs a wrapper which creates a bitcoin.conf with a random rpcpassword, though tbh that should probably have been removed...it was in debian and i just copied it
781 2013-02-27 21:18:58 <BlueMatt> so which should give you a wrapper
782 2013-02-27 21:20:42 <grau> sipa: regarding BIP32, no problem there, just took time for me to digest the notation.