 Show Posts
|
|
Pages: [1]
|
Para aqueles que ainda não sabem o que é a lightning network: https://bitcointalk.org/index.php?topic=1968479.0 A Eclair permite o uso da LN por meio de um app sem a necessidade de um full node, e por causa disso ela ainda tem certas desvantagens por enquanto, a principal delas seria o fato de você não conseguir receber pagamentos com ela. (canais unidirecionais). Sobre as aplicações para desktop existentes, nenhuma delas permite que faça o uso dela sem um full node local configurado, o que é um grande obstáculo, principalmente em aplicativos móveis. * Com o desenvolvimento dessas wallets, é de se esperar que essas limitações disapareçam, igual as lightweight wallets atuais (como o Electrum) em relação aos full node wallets. Depois de alguns testes na versão testnet do aplicativo deles, resolvi testar ela fazendo compras de verdade na mainnet, e aqui estão os resultados: Antes de começar, o uso da LN na mainnet não é recomendada a ninguém por enquanto, faça por sua conta e riscoConfiguração inicial e a abertura de um canal de pagamento Criar uma carteira e enviar bitcoins foi igual a qualquer outra carteira, você precisa gerar e guardar a seed e depois configurar uma senha PIN para proteger ela, depois é só enviar bitcoins para o endereço fornecido. Agora a parte da abertura do canal é algo que deve ser feita cuidadosamente, no app você tem a opção de criar um canal com o nó do ACINQ (desenvolvedores do Eclair wallet) ou conectar com um nó de sua escolha (você precisa copiar e colar a identificação do nó, que tem formato chave_pública@ip:porta). Agora algo importante nessa escolha do nó é lembrar-se de que o dinheiro do seu pagamento chegará até o destinatário por meio das conexões dos nós conectados a você, então se você se conecta só a um nó não confiável que fica offline facilmente, você terá riscos de não conseguir enviar o dinheiro na hora de fazer o pagamento. Para testar eu enviei apenas 0.003 BTC para a wallet, e sem esperar que ela a confirmação dela já fui criando a transação de abertura de canal com o nó do ACINQ (obrigado por permitir esses tipos de mágicas acontecerem Segwit). Acabei decidindo em usar todos os meus fundos nela (0.0029, deixei um resto na carteira para pagar a transação e deixar um número melhor dentro do canal), acabei usando os 3 sat/byte recomendado por eles, gasto de 528 satoshis por enquanto. Fazendo o primeiro pagamento A partir de agora, as fees pagas nas transações seriam apenas as fees cobradas pelos nós no caminho do meu nó para o nó do destinatário, e por enquanto uma grande parte dos nós não está cobrando nada para fazer esse roteamento, e quando cobra geralmente é algo representativo como 3 sat/transação (a transação não vai passar por mais que 5 nós na rede atual). Irei criar um review de alguns serviços que aceitam a LN nos comentários, para fazer os pagamentos a opção de QRCode funciona bem. Para fazer o primeiro teste quis utilizar o serviço do Bitrefill, que faz recargas de celular (vários países) e vende gift cards, indiretamente já é possível comprar na Amazon utilizando a LN, testei com uma recarga de 8 reais em um número antigo que eu tinha. Ao fazer o pagamente a transação, que era para ser instantânea, simplesmente travou no estado de "Pending" na wallet, e o que aconteceu foi justamente o que avisei sobre, o nó da ACINQ simplesmente resolveu dar uma parada quando eu estava fazendo o pagamento, por sorte depois de 2 horas a transação foi rejeitada pela rede e não perdi nada. Resolvi fazer a minha segunda tentativa. Na minha segunda tentativa eu resolvi abandonar o nó da ACINQ (vingança ou prevenção, o que você achar melhor), e conectei ao nó da SatoshiLabs ("dono" da Trezor, é fácil achar a identificação do nó deles na internet). Acabei gastando uma transação para fechar o canal anterior ( -510 sat em fees) e outra para abrir o novo canal ( -810 sat em fees, por juntar duas inputs na transação ficou mais caro que a abertura do primeiro canal). Fiz a segunda tentativa, e foi aprovada em segundos no celular, mas dessa vez quem quis dar problema foi a Bitrefill, que chegou a reconhecer a transação mas disse que os fundos não chegaram a eles (?), por sorte novamente, eles já contavam com um sistema pronto para enviar os fundos de volta (sem LN dessa vez). Persistente, fiz uma terceira tentativa, novamente o mesmo erro, parei por aqui ( - ~9 satoshis nas duas transações). Resolvi testar outro serviço então, o SatoshiTweet, que cobra para você criar um tweet na conta deles. Gerei o QRCode de pagamento de novo e enviei o dinheiro, dessa vez aceito de primeira e imediatamente, gastando apenas 1210 satoshis + 1,122 satoshis em taxa para o roteamento da transação (<1 sat para quem ficou confuso com a vírgula): Para o post não ficar extenso demais, vou colocar outras reviews abaixo (até porque ainda estou fazendo). Conclusão Fazendo as contas, numa situação ideal eu teria gastado apenas os primeiros 528 satoshis na abertura do primeiro canal, e os 1221 satoshi da compra feita, e considerando que não fechei o canal, a partir da segunda compra o total de taxas gastos já seriam quase a metade do que usando transações on-chain. Agora considerando uma situação real, como a minha ( 3068 satoshis por uma compra), você poderia facilmente perder todos os seus fundos a qualquer hora, por isso ainda é difícil dizer que já podemos ter uma solução para o problema da escalabilidade do bitcoin, mas com certeza no futuro a LN vai dar uma boa ajuda na rede no futuro. Estou começando a testar a lightning network com um full node em um servidor VPS, devo escrever sobre assim que estiver tudo funcionando e eu estiver com um tempo livre. Tentarei |
|
|
|
 A venda privada dos tokes CCX começará oficialmente no dia 17 de setembro de 2018!
