Hey y'all,
When these sorts of debates arise it prompts me to want to take a step back
and do a more fundamental analysis of what's going on. The question I have
before we even get to the starting line of implementation is "What is
actually being bought?".
It appears to me that what the buyer
Hi Benjamin,
Keep in mind that the to_local output is only spendable after the delay
period which means it is not a valid transaction (and won't show up in the
mempool) until the output becomes spendable. This is also true for HTLC
outputs if the channel type has anchors. The delay period for
Jorge,
I invite you to consider reading your emails before you send them. During
this reread, I specifically encourage you to do so with the frame of mind
of how your words will be read and understood by others on this mailing
list.
The people on this list may have varying levels of familiarity
> It should be therefore a top priority to make the UX of connecting my
mobile LN client to my home full node extremely easy, so that centralised
services can't improve much on that step. Especially if I already run a
full node.
For what it's worth, this is a main research area for us at Start9
exposure for
serving something like bip157 filters without removing your own ability to
make use of some of those same services.
Keagan
On Fri, May 8, 2020 at 1:51 PM Braydon Fuller wrote:
> On 5/6/20 9:07 PM, Keagan McClelland wrote:
>
> > I think that one of the solutions here is
d now you may have consensus capture by those..
>
> Le mer. 6 mai 2020 à 12:00, Keagan McClelland
> a écrit :
>
>> Hi Antoine,
>>
>> Consensus capture by miners isn't the only concern here. Consensus
>> capture by any subset of users whose interests diverge from the
Hi Antoine,
Consensus capture by miners isn't the only concern here. Consensus capture
by any subset of users whose interests diverge from the overall consensus
is equally damaging. The scenario I can imagine here is that the more light
clients outpace full nodes, the more the costs of security
