pianeiro on Nostr: Aos bitcoiners de plantão! Estou fazendo algumas análises de dados em relação ao ...
Aos bitcoiners de plantão!
Estou fazendo algumas análises de dados em relação ao Bitcoin e vou incluir uma variável com o total REAL de BTC em circulação -- onde "real" é o total minerado excluídos aqueles saldos em carteiras perdidas para sempre, incluindo aí as "carteiras malditas", como as do Satoshi. Em suma, a ideia, é ponderar o total minerado pela quantidade de BTC que realmente está propenso a ser transacionado.
Aos puristas, eu sei que ninguém tem esse valor.
Isto posto, modelarei uma aproximação a partir de hipóteses razoáveis e realizando uma espécie de meta análise de levantamentos já realizados (como os da Chainanalysis, Glassnode, Timothy Peterson, General Estimates, etc.). Irei unir todos os levantamentos, normalizados por data/bloco -- ou qualquer eixo X que o valha -- regridirei uma curva que "cuspirá" uma estimativa y, onde: 0 >= y >= 1, referente ao percentual de bitcoins perdidos para ponderar o total teórico.
A principal hipótese que vou assumir, e da qual estou praticamente certo de sua razoabilidade mas que venho por à prova, submetendo à análise de vocês, que têm mais vivência com o BTC do que eu, é a seguinte: partir do princípio que a quanto mais antigo o BTC, maior a propensão de ele ter sido perdido. Isso significa que, para datas/blocos mais antigos, o percentual de BTCs perdidos em relação ao total minerado acaba sendo maior e, com o passar do tempo, esse percentual vai diminuindo. Vou testar várias formas fcuncionais para ver a que retorna mais ajuste aos levantamentos, mas apósto que é 1/ln (log neperiano inverso).
E então, o que me dizem? Minha suposição é: "certamente correta", "provavelmente correta", "provavelmente incorreta" ou "certamente incorreta"? Caso tenham apontamentos a realizar, sintam-se a vontade.
Desde já, obrigado a quem contribuir...
Published at
2025-03-23 18:03:49Event JSON
{
"id": "d6bf6d6bfa4b80fcb3b993eec9d36273eb084a8f5c8b044d88933d8efca32ee3",
"pubkey": "e56993b3ed313ef502ff7fb64fc8b7d2acf789af6a094966a8cc615b62c8672e",
"created_at": 1742753029,
"kind": 1,
"tags": [],
"content": "Aos bitcoiners de plantão!\n\nEstou fazendo algumas análises de dados em relação ao Bitcoin e vou incluir uma variável com o total REAL de BTC em circulação -- onde \"real\" é o total minerado excluídos aqueles saldos em carteiras perdidas para sempre, incluindo aí as \"carteiras malditas\", como as do Satoshi. Em suma, a ideia, é ponderar o total minerado pela quantidade de BTC que realmente está propenso a ser transacionado.\n\nAos puristas, eu sei que ninguém tem esse valor. \n\nIsto posto, modelarei uma aproximação a partir de hipóteses razoáveis e realizando uma espécie de meta análise de levantamentos já realizados (como os da Chainanalysis, Glassnode, Timothy Peterson, General Estimates, etc.). Irei unir todos os levantamentos, normalizados por data/bloco -- ou qualquer eixo X que o valha -- regridirei uma curva que \"cuspirá\" uma estimativa y, onde: 0 \u003e= y \u003e= 1, referente ao percentual de bitcoins perdidos para ponderar o total teórico.\n\nA principal hipótese que vou assumir, e da qual estou praticamente certo de sua razoabilidade mas que venho por à prova, submetendo à análise de vocês, que têm mais vivência com o BTC do que eu, é a seguinte: partir do princípio que a quanto mais antigo o BTC, maior a propensão de ele ter sido perdido. Isso significa que, para datas/blocos mais antigos, o percentual de BTCs perdidos em relação ao total minerado acaba sendo maior e, com o passar do tempo, esse percentual vai diminuindo. Vou testar várias formas fcuncionais para ver a que retorna mais ajuste aos levantamentos, mas apósto que é 1/ln (log neperiano inverso).\n\nE então, o que me dizem? Minha suposição é: \"certamente correta\", \"provavelmente correta\", \"provavelmente incorreta\" ou \"certamente incorreta\"? Caso tenham apontamentos a realizar, sintam-se a vontade.\n\nDesde já, obrigado a quem contribuir...",
"sig": "9eba97f487089b84d6501fc8ed8ae42fc01a297479273829117e70f3cc216fc0be2e8afa61863c353657f4e15d09f204f4f272a110b8823f7f53f5a771c63d41"
}