-snip-
There's a
signature campaign running since 08/aug.. 10 posts/week, 9 members, for sure it helped.
There's a lot of good technical content that deserve more merits
eg
1Nem todas transações vão confirmar num longo período de tempo. Em 2016-2017 começaram a ser incluídos restrições mínimas no cliente do Bitcoin Core para não retransmitir transações sem taxas por exemplo. Alguns parâmetros são configuráveis mas outros precisam recompilar o cliente, o que raramente quem tem um node rodando vai fazer.
Transações que estão esperando ser confirmadas, são colocadas no "mempool" e podem ser tiradas de lá se o mempool fica muito cheio. Então caso não tenha pressa, é importante:
1. Usar o mínimo configurado de taxa que os nodes vão retransmitir (por default, o Bitcoin Core é 1000 satoshis por kbyte, ou 1 sat/byte)
1.1. Se você configurar o seu node E encontrar outros nodes e mineradores que tenham colocado uma taxa minima menor que isso (mas maior do que 0 sat por kbyte), "teoricamente" você pode ter uma transação confirmada em algum momento.
2. Sua transação precisa ser maior do que "poeira", ou seja o valor do output precisa ser maior do que a taxa necessária para gastar. Isso significa >546 sats para uma transação mais comum P2PKH na configuração tradicional do cliente Bitcoin Core.
3. Você precisa manter um node seu que iniciou a transação retransmitindo a mesma sempre que ela for retirada do mempool. Quando o volume de transações não confirmadas aumenta, as que tem menores taxas são excluídas da maior parte dos nodes. Se o seu node não ficar retransmitindo, a transação some da rede.
2Sim, o agendamento é possivel no BTC. Você utiliza um "lock time" e especifica que a partir de tal bloco a transação será válida para ser adicionada na blockchain - basicamente os mineradores não aceitam a transação até chegar no bloco especificado.
Assim, uma transação no dia 03 de dezembro ocorrerá em aproximadamente 15120 blocos, a partir da data de hoje.
144 * 105 = 15120 blocks ( número de blocos por dia x números de dias = número de blocos)
590985 ( bloco atual) + 15120 (blocos até o dia 03/12/19) = 606105 blocks (bloco no dia 03/12/19)
Dessa forma, ao especificar um "lock time" para o bloco 606105 e enviar 1 BTC para a Alice a transação apenas será aceita no dia 03/12/2019, data em que a transação será incluída na blockchain pelos mineradores.
O lock time de uma transação poderia ser realizada por meio da edição de uma raw transaction utilizando:
https://live.blockcypher.com/btc/decodetx/https://blockstream.info/tx/push 3SIM - existem dois tipos de transação que você pode fazer:
1. nLockTime: uma transação que só se torna válida após uma certa altura do blockchain (número do block) e alguém precisa guardar a transação e só colocá-la na rede depois que passar esse tempo.
O cenário aqui é: Alice promete transferir para Bob 1 BTC daqui 1000 blocos (~7 dias) e cria uma transação colocando o nLockTime = Bloco Atual + 1000
Bob recebe uma mensagem da Alice com o conteúdo dessa transação assinada e pode colocar ela na rede só depois de 7 dias, para ela ser efetivada.
Se Bob colocar essa transação antes na rede, vai estar inválida/vai ser ignorada.
Se Alice criar uma outra transação reutilizando os inputs da transação que foi para o Bob, quando Bob tentar executar a transação, vai dar errado.
Se alguma coisa acontecer com Alice, Bob ainda consegue receber o 1 BTC daqui 7 dias.
Esse cenário já foi utilizado algumas vezes como um "dead-man switch" ou tipo de testamento onde alguém fica com uma transação no futuro que permite receber seus bitcoins, mas se você quiser, pode mover eles antes e invalidar essa transação futura.
2. CLTV = CheckLockTimeVerify: uma transação que trava os outputs (bitcoins) por um tempo pre-determinado.
O cenário aqui é: Alice promete transferir para Bob 1 BTC *agora* mas que Bob só poderá gastar depois 1000 blocos (~7 dias).
A transação é executada na rede e Bob "recebe" 1 BTC, mas não pode fazer nada para gastar eles antes do LockTime passar.
Alice também não consegue pegar esse 1 BTC de volta.
Você consegue fazer isso usando o Bitcoin Core mas montando a transação na mão (não tem telas para isso).
Não sei de outro client que permite fazer isso com telas...
4Eu já fiz isso.
Pra quem quiser, dê uma olhada no
https://coinb.in/#newTimeLocked - você consegue criar um endereço que só permite gastos após X data ou X número de blocos. Coloquei uma data para 6 meses adiante e me forcei um hold.
5É um tipo de ataque de "gasto-duplicado" (double spending). Foi teorizado por Hal Finney:
https://bitcointalksearch.org/topic/m.48384Apenas um minerador conseguiria fazer isso. Porque ele precisa:
1. Ter o resultado de mineração de um bloco, incluindo uma transação que envia bitcoins dele (A) para ele mesmo (B) (sem publicar essa transação na rede). Mas não propaga o bloco novo ainda.
2. Envia uma transação de pagamento com os bitcoins que estão em (A) para algum vendedor que aceite não esperar nenhuma confirmação.
3. Depois que o vendedor aceita o pagamento e entrega o serviço/produto (provavelmente digital), o minerador propaga o bloco novo onde ele invalida a transação que o vendedor recebeu.
6Mas ai vc inviabiliza o registro e informações na blockchain, não? Uma operação de op_return transaciona zero alemda taxa.
Não sei se entendi sua pergunta. Uma transação de op_return deixa o output "unspendable" (= queima), então acredito que ele não precisa ser maior do que "dust" pois não pode ser reutilizado mesmo.
Então, o sabotag3x perguntou:
E um dust attack no qual o montante transacionado é menor do que a taxa?
Num op_return para registro de dados vc vai querer usar o menor output possivel (ou colocar tudo como fee). O "montante transacionado", ou montante queimado no caso, vai ser sempre menor que a taxa (podendo ser até 0).
Entendo que a regra continua a mesma: um *output* válido precisa ser spendable = ser maior que o limite de dust para a transação ser aceita.
Se uma transação quer colocar um OP_RETURN, existem duas opções:
1. faz uma transação com apenas um OP_RETURN, queimando qualquer bitcoin além da taxa (ou colocando apenas o suficiente para a taxa). Isso não gera nenhum output válido, então a transação é aceita.
2. faz uma transação com um OP_RETURN e um output recebendo o valor acima de dust. A transação é aceita porque, dentre os outputs válidos, o valor desse output é maior que dust.
Se tentar fazer uma transação com OP_RETURN E um output abaixo do dust, a transação vai ser negada.
Discussion about full nodes:
https://bitcointalksearch.org/topic/full-nodes-importancia-para-rede-criacao-de-1-fullnode-5178378A guy developing a game:
https://bitcointalksearch.org/topic/feedback-game-educativo-de-criptomoedas-para-os-gamers-5172896Open source bot:
https://bitcointalksearch.org/topic/bot-open-source-e-free-arbitragem-com-triangulacao-dentro-da-binance-5172344Some TA:
https://bitcointalksearch.org/topic/oficial-tradingview-bitcoin-e-altcoin-4655945Government regulations (9 pages of good content):
https://bitcointalksearch.org/topic/agora-e-lei-corretoras-e-tambem-usuarios-deverao-prestar-contas-a-receita-5140353etc