1 2017-06-04 10:08:40 <mem0x> hi, I'm trying to figure out how to deserialize the chainstate structure in level db (the 'c' record), I'm looking at the Unserialize method in coins.h but don't understand what it's doing. any pointer? other place in the code I should look at?
  2 2017-06-04 10:41:42 <mem0x> to answer my own question, this was what I was looking for: https://bitcoin.stackexchange.com/questions/31978/how-does-serializing-in-coins-h-work
  3 2017-06-04 10:41:45 <mem0x> :)
  4 2017-06-04 18:00:27 <Iriez> Could someone please confirm whether replay attack protection is even possible under BIP148? It seems to be overly complicated to attempt to get your coins confirmed on what will be the BIP148 chain, while not confirmed on the legacy chain post august 1st.
  5 2017-06-04 18:01:53 <Iriez> The only realistic option I've had theorized to me would be for BIP148 miners to offer a coinjoin on their bip148 block reward. Which requires some amount of trut and coordination.
  6 2017-06-04 18:02:59 <arubi> at the time of the split, see which chain is advancing faster, send a timelocked transaction to some blocks in the future, and redeem earliest as possible
  7 2017-06-04 18:03:38 <arubi> if it confirms right away and the slower chain didn't catch up yet, you're guaranteed successful replay protection for yourself
  8 2017-06-04 18:04:25 <Iriez> arubi: but what if the slower chain does catch up?
  9 2017-06-04 18:04:36 <Iriez> wouldn't it also then confirm that tx on the other chain?
 10 2017-06-04 18:05:37 <Iriez> or is the point of the timelock to expire before the slow chain can catch up?
 11 2017-06-04 18:05:38 <arubi> I don't think it'll get relayed on the slower chain's network
 12 2017-06-04 18:05:44 <arubi> because it's not final yet
 13 2017-06-04 18:06:01 <Iriez> right, its not final until the timelock passes
 14 2017-06-04 18:06:03 <arubi> so then you spend to a different output on the slower chain when it does catch up
 15 2017-06-04 18:06:05 <Iriez> hum, thats good.
 16 2017-06-04 18:06:37 <Iriez> At least, its much better than everything else I've seen, but still......not good enough to create the massive move of funds to the bip148 chain.
 17 2017-06-04 18:06:58 <Iriez> How many people are going to be willing to do this?
 18 2017-06-04 18:07:10 <Iriez> Not enough to move the needle in favor of bip148 im thinking, not enough by a landslide.
 19 2017-06-04 18:07:48 <arubi> it's not very easy, right, but I think miners would love to pay into exchanges as fast as possible after the fork
 20 2017-06-04 18:08:00 <arubi> and that would take 100 blocks
 21 2017-06-04 18:08:35 <arubi> slowly if people move their non replayable funds to exchanges, then it all gets mixed quickly
 22 2017-06-04 18:08:51 <Iriez> which would incentivize them to stick to the chain that confirms the fastest.
 23 2017-06-04 18:08:56 <Iriez> e.g. most hashpower
 24 2017-06-04 18:09:09 <arubi> oh I think exchanges would love supporting both chains
 25 2017-06-04 18:09:20 <Iriez> well my foots tapping waiting for announcements :P
 26 2017-06-04 18:09:48 <arubi> it's a sure thing imo.  the fees are going to be significant if it happens
 27 2017-06-04 18:10:14 <arubi> but really I think bip148 will pass very quickly :)
 28 2017-06-04 18:10:26 <Iriez> In favor of or against?
 29 2017-06-04 18:10:41 <arubi> in favor, pass successfully
 30 2017-06-04 18:11:15 <Iriez> Hum. I was on that side, and the more I learn the more I think it wont do very much. But that depends on ecosystem support
 31 2017-06-04 18:11:26 <Iriez> if exchanges do support it broadly, then chances for success are much greater
 32 2017-06-04 18:11:50 <arubi> any player on the legacy chain risks losing everything
 33 2017-06-04 18:12:18 <Iriez> assuming the bip148 continues
 34 2017-06-04 18:12:24 <arubi> it has to
 35 2017-06-04 18:12:35 <arubi> I mean, if it's worth anything, it will be mined
 36 2017-06-04 18:12:36 <Iriez> What if users have difficulty transacting on that chain?
 37 2017-06-04 18:12:52 <Iriez> if theres no economic activity solely on that side, then it wont be worth anything
 38 2017-06-04 18:13:01 <Iriez> but that would require users to split
 39 2017-06-04 18:13:03 <arubi> if it's not completely halted
 40 2017-06-04 18:13:17 <Iriez> and right now there doesn't seem a easy way to do that
 41 2017-06-04 18:13:32 <Iriez> however if exchanges got involved then it would be much easier as they could guarantee bip148 coins
 42 2017-06-04 18:13:39 <Iriez> (at least, I think so?)
 43 2017-06-04 18:14:14 <arubi> well, they're taking a risk.  they might want to exchange all profits to bip148 coins :)
 44 2017-06-04 18:14:48 <Iriez> Hrm, now thats got me thinking. CAN exchanges guarantee bip148 coins?
 45 2017-06-04 18:14:59 <Iriez> It would require enormous backend work I think, but possible given some time
 46 2017-06-04 18:15:03 <arubi> the bip148 chain is guaranteed
 47 2017-06-04 18:15:30 <Iriez> yes, but there is no guarantee that a tx sent wont be confirmed on both sides
 48 2017-06-04 18:15:43 <Iriez> so the exchange would have to send from uxto's that have already been split on bip148's side
 49 2017-06-04 18:16:03 <arubi> they can't support double spends
 50 2017-06-04 18:16:13 <arubi> or maybe they can
 51 2017-06-04 18:16:13 <Iriez> its not a double spend if its on 2 diff chain?
 52 2017-06-04 18:16:28 <arubi> I mean, just fund both the user's wallets
 53 2017-06-04 18:16:30 <Iriez> and the other chain would ignore the tx if its from a bip148 only uxto
 54 2017-06-04 18:16:48 <arubi> why ignore it though?  maybe the person did want it sent to both wallets?
 55 2017-06-04 18:16:54 <Iriez> ah, yes, i see where you are going BUT, how can you guarantee that it will get confirmed on both chains?
 56 2017-06-04 18:17:05 <arubi> you don't have to, it's independent
 57 2017-06-04 18:17:10 <Iriez> I suppose a high enough fee will sort that.
 58 2017-06-04 18:17:12 <arubi> you treat it as you would any client
 59 2017-06-04 18:17:15 <Iriez> right
 60 2017-06-04 18:18:41 <Iriez> Thanks, you've added some good perspective.
 61 2017-06-04 18:18:54 <arubi> cheers, hopefully segwit will be active by then :)
 62 2017-06-04 18:19:22 <Iriez> so, if it sends it to both wallets, then the coins are not split.
 63 2017-06-04 18:19:48 <arubi> as long as it's on their exchange, the user just handles their virtual balance
 64 2017-06-04 18:19:59 <arubi> that they track anyway across altcoins that they support
 65 2017-06-04 18:20:01 <Iriez> how would the exchange ensure if the user withdrawals from the bip148 wallet that it goes to the bip148 chain?
 66 2017-06-04 18:20:21 <arubi> they send to the user from an output already exclusively on the bip148 chain
 67 2017-06-04 18:20:28 <Iriez> They would have to have a pool of coins already on bip148
 68 2017-06-04 18:20:40 <arubi> right, even if there were replay protection
 69 2017-06-04 18:20:51 <Iriez> Yea, this is freaking complicated =)
 70 2017-06-04 18:21:13 <arubi> hehe, interesting times
 71 2017-06-04 18:21:22 <Iriez> but, I guess it could be made...somewhat easy, as long as the exchanges were on board
 72 2017-06-04 18:21:32 <arubi> they like exchange fees
 73 2017-06-04 18:21:45 <Iriez> for users wishing to transact on bip148 chain outside of exchanges though....thats a problem
 74 2017-06-04 18:23:06 <Iriez> So the exchanges can receive coins, and then split it internally, and then virtually assign balances. But users cannot do this, so they have no option other than trying that timelock trick
 75 2017-06-04 18:23:11 <arubi> yea..  maybe if hashrate is so evenly divided that both chains will continue for some time, then there would be some need for replay protection or some service to help
 76 2017-06-04 18:23:20 <Iriez> right
 77 2017-06-04 18:23:48 <Iriez> exchanges could offer such a service, for a fee. Or wallet developers. Hey what about belcher's coinjoin network?
 78 2017-06-04 18:23:49 <arubi> but as soon as the bip148 chain gains considerable hashrate, this is all retroactively not needed :)
 79 2017-06-04 18:23:53 <Iriez> Seems like that would be a good candidate
 80 2017-06-04 18:24:41 <arubi> or miners could create some 0 amout outputs for users to use (on demand) for replay protection on their first transaction on the chain
 81 2017-06-04 18:25:03 <Iriez> Right, I thought of that
 82 2017-06-04 18:25:11 <Iriez> I just hesitate using miners as service providers
 83 2017-06-04 18:25:21 <Iriez> really skews the dynamics of the system
 84 2017-06-04 18:25:28 <arubi> it can be very close to non interactive
 85 2017-06-04 18:25:52 <arubi> just have a pool of 0 amount outputs that you publish at demand, and listen for their use
 86 2017-06-04 18:26:00 <arubi> if it's used, remove it
 87 2017-06-04 18:26:09 <hcb_> Is this the right place to ask about Bitcoin Core operation?
 88 2017-06-04 18:26:17 <arubi> not like block space is an issue at first, more so if it's segwit inputs ;)
 89 2017-06-04 18:26:54 <arubi> hcb_, you can try, but if it's development related maybe #bitcoin-core-dev is better.  if it's just bitcoin core related, then #bitcoin
 90 2017-06-04 18:27:07 <hcb_> Ok, moving there. Thanks.
 91 2017-06-04 18:27:55 <Iriez> arubi, wouldn't it require the miners to give you the keys to the 0 output?
 92 2017-06-04 18:28:13 <Iriez> or are we trusting them to transfer funds from that address back to our address?
 93 2017-06-04 18:28:16 <arubi> just simple no checksig required scripts
 94 2017-06-04 18:28:43 <arubi> as long as it exists on the bip148 chain only, then you can include it in your transaction and it wouldn't be replayable
 95 2017-06-04 18:28:50 <arubi> like op_true is enough
 96 2017-06-04 18:29:05 <Iriez> so, its almost like a coinjoin?
 97 2017-06-04 18:29:11 <Iriez> sorry, im not following this one :P
 98 2017-06-04 18:29:54 <arubi> so say a miner has some movable coins on the bip148 chain
 99 2017-06-04 18:30:28 <arubi> they can spend these coins to themselves and also to some zero amount script that only says "op_true"
