Isto, em resumo, é para provar que seu evento não foi gerado por um bot. Pode ser que algum relay exija, para aceitar o evento.

Ok, mas qual a diferença entre prova de trabalho 1 para 10?

Interessante

Basicamente, a ideia é fazer o cliente realizar uma certa quantidade de trabalho para gerar uma nota com um ID contendo um número definido de bits zerados no começo DS string. Ou seja, o cliente precisa gastar uma certa quantidade de poder computacional (e energia) para adicionar uma demonstração ("minerar") determinada nota. Relays e clientes podem então rejeitar notas que não contenham essa prova. Por exemplo, se você não estiver na minha rede de confiança, precisaria de uma prova de trabalho com dificuldade de pelo menos 40 para postar. A teoria por trás disso é que o desafio seria barato de produzir para algumas poucas notas legítimas, mas caro para um spammer enviando milhares / milhões de notas. Na prática, a história é outra: na época do ReplyGuy, foi provado que a rede ainda é pequena o suficiente para que spammers consigam gerar notas e incomodar mesmo com dificuldades relativamente altas de PoW. Dito isso, vale a pena que os clientes implementem algo assim, já que alguns relays ainda exigem PoW. Por exemplo, o nos.lol e o nostr.mom às vezes requerem PoW 28 para postar, especialmente de npubs novos ou quando publicamos eventos demais em sequência. Para mais detalhes, veja:

GitHub

nips/13.md at master · nostr-protocol/nips

Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.

A "dificuldade" é a quantidade mínima de bits zerados no começo da nota.

Ele tentou postar em algum relay que usa PoW. O Iris pode não estar com a lista de relays dele desatualizada e por isso não deu erro lá, ele retirou o relay PoW ou o relay estava testando PoW naquele momento para implementar futuramente. São as possibilidades que pensei.

Jumble é foda demais, o cara falou um dia desse e já foi implementado.

Por isso eu digo que quando você escolhe um cliente Nostr, você precisa ver quem está por trás e o quão o desenvolvedor está ativo e envolvido no projeto.

E o quão detalhista a pessoa é também.

Esperei 1 ano pro Amethyst atualizar só pra me decepcionar :creepy_eyes:

Acho que ideia do Vitor era que o Amethyst fosse um faz tudo, até para que uma demanda da comunidade fosse realizads o mais breve possível, pois não existiam muitos clientes Nostr. Mas hoje não faz mais sentido ter um cliente faz tudo e com muitos bugs. Seria melhor nesse momento ele ir retirando funcionalidades e deixando o mais limpo possível.

Eu estou usando ao mesmo tempo Amethyst, Damus, Primal, Iris, Nostter, Jumble e de vez em quando tento o Phoenix pra ver se um dia para de dá erro. Eu faço isso porque mesmo colocando os mesmos relays, nem tudo chega em mim ou então chega em tempos diferentes. Depois disso eu comecei a colocar relays diferentes para cada cliente com o tempo, e o Amethyst tinha relays Onion Aparentemente eles sincronizaram meio erradamente e deram a louca kkkk Ainda estou aprendendo sobre relays e como eles funcionam

É a quantidade de zero a esquerda. Para entender, aproveite que voce usa o cliente jumble e clique nos três pontinhos e depois em ver evento em formato raw. Verá varios campos e seus valores. Para ser exato 7 campos. A maioria são de um único valor e o campo tag é uma lista de valores. [[Os valores Abaixo foram tirados da minha cabeça não correspondem a realidade. São só ilustrativos]] Existe um negócio chamado 'função hash' que o que ele faz é pegar um texto e transforma em um número aleatório ( ou pega um número e transforma em outro número aleatório). Como é uma função complicada, você não tem como saber qual o número que será gerado e portanto não tem como escolher qual número será gerado. Só como exemplo: 'novo' gerar 7 'nuvio' gerar 65535 'satoshi' gerar 21000 '121' gerar 123 Vamos supor que o número que a função hash gere seja números entre 0 e 1 bilhão. 000.000.000 - 999.999.999 Caso o relay peça um pow de 5, significa que só aceitará evento que tenha 5 zeros a esquerda, então como nossa fução hash só gera número naquele intervalo então só aceitará hash de 000.009.999 para baixo. O hash do evento vai ser colocada no campo id que você viu no modo raw. Vamos supor que eu queira publicar um evento cujo conteúdo é 'Boa noite galerinha'. mas o hash deu 697.804.322. Como o id é o hash do evento todo, exceto o campo sig, tem uma tag que vai variando para gerar um hash com determinada quantidade de zeros. Então o evento ficaria: O 5 é a quantidade de zeros exigidos no meu exemplo id: 697.804.322 conteúdo: 'Boa noite galerinha' tag: nonce, 1, 5 ignore a palavra nonce 👍 como no id não tem 5 zeros a esquerda, não será aceito pelo relay. então temos que calcular um outro hash, variando o primeiro número do pow. id: 143.998.021 conteúdo: 'Boa noite galerinha' tag: nonce, 2, 5 De novo id: 001.575.387 conteúdo: 'Boa noite galerinha' tag: nonce, 3, 5 novamente, na vigésima tentativa: id: 000.000.435 conteúdo: 'Boa noite galerinha' tag: nonce, 20, 5 Agora tem 6 zeros a esquerda, será aceito pelo relay. De forma bem porca, é isso. 'Aiiin mas o id que eu olhei não tinha 10 zeros.' É porque os zeros é na base binária e o id do evento é na base 16. e tem várias outras coisas que deixei de fora. como, por exemplo, o create_at ser atualizado. mas acho que deu para entender no geral.

Eu não entendi nada mas vou te mandar 1000 sats pela explicação.

Sério? 🤔 tentei ser o mais claro possível.

Para falar a verdade, eu não quis entender. Mas talvez mesmo se eu quisesse, teria uma chance grande de que eu continuaria sem entender.

Você entenderia pô. confia no pai, deixei muito óbvio.

Eu quis te recompensar pela minha preguiça.

Ué, eu já ia te perguntar. :lay_down: Vou ver os comentários.