-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.
![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
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://bitcointalk.org/index.php?topic=3441.msg48384#msg48384Apenas 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://bitcointalk.org/index.php?topic=5178378.0A guy developing a game:
https://bitcointalk.org/index.php?topic=5172896.0Open source bot:
https://bitcointalk.org/index.php?topic=5172344.0Some TA:
https://bitcointalk.org/index.php?topic=4655945.0Government regulations (9 pages of good content):
https://bitcointalk.org/index.php?topic=5140353.0etc