1 2014-01-10 00:00:03 <saizai> is there some way I can identify which of the payments to 1EVJyd8TbHBMUiMn6ogQ1PXbqoEZVp31Hz (if any) were made *not* using bitpay?
2 2014-01-10 00:00:55 <gmaxwell> saizai: subpoena bitpay.
3 2014-01-10 00:00:58 <saizai> ACTION does not have subpoena powa
4 2014-01-10 00:01:06 <saizai> short of that.
5 2014-01-10 00:02:01 <gmaxwell> I'm not aware of any technial measure. Ask the owner of that key to please tell you kindly?
6 2014-01-10 00:02:11 <saizai> I'd like to be able to point to something and say "look this probably didn't go through https://stockman2014.com/bitcoin-donation but instead from someone who saw http://www.businessinsider.com/steve-stockman-is-accepting-bitcoins-2014-1 or http://www.reddit.com/r/Bitcoin/comments/1u53yf/congressman_steve_stockman_accepting_btc_at/ "
7 2014-01-10 00:02:36 <saizai> which in turn'd mean he got btc that wasn't identified
8 2014-01-10 00:02:49 <saizai> which is illegal
9 2014-01-10 00:02:56 <saizai> and would be a useful example for me to point to about how you can't prevent someone from sending you bitcoin anonymously
10 2014-01-10 00:03:13 <saizai> ⦠especially if you pose for a photo op w/ a giant bitcoin QR on you
11 2014-01-10 00:03:47 <justanotheruser> Does bitpay pay USD->BTC or just BTC->USD?
12 2014-01-10 00:04:35 <saizai> not sure
13 2014-01-10 00:05:22 <pigeons> they only process bitcoin payments from the end user. they dont process usd payments
14 2014-01-10 00:05:38 <gmaxwell> saizai: certantly you can just ignore payments you weren't expecting.
15 2014-01-10 00:13:12 <saizai_> bah, shitty connection
16 2014-01-10 00:13:14 <saizai_> gmaxwell: not under FEC law.
17 2014-01-10 00:13:25 <saizai_> PACs can't possess bitcoins they don't have donor info for
18 2014-01-10 00:13:36 <saizai_> and have to get rid of such things w/in a small number of days
19 2014-01-10 00:14:52 <gmaxwell> saizai_: who says they possess it if they'll never spend it? I suppose the obvious thing to do if you're workeed about 'possess' is to just instantly convert any unexpected payments to fees.
20 2014-01-10 00:24:36 <saizai_> gmaxwell: actually that'd be doubly illegal
21 2014-01-10 00:24:50 <saizai_> that'd be an expenditure to anonymous third party
22 2014-01-10 00:24:52 <saizai_> by a PAC
23 2014-01-10 00:24:57 <saizai_> so not ok.
24 2014-01-10 00:25:06 <saizai_> anyway I'll come back when I'm on a stable connection
25 2014-01-10 00:25:09 <saizai_> this uplink sucks.
26 2014-01-10 00:25:40 <saizai_> but yeah, I'd appreciate if anyone could lmk if any of those transactions to 1EVJyd8TbHBMUiMn6ogQ1PXbqoEZVp31Hz could be shown to not be via bitpay without having to subpoena them
27 2014-01-10 00:25:54 <saizai_> (I did send them a nice email asking if they'd mind confirming, but they may not respond)
28 2014-01-10 01:25:20 <justanotheruser> Why does the scripts page say the standard tx script is scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG, shouldn't it be scriptPubKey: OP_DUP OP_HASH160 <pubKey> OP_EQUALVERIFY OP_CHECKSIG?
29 2014-01-10 01:26:16 <gmaxwell> because it's the pubkeyhash that is in the pay-to-pubkey hash transaction.
30 2014-01-10 01:26:22 <gmaxwell> the pubkey is in the scriptSig
31 2014-01-10 01:27:47 <justanotheruser> gmaxwell: but it doesn't become the pubkeyhash until OP_HASH160 is run, does it?
32 2014-01-10 01:27:54 <gmaxwell> so the stack sequence is sig pubkey->dup-> sig pubkey pubkey -> hash160-> sig pubkey pubkeyhash -> equalverify -> sig pubkey -> checksig
33 2014-01-10 01:28:16 <gmaxwell> justanotheruser: the value in the scriptPubkey is what its getting compared to
34 2014-01-10 01:28:23 <gmaxwell> imagine the stack machine operating in your head.
35 2014-01-10 01:28:47 <phantomcircuit> gmaxwell, i've found very few people can think that way
36 2014-01-10 01:28:54 <phantomcircuit> no offense to you justanotheruser
37 2014-01-10 01:29:03 <phantomcircuit> but you might be better off with pen/paper
38 2014-01-10 01:30:02 <justanotheruser> gmaxwell: so is the scriptsig automatically loaded into the stack?
39 2014-01-10 01:30:10 <justanotheruser> scriptSig: <sig> <pubKey>
40 2014-01-10 01:30:42 <gmaxwell> yes, you can imagine it evaluating ScriptSig | ScriptPubKey as if they were just concatinated.
41 2014-01-10 01:31:00 <gmaxwell> (thats originally how it was implemented too, but that resulted in some ... unfortunate ... behavior)
42 2014-01-10 01:31:25 <justanotheruser> wait, why would the two items be concatonated?
43 2014-01-10 01:31:52 <gmaxwell> justanotheruser: scriptSig is pushing things onto the stack.
44 2014-01-10 01:32:07 <gmaxwell> scriptSig: contains PUSH(sig) PUSH(pubKey)
45 2014-01-10 01:33:13 <justanotheruser> gmaxwell: is scriptsig the only way to push stuff onto the stack?
46 2014-01-10 01:33:30 <gmaxwell> justanotheruser: no the pubkey pushes things onto the stack too.
47 2014-01-10 01:33:35 <tiyoT> quick question, is there a software/api/protocol exist out there that can trigger something when particular btc address (eg our own) receive payment. Eg, tell my website php script to add +100gil to User1 when my btc address receive 0.1 btc.
48 2014-01-10 01:33:58 <gmaxwell> justanotheruser: e.g. in your example pubKeyHash is getting pushed onto the stack.
49 2014-01-10 01:33:59 <justanotheruser> gmaxwell: so the purpose of scriptsig is to push stuff onto the stack without modifying the transaction that is signed, no?
50 2014-01-10 01:34:05 <jakov> tiyoT you can poll something on blockchain.info
51 2014-01-10 01:34:17 <jakov> but better / more elegant would be to run bitcoind
52 2014-01-10 01:35:26 <gmaxwell> justanotheruser: You can think of a transaction input as having a single script that must evaluate to true. The script is formed as "ScriptSig | ScriptPubKey". the latter is provided by the coin being spent, the former by the spending transaction.
53 2014-01-10 01:36:09 <gmaxwell> justanotheruser: the normal usage has the scriptSig push 'stuff' onto the stack, which then code in the scriptpubkey checks and accepts if and only if it likes it.
54 2014-01-10 01:37:13 <tiyoT> jakov: bitcoind only allow as relay right? it didnt have the authority to spend the bitcoin etc... just to watch for activity, when it happen, it relay to the php script in my website
55 2014-01-10 01:37:38 <justanotheruser> gmaxwell: that is pretty elegant
56 2014-01-10 01:38:02 <jakov> tiyoT provided the private keys were not on your server nobody would be able to spend from those addresses
57 2014-01-10 01:38:11 <gmaxwell> justanotheruser: it's been slightly broken in bitcoin because uh there was an opcode that was basically return true; ... (OP_RETURN) ... and someone realized you could put it in scriptSig ...
58 2014-01-10 01:38:19 <jakov> bitcoind would be a node and watch as transactions are broadcast
59 2014-01-10 01:38:43 <tiyoT> ok, so i need to find coder that are verse in bitcoind
60 2014-01-10 01:38:53 <tiyoT> jakov: whats your coding background?
61 2014-01-10 01:39:29 <jakov> im not available for employment if thats what you're offering
62 2014-01-10 01:39:30 <justanotheruser> gmaxwell: Can't you have a non-empty stack and a tx evaluate to true without OP_RETURN? Or is the problem not the stack being non-empty?
63 2014-01-10 01:40:06 <jakov> too busy : )
64 2014-01-10 01:40:26 <jakov> you could try /r/jobs4bitcoin or the bitcointalk forum or around the irc
65 2014-01-10 01:40:29 <gmaxwell> justanotheruser: It prevented the scriptPubkey from ever running. Normally, e.g. in a pay-to-hash160 transaction there are *VERIFY opcodes which will abort execution if the spend isn't authorized.
66 2014-01-10 01:42:25 <justanotheruser> gmaxwell: but if you make a transaction with OP_RETURN you don't have to do any verification. I don't understand the problem?
67 2014-01-10 01:43:25 <gmaxwell> justanotheruser: I'm saying the scriptSig could contain it.
68 2014-01-10 01:43:38 <tiyoT> jakov: perhaps you can recommend me some names .. ?
69 2014-01-10 01:44:00 <gmaxwell> justanotheruser: so you have a txout with scripPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG and then someone comes along and signs for it with .. OP_RETURN
70 2014-01-10 01:44:18 <jakov> tiyoT i dont know im afraid, i actually havent been around here that long
71 2014-01-10 01:44:29 <gmaxwell> so then the composite script is OP_RETURN OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG which evaluated to true and the spend was permitted.
72 2014-01-10 01:44:45 <jakov> best of luck finding someone, i dont think it should be a problem since bitcoin is swarming with techie coders
73 2014-01-10 01:44:52 <justanotheruser> oh, so you have an exception for OP_RETURN? Like OP_RETURN can't be in the scriptsig or something?
74 2014-01-10 01:46:15 <gmaxwell> justanotheruser: well so OP_RETURN was changed to return false; and then the script execution was split so that ScriptSig executes and then ScriptPubKey executes with the stack carried across.
75 2014-01-10 01:48:28 <justanotheruser> gmaxwell: Why do you say "it's been slightly broken". Isn't it "it was broken"?
76 2014-01-10 01:49:05 <gmaxwell> justanotheruser: I mean we degraded the elegance.
77 2014-01-10 01:51:46 <justanotheruser> gmaxwell: was OP_RETURN ever abused?
78 2014-01-10 01:52:11 <gmaxwell> on testnet
79 2014-01-10 01:52:15 <gmaxwell> never on mainnet
80 2014-01-10 01:53:34 <warren> Never Gonna Give You Up
81 2014-01-10 01:54:03 <gmaxwell> We're not strangers to bugs
82 2014-01-10 01:54:32 <justanotheruser> gmaxwell: was that given an alert for upgrade?
83 2014-01-10 01:55:51 <gmaxwell> Before my time.
84 2014-01-10 02:31:36 <warren> gmaxwell: have you tried to build 0.8 on fedora 20?
85 2014-01-10 02:31:44 <warren> /usr/bin/ld: cannot find -lboost_filesystem-mt
86 2014-01-10 02:32:49 <warren> gmaxwell: oh ... BOOST_LIB_SUFFIX=-mt is no longer needed on Fedora 20
87 2014-01-10 03:34:29 <amincd> Can anyone tell me the current state of adoption of getblocktemplate and explain exactly what it enables? Does it make trust-free pooled mining possible? Does it have any drawbacks?
88 2014-01-10 03:35:43 <Luke-Jr> amincd: from the bitcoin network's perspective, GBT is always "trust-free"; miners know exactly what they're mining at all times
89 2014-01-10 03:36:16 <Luke-Jr> amincd: from the miner's financial perspective, the pool could still possibly rob them. trust-free in this area can be done with stratum or GBT equally well.
90 2014-01-10 03:36:37 <Luke-Jr> so, the benefit of GBT is in bitcoin security, not financial security for the individual miner's earnings
91 2014-01-10 03:36:56 <gmaxwell> Though the miner side to actually do anything useful with the info yielded by GBT is lacking.
92 2014-01-10 03:37:11 <gmaxwell> E.g. they have the information but don't do much of anything useful with it, with existing software.
93 2014-01-10 03:37:38 <gmaxwell> Pool adoption of GBT is not terribly significant.
94 2014-01-10 03:38:32 <Luke-Jr> gmaxwell: it isn't insignificant, either
95 2014-01-10 03:38:40 <Luke-Jr> gmaxwell: also, lechuga__ has been working on the libblkmaker changes needed
96 2014-01-10 03:39:33 <gmaxwell> Luke-Jr: who beyond eligius is offering it?
97 2014-01-10 03:40:18 <Luke-Jr> gmaxwell: https://en.bitcoin.it/wiki/Getblocktemplate#For_miners
98 2014-01-10 03:40:42 <gmaxwell> might want to drop 50btc from there.. :P
99 2014-01-10 03:40:46 <Luke-Jr> <.<
100 2014-01-10 03:40:52 <Luke-Jr> it's just 100% fee!
101 2014-01-10 03:43:04 <gmaxwell> bitarena.net is down, mkalinin.ru is down, the rest add up to about 2% of the network it looks like?
102 2014-01-10 03:43:29 <amincd> Luke-Jr: I'm mostly interested in network security aspect of it
103 2014-01-10 03:43:45 <Luke-Jr> :<
104 2014-01-10 03:44:18 <gmaxwell> amincd: most advanced in terms of network security /right now/ is p2pool.
105 2014-01-10 03:45:11 <wizkid057> doesnt bitminter have GBT?
106 2014-01-10 03:45:33 <wizkid057> and EMC
107 2014-01-10 03:46:10 <gmaxwell> yes, 372TH/s and 274TH/s.
108 2014-01-10 03:46:53 <gmaxwell> okay, which is 4.6% assuming a 14PH/s network so sue me, I didn't actually calculate it before.
109 2014-01-10 03:47:06 <amincd> gmaxwell: I'm familiar with p2pool. It's great but has limitations
110 2014-01-10 03:48:08 <wizkid057> so those two + eligius = 15.7% of a 14Ph network
111 2014-01-10 03:49:37 <gmaxwell> amincd: there is no method of increasing security that doesn't have costs. with normal stratum people are just selling their hashpower to remote miners, they don't have any information about the transactions, they're maximally in the dark. This means they don't need to do much computation, or recieve much data.
112 2014-01-10 03:50:03 <Luke-Jr> gmaxwell: GBT in pool+policyservice is pretty low cost
113 2014-01-10 03:50:31 <wizkid057> I think most miners really care what the transactions are, honestly, nor would most have any way of really checking even with GBT
114 2014-01-10 03:50:49 <wizkid057> *most miners DONT really care
115 2014-01-10 03:50:57 <gmaxwell> wizkid057: they don't have any at all currently, which is what I pointed out above: 19:36 < gmaxwell> Though the miner side to actually do anything useful with the info yielded by GBT is lacking.
116 2014-01-10 03:52:11 <wizkid057> what I'm saying is, what would the average miner do with the data in the first place? the average "modern miner" barely even knows what bitcoin is, let alone have enough knowledge to flag suspicious txns
117 2014-01-10 03:52:23 <gmaxwell> Luke-Jr: e.g. how can you with GBT cope with a situation where pools controlling 75% of the hashpower decide they'd like to inflate the currency by claiming transactions are paying more fees than they really are?
118 2014-01-10 03:52:53 <gmaxwell> wizkid057: the miner, the person wouldn't do squat. The miner _software_ could be checking that the data is consistent with the rules of the network.
119 2014-01-10 03:53:34 <wizkid057> I would assume the network would prevent a block from being utilized that violated network rules in the first place, unless these are new rules outside of that you're referring to
120 2014-01-10 03:54:29 <gmaxwell> wizkid057: 'the network' â most bitcoin users today are not running network nodes, they're using SPV clients, they believe the majority of hashpower almost unconditionally. This is not likely to improve.
121 2014-01-10 03:54:38 <gmaxwell> (and by most users I also mean most businesses)
122 2014-01-10 03:54:53 <Luke-Jr> [03:52:15] <gmaxwell> Luke-Jr: e.g. how can you with GBT cope with a situation where pools controlling 75% of the hashpower decide they'd like to inflate the currency by claiming transactions are paying more fees than they really are? <-- I don't see how that makes any sense
123 2014-01-10 03:55:05 <wizkid057> ^ i didnt understand that either
124 2014-01-10 03:55:28 <Luke-Jr> SPV risks are SPV risks. -.-
125 2014-01-10 03:55:30 <gmaxwell> Luke-Jr: you produce a block with a 1000 btc subsidy. All the SPV nodes will happily believe you.
126 2014-01-10 03:55:43 <Luke-Jr> that's a problem with SPV, not GBT
127 2014-01-10 03:55:48 <wizkid057> if most bitcoin users arent running nodes then we're eventually doomed anyway
128 2014-01-10 03:56:03 <wizkid057> and no amount of GBT-recheck magic will help
129 2014-01-10 03:56:05 <gmaxwell> No, SPV assumes that the majority of hashpower is honest. It's a not unreasonable assumption except when you've moved the majority of hashpower into two parties hands.
130 2014-01-10 03:56:29 <gmaxwell> wizkid057: then you need to start speaking up when gavin and mike are going around saying that there is no reason for people to run nodes.
131 2014-01-10 03:56:59 <gmaxwell> We can't have this situation where one group of people is saying its okay to hand over all the mining control to a few parties because nodes protect the network.
132 2014-01-10 03:57:18 <gmaxwell> And another group of people are going around telling people that it's okay for most parties to be on SPV nodes because miners will protect the network.
133 2014-01-10 03:57:45 <Luke-Jr> in theory, we could propose templates to all pools configured, and only mine ones accepted by the majority
134 2014-01-10 03:58:37 <wizkid057> on a side note, the existing GBT implementation while usable needs an efficiency overhaul
135 2014-01-10 03:58:40 <justanotheruser> gmaxwell: could spv security be breached by the two major pools without a price crash?
136 2014-01-10 03:58:42 <gmaxwell> So the idea of strenghtening mining is to uphold the assumptions needed for SPV to be safe.
137 2014-01-10 03:59:22 <gmaxwell> justanotheruser: today? probably notâ but thats today. Certantly there is no "crash" if its not a surprise.
138 2014-01-10 03:59:23 <wizkid057> someone should mine a block with a 1000 BTC subsidy and see what happens
139 2014-01-10 03:59:29 <wizkid057> :P
140 2014-01-10 03:59:58 <justanotheruser> wizkid057: wouldn't that do nothing? All your peers would reject that block right?
141 2014-01-10 04:00:17 <wizkid057> well, even if the SPV clients accepted it, it wouldnt be useful unless you built 100 blocks on top of it
142 2014-01-10 04:00:19 <gmaxwell> wizkid057: SPV nodes will accept it, full nodes won't, it'll get orphaned today because ~none of the hashpower will accept it (we hope!)
143 2014-01-10 04:01:15 <wizkid057> without huge pools, SPV would be fine in practice
144 2014-01-10 04:01:20 <gmaxwell> yes.
145 2014-01-10 04:01:26 <wizkid057> but theres too much trust in pools
146 2014-01-10 04:01:41 <gmaxwell> And thats the point of making the checking strongerâ to get us closer to the "without huge pools"
147 2014-01-10 04:01:44 <wizkid057> but, decent sized pools are needed
148 2014-01-10 04:02:01 <wizkid057> no one can solo mine anymore, and small pools have insanely high variance with these difficulties
149 2014-01-10 04:02:02 <gmaxwell> wizkid057: you only need decent sized pooling for payments, the pool doesn't need to control the content of the blocks.
150 2014-01-10 04:03:03 <gmaxwell> wizkid057: uh, variance is proportional to share, the absolute difficulty doesn't matter. E.g. a 1% miner has the same variance regardless of the difficulty.
151 2014-01-10 04:03:08 <gmaxwell> (so long as they're 1%)
152 2014-01-10 04:03:37 <wizkid057> i'm just saying, there is no existing mining hardware (single device) anymore that in itself would have reasonable solo mining variance
153 2014-01-10 04:03:42 <wizkid057> so pooling is needed
154 2014-01-10 04:03:56 <wizkid057> (this has been the case for a while)
155 2014-01-10 04:04:39 <wizkid057> also, p2pool isn't scalable up to large percentages of the network in terms of individual miner variance
156 2014-01-10 04:04:46 <wizkid057> so thats not a solution either
157 2014-01-10 04:04:48 <gmaxwell> In any case, pooling to share your income is totally orthogonal to handing over your influence in the network.
158 2014-01-10 04:05:51 <wizkid057> I'm all for a mining situation where miners run full nodes and utilize that data to craft blocks themselves for a pool of miners
159 2014-01-10 04:06:15 <wizkid057> but good luck getting ghash.io or btcguild to implement it
160 2014-01-10 04:06:17 <gmaxwell> wizkid057: I think you're again guilty of commenting on p2pool without a detailed understanding of it, but I don't see any reason to bother arguing it since I wasn't saying anything about p2pool.
161 2014-01-10 04:06:39 <gmaxwell> wizkid057: well, certantly no luck in getting them to do it when no one else does it. :)
162 2014-01-10 04:06:44 <wizkid057> i mentioned p2pool because it is the only existing example that fit your criteria
163 2014-01-10 04:07:08 <gmaxwell> wizkid057: yea but it goes further than strictly needed for the network security stuff, and there is indeed a cost to that.
164 2014-01-10 04:09:04 <wizkid057> from my informal polling it seems that miners in general flock to the larger pools to reduce varaince... any security solution that increases miner earning variance overall is likely to be rejected
165 2014-01-10 04:09:19 <gmaxwell> (the reason I was griping there: p2pool variance for small miners is already highâ but actually wouldn't increase too substantially if it were the size of the whole network. ... but I don't have a simulator for the automatic share difficulty stuff so I don't have concrete numbers)
166 2014-01-10 04:10:11 <gmaxwell> wizkid057: What I get told is that they flock to larger pools to increase income (which isn't true, but they think it to be so).
167 2014-01-10 04:10:20 <wizkid057> well, just in terms of coinbase size alone, lets say all of Eligius started mining p2pool, thats currently 5372 addresses to be paid every block ;)
168 2014-01-10 04:10:27 <gmaxwell> (I mean, this is what people tell me when I ask why they use btcguild instead of eligius)
169 2014-01-10 04:10:46 <gmaxwell> wizkid057: small p2pool users don't get paid every block when p2pool is finding a lot of blocks.
170 2014-01-10 04:11:04 <wizkid057> yeah, i've heard the arguement that people think large pools make more money
171 2014-01-10 04:11:33 <wizkid057> i was even told before that since eligius is ~12% of the network, and btcguild is 25%, the 3% fee doesnt matter because they're still making 10% more than eligius
172 2014-01-10 04:11:39 <wizkid057> (literally lol
173 2014-01-10 04:11:42 <wizkid057> 'd)
174 2014-01-10 04:11:49 <gmaxwell> wizkid057: basically if you're a tiny miner you already don't always have a share in the p2pool window, and so you're not always paid when it finds a block. Which is why increasing p2pools size doesn't make things better or worse for those miners relative to now.
175 2014-01-10 04:12:29 <wizkid057> increasing the size would make the cutoff definition of a "tiny miner" a higher hash rate
176 2014-01-10 04:12:39 <gmaxwell> wizkid057: yea, I've heard exactly that before! ("I make 30x more on BTCguild than I would on p2pool, I can't justify that kind of loss" or something like that)
177 2014-01-10 04:13:33 <gmaxwell> wizkid057: not as much as you think because miners pick adaptive difficulty, the larger miners which constute a lot of the pool set their share difficulty much higher (all automatically).
178 2014-01-10 04:14:06 <gmaxwell> (it increases their share variance some, but since they're large their variance wasn't that great already)
179 2014-01-10 04:15:08 <wizkid057> i'd admittedly have to look into it in detail/simulation/etc... i'm just guessing based on a reasonable number of outputs in a coinbase only so many individuals could make it into a block each time anyway, determined by variance
180 2014-01-10 04:16:39 <gmaxwell> wizkid057: ::nods:: in any case, just assume some people want to true-PPS mine, no decenteralized system can ever do that.
181 2014-01-10 04:16:59 <gmaxwell> But as I said, you could have users generate their own work, paying the PPS pool, and submit it to the pool to be credited for it.
182 2014-01-10 04:17:04 <lechuga__> late to convo but bitminter is also using gbt
183 2014-01-10 04:17:15 <wizkid057> gmaxwell: on a side note, i have notes on trying to make CPPSRB able to be decentralized
184 2014-01-10 04:17:20 <lechuga__> dunno y ghash and btc wouldnt on principal
185 2014-01-10 04:17:49 <gmaxwell> The pool could spotcheck the workâ sure, though maliciously sending bad work is isomorphic to a withholding attack, you'd only bother to spotcheck to catch accidental misconfiguration.
186 2014-01-10 04:17:54 <lechuga__> principle*
187 2014-01-10 04:18:04 <gmaxwell> and then from a network security perspective you'd be as good as no pooling at all.
188 2014-01-10 04:19:23 <gmaxwell> wizkid057: problem with decenteralizing CPPSRB, at least as eligius does it, is that the state required to compute the payments is really large.
189 2014-01-10 04:19:37 <gmaxwell> so its really expensive to make very decenteralized.
190 2014-01-10 04:19:59 <wizkid057> its actually not that large
191 2014-01-10 04:20:09 <wizkid057> the pruned share log is only a couple GB
192 2014-01-10 04:20:27 <wizkid057> and thats ~15 months of data
193 2014-01-10 04:21:00 <gmaxwell> yea, but you're basically in the same order of magnitude as bitcoin itself.. how many shares per second does eligius recieve?
194 2014-01-10 04:21:24 <wizkid057> roughly 20,000 vardiff shares as we speak
195 2014-01-10 04:23:10 <gmaxwell> so if a share is 80+12*32+1000 bytes (header,hashfragments,coinbase txn) 1464 bytes thats 234 mbit/sec of shares needed in order to keep updating payments owed?
196 2014-01-10 04:24:14 <gmaxwell> my p2pool node recieves 16kbit/sec.
197 2014-01-10 04:24:45 <wizkid057> would certainly need some work on the bandwidth efficiency front :)
198 2014-01-10 04:24:59 <wizkid057> Eligius is up to almost 1TB/day in bandwidth usage
199 2014-01-10 04:25:09 <wizkid057> although that includes random DoS attempts
200 2014-01-10 04:26:02 <gmaxwell> I could describe a protocol for securely compressing the old sharelog in a trust free way. .. but the update data is a lot of bandwidth. P2Pool represents one extreme where you cut the bandwidth very low, at the cost of increasing variance, and then everyone can run the payout calculation.
201 2014-01-10 04:26:22 <gmaxwell> but there probably are other ways to navigate the tradeoff.
202 2014-01-10 04:28:42 <wizkid057> whenever I get the time to actually work on it, I'll have to pick your brain :)
203 2014-01-10 04:28:54 <gmaxwell> wizkid057: more obviously you could do something like local work generation, and then get coinbases from some quorum of independant parties that collect shares and run CPPSRB.
204 2014-01-10 04:29:24 <gmaxwell> So you would have centeralization but only for payouts, and it would still be distributed so that 2 of 3 hosts had to be compromised to rip people off.
205 2014-01-10 04:29:43 <gmaxwell> And that would only require ~2x the bandwidth, which could be made up for by just doubling the minimum difficulty.
206 2014-01-10 04:30:41 <Luke-Jr> then you get higher variance -.-
207 2014-01-10 04:31:09 <gmaxwell> Luke-Jr: yea but whoptie do, only a small increase. Besides such a pool should dominate the network, so you get less block variance. :)
208 2014-01-10 05:04:51 <gmaxwell> Luke-Jr: an 80GH/s miner with a diff of 800 will get ~2000 shares per day. At that point, the'd have only a 1% chance of their daily share count being 1897 (94.8%) or less... and a 1% chance of getting less than 13725 (98%) shares in a week.
209 2014-01-10 05:05:44 <Luke-Jr> gmaxwell: I like graphs <.<
210 2014-01-10 05:06:21 <gmaxwell> Luke-Jr: in that brave new world, have miners graphing locally.
211 2014-01-10 05:06:34 <gmaxwell> The p2pool local graphs are pretty nice, fwiw. (and less noisy than the eligius ones)
212 2014-01-10 05:11:41 <gmaxwell> with a diff of 800 eligius would be 4,548 shares per second its current hashrate... and if shares submitted to CPPSRB calculation were 80+12*32+1500 (went and actually looked at a coinbase) that would be 71 mbit/sec... which is a bit more reasonable.
213 2014-01-10 05:14:28 <gmaxwell> and actually if you had a multiparty pool there would be less reason for coinbase payouts. so you could perhaps make that more like 23mbit/sec.
214 2014-01-10 05:15:03 <gmaxwell> so you basically could have three independantly run servers, that take in shares from users and share them, and reach a consensus about payouts, and automatically produce 2-of-3 multisignature payouts from the pools funds.
215 2014-01-10 05:16:03 <gmaxwell> and it would just require three parties each running a sever that could accept in about 23mbit/sec and out put 23mbit/sec.
216 2014-01-10 05:23:19 <phantomcircuit> 1TB/day?
217 2014-01-10 05:23:21 <phantomcircuit> lol
218 2014-01-10 05:23:28 <phantomcircuit> that's crazyness
219 2014-01-10 05:24:12 <phantomcircuit> gmaxwell, i bet if they set the minimum to even like 8 it would have a huge impact
220 2014-01-10 05:25:22 <gmaxwell> phantomcircuit: if the whole pool were 8 it would be 454,814 shares per second, which is substantially greater than wizkid said they had now.
221 2014-01-10 05:26:01 <phantomcircuit> gmaxwell, right but im sure they have a significant contingent of people mining unprofitably on cpus/gpus at very low difficulty
222 2014-01-10 05:26:10 <phantomcircuit> i would assume that is the bulk of the bandwidth
223 2014-01-10 05:26:22 <phantomcircuit> well also and trying to keep cgminer from disconnecting >.>
224 2014-01-10 05:26:50 <phantomcircuit> cgminer, give it a 64 bit search space and it disconnects if you dont ping it every 60 seconds
225 2014-01-10 05:27:35 <phantomcircuit> oh wait no it's 90 seconds
226 2014-01-10 05:29:15 <phantomcircuit> https://github.com/ckolivas/cgminer/blob/master/cgminer.c#L5322
227 2014-01-10 05:38:08 <justusranvier> "We can't have this situation where one group of people is saying its okay to hand over all the mining control to a few parties because nodes protect the network. And another group of people are going around telling people that it's okay for most parties to be on SPV nodes because miners will protect the network."
228 2014-01-10 05:38:19 <justusranvier> Bitcoin: the world's first tautologycoin
229 2014-01-10 05:51:35 <zone117x> justusranvier: hahaha
230 2014-01-10 06:12:02 <zone117x> after reading the comments from the past several hours I realized bitcoin is much less reliable that I used to think. It worries me that an entiy like the NSA could just take over a couple poors and destroy bitcoin. I have a good amount invested in bitcoin and now I'm not very confident about maintaing that capitol
231 2014-01-10 06:12:22 <zone117x> a couple pools***
232 2014-01-10 06:13:25 <Luke-Jr> it is just an experiment after all <.<
233 2014-01-10 06:13:37 <zone117x> I'm a developer and I've put a lot of time into developing for cryptocurrencies, stratum server specifically. and the community has NOT been helpful. the documentation is just terrible as well
234 2014-01-10 06:14:24 <zone117x> as popular as bitcoin is, I was expecting a lot better
235 2014-01-10 06:16:04 <upb> don't maintain that capitol then, maintain a smaller town
236 2014-01-10 06:17:22 <zone117x> bitcoin made me believe it was going to change the world. now I feel like that a naive belief :(
237 2014-01-10 06:17:45 <justanotheruser> zone117x: if the NSA took over the pools, the second they mined a block in a fork, it would be big news and everyone would drop btcguild and ghash
238 2014-01-10 06:17:54 <gmaxwell> Meh, the sausage making is never pretty. Worrying about this stuff is part of the process that addresses the risk.
239 2014-01-10 06:17:56 <justanotheruser> mined a fork from a few blocks back anyways
240 2014-01-10 06:18:15 <Luke-Jr> justanotheruser: unlikely
241 2014-01-10 06:18:39 <Luke-Jr> justanotheruser: half ghash users *can't* drop it
242 2014-01-10 06:19:09 <gmaxwell> yea, NSA is not the interesting threat model most likely in any case, but sure, there are exposures. If there weren't well, I suppose bitcoin would already be trading at $100k ea or whatever craze estimates people like to throw around. :)
243 2014-01-10 06:19:48 <zone117x> are there any cryptocurrencies today that address some of the issues with bitcoin? POS perhaps?
244 2014-01-10 06:20:35 <Luke-Jr> zone117x: no
245 2014-01-10 06:20:54 <justusranvier> PoS is how central banks work
246 2014-01-10 06:21:10 <gmaxwell> No. (in fact the existing PoS thing does something worseâ it gives the single developer the ability to pick the winning chain by announcing signatures... PoS sadly doesn't seem workable as a direct consensus mechnism.)
247 2014-01-10 06:22:58 <zone117x> if the NSA was bent destroying bitcoin what theoretical mechanism could prevent it. and do any cryptocurrencies today implement it?
248 2014-01-10 06:23:08 <justusranvier> PoS is very workable if you're the developer who wants the ability to pick winning chains. Not so much for the users who believe they are getting a decentralized currency.
249 2014-01-10 06:23:09 <Luke-Jr> probably impossible
250 2014-01-10 06:23:13 <Luke-Jr> short of quantum stuff
251 2014-01-10 06:23:41 <zone117x> P.S.: hello NSA agent who happens to be reading through this chat :)
252 2014-01-10 06:23:55 <Luke-Jr> well, you could probably ignore the NSA; they're not the big threat really
253 2014-01-10 06:24:04 <Luke-Jr> but government in general, you cannot really do anything about
254 2014-01-10 06:24:19 <Luke-Jr> spying on bitcoin doesn't get you far (NSA) ;)
255 2014-01-10 06:24:20 <gmaxwell> zone117x: I think you do yourself a great disservice by picking a major state level attacker. A state level attacker wouldn't attack via technical means. They'd make it unlawful and just agressively imprison or kill anyone who used it.
256 2014-01-10 06:24:33 <toffoo> there have been plenty of 51% pool risks before: slush, deepbit, asicminer, btcguild .. now ghash.io, ... and they never last very long, don't know what the big deal is this time.
257 2014-01-10 06:24:55 <Luke-Jr> there is nothing anti-governmental about bitcoin
258 2014-01-10 06:25:06 <toffoo> and lets not forget: it was the last 51% attacked that SAVED bitcoin (the fork event in march!)
259 2014-01-10 06:25:13 <gmaxwell> toffoo: they don't last precisely because people make a fuss, but also, making a fuss about "51%" is foolish.
260 2014-01-10 06:25:15 <Luke-Jr> toffoo: um, no.
261 2014-01-10 06:25:20 <gmaxwell> toffoo: Thats not true.
262 2014-01-10 06:25:20 <warren> toffoo: ghash.io is a substantial institutional miner
263 2014-01-10 06:25:45 <toffoo> well in broad strokes ;D
264 2014-01-10 06:25:53 <Luke-Jr> toffoo: the fork event in march was simply a bug in 0.8.0, no attack of any sort
265 2014-01-10 06:26:01 <gmaxwell> toffoo: without there being >50% of the hashpower then in two miners who'd upgraded inconsistenly with the fast majority of the network there wouldn't have been a march incident.
266 2014-01-10 06:27:01 <gmaxwell> toffoo: the majority of p2pool miners, for example, were <0.8 at the time. What would have happened if the network was well distributed is that that block would have been created and would have been orphaned by the next block and the network would have continued as normal.
267 2014-01-10 06:28:00 <gmaxwell> toffoo: and in any case, ghash.io concerns people more because their hashpower has already been used to double spend against a bitcoin site in the past. (back when they had 25% hashpower)
268 2014-01-10 06:29:14 <toffoo> i predict their hashpower dominance will come to an end sooner rather than later
269 2014-01-10 06:29:40 <gmaxwell> Another amplifier is that at least 45% of ghash.io's hashpower is physically controlled by their sister company, so the old "oh if its abused the hashpower will move elsewhere" argument doesn't hold.
270 2014-01-10 06:30:45 <gmaxwell> toffoo: yes, but if people were not yelling it wouldn't. (though sadly, it might just go away by some pretextual grooming where they "split" up the hashpower they control to hide the consolidation)
271 2014-01-10 06:31:20 <zone117x> my realizations today about the instability of bitcoin are deeply concerning. I am going to bed. perhaps tomorrow I may sell at btc I've held for a couple years :(
272 2014-01-10 06:32:10 <gmaxwell> zone117x: Nothing substantial has changed at least... so if you were okay with it a day ago...
273 2014-01-10 06:32:42 <zone117x> I feel that I was simply naive before
274 2014-01-10 06:35:17 <amincd> What's stopping a bunch of small pools from joining p2pool?
275 2014-01-10 06:35:44 <Luke-Jr> wouldn't be the first proxy-pool
276 2014-01-10 06:36:00 <Luke-Jr> in fact, I think that's actually common with p2pool nowadays
277 2014-01-10 06:36:27 <gmaxwell> amincd: the additional latency is somewhat adverse to your returns.. though thats less bad now that the p2pool sharechain is 30 seconds.
278 2014-01-10 06:38:43 <zone117x> when was the last time satoshi was involved with btc?
279 2014-01-10 06:40:49 <amincd> Luke-Jr, gmaxwell: I see. I figure a p2pool made up of a dozen larger miners, a.k.a. pools, controlling a majority of the network hashrate, would be a better situation than btcguild and ghash.io controlling it
280 2014-01-10 06:41:22 <justanotheruser> amincd: is that enforcable
281 2014-01-10 06:41:33 <justanotheruser> zone117x: I think late 2010
282 2014-01-10 06:41:54 <amincd> justanotheruser: what do you mean by enforcable?
283 2014-01-10 06:41:54 <gmaxwell> I don't see why you think this would be a great thing, how about no big entites controlling it? pooling for payments doesn't have to be related to controlling the network.
284 2014-01-10 06:43:03 <justanotheruser> amincd: you said it would be a better situation. Is there any way to make people do it is what i was asking. I think I was asking a question unrelated to your statement actually
285 2014-01-10 06:45:30 <amincd> justanotheruser: no it's not enforceable. People just have to choose to use it. A large part of it will come down to how user friendly the p2pool software is for pool operators, and the profitability of p2pool mining relative to the competition. gmaxwell mentions that the latency adversely affects returns for example. gmaxwell: of course, ideally no large entities would control it.
286 2014-01-10 07:02:17 <zone117x> can someone speculate why satoshi has not been invovled with btc in the last couple years?
287 2014-01-10 07:03:12 <zone117x> whether he be a governement, school, company, group of people, or just a person.. seems stange to not be involved
288 2014-01-10 07:03:48 <justanotheruser> zone117x: because people want to know who he is and he doesn't want them to know who he is
289 2014-01-10 07:05:07 <Luke-Jr> that begs the question of whether he actually isn't still involved.
290 2014-01-10 07:05:51 <zone117x> is the opinion of the community that he is just a person or an enity with interesting motives?
291 2014-01-10 07:06:16 <Luke-Jr> everyone is different
292 2014-01-10 07:06:31 <Luke-Jr> frankly, a lot of us don't really care :P
293 2014-01-10 07:06:37 <jcorgan> Satoshi is/was a consortium of electric power companies and ASIC foundries that came up with an interesting way to increase revenue :)
294 2014-01-10 07:07:05 <zone117x> jcorgan: ;p hahaha
295 2014-01-10 07:09:36 <gmaxwell> I don't care. I think caring about Satoshi is missing the point of Bitcoin. Bitcoin was created to largely eliminate the need for trust in people. Respect where its due, but Satoshi's greatest accomplishment was that his irrelevanceâ beyond historical interestâ was inherent in the design of Bitcoin.
296 2014-01-10 07:09:55 <amincd> well put gmaxwell
297 2014-01-10 07:10:14 <zone117x> gmaxwell: isnt that ironic given the situation today with pools' power
298 2014-01-10 07:11:00 <gmaxwell> zone117x: well, the situation we have today is just some blend of lazy, ignorant, and inertia. Nothing inherently makes it this way. It can be escaped.
299 2014-01-10 07:11:12 <zone117x> and recent (previously tinfoil-hat-esk) revelations about the power of the governments to control the internet
300 2014-01-10 07:11:32 <gmaxwell> I think if the first pool invented had been P2pool like we might never have had centeralized pools at all (instead we might have many varriations of distributed and decenteralized ones)
301 2014-01-10 07:12:12 <gmaxwell> zone117x: ha funny you say that, since mining is virtually never authetnicated, anyone would could intercept a pools network connectivity (e.g. just a their ISP) could redirect all the hashing power.
302 2014-01-10 07:12:33 <gmaxwell> authenticated* ... thats a point of vulnerability we don't see often discussed.
303 2014-01-10 07:13:29 <zone117x> I'm developing a stratum pool server in node.js. mayble I will become the biggest pool with 51%+ hashing power and destroy btc just for the fun of it :D
304 2014-01-10 07:13:56 <gmaxwell> zone117x: why don't you make a distributed pool?
305 2014-01-10 07:14:48 <zone117x> not clever enough I'm afraid. all I know is existing pool server stack is highly inefficient (php+python & poorly developed too)
306 2014-01-10 07:15:43 <zone117x> how much $ would chinese government pay to control btc???
307 2014-01-10 07:21:15 <amincd> zone117x: I doubt any government would make an overt against BTC
308 2014-01-10 07:21:23 <amincd> *overt move
309 2014-01-10 07:22:02 <zone117x> yea just non-overt. chinese government officials feel free to PM me :D
310 2014-01-10 07:22:21 <zone117x> bid starts 1 btc
311 2014-01-10 07:23:17 <amincd> covert
312 2014-01-10 07:24:11 <jcorgan> i'd assume most govt. officials would act in a way that preserves their power over their citizenry; BTC could either facilitate that or threaten that
313 2014-01-10 07:31:35 <zone117x> the /r/bitcoin community has a good amount of buzz about the ghash pool problem but its not enough. the community doesnt realize it is trivial for the NSA to hijack a couple of people serves to destory btc in the name of anti-terrorism/anti-drug
314 2014-01-10 07:32:20 <zone117x> we need an engineering solution ot a trust solution. I hope the smart people in the community can figure that out before its too late
315 2014-01-10 07:32:38 <gmaxwell> zone117x: we have a technical solution; have for years. P2Pool.
316 2014-01-10 07:32:55 <gmaxwell> zone117x: doesn't overcome ignorant miners who think that they get the most income from the largest pool.
317 2014-01-10 07:33:18 <zone117x> not good enough appearently. its a trust solution because we trust miners to swich to it
318 2014-01-10 07:33:31 <gmaxwell> zone117x: in any case, don't work yourself up too much. Consoidation of hashing power is a concern, but bitcoin doesn't just stop existing because of it.
319 2014-01-10 07:34:52 <gmaxwell> I note that even with all this noise: p2pool's hashrate doesn't appear to have increase in the past day or two.
320 2014-01-10 07:35:38 <zone117x> gmaxwell: but if the general public knew of the real resilience (lack of) of btc in the face of an entity such as NSA then the price would crash
321 2014-01-10 07:36:23 <gmaxwell> zone117x: I answered you before why I think you're completely off the mark.
322 2014-01-10 07:36:46 <gmaxwell> In spite of your concerns the non-technical attacks are just a lot more interesting if you're going to posit the US government as an attacker.
323 2014-01-10 07:36:56 <gmaxwell> And you do not need any specialized technical understanding to understand them.
324 2014-01-10 07:38:05 <zone117x> then anyone invested in btc is lucky that the public is not aware of how easy it is for the US government to kill btc
325 2014-01-10 07:39:35 <gmaxwell> I think you're lacking some perspective. The US government has the power to end human life on earth. Perhaps all life on earth. If investments were not valuable if the US government could destroy them, then no investment should be valuable at all.
326 2014-01-10 07:39:48 <jcorgan> zone117x: i wonder if the US govt. is actually afraid to try, given that bitcoin is a world-wide protocol, and that appearing impotent to control it would leave them worse off
327 2014-01-10 07:41:11 <gmaxwell> The absolute capability doesn't mean that there is a pratical and political capabilitly or that there would be interested in using it if there were none... just like few worry that the government is going to go around with threats of killing everything in order to get what "it" wants. :)
328 2014-01-10 07:42:40 <zone117x> I dont believe btc has reached critical mass for the US government to be afraid of it. they could destory btc and hail it in the media as a win again drugs and terrorism.
329 2014-01-10 07:44:03 <zone117x> if there was anything close to another 9/11 then they could easily slip into the media a line "funded by btc from terrorists" to justify new regulation that effectively destoys btc and gives them back control of wold currency
330 2014-01-10 07:44:29 <gmaxwell> to the extent that that risk exists I think it's likely alread priced in.
331 2014-01-10 07:45:07 <zone117x> only some techies and CEO of overstock.com would complain. rest of the country would be complacent
332 2014-01-10 07:45:53 <jcorgan> and the rest of the world would keep on keeping on
333 2014-01-10 07:46:36 <jcorgan> while lamenting the decreasing irrelevance of that former "beacon of liberty"
334 2014-01-10 07:46:46 <jcorgan> decreasing relevance
335 2014-01-10 07:47:14 <zone117x> believe me, I hope so. I've believed and invested in btc for a long time. I'm just very surprised that its not as resilient as I believed before
336 2014-01-10 07:48:26 <zone117x> perhaps I just need to establish residence in some stable scandinavian country
337 2014-01-10 07:50:00 <jcorgan> i do enjoy traveling to Scandanavian countries, as I find the culture there agreeable, but it's not clear to me that subjecting myself to their politicians is a wise move
338 2014-01-10 08:50:21 <xiangfu> Hi. is there a mailing list for bitcoin developer?
339 2014-01-10 08:51:09 <xiangfu> one people named Ken. ask me help on setup the China local developer group.
340 2014-01-10 08:51:47 <kinlo> xiangfu: http://sourceforge.net/p/bitcoin/mailman/?source=navbar
341 2014-01-10 08:52:10 <xiangfu> kinlo: thanks
342 2014-01-10 08:53:11 <xiangfu> he told me he was from bitcoin fundation. (blanka69@gmail.com)
343 2014-01-10 08:53:23 <kinlo> don't believe what people tell you
344 2014-01-10 08:53:34 <xiangfu> :)
345 2014-01-10 08:54:19 <kinlo> I don't know any ken
346 2014-01-10 08:55:20 <kinlo> I'm not stating that I know everybody inside the foundation, but I doubt that it's real
347 2014-01-10 08:55:36 <michagogo> cloud|Can someone explain what "Development of the Bitcoin" means?
348 2014-01-10 08:56:42 <xiangfu> kinlo: ok. know I ask him a loooot of questions.
349 2014-01-10 08:56:55 <xiangfu> kinlo: he didn't answer me yet.
350 2014-01-10 08:57:18 <xiangfu> ACTION try to find the bitcoin fundation email address. I can send one email there. :)
351 2014-01-10 08:57:42 <michagogo> cloud|(In the topic)
352 2014-01-10 09:52:05 <Bitember-Cray> hey, do you guys know of any gambling scripts that's open source for bitcoin?
353 2014-01-10 09:52:28 <Bitember-Cray> or any good sites for open source projects in general
354 2014-01-10 12:38:58 <warren> after my lastest PR was included in Bitcoin I received mail (spam?) saying "You received a tip for your commit"
355 2014-01-10 12:39:02 <warren> it wants me to click on links
356 2014-01-10 12:41:10 <lianj> warren: thats normal
357 2014-01-10 12:41:25 <warren> so this is legit?
358 2014-01-10 12:47:01 <alex_fun> is there plan to develop de centralised checkpoints system that are self propagating every x amount of blocks?
359 2014-01-10 12:47:07 <alex_fun> based on the longest chain
360 2014-01-10 12:47:43 <gmaxwell> Yes, it's called a block, each block authenticates all the ones prior to it.
361 2014-01-10 12:47:53 <alex_fun> well I know this one
362 2014-01-10 12:48:13 <alex_fun> gmaxwell: but what if gov confiscates github?
363 2014-01-10 12:48:34 <alex_fun> if checkpoints are distributed in some p2p fashion then its safer
364 2014-01-10 12:48:37 <alex_fun> imo
365 2014-01-10 12:49:03 <warren> alex_fun: yeah, especially great when a single person controls those checkpoints with a private key
366 2014-01-10 12:49:07 <gmaxwell> alex_fun: there if no fundimental need for "checkpoints" at all, hopefully we'll remove them in the next release or the one after (or at least diminish their role)
367 2014-01-10 12:49:25 <warren> gmaxwell: what would "diminish their role" look like?
368 2014-01-10 12:50:13 <fanquake> warren I Just got that same email.
369 2014-01-10 12:50:15 <gmaxwell> warren: headers first basically eliminates all the DOS oriented reasons for having them completely.
370 2014-01-10 12:50:27 <warren> fanquake: is it legit?
371 2014-01-10 12:50:32 <fanquake> Got 0.00023858 btc apparently
372 2014-01-10 12:50:40 <warren> whoa
373 2014-01-10 12:50:50 <warren> just think how many dogecoin I could buy with that
374 2014-01-10 12:50:53 <fanquake> Yes legit as far as I can tell, although you can't withdraw unless your balance is > 0.001
375 2014-01-10 12:51:53 <fanquake> See http://tip4commit.com/projects/2, the bitcoin.bitcoin repo currently has a "tip balance" of 0.023 btc
376 2014-01-10 12:52:00 <fanquake> *bitcoin/bitcoin
377 2014-01-10 12:52:16 <alex_fun> warren yes I see what u saying when its time to take next checkpoint which node got to do it, I suggest its random node within longest chain
378 2014-01-10 12:52:53 <gmaxwell> warren: sipa and I are thinking that ECDSA could be gated based on having >30 or >60 days of cumuulative work in between the best chain over the current block vs the best known fork... which should work well once the hashrate growth stablizes.
379 2014-01-10 12:54:10 <alex_fun> gmaxwell: if checkpoints are removed then btc depends on goodwill of largest pools
380 2014-01-10 12:54:25 <alex_fun> as they can double spend in theory
381 2014-01-10 12:55:00 <gmaxwell> alex_fun: you misunderstand how bitcoin works, but nothing new there.
382 2014-01-10 12:55:12 <warren> alex_fun: here's where you hail your dear leader sunnyking?
383 2014-01-10 12:56:51 <alex_fun> emm?
384 2014-01-10 12:57:09 <alex_fun> :)
385 2014-01-10 12:57:09 <alex_fun> warren: I like many people including you
386 2014-01-10 12:57:11 <gmaxwell> (also, how did you get back in here, you're still banned)
387 2014-01-10 12:57:22 <alex_fun> as to sunny I am even yet to talk to him
388 2014-01-10 12:57:32 <alex_fun> I just came to ask on topic questions
389 2014-01-10 12:57:36 <alex_fun> very simple :)
390 2014-01-10 12:58:05 <gmaxwell> in any case, checkpoints close of some corner case dos attacks which are better solved other ways, they don't have anything to do with pools.
391 2014-01-10 12:58:09 <gmaxwell> or double spending.
392 2014-01-10 12:59:46 <alex_fun> gmaxwell: well if you plan to remove checkpoints completely then largest pools provided they got way over 51% can re solve earier blocks and double spend right?
393 2014-01-10 12:59:57 <gmaxwell> (DOS attacks like flooding a node with diff 1 blocks forked from early on which the node then forced to store just in case they form a chain that eventually overtakes. Checkpoints lets it just ignore them.)
394 2014-01-10 13:00:15 <alex_fun> yes thats handy
395 2014-01-10 13:00:18 <warren> "Ghash.io has voluntary to suspend parts of service!" ... split into a secret pool and change nothing more likely.
396 2014-01-10 13:00:40 <alex_fun> ghash io prices are high anyway
397 2014-01-10 13:00:54 <gmaxwell> alex_fun: no, "51%" can only rewrite the history eventually if they keep that for up to infinite time.
398 2014-01-10 13:01:13 <gmaxwell> the further back it goes the longer it takes.
399 2014-01-10 13:01:24 <alex_fun> yes as per satoshi formula
400 2014-01-10 13:01:48 <alex_fun> so hmm why they where there in a first place
401 2014-01-10 13:01:54 <gmaxwell> Satoshi didn't give a formula for the time until overtaking, he assumed the attack goes on for infinite time.
402 2014-01-10 13:01:55 <alex_fun> maybe they do have some value :)
403 2014-01-10 13:02:28 <gmaxwell> they close off those dos attacks, as mentioned, and later were employed to triggers some other performance shortcuts.
404 2014-01-10 13:03:01 <warren> gmaxwell: http://tip4commit.com/projects looks like you could get a large tip by fixing peercoin's 'myths'
405 2014-01-10 13:03:07 <Subo1977_> hi, is there a timeframe for 0.9 release?
406 2014-01-10 13:03:50 <alex_fun> gmaxwell: seems like they copied devcoin mark idea only ok they pay with btc :D
407 2014-01-10 13:05:23 <gmaxwell> (and its not like a reorg back six months would be any less fatal than a complete rewrite)
408 2014-01-10 13:07:14 <alex_fun> reorg happpens when there is two or more large forks?
409 2014-01-10 13:07:30 <alex_fun> and then some blocks are orphaned
410 2014-01-10 13:08:59 <fanquake> warren I'm thinking about just making a commit so that my balance is withdrawable :P
411 2014-01-10 13:09:13 <alex_fun> but why is it deadly? it just causes some orphans
412 2014-01-10 13:09:38 <alex_fun> or reorg aka rewrite back 6 months
413 2014-01-10 13:11:26 <lifeofcray> hey, do you guys know of any gambling scripts that's open source for bitcoin?
414 2014-01-10 13:11:28 <lifeofcray> or any good sites for open source projects in general
415 2014-01-10 13:12:03 <alex_fun> lifeofcray: there might be but some got security holes
416 2014-01-10 13:12:19 <alex_fun> :D
417 2014-01-10 13:12:19 <alex_fun> ok time to catch bus
418 2014-01-10 13:45:08 <justusranvier> Question: https://bitcointalk.org/index.php?topic=181734.msg4429223#msg4429223
419 2014-01-10 16:45:15 <saizai> gmaxwell: so as I was saying earlier re 1EVJyd8TbHBMUiMn6ogQ1PXbqoEZVp31Hz â PACs can't legally possess an in-kind contribution that's not from an identified source
420 2014-01-10 16:45:29 <saizai> in any amount
421 2014-01-10 16:45:46 <saizai> promising not to spend it isn't enough, they have to get rid of it to a charity
422 2014-01-10 16:46:10 <saizai> and not e.g. as a possible payment to someone (like fees to a miner they might be collaborating with)
423 2014-01-10 16:46:31 <saizai> hence my wanting to see if any payments to that didn't go through bitpay
424 2014-01-10 16:47:13 <saizai> a solid example of "look, you can't refuse bitcoin payments, bad things under FEC rules will happen if you don't adopt our framework for handling it" woudl be very useful
425 2014-01-10 17:00:19 <sipa> justusranvier: the only reason to not do that is that it requires a hard fork
426 2014-01-10 17:18:54 <lechuga__> i wonder what some of the more prominent bitcoin devs did before bitcoin
427 2014-01-10 17:19:52 <lechuga__> i dont think ive seen any serious media articles on the core devs
428 2014-01-10 17:20:05 <lechuga__> although i wonder if nondevs would even be interested in that
429 2014-01-10 17:35:23 <helo> the only dev i've seen referred to is the nakamoto ghost
430 2014-01-10 17:37:18 <lechuga__> which seems wrong to me
431 2014-01-10 17:48:49 <helo> i agree. the devs are my primary reason for ignoring altcoins.
432 2014-01-10 17:49:43 <sipa> ?
433 2014-01-10 17:51:57 <lechuga__> helo: what do u mean?
434 2014-01-10 17:54:06 <rfree> how would one change rule like target block rate/hour, but apply it depending on the block numbe
435 2014-01-10 17:54:09 <helo> lechuga__: bitcoin core devs are great. altcoin devs are ... generally different
436 2014-01-10 17:54:31 <lechuga__> ic
437 2014-01-10 17:55:15 <sipa> rfree: when retargetting, take the block number into account
438 2014-01-10 17:55:25 <sipa> also, this is not #altcoin-dev
439 2014-01-10 17:55:34 <rfree> sipa: recall keyword or funcion name?
440 2014-01-10 17:56:04 <rfree> sipa: well, could your master race anyway discuss how BITCOIN code does work, without unneeded hint of unfriendliness? ;)
441 2014-01-10 17:56:13 <lianj> wonder why testnet is so busy lately
442 2014-01-10 17:56:51 <lechuga__> people are testing? :)
443 2014-01-10 17:57:01 <rfree> on a related for the bitcoin topic: perhaps one day, after some block number, bitcoin could consider adding PoS reward system
444 2014-01-10 17:57:09 <sipa> hell no
445 2014-01-10 17:57:29 <rfree> because that would be a change of past constant promise, or because PoS is generally bad idea?
446 2014-01-10 17:58:09 <rfree> e.g. if bitcoin would have PoS from start, then should it
447 2014-01-10 17:58:15 <sipa> in general, such a change is way too invasive for the economic model imho to ever be considered
448 2014-01-10 17:58:40 <sipa> (independent of whether it's a good idea or not, such a change could only be made if the alternative is imminent failure)
449 2014-01-10 17:58:50 <rfree> so it's about the *change* ok. And other then that, do you think PoS could help save bitcoin for 51% attacks or make them harder?
450 2014-01-10 17:59:21 <pjorrit> doest pos have its own 51p's
451 2014-01-10 18:00:06 <helo> assuming PoS is viable, it could make a 51% via chip fabrication more difficult. but it has its own problems...
452 2014-01-10 18:00:21 <sipa> rfree: in addition, all (pure) proof of work systems i know of actually fail to guarantee convergence
453 2014-01-10 18:00:42 <sipa> that's not to say that other ways are possible, or that a combination of PoW and PoS isn't viable
454 2014-01-10 18:00:49 <sipa> *are not possible
455 2014-01-10 18:01:11 <helo> sipa: did you mean "all (pure) proof of stake systems"?
456 2014-01-10 18:01:26 <sipa> yes!
457 2014-01-10 18:01:46 <sipa> with the added qualifier "that i know of"
458 2014-01-10 18:02:16 <pjorrit> but that's implied
459 2014-01-10 18:08:30 <lechuga__> PoS just feels wrong
460 2014-01-10 18:08:41 <lechuga__> although i have no idea how it would actually pan out in practice
461 2014-01-10 18:11:45 <rfree> I ment WoS+PoS of course, not one alone
462 2014-01-10 18:12:33 <rfree> well if "adversary" is able to both controll MOST of the current hardware, and MOST of the coins... well, then he trully does "own" the currency (but that's in his worst interst - people will turn away and he will lose long-term)
463 2014-01-10 18:13:30 <rfree> about the GHash 51%, is there any plan how to make this more avoidable in future?
464 2014-01-10 18:15:05 <lechuga__> making p2pool easier to adopt, extending GBT to allow txns sourced from miner-selected srcs
465 2014-01-10 18:15:35 <pjorrit> that's not allowed in gbt? i thought that was its spiel
466 2014-01-10 18:15:48 <lechuga__> its allowed and what luke designed it for
467 2014-01-10 18:15:54 <lechuga__> but the functionality isnt there atm
468 2014-01-10 18:16:34 <pjorrit> it's not available on the miner side you mean?
469 2014-01-10 18:16:39 <lechuga__> right
470 2014-01-10 18:17:01 <lechuga__> i mean miners support gbt but not abritrarily choosing txns
471 2014-01-10 18:17:42 <lechuga__> there may be other mitigation plans in the works but those r the 2 prominent ones in my understanding
472 2014-01-10 18:17:44 <pjorrit> yea alright
473 2014-01-10 19:18:59 <linagee_> is there a good way to monitor a lot of bitcoin addresses?
474 2014-01-10 19:19:02 <linagee_> (lets say... thousands, every second?)
475 2014-01-10 19:30:34 <lechuga__> monitor how?
476 2014-01-10 19:30:45 <andytoshi> linagee_: http://download.wpsoftware.net/bitcoin/bitcoin-faq.pdf
477 2014-01-10 19:30:58 <andytoshi> maybe will correct whatever mistake makes you think "monitor thousands of addresses per second" makes sense
478 2014-01-10 19:33:12 <jcorgan> linagee_ probably means "monitor incoming TXes for outputs that pay to an addresses in a list that could potentially be thousands in size"
479 2014-01-10 19:33:52 <Eagle[TM]> linagee: chainsnort?
480 2014-01-10 19:34:42 <linagee_> andytoshi: thanks. I just emailed mike from bitcoinmonitor.net my idea. (bitcoin alert by phone)
481 2014-01-10 19:35:14 <linagee_> er, by voice over phone. (kind of need to clarify that in today's world of everything mobile. heh.)
482 2014-01-10 19:36:15 <jcorgan> afaict none of the common wallets are event driven in the sense that you can have, say, bitcoind notify some other software when something happens.
483 2014-01-10 19:36:24 <linagee_> some old mom/pop shops don't have mobile phones let alone internet at their business and I think it would be neat to enable them to accept bitcoin. (this is assuming they have a desktop/laptop elsewhere where they can manipulate the funds.)
484 2014-01-10 19:36:30 <jcorgan> you have to poll the RPC interface in a loop
485 2014-01-10 19:36:56 <lechuga__> why would monitoring txns for some subset of addresses help with that problem
486 2014-01-10 19:37:23 <andytoshi> jcorgan: bitcoind has an event-driven interface
487 2014-01-10 19:37:36 <jcorgan> though ISTR that someone had put it zeromq queues in, which would be really nice
488 2014-01-10 19:37:38 <andytoshi> bitcoind --help | grep notify
489 2014-01-10 19:37:42 <linagee_> lechuga__: so I could run a business where they hand me a bunch of public addresses, I monitor them all for them, and report via phonecall when a txn happens. :) (along with some sort of OTP code that they also have on paper or something.
490 2014-01-10 19:38:20 <linagee_> lechuga__: this is to be one step better than hanging a static QR code in the business and then just telling people "there's my code! now pay me!" (argh.... vendors gonna get burnt.)
491 2014-01-10 19:38:42 <andytoshi> it's not one step better, address reuse is stupid regardless of mechanism
492 2014-01-10 19:38:55 <linagee_> andytoshi: no, no. I do think its incredibly stupid of them to do that.
493 2014-01-10 19:39:08 <linagee_> andytoshi: but - they could easily solve that problem with a notepad of public addresses. :)
494 2014-01-10 19:39:34 <andytoshi> ??? how would that discourage address reuse?
495 2014-01-10 19:39:48 <andytoshi> how does that not encourage address reuse, even?
496 2014-01-10 19:40:08 <linagee_> andytoshi: one person pays to the address, you tear off the sheet from the notepad, staple that to the receipt for recordkeeping (or throw it in the trash) and then the next QR code is there and ready. :)
497 2014-01-10 19:40:50 <andytoshi> linagee_: haha! very creative
498 2014-01-10 19:41:04 <andytoshi> like a physical 'getnewaddress'
499 2014-01-10 19:41:08 <helo> just keep a tight chain of control/surveillance of the notepad
500 2014-01-10 19:41:19 <linagee_> andytoshi: the phone service would also accept inbound calls to handle "I want to charge $4.50" and then it spits back out at you "0.01 BTC" (for instance, I didn't do the math.)
501 2014-01-10 19:41:28 <linagee_> helo: indeed.
502 2014-01-10 19:41:40 <linagee_> helo: actually, it wouldn't matter that much. :)
503 2014-01-10 19:41:43 <andytoshi> ok, i sorta see what you're going for here..
504 2014-01-10 19:41:53 <andytoshi> linagee_: people might replace the notepad
505 2014-01-10 19:41:56 <linagee_> helo: the first time someone pays and they don't get a phonecall back, they'll be like "hrm!!"
506 2014-01-10 19:42:02 <lechuga__> so how do they generate the key pairs for th enotepad
507 2014-01-10 19:42:06 <andytoshi> "hrm!!" doesn't get the money back
508 2014-01-10 19:42:19 <linagee_> granted that would suck, even for one vendor txn, but not like they can be totally screwed over.
509 2014-01-10 19:42:37 <jcorgan> interesting idea for bip00032 based address generation
510 2014-01-10 19:43:11 <jcorgan> the notebook would be m/N'/0/i, where each notebook would be a different N and each sheet would be a different i
511 2014-01-10 19:43:19 <linagee_> lechuga__: either I totally "bot" a coinbase account for them (after some legal contract allowing me to), or they handle coinbase themselves and via maybe some sort of CSV export or something... (not even sure if that exists)
512 2014-01-10 19:43:43 <linagee_> or I contact coinbase and try to whitelabel them with an actual stamp of approval from them. :)
513 2014-01-10 19:44:15 <lechuga__> interesting idea for less developed parts of the world
514 2014-01-10 19:44:20 <linagee_> lechuga__: hahahaha
515 2014-01-10 19:44:29 <linagee_> lechuga__: uhm.... lots of places in the US actually. :)
516 2014-01-10 19:44:39 <lechuga__> i guess i believe that too
517 2014-01-10 19:45:02 <linagee_> lechuga__: lots of stores around me they have just a cheap IBM cash register that's nothing more than a large calculator, receipt printer, and cash drawer. no network connection.
518 2014-01-10 19:45:22 <lechuga__> the majority dont also have smartphone sin their pockets?
519 2014-01-10 19:45:25 <linagee_> lechuga__: not saying they couldn't/shouldn't upgrade. I'm saying when you tell some of these people $50/mo just for mobile service they get wide eyed. :)
520 2014-01-10 19:45:46 <jcorgan> i suppose that is the polar opposite of all the coffee shops around here that have iPads in stylish holders with square, hanging off LTE
521 2014-01-10 19:45:54 <linagee_> lechuga__: eh. it differs. and this is for one niche. but not by any means a non-existant niche. :)
522 2014-01-10 19:46:00 <lechuga__> god my local coffee shop uses square
523 2014-01-10 19:46:02 <lechuga__> drives me insane
524 2014-01-10 19:46:05 <linagee_> lechuga__: same here...
525 2014-01-10 19:46:25 <lechuga__> swiping my stupid card for coffee
526 2014-01-10 19:46:37 <lechuga__> sometimes 5x before it take sit because debit cards r so cheaply constructed
527 2014-01-10 19:47:13 <lechuga__> wish credit/debit cards would die
528 2014-01-10 19:47:14 <linagee_> jcorgan: coffee shop near me has square. obviously they'd be better served by a bitpay or coinbase app. but the mexican restaurant down the street has one of these "dummy" type registers. :)
529 2014-01-10 19:47:55 <jcorgan> all the taxi drivers in my city use square, the transaction fees are *way* less then if they go through the taxi companies official CC service.
530 2014-01-10 19:48:05 <lechuga__> isnt square liek 2.5%
531 2014-01-10 19:48:29 <jcorgan> and the taxi companies were taking something like 15%
532 2014-01-10 19:48:31 <linagee_> does anyone know why coinbase doesn't allow instantly turning BTC into fiat?
533 2014-01-10 19:48:59 <linagee_> (you can do it automatically once per day, and automatically every transaction if you play with their API, but no easy way AFAIK through the interface.)
534 2014-01-10 19:49:17 <linagee_> (almost as if they did that on purpose to discourage it.)
535 2014-01-10 19:59:20 <niston> are there any projects in the works for instant bitcoin payment?
536 2014-01-10 20:01:26 <linagee_> niston: get bitcoin in bankers hands on their own member portal (as unpopular of an idea as bankers are with the bitcoin crowd) and you could have instant payment.