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
>invalidati
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
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 [upda
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, 2
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. [...]
Maybe this is obvious, but in case it's not, re: the locktime-based
sequencing in eltoo:
"any
(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 tran
Good morning Corne,
‐‐‐ Original Message ‐‐‐
On May 15, 2018 9:22 PM, Corné Plooy wrote:
> Hi Christian, ZmnSCPxj ,
>
> > > - The CSV-encumberance on settlement transactions, which are the ones
> > >
> > > which carry the contracts in the channel, affects all
> > >
> >
Hi Christian, ZmnSCPxj ,
>> - The CSV-encumberance on settlement transactions, which are the ones
>> which carry the contracts in the channel, affects all
>> absolute-timelocked contracts transported on the channel. Compare to
>> Poon-Dryja, where commitment transactions themselves are unencumbe
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 b
Hey Christian,
On Thu, May 03, 2018 at 12:51:01PM +0200, Christian Decker wrote:
> 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 i
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 transaction is simply a tra
ZmnSCPxj writes:
> Ha, no, looking at the detailed `SIGHASH_NOINPUT` spec, `hashPrevouts`, which
> normally commits to the other inputs, is blanked, so we do not commit to them
> either. This means that `SIGHASH_NOINPUT` implicitly has a
> `SIGHASH_ANYONECANPAY`.
>
> (the BIP `SIGHASH_NOINPUT`
Hi ZmnSCPxj, Christian, list,
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.
In 3.1 the funding transaction is de
Hi ZmnSCPxj, Christian, list,
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.
In 3.1 the funding transaction is de
Good morning Christian,
> > > 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.
> > >
> >
> > It sets them to a known constant, in
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 transacti
Good morning Christian,
Thank you very much!
> > 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.
> >
>
> It sets them to a known constant, i
Excellent summary ZmnSCPxj, I'll try to address the points inline (if
there is anything to add that is):
ZmnSCPxj writes:
> 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/verify
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` and `scriptPubKey`, and *
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 al
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
(cross-posting to bitcoin-dev since this serves as motivation behind the
sighash_noinput proposal)
> TL;DR: we announce a new, simple, update mechanism for off-chain protocols,
> see the announcement [1] and the paper [2] :-)
A little over a year ago, the three Lightning Network implementation
te
22 matches
Mail list logo
