O que é o seed-otp?
Como posso me beneficiar dessa feature e como ela pode ser útil?
Quais suas vantagens e desvantagens?
Quais são as suas limitações técnicas?
Topic: Bitcoin - Perguntas e Respostas. (Read 33969 times)
É uma maneira de definir, descrever conjuntos de chaves públicas e condições de resgate que podem ser utilizadas para gastar fundos em uma transação. Isso é útil para facilitar a criação de um grande número de endereços a partir de uma única semente.
Em resumo, são uma ferramenta para melhorar a segurança/flexibilidade das carteiras HD, permitindo gestão de fundos e dos gastos delas
Output descriptors no meu entendimento é você descrever para a carteira na forma de scripts exatamente como você quer quer ela deriva as chaves públicas ou privadas e de qual derivation path, tipo de endereço e etc a carteira deve recuperar. Porque se formos parar pra pensar, somente a seed-phrase não é uma informação suficiente na hora da restauração, tudo bem que a maioria segue o padrão BIP44 ou BIP84 e entre outros, pois esses derivation paths são quase que consenso em praticamente todas as carteiras, então essas carteiras pulam a parte técnica do usuário para que ele não precise lidar com essas informações na hora de criar ou recuperar a sua carteira.Em resumo, são uma ferramenta para melhorar a segurança/flexibilidade das carteiras HD, permitindo gestão de fundos e dos gastos delas
Isso é necessário porque o BIP39 é muito aberto no que tange a sementes, enquanto que no padrão de sementes da Electrum, as sementes electrum carregam nela um número de versão que já indica qual tipo de endereço a Electrum deve informar, enquanto que nas sementes BIP39 possuí o checksum e a carteira ou o usuário que define qual o derivation path e o script de endereço deve ser criado.
Vou quotar aqui a definição de descriptor do dev do Bitcoin Core, o achow101:
A HD wallet is a wallet where the keys are derived in a reproducible way from a single source of randomness known as the seed. The most widely used method for deriving such keys is BIP 32. Since the seed is fairly small, it's easy to back that up and be sure that, in theory, you are able to re-compute all of your private keys in the future.
However, HD wallets make no mention of the type of addresses to create, nor do they specifically state which private keys you are actually using. These change on a wallet by wallet basis. While most wallets follow various standards for choosing which keys to derive and what address types to make from them, just having the seed and knowing that your wallet is a HD wallet is not enough to recover your funds.
Descriptor wallets expand on HD wallets by storing Descriptor strings which specify the keys and the address types to create. Descriptors utilize BIP 32 so that BIP 32 keys and derivation paths can be contained within them to specify the specific keys to use without actually enumerating all of the keys. Descriptors further introduced the script expression notation in order to specify the type of script, and ultimately the type of address, that a descriptor can create. Thus a descriptor is a more complete backup and leaves nothing up to guess work as it specifies both the exact keys to use, and the addresses to create from them.
Descriptors is intended to be a more general notation, so it is also possible to create descriptors which contain just private keys with no BIP 32 derivation at all. They can also be used to represent raw output scripts for cases where the script is nonstandard, and they can be used to create complex arbitrary scripts through the use of the MIniscript language.
Since Descriptor wallets can include BIP 32 derivation, descriptor wallets are basically a kind of HD wallet. But really, they are a superset of HD wallets since they do a lot more than just managing private keys.
A way to think about how these are different is the philosophy that they essentially represent. A HD wallet represents a keys first philosophy where the key is the king. Everything comes from the key - the key exists first, then the script is created from that key.
Conversely, Descriptor wallets represent a scripts first philosophy where keys are inserted afterwards. Descriptors describe a script template in which keys are later computed and inserted into the positions in the script as described by the descriptor. For descriptors, how the key is generated is not that important; they could be randomly generated and put in the descriptor string, or they can be generated from a BIP 32 key and derivation path. All that is required is that the key expressions produce individual keys that can be placed into scripts.
However, HD wallets make no mention of the type of addresses to create, nor do they specifically state which private keys you are actually using. These change on a wallet by wallet basis. While most wallets follow various standards for choosing which keys to derive and what address types to make from them, just having the seed and knowing that your wallet is a HD wallet is not enough to recover your funds.
Descriptor wallets expand on HD wallets by storing Descriptor strings which specify the keys and the address types to create. Descriptors utilize BIP 32 so that BIP 32 keys and derivation paths can be contained within them to specify the specific keys to use without actually enumerating all of the keys. Descriptors further introduced the script expression notation in order to specify the type of script, and ultimately the type of address, that a descriptor can create. Thus a descriptor is a more complete backup and leaves nothing up to guess work as it specifies both the exact keys to use, and the addresses to create from them.
Descriptors is intended to be a more general notation, so it is also possible to create descriptors which contain just private keys with no BIP 32 derivation at all. They can also be used to represent raw output scripts for cases where the script is nonstandard, and they can be used to create complex arbitrary scripts through the use of the MIniscript language.
Since Descriptor wallets can include BIP 32 derivation, descriptor wallets are basically a kind of HD wallet. But really, they are a superset of HD wallets since they do a lot more than just managing private keys.
A way to think about how these are different is the philosophy that they essentially represent. A HD wallet represents a keys first philosophy where the key is the king. Everything comes from the key - the key exists first, then the script is created from that key.
Conversely, Descriptor wallets represent a scripts first philosophy where keys are inserted afterwards. Descriptors describe a script template in which keys are later computed and inserted into the positions in the script as described by the descriptor. For descriptors, how the key is generated is not that important; they could be randomly generated and put in the descriptor string, or they can be generated from a BIP 32 key and derivation path. All that is required is that the key expressions produce individual keys that can be placed into scripts.
Valendo um mérit: o que é um descritor ou output descriptor e como esse recurso ajuda e melhorar o esquema de chaves públicas/privadas em uma carteira HD?
É uma maneira de definir, descrever conjuntos de chaves públicas e condições de resgate que podem ser utilizadas para gastar fundos em uma transação. Isso é útil para facilitar a criação de um grande número de endereços a partir de uma única semente.
Em resumo, são uma ferramenta para melhorar a segurança/flexibilidade das carteiras HD, permitindo gestão de fundos e dos gastos delas
Valendo um mérit: o que é um descritor ou output descriptor e como esse recurso ajuda e melhorar o esquema de chaves públicas/privadas em uma carteira HD?
Tem o famoso tweet "running bitcoin" de 11 de janeiro: https://twitter.com/halfin/status/1110302988
Também acho que o Satoshi tinha 2 computadores.. afinal ele deve ter testado o sistema antes de liberá-lo..
Legal esse trecho do código @Prancheiro, não conhecia!
edit: o e-mail ali é 11 de janeiro também, não fevereiro.
Tinha esquecido do tuíte!
O cara respondeu o email, baixou o código, botou pra rodar, ficou felizão e tuitou! Hehe
Valeu pela correção! Editei!
O Hal respondeu o email do Satoshi no dia 11 de Fevereiro
Tem o famoso tweet "running bitcoin" de 11 de janeiro: https://twitter.com/halfin/status/1110302988
Também acho que o Satoshi tinha 2 computadores.. afinal ele deve ter testado o sistema antes de liberá-lo..
Legal esse trecho do código @Prancheiro, não conhecia!
edit: o e-mail ali é 11 de janeiro também, não fevereiro.
Bacana. So falou a referencia do codigo.
Realmente está lá e faz sentido. Quem será que foi o segundo node? Finney? Será que tem registro disso no fórum? Ou foi o próprio saroshi?
https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp
Realmente está lá e faz sentido. Quem será que foi o segundo node? Finney? Será que tem registro disso no fórum? Ou foi o próprio saroshi?
https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp
Boa bitmover!
Acabei esquecendo de colocar o link do código da v01.
Até hoje não se sabe. Poderia ter sido o sirius (Martti Malmi), mas nunca deixou explícito.
O Hal respondeu o email do Satoshi no dia 11 de Janeiro e começa com "Congratulations to Satoshi on this first alpha release. I am looking
forward to trying it out." (Tradução livre: Parabéns a Satoshi por este primeiro lançamento. Irei experimentar em breve).
Então só se ele já estava rodando e tentou despistar na resposta.
https://www.mail-archive.com/[email protected]/msg10152.html
Eu chutaria que foi o próprio Satoshi que arrumou outro computador e começou a rodar!
Valendo 2 merits (e 1 para a resposta folclórica):
Por que o segundo bloco foi minerado 6 dias após o bloco gênesis?
Por que o segundo bloco foi minerado 6 dias após o bloco gênesis?
A teoria é que a versão original do Bitcoin de Satoshi só começaria a minerar se tivesse pelo menos mais um nó na rede. Assim, é possível que o nó do Satoshi estivesse em funcionamento quando o software foi publicado, mas só começou a minerar quando um segundo nó se juntou à rede.
Quote
while (fGenerateBitcoins)
{
Sleep(50);
CheckForShutdown(3);
while (vNodes.empty())
{
Sleep(1000);
CheckForShutdown(3);
}
Devs podem verificar se faz sentido o código acima (main.cpp - linhas 2191 - 2199).{
Sleep(50);
CheckForShutdown(3);
while (vNodes.empty())
{
Sleep(1000);
CheckForShutdown(3);
}
Perguntei pro ChaGPT e ele disse que sim! Haha
O Bitcoin 0.1 foi anunciado na lista de e-mails no dia 8 de janeiro às 19:27 UTC, e então só a partir daí um segundo nó poderia teria aparecido na rede. O bloco 1 (o segundo bloco) foi minerado em 2009-01-09 2:54 UTC, 7 horas e 27 minutos após o anúncio por e-mail.
Realmente está lá e faz sentido. Quem será que foi o segundo node? Finney? Será que tem registro disso no fórum? Ou foi o próprio saroshi?
https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp
Valendo 2 merits (e 1 para a resposta folclórica):
Por que o segundo bloco foi minerado 6 dias após o bloco gênesis?
Por que o segundo bloco foi minerado 6 dias após o bloco gênesis?
A teoria é que a versão original do Bitcoin de Satoshi só começaria a minerar se tivesse pelo menos mais um nó na rede. Assim, é possível que o nó do Satoshi estivesse em funcionamento quando o software foi publicado, mas só começou a minerar quando um segundo nó se juntou à rede.
Quote
while (fGenerateBitcoins)
{
Sleep(50);
CheckForShutdown(3);
while (vNodes.empty())
{
Sleep(1000);
CheckForShutdown(3);
}
Devs podem verificar se faz sentido o código acima (main.cpp - linhas 2191 - 2199).{
Sleep(50);
CheckForShutdown(3);
while (vNodes.empty())
{
Sleep(1000);
CheckForShutdown(3);
}
Perguntei pro ChaGPT e ele disse que sim! Haha
O Bitcoin 0.1 foi anunciado na lista de e-mails no dia 8 de janeiro às 19:27 UTC, e então só a partir daí um segundo nó poderia teria aparecido na rede. O bloco 1 (o segundo bloco) foi minerado em 2009-01-09 2:54 UTC, 7 horas e 27 minutos após o anúncio por e-mail.
Mais duas dicas:
- Apesar do bloco gênesis ter sido minerado dia 3 de Janeiro, o email anunciando a versão 0.1 do código foi enviado apenas dia 8 de janeiro;
- main.cpp (2191–2199);
- Apesar do bloco gênesis ter sido minerado dia 3 de Janeiro, o email anunciando a versão 0.1 do código foi enviado apenas dia 8 de janeiro;
- main.cpp (2191–2199);
O primeiro bloco foi "pré-minerado"? é essa a resposta? Satoshi é um scammer?
sabotag3x, joker_josue e Pumared
Ainda não é essa teoria.
Mais duas dicas:
- Apesar do bloco gênesis ter sido minerado dia 3 de Janeiro, o email anunciando a versão 0.1 do código foi enviado apenas dia 8 de janeiro;
- main.cpp (2191–2199);
Ainda não é essa teoria.
Mais duas dicas:
- Apesar do bloco gênesis ter sido minerado dia 3 de Janeiro, o email anunciando a versão 0.1 do código foi enviado apenas dia 8 de janeiro;
- main.cpp (2191–2199);
Dica: A mais aceita envolve algo no código!
A diff estava muito alta e ele precisou ajustar "na mão"? Pelo que lembro é isso, mas faz tempo que li algo sobre essa história.
Legal a história folclórica, não conhecia.. os caras já tratam bitcoin como religião, agora estão tratando Satoshi como deus
Também pensei nisso e na estabilidade de como estava funcionando. Ele deve ter resolvido isso em 4 dias e decidiu esperar até o dia 6 para poder calhar com o "evento religioso". Não acredito que ele tenha pensado nisso antes de realizar os testes na rede etc.
Dica: A mais aceita envolve algo no código!
A diff estava muito alta e ele precisou ajustar "na mão"? Pelo que lembro é isso, mas faz tempo que li algo sobre essa história.
Por acaso, acho que esse motivo seja o que faça mais sentido.
Provavelmente ele seria o único a minerar, ou havia só mais uma ou duas pessoas a faze-lo. Depois, eu duvido que ele tenha feito pausas na mineração, depois de lançar o Bitcoin. Acredito mesmo que foi uma questão de dificuldade, e ele teve de ir fazendo ajustes ao código, até chegar a um ponto de equilíbrio.
Dica: A mais aceita envolve algo no código!
A diff estava muito alta e ele precisou ajustar "na mão"? Pelo que lembro é isso, mas faz tempo que li algo sobre essa história.
Legal a história folclórica, não conhecia.. os caras já tratam bitcoin como religião, agora estão tratando Satoshi como deus
Satoshi estava testando o sistema, talvez ?
ou então... estava sem luz. ou sem internet rsrs, ou deixou o PC desligado
ou então... estava sem luz. ou sem internet rsrs, ou deixou o PC desligado
Tem essa tese! Que como ele estava trabalhando sozinho, então teve que fazer alguns ajustes no código depois do primeiro bloco e portanto sobrava pouco tempo pra minerar.
Mas tem outra tese com mais evidências!
Lembrando que não existe resposta correta pois o Satoshi nunca explicou isso, então o que existem são suposições baseadas em evidências!
Dica: A mais aceita envolve algo no código!
A resposta folclórica eu sei (aliás, acho que sei
)Seria uma referência da Bíblia, onde o mundo foi criado em 6 dias e o criador descansou no 7º
E essa passagem também seria do Gênesis
Exato! Haha
Valendo 2 merits (e 1 para a resposta folclórica):
Por que o segundo bloco foi minerado 6 dias após o bloco gênesis?
Por que o segundo bloco foi minerado 6 dias após o bloco gênesis?
A resposta folclórica eu sei (aliás, acho que sei
)Seria uma referência da Bíblia, onde o mundo foi criado em 6 dias e o criador descansou no 7º
E essa passagem também seria do Gênesis
Se não for isso, estou curioso pra saber haha
Agora a parte técnica, eu acredito que era para testar a estabilidade da blockchain, mas não tenho certeza
Valendo 2 merits (e 1 para a resposta folclórica):
Por que o segundo bloco foi minerado 6 dias após o bloco gênesis?
Por que o segundo bloco foi minerado 6 dias após o bloco gênesis?
Satoshi estava testando o sistema, talvez ?
ou então... estava sem luz. ou sem internet rsrs, ou deixou o PC desligado
Valendo 2 merits (e 1 para a resposta folclórica):
Por que o segundo bloco foi minerado 6 dias após o bloco gênesis?
Por que o segundo bloco foi minerado 6 dias após o bloco gênesis?
Nessa situação, não seria melhor ter vários endereços, apesar de que, quando for necessário mover, será pago um valor a mais. Acho que ao ter vários endereços fica mais "privado". Ou estou errado?
A quantidade de endereços não interfere diretamente no valor da transação. Mas sim a quantidade de inputs
Um mesmo endereço pode ter dezenas ou centenas de inputs. Esses que estão falando em consolidar.
Para questões de privacidade sim, ter vários endereços, destinados para cada objetivo, aumenta a privacidade.
Para poupar taxas, conseguir ter o menos inputs possíveis, para movimentar o dinheiro pretendido.
Pessoalmente acho mais fácil gerir os endereços por questões de privacidade. E depois consolidar os inputs de endereços que tem muito movimento, com onde eu recebo o BTC da assinatura.
Também vejo dessa forma, gerir o endereço focado na privacidade. Pois acho que vai vir muita coisa em relação a monitoramento da receita futuramente. Então é interessante se preparar.
Nessa situação, não seria melhor ter vários endereços, apesar de que, quando for necessário mover, será pago um valor a mais. Acho que ao ter vários endereços fica mais "privado". Ou estou errado?
A quantidade de endereços não interfere diretamente no valor da transação. Mas sim a quantidade de inputs
Um mesmo endereço pode ter dezenas ou centenas de inputs. Esses que estão falando em consolidar.
Para questões de privacidade sim, ter vários endereços, destinados para cada objetivo, aumenta a privacidade.
Para poupar taxas, conseguir ter o menos inputs possíveis, para movimentar o dinheiro pretendido.
Pessoalmente acho mais fácil gerir os endereços por questões de privacidade. E depois consolidar os inputs de endereços que tem muito movimento, com onde eu recebo o BTC da assinatura.
Jump to: