Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

On 13 October 2018 7:12:03 pm GMT+09:00, Christian Decker wrote: >Great find ZmnSCPxj, we can also have an adaptive scheme here, in which >we >start with a single update transaction, and then at ~90% of the >available >range we add a second. This is starting to look a bit like the DMC

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Great find ZmnSCPxj, we can also have an adaptive scheme here, in which we start with a single update transaction, and then at ~90% of the available range we add a second. This is starting to look a bit like the DMC invalidation tree :-) But realistically speaking I don't think 1B updates is going

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Another way would be to always have two update transactions, effectively creating a larger overall counter: [anchor] -> [update highbits] -> [update lobits] -> [settlement] We normally update [update lobits] until it saturates. If lobits saturates we increment [update highbits] and reset

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Thanks Anthony for pointing this out, I was not aware we could roll keypairs to reset the state numbers. I basically thought that 1billion updates is more than I would ever do, since with splice-in / splice-out operations we'd be re-anchoring on-chain on a regular basis anyway. On Wed, Oct 10,

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

(bitcoin-dev dropped from cc) On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote: > eltoo is a drop-in replacement for the penalty based invalidation > mechanism that is used today in the Lightning specification. [...] I think you can simplify eltoo further, both in the way the

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Good morning Carsten, > > The setup transaction is simply a transaction that spends some funds and > > > > creates a single output, which has the script from Figure 2, but since > > > > that would be a forward reference, I decided to handwave and call it a > > > > multisig. A simple fix would

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Carsten Otto writes: > the paper is a bit confusing regarding the setup transaction, as it is > not described formally. There also seems to be a mixup of "setup > transaction" and "funding transaction", also named T_{u,0} without > showing it in the diagrams. The setup

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Good morning Christian, It seems to me we can remove the trigger transaction. The observation is that `nSequence`-encumbered transactions are only settlement transactions and not any update transactions. Thus, it is not needed for a trigger transaction to exist, if we can make update

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

ZmnSCPxj writes: > Good morning Christian, > > This is very interesting indeed! > > I have started skimming through the paper. > > I am uncertain if the below text is correct? > >> Throughout this paper we will use the terms *input script* to refer to >> `witnessProgram`

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Hi Christian, Let me know if I have summarized the paper accurately below: 1. SIGHASH_NOINPUT removes all inputs of the transaction copy before signing/verifying. 2. SIGHASH_NOINPUT can be combined with SIGHASH_SINGLE. It is dangerous to combine it with SIGHASH_NONE (as this also deletes

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Good morning Christian, This is very interesting indeed! I have started skimming through the paper. I am uncertain if the below text is correct? > Throughout this paper we will use the terms *input script* to refer to > `witnessProgram` and `scriptPubKey`, and *output script* to refer to the