Quote from: DdmrDdmr on September 17, 2019, 03:10:39 PM

-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
1

Quote from: dive on August 18, 2019, 09:46:33 PM

Nem 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.

2

Quote from: Alveus on August 20, 2019, 05:01:43 PM

Sim, 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.

Code:

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

3

Quote from: dive on August 20, 2019, 05:25:02 PM

SIM - 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...

4

Quote from: TryNinja on August 20, 2019, 05:53:41 PM

Eu 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

Quote from: dive on August 23, 2019, 07:47:06 PM

É um tipo de ataque de "gasto-duplicado" (double spending). Foi teorizado por Hal Finney: https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384

Apenas 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.

6

Quote from: dive on September 05, 2019, 11:17:24 PM

Quote from: girino on September 04, 2019, 10:51:53 PM

Quote from: dive on September 04, 2019, 08:11:43 PM

Quote from: girino on September 04, 2019, 03:50:22 AM

Quote from: dive on September 04, 2019, 01:46:12 AM

Quote from: sabotag3x on September 03, 2019, 11:38:32 PM

E um dust attack no qual o montante transacionado é menor do que a taxa?

Para esse precisa modificar o código e recompilar:
https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp#L14

Mas 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:

Quote from: sabotag3x on September 03, 2019, 11:38:32 PM

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.0

A guy developing a game: https://bitcointalk.org/index.php?topic=5172896.0

Open source bot: https://bitcointalk.org/index.php?topic=5172344.0

Some TA: https://bitcointalk.org/index.php?topic=4655945.0

Government regulations (9 pages of good content): https://bitcointalk.org/index.php?topic=5140353.0

etc