Hi Dmitry,
>While refund_tx_1 is in the mempool, Bob gives success_tx to the friendly
miner
I see, so you're talking about prior to protocol completion, right after
Alice sends Bob the success_tx. The reason this is not an issue is because
Alice and Bob both had to misbehave in order for this to
В Wed, 13 May 2020 21:03:17 +0200
Ruben Somsen wrote:
> Or perhaps you're referring to the issue ZmnSCPxj pointed out after
> that, where refund transaction #1 and the success transaction could
> both become valid at the same time. It would make sense for the test
> to pick up on that, but I
Good morning Antoine,
> While approaching this question, I think you should consider economic weight
> of nodes in evaluating miner consensus-hijack success. Even if you expect a
> disproportionate ratio of full-nodes-vs-SPV, they may not have the same
> economic weight at all, therefore
Hi Chris,
While approaching this question, I think you should consider economic
weight of nodes in evaluating miner consensus-hijack success. Even if you
expect a disproportionate ratio of full-nodes-vs-SPV, they may not have the
same economic weight at all, therefore even if miners are able to
Hi Dmitry,
Thanks for creating a specification for testing, I appreciate the interest!
>The checking of the model encoded in the specification can successfully
detect the violation of 'no mutual secret knowledge' invariant when one of
the participant can bypass mempool and give the transaction
The Succint Atomic Swap contract presented by Ruben Somsen recently has
drawn much interest.
I personally am interested in the smart contracts realizeable in the
UTXO model, and also interested in applying formal methods to the
design and implementation of such contracts.
I think that having
Hi ZmnSCPxj,
>on completion of the protocol, if Bob lets the refund tx#1 become valid
(i.e. does not spend the BTC txo) then Alice can broadcast it, putting both
their funds into chaos
You forget, refund tx #1 has a script (which btw won't be visible with
taproot): "Alice & Bob OR Alice in +1
Good morning Ruben,
> Hi ZmnSCPxj,
>
> >potentially both Alice and Bob know all the secrets on the LTC side and end
> >up competing over it
>
> That's exactly right.
>
> >Bob can thus give a copy of the revoke tx with signature directly to its
> >favorite miner, forcing Alice to take 3
Hi ZmnSCPxj,
>potentially both Alice and Bob know all the secrets on the LTC side and
end up competing over it
That's exactly right.
>Bob can thus give a copy of the revoke tx with signature directly to its
favorite miner, forcing Alice to take 3 transactions
Note that the timelock on the
Hi Chris,
Thanks for taking a look :)
>it also improves privacy because the coins could stay unspend for a long
time, potentially indefinitely
Excellent point. The pre-swap setup transactions would still be subject to
timing/amount analysis, but it's clearly a lot less problematic than the
Good morning Ruben,
> >If the shortened refund transaction exists (labeled "refund transaction #1"
> >in the SVG) then the same issue still occurs
>
> Yes, but there is one crucial difference: at that point in the protocol (Bob
> has the success transaction and then stops cooperating) Alice
11 matches
Mail list logo
