07:40 < kanzure> i have been pondering reorgs...
07:40 < kanzure> imagine that an attacker deposits into some bitcoin service (not necessarily an exchange), then withdraws where the service does not make a withdrawal based on other unspent outputs unrelated to the deposit.
07:40 < kanzure> in the event of a reorg, the attacker could try to mine a block that does not include the deposit, but does include the withdrawal.
07:40 < kanzure> so it seems like the only way to defend against this is to always only allow withdraws based on unspents that have referenced the original deposit in their history somewhere (it can be either the immediate prevout or any  in the history). but other than that, i can't think of a way to defend against this.
07:42 < kanzure> oops instead of "then withdraws where the service does not make a withdrawal based on other unspent outputs unrelated to the deposit" i mean "then withdraws where the service does not make a withdrawal transaction based on the deposited unspent outputs"
07:42 <@andytoshi> kanzure: mining the withdrawal wouldn't prevent someone else mining the deposit right?
07:42 <@andytoshi> so it's actually a harder attack to pull off because you aren't preventing the honest case from happening?
07:43 < kanzure> er, let me clarify
07:43 < kanzure> i mean that the deposit no longer exists in the blockchain after the reorg
07:43 < kanzure> but the withdrawal does
07:44 < kanzure> my idea for preventing this is to make all withdrawals (per user) always reference every single one of their deposits somehow (even if their deposits were spent some other way? i dunno.) one way to do this would be to always keep at least 1 satoshi for their deposits to couple to future withdrawals. so if their deposits ever vanish, then their withdrawals by definition must vanish.
07:45 <@andytoshi> yeah, in bitcoin i think to reference all deposits like this you'd have to have them as inputs
07:45 <@andytoshi> which is gonna scale really badly
07:45 < kanzure> i think it's just "as long as the inputs 'touch it' somehow" really-- it doesn't have to be a huge list of inputs, just 1 i think
07:45 <@andytoshi> ah, no, you could consolidate all deposits, then just reference the consolidated out..
07:45 < kanzure> right
07:45 <@andytoshi> yup
07:46 <@andytoshi> still seems more wasteful than it inprinciple needs to be
07:46 <@andytoshi> but i think that's best you can do with bitcoin
07:46 < kanzure> so per-user there must be a consolidated output transaction, and there must be at least 1 satoshi remaining of that consolidated balance, i think? and the other balance can be sent anywhere else.
07:46 < kanzure> yeah i mean i see no alternative to this
07:46 < kanzure> otherwise you will absolutely lose bitcoin in a reorg
07:47 < kanzure> andytoshi: i've been coding up an example of this idea.. not finished yet though https://github.com/kanzure/bitcoin-reorg-compatibility-toy
07:47 < kanzure> i am a little worried that this concept is not more prevalent or strongly encouraged
07:48 < kanzure> does this mean everyone has just been ignoring this problem or what
07:48 <@andytoshi> kanzure: yeah, generally the attitude is "wait enough confs and reorgs are impossible"
07:48 < kanzure> but that's not true though
07:48 < kanzure> i mean yes i agree that's the general consensus attitude
07:49 <@andytoshi> you're right, but i could easily argue that in public in a way you'd have a tough time arguing against..
07:49 <@andytoshi> it's too subtle for most people
07:49 < kanzure> what does your consolidated output tx look like?
07:49 <@andytoshi> and "word on the street" is that confs make things irreversible
07:49 <@andytoshi> kanzure: one big out
07:49 <@andytoshi> per user
07:50 <@andytoshi> it'd be created every day or whenever deposits are recognized
07:50 < kanzure> so once they deposit, make a zero-confirm tx that spends their output to an internal-controlled address, and this zero-confirm tx should have an input of at least 1 satoshi from the previous consolidated tx?
07:50 <@andytoshi> yeah
07:50 <@andytoshi> well
07:50 < kanzure> hmm. okay. i'll have to think about how to do the proper tracking around that previous-consolidated-tx-out.
07:51 <@andytoshi> it'd have to be an input that you actually own
07:51 <@andytoshi> so the deposit output
07:52 < kanzure> so the tx should have the input from this latest deposit, and an input from the previously-consolidated-tx-output, and in the event of this being the first deposit from the user i don't know what to do...
07:53 < kanzure> oh wait this was for withdrawals
07:53 <+andytoshi> in the event of the first deposit, the first deposit -is- the "consolidated out"
07:53 < kanzure> yeah okay, the withdrawal is the one that references the inputs from the consolidated output of course.
07:53 <+andytoshi> yup
07:54 < kanzure> cool
07:54 < kanzure> very neat
07:55 < kanzure> and if ever there is supposed to be a withdrawal that does not originate from that user's deposits... hrm.
07:55 <+andytoshi> maybe what you want is for your cold wallet to always sign SIGHASH_SINGLE txes which just move all its coin from itself to itself
07:56 <+andytoshi> which would implicate every transfer -to- the cold wallet .. then you include one of these txes in each withdrawal tx
07:56 <+andytoshi> oh, no, that requires "cold" to be very weak bc you'd have to do a new one for every withdrawal
07:58 <+andytoshi> kanzure: the idea would be, you just move one of the user's deposits as part of each withdrawal
07:58 < kanzure> if a withdrawal ever touches balances from multiple different users then that withdrawal tx must include one input per consolidated tx (so per user that the deposits originally move from)
07:58 <+andytoshi> you don't need to actually withdraw "from" the deposit
07:58 < kanzure> the problem is that a withdrawal can happen without a deposit
07:59 < kanzure> *without a deposit by that user
07:59 <+andytoshi> so i would consider having an output whose history involves every single deposit for all users, and just moving that within each withdrawal
07:59 < kanzure> right, that seems to be the safe thing, i agree
07:59 < kanzure> and then if there's ever any breakage, you just run forward from thta point honoring the withdrawals you were supposed to be making
07:59 < kanzure> *that
08:00 < kanzure> (if there's enough BTC and the lack of the existence of the transaction is not damaging)
08:00 <+andytoshi> yeah
08:00 < kanzure> the other weird thing is that when processing a reorg, a deposit may go missing but end up higher in the blockchain or something
08:00 <+andytoshi>  it'd be a non-automatic process
08:00 <+andytoshi> probably
08:01 <+andytoshi> yeah, so maybe you want to wait before reacting
08:01 < kanzure> so it may look like you're missing a deposit, but in reality a deposit just happened at a different time
08:01 < kanzure> in reality in this sort of reorg scenario anyway, all of your [previous withdrawal, and consolidation] transactions have been invalidated because of your clever tx scheme anyway, so you just wait and then start a new series of transactions after that point
08:02 < kanzure> is there a way to do this without consolidating all user/deposit inputs into a massive single tx?
08:02 <+andytoshi> well, you can use the old transactions, you just have to wait then publish them in order
08:02 <+andytoshi> unless there is actually a double-spend
08:03 <+andytoshi> so, you don't have to consolidate into a single massive tx (or single output)
08:03 < kanzure> there could be a pool of "consolidated outputs" i think
08:03 <+andytoshi> yeah
08:03 <+andytoshi> and you only need to reference one
08:03 <+andytoshi> in any given withdrawal
08:03 < kanzure> and each one in the pool has the same rules i think. i don't know when you would choose to make a new consolidated output though.. or when to merge them.. er..
08:04 <+andytoshi> i'd say, whenever you mark a deposit as "available for trade" you'd consolidate it with some existing output
08:04 <+andytoshi> existing consolidated output*
08:04 < kanzure> note, i think this is not exchanges-only, seems relevant to many possible bitcoin services
08:05 <+andytoshi> whenever you mark a deposit as "received, thanks user!"
08:05 <+andytoshi> as opposed to "pending" or whatever
08:05 < kanzure> ah so here's why a pool of different "consolidated tx outs" wont work: the problem is that a withdrawal may be made that uses outputs that are unrelated to a certain deposit. all deposits must be referenced.. that's the only way.
08:06 <+andytoshi> right
08:06 <+andytoshi> what i mean is, in a consolidating transaction you can have many outputs
08:07 <+andytoshi> and each of those is exactly as usable as a "consolidated tx out" as any other
08:07 < kanzure> oh
08:07 < kanzure> right
08:07 <+andytoshi> ah, but you're saying every time you re-consolidate you have to reference them all..
08:07 < kanzure> yes
08:07 <+andytoshi> oh, no, you just have to reference one ... and each re-consolidation would "split it"
08:07 < kanzure> the rule is basically: you should never allow a withdrawal from an unspent output that is unrelated to the latest set of deposits.
08:07 <+andytoshi> so you'd wind up with many "consolidated outs" which can be used to commit to various points in your history
08:08 <+andytoshi> a better rule: you should never allow a withdrawal via a transaction that does not include any inputs that are related to the set of deposits as seen at the time of the user's last deposit
08:08 <+andytoshi> at or after the time*
08:09 < kanzure> it's not just the user's deposits. it may be other users. because this user may have never deposited BTC...
08:09 <+andytoshi> if the user has never deposited BTC what exactly is the attack?
08:09 < kanzure> withdrawing BTC with insufficient reserve?
08:10 <+andytoshi> better safe than sorry, i guess, but that sounds like more of a vandalism attack than a theft attack
08:10 <+andytoshi> because without faking a deposit the user has not gained money he is not entitled to
08:11 < kanzure> i don't care if the user gains money, i care if the service loses money :)
08:11 < kanzure> i am thinking about the attack specifically. give me a few moments.
08:11 <+andytoshi> sure, that's fair, but i think nobody is motivated to do this attack :)
08:12 < kanzure> i guess it's not an attack really,
08:12 < kanzure> imagine that there are some old unspents that the user is withdrawing from
08:12 < kanzure> after the existence of those unspents,
08:12 < kanzure> there was some other user that made a deposit
08:13 < kanzure> other withdrawals occur
08:13 < kanzure> at the time that you issue the transaction to the user to withdraw the old unspents, you are allowing the withdrawal based on your understanding of the current net reserves
08:13 < kanzure> so if the reorg happens, that withdrawal tx you made that spends those old unspents is still technically valid and possibly even in the reorged version of the blockchain
08:14 < dgenr8> kanzure: shouldn't service just have a rule that reorg'd deposits are charged to the user?
08:14 < kanzure> which bleeds reserves that you should have kept
08:14 < kanzure> dgenr8: from a legal/accounting point of view sure.... that would be fun.
08:15 <+andytoshi> kanzure: right, but if a reorg occurs that changes your current net reserves, that is a deliberate (and expensive) attack on you
08:15 < kanzure> i believe we established these adversaries have unlimited funds heh
08:15 <+andytoshi> and i'm not clear what the reward is
08:15 <+andytoshi> yeah, sure
08:15 <+andytoshi> kanzure: but actually, you're right anyway, the user could just use two accounts
08:15 < kanzure> or maybe colluding users
08:15 <+andytoshi> which is what the user would do, in fact, if he knew you were using my scheme
08:16 <+andytoshi> your scheme blocks this
08:16 < kanzure> hmm.
08:16 < kanzure> yeah but my scheme sucks for privacy reasons
08:16 <+andytoshi> big time
08:16 <+andytoshi> and i don't think it's fixable actually, you explicitly need the linkability
08:17 <+andytoshi> if you were to unlink things in any way it'd break the current-reserve dependency
08:17 <+andytoshi> eg by coinswap or sidechain transfers
08:17 < kanzure> right.. i can't even think of a fix to bitcoind that would change all this.
08:17 <+andytoshi> we are well into "bitcoind tracks the chain and receives {sign|create}rawtransaction rpcs" here..
08:18 < kanzure> oh sure
08:18 < kanzure> i think that my scheme would be unnecessary if reorgs couldn't include/exclude transactions at will or something
08:19 < kanzure> but of course that's totally impossible to get, so :)
08:20 < kanzure> andytoshi: so one possible alternative is to always prefer super old confirmed outputs as inputs to withdrawals
08:20 -!- JackWinter_ [~jack@vodsl-11198.vo.lu] has quit [Quit: Konversation terminated!]
08:20 < kanzure> oh wait, hrm
08:20 -!- akstunt600 [~ak@65-78-62-173.c3-0.upd-ubr2.trpr-upd.pa.static.cable.rcn.com] has joined #bitcoin
08:20 <+andytoshi> dgenr8: because there is no "cleared" in bitcoin
08:20 <+andytoshi> kanzure: sure, if you are willing to trust confirmations now :)
08:21 -!- Lycerion [~Lycerion@unaffiliated/lycerion] has joined #bitcoin
08:21 < kanzure> yeah nevermind on that one
08:21 < kanzure> old unspents are more valuable really
08:21 <+andytoshi> yeah :/
08:21 < kanzure> what about a way to link the deposit step somehow
08:21 < kanzure> er.. hm.
08:22 <+andytoshi> though fwiw "old" is pretty binary, sometime between 100-1000 confs things are irreversible
08:22 <+andytoshi> in a "absolutely everything blows up if such a reorg happens" sense
08:22 -!- JackWinter [~jack@vodsl-11198.vo.lu] has joined #bitcoin
08:22 < kanzure> right.. it definitely looks like that would cause a bunch of problems.
08:23 < kanzure> it seems to me that if you write software that can correctly deal with that situation on the bitcoin end, it's possible to recover from that sort of disaster
08:23 -!- davidhq [~textual@93-103-183-27.dynamic.t-2.net] has joined #bitcoin
08:23 < kanzure> for example, if you deal with wire transfers or something i think those can be reversed too
08:23 < kanzure> it might take way longer of course
08:24 < kanzure> and every bitcoin service/company should always be trying to send out previous transactions that may still be valid in the event of that sort of reorg, to try to recover as many of the deposits or w/e as possible before  double spends happen
08:24 -!- nfnty [~nfnty@h172n4-lk-a31.ias.bredband.telia.com] has quit [Quit: Leaving]
08:24 < kanzure> (if double spends haven't happened already)
08:26 -!- joaopizani [~weechat@87-251-56-246.lombox.customer.bit.nl] has quit [Client Quit]
08:26 -!- Luke [~Luke@unaffiliated/luke] has quit [Quit: part]
08:27 < kanzure> andytoshi: so here's a thing.... if i use my scheme, then i basically force all withdrawing users to use services that implement this scheme too, otherwise i am causing a huge chain of brokenness on their behalfs because transactions will be disappearing.
08:28 < kanzure> this is going to quickly sound like a mutually assured destruction scheme ("everyone has to implement this because if you don't and you receive a transaction generated by this sort of withdrawal scheme, you will be easily invalidated in the event of a reorg, more so than if this shceme was not being implemented by everyone")
08:29 -!- scaramouche1 [~scaramouc@gateway/tor-sasl/scaramouche1] has joined #bitcoin
08:29 <+andytoshi> i don't see that implication
08:30 <+andytoshi> kanzure: what transactions do you expect to disappear? any ones that you care about are commited to..
08:30 <+andytoshi> ah, you are saying that you are propagating the disappearance
08:30 < kanzure> withdrawals that i paid out to users
08:30 <+andytoshi> yup
08:30 < kanzure> yes
08:30 < kanzure> which may not be bad really, it would be nice to enforce good design on everyone else
08:30 < kanzure> and they should not benefit from services poorly implementing withdrawals [e.g. that lose funds in a reorg because they have paid out those funds in a withdrawal already, but lose a deposit, etc... i could elaborate later i guess]
08:31 <+andytoshi> i'm not sure you're increasing their risk from txes disappearing
08:31 <+andytoshi> they are already exposed
08:31 < kanzure> as you touch more of the percent of available tx outs with this scheme, you increase the rippling effect or something
08:31 < kanzure> i think...
08:31 <+andytoshi> this is true
08:31 <+andytoshi> i'm not sure how significant it'd be
08:31 < kanzure> but yes i agree they are already exposed in general
08:32 <+andytoshi> i have literally no clue what the taint viscoscity is
08:32 < kanzure> gmaxwell: let's bug gmaxwell about it
08:32 <+andytoshi> lol