1 2012-10-06 00:06:12 <helo> anyone know when the devs get back from the bars?
  2 2012-10-06 00:07:31 <CoinHoarder> Thanks to silk road, the parties going all night long ;)
  3 2012-10-06 00:09:40 <jaxtr> what happened to glbse
  4 2012-10-06 00:10:15 <CoinHoarder> I don't think anyone knows for certain what happened
  5 2012-10-06 00:10:24 <CoinHoarder> Just that it's down right now
  6 2012-10-06 00:11:01 <CoinHoarder> scam accustations going on right now about GLSBE: https://bitcointalk.org/index.php?topic=115669.0
  7 2012-10-06 00:11:08 <CoinHoarder> -t
  8 2012-10-06 00:12:33 <gmaxwell> wow. thats pretty damning.
  9 2012-10-06 00:12:45 <gmaxwell> theymos is not one to just slap loose accusations.
 10 2012-10-06 00:12:55 <gmaxwell> Where is Nefario (what a name!) located?
 11 2012-10-06 00:13:05 <Raccoon> Nigeria?
 12 2012-10-06 00:13:13 <Diablo-D3> https://bitcointalk.org/index.php?topic=115669.0
 13 2012-10-06 00:13:15 <Diablo-D3> oh
 14 2012-10-06 00:13:15 <gmaxwell> come on, be serious.
 15 2012-10-06 00:13:17 <Diablo-D3> CoinHoarder beat me
 16 2012-10-06 00:13:22 <Raccoon> Nefarlands
 17 2012-10-06 00:13:41 <CoinHoarder> :P
 18 2012-10-06 00:13:51 <Diablo-D3> so
 19 2012-10-06 00:13:52 <Diablo-D3> fuck this
 20 2012-10-06 00:13:58 <CoinHoarder> I've heard he lives in England
 21 2012-10-06 00:14:01 <CoinHoarder> not sure tho
 22 2012-10-06 00:15:00 <Raccoon> so what is GLBSE and why would the FBI shut them down?
 23 2012-10-06 00:15:37 <Diablo-D3> fbi? wrong office.
 24 2012-10-06 00:15:45 <Diablo-D3> you really mean the sec, and thats wrong too, hes not in the US
 25 2012-10-06 00:16:28 <CoinHoarder> The UK has the FSA = same thing as SEC
 26 2012-10-06 00:16:46 <CoinHoarder> again, second hand knowledge, not sure about it.
 27 2012-10-06 00:17:12 <Raccoon> the FBI is a global organization, with offices in every soverign nation
 28 2012-10-06 00:17:15 <Diablo-D3> no, hes just a fucking liar
 29 2012-10-06 00:17:28 <Diablo-D3> Raccoon: go troll somewhere else
 30 2012-10-06 00:17:37 <Raccoon> but it's so.
 31 2012-10-06 01:19:04 <metadevdev> hey guys
 32 2012-10-06 01:19:08 <metadevdev> anyone on?
 33 2012-10-06 01:20:05 <gmaxwell> no.
 34 2012-10-06 01:20:30 <metadevdev> haha
 35 2012-10-06 01:57:39 <jgarzik> https://glbse.com/ appears to have been updated, with this message: https://bitcointalk.org/index.php?topic=115669.msg1249246#msg1249246
 36 2012-10-06 01:57:53 <jgarzik> "We will begin retuning bitcoin once we have recieved all coins from the GLBSE treasurer that manages the GLBSE cash reserves. BitcoinGlobal (GLBSE's partent company) shareholders and board voted for them to be returned immediately, we are awaiting compliance with this order."
 37 2012-10-06 01:58:20 <jgarzik> I think the treasurer is theymos
 38 2012-10-06 01:58:37 <Diablo-D3> dont hold your breath
 39 2012-10-06 01:58:51 <theymos> Yeah, I am.
 40 2012-10-06 01:59:19 <theymos> jgarzik: Can bitbonds eventually replace GLBSE, you think?
 41 2012-10-06 01:59:27 <jgarzik> theymos: yes
 42 2012-10-06 02:00:43 <theymos> Cool. That'd be a lot better than a centralised site.
 43 2012-10-06 02:00:47 <jgarzik> theymos: distributed bonds are simply coins like any other bitcoins, that are treated specially by the holders.
 44 2012-10-06 02:01:16 <theymos> Do you use 0-value coins?
 45 2012-10-06 02:01:39 <gmaxwell> I'm skeptical. Probably the _most_ two valuable thing GLBSE did was screen issuers somewhat so that 99-of-100 weren't instant scams; and allowing open orders for offline users so that there can be some liquidity.
 46 2012-10-06 02:02:01 <jgarzik> theymos: I send you 1-satoshi.  I am the bond issuer.  Anyone you send that specific satoshi coin to becomes the bond holder.
 47 2012-10-06 02:02:19 <jgarzik> theymos: no zero value outputs.  I like that there is an associated cost.
 48 2012-10-06 02:02:26 <jgarzik> encourages efficiency
 49 2012-10-06 02:03:05 <theymos> gmaxwell: Exchanges and verification services could be set up for bitbonds. But it wouldn't be so centralized.
 50 2012-10-06 02:03:23 <jgarzik> gmaxwell: A fair criticism.  The design sketch includes a space for ratings.  You just have to build a trust network with that
 51 2012-10-06 02:03:30 <theymos> jgarzik: How do you prevent an asset from being split?
 52 2012-10-06 02:03:31 <gmaxwell> theymos: then those would be the GLBSE replacement.
 53 2012-10-06 02:04:41 <theymos> gmaxwell: Yeah, but different sites can share assets. If one site goes down, some other site can easily replace it. And it also increases competition.
 54 2012-10-06 02:05:05 <gmaxwell> jgarzik: I've yet to see evidence that online trust networks are actually effective. OTC wot's has not been a tremendous success. A lot of people get scammed. ::shrugs::
 55 2012-10-06 02:05:10 <jgarzik> theymos: 1-satoshi == 1 bond, by the ruleset I prefer.  The sender and recipient both must agree on the "rules", namely preserving "BOND<HASH>OP_DROP".  If you fail to preserve that, you burn the bond.  If an imposter tries to add a bond message, the bond issuer can easily trace the coin history, and see that it is an invalid bond.
 56 2012-10-06 02:05:59 <jgarzik> theymos: the bond issuer is responsible for scanning the blockchain, verifying final ownership of each bond
 57 2012-10-06 02:06:52 <theymos> Can the asset creator issue more bonds?
 58 2012-10-06 02:06:57 <jgarzik> theymos: more generally, if a sender->recipient breaks the "rules" expected by the bond issuer, they won't get paid
 59 2012-10-06 02:07:13 <gmaxwell> theymos: of course they can??? they _define_ what the bond means.
 60 2012-10-06 02:07:16 <jgarzik> theymos: sure
 61 2012-10-06 02:07:26 <theymos> Sounds good. I like that design. That's similar to the design I had in mind for DNS.
 62 2012-10-06 02:07:29 <jgarzik> theymos: you are at the mercy of the bond issuer, for all
 63 2012-10-06 02:07:36 <gmaxwell> since you have to trust the issuer, why not just have them manage all the bond ownership in a provable way? e.g. via OT?
 64 2012-10-06 02:07:43 <jgarzik> theymos: you are at the mercy of the bond issuer, for payment, for proper tracking of bond holders in the chain, ...
 65 2012-10-06 02:08:11 <jgarzik> theymos: there is no concept of an "asset" or "issue", only the individual bonds
 66 2012-10-06 02:09:48 <gmaxwell> This is all pretty squarely inside what OT is intended to handle.. outside of what bitcoin is intended for. :(  I fear you've got a hammer and everything is a nail.
 67 2012-10-06 02:09:53 <amiller> it's interesting you say you rely on the issuer to properly track the bond holders
 68 2012-10-06 02:10:22 <gmaxwell> amiller: of course, other people might do so too.. but if the issuer doesn't all bets are off.
 69 2012-10-06 02:11:40 <jgarzik> amiller: you rely on the issuer to pay back the bond, whatever the medium
 70 2012-10-06 02:12:05 <gmaxwell> or grant you your voting rights or whatever other benefit holding the bond confers.
 71 2012-10-06 02:12:49 <jgarzik> gmaxwell: my general response is the same as TD's...  it is a small price to pay for a decentralized financial system, to have atomic smart property/payment swaps
 72 2012-10-06 02:13:07 <jgarzik> No other solution is as secure, atomic and reliable
 73 2012-10-06 02:13:35 <gmaxwell> Your system isn't secure at all. It has complete and ultimate trust on the issuer.
 74 2012-10-06 02:13:37 <amiller> just because you have to rely on them to pay back the bond doesn't mean you also rely on them to do proper accounting
 75 2012-10-06 02:14:02 <gmaxwell> If the issuer defects or defaults the users have no recourse, and even have no system provided mechenism to _prove_ that the default happened.
 76 2012-10-06 02:14:12 <amiller> suppose they have insurance
 77 2012-10-06 02:14:22 <amiller> then that would be their recourse, and in fact all bets would not be off if the issuer defaults
 78 2012-10-06 02:14:28 <jgarzik> amiller: independent third parties can track issuers through the chain, and verify that they make payments as claimed
 79 2012-10-06 02:14:39 <jgarzik> assuming you follow the standard bond spec
 80 2012-10-06 02:14:49 <gmaxwell> Vs OT which _can_ have some of those properties at least for contract terms which can be expressed with the ricardian contracts rules stuff.
 81 2012-10-06 02:16:38 <jgarzik> OT is the height of bleh
 82 2012-10-06 02:16:42 <gmaxwell> the only advantage I'm aware of for the bitcoin bond stuff is the atomic trades. But it comes at the cost of making real market like liquidity either non-existant or at least risky (lots of systems with private signing keys online at all times).
 83 2012-10-06 02:16:46 <jgarzik> ever read the code?
 84 2012-10-06 02:18:04 <gmaxwell> so to really have the sort of usable liquid markets that people will absolutely want the bonds will have to move into some centeralized market maker systems. This improves a ton of stuff, but moots the easy transferance value... and the external market can't obviously be made tamperproof.
 85 2012-10-06 02:18:10 <gmaxwell> jgarzik: yes. :(
 86 2012-10-06 02:18:31 <jgarzik> gmaxwell: that's part of why I won't touch OT with a ten foot pole
 87 2012-10-06 02:19:37 <jgarzik> yeah I think multiple people will create bond exchanges
 88 2012-10-06 02:19:48 <dakid> gmaxwell: my client keeps crashing, is it a known bug with macosx, i'm running bitcoin-qt 0.7-beta on osx 10.8.2
 89 2012-10-06 02:19:50 <jgarzik> just like with bitcoin exchanges
 90 2012-10-06 02:20:01 <gmaxwell> (I mean, bitcoin / litcoin  ; bitcoin / namecoin  trades are not hard to make atomic, secure, and decenteralized ... but _everyone_ uses an exchange. I'm pretty sure no secure trade cross those compatible cryptocoins has ever happened)
 91 2012-10-06 02:20:24 <jgarzik> yep
 92 2012-10-06 02:20:30 <gmaxwell> dakid: anything at the bottom of the debug.log file after it crashes?
 93 2012-10-06 02:21:56 <gmaxwell> jgarzik: and although there are 'big' volumes of those trades made... nothing. And they've been possible to make in a secure manner for as long as they've existed...  I don't believe there is a demand for the technical features you're providing.
 94 2012-10-06 02:22:14 <gmaxwell> Otherwise we'd see decenteralized exchange of ltc/nmc/btc. No?
 95 2012-10-06 02:23:03 <jgarzik> That's quite a bit different from smart property built on colored coins
 96 2012-10-06 02:23:05 <dakid> is this significant: ERROR: FetchInputs() : 70449ff9d8 mempool Tx prev not found 5fd035b182
 97 2012-10-06 02:23:22 <gmaxwell> dakid: no.
 98 2012-10-06 02:23:23 <jgarzik> It's a bad example besides... no market for alt-coins
 99 2012-10-06 02:23:35 <jgarzik> They can barely support a one-person hackable centralized exchange
100 2012-10-06 02:23:56 <gmaxwell> jgarzik: nmc and ltc markets are each probably as liquid as the sum of everything on glbse.
101 2012-10-06 02:24:03 <dakid> gmaxwell: let me see if i can crash it, and then ill check the debug.log
102 2012-10-06 02:24:17 <gmaxwell> jgarzik: there are several exchanges, in fact.
103 2012-10-06 02:24:22 <gmaxwell> but ::shrugs::
104 2012-10-06 02:25:15 <theymos> Last time I looked into OT there wasn't much documentation and it seemed way over-complicated.
105 2012-10-06 02:25:42 <gmaxwell> if that were its only problems???
106 2012-10-06 02:25:46 <amiller> OT is really disappointing, it explicitly leaves you vulnerable to the server operator counterfeiting bonds
107 2012-10-06 02:26:13 <gmaxwell> amiller: yes, but so does this.
108 2012-10-06 02:27:29 <jgarzik> counterfeiting?  or just adding dilution by issuing more bonds?
109 2012-10-06 02:27:35 <amiller> no way, this is totally different
110 2012-10-06 02:27:37 <jgarzik> printing new != copying old
111 2012-10-06 02:27:38 <amiller> the difference is in detectability
112 2012-10-06 02:27:40 <dakid> gmaxwell: If its any help, it always occurs right after I enter my wallet password during a transaction
113 2012-10-06 02:28:07 <jgarzik> distributed bonds are designed to be traced through the chain by third party verification software
114 2012-10-06 02:28:30 <amiller> in OT, if the server operator and the issuer collude then no one will notice. it is not part of the system that the server operator is transparent/public
115 2012-10-06 02:28:37 <gmaxwell> Okay, atltcoin markets are a bit smaller than they used to be.. currently only about 2000 BTC on open buy orders.
116 2012-10-06 02:28:55 <gmaxwell> amiller: it addresses this by letting you have any number of server operators.
117 2012-10-06 02:28:57 <amiller> in distributed bonds there is no private information and no designated server operator
118 2012-10-06 02:28:58 <jgarzik> sure you can print more, but everybody can see that
119 2012-10-06 02:29:36 <gmaxwell> amiller: and I don't agree that its not the same thing, in jeff's stuff the issuer can keep printing bonds all day long... even if there is nothing to back them.
120 2012-10-06 02:29:43 <amiller> k-of-N privileged entities =/= public participation
121 2012-10-06 02:31:12 <gmaxwell> (nor can you tell that they're doing it, so long as the bonds are orthorgonalized and you don't all go consult each other... e.g. "I thought alpaca socks corp was bond 12345, why do you say its 2345?"
122 2012-10-06 02:31:49 <jgarzik> you start out with a single output for N satoshis == N bonds.  that's associated with a hash
123 2012-10-06 02:31:52 <amiller> sure, lets just say the issuer can default
124 2012-10-06 02:31:54 <jgarzik> any change means new hash, new details
125 2012-10-06 02:32:07 <amiller> yes that's true in both cases - the difference is whether or not the issuer is responsible for keeping his own books or whether those are public
126 2012-10-06 02:32:49 <amiller> i think we should roughly model how insurance or auditing or these independent third parties would work
127 2012-10-06 02:33:03 <amiller> (FellowTraveller is forever stuck working on the 'auditing protocol' which i don't think is viable)
128 2012-10-06 02:33:09 <gmaxwell> amiller: OT at least gives you an organized way to k-of-N them.  colored coin bonds do not. You can publically trace around a single bond but you can't tell how many the issuer has let without their help.
129 2012-10-06 02:33:47 <amiller> oh
130 2012-10-06 02:33:55 <amiller> are single bonds individual?
131 2012-10-06 02:34:07 <amiller> do they split/merge or do they stay integral
132 2012-10-06 02:34:35 <amiller> i assumed there would be at least a notion of bonds from a specific issuance, like when a company is founded with a thousand shares and each of those can be tracked
133 2012-10-06 02:35:02 <jgarzik> 
ACTION was designing a graph, where all nodes start from a single one, nValue = X, where X is the number of bonds in a "bundle" that is tracked/rated/etc. together.

134 2012-10-06 02:35:21 <gmaxwell> That could certantly be arranged, but you can't discover another issuance, even so.
135 2012-10-06 02:35:24 <jgarzik> that is the root for tracking
136 2012-10-06 02:35:50 <jgarzik> gmaxwell: not sure that is solvable... any actor can publish more bonds, smart property or not
137 2012-10-06 02:36:01 <amiller> gmaxwell, that isn't solvable and there are simpler expressions for the same attack
138 2012-10-06 02:36:08 <amiller> the issuer can default for any personal reasons
139 2012-10-06 02:36:21 <amiller> e.g. if he has multiple identities that all default
140 2012-10-06 02:37:08 <gmaxwell> Yes, I'm aware of this??? and it's why I don't see much value in having tracking except as provided by the issuer or his designees... standardizing that tracking so it's portable and provable has value.
141 2012-10-06 02:37:30 <amiller> what's important is that within the set of a single issuance, for example any of the 1000 shares of a company that is publicly founded, that you can tell if any of them default
142 2012-10-06 02:37:41 <jgarzik> provides asynchronous, provable, atomic, independent third party -> third party transfers
143 2012-10-06 02:37:53 <gmaxwell> The _one_ good thing I see about bitbonds is the atomic exchange with bitcoin. Otherwise it's all daft. But even thats of limited value because everyone wants an exchange, which then doesn't need integrated atomic exchange as its easy for the exchange to provide that.
144 2012-10-06 02:38:35 <amiller> hmm. you know, distributed bonds are exactly as hard as a distributed trust network like otc
145 2012-10-06 02:38:45 <gmaxwell> (and if the exchange provides it 'online' by holding the keys and making bitcoin transaction even for its internal moves.. then its pretty hard to secure)
146 2012-10-06 02:45:23 <dakid> gmaxwell: another thing Ive notice is that growl notifications longer show up with the current versions of everything, is there a fix?
147 2012-10-06 02:45:52 <gmaxwell> I have no idea on that. (I don't even know what a growl notifications is)
148 2012-10-06 02:47:18 <gmaxwell> Man. I am totally looking forward to telling my girlfriend about GLBSE vanishing.  "and it was run by this guy named Nefario"  ... we though people giving their money to "pirate" was funny, but I think Nefario is even more amusing. :-/
149 2012-10-06 02:49:53 <dakid> oh, growl is a notification system, applications can send little messages to growl which puts up a notification bubble, its like KDE's kdialog, or Dbus on ubuntu
150 2012-10-06 02:50:17 <dakid> bitcoin qt would put up a bubble upon sending and recieving coins
151 2012-10-06 02:50:28 <dakid> in osx atleast
152 2012-10-06 02:51:53 <gmaxwell> but now it crashes instead? :P
153 2012-10-06 02:53:44 <dakid> it  might be related, who knows
154 2012-10-06 02:54:03 <dakid> its does give "10/6/12 12:51:56.078 AM sandboxd[1048]: ([193]) Growl(193) deny file-read-data /private/var/folders/xk/3m7cc7b91bnc04xnktqsx77c0000gn/T/qt_temp.FVr884" in the console
155 2012-10-06 02:54:36 <dakid> looks like the sandbox demon in osx is preventing bitcoin qt from passing messages to growl
156 2012-10-06 03:02:18 <gmaxwell> dakid: ah, and then it crashes when the unexpected happens perhaps.
157 2012-10-06 03:10:11 <dakid> yea, but its not consistent, it doesn't crash everytime sandbox stops growl, im tired, ill try to replicate the crash later, thanks for your help gmaxwell
158 2012-10-06 03:23:58 <amiller> hm hm, new algorithm devised
159 2012-10-06 03:25:15 <amiller> for merkle tree validation, if you have only O(1) memory, then you can still process N updates to a balanced merkle tree of bounded size M, using O(N log M) amount of data and in as much time
160 2012-10-06 03:25:40 <amiller> that's still a ton of data to transfer, the factor of log M there sucks
161 2012-10-06 03:27:28 <amiller> if you have sufficient memory to store the whole utxo, O(M), then you should only need O(N) transfer, which is optimal since that's just like downloading the raw blockchain
162 2012-10-06 03:28:55 <amiller> so the question is if you have some memory Q < M, but not enough to store a whole utxo, how much can you reduce the transfer
163 2012-10-06 03:35:30 <amiller> meh, maybe there's even a way to do disk efficient validation
164 2012-10-06 03:37:46 <jgarzik> gmaxwell: a smart property alt-chain would be interesting, but not sure how it might be bootstrapped past the point of where it suffers all the deficiencies of other weak chains
165 2012-10-06 03:37:55 <amiller> anyway the key thing to take advantage of is that if you're validating a fork, then you're not processing novel arbitrary queries, you're validating a particular sequence of queries. you don't need a search data structure, you need something else.
166 2012-10-06 03:38:52 <jgarzik> gmaxwell: at to Why Not, with regards to cross-chain trust-free trading...  this is simply Hard Stuff and software does not exist to demonstrate such techniques
167 2012-10-06 03:39:16 <jgarzik> gmaxwell: whereas any idiot can at least understand 100% of the design space of a centralized cross-chain exchange website
168 2012-10-06 03:40:01 <jgarzik> I largely view bonds as just a demonstration, a subset of smart property (smartcoins / colored coins)
169 2012-10-06 03:41:37 <jgarzik> but the obvious downside is using satoshi's is the blockchain becomes subclassed as a generic property registry
170 2012-10-06 03:41:44 <jgarzik> s/is using/to using/
171 2012-10-06 03:41:57 <noagendamarket> namcoin would probably work
172 2012-10-06 03:42:09 <jgarzik> thus it records bitcoin transfers and property transfers
173 2012-10-06 03:42:17 <amiller> jgarzik, that's its destiny
174 2012-10-06 03:43:15 <jgarzik> amiller: I think gmaxwell is right, at a minimum, in implying that other solutions besides crapping up the main chain should be explored, in the quest for decentralized financial and property tools
175 2012-10-06 03:43:16 <noagendamarket> its hard to overcome the anonymous scammer issue
176 2012-10-06 03:43:45 <jgarzik> well, any bond or smart-coin or colored coin's "rule enforcement" is left to those outside the chain itself
177 2012-10-06 03:44:02 <amiller> to these mysterious independent third parties
178 2012-10-06 03:44:14 <noagendamarket> thats where you end up with brokers who get squeezed by the feds :P
179 2012-10-06 03:44:21 <amiller> what we'd need is some way of incentivizing lots of those third party independent validators
180 2012-10-06 03:44:29 <jgarzik> I like bonds because it is a subset of smart property, where the incentives are a bit more clear
181 2012-10-06 03:45:26 <jgarzik> smart property is simply secure token transfer between parties, where it is not required even that there be a relationship between the current holder and original issuer
182 2012-10-06 03:45:40 <jgarzik> unlike bonds, where the original bond issuer is key to the relationship
183 2012-10-06 03:46:08 <amiller> "secure" is about public verifiability, right?
184 2012-10-06 03:47:17 <jgarzik> amiller: "secure token transfer" == ["transfer of a 1-satoshi bitcoin" | "transfer of a smart-property alt-coin"]
185 2012-10-06 03:47:34 <jgarzik> i.e. just crypto-signed messages of which we're already familiar
186 2012-10-06 03:47:45 <jgarzik> the difficult part is the layer above -- applying meaning to smartcoins
187 2012-10-06 03:48:10 <amiller> is meaning applied to bitcoin
188 2012-10-06 03:48:36 <jgarzik> Classic smart property example:  a 1-satoshi bitcoin or 1-propcoin transaction confers ownership of a car
189 2012-10-06 03:49:13 <jgarzik> The holder of the unspent coin is the car owner
190 2012-10-06 03:49:22 <jgarzik> (or bond owner etc.)
191 2012-10-06 03:49:24 <amiller> ownership is about public recognition
192 2012-10-06 03:49:26 <jgarzik> yep
193 2012-10-06 03:49:27 <amiller> (i.e., legal)
194 2012-10-06 03:49:45 <jgarzik> the problem -- how to close the loop between "I own $this bitcoin" and "I own this car"
195 2012-10-06 03:50:08 <jgarzik> with bonds, you may define a globally agreed protocol, which makes bond payments verifyable to the community
196 2012-10-06 03:50:46 <jgarzik> and a bond-payment network is a well known entity that may be wholly encompassed within the current blockchain data structures
197 2012-10-06 03:51:47 <jgarzik> so with bonds, closing that loop seems doable
198 2012-10-06 03:53:00 <jgarzik> For smart property in general to work, it seems like you need a massive amount of network-effect-driven coordination.  You need all the car dealerships to agree that car ownership follows the propcoin alt-chain.
199 2012-10-06 03:53:26 <amiller> jgarzik, can you imagine a near-future world where it's possible to make legally binding contracts in reference to the blockchain
200 2012-10-06 03:53:52 <jgarzik> amiller: legally speaking... seems like you can do that now.  contracts are just English-language programs ;p
201 2012-10-06 03:53:54 <amiller> if not in a court trial or something, maybe in the context of commercial arbitration?
202 2012-10-06 03:53:57 <amiller> then the property could have teeth
203 2012-10-06 03:54:01 <jgarzik> yep
204 2012-10-06 03:54:03 <jgarzik> agreed
205 2012-10-06 03:54:31 <amiller> heh, i hope by "seems like you can do that now" you're envisioning the same kind of bitcoin court dramas i am
206 2012-10-06 03:54:46 <jgarzik> hehehe
207 2012-10-06 03:55:29 <amiller> block hash 0x0000dfe8a98fd098 is introduced as evidence, the jury is expected to independently validate the reported work content of the chain of headers
208 2012-10-06 03:55:45 <amiller> the stenographer is mining by typing nonces
209 2012-10-06 03:56:07 <amiller> but really it should be easy... maybe you're right and it could be done now :p
210 2012-10-06 03:58:26 <jgarzik> amiller: it's all in the writing of the legal contract language...  you can specify any technical standard you wish; just be sure to spend some time on the "definitions" section. ;p
211 2012-10-06 04:35:43 <amiller> i have a 40 gigabyte file right now containing all the hashes encountered while building merkle utxo's up through blocks 140k or so, it compresses with tar.gz down to a quarter of that
212 2012-10-06 04:35:49 <amiller> it's still too big of course
213 2012-10-06 04:36:54 <amiller> i can feed it into my tiny O(log M)-memory validator and it goes along just fine
214 2012-10-06 04:37:23 <amiller> but the huge file is redundant in the sense that the validator computes all of those hashes itself at some point
215 2012-10-06 04:38:13 <amiller> imagine you're going to build a database/index and you're going to respond to queries from users, you'd want a balanced database so you can handle any query
216 2012-10-06 04:38:45 <amiller> but now imagine that before hand, an oracle gives you a prediction of exactly which queries you'll receive and when
217 2012-10-06 04:42:08 <amiller> now you don't need random access and balance is kind of irrelevant
218 2012-10-06 04:42:49 <amiller> it's like getting to cheat on a test because you get the exact questions ahead of time
219 2012-10-06 04:43:20 <amiller> you could just memorize all the answers in order - store a file containing the correct response to each of the queries - but now you have too big a file if many of the queries share data
220 2012-10-06 04:44:31 <amiller> one approach would be to have a circular buffer
221 2012-10-06 04:44:59 <amiller> and each time you respond to a query with a prerecorded answer, you use the prediction to place the data in exactly the right spot in the buffer so it will be at the cursor when you next need it
222 2012-10-06 04:47:26 <amiller> if the circular buffer can be up to size O(M) in random access memory then this strategy is super cool
223 2012-10-06 04:58:26 <amiller> but more realistic is that you don't have enough ram for a whole utxo set, so you want some other way to be I/O and cache efficient
224 2012-10-06 04:59:16 <amiller> i think the way to do this is with a funnel sort of some kind
225 2012-10-06 12:40:02 <pingdrive> hi, i received some btc yesterday, but it doesnt not show in bitcoind-qt it does however show in blockchain.info?
226 2012-10-06 12:40:15 <pingdrive> do priv keys get corrupted?
227 2012-10-06 12:42:03 <sipa> are you fully synced?
228 2012-10-06 12:43:03 <pingdrive> yes
229 2012-10-06 12:43:09 <pingdrive> it says on blockexplorer
230 2012-10-06 12:43:20 <sipa> try running with -rescan
231 2012-10-06 12:43:22 <pingdrive> public key (unknown)
232 2012-10-06 12:43:36 <sipa> and please let me know if that helped
233 2012-10-06 12:43:50 <sipa> oh, first just try exiting and restarting
234 2012-10-06 12:44:08 <pingdrive> yeh i did that thosands of times
235 2012-10-06 12:44:10 <pingdrive> lol
236 2012-10-06 12:44:14 <pingdrive> let me do rescan
237 2012-10-06 12:46:17 <pingdrive> also when i do walletdump
238 2012-10-06 12:46:18 <pingdrive> i have
239 2012-10-06 12:46:19 <pingdrive> "keys": [],
240 2012-10-06 12:46:20 <pingdrive> "minversion": "unsupported",
241 2012-10-06 12:46:26 <pingdrive> shouldnt keys be filled?
242 2012-10-06 12:48:04 <sipa> what version are you running?
243 2012-10-06 12:48:27 <sipa> and what is walletdump?
244 2012-10-06 12:48:55 <pingdrive> pywallet.py
245 2012-10-06 12:49:01 <pingdrive> -- walletdump
246 2012-10-06 12:49:14 <sipa> ah, no idea how that works
247 2012-10-06 12:49:46 <pingdrive> "version": 70003
248 2012-10-06 12:50:01 <sipa> can you try using the dumpprivkey RPC?
249 2012-10-06 12:50:22 <pingdrive> how do i do that
250 2012-10-06 12:53:46 <pingdrive> okay nvm i found how to do it, still rescanning
251 2012-10-06 12:56:06 <pingdrive> okay it showed thanks for help man
252 2012-10-06 13:33:00 <wizkid057> 
ACTION is shutting down shop for a few hours for cleaning and reorganization purposes. BBL!

253 2012-10-06 14:48:04 <jgarzik> boy, kano trolled everybody ;p
254 2012-10-06 14:52:10 <gmaxwell> "Where IS the restriction at the moment?" "That we're not permitted to throw you into a volcano."
255 2012-10-06 14:58:47 <nanotube> greetings y'all. just want to bring this thread to your attention: https://bitcointalk.org/index.php?topic=110781.0
256 2012-10-06 14:59:10 <nanotube> it appears that upon encrypting for the first time, any unused keypool addresses get discarded and replaced with new ones (sensible from a security point of view)
257 2012-10-06 14:59:30 <sipa> nanotube: noy discarded; marked usrd
258 2012-10-06 14:59:34 <sipa> *used
259 2012-10-06 14:59:36 <nanotube> but that also invalidates previous backups (bad from a safety point of view)
260 2012-10-06 14:59:56 <gmaxwell> nanotube: we talked to him on IRC when he posted that.
261 2012-10-06 14:59:56 <nanotube> well... either way, new transactions after encryption get change sent to new addresses which are not in the backup
262 2012-10-06 15:00:01 <nanotube> ah ok
263 2012-10-06 15:00:11 <nanotube> well i was just going to make a suggestion from a UI stand point
264 2012-10-06 15:00:12 <sipa> yes, 0.7.1 will warn to create a new backup upon encryption
265 2012-10-06 15:00:15 <gmaxwell> And future versions will warn you at encryption time.
266 2012-10-06 15:00:19 <nanotube> that upon wallet encryption, it should have a big fat warning
267 2012-10-06 15:00:27 <nanotube> ah ok then, you guys have it all sorted out .
268 2012-10-06 15:00:32 <nanotube> good. :)
269 2012-10-06 15:01:01 <gmaxwell> Yep. We're one step ahead of you. But thanks for pointing it out??? if he hadn't also shown up on IRC we might not have done this yet.
270 2012-10-06 15:01:13 <nanotube> just... reminded me of that one guy who lost 9kbtc back before satoshi added the keypool feature in 0.3.12 or so.
271 2012-10-06 15:01:41 <nanotube> indeed - just wanted to make sure you guys saw the issue. :)
272 2012-10-06 15:02:15 <gmaxwell> I'm hoping the theif shows up on the forums looking for help to crack the wallet crypto. :P
273 2012-10-06 15:02:31 <nanotube> lol that'd be funny
274 2012-10-06 15:02:40 <gmaxwell> "Sure, I'll crack that for you" <gives wallet back to owner>
275 2012-10-06 15:04:26 <sipa> gmaxwell: and answer "yeah, someone on the forum happened to know the passwod; that was fastrr than spending the 2^82 years to bruteforce the master key
276 2012-10-06 15:06:08 <gmaxwell> haha
277 2012-10-06 16:22:27 <jgarzik> gmaxwell: "p2ptrade", which uses pybond's "financial P2P network and financial hashmap (the DHT)" for mechanizing cross-chain trading, would be an interesting project
278 2012-10-06 16:23:14 <jgarzik> Reason being...  I'd be interested in pursuing a smart property alt-chain, if it was possible to secure that alt-chain from common weak-chain attacks
279 2012-10-06 16:23:54 <jgarzik> With a smart property alt-chain, at least bonds and smart property tokens (and their transfer) would be outside the blockchain
280 2012-10-06 16:24:10 <jgarzik> not convinced this would wind up a superior experience for users, but willing to give it a shot
281 2012-10-06 16:30:09 <jgarzik> Another concern is simply byte size:  will the total byte size added to the _bitcoin_ blockchain, in a trading-with-smart-property-chain scenario, versus the no-alt-chain scenario where smart property == colored coins?
282 2012-10-06 16:30:39 <jgarzik> This example makes it seem like that is within the realm of possibility: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
283 2012-10-06 16:35:25 <kjj_> jgarzik: I think that a second chain, using either merged mining as it exists today, or using the "free" method, will cause less bytes to enter the bitcoin chain
284 2012-10-06 16:36:02 <kjj_> the trade off is, though, that there will be more bytes in the other chain, but that's fine, because that cost of handled by users of that second chain
285 2012-10-06 16:36:17 <kjj_> er, is handled
286 2012-10-06 16:36:43 <jgarzik> even just considering the bitcoin side, cross-chain transactions are a lot bigger
287 2012-10-06 16:37:07 <kjj_> well...  I'm not sure that cross chain is necessary
288 2012-10-06 16:38:00 <kjj_> but the big p2sh blob gets spent right away, and so it should be prune-able
289 2012-10-06 16:38:10 <jgarzik> kjj_: it's not necessary, agreed.  everything could be done on the bitcoin side ("Atomic coin swapping" thread)
290 2012-10-06 16:38:34 <jgarzik> but I think gmaxwell would constantly bitch ;p
291 2012-10-06 16:38:58 <kjj_> heh.  if not him, someone else.  no matter what happens
292 2012-10-06 16:40:03 <kjj_> here is the other thing, in my view
293 2012-10-06 16:40:04 <jgarzik> well on a design point, it does make some sense:  a bitcoin output becomes a token of abstract ownership.  Scaling up, you wind up with a lot of people holding 1-satoshi unspent outputs.
294 2012-10-06 16:40:26 <jgarzik> you gotta store the property ownership tokens somewhere
295 2012-10-06 16:41:20 <kjj_> we could do a merged chain for securities TODAY
296 2012-10-06 16:41:52 <kjj_> the colored stuff would take a while.  there are still issues that need to be worked out
297 2012-10-06 16:45:43 <amiller> i don't see why anyone thinks that cross chain transactions will work correctly
298 2012-10-06 16:46:02 <kjj_> amiller: there are ways to do it
299 2012-10-06 16:46:14 <amiller> what prevents the namecoin side of the transactions from completing but the bitcoin side getting preempted
300 2012-10-06 16:46:21 <gmaxwell> jgarzik: yes, bht that property ownership should be stored by people who care about it, not by the entire world.
301 2012-10-06 16:46:43 <gmaxwell> Bitcoin ownership is held by the entire world because we care about bitcoin not being inflated (degrades our own bitcoin)
302 2012-10-06 16:46:56 <gmaxwell> Only the other holders of a bond give a crap about inflation or ownership of a bond. :P
303 2012-10-06 16:48:59 <gmaxwell> 11:30 <@jgarzik> This example makes it seem like that is within the realm of possibility: https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
304 2012-10-06 16:49:06 <gmaxwell> the example there is longer than it needs to be.
305 2012-10-06 16:49:54 <gmaxwell> (e.g. it doesn't need the if/else part for the escrow unlock)
306 2012-10-06 16:49:57 <amiller> gmaxwell, describe a simpler example and walk me through how either both txs succeed or neither do (atomicity?)
307 2012-10-06 16:50:38 <gmaxwell> amiller: I posted this a couple times but can't be bothered to look it up??? it's basically there, just eliminate the multisig half.
308 2012-10-06 16:51:28 <gmaxwell> you pay to preimage A + preimage B + A signature. on one side preimage A + preimage B + B signature on the other.
309 2012-10-06 16:54:22 <amiller> i don't know how to refer to the particular steps of the sequence clearly, but the problem is what prevents the last signer from spending the coins one one chain first and then signing the transaction
310 2012-10-06 16:54:36 <amiller> i agree that either both secrets are revealed or neither are, but that doesn't mean the transaction will complete
311 2012-10-06 16:57:13 <gmaxwell> amiller: I'm not following what you're asking, sorry.
312 2012-10-06 16:58:26 <gmaxwell> amiller: okay, you're asking about a holdup where one side goes into escrow and the other side spends their input first so it can't go into escrow
313 2012-10-06 16:58:32 <gmaxwell> and then you have a randsom situation?
314 2012-10-06 16:58:48 <gmaxwell> Indeed, to deal with that you do need the refund branch.
315 2012-10-06 16:59:12 <amiller> i missed the escrow part, is there a third party?
316 2012-10-06 16:59:46 <gmaxwell> ... no.
317 2012-10-06 16:59:50 <amiller> or is that based on the lock time
318 2012-10-06 17:00:19 <gmaxwell> By escrow I mean the deposits into a script that requires the parties to cooperate. (held in escrow by the blockchain)
319 2012-10-06 17:00:50 <gmaxwell> The idea is that you precompute and share refund transactions that are only valid in the future.
320 2012-10-06 17:01:17 <gmaxwell> so if the other guy manages to trick you into paying into the escrow without him doing the same, eventually that timer ticks down and you refund.
321 2012-10-06 17:04:38 <amiller> ah okay, each party first has to commit their coins into an escrow script (in the blockchain) with a timer and a refund destination
322 2012-10-06 17:05:11 <amiller> so on one hand you want to make the escrow time pretty short, because if you're interacting with a stranger then they could troll you by letting you go first and encumber your funds for a while while they just disappera
323 2012-10-06 17:05:50 <amiller> you can't trade with anyone else until the escrow timer runs out
324 2012-10-06 17:07:04 <amiller> on the other hand, the escrow times are not necessarily synchronized between the two chains
325 2012-10-06 17:10:58 <amiller> so there's still a race condition where the escrow expires and the refund is executed in one chain, but the exchange completes in the other chain
326 2012-10-06 17:12:45 <gmaxwell> amiller: yes, though thats why the refunds aren't instant. (thats true even if the times are 'synced', e.g. using time instead of height)
327 2012-10-06 17:12:52 <gmaxwell> It's also only the case for independant chains.
328 2012-10-06 17:13:00 <gmaxwell> Jeff's bond chain doesn't need to be independant.
329 2012-10-06 17:13:17 <gmaxwell> It can, in fact, have full (or only just SPV) security against the bitcoin chain.
330 2012-10-06 17:13:35 <gmaxwell> e.g. the jeff chain could do a kind of transaction that monitors the bitcoin chain.
331 2012-10-06 17:14:11 <gmaxwell> The key point is that joe random bitcoin users don't need to know about the ownership of bonds.
332 2012-10-06 17:16:26 <amiller> if joe random bitcoin users don't know about the ownership of bonds, then there's no way to synchronize their timelines and there's a race condition involving loss of bonds
333 2012-10-06 17:16:41 <gmaxwell> amiller: no, there isn't.
334 2012-10-06 17:17:09 <gmaxwell> amiller: just because bitcoin owners don't know about bonds doesn't mean that the bond holder don't know about bitcoin.
335 2012-10-06 17:22:03 <amiller> i still don't think that works; the problem is that bitcoin miners who don't know about bonds will timestamp (or merge mine) transactions in other chains whether they're valid, invalid, or undecidable
336 2012-10-06 17:22:34 <amiller> i'm inferring a bit about what you mean by "transaction that monitors the bitcoin chain" because i think i know what you mean but maybe i'm wrong, i'll look for a reference
337 2012-10-06 17:23:22 <gmaxwell> You apparently don't have a clue about how merged mining works.
338 2012-10-06 17:23:38 <gmaxwell> Thats the root of this misunderstanding.
339 2012-10-06 17:24:16 <gmaxwell> If the secondary chain requires something for validatity, timestamped work that doesn't conform with that rule is just non-existant from their perspective.
340 2012-10-06 17:25:31 <gmaxwell> (sorry for being terse, trying to get some actual work done...)
341 2012-10-06 17:26:06 <amiller> it's k, sorry for making you reexplain merge mining to me every time i get it wrong - maybe i just shouldn't have put it there though, i don't think you were talking about merge mining when you said transaction that monitors the blockchain
342 2012-10-06 17:27:12 <gmaxwell> Well it could be $anything that monitors the blockchain, when you mentioned "itcoin miners who don't know about bonds will timestamp (or merge mine)" I assumed you were making incorrect assumptions about how merged mining works.
343 2012-10-06 17:27:59 <gmaxwell> I don't think it matters for this queston how the bond holders decide. They can still get the validity of cross chain transactions with bitcoin by watching bitcoin, however they do their consensus for transactions that never touch bitcoin.