Verasity Is The Best Attention-Based Video Rewards Model

By: Scott Cunningham Verasity builds the infrastructure and tools for video publishers to serve rewarded video and loyalty programs to their viewers. Basically, you can earn VRA for watching what you already watch, like how Brave monetizes attention for its users.
Essentially from what I’ve gathered, it’s like Brave, but for videos. Also, it can work on Brave so you can earn BAT and VRA at the same time for anyone who is working with them. Anyone can apply if they publish on many sites like YouTube, Twitch, Vimeo, and more. I hope to see it expand to work with other alternative platforms like BitChute, Minds, BitTube, LBRY, etc. It works on top of any of these videos and just adds a simple little trophy icon that will turn green when you are done allowing you to earn VRA. I think this is great for users and creators because you can buy a large amount and run a campaign to incentivize full play-through and encourage more viewers to watch and be rewarded for their time at a low cost to…

Satoshi Nakamoto Emails 6 2008/11/08 - Tradução para português por Michelle Mafra (MamãeCrypto)


Texto traduzido por Michelle Mafra

Disponível no site Cypherpunks.com.br

Por: Satoshi Nakamoto

Lista de Endereços de Criptografia

Bitcoin P2P e-cash papel 

08-11-2008 01:58:48 UTC - E-mail original - Visualizar no tópico

Hal Finney escreveu:

É mencionado que, se uma transação transmitida não atingir todos os nós, não há problema, pois ela entrará na cadeia de blocos em pouco tempo. Como isso acontece - e se o nó que cria o bloco "próximo" (o primeiro nó para encontrar a colisão de hashcash) não tiver ouvido falar sobre a transação e, em seguida, mais alguns blocos forem adicionados também por nós que não souberam sobre essa transação transmitida? Todos os nós que o ouviram mantêm essa transação, esperando incorporá-la a um bloco quando tiverem a sorte de ser o que encontrar a próxima colisão?


Certo, os nós mantêm transações em seu conjunto de trabalho até entrarem em um bloco. Se uma transação atingir 90% dos nós, cada vez que um novo bloco for encontrado, ele terá 90% de chance de estar nele.


Ou, por exemplo, e se um nó estiver mantendo duas ou mais cadeias à medida que espera para ver o que cresce mais rápido, e um bloco entra para a cadeia A, que incluiria um gasto duplo de uma moeda que está na cadeia B? Isso é verificado ou não? (Isso pode acontecer se alguém gastou duas vezes e dois conjuntos diferentes de nós ouviram sobre as duas transações diferentes com a mesma moeda.)


Isso não precisa ser verificado. A transação em qualquer ramo que ficar  mais adiantada torna-se a transação válida, a outra é inválida. Se alguém tentar duplicar esse gasto, um e apenas um gasto sempre será válido, e os outros inválidos.

Recebedores de transações normalmente precisarão realizar transações por talvez uma hora ou mais para dar tempo para que esse tipo de possibilidade seja resolvido. Eles ainda podem gastar novamente as moedas imediatamente, mas devem esperar antes de executar uma ação, como o envio de mercadorias.


Eu também não entendo exatamente como o gasto duplo acontece, ou o cancelamento de transações, é realizado por um atacante superior que é capaz de reunir mais poder de computação do que todos os participantes honestos. Eu vejo que ele pode criar novos blocos e adicioná-los para criar a cadeia mais longa, mas como ele pode apagar ou adicionar transações antigas na cadeia? À medida que o invasor envia seus novos blocos, não existem verificações de consistência que os nós honestos podem executar para garantir que nada seja apagado? Mais explicações sobre este ataque seriam úteis, a fim de julgar os ganhos para um atacante, contra simplesmente usar seu poder de computação para dar origem `a moedas novas honestamente.



O invasor não está adicionando blocos ao final. Ele tem que voltar e refazer o bloco em que sua transação está e todos os blocos depois dela, bem como quaisquer novos blocos que a rede continue adicionando ao final enquanto ele estiver fazendo isso. Ele está reescrevendo a história. Uma vez que seu ramo é mais longo, torna-se o novo válido.

Isso toca em um ponto-chave. Mesmo que todos os presentes possam ver as travessuras acontecendo, não há como aproveitar esse fato.

É estritamente necessário que a maior cadeia seja sempre considerada válida. Os nós presentes podem lembrar que um ramo estava lá primeiro e foi substituído por outro, mas não haveria como convencê-los daqueles que não estavam presentes. Não podemos ter subfacções de nós que se apegam a um ramo que considerem primeiro, outros que viram outro ramo primeiro e outros que aderiram mais tarde e nunca viram o que aconteceu. O voto de prova de trabalho da CPU deve ter a palavra final. A única maneira de todos permanecerem na mesma página é acreditar que a cadeia mais longa é sempre válida, não importa o que aconteça.


Quanto às transações de gastos, que verificações o destinatário de uma moeda deve realizar? Ela precisa voltar pelo histórico completo de transferências da moeda e certificar-se de que todas as transações na lista estejam de fato ligadas à cadeia de blocos "timestamp"? Ou ela pode apenas fazer o mais recente?


O destinatário precisa apenas verificá-lo de volta a uma profundidade que esteja suficientemente distante na cadeia de blocos, o que geralmente exigirá apenas uma profundidade de duas transações. Todas as transações antes disso podem ser descartadas.


Os nós de registro de data e hora verificam as transações, certificando-se de que a transação anterior em uma moeda esteja na cadeia, reforçando assim a regra de que todas as transações na cadeia representam moedas válidas?


Certo, exatamente. Quando um nó recebe um bloco, ele verifica as assinaturas de cada transação nele em transações anteriores em blocos. Os blocos podem conter apenas transações que dependem de transações válidas em blocos anteriores ou no mesmo bloco. A transação C pode depender da transação B no mesmo bloco e B depende da transação A em um bloco anterior.

Desculpe por todas as perguntas, mas como eu disse, esta parece ser uma idéia muito promissora e original, e estou ansioso para ver como o conceito é desenvolvido. Seria útil ver uma descrição da idéia mais orientada para o processo, com detalhes concretos das estruturas de dados para os vários objetos (moedas, blocos, transações), os dados que são incluídos nas mensagens e descrições algorítmicas dos procedimentos para manipulação. os vários eventos que ocorreriam neste sistema. Você mencionou que está trabalhando em uma implementação, mas acho que uma descrição de texto mais formal do sistema seria um próximo passo útil.

Eu aprecio suas perguntas. Eu realmente fiz esse tipo de atraso. Eu tive que escrever todo o código antes que pudesse me convencer de que poderia resolver todos os problemas, então escrevi o artigo. Eu acho que serei capaz de liberar o código antes que eu possa escrever uma especificação detalhada. Você já está certo sobre a maioria de suas suposições, onde você preencheu os espaços em branco.

Satoshi Nakamoto


English Original Below


Cryptography Mailing List

Bitcoin P2P e-cash paper

2008-11-09 01:58:48 UTC Original Email - View in Thread

Comments

Popular Posts

Verasity Is The Best Attention-Based Video Rewards Model

LedgerX just launched the first physical Bitcoin futures contracts in the USA

What happened at the Bitcoin Conference 2019 San Francisco - Mamaecrypto

Brave Browser Download - What is Brave?