Alejandro Ranchal Pedrosa [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-03-29 to 2019-04-21
💬 Posted a total of 15 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:54:53

- reply

📅 Original date posted:2019-04-16
📝 Original message:
Apologies, just realised there is an important typo:
"Suppose that Dave is offline/unresponsive, meaning that they cannot
update the channel factory"
Best,
--
Alejandro Ranchal Pedrosa

2023-06-09 12:54:52

- reply

📅 Original date posted:2019-04-16
📝 Original message:
Hi ZmnScpXj,
that's correct, Lightning Factories require support for "transaction
fragments" to be added dynamically, which are only possible when using
non-interactive aggregation signature schemes.
The proposal of having a factory operator is in fact quite interesting, and
it is true it would give some scalability while the community discusses
other more long-lasting options. Is there a more in-depth proposal of the
protocol you suggest, or any of the like?
Best,
Alejandro.
Alejandro Ranchal Pedrosa
On 16 Apr 2019 at 17:39, <ZmnSCPxj <zmnscpxj at protonmail.com>> wrote:
Good morning Alejandro,
Your analyses seem to be quite spot on.
It does seem that factories need some work to be done further.
As I understand it, the proposal in "Scalable Lightning Factories for
Bitcoin" require a new signature scheme at the blockchain layer, is
that correct?
I observe that current Lightning uses single-funded channels.
This was to initially simplify the protocol.
Although dual-funded channels are being proposed, various issues came up.
Perhaps some simplification of factories is possible.
* Suppose we initially insist that factories be single-funded.
In this mechanism, a node may open multiple channels to multiple
other nodes using a single onchain UTXO.
* The funder of the factory is the factory operator.
* If the other nodes on the factory wish to create some change at the
factory level, they contact the factory operator only.
If the factory operator allows it, only will the factory-level
operation be allowed.
* The only factory-level operation allowed is a cooperative close.
Each channel in the factory must be in a quiescent state (no HTLCs)
and the factory operator requests signatures from all nodes.
What happens is that the factory operator requests and distributes
signatures for each individual channel closure first, before
corodinating to request and distribute signatures for the factory
close.
The operation completes on publication of the factory close.
* The factory close is the cut-through of the allocation transaction
and the individual channel close transaction, with the mining fee for
the factory close transaction equal to the total mining fees on the
allocation transaction and individual channel close transactions.
It may have fewer total outputs as the channel outputs of the
factory operator can be merged into a single output.
If both allocation and factory close are marked as RBF, then the
factory close will dominate over the allocation transaction in
feerate.
Miners would strongly prefer the factory close, and even if the
allocation transaction gets through, it does not degrade security (but
unnecessarily spends block space, meaning rational miners would not
prefer it especially since the factory close gives the same fee and is
smaller).
* This construction requires a simple n-of-n at the factory level, as
there is no update.
This is still a "factory", of a sort, but with only one known-safe operation.
The intent is simply to provide some of the scaling boost for now,
until we can determine how best to implement factory-level changes.
Regards,
ZmnSCPxj
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, April 16, 2019 7:59 AM, Alejandro Ranchal Pedrosa
<a.ranchalpedrosa at gmail.com> wrote:
> Hi all,
>
> This is the first of three related different emails on the topic,
> through which I will explain what, to my understanding, is the state of
> the construction of channel factories.
>
> First let's have a look at a situation known as a stale factory, or
> channel [1], as defined by Ranchal-Pedrosa et al.. For simplicity, let's
> consider a channel first. Suppose a DMC channel Alice between Alice and
> Bob. This channel must be updated through so-called refunding
> transactions R^k_{AB}, where k refers to the state (so initial state
> R^0_{AB}, after one payment R^1_{AB}, etc.) and {AB} refers to both A
> and B having already signed the transaction (if a dot appears instead of
> A or B, it means there's a signature missing.
> The stale channel derives from the fact that either Alice or Bob needs
> to sign before their counterparty. Suppose a situation like this:
> Alice Bob
> | |
> |<--R^1{.B}<--|
>
> |-->R^1_{AB}-->|
>
> ... ...
>
> |<--R^k_{.B}<--|
>
> | |
>
> In this situation, Bob does not have a fully signed transaction for the
> last state k, whereas Alice may have it (from the point of view of Bob).
> That is, even if the message was lost, all Bob knows in the trustless
> model is that he signed for something that he did not get a fully signed
> transaction back for. So he should believe Alice has the fully signed
> transaction and may enforce it if necessary. At the same time though,
> Bob can enforce transaction R^{k-1}{AB}, which he must have, and
> therefore finish with the ambiguity by publishing on-chain such state,
> should he not be able to communicate with Alice and perform updates anymore.
> The stale factory is the same situation, but affecting a new allocation
> transaction, as defined by Decker et al.[2], rather than a new refunding
> transaction. There are two major differences between a stale factory and
> a stale channel:
> - In a stale factory, only one user (out of n) can already cause
> this situation. That is, even if the remaining n-1 users are active and
> online, with one of them not replying back, is enough for Alice to
> believe that there's a possibility that one of its counterparties might
> have the fully signed new allocation transaction.
> - The new allocation transaction may or may not affect a particular
> channel in the factory, but if it does then users do not even know in
> which channel they have their funds.
> Ways to go around these are:
> - Try to create a new refunding (or allocation) transaction
> R^{k+1}{AB}. If it fails though, now there are three possibletransactions. Besides, if the channel/factory follows the DMC
> construction, the timer reduces yet again.
>
> - Close the channel/factory by publishing it on the Blockchain.
>
> Open for discussion about this situation and its implications. In an
> upcoming email I will explain what, to my understanding, is the biggest
> problem associated with this situation.
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Alejandro Ranchal-Pedrosa
>
> [1]: Scalable Lightning Factories for Bitcoin
>
> [2]: Scalable Funding of Bitcoin MicropaymentChannel Networks
>
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190416/324ed866/attachment.html>

2023-06-09 12:54:51

- reply

📅 Original date posted:2019-04-20
📝 Original message:
Hi ZmnSCPxj,
I also thought about the possibility of using 'SIGHASH_NOINPUT', it
certainly offers a functionality very similar to the one I suggest in
the paper.
The problem with 'SIGHASH_NOINPUT' as it is now is that, if I am not
mistaken, in the example you are showing, seems like A,D and C can
unilaterally decide to include a new participant, F. Seems to me like
this can affect the no-lock property of offchain layers, since they
might require F to release the funds in the mainchain.
Certainly, with some variants to SIGHASH_NOINPUT this solution can be
achieved. Actually, this is in some way what I propose in the Lightning
Factories paper. Adding a non-interactive aggregate signature scheme is
just going one step further with an optimization to save space, the same
way Schnorr-based signatures schemes for aggregation are proposed in
Channel Factories. But with minor variants (that are listed in the
paper), a SIGHASH_NOINPUT would work like a charm.
Best,
Alejandro.
On 17/04/2019 13:39, ZmnSCPxj wrote:
> Good morning Alejandro and list,
>
> Let me characterize the problem in detail.
>
> * Stale offchain system is the issue where one participant of a multiparticipant offchain system sends a signature that advances the protocol, but is unable to receive further signatures from one or more of the other participants to continue the protocol.
> * Often, such a stall in the protocol requires some timeout and a backoff path, aborting the protocol and performing some corrective action onchain.
> * More participants means more chances of this kind of stale offchain system disruption.
>
> * For two-participant offchain systems ("payment channels"), this disruption is indistinguishable from the other participant going offline.
> * For payment channels, the other participant going offline implies that future updates of the channel will not occur, thus it is always possible for participants to insist on redoing the signature exchange before performing further updates.
> * Thus, for payment channels, this issue can be fixed by allowing the exchange of signatures (including those you believe to have sent previously) of the most recent state upon re-establishing a communication channel.
> * BOLT already requires this.
>
> * For multiparticipant offchain systems that host other offchain systems ("channel factories"), this disruption is also indistinguishable from one of the participants going offline.
> * For channel factories, the remaining participants might wish to continue participating in hosted offchain systems ("on-factory channels") that do not involve the dropped participant.
> * However, it is unknown if the dropped participant is able to construct the new state or not.
> * Thus it is ambiguous if on-factory channels should be rooted from the old state or the new state.
>
> --
>
> A thought comes to mind: would `SIGHASH_NOINPUT` help?
> On-factory channels not affected by a channel reorganization operation at the factory level can continue to operate, by use of `SIGHASH_NOINPUT`.
>
> For instance, suppose the current factory state is the channels: (A, B) 1; (B, C) 1; (A, D) 1; (C, D) 1
> Suppose A, C, and D propose a reorganization to the new state: (A, B) 1; (B, C) 1; (A, C) 0.5; (C, D) 1.5
>
> If channel states use `SIGHASH_NOINPUT` in signatures, then (A, B) and (B, C) channels can be trivially re-rooted in both the old or the new factory state,
> At the same time, (A, D) 1 and (C, D) 1 are both closed until the new state is completely signed, so their continued operation is stopped.
> And the channels (A, C) 0.5 and (C, D) 1.5 are not yet opened until the new state is completely signed, so their operation cannot be begun.
>
> This allows unaffected channels to continue operation even if a factory-level operation is in an indterminate state.
>
> Regards,
> ZmnSCPxj
--
Alejandro Ranchal Pedrosa

2023-06-09 12:51:53

- reply

📅 Original date posted:2018-10-24
📝 Original message:
Hi Margherita,
can you be a bit more specific about what you mean by double-spend
attacks?. A double-spend is not an attack that can be performed acting
solely on the Lightning Network, and as far as I know there are no nodes
being banned because of this.
If there are nodes that are being banned for tampering or sending wrong
information on the p2p Lightning Network (such as changing
channel_announcements or creating others that are wrong) is something I
am not completely sure (maybe in some implementations? or is it
specified in BOLT). In any case, this is not a double-spending attack.
Best,
Alejandro.
On 24/10/2018 00:18, Margherita Favaretto wrote:
> Dear Lighning-dev group,
> I am Margherita Favaretto, a Master student of Cyber Security at the
> Technical University of Denamark (DTU). I'm currently in San Francisco
> for one month, to advance with my academic research on Lightning
> Network by taking part to the networking events that are happening here.
> My research is focused on a remediation protocol for Lightning Network
> double-spend attacks. More in detail, my research wantsto mitigate the
> problem of false positives (e.g. software errors). Today, attacking
> nodes get excluded from the network, without any distinction between a
> software bug or an "Eve" malicious node.
> The solution, that I'm calling a "trusted remediation" gossip
> protocol, wants to solve: the identification of a false positive; the
> communication to other nodes; and the remediation payments mechanism.
> I would really appreciate an open feedback about the relevance of this
> issue, and which is the best way to be in contact with you.
> Your help would help me to focus my research on the right issues, and
> open a discussion about my assumptions and the related work that could
> help me. The goal is to give my contribution to this project and be
> actively part of the group as an independent researcher.
> Any thoughts/suggestions are really appreciated. I'm available for
> possible collaborations outside of this scope with people interested
> on this research topic.
> Thank you in advance,
> Margherita Favaretto
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181024/1dc3765b/attachment.html>

2023-06-09 12:49:59

- reply

📅 Original date posted:2018-04-11
📝 Original message:
Hi ZmnSCPxj,
> No, channel balance of each peer on the channel is not revealed on
> node gossip.
>
> Logically, invert the question: do you want to report how much you
> spend/receive on each of your channels to the network? Do you want to
> report how much you own on Lightning to be reported to everyone on
> Lightning?
>
> Since the balance on each peer is effectively the amount of money each
> peer owns on that channel, and each change to that balance represents
> a send/receive on that channel, you will not want to report your
> balance, and any changes in that balance, to the entire network.
>
> Logically you can then expect not to receive such updates from anybody
> else, either.
>
> How do real-life implementations like c-lightning get your payment
> routes then? By brute-force trial-and-error
If payment routes are discovered by brute-force trial-and-error, and
actually the sender can interrupt any payment by simply not revealing
the secret, isn't it possible for any sender to simply start probing to
discover the capacities in each path?
Best,
Alejandro.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180411/3c086b31/attachment.html>

2023-06-09 12:49:45

- reply

📅 Original date posted:2018-04-11
📝 Original message:
Hi Christian,
> That's not as bad a tradeoff as people usually interpret, the DMC
> construction has parameters that allow tweaking the number of
> invalidations, and with parameters similar to LN we can have 1.4 billion
> updates. Which is years of operation without need to
> re-anchor. In addition penaltyless invalidation has a number of
> advantages,
As far as I understand, long-lasting DMCs require either:
    (a) an initial Refund transaction with a very distant relative
locktime
    (b) periodic updates in the form of a Refund transaction pointing
to a new Refund transaction resetting initial the locktime, instead of
actually refunding.
    For an extreme case of (a), if one party goes unresponsive and
decides not to sign new commitments then the counterparty in the DMC
will have its funds locked for a significant amount of time, without
penalising the unresponsive party. In the extreme case of (b), either if
as a result of a malicious, unresponsive, or honest participant, each
new refund transaction that resets the refunds may end up hitting the
blockchain, which means the worst-case utility of the channel itself
decreasing due to accumulative blockchain fees. Is this the trade-off
you speak of? if so, can you point at any resource where this trade-off
is tackled to get worst-case utility similar to that of LN channels?
Best,
Alejandro.

2023-06-09 12:49:41

- reply

📅 Original date posted:2018-03-29
📝 Original message:
Hello all,
Christian Decker pointed the following out
(source:https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000991.html):
>I'd also like to point out that the way we do state invalidations in
>Lightning is not really suited for multi-party negotiations beyond 2
>parties. The number of potential reactions to a party cheating grows
>exponentially in the number of parties in the contract, which is the
>reason the Channel Factories paper relies on the Duplex Micropayment
>Channel construction instead of the retaliation construction in LN.
Can somebody ellaborate on this assumption?
Best,
Alejandro.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180329/3b672012/attachment.html>

2023-06-07 18:16:11

- reply

📅 Original date posted:2019-02-09
📝 Original message:Hi all,
>
> Side note: I was not able to come up with an similar, eltoo-like
> protocol that works
> if you can't predict in advance who will become absent.
>
An eltoo-like protocol that works (without going on-chain) if you can't
predict in advance who will become absent would be a childchain. If the
off-chain protocol can continue updating in the abscence of other
parties, it means that other parties' signatures must not be required
when they are not involved in the off-chain state update. If other
parties' signatures must not be required, there must be a way of having
a common verifiable 'last state' to prevent a party to simultaneously
'fork' the state with two different parties, and double-spend. A
solution for this is a childchain for Bitcoin. An example of this is
what is known as a 'Broken Factory' attack [1]
(https://bitcoin.stackexchange.com/questions/77434/how-does-channel-factory-act/81005#81005)
> If the expectation is that the unresponsive party returns, fungibility is
> not reduced due to output tagging because the above scheme can be used
> off-chain until the original channel can be continued.
I believe that in many cases other parties won't be able to continue
until the unresponsive parties go back online. That might be true in
particular scenarios, but generally speaking, the party might have gone
unresponsive during a factory-level update (i.e. off-chain closing and
opening of channels), while some parties might have given out their
signature for the update without receiving a fully signed transaction.
In this case they do not even know which channel they have open (the one
of the old state that they have fully signed, or the one for the new
state that they have given out their signature for). This is known as a
'Stale Factory', and can be exploited by an adversary in a 'Stale
Factory' attack [1]. Even if they knew which state they are in (i.e. the
party went unresponsive but not during a factory-level update), some of
them might have run out of funds in some of their channels of the
factory, and might want to update, while they will not be willing to
wait for a party to go back online (something for which they also have
zero guarantees of).
An eltoo-like protocol that works (allowing going on-chain) if you can't
in advance who will become absent, then this is precisely why
'Transaction Fragments' have been suggested. They allow an eltoo-like
protocol even when one cannot predict in advance who will become absent,
or malicious (by publishing invalid states), cause the non-absent
parties can unite their fragments and create a valid spendable
factory-level transaction that effectively kicks out the malicious
parties, while leaving the rest of the factory as it was. To the best of
my understanding, the eltoo original proposal also allows this though.
Best,
Alejandro.
[1]: Scalable Lightning Factories for Bitcoin,
https://eprint.iacr.org/2018/918.pdf
On 08/02/2019 20:01, Jonas Nick via bitcoin-dev wrote:
> Output tagging may result in reduced fungibility in multiparty eltoo channels.
> If one party is unresponsive, the remaining participants want to remove
> the party from the channel without downtime. This is possible by creating
> settlement transactions which pay off the unresponsive party and fund a new
> channel with the remaining participants.
>
> When the party becomes unresponsive, the channel is closed by broadcasting the
> update transaction as usual. As soon as that happens the remaining
> participants can start to update their new channel. Their update signatures
> must use SIGHASH_NOINPUT. This is because in eltoo the settlement txid is not
> final (because update tx is not confirmed and may have to rebind to another
> output). Therefore, the funding output of the new channel must be NOINPUT
> tagged. Assuming the remaining parties later settle cooperatively, this loss
> of fungibility would not have happened without output tagging.
>
> funding output update output settlement outputs update output
> [ A & B & C ] -> ... -> [ (A & B & C & state CLTV) | (As & Bs & Cs) ] -> [ NOINPUT tagged: (A' & B'), -> ...
> C' ]
> If the expectation is that the unresponsive party returns, fungibility is
> not reduced due to output tagging because the above scheme can be used
> off-chain until the original channel can be continued.
>
> Side note: I was not able to come up with an similar, eltoo-like protocol that works
> if you can't predict in advance who will become absent.
>
> On 12/13/18 12:32 PM, Johnson Lau via bitcoin-dev wrote:
>> NOINPUT is very powerful, but the tradeoff is the risks of signature replay. While the key holders are expected not to reuse key pair, little could be done to stop payers to reuse an address. Unfortunately, key-pair reuse has been a social and technical norm since the creation of Bitcoin (the first tx made in block 170 reused the previous public key). I don’t see any hope to change this norm any time soon, if possible at all.
>>
>> As the people who are designing the layer-1 protocol, we could always blame the payer and/or payee for their stupidity, just like those people laughed at victims of Ethereum dumb contracts (DAO, Parity multisig, etc). The existing bitcoin script language is so restrictive. It disallows many useful smart contracts, but at the same time prevented many dumb contracts. After all, “smart” and “dumb” are non-technical judgement. The DAO contract has always been faithfully executed. It’s dumb only for those invested in the project. For me, it was just a comedy show.
>>
>> So NOINPUT brings us more smart contract capacity, and at the same time we are one step closer to dumb contracts. The target is to find a design that exactly enables the smart contracts we want, while minimising the risks of misuse.
>>
>> The risk I am trying to mitigate is a payer mistakenly pay to a previous address with the exactly same amount, and the previous UTXO has been spent using NOINPUT. Accidental double payment is not uncommon. Even if the payee was honest and willing to refund, the money might have been spent with a replayed NOINPUT signature. Once people lost a significant amount of money this way, payers (mostly exchanges) may refuse to send money to anything other than P2PKH, native-P2WPKH and native-P2WSH (as the only 3 types without possibility of NOINPUT)
>>
>> The proposed solution is that an output must be “tagged” for it to be spendable with NOINPUT, and the “tag” must be made explicitly by the payer. There are 2 possible ways to do the tagging:
>>
>> 1. A certain bit in the tx version must be set
>> 2. A certain bit in the scriptPubKey must be set
>>
>> I will analyse the pros and cons later.
>>
>> Using eltoo as example. The setup utxo is a simple 2-of-2 multisig, and should not be tagged. This makes it indistinguishable from normal 1-of-1 utxo. The trigger tx, which spends the setup utxo, should be tagged, so the update txs could spend the trigger utxo with NOINPUT. Similarly, all update txs should be tagged, so they could be spent by other update txs and settlement tx with NOINPUT. As the final destination, there is no need to tag in the settlement tx.
>>
>> In payer’s perspective, tagging means “I believe this address is for one-time-use only” Since we can’t control how other people manage their addresses, we should never do tagging when paying to other people.
>>
>> I mentioned 2 ways of tagging, and they have pros and cons. First of all, tagging in either way should not complicate the eltoo protocol in anyway, nor bring extra block space overhead.
>>
>> A clear advantage of tagging with scriptPubKey is we could tag on a per-output basis. However, scriptPubKey tagging is only possible with native-segwit, not P2SH. That means we have to disallow NOINPUT in P2SH-segwit (Otherwise, *all* P2SH addresses would become “risky” for payers) This should be ok for eltoo, since it has no reason to use P2SH-segwit in intermediate txs, which is more expensive.
>>
>> Another problem with scriptPubKey tagging is all the existing bech32 implementations will not understand the special tag, and will pay to a tagged address as usual. An upgrade would be needed for them to refuse sending to tagged addresses by default.
>>
>> On the other hand, tagging with tx version will also protect P2SH-segwit, and all existing wallets are protected by default. However, it is somewhat a layer violation and you could only tag all or none output in the same tx. Also, as Bitcoin Core has just removed the tx version from the UTXO database, adding it back could be a little bit annoying, but doable.
>>
>> There is an extension to the version tagging, which could make NOINPUT even safer. In addition to tagging requirement, NOINPUT will also sign the version of the previous tx. If the wallet always uses a randomised tx version, it makes accidental replay very unlikely. However, that will burn a few more bits in the tx version field.
>>
>> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 18:14:39

- reply

📅 Original date posted:2018-09-07
📝 Original message:Yes I agree with what you mean but this requires Alice to broadcast an
additional transaction. Also, Alice is supposed to be able to 'cancel'
the transaction in the first 24hours, not after them.
Best,
Alejandro.
On 9/6/18 6:33 PM, Matt Corallo wrote:
> I think you misunderstood my proposal. What you'd do is the transaction
> is spendable by either Bob OR (Bob AND Alice) and before
> broadcast/during construction/whatever sign a new transaction that
> spends it and is only spendable by Alice, but is timelocked for 24
> hours. At the 24h mark, Alice broadcasts the transaction and once it is
> confirmed only Alice can claim the money.
>
> On 09/06/18 10:59, Alejandro Ranchal Pedrosa wrote:
>> Dear Matt,
>>
>> Notice that what you suggest has some substantial differences. With your
>> suggestion of a multisig option with a 24h timelock, once you give Alice
>> the chance to spend that UTXO without a negative timelock (as we argue),
>> by means of, say, a transaction that she can use, you cannot enforce
>> that this is not used by Alice after the 24hs. Perhaps it is possible,
>> tweaking the Lightning Channel design of Breach Remedy txs, to penalize
>> Alice if she does this, but this requires Bob to check the Blockchain in
>> case he needs to publish a proof-of-fraud, think of adding extra funds
>> to the transaction to account for penalization, etc.
>>
>> Feel free to correct me if I got it wrong in your email.
>>
>> Best,
>> Alejandro.
>>
>>
>> On Thu, Sep 6, 2018 at 3:32 PM Matt Corallo <lf-lists at mattcorallo.com
>> <mailto:lf-lists at mattcorallo.com>> wrote:
>>
>> I think a simple approach to what you want to accomplish is to
>> simply have a multisig option with a locktime pre-signed transaction
>> which is broadcastable at the 24h mark and has different
>> spendability. This avoids introducing reorg-induced invalidity.
>>
>> On September 6, 2018 9:19:24 AM UTC, Alejandro Ranchal Pedrosa via
>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> Hello everyone,
>>
>> We would like to propose a new BIP to extend OP_CSV (and/or OP_CLTV) in
>> order for these to allow and interpret negative values. This way,
>> taking the example shown in BIP 112:
>>
>> HASH160 <revokehash> EQUAL
>> IF
>>     <Bob's pubkey>
>> ELSE
>>     "24h" CHECKSEQUENCEVERIFY DROP
>>     <Alice's pubkey>
>> ENDIF
>> CHECKSIG
>>
>> that gives ownership only to Bob for the first 24 hours and then to
>> whichever spends first, we basically propose using the negative bit value:
>>
>> HASH160 <revokehash> EQUAL
>> IF
>>     <Bob's pubkey>
>> ELSE
>>     "-24h" CHECKSEQUENCEVERIFY DROP
>>     <Alice's pubkey>
>> ENDIF
>> CHECKSIG
>>
>> meaning that both would have ownership for the first 24 hours, but
>> after that only Bob would own such coins. Its implementation should
>> not be too tedious, and in fact it simply implies considering negative
>> values that are at the moment discarded as for the specification of
>> BIP-112, leaving the sign bit unused.
>>
>> This, we argue, an increase the fairness of the users, and can at times
>> be more cost-effective for users to do rather than trying a Replace-By-Fee
>> transaction, should they want to modify such payment.
>>
>> We would like to have a discussion about this before proposing the
>> BIP, for which we are preparing the text.
>>
>> You can find our paper discussing it here:
>> https://hal-cea.archives-ouvertes.fr/cea-01867357 (find attached as well)
>>
>> Best,
>>