Igor Cota [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-04-05 to 2021-02-27
💬 Posted a total of 7 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:49:47

- reply

📅 Original date posted:2018-04-09
📝 Original message:
Hi all,
On 9 April 2018 at 11:47, Corné Plooy via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
>
> Is this really only about reducing the size of QR codes? How many
> percent reduction do you think you can accomplish with your approach? I
> think, when it comes to reducing QR code size, it makes more sense to
> think of a better way to encode the node ID. Hexadecimal isn't exactly
> the most space-efficient encoding.
>
We'd save 33 bytes by not using hex. Makes the QR code a bit rarer
(whatever is opposite of dense).
I intend to support both approaches, if there are 33 bytes before the '@'
it's raw, 66 it's hex.
Igor
> Op 07-04-18 om 17:17 schreef Robert Olsson:
> > Hello all,
> >
> > I seem to not find a bolt regarding the QR code of node at ip:port
> >
> > It seems eclair only supports the format hex at ip:port format, and i
> > haven't tried any other mobile wallets.
> >
> > I thought there would be support for bech32 nodeid:s to keep the QR
> > small, but it doesn't seem that way.
> >
> > If it isn't standardized yet, i think we should do it soon so all
> > wallets will support it from start and we can avoid bulky QR codes.
> >
> > To fully utilize QR it should work with charset in text-mode, so i
> > would suggest a format like
> >
> > lightning:ln1bech32nodeid/ipnumber/port
> >
> > where /port is optional if port is 9735
> >
> > this is to avoid @ and confusion of : in ipv6 and :portnumber
> > (skip '[' and ']' in ipv6)
> >
> > another approach would be to encode ip and portnumber in bech32 as
> > well. my opinion is that everything coded entirely in bech32 shouldn't
> > need a protocol so the 'lightning:' part could possibly be omitted as
> > well.
> >
> > or did i just miss a bolt somewhere?
> >
> > best regards
> > Robert Olsson
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
*Igor Cota*
Codex Apertus Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180409/eb71167a/attachment.html>

2023-06-09 12:49:42

- reply

📅 Original date posted:2018-04-05
📝 Original message:
Hello all,
I feel that one of the biggest promises of lightning lies in it being used
for everyday retail payments.
I'd like to see a system that's:
1) instantaneous like the contactless bank cards of today
2) encodes a fancy HTML receipt in bolt11 for the payers future reference
QR codes are a bit unwieldy and even more so if you want a nice HTML table
description of your grocery shopping with hundreds of items - this
relatively large amount of data makes them impractical to scan.
To this end I've been running an instance of c-lightning on Android
[1][2][3] and experimenting with payments via NFC. I set up a machine with
an NFC USB dongle that acts as an point-of-sale terminal [4]. So far so
good!
There are two basic ways you can use NFC enabled phones today - as passive
tag readers or in card emulation mode (not sure if the latter is available
on iOS).
Passive tags are really simple and encoding bolt11 to them works as
expected. If you set the right MIME type Android will open whatever app is
registered to handle lightning and you can either pay instantaneously or
after user confirmation. Works great provided both the phone and terminal
are connected to the network and have a route to each other.
Card emulation mode is more interesting because it enables us to have two
way communication and therefore an ad hoc connection to the lightning
network. After some handshaking, phone can tell the terminal that it wants
to connect to lightning via NFC. All communication between these two
lightning nodes can be done over NFC or even bluetooth [5]. This might be
useful as fallback in situations where mobile data is not available.
I settled on a MIME type (application/lightning) and an NFC application id
(LIGHTNING). There is also a very simple protocol to forward socket data.
For the sake of interoperability it would be great if we agreed on some
standards but I'm not sure how to proceed with this. Should these be part
of a future BOLT or is mailing list banter enough?
I look forward to your views!
Cheers,
Igor
[1]
https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
[2]
https://github.com/ElementsProject/lightning/commit/d4d1c4acb08efb6be4f491cdee5cb6dd4b84ddf7
[3]
https://github.com/ElementsProject/lightning/commit/bd95aba7a5f9bad8f447bf3de8f7e8cfe83751af
[4] https://github.com/icota/presto
[5] https://github.com/ElementsProject/lightning/pull/1323
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180405/14754627/attachment.html>

2023-06-07 18:29:14

- reply

📅 Original date posted:2021-02-27
📝 Original message:Hi Keagan,
I had a very similar idea. The only difference being for the node to decide
on a range of blocks to keep beforehand, rather than making the decision
block-by-block like you suggest.
I felt the other nodes would be better served by ranges due to the
sequential nature of IBD. Perhaps this would be computationally lighter as
well.
I also encourage you to read Ryosuke Abe's paper [1] that proposes a DHT
scheme to solve this same problem.
Cheers,
Igor
[1] https://arxiv.org/abs/1902.02174
On Fri, 26 Feb 2021 at 21:57, Keagan McClelland via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> I've been thinking for quite some time about the problem of pruned nodes
> and ongoing storage costs for full nodes. One of the things that strikes me
> as odd is that we only really have two settings.
>
> A. Prune everything except the most recent blocks, down to the cache size
> B. Keep everything since genesis
>
> From my observations and conversations with various folks in the
> community, they would like to be able to run a "partially" pruned node to
> help bear the load of bootstrapping other nodes and helping with data
> redundancy in the network, but would prefer to not dedicate hundreds of
> Gigabytes of storage space to the cause.
>
> This led me to the idea that a node could randomly prune some of the
> blocks from history if it passed some predicate. A rough sketch of this
> would look as follows.
>
> 1. At node startup, it would generate a random seed, this would be unique
> to the node but not necessary that it be cryptographically secure.
> 2. In the node configuration it would also carry a "threshold" expressed
> as some percentage of blocks it wanted to keep.
> 3. As IBD occurs, based off of the threshold, the block hash, and the
> node's unique seed, the node would either decide to prune the data or keep
> it. The uniqueness of the node's hash should ensure that no block is
> systematically overrepresented in the set of nodes choosing this storage
> scheme.
> 4. Once the node's IBD is complete it would advertise this as a peer
> service, advertising its seed and threshold, so that nodes could
> deterministically deduce which of its peers had which blocks.
>
> The goals are to increase data redundancy in a way that more uniformly
> shares the load across nodes, alleviating some of the pressure of full
> archive nodes on the IBD problem. I am working on a draft BIP for this
> proposal but figured I would submit it as a high level idea in case anyone
> had any feedback on the initial design before I go into specification
> levels of detail.
>
> If you have thoughts on
>
> A. The protocol design itself
> B. The barriers to put this kind of functionality into Core
>
> I would love to hear from you,
>
> Cheers,
> Keagan
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
*Igor Cota*
Codex Apertus d.o.o.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210227/c79266b3/attachment.html>