Good morning Chris,
>
> Looking at these equations, I realize that the incentives against
> post-coinswap-theft-attempt still work even if we set K = 0, because the
> extra miner fee paid by Bob could be enough disincentive.
This made me pause for a moment, but on reflection, is correct.
The imp
Hello list,
This email is an appendium or modification of the earlier CoinSwap
protocol published on this list. It is intended to fix the problems
found in review. (Original email quoted here too)
On 11/08/2020 13:05, Chris Belcher via bitcoin-dev wrote:
> I'm currently working on implementing C
subscribe pls https://www.youtube.com/channel/UCcRPSO-n2HgolBFKzW3re4Q
On Saturday, September 5, 2020, Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Chris,
>
> I forgot to underscore that contract transaction output must be grieved by
> at least a CSV of 1. Ot
Hi Zeeman,
I think one of the general problems for any participant in an
interdependent chain of contracts like Lightning or CoinSwap is to avoid a
disequilibrium in its local HTLC ledger. Concretely sending forward more
than you receive backward. W.r.t, timelocks delta aim to enforce order of
eve
Hi Chris,
I forgot to underscore that contract transaction output must be grieved by
at least a CSV of 1. Otherwise, a malicious counterparty can occupy with
garbage both the timelock-or-preimage output and its own anchor output thus
blocking you to use the bumping capability of your own anchor ou
Good morning Chris, and probably also Lightningers,
> However, it might be possible to prevent the maker from learning the
> collateral input at all.
>
> If my understanding of BIP-143 is correct, inputs are hashed separately
> (`hashPrevouts`) from outputs (`hashOutputs`).
> Bob can provide the
Good morning Antoine,
> > This can be arranged by having one side offer partial signatures for the
> > transaction of the other, and once completing the signature, not sharing it
> > with the other until we are ready to actually broadcast the transaction of
> > our own volition.
> > There is n
Good morning Chris,
> > This seems a great solution!
> > Since B is the one offering HTLCs, the taker of a CoinSwap sequence can be
> > B as well.
> > This means, the taker has to have some collateral input, of at least value
> > K, that it cannot swap (because if it tried to swap that amount,
Hello ZmnSCPxj,
On 03/09/2020 10:45, ZmnSCPxj wrote:
> Good morning Chris,
>
>> A big downside is that it really ruins the property of allowing coins to
>> remain unspent indefinitely. That has privacy implications: if a coin
>> remains unspent for longer than 2 weeks (or another short locktime)
Good morning Chris,
> A big downside is that it really ruins the property of allowing coins to
> remain unspent indefinitely. That has privacy implications: if a coin
> remains unspent for longer than 2 weeks (or another short locktime) then
> for sure the transaction was not a CoinSwap, and so th
Hello ZmnSCPxj,
On 25/08/2020 04:16, ZmnSCPxj wrote:
>
> Good morning Antoine,
>
>
>> Note, I think this is independent of picking up either relative or absolute
>> timelocks as what matters is the block delta between two links.
>
> I believe it is quite dependent on relative locktimes.
> Re
Good morning Chris,
> It seems having just one contract transaction which includes anchor
> outputs in the style already used by Lightning is one way to fix both
> these vulnerabilities.
>
> For the first attack, the other side cannot burn the entire balance
> because they only have access to the
Hello Antoine,
Thanks for the very useful insights.
It seems having just one contract transaction which includes anchor
outputs in the style already used by Lightning is one way to fix both
these vulnerabilities.
For the first attack, the other side cannot burn the entire balance
because they on
Good morning Antoine,
> Note, I think this is independent of picking up either relative or absolute
> timelocks as what matters is the block delta between two links.
I believe it is quite dependent on relative locktimes.
Relative locktimes *require* a contract transaction to kick off the rela
Hello Chris,
I think you might have vulnerability issues with the current design.
With regards to the fee model for contract transactions, AFAICT timely
confirmation is a fund safety matter for an intermediate hop. Between the
offchain preimage reveal phase and the offchain private key handover p
Good morning Chris,
> > Absolute timelocks mean that you can set a timer where you put your node to
> > sleep without risk of loss of funds (basically, once the absolute timelocks
> > have resolved, you can forget about CoinSwaps).
> > But I think the ability to spend at any time would be bette
Hello,
On 21/08/2020 05:20, ZmnSCPxj wrote:
> Good morning,
>
>
>
>> Right, so if the taker uses only a single maker then they must have more
>> than one UTXO.
>
> Spending one UTXO is fine, it is generating a transaction that has one output
> that is problematic.
>
> What needs to happen is
Good morning,
> Right, so if the taker uses only a single maker then they must have more
> than one UTXO.
Spending one UTXO is fine, it is generating a transaction that has one output
that is problematic.
What needs to happen is that this single UTXO is spent to two outputs: the
CoinSwap 2-o
Hello Nadav and ZmnSCPxj,
On 20/08/2020 22:38, ZmnSCPxj wrote:
> Good morning Nadav,
>
>> Hey Chris and all,
>>
>> Looking good :) I have one major concern though
>>
>>> q = EC privkey generated by maker
>>> Q = q.G = EC pubkey published by maker
>>>
>>> p = nonce generated by taker
>
Hello ZmnSCPxj,
Thanks for the review. My comments are inline.
On 20/08/2020 12:17, ZmnSCPxj wrote:
> Good morning Chris,
>
> Great to see this!
>
> Mostly minor comments.
>
>
>
>>
>> == Direct connections to Alice ===
>>
>> Only Alice, the taker, knows the entire route, Bob and Charlie just
Good morning Nadav,
> Hey Chris and all,
>
> Looking good :) I have one major concern though
>
> > q = EC privkey generated by maker
> > Q = q.G = EC pubkey published by maker
> >
> > p = nonce generated by taker
> > P = p.G = nonce point calculated by taker
> >
> > R = Q + P = pubk
Hey Chris and all,
Looking good :) I have one major concern though
>q = EC privkey generated by maker
>Q = q.G = EC pubkey published by maker
>
>p = nonce generated by taker
>P = p.G = nonce point calculated by taker
>
>R = Q + P = pubkey used in bitcoin transaction
> = (
Good morning Chris,
Great to see this!
Mostly minor comments.
>
> == Direct connections to Alice ===
>
> Only Alice, the taker, knows the entire route, Bob and Charlie just know
> their previous and next transactions. Bob and Charlie do not have direct
> connections with each other, only with
I'm currently working on implementing CoinSwap (see my other email
"Design for a CoinSwap implementation for massively improving Bitcoin
privacy and fungibility").
CoinSwaps are special because they look just like regular bitcoin
transactions, so they improve the privacy even for people who do not
24 matches
Mail list logo
