Good morning Tyler,
> Great points. IsStandard() is something I hadn't considered yet, but I think
> miners are incentivized to want Numerifides transactions as a registration
> will need a solid miners fee, and "revoked" names will cause escalating fee
> wars that the miners can just soak up.
Great points. IsStandard() is something I hadn't considered yet, but I
think miners are incentivized to want Numerifides transactions as a
registration will need a solid miners fee, and "revoked" names will cause
escalating fee wars that the miners can just soak up. I think a standard
that uses m
Good morning Tyler,
> I like the efficiency your method brings and I'm also not that enthused about
> bloating the blockchain with "non-financial data", however I do think there's
> value in having the data live in the base chain, both from accessibility and
> censorship resistance of the data
I like the efficiency your method brings and I'm also not that enthused
about bloating the blockchain with "non-financial data", however I do think
there's value in having the data live in the base chain, both from
accessibility and censorship resistance of the data to less additional
"networks". A
Good morning,
CLTV < unix epoch is for absolute lock time measured sanely in blocks, while >
unix epoch is for absolute lock time measured in that arbitrary human-preferred
unit called "seconds". I believe you mean CSV, as that is for relative lock
time measured in blocks (but note that it has
"[]" are placeholders for the appropriate data. I believed that CLTV less
than the Unix epoch would be for a relative time lock but admittedly I've
never written Bitcoin script so CSV definitely could be the appropriate
opcode to be use here for a relative time lock.
52560 was meant to be a year i
Good morning Tyler,
Offhand, I am uncertain the first script given in "Technical Proposal" works as
a "check proof-of-work" script.
Are the "[]" comments? Or are they pushes of actual data embedded in the
SCRIPT? It seems to be comments...?
OP_CheckLockTimeVerify is absolute time, not relativ
I'm working on a proposal called Numerifides. Full working document here:
https://github.com/tyzbit/numerifides
Highlights:
- Committed directly to Bitcoin blockchain
- Seems to solve Zooko's triangle (Decentralized, secure and human
meaningful)
- Can use already existing SPV infrastructure for l
Op 10-04-18 om 20:34 schreef Tyler H:
>
> I will continue to approach the problem of securely advertising
> human-understandable node names, and I hope someday soon I will have a
> solution Lightning can use that retains the open, decentralized
> properties of the technology and the underlying blo
ZmnSCPxj writes:
>> This also allows domain operators to have one or more public nodes,
>> but many private ones with channels open to their public nodes to
>> better manage their risk. For example, the private nodes could be
>> behind a firewall.
>
> I am not sure how the risk gets managed if the
ZmnSCPxj,
Yes, I understand I essentially I'd have to solve that trilemma in order to
implement something suitable for Lightning.
That is why I have pulled my support for my proposal, and I do insist that
the proposal AT MOST be a convention, but not a standard, and nodes SHOULD
NOT trust DNS.
T
Good morning Tyler,
> I will continue to approach the problem of securely advertising
> human-understandable node names, and I hope someday soon I will have a
> solution Lightning can use that retains the open, decentralized properties of
> the technology and the underlying blockchains.
I beli
Christian, ZmnSCPxj et al,
Your concerns have been taken seriously, and while this might provide some
useful features with regard to opening appropriate channels (and I guess
can be implemented outside of spec, if an implementation so wishes), after
consideration and some very useful feedback from
Good morning Tyler,
> The external party idea is interesting, but I'm fearful that it can't be done
> in a way that retains a bare minimum of privacy.
No, of course not. "Private" channels are privacy sieves and should not be
used by privacy-conscious entities. Since the channel is never publ
I understand now, I hadn't fully considered the necessary channels for such
a configuration, though there is still the value of domain owners being
able to advertise preferred nodes to connect to in order to pay them
efficiently. The external party idea is interesting, but I'm fearful that
it can'
Good morning Tyler,
> This is not the intention. This BOLT _does not_ replace bootstrapping seed
> functionality, now or ever. A client can supplement her view of the network
> by getting the graph from well-known nodes if she wishes, but no more. To do
> otherwise _would_ centralize the net
> Connect is not the same as make a channel with. Connect simply lets you
access gossip information. So the hard-coded node is not privileged: it
simply relays gossip information to the wallet, equivalent to getting an
entire map of the network as visible from that node. The plan is that you
con
Good morning Tyler,
> A side effect of this BOLT would be, as an example, the mobile Eclair wallet
> could be updated to accept a domain parameter to specify an initial node to
> open a user's first channel to rather than only the option to "autoconnect"
> to their hard-coded node, and the wall
Christian,
I hope the additional clarification in the RFC makes clear that BOLT 10
takes precedence for bootstrapping and autopilot functionality. To
summarize the intention of this BOLT: Lightning is authoritative, but DNS
can be used to assist in on-boarding (with all of its usefulness AND
inhe
Tyler,
thanks for the detailed feedback, I'll try to address some of the issues
inline:
Tyler H writes:
> --Regarding looking up nodes at the time of payments:
>
> In the future, nodes could negotiate a channel open with a push amount and
> provide the TXID or payment hash as proof of their paym
Christian et al,
I've added additional wording to the PR to explicitly state BOLT 12 MUST
NOT be used for node bootstrapping. I will squash the commits should this
proposal become a standard.
A side effect of this BOLT would be, as an example, the mobile Eclair
wallet could be updated to accept
Christian,
I think your points are all valid. I believe the challenge with something
like this will be in it's general use and implementation, which is why the
RFC doesn't make mention of intended usage past mentioning different nodes
for "clothing" or "ebooks" a domain could advertise.
--Regard
Hi Tyler,
Hi Robert,
first of all, welcome to the mailing list, always good to have more
people looking and improving the spec. I quickly read through the spec
and it is very well written, and it looks good.
On a conceptual level, I do however have some issues with the
proposal. I don't think tha
Greetings,
A challenge end-users face is connecting to nodes with enough liquidity to
pay every merchant, and failing that, finding the merchant node in a
reasonably sane way to open a channel to them for payments.
As it is now, people find nodes in other people's visualizers, and pass
node alias
24 matches
Mail list logo