1 2013-12-28 00:20:15 <maaku> ahmedbodi__: totally depends on what framework is being used for http requests
2 2013-12-28 00:20:27 <ahmedbodi__> maaku: its cool ive sorted it :)
3 2013-12-28 00:20:27 <maaku> you can probably catch an exception, or examine the result to see
4 2013-12-28 00:20:31 <maaku> k
5 2013-12-28 00:20:47 <ahmedbodi__> except ValueError:
6 2013-12-28 00:20:47 <ahmedbodi__> log.error("Failed Connect(HTTP 500 or Invalid JSON), Check Username and Password!")
7 2013-12-28 00:20:47 <ahmedbodi__> reactor.stop()
8 2013-12-28 00:21:01 <ahmedbodi__> thanks for the advice tho :)
9 2013-12-28 00:34:02 <rfish> hey, I think I figured out how to make colored coins without changing the bitcoin protocol
10 2013-12-28 00:34:16 <rfish> just changes to the bitcoin client
11 2013-12-28 00:34:17 <sipa> why would you need to change the protocol for them...?
12 2013-12-28 00:34:28 <sipa> you just keep track of the color of coins...
13 2013-12-28 00:35:20 <rfish> is there a client that already exists that implements colored coins?
14 2013-12-28 00:35:46 <sipa> unsure, but i don't see why the protocol would need to change for them
15 2013-12-28 00:36:07 <rfish> well I don't see why either
16 2013-12-28 00:36:15 <sipa> ok :)
17 2013-12-28 00:36:28 <gmaxwell> rfish: there are things like that colored coin armory thing. ... but really no one has answered the greater question of what purpose colored coins really have at all.
18 2013-12-28 00:37:01 <gmaxwell> Because pratically every application people cite for them can be just slightly refactored to completely remove the colored coin, usually resulting in a protocol with lower overhead.
19 2013-12-28 00:37:08 <rfish> uhh.... issuing stock or asset certificates?
20 2013-12-28 00:37:42 <rfish> right in the block chain
21 2013-12-28 00:38:49 <rfish> it will allow you to move these certificates from exchange to exchange as you see fit
22 2013-12-28 00:38:53 <gmaxwell> rfish: sure, and in all those cases you depend on the company to actually make the stock have any value or meanin at all. So just have it run the ledger (I suppose it can publish commitments to the ledger state in some public way, if you don't trust it). There is no need to record the indivigual transactions in the bitcoin blockchain and a lot of reason not to (e.g. quasi-exponential overhead in tracing the colored coins).
23 2013-12-28 00:39:23 <gmaxwell> (transaction fees, risk of censorship by miners, loss of control over privacy)
24 2013-12-28 00:41:37 <phantomcircuit> gmaxwell, if you dont trust the company to keep a ledger of ownership, why are you giving them funds in the first place?
25 2013-12-28 00:41:38 <sipa> BlueMatt: BIP37 doesn't list the protocol version that enables it
26 2013-12-28 00:43:17 <rfish> well it might be time consuming and expensive to manage your own leger if you were a company managing your own stock
27 2013-12-28 00:43:35 <rfish> why not leverage the bitcoin network to do it?
28 2013-12-28 00:43:44 <gmaxwell> phantomcircuit: right, thats generally the case for almost all cited applications of colored coins. There is some {thing} that gives the colors meaning which could just be employed to maintain a ledger. The only example where there isn't is where you hope to create a competing currency. In which case the incentives miners to screw with it is maximized.
29 2013-12-28 00:44:20 <gmaxwell> rfish: it should be no more time consuming and expensive to manage than just running a network nodeâ which you'd have to do to usefully participate in / issue / pay dividends etc. for any colored coin scheme.
30 2013-12-28 00:44:49 <rfish> wouldn't it take a solid majority of minors to screw with it?
31 2013-12-28 00:45:06 <rfish> and if that starts happening for any application for bitcoin, then bitcoin is dead?
32 2013-12-28 00:45:53 <gmaxwell> hm? no way. a majority of miners can block it completely, but with less than that it can be made insecure, have slow confirmation times, etc.
33 2013-12-28 00:46:23 <phantomcircuit> a fairly small number of miners could effectively blacklist all colored coins
34 2013-12-28 00:46:31 <gmaxwell> And I don't think bitcoin miners deciding as a group to block a parasitic use would say anything about "bitcoin is dead".
35 2013-12-28 00:46:38 <phantomcircuit> indeed by default most of them already do since most of those schemes rely on 1 satoshi outputs
36 2013-12-28 00:47:10 <rfish> do they block 1 satoshi outputs even if fees are paid?
37 2013-12-28 00:47:12 <gmaxwell> besides, a bitcoin like blockchain is really a bad fit for an 'exchange' model. Transactions take a long time to be sure of their completion.
38 2013-12-28 00:47:15 <gmaxwell> rfish: yes.
39 2013-12-28 00:48:18 <gmaxwell> rfish: because there is generally no incentive to go spend those outputs again, as they cost more in fees to consume than they yield in coins... and so they have a high risk of perpetually bloating up the working set.
40 2013-12-28 00:48:28 <phantomcircuit> rfish, nobody has any incentive to allow ridiculously tiny outputs
41 2013-12-28 00:48:52 <CodeShark> for such a purpose, it would be far better to just pay a fee and have 0-satoshi outputs
42 2013-12-28 00:48:57 <rfish> phantomcircuit: Why do they care, if there is also a large fee attached for the miner?
43 2013-12-28 00:49:05 <sipa> CodeShark: how is that any better?
44 2013-12-28 00:49:23 <CodeShark> 0-satoshi outputs mean no utxo bloat
45 2013-12-28 00:49:26 <phantomcircuit> rfish, long term incentive is to keep bitcoin working of course
46 2013-12-28 00:49:28 <gmaxwell> CodeShark: uh. no. absolutely the same working set impact.
47 2013-12-28 00:49:29 <sipa> CodeShark: eh, no
48 2013-12-28 00:49:43 <rfish> if a small minority of minors really have that power to control the network, then bitcoin sucks
49 2013-12-28 00:49:46 <sipa> CodeShark: provably unspendable outputs mean no UTXO bloat
50 2013-12-28 00:49:57 <CodeShark> isn't that an implementation detail?
51 2013-12-28 00:49:57 <sipa> but 0-satoshi outputs can completely legally be spent
52 2013-12-28 00:49:59 <sipa> no
53 2013-12-28 00:50:00 <CodeShark> oh, hmm
54 2013-12-28 00:50:05 <CodeShark> I guess that means a protocol change
55 2013-12-28 00:50:13 <sipa> it would be a (soft)fork to disallow spending 0-satoshi outputs
56 2013-12-28 00:50:38 <rfish> 1-satoshi outputs with an appropriate fee should be allowed
57 2013-12-28 00:50:46 <gmaxwell> rfish: because they want bitcoin to be actually useful as a decenteralized currency in the future, and people bloating up the UTXOâ which must be available in fast storage for rapid lookup and has a direct impact on block/transaction validation timesâ screws up Bitcoin's decenteralization and usage as a currency.
58 2013-12-28 00:50:47 <CodeShark> the main problem I have with this approach is that only miners are compensated
59 2013-12-28 00:50:47 <rfish> and if not then seriously wtf?
60 2013-12-28 00:51:06 <CodeShark> if somehow the fee were distributed to the entire network for the service of publication and storage, I'd be fine with it
61 2013-12-28 00:51:15 <gmaxwell> rfish: They aren't. Bitcoin is not a data storage service, especially not the UTXO set. Perhaps you want datacoin? http://datacoin.info/index.php?id=index
62 2013-12-28 00:51:49 <sipa> CodeShark: yes, that's exactly the problem
63 2013-12-28 00:52:13 <gmaxwell> CodeShark: yea, actually requring a larger output effectively does distribute it to all the bitcoin holders for the case where the storage takes the coin out of circulation... Not the nodes though, which is unfortunate.
64 2013-12-28 00:52:22 <rfish> I'm not storing data, I'm giving transactions some artificial meaning
65 2013-12-28 00:52:41 <sipa> you can store that meaning outside bitcoin just as well
66 2013-12-28 00:52:54 <rfish> and solution to transaction bloat is just have miners up the transactions fees
67 2013-12-28 00:53:13 <rfish> make incentives to use some centralized services for small transactions
68 2013-12-28 00:53:15 <sipa> rfish: i'm running a full node; your transactions with data attached are stored on my hard drive
69 2013-12-28 00:53:23 <sipa> rfish: i'm not paid for that
70 2013-12-28 00:53:29 <sipa> no miner will send their income to me
71 2013-12-28 00:53:32 <gmaxwell> rfish: no, thats not a fully general and complete solution... because the regular currency usage of bitcoin suffers from it too.
72 2013-12-28 00:53:40 <andytoshi> rfish: bullshit, i'm also running a full node, and besides, i use bitcoin as a currency, so having my fees jacked up to pay for you wasting my time nad space
73 2013-12-28 00:53:44 <rfish> sipa: you aren't paid anything to run full node
74 2013-12-28 00:53:55 <rfish> sipa: are doing it out of the goodness of your heart
75 2013-12-28 00:53:59 <rfish> sipa: even now
76 2013-12-28 00:54:01 <andytoshi> for something which shouldn't be done in bitcoin and doesn't need to be anyway
77 2013-12-28 00:54:03 <gmaxwell> rfish: miners aren't getting paid any of your "artificial meaning" so why should they give a darn about your scheme which only increases costs for all the currency users?
78 2013-12-28 00:54:19 <rfish> yes they are, they get paid the miners fee
79 2013-12-28 00:54:27 <gmaxwell> rfish: you _are_ paid to run a full nodeâ by bitcoin being useful as a secure decenteralized currency.
80 2013-12-28 00:54:32 <rfish> I'm saying I attach a miners fee to the 1 satoshi output
81 2013-12-28 00:54:56 <sipa> rfish: and the whole world is required to keep track of it forever, while you already know you're _never_ going to spend it
82 2013-12-28 00:55:13 <gmaxwell> rfish: yea so? I kicked in your door, drank your beer, watched your TV, brushed with your tooth brush, but no worries, I left a $50 note on your counter. Paying doesn't make a usage non-abusive.
83 2013-12-28 00:55:31 <CodeShark> despite all the other problems, solving the utxo bloat issue would be a good thing
84 2013-12-28 00:55:47 <sipa> CodeShark: we have pruning of unspendable outputs
85 2013-12-28 00:55:53 <gmaxwell> CodeShark: it seems to be pretty under control since dust outputs were made non-standard.
86 2013-12-28 00:56:09 <rfish> gmaxwell: If you gave me maybe 10,000k I would let you do it
87 2013-12-28 00:56:22 <rfish> why not let supply and demand run its course
88 2013-12-28 00:56:28 <CodeShark> perhaps an additional OP code for output scripts declaring it unspendable
89 2013-12-28 00:56:33 <gmaxwell> ...
90 2013-12-28 00:56:36 <CodeShark> lol
91 2013-12-28 00:56:36 <rfish> if people want this feature, and want to pay the appropriate miners fee, let them
92 2013-12-28 00:56:48 <sipa> rfish: they would have to pay ME
93 2013-12-28 00:56:50 <sipa> not just miners
94 2013-12-28 00:56:51 <Emcy> wheres my 10k
95 2013-12-28 00:56:51 <gmaxwell> rfish: again, paying miners is not sufficient.
96 2013-12-28 00:56:58 <CodeShark> or a making a nonspendable output script standard
97 2013-12-28 00:57:01 <Emcy> i got your shitty output in my RAM now forever too
98 2013-12-28 00:57:02 <rfish> perhaps this feature will add more value to the network as a whole and the value of bitcoin would go up
99 2013-12-28 00:57:17 <sipa> CodeShark: done
100 2013-12-28 00:57:28 <rfish> and in that way, nodes are getting paid
101 2013-12-28 00:57:35 <rfish> by adding value to the bitcoin network
102 2013-12-28 00:57:54 <CodeShark> in any case, bitcoin is not really designed as a general purpose protocol stack layer upon which specific protocols can be built
103 2013-12-28 00:57:54 <Emcy> no it decreases value by making it harder to run a node
104 2013-12-28 00:57:54 <sipa> so do it for nodes that care to do so
105 2013-12-28 00:57:55 <rfish> I think colored coins have the ability to disrupt wall street
106 2013-12-28 00:58:15 <sipa> duly noted.
107 2013-12-28 00:58:26 <gmaxwell> rfish: It's generally of people's opinion that (economically)unspendable transactions currently lower bitcoin's value. If you really want to add value, and your usage isn't worthless, then you can just happily use whole bitcoins or whatever as your colored denomination. Still stupid, but you can avoid the current restriction.
108 2013-12-28 00:58:28 <jtcwang> Are there any other sources of protocol specification apart from https://en.bitcoin.it/wiki/Protocol_specification#tx?
109 2013-12-28 00:58:49 <sipa> jtcwang: github.com/bitcoin/bitcoin
110 2013-12-28 00:58:58 <sipa> jtcwang: the wiki is unfortunately not even up to date
111 2013-12-28 00:59:04 <jtcwang> i see
112 2013-12-28 00:59:07 <jtcwang> good to know thanks
113 2013-12-28 00:59:10 <CodeShark> all these attempts to use bitcoin to store arbitrary data strike me as examples of "I only know how to use a hammer"
114 2013-12-28 00:59:13 <sipa> though recent modifications are always encoded in bips
115 2013-12-28 00:59:14 <jtcwang> guess i really need to dig the code
116 2013-12-28 00:59:26 <sipa> CodeShark: yup!
117 2013-12-28 00:59:33 <gmaxwell> rfish: ow. Your waving arms hit me right in the nose. "disrupt wallstreet" lol. As I said above, anything that can be done with colored coinsâ except, perhaps creating a competing currencyâ can be done without.
118 2013-12-28 00:59:34 <jtcwang> we need like code handhelding for noobies like me
119 2013-12-28 00:59:38 <gmaxwell> CodeShark: BINGO
120 2013-12-28 00:59:59 <jtcwang> just joking
121 2013-12-28 01:00:06 <gmaxwell> Damnit, I wish for the days when the "I only know how to use a hammer" was people coming in here yabbering about DHTs.
122 2013-12-28 01:00:06 <jtcwang> i'll dig it
123 2013-12-28 01:00:25 <Emcy> is there a mergemined coin for this sort of thing? Or are all the alts still obsessed with scrypt?
124 2013-12-28 01:00:27 <sipa> gmaxwell: we should make bitcoin run in the cloud
125 2013-12-28 01:00:39 <Zarutian> gmaxwell: well, their hammers got screwed tight. ;-Ã
126 2013-12-28 01:00:48 <Emcy> i wonder if this sort of abuse would be incentive enough to get miners to merge mine a storage coin
127 2013-12-28 01:00:48 <gmaxwell> Webscale Coin.
128 2013-12-28 01:01:36 <gmaxwell> Emcy: namecoin already formally supports free key value storage.
129 2013-12-28 01:02:04 <gmaxwell> And basically no IsStandard restrictions on it.
130 2013-12-28 01:02:15 <Emcy> yeah but that would be a bit abusive too
131 2013-12-28 01:02:23 <gmaxwell> Emcy: though generally the high cost of running things discourages people from mergemining them.
132 2013-12-28 01:02:40 <Emcy> high cosst?
133 2013-12-28 01:02:54 <CodeShark> we already compensate nodes (miners) for timestamping - if we could devise a protocol to compensate nodes for storage as well
134 2013-12-28 01:02:56 <gmaxwell> Emcy: if they actually get used (or in the case of NMC, because there is very little development)
135 2013-12-28 01:03:29 <sipa> CodeShark: welcome to TXO MMRs :)
136 2013-12-28 01:03:34 <jtcwang> Simple question: Once a Nlocktime transaction is in the mem pool, it'll reject any other transaction using the same input am i correct?
137 2013-12-28 01:03:54 <sipa> jtcwang: correct, and that is regardless of nlocktime
138 2013-12-28 01:04:10 <jtcwang> cool thx
139 2013-12-28 01:04:57 <theboos> oh hey, we're back on this topic
140 2013-12-28 01:05:04 <gmaxwell> jtcwang: we won't relay or mempool out of scope locked txn.
141 2013-12-28 01:05:14 <rfish> What is the minimum output allowed?
142 2013-12-28 01:05:28 <sipa> rfish: depends on what you configure as price per kilobyte
143 2013-12-28 01:05:39 <jtcwang> gmaxwell: out of scope as in too far away in the future?
144 2013-12-28 01:05:51 <sipa> though the default currently is a few thousand satoshi
145 2013-12-28 01:06:15 <CodeShark> it is also a major problem that relay is not compensated
146 2013-12-28 01:06:37 <sipa> rfish: nodes refuse relaying transactions that have outputs where the cost of redeeming that extra output costs more than 1/3 of its value
147 2013-12-28 01:07:21 <gmaxwell> jtcwang: right. We currently won't accept or relay nlocktimes where the lock is .. uh I forget did we relax that to 1 block/10 minutes or is not until they're locked now?
148 2013-12-28 01:07:38 <CodeShark> if relay, storage, and mining were all appropriately compensated then each node could set its own policy however it chooses
149 2013-12-28 01:08:11 <jtcwang> gmaxwell: what do you mean by 'locked'?
150 2013-12-28 01:09:07 <sipa> jtcwang: with a nlocktime that hasn't passed yet
151 2013-12-28 01:09:37 <rfish> bitcoin nodes are going to get fewer and fewer over time as more and more people use the network
152 2013-12-28 01:09:42 <Emcy> paying for relay would be sybiled to hell
153 2013-12-28 01:09:51 <sipa> rfish: we should do all we can to avoid that
154 2013-12-28 01:10:07 <sipa> but a certain shift is probably inevitable
155 2013-12-28 01:10:15 <Emcy> dunno about storage. Verification would be a huge faff id guess
156 2013-12-28 01:10:27 <Emcy> probably have to be continuous
157 2013-12-28 01:10:29 <rfish> and the only nodes people are going to care about are the mining pool nodes
158 2013-12-28 01:10:41 <sipa> rfish: in that case, bitcoin has failed
159 2013-12-28 01:10:56 <gmaxwell> what sipa said
160 2013-12-28 01:10:58 <sipa> its purpose was to create a currency that doesn't require trust in anyone "doing the right thing"
161 2013-12-28 01:11:18 <sipa> if only miners are able/interested in verifying that nobody is cheating, what prevents them from cheating?
162 2013-12-28 01:11:20 <rfish> well the miners will remain decentralized
163 2013-12-28 01:11:32 <sipa> banks are also decentralized
164 2013-12-28 01:11:35 <sipa> there are several!
165 2013-12-28 01:11:44 <Emcy> ha
166 2013-12-28 01:11:48 <rfish> and miners will vote for the more ethical mining pool with their hashing power
167 2013-12-28 01:11:55 <sipa> yeah right :D
168 2013-12-28 01:11:57 <CodeShark> lol
169 2013-12-28 01:11:59 <gmaxwell> rfish: "miners" what do you mean by that? Someone who doesn't run a bitcoin node is not a miner. They're just selling compute services to a miner.
170 2013-12-28 01:12:07 <gmaxwell> Thats like calling AMD a miner. :P
171 2013-12-28 01:12:08 <Emcy> also by "cheating" what is meant is "compelled to do all sorts of shit"
172 2013-12-28 01:12:27 <sipa> rfish: if miners will vote for the ethical thing, then we can just as well trust banks now to do the ethical thing, right?
173 2013-12-28 01:12:38 <rfish> by miners I mean people with hashing power
174 2013-12-28 01:12:39 <gmaxwell> rfish: lol, nice theory there. Except GHASH.IO appears to have been caught ripping off bitcoin users and no one seems to care.
175 2013-12-28 01:12:50 <sipa> rfish: same thing
176 2013-12-28 01:12:53 <sipa> they'll be the elite
177 2013-12-28 01:13:01 <gmaxwell> ( https://bitcointalk.org/index.php?topic=327767.0 )
178 2013-12-28 01:13:09 <sipa> take this to #bitcoin please?
179 2013-12-28 01:13:32 <gmaxwell> The whole reason that miners (however you define them) behave honestly is that they are generally enforced to by all the other people running nodes.
180 2013-12-28 01:14:02 <rfish> mining pool operators can block transactions from what I understand
181 2013-12-28 01:14:14 <CodeShark> there is a strong incentive for anyone accepting bitcoin payments as part of their business to run a full verification node even if they do not run a mining node
182 2013-12-28 01:14:14 <rfish> and their miners help enforce that
183 2013-12-28 01:14:22 <sipa> rfish: that would be a 51% attack
184 2013-12-28 01:14:27 <sipa> but yes
185 2013-12-28 01:14:47 <rfish> but the mining pool operators can't block transactions in a way that their miners can't figure it out
186 2013-12-28 01:15:00 <jcorgan> rfish: an individual miner can choose to ignore specific TXs (including all of them)
187 2013-12-28 01:15:26 <jcorgan> (solo miner or mining pool)
188 2013-12-28 01:15:31 <rfish> jcorgan: even as part of a mining pool?
189 2013-12-28 01:15:47 <CodeShark> unfortunately, the incentive to run a miner on typical hardware has deteriorated since the original satoshi paper
190 2013-12-28 01:15:47 <jcorgan> mining pool operator
191 2013-12-28 01:16:05 <jtcwang> gmaxwell: (nLockTime) I thought nLockTime specifies a future block #?
192 2013-12-28 01:16:17 <rfish> the mining pool operator can, but not a mining pool member from what I understand
193 2013-12-28 01:16:17 <sipa> jtcwang: or timestamp
194 2013-12-28 01:16:29 <sipa> rfish: depends on the protocol used
195 2013-12-28 01:16:40 <sipa> getwork/stratum don't allow inspecting blocks, gbt does
196 2013-12-28 01:17:17 <jtcwang> "with a nlocktime that hasn't passed yet" doesn't that mean i cannot publish a transaction that'll happen in the future and make sure no one touches that fund?
197 2013-12-28 01:17:22 <rfish> even the operator can always post the block somewhere allowing who ever wants to inspect it
198 2013-12-28 01:17:23 <sipa> ;;blocks
199 2013-12-28 01:17:24 <gribble> 277324
200 2013-12-28 01:17:54 <rfish> and by inspecting the hash of the block you are suppose to mine you can see that he is telling the truth about the block you are suppose to mine
201 2013-12-28 01:18:05 <sipa> jtcwang: not far into the future no; that would mean requiring the whole world to keep your transaction in memory for a long time
202 2013-12-28 01:18:13 <Emcy> gmaxwell that ghash.io really caught skimming blocks? As in proof?
203 2013-12-28 01:18:32 <jtcwang> i agree but if then what are the uses of nlocktime?
204 2013-12-28 01:18:58 <Emcy> sok i got the thread
205 2013-12-28 01:19:55 <jtcwang> i mean the only use case is that my sick grandpa give me his inheritance
206 2013-12-28 01:20:23 <jtcwang> with nlocktimed transaction. I can trust him to not touch the fund before that
207 2013-12-28 01:28:23 <maaku> jtcwang: it's useful in various higher level protocols
208 2013-12-28 01:28:31 <maaku> e.g. cross-chain trade
209 2013-12-28 01:30:02 <rebroad> Hmmm. bitcoin-qt isn't compiling with the latest master... I'm getting:-
210 2013-12-28 01:30:03 <rebroad> /home/rebroad/src/bitcoin/src/qt/guiutil.cpp:169: undefined reference to `BitcoinUnits::format(int, long long, bool)'
211 2013-12-28 01:30:03 <rebroad> ../../../src/qt/libbitcoinqt.a(libbitcoinqt_a-guiutil.o): In function `GUIUtil::formatBitcoinURI(SendCoinsRecipient const&)':
212 2013-12-28 01:30:03 <rebroad> ../../../src/qt/libbitcoinqt.a(libbitcoinqt_a-guiutil.o): In function `GUIUtil::parseBitcoinURI(QUrl const&, SendCoinsRecipient*)':
213 2013-12-28 01:30:04 <rebroad> /home/rebroad/src/bitcoin/src/qt/guiutil.cpp:130: undefined reference to `BitcoinUnits::parse(int, QString const&, long long*)'
214 2013-12-28 01:30:07 <rebroad> ../../../src/qt/libbitcoinqt.a(libbitcoinqt_a-paymentserver.o): In function `PaymentServer::processPaymentRequest(PaymentRequestPlus&, SendCoinsRecipient&)':
215 2013-12-28 01:30:10 <rebroad> /home/rebroad/src/bitcoin/src/qt/paymentserver.cpp:490: undefined reference to `BitcoinUnits::formatWithUnit(int, long long, bool)'
216 2013-12-28 01:30:13 <rebroad> collect2: ld returned 1 exit status
217 2013-12-28 01:31:11 <andytoshi> rebroad: if you rerun autogen and configure, does it still happen
218 2013-12-28 01:31:18 <andytoshi> (sorry, i know that's like a 30-minute test)
219 2013-12-28 01:32:06 <gmaxwell> jtcwang: you really can't trust him to do that with nlocktime.
220 2013-12-28 01:32:13 <rebroad> andytoshi, I'll try
221 2013-12-28 01:32:21 <gmaxwell> jtcwang: because he could just pay a miner to include a conflicting transaction directly.
222 2013-12-28 01:32:51 <gmaxwell> jtcwang: and besides, if he really couldn't spend it himself, how is that different from just transfering the control to you?
223 2013-12-28 01:33:26 <gmaxwell> I think what you would probably prefer is a protocol where he assigns the coins to 2 of 2 him+you, and also signs a nlocked release to transfer the coins to you.
224 2013-12-28 01:33:27 <jtcwang> gmaxwell: i can't trust my grandpa? :( I've been reading some archived post on nLockTime and ppl mentioned it being accepted into the mempool as long as it isn't too many days out?
225 2013-12-28 01:33:58 <gmaxwell> jtcwang: if you can trust your grandpa without enforcement, then just trust him, you don't need any locktime exclusion.
226 2013-12-28 01:34:46 <rebroad> andytoshi, might it be because gettext-kde wasn't installed?
227 2013-12-28 01:35:19 <andytoshi> i don't think so, the undefined reference would be to something less bitcoiny then, no?
228 2013-12-28 01:35:20 <rebroad> andytoshi, probably not, just that i saw a warning about xgettext when i just ran configure... probably not related though
229 2013-12-28 01:35:29 <jtcwang> gmaxwell: true
230 2013-12-28 01:35:35 <andytoshi> but if so, configure should probably fail, so that'd be a bug
231 2013-12-28 01:39:16 <rebroad> I've made a patch for bitcoin-qt which brings up the client for spending bitcoins only and doesn't download or upload blocks/transactions. Might this be useful? If so, I'll do a pull request for it.
232 2013-12-28 01:41:05 <andytoshi> i think people would get double-spent pretty badly if this was easy to do
233 2013-12-28 01:41:25 <gmaxwell> why do you need a patch? start with -noconnect -nolisten ?
234 2013-12-28 01:41:36 <andytoshi> oh, never mind
235 2013-12-28 01:41:37 <gmaxwell> oh it'll still transmit? hm.
236 2013-12-28 01:42:12 <gmaxwell> though andy has a point that its kinda easy to doublespend yourself if you don't syncup before spending if you ever load another copy of your wallet. I dunno that its that much of a concern.
237 2013-12-28 01:43:08 <andytoshi> yeah, enabling double-spends is probably fine, exposing people to them is what i was worried about..
238 2013-12-28 01:43:14 <andytoshi> but i don't see that this would expose people to that risk
239 2013-12-28 01:46:30 <gribble> 277327
240 2013-12-28 01:46:30 <sipa> ;;blocks
241 2013-12-28 02:10:37 <jcorgan> in mike hearn's merge avoidance essay, he doesn't go into the optimal strategy for choosing a UTXO for a subset of a payment
242 2013-12-28 02:11:37 <jcorgan> is there a "best practices" for how to choose UTXOs?
243 2013-12-28 02:12:14 <sipa> "All you have to do is solve the subset sum problem"
244 2013-12-28 02:12:39 <jcorgan> i guess even when you only need a single UTXO, is it better, for example, to choose the smallest one greater than what you need, to create a small change output, or perhaps choose one twice the size to create a similar size change output?
245 2013-12-28 02:14:21 <jcorgan> maybe there is an optimal distribution of UTXO amounts and you should choose the one that leaves the remaining UTXOs plus change "closer" to this optimal distribution
246 2013-12-28 02:14:29 <sipa> well there are many things to prioritize: cost, size, privacy (through different means, even, ...)
247 2013-12-28 02:14:53 <sipa> even things like creating "nicely rounded" change outputs may have an impact on privacy
248 2013-12-28 02:16:11 <jtcwang> imagine if a coin has exponential growth rate (but hard capped), how would it play out?
249 2013-12-28 02:16:12 <jgarzik> ACTION waves at jcorgan
250 2013-12-28 02:16:40 <jtcwang> so you have something like block reward doubling every 200k blocks
251 2013-12-28 02:16:41 <justanotheruser> jtcwang: I doubt anyone would want to buy it, or mine it.
252 2013-12-28 02:17:03 <jtcwang> what if this coin is useful
253 2013-12-28 02:17:08 <jtcwang> say tied to a service
254 2013-12-28 02:17:13 <pigeons> justanotheruser: you would think that, but it seems people want to buy or mine anything with a blockchain or even without these days
255 2013-12-28 02:17:34 <justanotheruser> pigeons: Thats true.
256 2013-12-28 02:17:52 <justanotheruser> jtcwang: the coin wouldn't be useful then, the service would
257 2013-12-28 02:17:53 <jtcwang> so the exponential growth is to limit the amount of coins being released too soon
258 2013-12-28 02:18:19 <jtcwang> say if you need 1 coin to use the service
259 2013-12-28 02:18:44 <jtcwang> idk its just a thought exercise for me
260 2013-12-28 02:19:13 <justanotheruser> jtcwang: I'm guessing your exponential growth is to prevent the early adopters from having too much?
261 2013-12-28 02:19:37 <jtcwang> i guess so
262 2013-12-28 02:19:43 <jtcwang> like
263 2013-12-28 02:19:58 <jcorgan> i was just wondering if there were any established ways people have already come up with to choose a UTXO for a given spend, understanding there are lots of interacting motivations
264 2013-12-28 02:20:10 <jtcwang> i want the amount of coin available to be proportional to the mining power
265 2013-12-28 02:20:44 <jtcwang> so as adoption increases (more mining power), coins are released at a higher rate so the coin remain roughly the same value
266 2013-12-28 02:22:01 <pigeons> take a look at primecoin's generation, it isnt exactly like that, but somewhat
267 2013-12-28 02:22:08 <jtcwang> ok
268 2013-12-28 02:24:00 <kratek> hi all. does anybody can give me a clue with sendrawtransaction rpc command?
269 2013-12-28 02:25:12 <justanotheruser> kratek: sendrawtransaction <transaction in hex>
270 2013-12-28 02:26:10 <kratek> justanotheruser: i know. i have already send coins with sendraw command,but my problem is how to pay a fee for miners...
271 2013-12-28 02:26:58 <justanotheruser> kratek: the transaction pays the miners...
272 2013-12-28 02:27:33 <pigeons> make the output less than the input, the miners will take the extra
273 2013-12-28 02:28:15 <kratek> pigeons: Thank you i 'll try
274 2013-12-28 02:30:24 <BlueMatt> sipa: yea, for some reason I was thinking you'd have to do some script element hashing or something, but thats not true so, yea, essentially no overhead
275 2013-12-28 02:31:50 <miedda> correct channel for these types of questions, please let me know)
276 2013-12-28 02:31:50 <miedda> I've setup a testnet-in-a-box network to try and wrap my head around the api commands, I've mined several bit coins and transferred them from the default account using the move command, but for some reason when i try to do a sendfrom, i am getting a insufficient funds, error, i tried moving some coins back to the default account as I read somewhere that the default account is used and am still getting the same error. What am I missing? (if this is not t
277 2013-12-28 02:32:19 <rebroad> andytoshi, nope. the same error again...
278 2013-12-28 02:32:25 <rebroad> I'll raise an issue for this...
279 2013-12-28 02:35:23 <Luke-Jr> miedda: I don't see anything missing in what you described
280 2013-12-28 02:35:36 <Luke-Jr> miedda: but note that mined coins require 120 block confirmation before you can spend them
281 2013-12-28 02:36:51 <miedda> i was thinking it might be something along those lines as i ran into that issue with the non regtest client
282 2013-12-28 02:37:25 <miedda> would i just run setgenerate true a couple hundred times?
283 2013-12-28 02:39:10 <Luke-Jr> lol no
284 2013-12-28 02:39:14 <miedda> using bitcoin-cli how can i see if the coins have matured?
285 2013-12-28 02:39:20 <Luke-Jr> listtransactions
286 2013-12-28 02:40:54 <miedda> list transactions just shows all the move transactions
287 2013-12-28 03:15:04 <rfish> and if you are looking for a use for color coins
288 2013-12-28 03:15:40 <rfish> it is so the color coins can be exchanged on various markets..... such as markets that people don't like
289 2013-12-28 03:18:23 <gmaxwell> you don't have to have colored coins for that, you can simply hand over ledger keys if you're willing to trust those things to hold your assets. (or if the asset system supports multisigning, escrow your transactions via them)
290 2013-12-28 03:19:28 <rfish> it would seem simpler if all the various colored coins existed on one system
291 2013-12-28 03:20:43 <gmaxwell> no, thats only "simpler" if you pretend that the external costs you impose on others are free.
292 2013-12-28 03:21:14 <gmaxwell> Besides, there is no reason a single client couldn't be created that talked to many of these systems.
293 2013-12-28 03:21:55 <rfish> lets say the silk road wanted to use a currency that was backed by the dollar instead of bitcoin
294 2013-12-28 03:22:45 <rfish> and if all these parties got wind that the silk road was doing this and wanted to block it
295 2013-12-28 03:23:01 <rfish> how can the silk road protect itself
296 2013-12-28 03:23:40 <rfish> and disguise how these backed currencies are being traded
297 2013-12-28 03:23:56 <Polyatomic> bitcoind 0.8.6: what is the default value for minrelaytxfee=?
298 2013-12-28 03:25:55 <gmaxwell> rfish: digital dollar notes are regulatory nightmares and anyone doing them has rapidly been put out of business. But ignoring that, it's no different either way. If you use "colored coins" the provider of your dollars can just refuse to honor any colored transactions that don't have the right identifying information.
299 2013-12-28 03:26:10 <gmaxwell> You lose nothing with respect to that by using an external ledger, and you gain a lot of performance and scalablit.y
300 2013-12-28 03:27:50 <rfish> ok, I think I understand now
301 2013-12-28 03:27:58 <rfish> thank you
302 2013-12-28 03:28:59 <rfish> I guess if you have to trust a backer, you might as well trust him with his ledger
303 2013-12-28 03:30:34 <rfish> gmaxwell: And my idea for a backed dollar, is not to offer someone a dollar, but to offer someone the value of a dollar in terms of bitcoin when they redeam it
304 2013-12-28 03:31:34 <rfish> so a way to switch into a more stable currency when trading, and then when you want to cash out, swap the currency for bitcoin and then go sell it on an exchange
305 2013-12-28 03:31:40 <jgarzik> I'll gladly pay you Tuesday for a hamburger today.
306 2013-12-28 03:33:22 <rfish> well some people might like that offer
307 2013-12-28 03:34:29 <nsh> ACTION offers hamburger escrow services
308 2013-12-28 03:36:26 <rfish> lol
309 2013-12-28 03:37:06 <rfish> The idea is first you use bitcoins to buy a token of USD
310 2013-12-28 03:37:24 <rfish> I sell your bitcoin on an exchange and hold onto the dollar
311 2013-12-28 03:38:25 <rfish> and then when you want I can take the dollar token, buy bitcoin and give you back your value of the dollar in bitcoin
312 2013-12-28 03:38:42 <rfish> if people trust exchanges, why not trust that?
313 2013-12-28 03:39:10 <rfish> and that way I don't have to touch anyones fiat
314 2013-12-28 03:39:27 <rfish> perhaps makes me free from regulators
315 2013-12-28 03:40:05 <jcorgan> rfish: history (and jails) are rife with examples of people trying to be clever with US regulatory agencies
316 2013-12-28 03:41:07 <gmaxwell> Because its (probably) unlawfulâ at least varrious exchange operators who used to offer direct USD to USD transactions have concluded it wasn't a service they could lawfully provide. Perhaps you can find someone who is operating in outer mongolia who will do it, but they're the same people who are most likely to run off with everyone's funds.
317 2013-12-28 03:41:29 <gmaxwell> This is really far offtopic for #bitcoin-dev now.
318 2013-12-28 03:42:49 <rfish> I will continue #bitcoin
319 2013-12-28 04:06:22 <Plinker> I agree gmaxwell and think perhaps people are in for a surprise
320 2013-12-28 04:27:57 <jtcwang> f
321 2013-12-28 04:28:12 <TheLordOfTime> ?
322 2013-12-28 04:47:20 <numismatics> why doesn't bitcoin-qt show addresses used to split up a larger denomination received to a single receiving address?
323 2013-12-28 05:17:39 <jcorgan> sipa: do you expect your secp256k1 library to ever be used outside of the bitcoind context (assuming the switch happens)?
324 2013-12-28 05:21:16 <gmaxwell> After realizing the ed25519 has a cofactor of 8, and that secp256k1 is twist secure, I'm suddenly more fond of secp256k1. :P
325 2013-12-28 05:23:21 <jcorgan> i guess what i'm really wondering is if it will continue life as a shared library for use by dynamic linking with many projects, or just get incorporated into the source for bitcoind
326 2013-12-28 05:23:33 <jcorgan> (assuming it gets used)
327 2013-12-28 05:23:50 <andytoshi> is 'twist secure' a standard term?
328 2013-12-28 05:24:38 <phantomcircuit> jcorgan, most of the libraries we use are included in the source tree since upstream do not have the same consistency issues we do
329 2013-12-28 05:24:45 <phantomcircuit> so the answer is probably both
330 2013-12-28 05:26:25 <jcorgan> sure, thanks
331 2013-12-28 05:29:09 <mxiia> what is irc.smutfairy.com for?
332 2013-12-28 05:37:00 <netg> old method of finding nodes
333 2013-12-28 05:37:17 <netg> smutfairy is supposed to be a "funny" name for an legitimate irc server
334 2013-12-28 05:38:15 <mxiia> so it's a fallback now?
335 2013-12-28 05:38:59 <netg> cant answer, dont know for sure
336 2013-12-28 05:39:15 <netg> i think its supposed to be removed (or should be gone already)
337 2013-12-28 05:39:27 <mxiia> it's in the .6.4 source which is what most altcoins are based off of
338 2013-12-28 05:39:31 <mxiia> if you go on that server now
339 2013-12-28 05:39:37 <mxiia> there are hundreds of channels
340 2013-12-28 05:39:40 <mxiia> with a few users in each
341 2013-12-28 05:39:59 <mxiia> all just the usomethingsomething names
342 2013-12-28 05:40:04 <mxiia> it's kinda cool actually
343 2013-12-28 05:43:14 <netg> you are here in #bitcoin-dev
344 2013-12-28 05:43:25 <netg> .6.4 is not supported anymore
345 2013-12-28 05:43:31 <netg> as far as i understand it
346 2013-12-28 05:43:49 <netg> people wont help you with the old codebase
347 2013-12-28 05:45:03 <mxiia> not asking for "help" persay, just was curious as to the origins of that server and why it was in bitcoin's code
348 2013-12-28 05:45:18 <mxiia> thanks for the info though
349 2013-12-28 05:45:18 <netg> type in smutfairy on forum
350 2013-12-28 05:45:21 <netg> many threads
351 2013-12-28 05:45:34 <mxiia> google didn't yeild anything useful when I typed smutfairy
352 2013-12-28 05:45:42 <mxiia> http://infinitecointalk.org/index.php/topic,937.0.html was all i found
353 2013-12-28 05:45:45 <mxiia> not even bitcointalk
354 2013-12-28 05:45:58 <netg> try
355 2013-12-28 05:46:00 <netg> https://bitcointalk.org/index.php?topic=4049.0
356 2013-12-28 05:46:04 <netg> https://bitcointalk.org/index.php?topic=215.0
357 2013-12-28 05:46:21 <netg> https://bitcointalk.org/index.php?topic=256768.0
358 2013-12-28 05:50:01 <nessence> are there any good source mining pool servers? I only see eloipool on the wiki (rest say not maintained)
359 2013-12-28 05:51:01 <netg> wat?
360 2013-12-28 05:52:44 <nessence> All I'm finding is eloipool. I'd like to poke around the code where they're handling transactions
361 2013-12-28 05:57:32 <netg> dont know sorry, ask Luke-Jr
362 2013-12-28 06:02:24 <arioBarzan> does reference implementation relay a tx with an output with this scriptPubKey:
363 2013-12-28 06:02:26 <arioBarzan> OP_DUP OP_HASH160 <pubKey1Hash> OP_EQUALVERIFY OP_2 OP_SWAP <pubKey2> OP_2 OP_CHECKMULTISIG
364 2013-12-28 06:03:57 <arioBarzan> scriptSig would be OP_0 <sig1> <sig2> <pubKey1>
365 2013-12-28 06:05:11 <gmaxwell> no.
366 2013-12-28 06:06:57 <CodeShark> arioBarzan: didn't we go over this yesterday? :)
367 2013-12-28 06:11:01 <nessence> will https://github.com/spesmilo/libbitcoin become mainline?
368 2013-12-28 06:11:21 <BlueMatt> become mainline...what?
369 2013-12-28 06:11:32 <BlueMatt> its mainline libbitcoin..
370 2013-12-28 06:11:39 <arioBarzan> CodeShark: yes. but apparently you was not interested in such scriptPubKey. However I hope maybe someone else find it interesting so that in future reference client accept it :)
371 2013-12-28 06:12:24 <arioBarzan> CodeShark: Nevertheless I appreciate your very helpful comments yesterday.
372 2013-12-28 06:12:40 <nessence> BlueMatt: I mean, will the official client start to use it
373 2013-12-28 06:12:49 <BlueMatt> nessence: lol no
374 2013-12-28 06:13:31 <nessence> yeah. I'm trying to figure out what's where, so I don't build on top of something that will be maintained
375 2013-12-28 06:14:02 <BlueMatt> welcome to bitcoin...nothing is really maintained for long
376 2013-12-28 06:14:22 <nessence> yes. I was told that would happen to whatever I build too
377 2013-12-28 06:14:44 <nessence> It *does* get replicated everywhere though. Suppose that's something
378 2013-12-28 06:14:56 <BlueMatt> best bet: pick something that is being actively used
379 2013-12-28 06:15:03 <nessence> ACTION is creating the metacoin
380 2013-12-28 06:15:10 <nessence> j/k :)
381 2013-12-28 06:15:21 <BlueMatt> libbitcoin is old, but I think it was on hiatus for a long time
382 2013-12-28 06:15:23 <BlueMatt> bitcoinj is right up there (if you're willing to tolerate java)
383 2013-12-28 06:15:47 <BlueMatt> after that are ones which are used privately (eg lots of merchants have their own libs)
384 2013-12-28 06:16:40 <nessence> who needs java when you've got rand()
385 2013-12-28 08:05:49 <sipa> gmaxwell: twist secure?
386 2013-12-28 08:11:34 <gmaxwell> sipa: for some curves the quadratic twist (the other curve you get from the X values that are not on the curve) is not cryptographically sounds, and so in some protocols you can perform an attack where you trick someone into multiplying a point on the twist by their secret and then solve the DLP on the twist. I had _thought_ that the twist for secp256k1's order was relatively smooth and so solving the DLP on it is not extremely hard. But ...
387 2013-12-28 08:11:40 <gmaxwell> ... it turns out that some paper I'd read had the wrong order for it! and the actual twist is almost as hard as the curve.
388 2013-12-28 08:11:41 <sipa> BlueMatt: i have a ~working bip37 block download branch, but it's buggy and seems to miss blocks and is very slow
389 2013-12-28 08:14:29 <sipa> gmaxwell: ok, so "twist secure" == has a secure twist
390 2013-12-28 08:14:31 <BlueMatt> sipa: strange...missing blocks...how?
391 2013-12-28 08:15:24 <gmaxwell> sipa: yea.
392 2013-12-28 08:15:26 <sipa> BlueMatt: haven't investigated, but my guess is transactions that a peer assumes we have and doesn't send again
393 2013-12-28 08:15:55 <sipa> while they already have expired from our relay pool
394 2013-12-28 08:16:35 <BlueMatt> sipa: bitcoinj solves this (iirc) by pinging right after requesting the block, and then when it gets the pong, requesting any txn its missing
395 2013-12-28 08:16:46 <BlueMatt> no, wait, that doesnt work...
396 2013-12-28 08:16:50 <BlueMatt> well, I dont remember
397 2013-12-28 08:16:58 <sipa> it doesn't help
398 2013-12-28 08:17:47 <sipa> if we need to ask for missing transactions, there is an extra roundtrip, which makes it likely slower than full block download for many connections
399 2013-12-28 08:18:23 <BlueMatt> you also cant request missing txn since they are no longer in mempool
400 2013-12-28 08:18:53 <sipa> eggtrue
401 2013-12-28 08:18:56 <sipa> huh
402 2013-12-28 08:18:58 <sipa> true
403 2013-12-28 08:19:26 <gmaxwell> yuck.
404 2013-12-28 08:21:33 <gmaxwell> sounds like we really do need a protocol extension for this.
405 2013-12-28 08:21:43 <BlueMatt> ahh, yes, bitcoinj just doesnt care (if the txn isnt a fp then bitcoinj has it since it was added to wallet, so we are no worse off trusting the peer's txn list than other withholding attacks)
406 2013-12-28 08:23:06 <sipa> gmaxwell: i don't see how to do it without extra roundtrip
407 2013-12-28 08:23:59 <BlueMatt> send a list of txn in your mempool (or bloom filter over them or whatever)!
408 2013-12-28 08:24:00 <BlueMatt> :(
409 2013-12-28 08:24:34 <sipa> a bloom filter won't work, as you cannot tolerate false positives here
410 2013-12-28 08:25:02 <gmaxwell> sipa: can do it without an extra roundtrip if there is some normative determinstic cache retention policy.
411 2013-12-28 08:25:05 <gmaxwell> bleh
412 2013-12-28 08:25:08 <BlueMatt> sure you can, the filteredblock tells you which txn you are gonna care about, and false positives just means you get more than you want
413 2013-12-28 08:25:28 <BlueMatt> but, thats just dumb, really
414 2013-12-28 08:25:28 <gmaxwell> huh?
415 2013-12-28 08:25:42 <gmaxwell> BlueMatt: I don't see how that avoids an extra round trip.
416 2013-12-28 08:25:56 <sipa> if you send a bloomfilter over your mempool, the peer will think you have something you do not...
417 2013-12-28 08:26:02 <BlueMatt> gmaxwell: you send the set of txn in your mempool along with the request for the filtered block
418 2013-12-28 08:26:05 <BlueMatt> sipa: doh
419 2013-12-28 08:27:13 <sipa> the extra roundtrip is not really a problem, if you move it a step ahead (inv,getdata,filteredblock) becomes (inv,mempool+getdata,filteredblock)
420 2013-12-28 08:27:43 <sipa> well, mempool+relaypool+orphanpool
421 2013-12-28 08:28:13 <sipa> ...
422 2013-12-28 08:30:36 <gmaxwell> I'd have a solution if all the transactions were the same size. In that case, you send the list (or better truncated listâ only need â say 64 bits to distinguish) and then the sender computes a (N-transactions, 65535) Reed Solomon code over the transaction data, and sends M non-syndromic codewords from the RS code. And then you can reconstruct up to M missing transactions without the sender knowing which ones. :P
423 2013-12-28 08:30:46 <gmaxwell> oops, this isn't #bitcoin-wizards
424 2013-12-28 08:33:23 <midnightmagic> zfec is free and appears to be the fastest erasure-coding generally-applicable k-of-m tool that is widely used, so that avenue might be less onerous
425 2013-12-28 08:34:10 <gmaxwell> midnightmagic: the same size constraint is onerous, alas. as it would make all the extra codewords the same size as the largest txn, which would be super lame.
426 2013-12-28 08:34:39 <midnightmagic> implicit zero-padding?
427 2013-12-28 08:34:52 <gmaxwell> There is plenty of easily found public domain 2^16 RS code out there. Otherwise it would be kinda nifty to use an erasure code to remove the round trip.
428 2013-12-28 08:34:55 <midnightmagic> mmf no, nevermind
429 2013-12-28 08:35:21 <gmaxwell> midnightmagic: yea, implicit zero-padding is what results in all the extra codewords being the size of the largest txn.
430 2013-12-28 08:35:50 <sipa> break up the transactions into 32-byte blocks or so?
431 2013-12-28 08:36:21 <sipa> i don't actually understand your proposal, btw...
432 2013-12-28 08:36:22 <gmaxwell> yea, you'd have to transmit the transaction sizes, I think. the reciever needs to know the sizes of the holes.
433 2013-12-28 08:36:51 <midnightmagic> one additional limitation also: zfec, while blindingly fast, does no integrity checking on its own
434 2013-12-28 08:37:12 <midnightmagic> still.. <3 zfec.
435 2013-12-28 08:38:00 <midnightmagic> packed tx set data structure?
436 2013-12-28 08:40:31 <gmaxwell> sipa: say I have 10 bytes b_[0..9], some of which you may know already, but I dunno which. I can use some RS code over bytes to expand those 10 bytes to up to 255 bytes, the the first 10 entries untouched and b_[10..255] are new ones. Now I assume you have at least 5 of 0..9 and so I send you 10,11,12,13,14 (and, of course, I tell you what I'm sending). Now, if I was right and you have at least 5, no matter which they were, you can ...
437 2013-12-28 08:40:37 <gmaxwell> ... reconstruct all 10.
438 2013-12-28 08:41:40 <gmaxwell> so I'm saying that this could be done for transmitting transactions so long as you have a good guess on how much data may be missing, you can send recovery data to recover up to that much, without knowing which data was missing.
439 2013-12-28 08:42:46 <gmaxwell> though this is probably all too much rocket science for the protocol today, it might be fun as a secondary block relay protocol.
440 2013-12-28 13:10:54 <monolithik> does the bitcoin protocol assume universal connectivity between nodes?
441 2013-12-28 13:18:56 <gmaxwell> no
442 2013-12-28 13:20:01 <gmaxwell> monolithik: bitcoin 101 questions will usually get better answers in #bitcoin, this channel is supposted to be for active development work.
443 2013-12-28 13:30:03 <monolithik> gmaxwell: sorry, agreed.
444 2013-12-28 13:48:53 <tholenst> It seems to me that getrawmempool doesn't list the orphaned transactions. Is that on purpose?
445 2013-12-28 13:51:10 <gmaxwell> tholenst: they're not considered in the mempool. we don't even know if they're valid or not.
446 2013-12-28 13:52:01 <tholenst> I see. Yes, I see it makes more sense not to list them, at least by default.
447 2013-12-28 16:09:38 <jacob___> hi
448 2013-12-28 16:09:49 <jacob___> what are rev00xxx.dat files?
449 2013-12-28 16:09:54 <jacob___> qt client
450 2013-12-28 16:09:59 <jacob___> satoshi client
451 2013-12-28 16:10:37 <jacob___> anyone?
452 2013-12-28 16:11:00 <sipa> undo data for the chainstate
453 2013-12-28 16:11:41 <sipa> so blocks can be reverted
454 2013-12-28 16:11:49 <sipa> which is needed during reorganization
455 2013-12-28 16:13:19 <jacob___> demn
456 2013-12-28 16:13:22 <jacob___> thanks sipa
457 2013-12-28 16:13:31 <jacob___> i dont know what you are talking about though)
458 2013-12-28 16:14:09 <jacob___> why would blocks need to be reverted, and what does reverted mean?
459 2013-12-28 16:14:25 <jacob___> why would blocks need to be reverted, and what does "reversion" mean?
460 2013-12-28 16:14:35 <sipa> the chainstate is basically the set of all unspent transaction outputs
461 2013-12-28 16:14:37 <jacob___> ^^ better phraised i think
462 2013-12-28 16:14:50 <jacob___> cool
463 2013-12-28 16:14:54 <jacob___> makes sense
464 2013-12-28 16:14:57 <sipa> every block contains transactions, each transaction consumes somes outputs, and produces some new ones
465 2013-12-28 16:15:02 <sipa> 5inputs qnd outputs-
466 2013-12-28 16:15:11 <jacob___> so all "transaction - leafs" end up in chainstate?
467 2013-12-28 16:15:21 <sipa> only the outputs
468 2013-12-28 16:15:36 <jacob___> yeah because inputs are never leaves
469 2013-12-28 16:15:41 <jacob___> wouldnt make sense
470 2013-12-28 16:15:43 <sipa> that makes no sense
471 2013-12-28 16:15:51 <sipa> leaves of what?
472 2013-12-28 16:16:15 <jacob___> if an output is not an input of another transaction then it goes into chainstate? is this statement correct?
473 2013-12-28 16:16:25 <sipa> yes
474 2013-12-28 16:16:31 <sipa> that's the "unspent" part
475 2013-12-28 16:16:38 <sipa> when a block is activated, its transactions' outputs are added to the chainstate, and the outputs consumed by its inputs are removed
476 2013-12-28 16:16:51 <jacob___> so in chainstate we see all the money that was never spent))
477 2013-12-28 16:16:57 <sipa> indeed
478 2013-12-28 16:17:17 <sipa> sometimes a fork appears, it may happen that the other side is extended, so we need to switch to a new chain
479 2013-12-28 16:17:32 <sipa> in that case, the last few blocks have to be reverted first
480 2013-12-28 16:17:42 <sipa> its inputs added back to the chainstate, and its outputs removed
481 2013-12-28 16:17:46 <jacob___> reversion is bascily undo
482 2013-12-28 16:17:52 <sipa> the rev* files contain the undo data
483 2013-12-28 16:17:54 <jacob___> reversion is bascily an "undo operation"
484 2013-12-28 16:17:58 <sipa> yes
485 2013-12-28 16:18:47 <jacob___> wow,.., isnt that a bit "dangerous"? I mean a fork is basicly after the network conforms the transaction?
486 2013-12-28 16:19:24 <jacob___> so , i sent some coin,.., confirmation....oops undo because of fork?
487 2013-12-28 16:20:28 <jacob___> i understand chainstate and the blk files))..., no i need to understand the rev files.... i guess thats just a "before image" of the transaction?
488 2013-12-28 16:22:46 <jacob___> sipa i tried google "revxxxdat bitcoin" but didnt come up with any hits, can you point me to a link where it is explained, dont want to take to much of your time thanks
489 2013-12-28 16:22:54 <jacob___> (or anyone else if he/she knows link)
490 2013-12-28 16:41:11 <deanclkclk> folks...do u think it's possible to rent a dedicated server for bitcoin mining?
491 2013-12-28 16:41:48 <gfawkes_> anyone have any problems maintaining network connectivity while running bitcoind continuously?
492 2013-12-28 16:42:00 <gfawkes_> deaclkclk - bitcoin-mining might be a better place to ask
493 2013-12-28 16:42:51 <gfawkes_> its almost like as soon as i bring my node online im either getting slammed by someone or my isp is throttling or cutting off connectivity =\
494 2013-12-28 16:43:34 <gfawkes_> i discount the latter bc its not like i just started running a node and my isp hasnt given me problems before
495 2013-12-28 16:44:15 <gfawkes_> are there any reports of nodes getting ddos'd?
496 2013-12-28 17:11:27 <sipa> jacob___: it contains the outputs that were spent by a particular block
497 2013-12-28 17:11:37 <sipa> jacob___: so they can be restored when reverting a block
498 2013-12-28 17:12:13 <jacob___> sipa,.., is there a fileformat description, or do i need to dive into source code((
499 2013-12-28 17:12:13 <sipa> jacob___: i doubt there's any document that really explains it
500 2013-12-28 17:12:18 <jacob___> haha
501 2013-12-28 17:12:22 <jacob___> crosspost
502 2013-12-28 17:12:30 <sipa> what do you need it for?
503 2013-12-28 17:12:43 <sipa> it's not really intended to be used by anything but bitcoind
504 2013-12-28 17:12:45 <jacob___> I need to parse the blockchain
505 2013-12-28 17:12:52 <sipa> no need for the undo data
506 2013-12-28 17:13:07 <jacob___> fair enough,.., i needed to know all structures
507 2013-12-28 17:13:09 <sipa> there's nothing uniaue in it
508 2013-12-28 17:13:15 <sipa> unique
509 2013-12-28 17:13:29 <jacob___> ok
510 2013-12-28 17:13:39 <jacob___> is there a description of chainstate?
511 2013-12-28 17:13:39 <sipa> the block files do have a standard formqt
512 2013-12-28 17:13:42 <sipa> format
513 2013-12-28 17:13:59 <sipa> again, not intended to be used by anything but bitcoin
514 2013-12-28 17:14:01 <jacob___> i noted a link to the blockchain format
515 2013-12-28 17:14:19 <jacob___> i understand chainstate is sort of an index
516 2013-12-28 17:14:27 <sipa> not at all
517 2013-12-28 17:14:30 <jacob___> oh
518 2013-12-28 17:14:38 <sipa> it's the set of all unspent transaction outputs
519 2013-12-28 17:14:44 <sipa> that's all
520 2013-12-28 17:14:45 <jacob___> yeah......
521 2013-12-28 17:14:50 <sipa> nothing index in it
522 2013-12-28 17:15:02 <jacob___> i think its a semantic problem again)))
523 2013-12-28 17:15:24 <sipa> an index implies it' contains references to other data
524 2013-12-28 17:15:33 <jacob___> yes indeed
525 2013-12-28 17:15:43 <jacob___> and in this case...it contains transaction id's?
526 2013-12-28 17:15:43 <sipa> that's not the case; it's not pointers to where things are found in the blockchain
527 2013-12-28 17:15:59 <sipa> it's just a database with all unspent transaction outputs
528 2013-12-28 17:16:32 <jacob___> a transaction id is just a number right
529 2013-12-28 17:16:41 <sipa> yes
530 2013-12-28 17:16:49 <jacob___> so the chainstate is a bunch of numbers
531 2013-12-28 17:17:16 <jacob___> of these transaction id's
532 2013-12-28 17:17:16 <sipa> well;, in that case all computer data is just a bunch of numbers
533 2013-12-28 17:17:37 <sipa> the chainstate is much more thqn just txids
534 2013-12-28 17:18:05 <sipa> for every txid; it contains the unspent transaction outputs of that transaction, and some metadata
535 2013-12-28 17:18:12 <jacob___> I would like to know the file format
536 2013-12-28 17:18:21 <sipa> really, this is internal stuff to bitcoind, you should not need to care about it
537 2013-12-28 17:18:23 <jacob___> where can i find it
538 2013-12-28 17:18:27 <sipa> in the sourcecode
539 2013-12-28 17:18:41 <jacob___> cool, do you know wich specific c file?
540 2013-12-28 17:18:45 <jacob___> or cpp file
541 2013-12-28 17:18:51 <sipa> coins.cpp in git head
542 2013-12-28 17:18:54 <sipa> and coins.h
543 2013-12-28 17:19:01 <jacob___> greeeeeeeeeeaaaaaat
544 2013-12-28 17:19:17 <sipa> but really, you're on a side track
545 2013-12-28 17:19:22 <sipa> there's no point in using this data
546 2013-12-28 17:19:28 <jacob___> maybe...
547 2013-12-28 17:19:34 <sipa> it's not accessible anyway while bitcoind is running
548 2013-12-28 17:19:39 <sipa> or bitcoin-qt
549 2013-12-28 17:19:46 <jacob___> ok
550 2013-12-28 17:19:56 <sipa> if you need access to the data in it, use the gettxout and gettxoutsetinfo RPC commands
551 2013-12-28 17:20:01 <sipa> but really, don't
552 2013-12-28 17:20:25 <sipa> https://github.com/bitcoin/bitcoin/blob/master/src/coins.h#L17
553 2013-12-28 17:20:36 <sipa> the value format is documented there
554 2013-12-28 17:21:08 <sipa> the chainstate itself is a leveldb database, with key-value pairs, where the keys are txids and the values are byte arrays obtained through that format described in that file
555 2013-12-28 17:21:15 <wallet42> can i use signrawtransaction to sign "normal" transactions (send to p2h)
556 2013-12-28 17:21:40 <sipa> wallet42: yes
557 2013-12-28 17:23:41 <sipa> jacob___: what are you actually trying to do?
558 2013-12-28 17:24:13 <jacob___> just wanting to know more about qt client nitty gritty
559 2013-12-28 17:24:31 <sipa> that's very different from "trying to parse the blockchain"
560 2013-12-28 17:24:46 <jacob___> i am on github checking coin.cpp out
561 2013-12-28 17:24:52 <jacob___> coins.cpp*
562 2013-12-28 17:26:09 <sipa> start with the .h file
563 2013-12-28 17:32:52 <jacob___> jesus 24xxx forks. lol
564 2013-12-28 17:32:57 <jacob___> jesus 24xx forks. lol
565 2013-12-28 17:33:28 <lianj> good talk at saal1 30c3 now. "year in crypto"
566 2013-12-28 17:33:44 <sipa> jacob___: ?
567 2013-12-28 17:34:54 <jacob___> sipa the number of forks on github
568 2013-12-28 17:34:58 <sipa> oh
569 2013-12-28 17:35:05 <sipa> who cares :)
570 2013-12-28 17:35:47 <jacob___> impressive i think
571 2013-12-28 17:35:54 <jacob___> will be more i am sure , anyway
572 2013-12-28 17:36:15 <jacob___> sipa, what does "coinbase" intail?
573 2013-12-28 17:39:08 <sipa> it's the first transaction in each block
574 2013-12-28 17:39:30 <sipa> which is special, as it doesn't really have an input, but instead received fees and subsidy from block creation
575 2013-12-28 17:43:11 <jacob___> cool
576 2013-12-28 17:43:35 <sipa> this is more 3bitcoin stuff
577 2013-12-28 17:43:40 <sipa> #bitcoin, i mean
578 2013-12-28 17:47:44 <jacob___> sipa, ok.., i thought talking about C++ code would be a bitcoin-dev question
579 2013-12-28 17:48:21 <jacob___> excuse the confaltion
580 2013-12-28 17:48:26 <jacob___> conflation
581 2013-12-28 18:27:55 <TD> interesting new site with charts/block explorer: http://blockr.io/charts