If I'm not mistaken, the scriptless scripts concept (as currently
formulated) falls to Schor's algorithm, and at present there is no
alternative implementation of the concept to fall back on. Correct? Lest we
build a house of cards, I'd strongly urge everyone to not depend on
functional concepts
Good afternoon ZmnSCPxj,
"I do not see a bloom filter?"
Well, if you look at it kinda sideways, you are using a bloom filter in
your March 23rd proposal. As originally defined, I think the "false
positives" in bloom filtering were the unfortunate cost of performance. In
BIP 37, the false
the real
> network.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On April 19, 2018 7:56 AM, Benjamin Mord <ben@mord.family> wrote:
>
>
> Elegant idea.
>
&
ency could be greatly improved.
Thanks again,
Benjamin Mord
On Thu, Apr 12, 2018 at 12:49 AM, ZmnSCPxj <zmnsc...@protonmail.com> wrote:
> Good morning Benjamin,
>
> Do (should) channels have the option of publicizing their balances, so as
> to improve routing performance / sc
Do (should) channels have the option of publicizing their balances, so as
to improve routing performance / scalability in a large network, and for
competitive differentiation among competing routes? This would allow
channel owners to balance privacy with efficiency, and where the incentive
to
e you to continue this conversation on #lnd on Freenode.
>
> [1]: https://github.com/lightningnetwork/lnd/blob/
> master/lnwallet/interface.go
>
> On Wed, Jan 31, 2018 at 12:23 PM Benjamin Mord <b...@mord.io> wrote:
>
>> Hi,
>>
>> I'm not finding evidence of se
Hi,
I'm not finding evidence of segwit in btcd, yet choice of golang is
appealing to me. Can one run lnd on bitcoind?
More generally speaking, is there a plan for the layer 2 / layer 1 protocol
binding to be abstracted away from the implementation on either side, via
SPI or such?
Thanks,
Ben
reed
> it's a bit floaty unless there's an actual proposal.
>
> On Tue, Jan 30, 2018 at 11:42 AM, Benjamin Mord <b...@mord.io> wrote:
>
>>
>> Ugh, correction - BOLTs are presently written explicitly require segwit
>> (not segwit2x! need more coffee...). Sorry for the
Ugh, correction - BOLTs are presently written explicitly require segwit
(not segwit2x! need more coffee...). Sorry for the 'typo'
On Tue, Jan 30, 2018 at 11:41 AM, Benjamin Mord <b...@mord.io> wrote:
>
> Greg, I think you are confusing two different topics: adversarial forks,
>
nature algorithm, are basically impossible to defend against. May
> be best to focus energies on forks that use strong replay protection in the
> form of FORKID.
>
> On Tue, Jan 30, 2018 at 11:26 AM, Benjamin Mord <b...@mord.io> wrote:
>
>>
>> Thank you, ZmnSCPxj. BCH is
Thank you, ZmnSCPxj. BCH is a warmup question for several reasons, I
believe they don't even support segwit (!) so lightning would be unsafe due
to their txid mutability bug. I agree altcoin support should be lower
priority, whenever it is obvious which is the altcoin (as indeed, is
abundantly
Hi,
One topic I can't seem to find in the BOLTs is how lightning nodes maintain
consensus during or after a fork of the underlying blockchain(s). For
example, channel_announcement messages use a chain_hash, defined as hash of
underlying block chain's genesis block, to identify the currency in
Related, I am also interested in the differences between the three major
lightning implementations: lnd, eclair, and c-lightning. I understand they
are implemented in Go, Scala, and C, respectively. Are there other
important differences for early adopters to consider, when selecting an
Although lightning and cryptocurrency is new, the idea of a distribution
network created from links with negotiated fees and with limited
unidirectional capacity that can be corrected via rebalancing, is not new.
In fact there are several very large and mature markets around the world
that we can
prefers to treat as 0 for simplicity. That should be up to
the implementation I think, and not a protocol constraint.
On Tue, Jan 16, 2018 at 2:58 PM, William Casarin <j...@jb55.com> wrote:
> Benjamin Mord <b...@mord.io> writes:
> > [..]
> > why not allow negati
It isn't obvious to me from the BOLTs if fees can be negative, and I'm
finding uint in the go source code - which suggests not. In scenarios where
the funding of a payment channel has been fully committed in one direction,
why not allow negative fees to incent unwinding, in scenarios where nodes
n abstract level, but at a detailed one also.
On Mon, Jan 15, 2018 at 7:01 PM, Rusty Russell <ru...@rustcorp.com.au>
wrote:
> Benjamin Mord <b...@mord.io> writes:
> > One thing I find useful in RFCs is a brief discussion about the meaning
> of
> > terms like MUST, SHOU
One thing I find useful in RFCs is a brief discussion about the meaning of
terms like MUST, SHOULD, MAY, etc.. as used in the subsequent protocol
definition. But in the traditional approach to protocol design we first
assume cooperative nodes, and then later attempt to retrofit security when
we
I ask what use-case you are looking to implement using this feature?
>
> Cheers,
> Christian
>
> Benjamin Mord <b...@mord.io> writes:
> > Are there, or will there be, annotations one can add to a lightning
> > transaction that can be read by all intermediate n
d writing down some of the ideas at least for Lightning in the
> project's wiki [4], but they're definitely not fleshed out.
>
> [4] https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming
>
>
> On Fri, Nov 17, 2017 at 3:10 PM Benjamin Mord <b...@mord.io&
to
imagine it would be a new idea, although I have not yet found the precedent:
http://ben.mord.io/p/delayed-chained-key-revelation-dckr.html
Thanks,
Ben
On Nov 17, 2017 8:04 AM, "Christian Decker" <decker.christ...@gmail.com>
wrote:
On Thu, Nov 16, 2017 at 5:01 PM Benjamin Mord <
21 matches
Mail list logo
