00:12 <grubles> how early were interactive atomic swaps described?

00:14 <gmaxwell> grubles: prior to nov 2011. e.g. the ZKCP page is just describing one, https://en.bitcoin.it/w/index.php?title=Zero_Knowledge_Contingent_Payment&oldid=20089 but I believe the construct without the extra steps was probably described even before then.

00:15 <grubles> ok excellent

00:16 <grubles> yes i'm looking for email list posts etc from around that time period

00:18 <gmaxwell> also https://bitcointalk.org/index.php?topic=91843.msg1011956#msg1011956 (and now I curse my past self for not being more rigorous in citing)

00:20 <grubles> ah no worries. thanks!

00:22 <gmaxwell> Sep 2011, https://en.bitcoin.it/w/index.php?title=Contract&oldid=16111#Example_5:_Trading_across_chains he later edited it to credit tier nolan, but I dunno where tier's post is because he wiki currently links a later 2013 explination.

00:23 <grubles> yeah just saw that

00:24 <gmaxwell> most of the stuff mike posted on that page came from posts or emails with Satoshi.

00:32 <grubles> @gmaxwell, do you know of any instances where an atomic swap order book was described during that time period (early 2010s)

00:34 <gmaxwell> Almost certantly on IRC. you might want to ask maaku, who might have a better memory for that sort of thing.

00:37 <gmaxwell> From my perspective, it was well known and obvious that you could do these things from at least mid 2011 on... the primary hurdles to doing them were (1) no one really wanted to, centeralized systems work fine; (2) building multiparty protocols is @#$@ complex; (3) prior to CLTV the only way to prevent holdup was to use refund transactions, which were insecure due to malleability.

00:38 <gmaxwell> Satoshi mentions secure swaps here, https://bitcointalk.org/index.php?topic=1790.msg28917#msg28917 but doesn't describe them in detail.

00:43 <grubles> oo ok that will surely be helpful

00:52 <grubles> just to clarify, "mike" on the bitcoin wiki is hearn?

08:47 <da2ce7> Hello. I want to have a hash-puzzle something like: OP_SIZE <32> OP_EQUAL OP_VERIFY OP<HASH> <32 byte puzzle> OP_EQUAL . Where I want to constrain any valid solution to being exactly 32 bytes long.

08:47 <da2ce7> Is this the right approach to doing it?

08:48 <da2ce7> My concern is that I don't want any attacks where the spending script is very large.

08:52 <da2ce7> *OP_HASH256

08:52 <da2ce7> OP_SIZE <32> OP_EQUAL OP_VERIFY OP_HASH256 <32 byte puzzle> OP_EQUAL

10:28 <da2ce7> The second question is how do I do this? I need to be able validate an output matches the template: "OP_SIZE <32> OP_EQUAL OP_VERIFY OP<HASH> <32 byte puzzle> OP_EQUAL" (or whatever it should best be) by looking at the blockchain deterministically. (no out-of-chain validation data). - Is there any way to do this without breaking IS_STANDARD?

10:29 <da2ce7> As a P2SH script, this would not work as only in spending the P2SH output is the script shown in the blockchain.

10:30 <da2ce7> I'm not sure if it is possible to do this witnesses.

10:30 <da2ce7> Otherwise I think that I must settle for a non-standard transaction.

10:32 <da2ce7> The core reason why I don't want to use a P2SH as the Puzzle Function is that the redeeming Solution is unconstrained in length (well to the point of the blocksize limit).

10:34 <waxwing> grubles, i'm curious why you specified 'interactive' atomic swap? am i forgetting something, but what kind of atomic swap doesn't involve interaction?

10:34 <waxwing> the question's interesting to me because i've spent some time trying to come up with (even crazy) schemes which really minimize the interaction, but also don't expose the swap somehow on-chain (i.e. don't lose privacy)

10:35 <waxwing> a bare-bones atomic swap with hash preimages in the script minimizes interactivity (in particular no 'cross-block' interactivity) but gives no privacy boost

10:47 <Jmabsd> Can I add witness data to a transaction input that is not necessarily segwit and where the witness data i'd add is unrelated to the output the input spends? (repeat from #bitcoin however disconnected.)

11:19 <waxwing> Jmabsd, answered in #bitcoin

13:46 <ruby32> Hi all, wondering about the proposed change to Bitcoin Cash with OP_CHECKDATASIG. https://github.com/bitcoincashorg/bitcoincash.org/pull/93/files

13:47 <ruby32> Just to make sure I'm understanding this correctly: this is a minor improvement over using a symmetric key with OP_HASH<n> and OP_EQUAL, correct?

13:47 <ruby32> My understanding is: anything that OP_CHECKDATASIG can do could with asymmetric keys could also be done with hashing a symmetric key

15:42 <grubles> waxwing, oh no reason other than to just be specific i guess