Re: [bitcoin-dev] OP_LOOKUP_OUTPUT proposal

[Runchao Han via bitcoin-dev]

Good morning ZmnSCPxj,

Sorry for the ambiguity of my last email. It was Sunday and I wrote it in 1 min 
on my bed. Let me elaborate what we are thinking of here.



## Analysis on the protocol from Fournier et al.

In this protocol, Bob participates in the swap following the steps below:

1. Alice and Bob creates a payment channel on WJT blockchain.
2. Bob creates the WJT transaction using the joint account of Alice and Bob, 
including 1) Bob's input of 1,000,000 WJT, 2) Alice’s input for the 10,000 WJT 
premium. This transaction should be signed by both Alice and Bob in order to be 
valid.
3. Bob signs the WJT transaction and sends the WJT transaction to Alice.
4. Alice signs this WJT transaction. At this stage, Alice has both the valid 
BTC transaction and the valid WJT transaction.
5. Alice broadcasts both the BTC transaction and the WJT transaction.

In a word, Bob is responsible for preparing the WJT transaction, while Alice is 
responsible for preparing the BTC transaction and broadcasting both 
transactions.

Here, if Bob stalls, nothing will happen, because Bob cannot spend the 10,000 
WJT premium without Alice’s signature.
If Alice stalls, you are saying that Bob can spend the input of 1,000,000 WJT 
so he does not lose any money.

I have 3 questions on this scheme.

First, I’m not sure how do you define “Alice stalls”. In this case, Alice can 
stall by 1) withhold the WJT tx, or 2) broadcast BTC/WJT funding txs but 
withhold the preimage.
If 2), this protocol is okay. But what about 1) i.e. Alice withholds the WJT 
tx? Here, Bob cannot do anything except for closing the payment channel and 
quit.

Second, I’m not sure whether Bob can spend his money in this payment channel 
while the payment channel is still valid.
In Bitcoin, Bob needs to close the payment channel and get back his money 
first, then he can spend the money.

Third, let’s optimistically assume Bob can close this payment channel without 
Alice’s consent.
Now he decides to close this channel if Alice does not broadcast the WJT tx all 
the time.
Alice does not need to pay for the premium if she withholds the WJT tx. If 
Alice decides not to proceed this swap, Bob should close this channel and get 
back 1,000,000 WJT. However, Bob cannot get the 10,000 WJT premium.

In conclusion, Alice’s optionality is not free when she exercises this option, 
but is free when she aborts this option.



## What will happen if Alice is responsible for broadcasting both funding txs

If Alice is responsible for broadcasting both txs, Alice can always abort the 
swap for free, regardless of how the protocol is designed.
Basically, Bob officially participates in the swap by signing the WJT tx.
After Bob participating, if Alice hopes to abort the swap, she can just 
withhold the WJT tx.

In the original Atomic Swap, Bob participates in the swap by signing and 
broadcasting the WJT tx, and Alice cannot withhold Bob’s participation.
However, if Alice is responsible for broadcasting Bob’s WJT tx, Alice can 
withhold Bob’s participation by withholding the WJT tx.

Therefore, I think for Atomic Swap protocol design, Bob should be responsible 
for broadcasting the WJT tx, otherwise the protocol is impossible to be fair to 
Bob.



Again, sorry for the ambiguity introduced in our last email, and we look 
forward to hearing from you.

Thanks,
Runchao