Crypto Circle X é baseado em um algoritmos tecnológico e superior que é capaz de fazer mais de 10 milhões de transações por segundo com alta performance, bots com AI, auto-trading, gráficos profissionais com análises técnicas, alertas relaxionados ao trading, e muito mais, em uma interface amigável e responsiva e amigável ou no nosso aplicativo feito especificamente para plataformas móveis.
O que nos faz diferentes? A abordagem do Crypto Circle X é construir um ecossistema centrado na necessidade dos usuários. Nós queremos criar uma exchange de criptomoedas confiável e segura que foca primeiramente na velocidade, segurança, escalabilidade, e um serviço de atendimento 24h ao consumidor.  Sobre a Crypto Circle X
Crypto Circle Exchange é a exchange de criptomoedas mais avançada e segura alimentado por uma tecnologia de ponta que é capaz de processar mais de 10 milhões de transações por segundo. Nossos clientes dependem de nós, assim como dependemos deles. Em um mundo cooperativo, isso nunca foi tão transparente como agora, quando se lida com a nossa exchange. Nós queremos que os outros olhem no nosso logo, e lembrem instantaneamente nossa conexão com os nossos clientes. |
|
|
|
Grande correlação com o problema do knapsack, leia antes aqui, e se não gostou, não tente continuar a ler este. No fundo este problema é muito menos importante e menos discutido do que o problema do knapsack, mas mesmo assim vale a pena dar uma olhada. Segundo a Wikipedia: "Na teoria dos grafos, um conjunto independente de um grafo G é um conjunto S de vértices de G tal que não existem dois vértices adjacentes contidos em S. Em outras palavras, se a e b são vértices quaisquer de um conjunto independente, não há aresta entre a e b. [...] Se S é um conjunto independente de G e não existe um conjunto independente de G maior que S, diz-se que S é um conjunto independente máximo de G." Provavelmente você não entendeu a explicação nada simples acima, então resumindo o problema: o nome do problema é conjunto independente máximo (maximum independent set problem) e se resume a um grafo, que é um monte de vértices e arestas juntos, um conjunto independente é aquele que não existem dois vértices "vizinhos" (compartilhando uma mesma aresta) no conjunto, e queremos escolher um conjunto independente tal que maximize seu tamanho. Na imagem acima, as bolinhas coloridas são os vértices, os traços pretos são as arestas, e representa 1 grafo e 6 modos diferentes de escolher conjuntos independentes (apenas os vermelhos) nesse grafo, e apenas 2 são soluções para este problema (tente descobrir quais são). Este problema também é um problema NP-completo, igual o knapsack, e agora que você provavelmente entendeu os dois problemas, vai um fato curioso: existem 21 problemas nessa classificação, todos bastante diferentes assim como este em relação ao problema do knapsack, e mesmo assim, resolvendo um deles você automaticamente está resolvendo todos ao mesmo tempo. Certo, e o que isso tem a ver com o Bitcoin ? É possível separar o problema em duas partes, ambos relacionados a incluir a transação no bloco: 1) Conflito entre transações tentativas de gasto duplo: Se existem várias transações tentando usar o mesmo dinheiro dizemos que as transações estão conflitando entre si, e então criamos um grafo onde cada vértice é uma transação e cada aresta entre A e B quer dizer que A e B estão em conflito entre si. E então apenas resolvemos o problema descrito acima (maior conjunto = mais transações = quase_sempre_mais_dinheiro). 2) Transações que dependem do saldo de uma outra transação não confirmada: Nesse caso o problema é de dependência, se a transação B usa o dinheiro da transação A, ambas não confirmadas, e eu quiser colocar a transação B no bloco, eu devo colocar a A obrigatoriamente. Colocar este problema junto com o item 1) em um grafo exige um pouco mais de teoria, mas acredite quando eu digo que este problema fica mais fácil se "incorporado" ao item 1) . Então basicamente o problema com as transações agora é questão de bloco válido ou não, e não apenas uma questão de lucro adicional como tínhamos no problema do knapsack. Certo, e como se resolve isso ? Um ponto muito importante nisso tudo é que devemos lembrar que transações de gasto duplo são extremamente raras (os nodes/carteiras já têm um sistema que impede de ficar recebendo/mandando um monte de transações de gasto duplo). E sobre as dependências entre transações temos que elas são mais simples de calcular se você não tiver o problema de conflito (gasto duplo), bastando que se a B depende da A o minerador trata a B como se fosse um "A+B" (bytes A + bytes B + fee A + fee B), o que na verdade faz com que o knapsack problem fique um pouco mais difícil, mas o algoritmo guloso simplesmente ignora isso. Então diferentemente do problema do knapsack, onde os mineradores simplesmente faziam uma escolha simples que já rende um lucro próximo ao máximo, o maximum independent set problem pode ser simplesmente calculado com algum algoritmo lento, já que os números são muito baixos. Conclusão Este é um problema NP-completo que os mineradores simplesmente não resolveram, simplesmente a ignoraram e mesmo assim temos a solução perfeita. Quem sabe se um dia o mesmo conseguirem fazer o mesmo em relação ao knapsack problem ? parte um pouquinho mais técnica para os curiosos: Eu acho que este post já possui informação demais pra ser absorvida, se quiser mais mesmo leia mais nos links abaixo. Fontes: https://pt.wikipedia.org/wiki/Conjunto_independentehttps://en.wikipedia.org/wiki/Maximal_independent_sethttps://freedom-to-tinker.com/2014/10/27/bitcoin-mining-is-np-hard/ |
|
|
|
Segundo a Wikipedia: " O problema da mochila (em inglês, Knapsack problem) é um problema de otimização combinatória. O nome dá-se devido ao modelo de uma situação em que é necessário preencher uma mochila com objetos de diferentes pesos e valores. O objetivo é que se preencha a mochila com o maior valor possível, não ultrapassando o peso máximo." E o legal deste problema é que faz parte de um dos 21 problemas NP-completos que se você conseguir criar um algoritmo que consiga resolve-los rapidamente (os algoritmos atuais são extremamente lentos), você pode clamar por um premio de 1 milhão de dólares proposto por uma universidade, além de criar uma nova era para matemática e da computação, e consequentemente ferrando uma boa parte dos algoritmos criptográficos que temos hoje em dia... Certo, e o que isso tem a ver com o Bitcoin ? Bem, pra fazer essa ligação é preciso antes lembrar de algumas coisas: 1) Os blocos de mineração só comportam 1MB de informação (ou 4 milhões de weight units, mas isso não tem relevância agora). 2) Os mineradores podem escolher as transações que irão colocar no bloco, e irão ganhar as taxas de transação delas. Ou seja, os mineradores escolhem quais transações colocar no bloco, dependendo de seu tamanho e suas taxas. Ok, e o que tem de mais nisso ? Bom, antes de explicar como é resolvido o problema do knapsak, é preciso entender a verdadeira dificuldade de resolver ela. Então já colocando ela no contexto do Bitcoin, olhe este exemplo: Digamos que o minerador tenha apenas essas 4 transações na sua mempool:
1) 300 kbytes com 300 sat de fee (1sat/kbyte)
2) 500 kbytes com 600 sat de fee (1.2sat/kbyte)
3) 600 kbytes com 800 sat de fee (1.33sat/kbyte)
4) 200 kbytes com 400 sat de fee (2sat/kbyte)
A solução trivial seria simplesmente pegar as transações com o maior sat/byte e escolher elas até que o bloco fique cheio, mas nesse caso vemos que seria as opções 4 e 3 (400+800 =1200 sat), enquanto que a solução ótima seria escolher as opções 1, 2 e 4 (300+600+400 =1300 sat), ou seja, a coisa não é tão simples quanto parece. Se o problema é tão difícil de resolver, como os mineradores o fazem ? A solução atual que temos para este problema faria impossível de o minerador montar o bloco dele e achar o hash do PoW em um tempo bom o suficiente para competir com os outro, então o que o minerador faz é simplesmente ignorar ele e fazer a escolha gulosa: pegar as transações com o maior sat/byte e ignorar uma possível escolha melhor. Mas por que ? Eles não querem saber de mais dinheiro ? Sim, por isso mesmo, tempo=dinheiro, levando em conta que o bloco dá 12.5 BTC de "prêmio" e que as taxas de transação nao passam de uns 5 BTC, e que calcular a escolha ótima simplesmente demora e o ganho extra seria bem pequeno (sei lá, estimo que 1 BTC no máximo ?), simplesmente vale a pena só caçar o hash com os zeros e incluir as transações no bloco só quando conseguem. UPD: um ótimo exemplo de que os mineradores não estão muito aí para as taxas são os aceleradores de transação, que colocam a sua transação no bloco mesmo não tendo a melhor taxa (marketing). Conclusão No futuro, quando a geração de bitcoins realmente se tornar escassa, aí sim teríamos que pensar em como resolver melhor este problema, mas por enquanto isso é algo menos preocupante que a computação quântica. E mais, não resolver este problema ainda é uma ótima ideia para o bitcoin, já que isso incentiva aos usuários a escolher taxas sempre maiores, estimulando a competitividade e fazendo com que aquelas transações com 0.1sat/byte simplesmente não seja confirmada por "sorte". parte um pouquinho mais técnica para os curiosos: O cálculo do knapsack 0-1 descrito tem uma complexidade de O(nW), onde n é o número de objetos (transações), e W é o tamanho da mochila (1.000.000 bytes), e uma média boa de transações não confirmadas é de 5000. Ou seja, o algoritmo teria que fazer 5000*10^9 operações, e supondo que um computador faça ~10^9 cálculos por segundo, temos 5000 segundos > 1 hora só para calcular a montagem do bloco (o cara ainda tem que calcular os hashs depois). Já o cálculo do algoritmo guloso tem uma complexidade de O(nlogn), que dá 5000*10 = 5*10^4 operações, que acarreta em um tempo < 1 segundo de cálculo. É claro que existem otimizações nisso, se alguém quiser discutir sobre elas sinta se a vontade. Fontes: https://pt.wikipedia.org/wiki/Problema_da_mochilahttps://en.wikipedia.org/wiki/Knapsack_problemhttps://freedom-to-tinker.com/2014/10/27/bitcoin-mining-is-np-hard/
|
|
|
|
This post was initially written in Portuguese (see here), and I first wrote because there is very little documentation about the segwit written in other languages, but I still think it's good to post here. Sorry for any english errors. It is an "update" that has had on the bitcoin network, opening doors for lighter, faster and cheaper transactions and also enabling the implementation of protocols such as lightning network. More technical explanation: It is a soft-fork (BIP 141) that changes the concept of block size, putting the concept of 'weight unit' (explained later). Providing a temporary solution to the problem of scalability and the problem of malleability in transactions (also explained later). Faster and cheaper transactions? The answer to this is depends, creating more "cheap" transactions is only possible with the new types of address (see below), and even so, the speed for your transaction to be confirmed depends on other factors, such as miners and mempool (basically the transactions of others that were not confirmed). New formats of address There are currently three address formats in use: Legacy (P2PKH): These are the "old" formats, they start with the digit '1' and if you use them you continue as before, paying as before, nothing changes for you (taking the fact that you are outdated - so please use the "new" formats). eg: 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 P2SH (nested Segwit): They are the best for the moment, start with the digit '3' (remember the multisig wallets), with them you will have the same compatibility of the Legacy type, but with the advantage of creating witness transactions. The rate savings are around 27% (depends on the inputs and outputs). To use this format in the wallets, know that most have already adopted this one by default. (see how to create this type of address on electrum here) eg: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy Bech32: Theoretically they are much better than the two mentioned above, it starts with "bc1", this type have the advantage of being better readable to the human (it only has lowercase letter), which avoids typing errors and also allow the autocomplete of the wallets and a smaller QRcode for addresses of that type. And the main thing: they do witness transactions with a much higher rate of savings, around 38% (again this depends on the inputs and outputs). The problem? almost no service recognizes this as a bitcoin address, which brings a serious compatibility problem. (if you want to use this type, the Electrum wallet already offers this). eg: bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdqWhy encourage the use? If you are already using a segwit address (P2SH or bech32), and you are sending money you received from another segwit address (segwit-> you-> other), then you will have a lower transaction fee than someone who is using a segwit address by spending money that came from a legacy (a "legacy input") (legacy-> you-> other) address. Again, if you are using a legacy address nothing will change, but if everyone uses only segwit, the advantages will be greater. If you've read so far you already have all the essential information about Segwit, read on only if you have technical curiosities about how segwit really works What are "weight units"? With the activation of Segwit, the old unit of measurement bytes became obsolete, and the units vbytes and weight unit were introduced, the relation between them is of 1 weight unit = 4 vbytes, and in the new sizes of the blocks it was 4 millions of weight units per block. Has the block size not increased ? Would not that be a hard-fork ? No, because from this change in the blocks, the way of measuring the size of transactions also changed, and in legacy transactions (old) the value of byte also changed to that is, a transaction of 300 bytes is now 300 vbytes, which actually amounts to 300 * 4 = 1200 weight units , which occupies the same percentage of space in blocks as before. Now, in the transactions created using Segwit this changes completely. The "witness" transactions Basically, when you create a transaction using segwit, the size of the transaction decreases, but if you are thinking that it is because they are fully measured in weight units , you are also wrong, what these new addresses they can do is write some parts (specifically related to the signature) that would normally be written on a scale of vbytes in weight units, that is, parts of the transaction (in truth the process is more complex than it) are 4x smaller! and this is why we generally only see transactions with a rate saving of not more than 50%, also showing that it is impossible to see blocks with 4x more transactions the capacity gain of the blocks actually reaches only + 60% until + 100%). Note: There isnt any way to rise the size of the block without a hardfork. The problem of the malleability of transactions The problem of malleability in transactions was a problem that affected Mt.Gox in 2013, basically it was possible to change the txid of a transaction even without changing its values (origin, recipient, value) and still make it valid. What's the problem? the exchange created a transaction with a txid and the attacker adulterates this transaction with another txid and also transmits it, in the end if only the transaction of the attacker was confirmed, the exchange ended up not discounting the balance of the attacker by looking only the txid generated by they. With segwit this problem is over. More technical part yet Leaving the transactions "lighter" was precisely what triggered the solution of malleability - to be more specific: all the segwit does is basically take the part of ScriptSig (the part that left malleable, it is possible to add useless thing inside) of the part of the transaction (the part that interferes with the hash / txid), and puts it in a region called "witness data", which is lighter (hence the space savings mentioned above), and this ends the problem of malleability and timely space.  -before and after the fork- With the problem of malleability, since in the lightning network you have to generate new transactions based on old transactions that were not transcribed in the blockchain, and if there were the problem of "two txid same for the same transaction", this would not be possible ( it seems that there was even a solution without the need for segwit, but that made everything much more complicated). Note: the LN will work only with "segwit adresses". Schnorr Signatures I will not go into many details, but it is a proposal that can be implemented as well as segwit (but it depends on it), which would further reduce the size of the transactions (especially the multisig), in addition to offering more security and privacy to users. Extra: The schnorr signature perfects and much the system called CoinJoin. Conclusion... The use of segwit drastically reduces transaction fees, but we still need solutions that solve the problem of scalability like Lightning Network, while we should only use the resources we have, and this already helps the network as a whole. I tried to describe the parts a little more technical without complicating much, so probably it will have many mistakes, I will be gratful if you help me to correct ths mistakes. |
|
|
|
Esse tutorial tem o intuito de dar desde as informações mais básicas até algumas mais técnicas. O que é a Segwit ? Explicação simples: É uma "atualização" que teve na rede do bitcoin, abrindo portas para transações mais leves, rápidas e baratas e também possibilitando a implementação de protocolos como a lightning network. Explicação mais técnica: É um soft-fork que muda o conceito de tamanho dos blocos, colocando o conceito de 'weight unit' (explicado depois). Possibilitando uma solução temporária para o problema de escalabilidade e o problema da maleabilidade nas transações (explicado depois). Transações mais rápidas e baratas ? A resposta para isso é depende, a criação de transações mais "baratas" só é possível com os novos tipos de endereço (veja abaixo), e mesmo assim, a velocidade para que a sua transação seja confirmada depende de outros fatores, como os mineradores e a mempool (basicamente as transações dos outros que não foram confirmadas). Novos formatos de endereços Atualmente existem 3 formatos: Legacy (P2PKH): São os formatos antigos, elas começam com o dígito '1' e se você usar eles você continua como antes, pagando como antes, nada muda pra você (tirando o fato de você estar ultrapassado - então por favor use os novos formatos). ex de endereço: 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2 P2SH (nested Segwit): São os melhores para o momento, começam com o digito '3' (lembram as carteiras multisig), com elas você tem a mesma compatibilidade das Legacy, mas com a vantagem de criar transações witness. A economia de taxa gira por volta de 27%. Para usar esse formato nas carteiras, saiba que a maioria já adotou este como padrão - tirando a carteira Electrum, mas para isso existe esse ótimo tutorial em português ensinando. ex de endereço: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy Bech32: Teoricamente são muito melhores que os dois mencionados acima, ela começa com "bc1", os endereços delas tem a vantagem de serem bem legíveis ao ser humano (só tem letra minúscula), o que evita erros de digitação e também permitem o autocompletar das carteiras e um QRcode menor para endereços desse tipo. E o principal: fazem transações witness com uma economia nas taxas bem maior, por volta de 38%. O problema ? quase nenhum software/serviço reconhece isso como um endereço bitcoin, o que traz um grave problema de compatibilidade. (se você deseja usar esse tipo, a carteira Electrum já oferece isso). ex de endereço: bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdqPor que incentivar o uso ? Se você já estiver usando um endereço segwit (P2SH ou bech32), e e você estiver enviando um dinheiro que você recebeu de um outro endereço segwit (segwit->você->outro), então voce terá uma taxa de transação menor do que alguém que está usando um endereço segwit gastando um dinheiro que veio de um endereço legacy (legacy->você->outro). Novamente, se você estiver usando um endereço legacy nada vai mudar, mas se todo mundo usar apenas segwit, as vantagens vão ser maiores. Para ver a adoção da segwit na rede do bitcoin existem diversos sites como este, que possui gráficos para ajudar na visualização. Se você leu até aqui você já tem todas as informações essenciais sobre Segwit, continue a ler somente se você tem curiosidades técnicas sobre como a segwit realmente funciona O que sao "weight units" ? Com a ativação da Segwit, a antiga unidade de medida bytes ficou obsoleta, e foi introduzida as unidades vbytes e weight units, a relação entre elas é de 1 weight unit = 4 vbytes, e em os novos tamanhos dos blocos ficou como 4 milhões de weight units por bloco. O tamanho do bloco não aumentou ? isso não seria um hard-fork ? Não, porque a partir dessa mudança nos blocos, a forma de medir o tamanho das transações também mudou, e nas transações legacy (antigas) o que valia de byte também passou a valer em vbytes, ou seja, uma transação de 300 bytes vale agora 300 vbytes, que na verdade equivale a 300*4=1200 weight units, o que ocupa a mesma porcentagem de espaço nos blocos que antes (na prática, se você entendeu até aqui, 1 byte = 1 vbyte = 4 weight units, mas parece que o pessoal nao gosta de usar essa relação com os bytes). Agora, nas transações criadas usando a Segwit o negocio muda totalmente. As transações "witness" Basicamente, quando voce cria uma transação usando a segwit, o tamanho da transação diminui, mas se você está pensando que é porque elas são totalmente medidas em weight units, você também está errado, o que esses novos endereços conseguem fazer é escrever algumas partes (especificamente relacionadas à assinatura) que normalmente seriam escritos em uma escala de vbytes em weight units, ou seja, partes da transação ficam 4x menor ! e é por isso que geralmente só vemos transações com uma economia de taxas não maior que 50%, mostrando também que é impossível vermos blocos com 4x mais transações (há referencias de que o ganho de capacidade dos blocos chega efetivamente somente aos +60% até +100%). Nota: Para que o bloco aguente 4x o numero de transações, realmente teria que ser aplicado um hard-fork. O problema da maleabilidade das transações O problema da maleabilidade nas transações foi um problema que afetou a Mt.Gox em 2013, basicamente era possível alterar a txid de uma transação mesmo sem alterar os seus valores (origem, destinatario, valor) e mesmo assim tornar ela válida. Qual o problema disso ? a exchange criava uma transação com uma txid e o atacante adultera essa transação com um outro txid e também transmite ela, no fim se apenas a transação do atacante se confirmasse, a exchange acabava não descontando o saldo do atacante por olhar apenas a txid gerada por eles. Com a segwit isso acabou. Parte mais técnica ainda Deixar as transações "mais leves" foi justamente o que desencadeou a solução da maleabilidade - para ser mais específico: tudo que a segwit faz é basicamente tirar a parte do ScriptSig (a parte que deixava maleavel, é possivel adicionar coisa inutil lá dentro) da parte principal da transação ( a parte que interfere no hash/txid) , e coloca numa região chamada "witness data", que é mais leve (por isso a economia de espaço mencionada acima), e isso acaba com o problema da maleabilidade etemporariamente do espaço. genial. -antes e depois da segwit- Com a solução do problema da maleabilidade, já que na lightning network você precisa gerar transações novas com base em transações antigas que não foram transimidas na blockchain, e se houvesse o problema de "dois txid iguais para mesma transação", isso não seria possível (parece que existia até uma solução sem a necessidade da segwit, mas isso tornava tudo muito mais complicado). Nota: Só vai ser possivel tirar proveito da LN no futuro quem estiver usando a segwit, endereços legacy simplesmente não funcionarão. Schnorr Signatures Não vou entrar em muitos detalhes, mas ele é uma proposta que pode ser implementada assim como a segwit (mas depende dela), que diminuiria ainda mais o tamanho das transações (principalmente as multisig), além de oferecer mais segurança e privacidade aos usuários. Extra: A schnorr signature aperfeiçoa e muito o sistema chamado CoinJoin - e tem um experimento aqui no forum local (administrado por um moderador daqui) para todo mundo que quiser tentar. Resumindo... O uso da segwit reduz drasticamente as taxas de transação, mas mesmo assim precisamos de soluções que resolvam de vez o problema da escalabilidade como a Lightning Network, enquanto devemos usar apenas os recursos que temos, e isso já ajuda a rede como um todo. Seria legal se vocês postarem todas os erros do artigo ou as duvidas sobre segwit nos comentários. |
|
|
|
Recentemente tenho percebido alguns fatos curiosos entre os últimos blocos minerados, além de serem mineradas com poucas transações (algo até aceitável por causa da queda brusca no seu valor comercial nos últimos dias), elas estão sendo mineradas com intervalos de tempo muito irregulares (segue as imagens), teoricamente isso não e prejudicial para o bitcoin já que os blocos são minerados com uma média de 10 minutos, mas se isso continuar ocorrendo em um período onde acontece mais transações (geralmente quando o preço sobe) será um problema e tanto. Comentem o que acham disso.  -ultimos blocos minerados agora, as vezes ocorre ainda de ter gaps de mais de 40min entre os blocos- UPD: otimo site com graficos bons sobre o bitcoin.   -sobre como o tempo entre blocos nao tem a ver com o tamanho do bloco em si- |
|
|
|
|
Eu queria criar uma moeda virtual quase 100% de copia do BTC (eh so um tokem pra eu poder aprender mais profundamente e tbm pra zueira entre amigos) e gostaria de pedir ajuda a vcs sobre como comecar...
*e sim, eu conheco bem a bitcoin e tambem sei programar um pouco de linguagem C
gostaria de deixar esse topico tbm para as pessoas que quiserem criar seu proprio token caseiro.
|
|
|
|
|
