1 2016-12-14 20:05:17 <stiell> If I understand BIP 114 (MAST) correctly, there are only two ways to provide data to a script: either as part of the witness data (where it is unsigned) for the individual input, or as a push operation in every single branch where it is used. I'm working on a contract that makes use of data that is updated very often and must be signed in some way. The only way I've found to do this is to make a tx
 2 2016-12-14 20:05:20 <stiell> (off-chain) for every update, which outputs to a newly generated MAST where each branch contains a push operation with the new data. Due to the number of branches, this may be expensive. Is there some other possible solution that I'm missing?
 3 2016-12-14 20:25:19 <arubi> stiell, I just read your question and still parsing.  just curious, what type of data?
 4 2016-12-14 20:26:55 <arubi> I mean, a number? (maybe sequence is good?),  a single push? (maybe op_return?)
 5 2016-12-14 20:30:05 <stiell> arubi: a hash, the root of a Merkle tree whose various leaf nodes are evaluated depending on the branch in the MAST.
 6 2016-12-14 20:31:30 <arubi> is it a different root than the one already in scriptpubkey?  I'm missing something
 7 2016-12-14 20:31:49 <stiell> arubi: I don't think a script is able to access the data in another script's op_return?
 8 2016-12-14 20:32:17 <stiell> arubi: yes, this is non-script data in a Merkle tree.
 9 2016-12-14 20:32:35 <arubi> if a checksig operation is done in that script, and the checksig is not "single" or "none", then it does sign that op_return output
10 2016-12-14 20:33:16 <stiell> by evaluated, I mean used as stack data in the script.
11 2016-12-14 20:33:32 <arubi> oh, as an input
12 2016-12-14 20:34:15 <arubi> hmm
13 2016-12-14 20:35:08 <arubi> so when is that data determined?
14 2016-12-14 20:35:57 <arubi> you say it's updated, were the possible "update states" determined before the input for this tx was signed?
15 2016-12-14 20:38:42 <stiell> The data is some state passed back and forth between two parties. Each party performs some partially secret computation on the data and passes along a tx that can later be used to validate that the secret computation was correct.
16 2016-12-14 20:39:17 <arubi> is it like lightning?  I still feel like I'm missing a big part of it
17 2016-12-14 20:41:22 <stiell> I suppose it creates something like a state channel. The point is to make sure each party's secret computations are according to certain rules, otherwise they lose their funds to the other party once the secret data is revealed.
18 2016-12-14 20:41:42 <arubi> oh so there's also penalty
19 2016-12-14 20:42:07 <arubi> I'd love to see that contract :)
20 2016-12-14 20:43:57 <arubi> put it this way, there's one way that I know to get data signed as part of an input, and it's by using sequence numbers and things like CSV
21 2016-12-14 20:44:27 <stiell> So when one party wants to terminate the protocol, they reveal their secret key and force the other party to reveal theirs via the contract. With that key they can examine every computation made by the other player. If something was against the rules, they can publish the off-chain tx that followed the update, along with proof that a rule was broken, to redeem the funds.
22 2016-12-14 20:45:51 <arubi> how does one party force the other to reveal their key?
23 2016-12-14 20:49:00 <arubi> grr, sorry stiell, ride is here.  very cool stuff..  will probably be back tomorrow
24 2016-12-14 20:50:16 <stiell> The proof-of-cheat MAST contains a subscript that pushes the other party's secret key to the stack. Only the hash of this subscript is public at first, and is enough to build the MAST. To force the other party to reveal their key, they publish a pre-signed tx which requires the other party to provide the data matching this hash, otherwise it times out and they lose the funds.