> On 10 Aug 2019, at 11:01 pm, Runchao Han  wrote:
> 
> If I remember it right, Alice first signs the WJT transaction, sends it to 
> Bob, then Bob signs it and makes this transaction valid.
> 
> If so, there are two problems.
> First, Bob gets the valid tx first, and he can choose not to send it to Alice.
> Second, even if Bob honestly sends Alice this tx, Alice cannot fully control 
> when to broadcast this to, as Bob also has this transaction.
> 
> If Bob first signs then Alice signs, Alice still has optionality, as she can 
> choose whether to publish this tx and preimage.
> 
> Runchao
> 
> On Sat, Aug 10, 2019 at 10:50 PM ZmnSCPxj  > wrote:
> Good morning Runchao,
> 
> 
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐ Original Message ‐‐‐
> On Saturday, August 10, 2019 1:44 PM, Runchao Han  > wrote:
> 
> > Hi ZmnSCPxj,
> >
> > Thanks for your reply.
> >
> > I agree with your opinions about OP_LOOKUP_OUTPUT.
> > Indeed, the pruning mechanism renders this opcode unrealistic for some 
> > nodes. Also, the execution of OP_LOOKUP_OUTPUT depends on the time of 
> > verifying this tx.
> >
> > However, I’m concerning of some security issues of your mentioned protocol 
> > (Alice pays the premium contingently on Bob participating).
> > If I understand it right, Alice and Bob should create a payment channel, 
> > and mutually construct the funding transaction that “Alice pays Bob 10,000 
> > WJT; Bob hash-timelocked pays Alice 1,000,000WJT”, where the time lock is 
> > T+24.
> > Here, Bob is responsible for broadcasting this tx after confirming 

Re: [bitcoin-dev] 32-byte public keys in Schnorr and Taproot

[Karl-Johan Alm via bitcoin-dev]

Hello,

It makes no sense to me to not switch to 32-byte keys. There are
literally no (or very mild) disadvantages to this, from what it
appears like. I don't think refraining from updating a proposal just
because it's been out there for awhile is a valid reason, personally.

On Sat, Aug 10, 2019 at 3:17 AM Pieter Wuille via bitcoin-dev
 wrote:
>
> Hello all,
>
> It has been suggested [1] to drop the Y oddness bit in the witness
> program for Taproot outputs. This seems like a worthwhile change, as:
> * The bit doesn't actually contribute to security.
> * It avoids Taproot outputs from being more expensive to create than v0 P2WSH.
> * It doesn't preclude future changes that would still need the
> additional byte anyway.
>
> In exploring that option, Jonas Nick found that it seems cleanest [2]
> to actually introduce a type of 32-byte public keys (which implicitly
> have an even Y coordinate) in bip-schnorr, with associated signing and
> verification logic that are distinct from the 33-byte variant.
>
> This makes me wonder if we need 33-byte public keys at all.
>
> So I'd like to hear opinions about modifying bip-schnorr to only
> define 32-byte public keys. The implications of that would be:
> * bip-schnorr public keys wouldn't be exactly the same as ECDSA public
> keys, however all derivation logic would still apply (BIP32,
> mnemonics, xpubs, ... would still exist and be compatible - just the
> first pubkey byte would be dropped at the end).
> * The Q point in bip-taproot (the one going in the scriptPubKey) would
> just follow the 32-byte pubkey encoding, rather than needing a 33rd
> byte.
> * The P point in bip-taproot (the internal key revealed during script
> path) would become just a 32-byte public key (and we can drop the one
> bit in the control block to transmit the oddness of the Y coordinate
> of P).
> * In order to permit batch verification of the P to Q tweaking for
> script-path spending, another control block bit is now needed, namely
> one that indicates whether a negation was needed to make P+H(P||m)*G's
> Y coordinate even.
> * All public keys inside bip-tapscript would also become 32-bytes. If
> desired, the "upgradable public key" construction in bip-tapscript can
> be kept, by triggering based on the length of public keys (rather than
> based on their first byte).
>
> One question is whether it's worth such a change to bip-schnorr at
> this point. We've purposefully never progressed it past draft since
> publishing [3], but it has been a while. If necessary, it's possible
> to keep verification compatible by still hashing the implied "even"
> byte inside the scheme (which commits to the pubkey), but if we're
> going to change things, it's perhaps best to do it as cleanly as
> possible and also drop that byte.
>
> Opinions?
>
>   [1] 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016943.html
>   [2] https://github.com/sipa/bips/pull/52
>   [3] 
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html
>
> Cheers,
>
> --
> Pieter
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev