Author

Topic: LN: os planos não sobrevivem ao encontro com o mundo real (Read 122 times)

hero member
Activity: 1274
Merit: 681
I rather die on my feet than to live on my knees
Gostava de ter visto uns screens ou fotos dessas falhas. Mas a cena dos invoices por si só, não é a coisa mais intuitiva do mundo. Se queres receber de alguém, tu geras um invoice para tu receberes. Se precisas de enviar para alguém, esse alguém gera um invoice para tu pagares!

À primiera vista, quem quer enviar também devia poder gerar um invoice, mas normalmente, quem recebe é quem gera o invoice. á uma circunstância muito específica em que pode ser quem envia a criar o invoice mas é com um comando (pelo menos no CLN) que é o keysend, onde partimos do princípio que o node que vai receber sabe a pre-image (ou payment hash). Mas muito raramente este método é usado!

A ideia é simples! E eu já gerei vários e já paguei usando vários. Mas, algumas vezes, quando eu quero adicionar só o endereço LN e setar o valor (tal como seria o fluxo normal de um pagamento BTC), acho que algumas configurações não aceita. Só aceita via invoice, mas isso não está necessariamente especificado. Continha estando escrito '' endereço'', de forma que eu não consigo saber se realmente aquele sistema/implementação só aceita invoice ou se a questão é outra e é alguma possível falha mesmo.

Nunca tive problema em gerar, mas é mais no processo de se conectar com o outro lado da transação.

Eu não consegui perceber o que tentaste dizer ali no que sublinhei. Se conseguires dizer de outra forma para ver se eu consigo entender, agradecia.
Que wallet usaste? É que em LN não há endereços, pelo menos na mesma perspectiva de Bitcoin (onchain). O mais parecido que temos são as pub keys dos nodes LN que pode ser ago deste género:
03fef777d58a529df02a3fb267690e0c9033767b555cc1c63844bb2d3498789f91
Esta é a pubkey do meu node.

Outra coisa que pode ser o ue tu te referes como endereço, é o código do invoice que pode ser algo deste género:
lnbc9999990n1pj4l2e4pp5h03rkyn95tncvfyf6mgpcucqhvjz9svn8f3jsv68gjfafcwhjlnsdqqc qzzsxqyz5vqsp5jn762gd0upt09u2x9u5js0anavfq56642pyzs4a2fnuj65q9qm2s9qyyssqzy4esm u6rhfxm9tzh4ytux96kz0m8ccdlyvdvynel39g5y7zuthxpudullkt07rw06hvpejjwqh7zm3r4h3d4 mlzwprr7yxtsp3xu4gpxszej5

E a que configurações ao certo te referes? Podes dar algum exemplo?

Eu ainda hoje fiz um pagamento de cerca de 36€ e correu tudo bem, do meu node para outro node conhecido meu! Mas não usei nenhuma wallet "de terceiros". Usei o meu node LN. Pedi ao "credor" um invoice do valor que lhe devia. Ele criou esse invoice e deu-me o código e eu paguei usando um comando no meu node! Demorou alguns segundos até receber a confirmação que o pagamento tinha sido efectuado!
legendary
Activity: 1428
Merit: 1568
Gostava de ter visto uns screens ou fotos dessas falhas. Mas a cena dos invoices por si só, não é a coisa mais intuitiva do mundo. Se queres receber de alguém, tu geras um invoice para tu receberes. Se precisas de enviar para alguém, esse alguém gera um invoice para tu pagares!

À primiera vista, quem quer enviar também devia poder gerar um invoice, mas normalmente, quem recebe é quem gera o invoice. á uma circunstância muito específica em que pode ser quem envia a criar o invoice mas é com um comando (pelo menos no CLN) que é o keysend, onde partimos do princípio que o node que vai receber sabe a pre-image (ou payment hash). Mas muito raramente este método é usado!

A ideia é simples! E eu já gerei vários e já paguei usando vários. Mas, algumas vezes, quando eu quero adicionar só o endereço LN e setar o valor (tal como seria o fluxo normal de um pagamento BTC), acho que algumas configurações não aceita. Só aceita via invoice, mas isso não está necessariamente especificado. Continha estando escrito '' endereço'', de forma que eu não consigo saber se realmente aquele sistema/implementação só aceita invoice ou se a questão é outra e é alguma possível falha mesmo.