100 2017-06-04 18:30:56 <arubi> so you have some tx where output 0 pays back to the miner, and output 1 is just a zero amount redeemable by anyone
101 2017-06-04 18:31:35 <arubi> I want to transact on the bip148 chain, I ask the miner to tell me about some utxo that I can use in my transaction as an input, and it has to be on the bip148 chain only
102 2017-06-04 18:32:13 <Iriez> I think where im not understanding is how you can use/redeem a 0 balance utxo
103 2017-06-04 18:32:20 <arubi> so the miner tells me about a utxo, one of these op_true outputs, I use that as an input in my transaction and relay
104 2017-06-04 18:32:36 <arubi> you redeem it as you normally would, it just costs you fees
105 2017-06-04 18:32:55 <arubi> you can't really use "op_true" in a bare way like that
106 2017-06-04 18:32:59 <Iriez> but there's nothing to redeem? haha, this is just me clearly not understanding the underlying mechanisms well enough.
107 2017-06-04 18:33:08 <Iriez> I thought you couldn't spend from a 0 utxo
108 2017-06-04 18:33:35 <arubi> you could, and you can create one too,  but you can't create a valid 0 -> 0 tx :)
109 2017-06-04 18:33:55 <arubi> so really op_true is just simplification
110 2017-06-04 18:33:59 <Iriez> So it could only be used in conjunction with another input?
111 2017-06-04 18:34:12 <arubi> you need some p2sh with a random value to wrap that, or people would just abuse it
112 2017-06-04 18:34:16 <arubi> yes
113 2017-06-04 18:34:26 <Iriez> thats super interesting, I had no idea.
114 2017-06-04 18:35:25 <Iriez> so the miners could setup a page on their node that could generate a 0 utxo on the fly for you to use as one of your inputs
115 2017-06-04 18:35:36 <Iriez> realistically, wallet dev's could do this as well, couldn't they?
116 2017-06-04 18:35:45 <Iriez> once they have some coins that are split, couldn't they just generate them?
117 2017-06-04 18:35:47 <arubi> yea, anyone can offer this service
118 2017-06-04 18:35:56 <Iriez> So electrum would be a good candidate
119 2017-06-04 18:36:05 <Iriez> since they already provide outbound servers
120 2017-06-04 18:36:12 <arubi> if you sign your transaction just right (allow for others to include more inputs), then you can just ask someone else to do it for you
121 2017-06-04 18:36:41 <Iriez> so they could also have a raw tx input submission form or API and they could just relay it for you with the 0 utxo added
122 2017-06-04 18:37:06 <arubi> right, if you used some sighash that allows more inputs
123 2017-06-04 18:37:41 <Iriez> Do you know if anyone is actually working on these things? Seems essential for these services to exist
124 2017-06-04 18:38:02 <arubi> don't know, just now talking about it because you brought it up :)
125 2017-06-04 18:38:46 <Iriez> Cool. Well now my mental framework is much more solid on the subject. I can see the path but not the end of the road.
126 2017-06-04 18:40:20 <arubi> I really think that as long as the bip148 chain is impossible to reorg (soft fork nature), that it's zero risk to consider as a money transaction network
127 2017-06-04 18:40:32 <arubi> no matter the price even.  if it's cheap, just buy coins :)
128 2017-06-04 18:40:54 <Iriez> hum.
129 2017-06-04 18:58:05 <arubi> so now I think if it's possible to use cltv and csv at the same time to assert "this chain advanced quickly enough to redeem this input"
130 2017-06-04 19:00:14 <arubi> sort of "redeemable 600 minutes /and/ 8 blocks from now" or something :)
131 2017-06-04 19:02:29 <arubi> maybe just csv and locktime in block height
132 2017-06-04 19:03:05 <arubi> but.. maybe not :\
133 2017-06-04 19:03:44 <arubi> well yea, maybe so because time passes faster on the longer chain
134 2017-06-04 19:04:39 <arubi> good thing I have a month+ to try :)
135 2017-06-04 20:38:22 <Iriez> arubi: Super cool. I'll bug you now and then to see how progress is going =)
136 2017-06-04 20:38:32 <Iriez> Im very interested in understanding how this is evolving