00:45:00robert222:Bitmessage 2.0
00:45:18robert222:"Introducing Twister: a fully decentralized P2P microblogging platform leveraging both the Bitcoin and BitTorrent protocols. "
00:45:21robert222:robert222 has left #bitcoin-wizards
00:51:32CodeShark:gmaxwell, sipa: please, tell me why this is a bad idea :)
00:52:30sipa:if a transaction gets included right at the edge, a reorganization could push it over the limit
00:52:34sipa:making it invalid
00:52:42sipa:and making any transaction depending on it invalid
00:52:54CodeShark:same could be said for double-spends, though, no?
00:53:08sipa:those don't happen without malice
00:53:23CodeShark:I gave some examples where they in fact happen without any malice at all
00:53:34sipa:malice or buggyness :)
00:54:24CodeShark:in practice you'd set the expiration sufficiently in the future and set the fee high enough so that this reorg risk is reduced
00:54:40gmaxwell:CodeShark: sipa was faster than me. This creates fungibility problems because now you have transactions dependant on spending recently mined expiring coins, where a perfectly ordinary chance reorg will invalidate enormous amounts of transaction potentially.
00:55:14gmaxwell:CodeShark: the risk is not just to the transaction user, the risk is to all downstream coins... and so you'd have to do blockchain analysis to figure out which coins have what exposure.
00:55:29gmaxwell:(preventing this is part of why the coinbases aren't spendable for 100 blocks)
00:55:44CodeShark:hmm - ok, this is a valid point…trying to think of a way around it
00:56:01sipa:in a world where nobody trust 0-conf transactions, and everyone waits N (with N>2 or so) confirmations before spending anything, that is likely much less of a problem
00:56:12gmaxwell:There are other script features people have wanted that had similar risks.
00:56:48CodeShark:yeah, what sipa just said: accepting transactions with low confirmation count is already somewhat risky - if some of those coins also happen to be near expiration, it's even more risky
00:56:55gmaxwell:sipa: except if you accept N>2 and someone has a transaction which would get killed by an N=3 reorg, you would really want a N>2+3 wait on that coin.
00:57:36CodeShark:the biggest problem, I think, is not so much the risk…this could be managed…but the potential complications in dependency analysis
00:58:02CodeShark:but nothing that couldn't be solved with some well-written code :p
00:58:11sipa:too tired to reason now, but i'm very wary about changing the (apparently very deliberately chosen) rule that a transaction, once valid, is always valid (modulo its inputs becoming unavailable)
00:58:12CodeShark:doesn't seem to be intractable
00:58:14gmaxwell:as far as expirations go, we already have a way to expire: spend one of the contributing inputs. :P
00:58:41sipa:CodeShark: it's completely impossible for SPV wallets to do such analysis
00:58:49sipa:without a local mempool
00:58:53CodeShark:sipa: true
00:59:06CodeShark:well, there could be other partial validation mechanism
00:59:15CodeShark:but that's perhaps a topic for another time :p
00:59:28sipa:that's perhaps more on topic here in the first place :D
00:59:46CodeShark:I'm running into this problem right now as we speak, though - here's the use scenario:
01:00:07CodeShark:(it's not hypothetical - I'm actually doing it for real)
01:00:31CodeShark:you create a joint account with two other people, 2-of-3 signature policy
01:00:54CodeShark:you want to initiate a payment, need approval from at least one other person
01:01:05CodeShark:you provide them with a partially signed transaction
01:01:42CodeShark:now, to invalidate that transaction the way gmaxwell was talking about, you'd also have to incorporate another simple output that only you can redeem
01:02:09CodeShark:so now we need to mix the 2-of-3 policy account with another personal account
01:02:23CodeShark:just to allow us to pull the trigger on it
01:02:40CodeShark:the usability becomes horrendous
01:03:13CodeShark:an expiration time would be a very simple solution to this particular problem
01:03:30sipa:but a very significantly change to force onto every wallet on earth...
01:03:52gmaxwell:not just every wallet, but the whole incentive structure of bitcoin
01:03:59CodeShark:you can refuse to accept payments that expire soon
01:04:23gmaxwell:since now you need to think about miners being bribed to reorg or being unwilling to reorg to change to an honest chain because of txn that can't be included.
01:04:51gmaxwell:CodeShark: only if you can determine when the entire (perhaps exponentially sized) history's earliest expiration is.
01:05:50CodeShark:these are healthy concerns - this is why I like to talk to you guys :)
01:06:16sipa:we've heard these suggestion many times already :p
01:06:41CodeShark:however, in a real practical sense right now, one way or another I need a solution - and I don't think deliberately "double-spending" extra outputs is a very clean one, to say the least :)
01:07:08gmaxwell:yea, it's not just applicable to your application. E.g. people have wanted things like lotteries which can read the block hash of some subsiquent confirming block.
01:07:28gmaxwell:CodeShark: why don't you make your protocol such that the originator of the transaction signs last?
01:07:44CodeShark:that could work
01:08:20CodeShark:yeah, I suppose it does make sense for the originator to be the one who broadcasts (or sends to recipient)
01:08:37maaku:gmaxwell: no i didn't investigate any JS solutions, but "javascript rsa" turns up some hits
01:09:16CodeShark:gmaxwell: without blinding, though, you still have a problem if the originator changes her mind
01:09:35gmaxwell:CodeShark: hm? why? they just don't sign then.
01:09:44CodeShark:but then you get the same issue in reverse
01:09:57CodeShark:now it's the person whose signature was requested that ends up in this unfinished situation
01:10:11gmaxwell:maaku: this is what I'm thinking of proposing, if you care: http://0bin.net/paste/yV7e4WCpZVHEj7nN#fi70f2LMSGO3JyrkNSeOG+ivIpfr2QirZzcNbVc2IXc=
01:10:56CodeShark:if only there were a way to ensure that the signature sharing were atomic :)
01:11:39gmaxwell:CodeShark: whats the problem with everyone except the originator pretending it didn't happen until it ends up in the blockchain?
01:12:51CodeShark:a few: they can't use those outputs without halting a transaction they want to happen, and if they pretend it didn't happen they might overspend their balance
01:12:52gmaxwell:e.g. if the funds in the account form a linked list (e.g. only a linear line of coins) then it's all atomic. Any parallel signatures are mutually exclusive.
01:13:02maaku:gmaxwell: it's a great idea
01:14:07gmaxwell:CodeShark: ISTM you're expecting bitcoin to function as a database for your application giving it SERIALIZABLE atomiticiy for all its data.
01:14:38gmaxwell:thats probably unrealistic in general, because there are probably non-transaction bits of data you'd eventually what to synchronize too.
01:15:06CodeShark:well, there are things like labels, but that's a separate problem for now
01:15:24gmaxwell:Instead of pretending your application is multi-master, it would be a lot simpler to make it master/signer where all transactions are originated in one point normally (except for exceptional recovery cases)
01:15:32CodeShark:ideally I want to reduce the amount of data that needs to be sent over the block chain
01:16:26maaku:CodeShark: I'm a dissenting voice here. How is nExpireTime any different in principle than a coinbase output?
01:17:03maaku:there are very real advantages to having an nExpireTime, and other scripting extensions which invalidate txns over a reorg
01:17:34maaku:Making users wait to get the desired number of confirmations is not a big hurdle
01:17:52maaku:They should be doing that anyway
01:17:54gmaxwell:maaku: a coinbase output can't be spent in the blockchain for 100 blocks. If you wanted to have an identical limit for outputs from those txn, my objections would go away— except to point out that it's really trying to cram application logic into bitcoin which might be a poor fit.
01:18:22CodeShark:ok, then how about this: set a limit on number of blocks before an nExpireTime transaction is spendable :)
01:18:23maaku:gmaxwell: I don't like the 100 block protocol rule
01:18:32gmaxwell:maaku: I'm sorry for you then.
01:18:34maaku:but i think clients / wallets should implement something similar
01:18:35CodeShark:doesn't have to be 100 blocks
01:18:49sipa:i think 100 is serious overkill, but the reason the rule exists is very real
01:19:00gmaxwell:CodeShark: I think it does need to be 100 blocks, simply because asking wallets to cope with _two_ kinds of behavior is burdensom.
01:19:11maaku:there's no problem building off a txn that can be reorg'd away, but the user interface better have big flashing red lights
01:19:12CodeShark:but require that any transaction confirmed close to the edge of nExpireTime sit on the block chain for a bit before it can be spent
01:19:19gmaxwell:meh, we've had reorg events a substantial fraction of 100.
01:19:44gmaxwell:Imagine we have another long fork event and then we _cannot_ fix it without people forever losing money. Even if there were no malicious spends. egads.
01:20:00CodeShark:the problem, as I understand it, is the potential for a long chain of dependencies from an edge transaction
01:20:13CodeShark:that seems to be the main concern, right?
01:20:28CodeShark:so we can alleviate that concern by taking similar measures as we do for coinbase transactions
01:20:43gmaxwell:maaku: you even have to be able to detect it. a SPV client can't tell how deep the newest expiring input is from some chained coin.
01:21:07maaku:CodeShark: well you'll get to play with this in any case. Freimarkets has an nExpireTime and other reorg-sensitive constructions
01:21:32gmaxwell:maaku: sadly none of that matters unless the system gets serious usage you'll never learn the folly of your ways.
01:21:49CodeShark:if you have an nExpireTime transaction that confirms 100 blocks before expiration, no problem. but if it confirms one block before expiration, it should not be spendable for a few blocks :)
01:21:50maaku:gmaxwell: it could if you had utxo proofs with embedded heights
01:22:18phantomcircuit:zomg yes pizza
01:22:22maaku:(which is one reason why my proposal keeps the height field even though it is not strictly needed)
01:22:25gmaxwell:exponentially in size, since you have to trace the whole history.. having one height isn't good enough.
01:23:56gmaxwell:I guess you could track for every output a shortest-reorg-that-can-kill-it?
01:24:35gmaxwell:e.g. max(height)
01:25:02maaku:gmaxwell: I honestly don't think the risk is high enough to warrent doing that calculation
01:25:19maaku:which is not easy to do in general beyond the nExpireTime case
01:26:14CodeShark:I tend to concur, maaku
01:26:20gmaxwell:maaku: We've had long >20 block reorgs in bitcoin, where thousands of transactions would have been irrepariably invalidated if there were just one or a few unreorgable coins.
01:27:00gmaxwell:I think you guys are nuts, it's not even a theoretical problem. We've had at least three events where what you would have proposed would _probably_ have caused severe monetary loss if it were widely used.
01:27:15CodeShark:the risk could be mitigated
01:27:27CodeShark:I'm not saying "pretend the risk doesn't exist
01:27:31gmaxwell:and with expirations near the tip, we could be exposed on each and every block.
01:27:54gmaxwell:coins with the risk are not fully fungible with coins without the risk.
01:28:01maaku:gmaxwell: how is that any different than someone watching a major fork in progress, and doing a double-spend?
01:28:04CodeShark:so you simply don't allow spending of those coins for a while
01:28:07maaku:(as actually did happen back in March)
01:28:30maaku:from the perspective of someone building off the transaction, that is
01:28:48gmaxwell:Because it requires someone to actually be malicious, this doesn't.
01:29:21gmaxwell:CodeShark: if _you_ are defining the "a while" then you have an exponential complexity check of the history to make sure an earlier spender didn't use a more lax definition of 'a while'.
01:29:47gmaxwell:making it a rule as we do for coinbases makes it instantly SPV compatible.
01:30:15CodeShark:the "while" could be a predetermined, fixed amount
01:30:27gmaxwell:well, then we have such a number already, it's 100.
01:30:34maaku:gmaxwell: there's a very easy way to make it SPV compatible: wait N blocks before taking action based on the txn
01:30:52maaku:you seem to want a user to absolutely trust a txn as soon as it has 1 confirm
01:31:00CodeShark:maaku: the problem is if there's a chain
01:31:08gmaxwell:maaku: egaha. The problem there is that you don't know if a transaction had an inherently risky past in a SPV compatible manner.
01:31:48gmaxwell:E.g. I want to wait 100 for coinbases, 6 for normal payments. if coinbases were technically spendable at 1, then a spv node couldn't tell your txn was dependant on a coinbase 3 blocks ago.
01:31:57CodeShark:the min reorg depth would need to be somehow propagated through the chain…or the SPV client would need a way to obtain a simple proof of at least a certain depth
01:32:08maaku:so? you want it to be safe from any reorg less than 100 blocks? then wait 100 blocks after it hits the chain
01:32:40CodeShark:the burden of proof could be passed to the payer
01:32:49gmaxwell:also if the rule is not consistent we can't reason about the safty of forks. E.g. we know that coinbases are not spendable before 100 so if we must we can do a 99 block reorg to fix the chain and include no double spends and we won't invalidate any spent coins.
01:33:18maaku:so let the payer use old coins so they can provide a compact proof of stability
01:33:28gmaxwell:Also you've increased communications complexity between the payee and payer. Because as a payer now I need to know the payee has some preference for non-risky coins wich differs from payee to payee.
01:33:33maaku:otherwise, sucks to be them and the merchant makes them wait 100 blocks
01:34:42gmaxwell:having to wait 100 blocks at all times, or having to treat coins as highly non-fungible are both pretty poor solutions.
01:35:03gmaxwell:Esp. when the coin is some small improvement which you couldn't even explain to most people. :P
01:35:19gmaxwell:Perhaps its fine in some other system, I don't think its something we can reasonably do in bitcoin.
01:35:38maaku:well having signatures expire is pretty important when its used ina p2p exchange...
01:35:55maaku:or in a server-to-server consensus mechanism
01:36:10gmaxwell:17:35 < maaku> or in a server-to-server consensus mechanism
01:36:44gmaxwell:yea... except dear gods, the bitcoin blockchain is NOT a communications mechenism for your server to server consensus! _global broadcast network_
01:36:54maaku:gmaxwell: using the public chain as a semaphore for two-phase commit of a distributed transaction over multiple private asset servers
01:37:42gmaxwell:your asset servers are known in advance! use a freeking ordinary consensus.
01:37:48maaku:that's why we haven't even tried to get anyone onboard with deploying Freimarkets to bitcoin
01:37:53maaku:i just assume it wouldn't fly
01:38:28maaku:gmaxwell: you need to hit the public chain for public<-->private txns
01:39:11maaku:(e.g. atomic swaps of freicoins for private assets)
01:39:27gmaxwell:For anything like that you have a small number (because multisig scalablity) of known-in-advance servers. Which means you can do a regular n-of-m consensus totally external to bitcoin. E.g. an initatior proposes a distributed database update and get a supermajority of the servers to sign off on it.
01:39:44CodeShark:ok, perhaps amore interesting theoretical question (whose solution would work just as well for my problem): is there a practical way to achieve atomic data swaps between multiple entities?
01:40:21CodeShark:homomorphic encryption?
01:41:12CodeShark:would it require quantum crypto? :)
01:41:36gmaxwell:CodeShark: you basically want two people to trade data such that they either both get the data or neither do?
01:42:45CodeShark:and the outcome shouldn't take forever to determine :)
01:42:59gmaxwell:I don't know if its possible, unless you assume both parties are equally computationally bounded.
01:43:25CodeShark:or you use quantum crypto
01:43:44gmaxwell:I'm not even sure how you'd do it with quantum crypto.
01:44:08gmaxwell:lemme think for a minute.
01:45:26gmaxwell:It has to be a two party protocol? Can the protocol have N bystanders who help out, and the protocol is fair if most of the bystandards are honest?
01:46:02gmaxwell:I can give you protocols for this, but they don't work for the two-party case because they need an honest majority.
01:46:40CodeShark:yeah, the two party case seems to have much more profound theoretical implications
01:47:14gmaxwell:yea, kinda, you split the data up N ways such that N/2+1 can reveal. And then N/2+1 reveals to both and you're done. Of course it can be encrypted so that no one but the right parties learn anything.
01:47:50gmaxwell:With N=2 I think the best I can do involves bitcommitments and a cheater can terminate the protocol early and know 1 more bit than the other guy, plus then they can do computation to grind out the answer.
01:48:37gmaxwell:e.g. say you both can afford 2^64 work to grind out a missing key. I abort the protocol early so that I am missing 64 bits and you are missing 65. It's even worse if the parties are computationally unbalanced.
01:49:10gmaxwell:e.g. you can afford 2^32 and I can afford 2^64. I can terminate it after learning K-64 bits and you're just screwed.
01:51:28gmaxwell:I know there are some protocols which claim to be able to achieve 2-party active secure multiparty computation. So I suppose I should go look and find out what the catch is, becuase I think thats not possible.
01:51:36gmaxwell:(for the same reason as here)
01:51:45CodeShark:not even with quantum crypto?
01:53:29gmaxwell:I think if you can do it with quantum crypto then you can make something secure in the CRS model (e.g. where there is some magic trusted random tape).
02:06:13brisque:would anybody be available to help me isolate some network oddness? trying to work out if something I'm seeing is my peers behaving badly, or something on a larger scale.
02:06:35CodeShark:what are you seeing?
02:07:27brisque:I'm getting huge floods of double spend attempts in my logs- I know it's not an issue but it's extremely persistent
02:08:18brisque:usually around block boundaries I get 60+ transactions spending spent outputs, which is strange in my eyes. big blocks milliseconds apart.
02:08:27gmaxwell:brisque: I don't think thats anything too new or interesting, some things, e.g. bc.i uselessly flood peers with double spends.
02:08:43gmaxwell:also I think coinbase does this.
02:09:11gmaxwell:after a block that doesn't have some unconfirmed transaction it has, it uselessly floods all its peers readverting them, even if they're conflicted.
02:09:26brisque:ah. I've banned blockchain.info for that, but I wasn't aware anybody else decided it was a good idea.
02:32:20brisque:I'm definitely connected to blockchain.info or coinbase's nodes, but I've no way of knowing which they are out of hundreds of peers. might be a rainy day project to try and isolate them somehow.
02:53:41gmaxwell:brisque: unfortunately it's hard to distinguish idiotic spamming of conflicted transactions vs honest spamming of them from a peer which isn't quite caught up with the blockchain.
02:53:56gmaxwell:If it were, we could just automatically ban those nodes.
02:58:12brisque:gmaxwell: if you were intent on identifying one of the mentioned services, you presumably could just listen and isolate it by forcing the service to broadcast known transactions and measuring the latency. I don't have any inclination to, but even if they're not listening (I'm sure they're not) you could eventually find them. the number of listening nodes in the network is quite small after all, anyone with enough
02:59:52brisque:I seem to remember that Bitcoind avoids talking to multiple peers in the same network, which would make that more difficult of course.
03:01:54gmaxwell:well mostly I think this crap wastes a lot of bandwidth, but right now people have very little incentive to write compently authored node software in any case that won't get them banned.
03:05:21brisque:I suppose bandwidth is cheap enough that nobody cares. ultimately their dodgy patches will just lead to them not updating, which is the real risk.
03:10:18gmaxwell:it's already the case... well it's not just 'dodgy patches', e.g. coinbase has their own node software... and yea, they get isolated from time to time as a result.
03:10:38gmaxwell:The bandwidth might be cheap for them, but it's pretty inconsiderate to the network.
03:10:48brisque:oh god. seriously!?
03:11:04brisque:why would anybody running a financial service run their own bitcoin node!?
03:11:23gmaxwell:And expose it directly to the world too.
03:12:33gmaxwell:In any case, maybe we could just keep a count of doublespends per-peer preferentially kick the worst offender.
03:13:19brisque:that's just ridiculous. the cost involved in building their own bitcoin node would far outstrip any benefit they would gain from it. no wonder they needed piles of VC money.
03:13:43brisque:it explains a lot, why their outgoing transactions are so slow, get stuck, often don't get broadcast.
03:14:31gmaxwell:it's not just that, if someone goes and finds yet another way to get them to reject the real chain, (which has happened by accident many times) they can potentially buy a bit of hashpower and rob them blind.
03:15:07gmaxwell:... though in that particular case, I guess its not even the low hanging fruit. At least a month ago it was possible to deposit, and then withdraw before it confirmed.... (I reported it to them, dunno if they fixed it)
03:15:36brisque:surely they would have paid a bug bounty for you. they have a minimum 5BTC policy.
03:15:49brisque:that's an obscenely bad bug for an online wallet to have
03:15:50Luke-Jr:gmaxwell: now I can't even sell until it confirms :/
03:16:02gmaxwell:oh I guess they fixed it then.
03:16:59gmaxwell:brisque: I didn't ask about that. .. hell I wasn't even trying to discover it. Worse, in the case where I discovered this there was actually a double spend on the network, and I could have _accidentally_ ripped them off.
03:17:09brisque:I think you could have the QT client scream "DONT ACCEPT ZERO CONF TRANSACTIONS" every 5 minutes and people would still do it.
03:18:05brisque:gmaxwell: I'm shocked nobody had realised that before.
03:19:13brisque:oh, coinbase have changed their responsible disclosure police. it's now minimum $1000 rather than 5BTC. guess they got bitten by the exchange rate.
03:19:16gmaxwell:(it was at a time when mtgox was having problems, and I transfered from mtgox to coinbase, .. and mtgox made a conflicting doublespend... so not only did I withdraw unconfirmed coins, I did so at a time when .. if things confirmed in a different order it would have ripped them off)
03:19:24gmaxwell:... to the tune of something like $30,000.
03:19:58gmaxwell:(I wasn't aware of the second mtgox payment... lol.. or I wouldn't have done something so potentially confusable as an attempt at theft!)
03:20:45brisque:either way, lucky you found it rather than somebody who would have exploited it.
03:20:47gmaxwell:in any case, if you look around you can find horrifying stories about almost every bitcoin service.
03:21:20gmaxwell:brisque: Well, maybe thats what the VC money is for: to cover hemoraging money from failures like that. :P
03:21:48gmaxwell:BTC-e has has some really severe money loss events and somehow keeps on trucking.
03:22:01brisque:fractional reserve?
03:22:26gmaxwell:e.g. someone figured out how to impersonate the liberty reserve deposit callback and then gave themselves infinite btc-e USD.
03:22:39gmaxwell:and then bought up and withdrew all coins that appeared in the btc-e hotwallet.
03:22:43gmaxwell:... for something like 12 hours.
03:23:08gmaxwell:btc-e price per bitcoin went to >$100 (when btc had been at like $10 or something) and so lots of idiots deposited more coin.
03:24:08brisque:you'd think a service like that would have some sort of checks and balances that sees someone with unlikely situations and freezes the site until it can be verified. better that than losing out.
03:24:40gmaxwell:mtgox now does some of that, though I think probably not enough.
03:25:22gmaxwell:at least these things should freeze deposits and withdrawls... anything purely internal can at least be made right later.
03:25:41gmaxwell:But I suspect that the pretty good incomes from running the sites coupled with fractional reserve can make up for a lot of mistakes.
03:26:50brisque:until there's a bank run, and then they're completely high and dry
03:27:31gmaxwell:Failure is always an option.
03:28:04gmaxwell:I'm not aware of a _single_ major bitcoin business operator who has faced _civil_, much less criminal, charges for their default.
03:28:50pigeons:i guess calling trendon sahvors/pirate@40 a business operator would be a stretch
03:29:42phantomcircuit:gmaxwell, er
03:29:47phantomcircuit:* phantomcircuit raises hand
03:29:51gmaxwell:okay, fair, I'd even include that since a lot of people did think it was real. (::facepalm::) has he actually suffered any consequences for it?
03:30:11pigeons:he got a default judegemnt by the sec cause he stopped responding to the court
03:30:13phantomcircuit:oh charges
03:30:16phantomcircuit:didn't see that
03:30:16gmaxwell:phantomcircuit: well I'm not counting bitcoinica because the actual owner and responsible party dropped the bag of shit in someone elses lap!
03:30:19pigeons:and now the fbi is finishing their investigation
03:30:39phantomcircuit:gmaxwell, charges usually refers to government action also
03:30:52phantomcircuit:gov can take civil action which i believe is what they did against shavers
03:31:01phantomcircuit:or however the fuck you spell his name
03:31:07pigeons:these are the shavers docs. http://ia800904.us.archive.org/35/items/gov.uscourts.txed.146063/
03:31:07gmaxwell:thats what they did against him, yea.
03:31:26pigeons:yes and i hear criminal is coming soon against shavers
03:31:27brisque:the point being that even under the most abstract failure, most sites simply disappear when something goes wrong.
03:31:30phantomcircuit:so looks like hashfast isn't going to delivery
03:31:45gmaxwell:phantomcircuit: nope, they're not.
03:31:50pigeons:not only do they disappear, they reopen using the same identity
03:32:02gmaxwell:They've also announced that they aren't planning to honor their original comittments to refunds.
03:32:07brisque:I enjoyed the inputs.io thread particularly. by the looks of things all the "security" advertised either didn't work or didn't even exist in the first place.
03:32:07phantomcircuit:i actually knew this like two weeks ago
03:32:16phantomcircuit:but i find it amusing watching people find out they're fucked
03:32:38gmaxwell:I'm trying to figure out what I'm going to do about that, as I have two orders with them, along with email correspondance confirming that their refund commitment was to refund the full amount of BTC paid.
03:32:59gmaxwell:The problem, of course, is that if I sue them they'll just bankrupt themselves defending it, and there will be nothing to recover.
03:33:27brisque:they'll end up delivering something I assume
03:33:29phantomcircuit:gmaxwell, my guess is they dont have the capital to do a full production run and were delaying hoping to get enough new orders to do the run
03:33:42phantomcircuit:they didn't hit the target and are now completely screwed
03:33:50phantomcircuit:this is of course fraud
03:34:14phantomcircuit:gmaxwell, it's likely criminal
03:34:24phantomcircuit:but i doubt it's worth anybodies time to pursue
03:34:30brisque:is a poor lack of judgement criminal?
03:34:31gmaxwell:brisque: yea, but at this point its so late that anything they deliver will be a massive loss. To entice batch 1 customers they initially claimed target shipment on Oct 20th, and a full refund of the BTC amount paid if they don't make dec 31st.
03:34:55gmaxwell:brisque: Its become pretty hard to believe that they ever thought they could deliver on what they promised.
03:35:17phantomcircuit:gmaxwell, fun fact hashfast was trying to sell chips in bulk recently
03:35:25phantomcircuit:possibly they have the chips but they dont work
03:35:33phantomcircuit:or they cant put them on boards
03:35:38phantomcircuit:or they cant get components
03:35:40phantomcircuit:or ???
03:35:44gmaxwell:they have some demo videos now actually showing a test unit hashing,
03:35:51brisque:gmaxwell: from what I've read it looks like they underestimated the complexity, underestimated the power draw (needing new power supplies), and burnt all their funds trying to rectify it all.
03:35:58gmaxwell:and I believe that its real (esp since one of the people in #eligius went to visit them and saw it)
03:36:27gmaxwell:brisque: nah, their power was on target (you might have been duped by someone's joke post... which was sadly a little too believable)
03:36:35gmaxwell:this is the epic timeline post: https://bitcointalk.org/index.php?topic=391251.0
03:37:02brisque:gmaxwell: I wasn't duped by that post, there's a hashfast comment that they needed to order new PCB designs of a new revision.
03:37:21gmaxwell:brisque: oh that, yea, I assumed it was just a design error.
03:37:38phantomcircuit:gmaxwell, they might have the chips
03:37:43phantomcircuit:which i assume they could sell
03:37:53phantomcircuit:so possibly bankruptcy would actually be useful
03:38:04phantomcircuit:but there is no way they can actually refund people in btc
03:38:12Luke-Jr:phantomcircuit: yes there is
03:38:27brisque:hashfasts design is useless anyway. it's cheaper to just buy other designs at this point.
03:38:32phantomcircuit:Luke-Jr, if they kept the btc?
03:38:38Luke-Jr:phantomcircuit: exactly
03:38:48gmaxwell:phantomcircuit: it actually appears that they did though its hard to be sure.
03:39:01brisque:Luke-Jr: isn't there a comment about them using Bitpay, which would go to USD instantly?
03:39:17gmaxwell:brisque: they took both direct payments and bitpay, and bitpay lets the merchant choose.
03:39:19Luke-Jr:brisque: BitPay offers that *option*, but it isn't required
03:39:21phantomcircuit:gmaxwell, huh interesting
03:39:45brisque:Luke-Jr: I wasn't aware of that, interesting
03:40:29gmaxwell:the other fucked up thing is that they're claiming that you have only 15 days to request a refund, which they'll just refund a tiny fraction of the BTC paid (and a bit less than half of what you could expect to mine if they ship early january), and if you don't elect a refund in that window you can't have one.
03:41:00gmaxwell:so it looks like an optimal (scummy) strategy for them is to just build the boxes and start mining and say fuck you to everyone who doesn't refund until march.
03:41:35gmaxwell:so you either lock in an 86% loss by refunding, or take a risk that they'll do something shitty like that.
03:41:47brisque:I suppose they messed up and they're quite afraid of the consequences. I don't blame them for acting irrationally.
03:43:04gmaxwell:brisque: yea, though part of the issue is that no one has yet proposed a conceivable explination for their actions which doesn't involve fraud.
03:43:38gmaxwell:e.g. messing up doesn't explain why they were saying they were on time just a few days before they mised their original oct 20 target, and yet it turns out they didn't get anything from the fab until mid dec.
03:44:27gmaxwell:I guess the most charitable explination I can come up with is the one phantomcircuit mentioned— that they didn't raise enough money for the fab run until fairly late... but that still involves them lying about their schedule continually since november.
03:44:53brisque:gmaxwell: I can certainly relate to them from reading that timeline. you mess up a little and tell yourself that it will be alright, you can save face if you just pretend you don't make it clear. things crumble under them and they've just got to keep continuing on so as to not admit they lied in the first place.
03:45:10brisque:it's schoolchildren mentality, but there you go.
03:47:15gmaxwell:they could do other things to make it right. Their COGS on these devices should be very low. They _should_ be able to afford to double everyones order, for example.. which is what cointerra did for their december orders.
03:47:45gmaxwell:but god knows, maybe their had a failed spin.
03:49:10brisque:that market is fascinating really. we have BFL, Avalon, Hashfast and Bitfury all acting quite strangely for companies
03:49:41brisque:I can't fathom what's going on with Bitfury and ghash.io. by the looks of things they own most of the network with their own hardware.
03:51:05brisque:frustratingly there's very little information about what ghash.io actually is, and what Bitfury is doing behind the scenes with it
03:59:39gmaxwell:the old "miners will avoid violating the security assumptions for fear of making their coins worthless" argument turns out to fail because its possible to violate the assumptions and keep them secret, and people are willing to gamble that no one will notice or care if the security assumptions are violated.
04:03:07brisque:easy enough to hide your hashrate with a fake pool anyway or by replicating coinbases.
04:03:24brisque:do you like Luke would notice if I mined a block with Eligius.st's coinbase?
04:05:21brisque:back to the point, I don't think anybody would notice or care in a wider sense if Bitfury took a larger potion of the network. as it stands his portion is absolutely massive, and has some real world attacks under it's belt.. yet there's nothing really that anybody can do about it.
04:07:29gmaxwell:well, for one, they could stop giving him _more_ hashpower. :P
04:07:53gmaxwell:best estimatimates still have 1/2 to 1/3 of ghash.io's hashpower is third party.
04:08:27phantomcircuit:brisque, bitfury supplies cex.io which uses ghash.io
04:08:28gmaxwell:they could also stop buying more insanely priced chips from him, since every chip you buy from him pays for him to put 10x more than that chip onto his own farm.
04:08:35phantomcircuit:they're actually different people
04:08:47phantomcircuit:but since they're all ukrainians with weird names nobody can tell
04:09:01gmaxwell:phantomcircuit: I don't believe they are. They claim to be, but evidence I've seen suggests it's one person with a couple employees.
04:09:15phantomcircuit:gmaxwell, it's definitely different people
04:09:25phantomcircuit:they are obviously very close though
04:10:04nessence:are dzminercoop guys legit?
04:15:14CodeShark:gmaxwell: https://github.com/CodeShark/bips/blob/master/bip-n1.mediawiki
04:17:59gmaxwell:CodeShark: you realize that partially signed transactions are already implemented by bitcoin-qt, bitrated, brainwallet, and a half dozen other things, right?
04:18:18CodeShark:is there a standard?
04:19:24CodeShark:many "partially signed transaction" implementations I've seen just blank out entire input scripts
04:19:35CodeShark:which makes some of the use cases I'm considering impossible
04:20:37gmaxwell:A defacto one at least. I'm not sure what you mean by "entire input scripts"
04:20:54CodeShark:as in the entire input script is blanked
04:20:56maaku:CodeShark: what use cases are you considering?
04:21:04maaku:or rather, what do you need to do?
04:21:33CodeShark:maaku: the main thing for me right now is supporting p2sh
04:22:16CodeShark:especially in cases where the signing devices don't know anything about the scripts a priori
04:22:31CodeShark:they just need to know whether they can sign and if they sign what the implications are
04:24:00CodeShark:IMO, the signatures should have been kept as a separate list structure in the txin
04:24:05CodeShark:rather than making them part of the script :p
04:24:09CodeShark:but that's another story
04:24:53CodeShark:an account management app keeps track of script pairs (txinscript/txoutscript)
04:25:02CodeShark:the txinscript just have placeholders for signatures
04:25:14CodeShark:the signing devices just keep keychains
04:25:26CodeShark:they don't even need to know about the scripts a priori at all
04:26:34CodeShark:this will allow a good separation between account management/inbound payment processing tools (a.k.a. watch-only wallets) and signing devices
04:26:49maaku:CodeShark: why is scriptSig connected to p2sh?
04:26:57maaku:don't they figure that out by looking at the scriptPubKey?
04:27:12CodeShark:the scriptPubKey for a p2sh only holds a hash of the script
04:27:20CodeShark:which is useless to anyone who doesn't already know the script
04:27:54maaku:ok so you're partially constructing the p2sh scriptSig
04:28:08maaku:(a) wallets probably already know the scripts (but I can imagine cases where they do not)
04:28:14maaku:(b) pass it out-of-band
04:28:52CodeShark:I like the p2sh approach generally - it's the recipient's responsibility to know how to claim the output
04:29:01CodeShark:the sender doesn't really care
04:33:10CodeShark:I mean, there could be conceivable cases where the sender cares - but not for the use cases under consideration here
04:33:37gmaxwell:... https://bitcointalk.org/index.php?topic=392166.0 < KNC miner botnet.
04:36:10CodeShark:the out-of-band stuff is the principal motivation, maaku - I'm trying to develop a signing request protocol…might turn out to be a natural extension of the payment protocol
04:36:22CodeShark:a "generalized" payment protocol, so to speak
04:37:16CodeShark:which works for multisigs, coinjoin, internal company policy, merchants, and several other use cases
04:37:25phantomcircuit:gmaxwell, he's just brute forcing the passwords for web exposed boxes
04:37:40phantomcircuit:it's comical anybody has web exposed boxes at all
04:37:50gmaxwell:phantomcircuit: yea, sort of, except he can do an offline brute force, which digest auth is supposted to prevent.
04:37:59gmaxwell:presumably it uses a constant nonce or something stupid like that.
04:38:30maaku:why the hell was this posted online?
04:38:30phantomcircuit:but still
04:38:52phantomcircuit:maaku, the guy who found it decided to
04:40:09gmaxwell:someone reported the post and asked me to remove it, but I think its too late.
04:40:16maaku:phantomcircuit: i understand, but besides being unethical it is illegal with legal implicaitons if any of those boxes do get hacked
04:40:46phantomcircuit:maaku, publishing an exploit like that isn't illegal
04:40:54gmaxwell:in the grand scheme of shitty behavior in bitcoin land, someone hacking miners to divert them is probably the most minor.
04:40:55phantomcircuit:admitting to breaking into 28 boxes is
04:41:10phantomcircuit:gmaxwell, well he is basically rootkitting them
04:41:13gmaxwell:hehe 'most minor'
04:41:21phantomcircuit:those 28 people are going to have to pull the sd card to fix them
04:41:31maaku:phantomcircuit: depends on your jurisdiction, but yes publishing exploits is typically illegal
04:41:35gmaxwell:he said he didn't actually do that.
04:41:39maaku:if done in a negligent way
04:41:43phantomcircuit:oh i missed that part
04:42:12phantomcircuit:maaku, not in parts of the world with freedom
04:42:14gmaxwell:maaku: illegal? probably not. Exposes him to civil claims, perhaps.
04:42:20phantomcircuit:im going to assume he doesn't live in north korea
04:42:30phantomcircuit:since he's on the internet
04:42:48gmaxwell:actually reading again, I'm not sure what he's saying.
04:43:18gmaxwell:http digest auth doesn't prevent bruteforcing, and it actually does sound like he's doing a regular bruteforce attack. kinda boring.
04:44:15maaku:phantomcircuit: North Korea? try France, for example. In the U.S. this is borderline. see: https://www.eff.org/issues/coders/vulnerability-reporting-faq
04:44:40phantomcircuit:maaku, im not aware of anybody who has even been prosecuted in the us for disclosing a flaw
04:45:08phantomcircuit:numerous people have been subsequently accused of using the flaw under the assumption they the attack happened before they had disclosed it
04:45:14phantomcircuit:so thye must have been the attacker
04:45:21phantomcircuit:but that's not the same thing
04:50:22CodeShark:the funny thing is that this guy's "exposure of vulnerability" applies just about to pretty much any device connected directly to the Internet :p
04:50:54CodeShark:so it's not so much an exposure as it is just another example of a well-known attack
04:55:04maaku:CodeShark: it's pointing people at the factor reset script and config files to update which is more unique
04:55:22maaku:not hard to figure out by anyone technically compitent, but he reduced it down to script kiddie level
04:57:25CodeShark:the hard part is getting root access :p
04:58:27CodeShark:but yeah, this guy sounds a tad bit too boastful
05:03:25brisque:that's bold, announcing that you're exploiting people's hardware on a public forum.
05:05:09brisque:depending on the country that's most certainly illegal, akin to breaking and entering. if they get charged for doing it or not is a whole different matter.
05:05:30CodeShark:it's not announcing it that's illegal - it's doing it that's illegal
05:06:05brisque:certainly, but announcing that you did it is foolhardy
05:07:53brisque:oh dear. the user has also posted their KNC order number on the forums, and their country.
05:14:30brisque:who connects an embedded device directly to the internet anyway?
05:19:27phantomcircuit:brisque, people putting them in a dc who dont pay attention
05:20:27brisque:right. forgotten people might be doing that.
05:37:50gmaxwell:hey, could be worse, he could have posted instructions for making it look like one 1/4 of the hardware failed, while sending the 1/4 of the hashrate to himself.
05:39:16brisque:not even that, just skimming 5% of the hash power wouldn't be noticed. over 1000 units they claim to have found, that's uh.
05:40:05gmaxwell:well he only got into 28 of them I think.
05:40:58brisque:the "disclosure" is shit because we know that most of these units won't be patched in a reasonable timeframe. there's a lot that are now going to be under attack by people hoping to make a quick buck.
05:45:37gmaxwell:brisque: they don't need to be 'patched' they just need to have their password changed to something not crackable.
05:49:07brisque:gmaxwell: haven't brainwallets showed that users, even technical ones, can't make secure passwords to save their own money?
05:50:00gmaxwell:brisque: brainwallets add the extra expectation that they'll remember those passwords.
05:50:11gmaxwell:No need to remember these... just write them down.
05:51:41brisque:the point is more that people won't no matter what is being told to them. protecting $10000 of mining equipment is a difficult job when they're advertising what they are at connect time.
05:53:03gmaxwell:brisque: uh? all my miners have 128 bit passwords...
05:53:46brisque:you're not an average user.
05:53:49gmaxwell:(even though they're not internet exposed, just a standard practice. If I weren't a chickenshit I'd turn off the web interfaces entirely, but I'm a bit afraid of getting locked out.)
05:54:28gmaxwell:brisque: in any case, it's easy to give good advice for this. Well, give a little credit: An average user doesn't own a $10,000 asic miner.
05:58:01brisque:I suspect a lot of miners are in the hands of casual users though, which is why there's exposed KNC miners in DCs in the first place.
06:03:52gmaxwell:how casual can you be with a $10k device in a data center? come on— signing up for the colocation is more complicated than using a password generator and a text file. :P
06:20:54Sangheili_afk:Sangheili_afk is now known as Sangheili
07:27:41midnightmagic:ha ha ha
07:31:42midnightmagic:It would be great if that were gobbles.
07:52:30BlueMatt:I'm assuming this has been seen already: http://miki.it/pdf/BitIodine_presentation.pdf
07:53:32gmaxwell:anyone try out their software?
07:53:41gmaxwell:I queued that presentation for reading and forgot about it
07:53:52brisque1:they did a hell of a lot os scraping
07:54:02BlueMatt:it looks like they've actually thought coin analysis through, unlike most of the shit we've seen so far
07:54:33BlueMatt:mostly because of the huge amount of scraping they did
07:55:31justanotheruser:BlueMatt: "When a transaction has multiple input addresses, we can safely assume that those addresses belong to the same wallet, thus to the same user."
07:55:58justanotheruser:biggest flaw I found
07:56:11BlueMatt:yea, they didnt get that right, at least they could have said "we can usually safely assume"
07:56:17BlueMatt:because, realistically, today, you can
07:56:19brisque1:justanotheruser: generally a safe assumption, especially with some online wallets reusing addresses for change.
07:56:33brisque1:in that case you don't even have to assume.
07:57:58gmaxwell:oh wow, the presentation is kinda worthless.
07:58:38gmaxwell:BlueMatt: nah, even today a really substantial fraction of txn on the network are shared wallet transactions.
07:58:50gmaxwell:so you can't do the common inputs = same user thing.
07:58:55justanotheruser:"If multiple outputs, change is never the last output. Fixed only in January 2013!"
07:59:01justanotheruser:Most interesting thing I learned
07:59:20gmaxwell:justanotheruser: I like how it's like "software is flawed" except it was fixed long before their work. Should say 'was' but oh well.
07:59:48brisque1:you can often tell what is change just from the values. if there's a 0.1BTC output another with 8 places, you know certainly which is the change.
07:59:54gmaxwell:Gavin introduced the bug in .. what, 2010? Hal found the bug at the end of 2012.
08:00:07gmaxwell:brisque1: yea, thats a somewhat helpful hurestic. though not always true.
08:00:16BlueMatt:gmaxwell: true, though you can safely assume that the users are using the same shared wallet (which is likely the intended meaning here, though its not explicitly stated)
08:00:30gmaxwell:e.g. when the amount I move is up to me, I make the third party get the change like amount sometimes.
08:01:04gmaxwell:BlueMatt: eh. but thats strictly less useful. Because you may not know either of the users are using a shared wallet at all.
08:01:19BlueMatt:oh, sure, but its still more than nothing
08:01:44BlueMatt:and if you know which shared wallet, you can sometimes tell via other things (coinbase does some dumb double-tx shit to make the "from" address work)
08:02:04gmaxwell:yea, coinbase does dumb stuff. Strongcoin does dumb stuff.
08:02:16gmaxwell:(strongcoin makes every transaction pay some donation address of theirs)
08:02:18brisque1:seriously? coinbase wants to have "return" addresses?
08:03:38gmaxwell:brisque1: dude not just that, coinbase's merchant thing was randomly "refunding" things when it wasn't expecting a payment. (and causing people to lose bitcoin forever, dunno if its fixed yet— I assume)
08:03:58gmaxwell:brisque1: every transaction into or out of coinbase result in two transactions. Except sometimes it doesn't
08:04:37brisque1:gmaxwell: that's not giving me the warm fuzzy feeling their "safe and secure" animation says I should.
08:04:42gmaxwell:BlueMatt: in any case, share wallets are still a huge source of noise and uncertanty in this kind of analysis.
08:05:05gmaxwell:BlueMatt: just because until you have evidence that its a shared wallet you'll be falsely merging some users.
08:05:08BlueMatt:gmaxwell: yes, but I'd like to see these guys figure out ways to analyse coinbase txn to link them too, etc
08:06:54_ingsoc:brisque1: What animation?
08:07:23brisque1:_ingsoc: coinbase.com has a sort of flip clock thing that says "safe and secure" when you visit the page.
08:07:37_ingsoc:Ah, thank you. I like animations.
08:07:54gmaxwell:BlueMatt: I still think we should have some switch you can set when sending coins that lets it round up to x amount more to eliminate or round-off change.
08:08:32BlueMatt:gmaxwell: I still think all wallets should work together to make this kind of analysis impossible (coinjoin et al), but until the analysis gets amazingly accurate, we may not see that
08:14:20gmaxwell:certantly I think it's useful if the publically disclosed analysis is as powerful as any privately held analysis may be.
09:45:14mist:[Festive Global Notice] The year 2014 will soon be kicking in in some parts of the world! Join us in #freenode-newyears for fun and festivity! (Yes, there may be more comedy globals over the period, complaints to /dev/null you moaning ninnies)
11:00:37mist:[New Year Global] Happy New Year to everyone in the New Zealand time zone!
11:11:37RichiH:[Global Notice] Hi all. As the kiwis are firmly in 2014 already and the marmites are preparing, let us remind you about the spammy #freenode-newyears and the conversational #freenode-newyears-nospam . Also in the news: carrots
11:38:02jtimon:hello, does anyone has what was talked after this?
11:38:12jtimon:[02:36:09] 17:35 < maaku> or in a server-to-server consensus mechanism
11:38:12jtimon:[02:36:43] yea... except dear gods, the bitcoin blockchain is NOT a communications mechenism for your server to server consensus! _global broadcast network_
11:38:12jtimon:[02:36:52] gmaxwell: using the public chain as a semaphore for two-phase commit of a distributed transaction over multiple private asset servers
11:38:12jtimon:[12:08:31] <-- jtimon (~quassel@87.pool85-53-148.dynamic.orange.es) has quit (No Ping reply in 180 seconds.)
11:39:12RichiH:[Global Notice] a very grumpy dan408_ has requested, and confirmed, that he does not, quote, "receive enough msgs as well". he wants _you_ to fix that. do not ask me why, but have at it, i guess
12:05:28jtimon:a pastebin would do it
12:06:15brisque:I'd help you out but I don't have scrollback that far. someone will surely have logs.
15:52:56mist:[New Year Festive Notice] About 10 minutes to go until new year hits Malaysia, bits of China, and finishes sweeping through Oz. Cast greetings out in #freenode-newyears!
16:19:28andytoshi:jtimon: i have logs at http://download.wpsoftware.net/bitcoin/wizards/2013-12-31.txt which cover what you want
17:13:12jtimon:cool andytoshi thank you
17:23:18phantomcircuit:gmaxwell, bitcoin.org was moved to a dedi and the dedi died under the load
17:23:22phantomcircuit:it's like
17:23:24phantomcircuit:all static content
17:23:26phantomcircuit:how is that even
17:25:52jtimon:I'm not sure I understand this part:
17:25:54jtimon:01:38:28 gmaxwell: you need to hit the public chain for public<-->private txns
17:25:55jtimon:01:39:11 (e.g. atomic swaps of freicoins for private assets)
17:25:55jtimon:01:39:27 For anything like that you have a small number (because multisig scalablity) of known-in-advance servers. Which means you can do a regular n-of-m consensus totally external to bitcoin. E.g. an initatior proposes a distributed database update and get a supermajority of the servers to sign off on it.
17:26:24jtimon:freimarkets options also need expiries
17:27:25jtimon:but the first use case when it was reallly necessary are transitive (ripple-like) trasactions involving several in-chain and off-chain assets
17:28:08jtimon:when all the asset are off-chain you can just use a regular timestamping server all the private chains agree upon
17:29:24jtimon:what we used to call "registries" in 2PC Ripple http://archive.ripple-project.org/Protocol/RegistryCommitMethod
17:32:10jtimon:I don't know how can you implement my example "5.6.3 Hybrid Transitive transaction" (pubA -> pubB -> privC -> privD -> pubE -> userA) without block expiries
17:32:42jtimon:of course, whether you think that's an important use case or not is another question
17:34:30jtimon:as for the "dangers of expiries" the way I see it, the responsability to decide how many blocks to wait to consider a transaction "safely buried" should ALWAYS rely on the recipient
17:34:57jtimon:6 blocks is just an orientation
17:35:34jtimon:it depends much more on the quantity than in previous transactions or expiries
17:36:05jtimon:well, it will usually will, but it's still the payee's problem
17:38:53jtimon:in fact all of the examples in our off-chain transactions section rely on expiries (the all off-chain asset transaction example is missing, but it's basically 2PC Ripple)
17:57:54andytoshi:jtimon: the problem is that it the whole transaction sub-DAG is risky .. IMO requiring 100 blocks before any nExpiresTime output can be spent would solve this, and it'd be better than having no expiry time
17:58:05andytoshi:as for the weird miner incentives, i'd really have to think about that
17:59:02ziplock:ziplock has left #bitcoin-wizards
18:38:48_ingsoc:_ingsoc is now known as Guest80848
18:50:58Emcy:"BitTorrent Sync was designed with privacy and security in mind. The system uses SRP for mutual authentication and for generating session keys that ensure Perfect Forward Secrecy. All traffic between devices is encrypted with AES-128 in counter mode, using a unique session key. Modification requests are all verified using Ed25519 signatures and only systems with full access keys can generate valid modification requests."
18:51:19Emcy:that seems ok right. apart from the closed source ofc
19:02:57gmaxwell:"Hmm. Low fat. Low Sodium. That seems ok right. apart from the gives you cancer part ofc"
19:07:04Emcy:but bt sync is so usable.....
19:09:19maaku:jtimon: having transactions expire is a requirement of the system we are building. no way around that
19:11:04Emcy:i did notice in the android client sync gives you the option to email somewhere that nifty shared secret string you just generated
19:11:06Emcy:derp derp
19:11:47maaku:Emcy: that email is PGP encrypted, of course? :P
19:12:15Emcy:of course not, just uses whatever email handler you have in android. Liekly gmail
19:13:18Emcy:they should take that out and add the QR reader to the desktop app instead. The android client can already scan a QR produced by the desktop program, dont know why its not both ways
19:13:24Emcy:i guess thats why its still beta
19:18:21phantomcircuit:Emcy, i dont see any really good reason why you couldn't implement bittorrent sync with nothing more than a private tracker and a shared key
19:18:34phantomcircuit:it shouldn't even be that difficult
19:19:09Emcy:i think thats essentially what theve done
19:21:42Emcy:theyve just automated the hashing and .torrent publishing parts, and have some sort of metadata files hanging around so the nodes dont get confused about timestamps and such
19:21:42Emcy:it seems to be really quite usable though so far
19:21:42phantomcircuit:Emcy, depending on whether you trust the filesystems modification timestamp you can do all of this very very efficiently
19:21:42Emcy:its not quite dropbox level of brain absentia though
19:21:42phantomcircuit:im surprised it took them this long to do it actually
19:22:32Emcy:yeah well no one wanted to do anything with torrent tech because muh piracy
19:22:44phantomcircuit:if they wanted to make it really fast they could share the block hashes for all the files
19:23:03phantomcircuit:so you have 2 files that are 90% identical you only transfer the diff blocks
19:23:19phantomcircuit:but i bet they didn't do that and have each file setup as basically a torrent with private peering
19:23:28Emcy:i think there was actually a BEP for that for normal bittorrent
19:27:19Emcy:a thing which could maybe bring avail. <1 torrents back fromthe dead by matching data blocks from seeders of other torrents
19:27:19jtimon:maaku I though gmaxwell was proposing an alternative with multisig, but probably not the same use case
19:27:42jtimon:andytoshi, I'm not sure what you mean by "the whole transaction sub-DAG is risky", but I don't see how the 100 block wait is necessary
19:30:52jtimon:I'm not very informed on the bittorrent sync topic, but wouldn't a tahoe-LAFS GUI be better?
19:31:10andytoshi:jtimon: if a tx gets expired as a consequence of some reorg, the receiver of the btc loses out -- and so does everyone he spent to, and everyone they spent to, and so on
19:31:34andytoshi:the whole transaction chain is invalidated, so the risk model is the same as that for coinbase transactions
19:31:36andytoshi:hence the 100 block wait
19:31:40jtimon:that's the receiveer problem, why didn't he wait for reorgs to be unlikely?
19:32:04maaku:jtimon: they like the fact that any non-coinbase tx that hits the chain can only be made invalid by malicious/buggy clients
19:32:23jtimon:or by a later double-spend
19:32:31andytoshi:jtimon: because he's an spv node and he didn't know that there was an nExpiresTime tx 2 layers back in the blockchain
19:32:43maaku:jtimon: that falls under the malicious category
19:33:17jtimon:can SPV wait less confirmation than rational people just because they have less information about the global state?
19:33:18maaku:as you say, it is trivially solved by having the receiver wait 100 blocks, then you have the same security as other transactions
19:33:27andytoshi:jtimon: and actually, if people are doing this sort of analysis when considering whether to receive coins, then the coins are non-fungible
19:33:33andytoshi:(at least temporarily)
19:33:35jtimon:why 100? where that number comes from?
19:33:38maaku:or, alternatively, tracing inputs back 100 blocks to show that they are not expiring soon
19:33:44maaku:coinbase maturity
19:34:08andytoshi:jtimon: 100 is arbitrary, just to be consistent with coinbases
19:34:32maaku:i'm just saying that would get you to the same level - right now any bitcoin transaction could get reversed in a reorg of >100 blocks
19:34:34jtimon:if you wait 50 blocks you are probably pretty secure despite previous coinbases or expiries
19:34:47maaku:well not *any* txn, but as a SPV node you don't know which ones
19:35:37adam3us:jtimon: thanks for the url btw i was unable to find "original ripple" before archive.ripple-project.org! all other urls and history redirects to ripple.com which maybe moderately different
19:36:10maaku:adam3us: significantly different
19:37:07jtimon:adam3us that link was to the 2PC distributed Ripple protocol, which is radically different from ripple.com
19:38:13maaku:jtimon: you know i think this is a non-issue, but it falls in a similar category as refheights
19:38:25maaku:you have to change your behavior slightly, and maybe adjust how clients/wallets work
19:38:27jtimon:everything is "off-chain" and you can actually trade 2PC assets for bitcoins (not btc denominated IOUs) atomically
19:38:58jtimon:if there wasn't expiries
19:39:39jtimon:all clients should probably determine the "secure number of confirmations" from the value of the transaction received
19:40:22jtimon:my point is that with expiries, transaction value is still the more important criterion
19:40:32jtimon:for both SPV and non-SPV clients
19:41:01maaku:jtimon: the ~100 blocks of security becomes a concern during network-wide problems like the March fork
19:41:30maaku:where opportunistic people can build chains off of expiring transactions on the bad fork, and cause merchants to lose money
19:41:40jtimon:maybe some miners
19:42:00maaku:but there are solutions that could be put in place on the merchant and wallet side to fix that
19:42:47maaku:by estimating nethash you'd be able to see the drop in hash power that would signal a fork, and delay/postpone any irreversable actions
19:43:14jtimon:march fork was exceptional, it was an unexpected hardfork
19:43:26jtimon:what are the chances of that happening again?
19:44:30maaku:pretty high, just not on a regular basis
19:44:35maaku:or you can make 100 confirms, or something as absurdly high the norm for high-value transactions
19:45:03maaku:and let clients/wallets use old coins with short proofs showing that they can't be reversed in less than N blocks
19:45:26jtimon:"high-value" doesn't exist in chain
19:45:45maaku:it's not something you have to reach consensus over
19:45:59jtimon:value is only in our heads, thus outside the chain
19:46:02jtimon:oh, I see
19:46:09jtimon:client policies
19:46:11maaku:i'm just saying the merchant waits until processing your gateway withdrawal or shipping your order or whatever
19:46:37jtimon:yeah, I'm with client policies as well
19:46:55maaku:unless your client used old coins and provided proof, which could even be made the default behavior with little more than a UI checkbox for "expediatd transaction"
19:47:23jtimon:in certain way I'm with miners policies too I don't like "non-standard fees" for the long run
19:48:14maaku:so my position is that like refheights this is a developer education problem
19:48:20maaku:but what we get out of it is absolutely worth it
19:48:48maaku:what do you mean?
19:48:58jtimon:I still I don't see how unexpected hardforks can be common anyway
19:49:46gmaxwell:who cares if its common, if you play your cards right its world ending.
19:49:47jtimon:and although I think the devs did the right thing, they could have been chosen the other solution
19:49:58gmaxwell:As in .. some event happens and it can never be recovered.
19:50:22jtimon:it was the ref implementation which wasn't following the protocol specification
19:51:19jtimon:we could have had much lower hashrates until the ref implementation was fixed
19:51:31gmaxwell:... thats what we did.
19:51:41gmaxwell:we fixed the ref implementation to match the old.
19:51:59jtimon:that's the opposite of what I'm saying
19:52:17maaku:gmaxwell: you get just as much gloom and doom from a >100 block reorg now, and merchant policies can limit their exposure to be the same
19:52:20jtimon:we said "the rules aren't the specification, the rules were the old implementation"
19:52:21gmaxwell:jtimon: something like 80% of nodes were on the other fork including every major merchant, it would have been a non-issue except for the fact that 3 upgraded miners constuted >60% of the hashpower.
19:52:49jtimon:we could have as well said "the rules are the specification, fuck the old implementation for not following it"
19:52:50gmaxwell:maaku: yes, >100. But the events we've had have been <20.
19:53:10maaku:"merchant policies can limit their exposure to be the same"
19:53:32maaku:the only guys who got screwed are the ones who weren't doing adequate coin safety
19:53:41gmaxwell:jtimon: gee thats nice, except for the 80% of nodes including all major merchants who were actively being defrauded.
19:54:02jtimon:exactly, the decision was taken (sanely) counting miners and merchants, instead of being strict with the defined rules
19:54:46gmaxwell:jtimon: not to mention the utterly insane risk of rapidly forcing everyone onto bleeding edge software... including god knows how many people who had highly customized code who are _still_ on 0.7.x with patches.
19:54:58adam3us:the 2pc ripple seems a bit like OpenTranscations security model also... get signed/timestamped receipts from servers, users audit servers, if they detect malicious server, they have proof, and can rebuild server state with the receipts (in theory though maybe the rebuild part may not be automated yet)
19:55:05gmaxwell:jtimon: the decision was simply "the deployed software is the spec"
19:55:06jtimon:I'm not saying the decision was wrong
19:55:20jtimon:but I hate that justification
19:56:03jtimon:I prefer to justify it as "following the specs instead of the ref code would have had worse consequences"
19:56:26gmaxwell:jtimon: You can point at a stack of paper and say "but the rules!" all day... but the paper doesn't do shit. The behavior of the participants is what defines the rules in a consensus system.
19:57:01gmaxwell:jtimon: well of course, it's not like we say "the deployed software is the spec" because God gave that to us on a tablet,— rather, its the necessary thing to achieve good outcomes in 99.99% of cases.
19:57:13jtimon:agreed, of ALL the participants, not just miners
19:57:41jtimon:as some seemed to imply at the time
19:57:44gmaxwell:absolutely not just miners, and double absolutely not hashpower.
19:57:51jtimon:let me put it another way
19:57:56gmaxwell:Those implying that are not competent.
19:58:52jtimon:if 90% of the hash power was in the old code and 90% of merchants and users are on the specs (I know that wasn't the case), what's the right chain?
19:58:56gmaxwell:(And as you may note, in that hardfork the majority of hashpower was the new behavior... due to the fact that hashpower is controlled by basically 3-4 people, and they'd upgraded faster than the rest of the network due to the competative incentive of orphaning reduction)
19:59:18jtimon:yeah, ok, good point
19:59:39gmaxwell:Merchants and users would be the right chain generally.
19:59:41adam3us:i suppose this is another reason pooled mining can be a problem
19:59:43jtimon:the majority of hash was on the specs back then and we went with users
20:00:00adam3us:and economies of scale in mining
20:00:12jtimon:I agree, merchants and users are the right chain
20:00:15gmaxwell:(90% hashpower might just be 50 people that need to fix themselves)
20:00:46gmaxwell:(but even ignoring that, I think its reasonable and prudent that mining basically takes more of the risk, and pratically every miner whos thought about any of this would agree)
20:01:26adam3us:gmaxwell: how do u think that fork would've played out if there was no pooled mining and mostly decentralized mining power? better or worse? (more distributed consensus on sw upgrade, maybe slower reaction time)
20:01:35jtimon:adam3us, 2PC is similar to OT in some senses, but simpler (not so many instruments) and...in OT all atomic stuff occurs in a single server, with 2PC, there's atomic trades involving an arbbitrary number of independent servers that don't necessarily trust each other
20:01:50gmaxwell:adam3us: I don't think the fork would have happened, in fact.
20:02:03gmaxwell:(well, it would have self resolved)
20:02:20adam3us:gmaxwell: well wasnt the fork the result of the level db bug? how would it have self-resolved... a few people early would've noticed problems
20:02:30adam3us:gmaxwell: and been outvoted anyway, and then the bug backed-out?
20:02:32maaku:adam3us: It would have been much harder to side with the users
20:02:47gmaxwell:adam3us: it would have been hashpower overtaken
20:02:48maaku:if there weren't any big miners you could get to switch chains
20:03:00gmaxwell:maaku: there wouldn't have been an artificial miner/user split there.
20:03:11adam3us:jtimon: i think OT also has a concept called voting pools like k of n pools have to agree for a tx to complete
20:03:19gmaxwell:most _miners_ were also on old code at the time too.
20:03:29maaku:gmaxwell: yes there would. miners-set doesn't overlap well with user-set
20:03:34gmaxwell:it's just that most hashpower was on the new stuff.
20:03:55adam3us:gmaxwell: we could really do with direct mining protocol for that reason also. difficult to make that work though.
20:04:18adam3us:gmaxwell: a lesson therefore without decentralization, is the centralized parties need to use intelligence and gradual phase in
20:04:25gmaxwell:maaku: at the time most of p2pool's hashpower stayed on the 0.7 side.. though it was complicated by the fact that 0.7 didn't reliably reject the new chain.
20:04:44adam3us:gmaxwell: however i think from views expressed here that most of the mining power has very limited "intelligence" applied to it at all
20:04:50gmaxwell:(it wasn't a real hard fork, it was a softboiled fork. :P )
20:05:12maaku:adam3us: iirc Luke does a good job of this. he runs blocks past multiple node versions
20:05:36gmaxwell:yes, it would be easier for more to do that if we'd merged luke's patches for that.. but they were pretty invasive.
20:07:43jtimon:adam3us, but that's not more scalable, that's like a "shared server" much like ripple.com's consensus mechanism
20:09:12adam3us:maaku: yes Luke-Jr is a rare example of pool intelligence
22:14:50irc.freenode.net:Disconnected from irc.freenode.net (ERROR :Closing Link: S0106c0c1c0894c25.vs.shawcable.net (Ping timeout: 265 seconds))
22:15:06dickson.freenode.net:topic is: Bitcoin research, hardfork wishlist, ideas for the future - see also: https://en.bitcoin.it/wiki/Hardfork_Wishlist https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas
22:15:06dickson.freenode.net:Users on #bitcoin-wizards: andytoshi-logbot andytoshi justanotheruser MoALTz_ go11111111111 mappum spinza_ Guest80848 gribble bizzle deepc0re_ Graet hnz jtimon fagmuffinz Luke-Jr Dylan_ Emcy gmaxwell CodeShark BlueMatt rs0_ OneFixt espes__ Fistful_of_Coins realazthat iddo Krellan Hunger- jrmithdobbs jarpiain ghtdak @ChanServ maaku forrestv tucenaber typex warren sipa wumpus jgarzik Alanius K1773R helo Sangheili edulix michagogo|cloud kinlo wangbus amiller hno
22:15:06dickson.freenode.net:Users on #bitcoin-wizards: harrow EasyAt petertodd nanotube azariah4 phantomcircuit Mikalv midnightmagic epscy UukGoblin pigeons trn lianj cfields Ryan52 HM2
22:17:31andytoshi:hey, it came back on its own :)
22:56:40realazthat:realazthat is now known as rudest
23:25:55rudest:rudest is now known as realazthat
23:42:49gmaxwell:but ... now it seems to have a droopy leg and a strange interest in brains.