Nunca tive problema em gerar, mas é mais no processo de se conectar com o outro lado da transação.
hero member
Activity: 1274
Merit: 681
I rather die on my feet than to live on my knees
Gostava de ter visto uns screens ou fotos dessas falhas. Mas a cena dos invoices por si só, não é a coisa mais intuitiva do mundo. Se queres receber de alguém, tu geras um invoice para tu receberes. Se precisas de enviar para alguém, esse alguém gera um invoice para tu pagares!

À primiera vista, quem quer enviar também devia poder gerar um invoice, mas normalmente, quem recebe é quem gera o invoice. á uma circunstância muito específica em que pode ser quem envia a criar o invoice mas é com um comando (pelo menos no CLN) que é o keysend, onde partimos do princípio que o node que vai receber sabe a pre-image (ou payment hash). Mas muito raramente este método é usado!
legendary
Activity: 1428
Merit: 1568

Eu estou bem curioso sobre detalhes dos pontos 1 e 2, pois parece ser algo especifico de uma software especifico. Se puder postar detalhes a respeito eu ficaria muito feliz em olhar.

Infelizmente, software mal escrito ta cheio por ai, e isso nao é exclusividade do mundo crypto, essa semana eu precisei criar um usuario em um sistema governamental aqui do pais onde moro e para minha surpresa, a mensagem de erro que recebi era de que "a person with that name and date of birth already exists" (uma pessoa com esse nome e data de nascimento ja existe).

Ou algo bem mais grave como o caso do Airbus 737 max: https://en.wikipedia.org/wiki/Boeing_737_MAX_groundings

Eu trabalho com desenvolvimento de software em uma das maiores empresas da area e mesmo no cenario onde me encontro ainda da pra chorar com o que vemos de vez em quando.

Já o terceiro ponto é sim um grande problema atualmente, principalmente para valores maiores... há alguma propostas a respeito em andamento mas ainda acho que estamos longe de resolver. E acho que nem é tao dificil assim de resolver visto que é uma tecnologia 100% automatizada entao o "money velocity" (https://www.investopedia.com/terms/v/velocity.asp#toc-example-of-velocity-of-money) seria tao alto que tornaria rebalanceamento (ou roteamento dinamico, que efetivamente causaria o rebalanceamento automatico) algo simples de resolver... de maneira simplista, o pessoal de networking e a internet ja resolveu isso a decadas com OSPF, RIP, BGP e outros protocolos que poderiam ser adaptados.



Eu não sei muitos detalhes, já que era um evento. Mas vou especificar o que eu sei:

1. Era uma máquina de café e na máquina tinha os QR codes pré-setados para cada tipo de café. Você lia o QR code e então a máquina deveria começar o café. A muun não era capaz de entender o QR CODE como um invoice de pagamento, ela lia como um invoice meu, como se eu estivesse pedindo o pagamento para o qr code da máquina de café. Sei que a Wallet of Satoshi e o envio via BIPA funcionaram tranquilamente na máquina.

2. No evento, os estabelecimentos aceitavam pagamentos via LN, as máquinas foram uma implementação feita pela Cometcash:https://www.cometcash.com/
A muun conseguia ler normal o QR code e eu fiz várias compras. Nesse, a wallet of satoshi e a phoenix e talvez até a ZEUS não funcionou.

3.  O pagamento não era tão alto, era de 300 reais.

Ontem tive um novo problema kkkk mas nesse caso talvez o problema tenha sido meu, mas foi nada intuitivo. Eu estava tentando sacar via LN e quando eu colocava o endereço (sem ser invoice) ele não reconhecia. Dava como endereço inválido. Tentei com 2 endereços LN de duas wallets diferentes (muun e phenix). Ai quando eu FIZ o invoice do valor com uma terceira solução, deu certo.

Ontem também tentei fazer duas transferencias LN via Muun e a taxa estava em R$ 13 kkkk

Particularmente, não gosto mt da ideia do ''invoices'' da LN. Mas talvez tenha um ponto que como usuária, eu não entendi.



Qualquer das formas, concordo com a Disruptivas.
Apesar de nunca ter usado LN, do que tenho pesquisado, a coisa é mais "trabalhosa" do que realmente parece. Honestamente, ainda não estou convencido... mas vou continuar analisar.

Quando dá certo, é bem fácil e nada trabalhoso. Já paguei cerveja, café, cinema.. muitas coisas tanto via BTC msm ou via LN. E se dá certo, é show. Mas se dá errado, até dar certo é trabalhoso kkkk

hero member
Activity: 1274
Merit: 681
I rather die on my feet than to live on my knees
Bom galera, quero fazer alguns relatos pessoas com a LN

A proposta todos sabem qual é.

Mas na prática, a experiência é BEEEEEEEEEEM BUGADA.

Nos ultimos meses eu tive algumas oportunidades de usar a LN. E vários bugs ocorreram.

1. Ao ler um QR code de ENVIO, a minha wallet entendia que eu estava PEDINDO um depósito. Outras wallets funcionavam.
2. Algumas wallets simplesmente não reconheciam um QR code de pagamento. Outras sim.
3. Algumas vezes, os invoices via LN são erro ''Failure_reason_no_route''


Ou seja, digamos que em 10 tentativas de transações envolvendo máquinas diferentes e wallets diferentes, umas 3 dá um erro novo kkkk

Os pontos 1 e 2 são claramente wallet-dependent. Ou seja, leitura de QR codes não faz parte do protocolo LN. Portanto, isso é algo que faz parte da implementação da wallet que usaste.
Podes fazer é o seguinte:
Com um QR code reader comum, faz scan a um desses QR codes das wallets LN que usaste. Depois podes tentar comparar o conteúdo de uma wallet que funciona com o de outra que não funciona! Ou até postar aqui e pode ser que alguém consiga identificar algum problema mais óbvio! Quem sabe se não "achaste" um bug qualquer! Smiley
hero member
Activity: 1554
Merit: 814
The Alliance Of Bitcointalk Translators - ENG>POR
(...)
Olha, confesso que também fiquei bem curioso sobre esses bugs.
Mas eu acredito que possa ter acontecido o que o @Adriano disse acima, o código do software pode ter sido mal escrito, talvez a versão do app e ou SO pode ter alguma influencia ou algum ""erro de compatibilidade"" possa ter ocorrido (claro que isso é "achismo" de minha parte)

Alias @Disruptivas, qual wallet que você estava utilizando? Electrum? Eclair?
legendary
Activity: 1722
Merit: 4711
**In BTC since 2013**
achei aqui:

Em uma cidade, os habitantes, endividados, estão vivendo às custas de crédito.
Por sorte chega um gringo e entra no único hotel da cidade.
O gringo saca uma nota de R$ 100,00, põe no balcão e pede para ver um quarto.
Enquanto o gringo vê o quarto, o gerente do hotel sai correndo com a nota de R$ 100,00 e vai até o açougue pagar suas dívidas com o açougueiro.
O açougueiro pega a nota e vai até um criador de suínos a quem deve e paga tudo. O criador, por sua vez, pega também a nota e corre ao veterinário para liquidar sua dívida.
O veterinário, com a nota de R$ 100,00 em mãos, vai até à zona pagar o que devia a uma prostituta (em tempos de crise essa classe também trabalha a crédito).
A prostituta sai com o dinheiro em direção ao hotel, lugar onde levava seus clientes e que ultimamente não havia pago pelas acomodações e paga a conta de R$ 100,00.
Nesse momento o gringo chega novamente ao balcão, pede sua nota de R$ 100,00 de volta, agradece, diz não ser o que esperava e sai do hotel e da cidade.
Ninguém ganhou um vintém, porém agora todos saldaram suas dívidas e começam a ver o futuro com confiança!

Moral da história:
Quando o dinheiro circula, não há crise.

Excelente historia. Acho que devia partilhar com os Bancos Centrais, para acabarem com essa ideia de aumentar as taxas de juros, para a malta parar de gastar dinheiro.  Roll Eyes
Sim eu sei que existe mais coisas envolvidas, mas achei que encaixava bem esta historia, com as taxas de juro.


Qualquer das formas, concordo com a Disruptivas.
Apesar de nunca ter usado LN, do que tenho pesquisado, a coisa é mais "trabalhosa" do que realmente parece. Honestamente, ainda não estou convencido... mas vou continuar analisar.
staff
Activity: 1286
Merit: 1085
achei aqui:

Em uma cidade, os habitantes, endividados, estão vivendo às custas de crédito.
Por sorte chega um gringo e entra no único hotel da cidade.
O gringo saca uma nota de R$ 100,00, põe no balcão e pede para ver um quarto.
Enquanto o gringo vê o quarto, o gerente do hotel sai correndo com a nota de R$ 100,00 e vai até o açougue pagar suas dívidas com o açougueiro.
O açougueiro pega a nota e vai até um criador de suínos a quem deve e paga tudo. O criador, por sua vez, pega também a nota e corre ao veterinário para liquidar sua dívida.
O veterinário, com a nota de R$ 100,00 em mãos, vai até à zona pagar o que devia a uma prostituta (em tempos de crise essa classe também trabalha a crédito).
A prostituta sai com o dinheiro em direção ao hotel, lugar onde levava seus clientes e que ultimamente não havia pago pelas acomodações e paga a conta de R$ 100,00.
Nesse momento o gringo chega novamente ao balcão, pede sua nota de R$ 100,00 de volta, agradece, diz não ser o que esperava e sai do hotel e da cidade.
Ninguém ganhou um vintém, porém agora todos saldaram suas dívidas e começam a ver o futuro com confiança!

Moral da história:
Quando o dinheiro circula, não há crise.
staff
Activity: 1286
Merit: 1085
Oi Disruptivas

Eu estou bem curioso sobre detalhes dos pontos 1 e 2, pois parece ser algo especifico de uma software especifico. Se puder postar detalhes a respeito eu ficaria muito feliz em olhar.

Infelizmente, software mal escrito ta cheio por ai, e isso nao é exclusividade do mundo crypto, essa semana eu precisei criar um usuario em um sistema governamental aqui do pais onde moro e para minha surpresa, a mensagem de erro que recebi era de que "a person with that name and date of birth already exists" (uma pessoa com esse nome e data de nascimento ja existe).

Ou algo bem mais grave como o caso do Airbus 737 max: https://en.wikipedia.org/wiki/Boeing_737_MAX_groundings

Eu trabalho com desenvolvimento de software em uma das maiores empresas da area e mesmo no cenario onde me encontro ainda da pra chorar com o que vemos de vez em quando.

Já o terceiro ponto é sim um grande problema atualmente, principalmente para valores maiores... há alguma propostas a respeito em andamento mas ainda acho que estamos longe de resolver. E acho que nem é tao dificil assim de resolver visto que é uma tecnologia 100% automatizada entao o "money velocity" (https://www.investopedia.com/terms/v/velocity.asp#toc-example-of-velocity-of-money) seria tao alto que tornaria rebalanceamento (ou roteamento dinamico, que efetivamente causaria o rebalanceamento automatico) algo simples de resolver... de maneira simplista, o pessoal de networking e a internet ja resolveu isso a decadas com OSPF, RIP, BGP e outros protocolos que poderiam ser adaptados.

Tem uma piada bem simples para entender money velocity, deixa ver se acho aqui e posto um update.

Abraco,

Adriano
legendary
Activity: 1428
Merit: 1568
Bom galera, quero fazer alguns relatos pessoas com a LN

A proposta todos sabem qual é.

Mas na prática, a experiência é BEEEEEEEEEEM BUGADA.

Nos ultimos meses eu tive algumas oportunidades de usar a LN. E vários bugs ocorreram.

1. Ao ler um QR code de ENVIO, a minha wallet entendia que eu estava PEDINDO um depósito. Outras wallets funcionavam.
2. Algumas wallets simplesmente não reconheciam um QR code de pagamento. Outras sim.
3. Algumas vezes, os invoices via LN são erro ''Failure_reason_no_route''


Ou seja, digamos que em 10 tentativas de transações envolvendo máquinas diferentes e wallets diferentes, umas 3 dá um erro novo kkkk
Jump to: