Bitcoin Forum
December 17, 2018, 09:06:56 AM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [20] 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 ... 294 »
381  Economy / Reputation / Re: It's a judgement day [Wrong negative trust ] on: October 09, 2018, 01:04:27 PM
Only Bitcoin transaction relationship are not enough to show alts between users , because people of Bitcointalk are not only connected here but they have better friend circle at social media ( WhatsApp and friends zone ) .

Any sane people won't use Bitcoin address on wallet which owned/accessed by multiple person since someone might stole other's Bitcoin anytime or one of them have weak security.

There's an exception if we're talking about Multi-signature address/wallet.

IP check.. anyone want a bet that the accounts all consistently logged in on the same IP?
Since all of those are his friends, they may visit his house someday and use the same. It can also be an excuse. Thus, you will lose the bet, lol.

User agent, Browser Fingerprint and other tracking method solve the problem.

Device name, MAC address, DNS Request, local IP leak & behavior analysis also possible if this forum owned by Google, Facebook or etc.
382  Bitcoin / Development & Technical Discussion / Re: Create and manage unlimited BTC addresses for users? on: October 09, 2018, 12:57:27 PM
You don't need full node to generate Bitcoin address and there are plenty script on GitHub to do that.
About scalable, i guess you should find/create script which support multi-threading and written on lower (not low) level programming language such as C++.
et that bitpay is hostile towards Bitcoin

That's right, I need to create a bitcoin address for each user so they can deposit. Get notified about new deposit with addresses to be able to credit their accounts and then transfer Bitcoin from these addresses to our address. Do you have any recommends GitHub link?

I only can recommend https://github.com/nym-zone/segvan which made by nullius, a popular member in this forum. It has basic multi-core usage and it generates SegWit address which uses lower fees.
383  Bitcoin / Bitcoin Technical Support / Re: Getting bitcoin address from blockchain.info wallet.aes.json file on: October 09, 2018, 12:17:07 PM
If you don't remember the password of your wallet.aes.json or blockchain.info, then there are no way to know/access your bitcoin address/amount.
But blockchain.info send email whenever you send/receive transaction and that could be lead to know your past Bitcoin address with it's amount.
384  Bitcoin / Development & Technical Discussion / Re: Create and manage unlimited BTC addresses for users? on: October 09, 2018, 11:45:30 AM
I'm looking for a way to create and manage 1 million bitcoin addresses for 1 million of our users, any method is limitless and scalable. Open source methods and no full node load are preferred.

You don't need full node to generate Bitcoin address and there are plenty script on GitHub to do that.
About scalable, i guess you should find/create script which support multi-threading and written on lower (not low) level programming language such as C++.

Also there are any APIs that are not limited.

Honestly, i don't have much idea, but https://www.blockcypher.com/ is popular. Alternatively, you could use https://bitcore.io/ client/full nodes which have efficient API.

I believe bitpay.com is the way to go. Easy and tested a lot already.

Don't forget that bitpay is hostile towards Bitcoin
385  Alternate cryptocurrencies / Altcoin Discussion / Re: Can make fake coin? on: October 09, 2018, 11:37:52 AM
If it's not open-source, there are many ways to make fake generate coins outside the intended plan such as accept blocks mined by x address no matter the output of coinbase transaction on the source-code.

Also, total nodes have small correlation with 51% attack unless total nodes is very low. If you want to prevent that, you must encourage people to run full-nodes and not choose pool with big hashrate.
Even this coin's mining reward is 0 and all coins 100% are premined? Then how others can make coin?

Basically what i meant is developer of the wallet/full-nodes client put backdoor on it's wallet/full-nodes client which accept blocks with custom mining reward with condition set by those who put the backdoor.
But what you should worry about DDoS attack since there are only 2 full nodes on x coin network.
386  Other / Meta / Re: As the spammers seem to of started to find meta... on: October 09, 2018, 10:41:40 AM
1. Disable signature or/and merit on Meta boards. People who actually want to talk/discuss about this forum won't leave Meta boards.
2. Create multiple boards child board for account recovery, ban appeal and merit.
3. Warn that all merit TX on Meta will be reversed if people continue to spam
387  Alternate cryptocurrencies / Altcoin Discussion / Re: Can make fake coin? on: October 09, 2018, 05:35:03 AM
If it's not open-source, there are many ways to make fake generate coins outside the intended plan such as accept blocks mined by x address no matter the output of coinbase transaction on the source-code.

Also, total nodes have small correlation with 51% attack unless total nodes is very low. If you want to prevent that, you must encourage people to run full-nodes and not choose pool with big hashrate.
388  Bitcoin / Bitcoin Technical Support / Re: How can I create a bitcoin QR code securely? on: October 09, 2018, 04:34:45 AM
I doubt there are any tools which don't create genuine QR code, unless it's buggy or made by shady person.
If you want to be secure, just search qr code generator on GitHub, choose best repository for your usage and run it offline on secure device.

Code:
https://chart.googleapis.com/chart?chs=150x150&cht=qr&chl=YOUR-BITCOIN-ADDRESS-HERE

Don't forget to add bitcoin: before your bitcoin address since it would be more convenient for payment or better auto-identification
389  Other / Meta / Re: ETFbitcoin's merit source application on: October 09, 2018, 04:08:49 AM
You can, you have to do it manually. There are several ways to quote a locked topic. You can find some here- https://bitcointalk.org/index.php?topic=4144474.0

Anyway, I support your application and wish theymos make you merit source. I like the posts you have quoted. Most of the application only quote some from meta (Quoting threads only from meta doesn't evaluate a person's ability, IMO.)

Thanks for the help and support

What I love from all those merit source application is reading the selected posts.
The best way to learn things, and here's quite a lot to read.

@OP, really like your application as you are more technically oriented. Crossing fingers for the best outcome in a short time.

Thank you for your support

...

Thanks for the help

ETFbitcoin - do you speak Indonesian? I think you should mention that in your application. Being able to merit posts in more than one language is an advantage.

Yes. I forgot to mention that even though i made a draft about it.
390  Other / Meta / Re: ETFbitcoin's merit source application on: October 08, 2018, 05:28:48 PM
#7
Our education system (or at least in the country where I'm from) is such that students learn very little about the principles and foundation of money. For example, nobody is teaching about the history of money, how it is created, how it works, why it works etc.

Maybe the principles of money are known to economics students, but it is easy to check that the general population knows very little about the concept of money. Given how important money is in everyone's life, this lack of knowledge is really symptomatic. So much so that one has to ask oneself if this is done deliberately to keep the masses ignorant of one of the most important aspects in their lives.

In the following, I want to share a couple of interesting points about how crypto compares to fiat money and where is the important difference. It is about 3 types of consensus inherent to Bitcoin that I learned from the book:

Bitcoin and Cryptocurrency Technologies, Chapter 7. Community, Politics, and Regulation

As the authors state, there are basically

3 types of consensus that any cryptocurrency functioning as money has to have:

consensus about rules
consensus about history
consensus about value

1. The consensus about rules is basically a set of rules the majority agrees to follow.

Fiat money doesn't have this kind of consensus, because the government declares the rules by fiat. It may even change the rules along the way as it sees fit. Great example is the current hyperinflation disaster in Venezuela.

Cryptocurrencies do have this kind of consensus. In Bitcoin, we have a consensus about what makes a transaction valid, what makes a block valid, how new bitcoins are minted, what the total supply is, etc.

2. The consensus about history is actually about record keeping.

Like in the previous point, fiat money doesn't need this kind of consensus. It is enough to physically own money, or the banks can take care of your money and keep a record for you, so there is no need for this consensus.

Cryptocurrencies do need this kind of consensus. In Bitcoin, there has to be a consensus about the history of all valid transactions as well as about the current state of the public record.

3. The consensus about value is a mutual agreement about the value of money.

This consensus is the only consensus both fiat and crypto require in order to function properly. It is about people agreeing that the value of the money they are using will be there in the future.

This consensus equally applies to dollars, euros, and bitcoin. You have to believe that the money you hold will retain its value tomorrow. If many people believe in the same outcome, there is a consensus about value.

Interdependence of the 3 Types of Consensus

Bitcoin (and other cryptocurrencies) have to have all three types of consensus to work as they are supposed to. Moreover, these 3 types support one another. If everyone agrees about valid blocks and transactions, everyone agrees about the state of the public record. As a result, everyone agrees that the currency is not double spent and everyone agrees that the currency will be valuable in the future.

And the other way around: If everyone agrees that the currency will have value in the future, everyone will make sure the consensus rules are followed and the miners have incentive to obey the rules. Then, automatically there is a consensus about the state of the public record.

The ingenuity of Satoshi Nakamoto can be seen, among other things, in connecting these 3 consensus mechanisms and making them work so well in practice to support each other.
Thread link : https://bitcointalk.org/index.php?topic=4975639.msg44869693#msg44869693 (thread is locked, so i can't quote the post)Thank you for k0er and Husna QA who give quoted code Smiley
Archive link : https://archive.fo/1wX3v
Short comment/info : Sharing about Bitcoin's consensus from book by Jameson Lopp and compare it with fiat money


#8
The impression I get is that people either decide to run a full node on purpose or just go straight for a SPV wallet. Running a "semi-full" node (eg. Bitcoin Core with pruning enabled) seems to be the exception. Accordingly I doubt that providing the ability to run a semi-full node increases the overall node count much. However I'm just extrapolating from anecdotal observations without having anything substantial to back this claim up, so don't take my word for it.

I think the problem at hand is, that the fewer full nodes there are, the more traffic they need to bear. This in turn will make running a full node even harder, causing more full nodes to drop off, further increasing the traffic on the remaining nodes until only a handful of very costly full nodes are left. And every new pruned node that comes online needs these full nodes to bootstrap, lest they won't even become a semi-full node.
Archive link : https://archive.fo/tn6hS
Short comment/info : Nice thoughts if majority nodes use pruned-mode


#9
Why do you trust banks with your money? Oh wait, I don't, and I don't trust online or other wallets either.

I don't see what's wrong with a password protected Bitcoin core wallet. I think that is the most trustworthy, but that's just an instinctive reaction on my part.

But the OP question still remains.

Why do you trust the Bitcoin Core wallet?
Why do you trust the operating system that you are running your Bitcoin Core wallet on?
Why do you trust the hardware that your operating system is running on?
Why do you trust the mathematical functions of ECDSA and SHA?

I think the important question that the OP was asking is...

"If I do not have the technical expertise to know exactly what the software and hardware are doing, then how can I be certain that those who do have the technical expertise aren't lying to me?"

The security of open source relies on the concept that hiding the true nature of the thing requires that ALL TECHNICALLY CAPABLE people in the ENTIRE WORLD will collude to hide the behavior of the thing from ALL TECHNICALLY INCAPABLE people.  If even 1 single technically capable person refuses to collude with all the other technically capable people, then that one person can reveal the true nature of the thing to all the technically incapable people.
Archive link : https://archive.fo/bBj9T
Short comment/info : Short, yet clear message about how to trust something from those with technical expertise if you don't have sufficient technical expertise

#10

Intro


Sebelum Bitcoin muncul dengan jaringan Blockchain-nya. Sudah banyak metode-metode pengembangan dari sistem mata uang digital yang tidak bisa sukses (gagal), karena terkendala untuk mencapai suatu konsensus atau membuahkan suatu hasil yang mustahil. Permasalahan ini dikenal dengan sebutan "Byzantine Generals Problem".

Pengertian Umum dari Byzantine Generals Problem

Sekelompok pasukan Bizantium terbagi menjadi beberapa kelompok dengan seorang Jenderal sebagai pemimpin kelompoknya. Masing-masing jenderal saling berkomunikasi lewat pesan yang dihantar melalui kurir sehingga bisa ditentukan kapan waktu untuk menyerang dan kapan waktu untuk mundur secara bersamaan (antar kelompok). Dengan dilakukan serangan secara bersama, maka peluang untuk memenangkan pertarungan ini sangat besar. Sistem ini mempunyai banyak kelemahan dan besar kemungkinan untuk dimanipulasi karena posisi dari masing-masing Jenderal terpaut jarak yang jauh dan diperlukan adanya kurir sebagai perantara intruksinya.

Beberapa masalah yang bisa muncul pada sistem ini antara lain seperti :

- Pesan (intruksi) tidak sampai karena kurir terbunuh ditengah jalan
- Jika pesan (intruksi) yang disampaikan tidak sama, maka keputusan diantara Jenderal juga akan berbeda.
- Jika ada beberapa Jenderal atau pasukan yang berkhianat, maka hasil serangan tidak akan efektif lagi

Algoritma konsensus pada teknologi Blockchain muncul sebagai solusi dari "Byzantine Generals Problem".




Konsensus


Pengertian umum Konsensus adalah kesepakatan kata atau permufakatan bersama (mengenai pendapat, pendirian, dan sebagainya) yang dicapai melalui kebulatan suara (https://kbbi.web.id/konsensus)

Sedangkan pengertian Konsensus didalam teknologi Blockchain ialah Persetujuan bersama (mufakat) untuk melakukan validasi pada suatu transaksi (Block) yang dihasilkan dari proses perhitungan yang kompleks dan rumit.  




Algoritma Konsensus Blockchain


Algoritma pada dasarnya menjabarkan segala prosedur yang harus dilakukan dalam menyelesaikan sebuah masalah. Karena sifat dari blockchain yang terdistribusi, maka dibutuhkan algoritma untuk mencapai konsensus dengan mengurutkan dan merumuskan suatu masalah (data) secara bersama-sama. Sehingga bisa ditetapkan/diterbitkan suatu hasil (hash) yang autentik dan valid ke dalam sebuah block didalam jaringan Blockchain.




1. Proof of Work

Sebuah protokol yang mempunyai fungsi untuk mencegah aktifitas serangan cyber (DDos), yang dapat melumpuhkan/melemahkan suatu sumber daya sistem komputer. Konsep POW pertama kali dikenalkan oleh Cynthia Dwork & Moni Naor pada tahun 1993 dan baru di implementasikan oleh Markus Jakobsson (mata uang Shell) pada tahun 2009.

Dalam teknologi Blockchain, POW digunakan oleh Satoshi Nakamoto sebagai algoritma konsensus dan Bitcoin sendiri sebagai Mata Uang dari konsensus Proof of Work ini. Persyaratan utama dalam konsensus POW adalah proses kegiatan mining (proses komputasi dari CPU, GPU, ASIC, FPGA) yang berfungsi sebagai penemu, pencari solusi dan memvalidasi setiap masalah (hash) kedalam sebuah block dan akan didistribusikan ke dalam sebuah buku besar (ledger) yang disebut dengan Blockchain.

Untuk mencapai sebuah konsensus, sebuah transaksi harus melewati beberapa proses yang juga melibatkan adanya proses komputasi yang dilakukan oleh beberapa miners, sehingga bisa tercipta sebuah Block yang valid.

Sistem Distribusi konsensus Proof of Work :

- Suatu (beberapa) transaksi yang muncul dari sebuah wallet yang bertindak sebagai Full Node (salinan Blockchain) akan di publish pada jaringan (P2P).
- Transaksi-transaksi ini akan tehubung ke sebuah jaringan yg juga terhubung dengan node Miners
- Miner-miner akan melakukan proses komputasi (hash function) untuk menyelesaikan persoalan matematika rumit ini ke dalam sebuah block.
- Jumlah maksimal transaksi dalam setiap block tergantung dari protokol yang berlaku.
- Setelah masalah (hash) terpecahkan, maka miner yang pertama kali memecahkan masalah ini akan mem-broadcast block baru ke jaringan (P2P).
- Node-node (miner-miner) lainnya yang menerima block ini akan melakukan proses verifikasi (validasi).
- Setelah block mendapat validasi, maka block ini akan di distribusikan ke dalam blockchain sebagai Block baru yang valid.
- Miners yang bertindak sebagai pembuat block valid akan menerima reward.






Cryptocurrencies yang menggunakan algoritma konsensus PoW

  • Bitcoin (BTC)
  • Ethereum (ETH)
  • Monero (XMR)
  • Litecoin (LTC)
  • Dan lain-lain



2. Proof of Stake

Algoritma konsensus Proof of Stake (PoS) pertama kali dikenalkan oleh Sunny King dan Scott Nadal pada tahun 2012. Penggunaan metode ini diharapkan dapat mengatasi besarnya daya yang dibutuhkan untuk melakukan proses komputasi pada konsensus PoW. Secara garis besar, proses Staking ialah mengunci beberapa jumlah coin (cryptocurrency) sebagai jaminan, didalam sebuah wallet yang menjalankan Full Node dari sebuah blockchain. Jaminan ini sebagai bukti kepemilikan seorang pemegang koin (tokens holder) sebagai fungsi node, dalam berkontribusi didalam jaringan  konsensus PoS dengan proses yang dinamakan Forging (menempa koin).

Berbeda dengan konsensus PoW yang membutuhkan proses komputasi menggunakan peralatan-peralatan dengan sumber daya listrik. Pada metode PoS, untuk mencapai sebuah konsensus hanya dibutuhkan sebuah Full Node (Wallet) dengan token/koin didalamnya. Dan setiap token/koin holder yang senantiasa terhubung dengan jaringan (node) blockchain, mempunyai peluang untuk menjadi seorang staker/forger dengan memenuhi syarat sesuai dengan protokol yang berlaku. Oleh karena itu didalam konsensus PoS ini, tidak dibutuhkan banyak sumber daya energi (listrik) dalam proses pencapaian suatu konsensus.

Sistem Distribusi konsensus Proof of Stake :

- Untuk bisa melakukan forging (minting), maka pemegang token/koin harus mengunci sejumlah koin didalam walletnya (Full Node) yg terhubung dengan jaringan blockchain.
- Pada saat sebuah/beberapa transaksi masuk ke dalam jaringan (P2P). Pembuatan sebuah block (validasi transaksi) dipilih secara Pseudorandom berdasarkan jumlah koin yang di stake dan berapa lama koin tersebut sudah di stake.
- Token/Coin Holder dengan jumlah Staking Coin yang besar dan waktu (umur) staking yang lama, mempunyai peluang (kesempatan) lebih tinggi untuk melakukan proses forging pada block berikutnya.
- Setelah proses pembuatan block dan proses validasi selesai, maka block ini akan didistribusikan ke dalam jaringan blockchain sebagai block baru yang valid.
- Forger (staker) akan menerima reward dari hasil kerjanya dan untuk umur staking coinnya akan direset ulang.






Cryptocurrencies yang menggunakan algoritma konsensus PoS

  • Peercoin (PPC)
  • NXT
  • Blackcoin
  • Dan lain-lain



3. Delegated Proof of Stake

DPoS diciptakan oleh Daniel Larimer pada saat membuat sebuah cryptocurrency yang disebut dengan BitShares pada tahun 2014. Algoritma konsensus ini adalah sebuah metode baru sebagai tindakan pengamanan terhadap sebuah jaringan cryptocurrency untuk mencapai sebuah konsensus tanpa memerlukan adanya otoritas terpusat. Prinsip kerjanya hampir mirip dengan konsensus Proof of Stake, dimana untuk mencapai konsensus yang valid maka dibutuhkan proses verifikasi dari pelaku-pelaku otoritas yang terdistribusi dan berjalan sesuai dengan protokol yang ada didalam metode konsensus tersebut.

Jika didalam PoS pemilihan pembuatan block bersifat Pseudorandom (berdasar jumlah dan umur Coin/Token), maka pada DPoS setiap delegasi/witness (pembuat block) akan ditentukan dengan voting. Setiap pemegang koin/token mempunyai suara (vote) yang bisa digunakan untuk memilih satu atau beberapa witness/validator dan dapat memindahkan vote-nya kepada witness lainnya setiap saat. Validator/witness terpilih (diurutkan berdasarkan jumlah vote) akan mempunyai otoritas untuk membuat sebuah block dan mempublikasikannya ke dalam jaringan Blockchain.

Sistem Distribusi konsensus Delegated Proof of Stake :

- Setiap transaksi yang terjadi akan masuk ke jaringan (P2P).
- Token/Coin holder yang menjalankan Full Node (wallet) akan melakukan Vote untuk menentukan beberapa witness/delegasi. Semakin besar jumlah token maka semakin besar juga nilai votenya.
- Token/Coin holder bisa melakukan vote terhadap dirinya sendiri setelah melakukan registrasi menjadi witness (validator) sesuai dgn protokol yang berlaku.
- Dalam setiap putaran, masing-masing validator/witness terpilih (jumlah max (N) witness berdasarkan protokol yang berlaku) akan memproses beberapa transaksi ke dalam sebuah block.
- Sebelum block valid dibroadcast ke dalam blockchain, urutan rank dari validator/witness akan berubah-ubah sesuai dengan jumlah vote yang didapat.
- Setelah block berhasil divalidasi oleh witness/validator, maka masing-masing block akan didistribusikan ke dalam jaringan blockchain berdasarkan urutan rank dari Validator.
- Masing-masing Validator (witness) akan menerima reward sesuai protokol yang berlaku.







Cryptocurrencies yang menggunakan algoritma konsensus DPoS

  • BitShares
  • EOS
  • Lisk
  • Steem
  • Dan lain-lain



4. Delegated Byzantine Fault Tolerance

Algoritma konsensus ini muncul untuk mengatasi masalah dari "Byzantine Generals Problem" (BGP). Dengan menggunakan protokol yang hampir mirip dengan konsensus DPOS, diharapkan dapat menutupi kekurangan suatu sistem buruk (BGP) didalam sebuah jaringan, sehingga bisa dicapai suatu konsensus yang valid.

Didalam konsensus DBFT ada beberapa entitas yang mempunyai peran dan fungsi masing-masing, dalam pelaksanaannya untuk mencapai sebuah konsensus kerja, sehingga setiap block-block yang dihasilkan dan divalidasi dapat didistribusikan ke jaringan blockchain.
1. Node (Token/Coin Holder) bertindak sebagai pemilih delegasi dengan menggunakan metode Vote berdasarkan dengan jumlah Token mereka.
2. Delegasi (Validator) dipilih berdasarkan vote dan juga mempunyai peran untuk melakukan proses verifikasi (validasi) terhadap sebuah block yang akan didistribusikan ke dalam jaringan Blockchain.
3. Pemimpin delegasi (Delegate Leader) dipilih secara acak dari calon-calon delegasi yang ada. Pemimpin Delegasi bertanggung jawab untuk membuat sebuah block baru yang berisikan data-data transaksi, yang nantinya akan didistribusikan ke dalam jaringan Blockchain setelah melalui proses validasi.

Sistem Distribusi konsensus Delegated Byzantine Fault Tolerance :

- Pada sebuah/beberapa transaksi yang terjadi didalam jaringan (P2P), maka akan ditindaklanjuti oleh seorang Block producer (Delegate leader)
- Block producer yang dipilih secara random dari beberapa calon delegasi, akan menciptakan suatu block baru yang nantinya akan diusulkan untuk mendapatkan proses validasi.
- Pada saat block terselesaikan, maka group delegasi akan melakukan proses validasi. Dan dibutuhkan N % verifikasi (tergantung ketentuan protokol) supaya block baru ini dianggap valid.
- Setelah block mendapatkan jumlah verifikasi sebesar N %, maka block akan didistribusikan ke jaringan blockchain sebagai block baru yang Valid.
- Delegate leader (Block Producer) akan menerima reward sebagai imbalan hasil kerja.






Cryptocurrency yang menggunakan algoritma konsensus DBFT

  • Neo


Beberapa Algoritma Konsensus lainnya

- Proof of Authority
  • POA Network (POA)
  • VeChain (VET)

- Proof of Space / Proof of Capacity
  • BurtsCoin

- Proof of Importance
  • NEM / XEM






References :
https://blockgeeks.com/guides/blockchain-consensus
https://en.wikipedia.org/wiki/Proof-of-work_system
https://en.wikipedia.org/wiki/Proof-of-stake
http://docs.bitshares.org/bitshares/
https://cryptowiki.com/Delegated_Byzantine_Fault_Tolerance
Archive link : https://archive.fo/ljLNA
Short comment/info : List of some consensus method with detailed explanation



This thread is archived at https://archive.fo/QGyZP

Reference :
1.
Code:
SELECT SUM(M.MERIT) AS "Total Merit Sent",COUNT(M.MERIT) AS "Total Merit TX", M.FromID, U.Username
FROM UserData as U, MeritData as M
WHERE M.FromID = U.UserID
GROUP BY M.FromID
ORDER BY "Total Merit TX" DESC;
391  Other / Meta / ETFbitcoin's merit source application on: October 08, 2018, 05:28:21 PM
Hi, i'm ETFbitcoin and i would like to apply to be a merit source, mainly because :
1. Not enough appreciation for newcomers who bring rough, but interesting/great idea for Bitcoin development
2. I'm out of sMerit, even if i only give 1-2 merit for a post/thread

Based on tool made by Piggy at https://bitcointalk.org/index.php?topic=4393868.0 & https://albertoit.github.io/Merit-Explorer-SQL/, i'm top 5 merit sender on "Development & Technical Discussion" boards, top 10 on "Bitcoin Technical Support" and top 50 overall1 based on transaction count.
I'm from Indonesia, so i can participate in Bahasa Indonesia (Indonesian) boards and try to encourage more technical discussion in my board.

I'm not sure if i'm can categorized as somewhat established member, but i :
1. Sometimes help others with basic/common technical problem
2. I actively report spam on few board with stats 989 posts with 98% accuracy (936 good, 27 bad, 26 unhandled)

3. Starting try to make people aware with unpopular/upcoming Bitcoin technology such as Dandelion



Here are 10 posts/threads which i believe haven't received enough merit or/and could be implemented on Bitcoin development with further development. P.S. i'm fully aware some of the idea is controversial.

#1
Proof of Collaborative Work

A proposal for eliminating the necessity of pool mining in bitcoin and other PoW blockchains

Motivation
For bitcoin and the altcoins which are based on common PoW principles,  centralization of mining through using pools, is both inevitable and unfortunate and puts all the reasonings that support the security of PoW in a paradoxical, fragile situation.

A same problem does exist with PoS networks. Things can get even worse  there because of the fact that most PoS based systems enforce long run deposit strategies for miners that is highly discouraging for them to migrate from one pool to another because of the costs involved.

Satoshi Nakamoto's implementation of PoW that is the core of bitcoin client software is based on a winner-takes-all strategy which is the fundamental factor behind two critical flaws: mining variance and proximity premium which are the most important forces that participate in forming pooling pressure.

Until now, both mining variance and proximity premium are known to be unavoidable and hence pooling pressure is considered an inherent flaw for bitcoin and other PoW based currencies.

In this proposal, we are suggesting an alternative variant of PoW in which the traditional winner-takes-all is replaced with a collaborator-takes-share strategy.

The problem of solo mining becoming too risky and impractical for small mining facilities appeared in 2010, less than 2 years after bitcoin had been launched. It was the worst timing ever, although Satoshi Nakamoto made a comment on bitcointalk about first pool proposals,  it was among the latest posts Satoshi made and he just disappeared few days later from this forum, forever, without making a serious contribution to the subject.

This way, the confused community came out with an unbelievable solution for such a critical problem, a second layer centralized protocol, named pooling, boosted by greed and ignorance, supported by junior hackers who as usual missed the forest.

Bitcoin was just 2 years old when pooling age began and eventually dominated almost all the hashpower of the network.

A quick review of Slush thread in which Satoshi has made the above referenced reply, could reveal how immature and naive this solution was and has been discussed and how it has been adopted: In a rush with an obvious greed.
Nobody ever mentioned the possibility of an algorithm tweak to keep PoW decentralized. Instead everybody was talking about how practical was such a centralized service while the answer was more than obvious:
Yes! you can always do everything with a centralized service, don't bother investigating.  

Anyway, in the thread, one couldn't find any arguments about the centralization consequences or the possibility of alternative approaches including the core algorithm improvements Shocked

I think it is not fair. PoW is great and can easily be improved to eliminate such a paradoxically centralized second layer solution. This proposal, Proof of Collaborative Work (PoCW) is an example of inherent possibilities and capacities of PoW. I didn't find any similar proposal and it looks to be original but If there is a history, I'll be glad to be informed about. Smiley

The Idea is accepting and propagating works with hundreds of thousands times lower difficulties and accumulating them as a proof of work for a given transaction set, letting miners with a very low shares of hash power ( say of orders like 10-6) to participate directly in the network and yet experience and monitor their performance on an hourly basis.



Imo, now, after almost a decade being passed, Moore law has done enough to make it feasible utilizing more bandwidth and storage resources and it seems to me kinda hypocritic to make arguments about 'poor miners' and pretending to be concerned about centralization threats and making excuses so for rejecting this very specific proposal that although increases the demand for such resources, can radically disrupt current situation with pools and centralized mining.

This proposal is mainly designed for bitcoin. For the sake of convenience and letting the readers to have a more specific perception of the idea, I have deliberately used constants instead of adjustable parameters.

Outlines
  • An immediate but not practically feasible approach can be reducing blocktime (along with proportional reduction in block reward). Although this approach, as mentioned, can not be applied because of network propagation problems involved, but a very excellent consequence would be its immediate impact on the scalability problem if employed, we will use it partially (reducing blocktime to 1 minute compared to current 10 minutes period).
  • As  mentioned earlier (and with all due respects to Core team), I don't take objections about the storage and network requirements implications and consequences of reducing blocktime as a serious criticism. We should not leave mining in hands of 5 mining pools to support a hypothetical poor miner/full node owner who can not afford installing a 1 terabyte HD in next 2 years!.
  • Also note, blocktime reduction is not a necessary part of PoCW, the proposed algorithm, I'm just including it as one of my old ideas (adopted from another forum member who suggested it as an alternative to infamous block size debate and later has been developed a bit more by me) which I think deserves more investigation and discussion.
  • PoCW uses a series of mining relevant data structures to be preserved on the blockchain or transmitted as network messages
    • Net Merkle Tree: It is an ordinary Merkle hash tree of transactions with the exception that its coinbase transaction shows no block reward (newly published coins) instead the miner charges all transaction fees to his account (supports SegWit)
    • Collaboration Share: it is  a completely new data structure composed of following fields:
      • 1- The root of a Net Merkle Tree
      • 2- Collaborating miner's wallet address
      • 3- A nonce
      • calculated difficulty using previous block hash padded with all previous fields, it is always assumed to be at least as hard as 0.0001 compared to current block difficulty
    • Coinbase Share: it is new too and is composed of
      • 1- A Collaborating miner's wallet address
      • 2- A nonce
      • 3- A computed difficulty score using the hash of
        • previous block's hash padded with
        • current block's merkle root, padded with
        • Collaborating miner's address padded with the nonce field
      • 4-  A reward amount field
    • Shared Coinbase Transaction: It is a list of Coinbase Shares  
      • First share's difficulty score field is fixed to be  2%
      • For each share difficulty score is at least as good as 0.0001
      • Sum of reward amount fields is equal to block reward and for each share is calculated proportional to its difficulty score
    • Prepared Block: It is an ordinary bitcoin block with some exceptions
      • 1- Its merkle root points to a  Net Merkle Tree
      • 2- It is fixed to yield a hash that is as difficult as target difficulty * 0.05
    • Finalization Block: It is an ordinary bitcoin block with some exceptions
      • 1- Its merkle root points to a  Net Merkle Tree
      • 2- It is fixed to yield a hash that is as difficult as target difficulty * 0.02
      • 3- It has a new field which is a pointer to (the hash of) a non empty Shared Coinbase Transaction
      • 4- The Shared CoinBase Transaction's sum of difficulty scores is greater than or equal to 0.95
  • Mining process goes through 3 phases for each block:
    • Preparation Phase: It takes just few seconds for the miners to produce one or (barely) 2 or 3 Prepared Blocks typically. Note that the transaction fees are already transferred to miner's wallet through coinbase transaction committed to the Net Merkle Tree's root for each block.
    • Contribution Phase: Miners start picking one valid Prepared Block's Merkle root, according to their speculations (which become more accurate as new shares are submitted to the network) about it to get enough shares eventually, and producing/relaying valid Contribution Shares for it.
      As the sum of the difficulty scores for a given Prepared Block's Merkle root grows we expect an exponential convergence rate for the most popular Merkle root to be included in Contribution Shares.  
    • Finalization Phase: After the total scores approaches the 0.93 limit, rational Miners would begin to produce a Finalized block
  • Verification process involves:
    • Checking both the hash of the finalized block and all of its Shared Coinbase Transaction items to satisfy network difficulty target cumulatively
    • Checking reward distribution in the shared coinbase transaction
    • Checking Merkle tree to be Net
  • UTXO calculation is extended to include Shared Coinbase Transactions committed to finalized blocks on the blockchain as well
  • Attacks/forks brief analysis:
    • Short range attacks/unintentional forks that try to change the Merkle root are as hard as they are in traditional PoW networks
    • Short range attacks/unintentional forks that preserve the Merkle root but try to change the Shared CoinBase Transaction has  zero side effects on the users (not the miners) and as of redistributing the shares in favor of the forking miner, they are poorly incentivized as gains won't go anything further than like %2-%10  redistribution ever.
    • Long Range attacks with a total rewrite agenda will fail just like Traditional PoW  
    • Long Range attacks with partial coinbase rewrite are again poorly incentivized and the costs won't be justified

Implementation

This is a radical improvement to classical PoW, I admit, but the costs involved are fair for the huge impacts and benefits. I have reviewed the bitcoin Core's code and found it totally feasible and practical form the sole programming perspective. Wallets could easily be upgraded to support the new algorithm as well,  but a series of more complicated issues, mostly political are extremely discouraging but it is just too soon to give up and go for a fresh start with a new coin, or just manage for an immature fork with little support, imo.

Before any further decisions, it would be of high value to have enough feedback from the community. Meanwhile I'll be busy coding canonical parts as a BIP for bitcoin blockchain, I think it takes like 2-3 weeks or even a bit more because I'm not part of the team and have to absorb a lot before producing anything useful, plus, I'm not full time, yet Wink

I have examined the proposed algorithm's feasibility as much as I could, yet I can imagine there might be some flaws overlooked, and the readers are welcome to improve it. Philosophical comments questioning the whole idea of eliminating pools don't look to be constructive tho. Thank you.


Major Edits and Protocol Improvements:
  • June 10, 2018 09:30 pm Inspired by a discussion with @ir.hn

    • A Prepared Block should be saved in the fullnodes for a long period of time enough to mitigate any cheating attempt to avoid Preparation Phase and using non-prepared, trivially generated Net Merkle Roots.  
      • Full nodes MAY respond to a query by peers asking for a block's respected Prepared Block if they have decided to save the required data long enough
      • For the latest 1000 blocks preserving such a data is mandatory.
      • For blocks with an accumulated difficulty harder than or equal to the respected network difficulty, it would be unnecessary to fulfil the above requirement.*
      • Prepared Block and Preparation phase terms replaced the original Initiation Block and Initiation Phase terms respectively to avoid ambiguity
      Notes:
      * This is added to let miners with large enough hash powers choose not to participate in collaborative work.
  • reserved for future upgrades
  • July 3, 2018 02:20 pm inspired by discussions with @anunimint

    • A special  transaction was added to Shared CoinBase Transaction to guarantee/adjust proper reward for the finder of Prepared Block and some enhancements were made to include both block reward and transaction fees (partially) in the final calculations.
      • In Finalization Phase, miners should calculate a total reward for the miner of its respected Prepared Block as follows:  
        preparedBlockReward = blockReward *0.04 + totalTransactionFees *0.3
      • Shared Coin Base Transaction should include one input/output address-amount pair that adjusts the amount of reward assigned to the Prepared Block Miner in the ordinary coinbase transaction
      • All the calculations needed for calculating rewards assigned to the miners of finalized block and shares will be carried out on the sum of network block reward and 70% of transaction fees collected in transactions that are committed to Net Merkle Tree
      Note:
       This change is made to both guarantee a minimum reward for miners of Prepared Blocks and incentivize them for including more transactions with higher fees  
  • reserved for future upgrades






Archive link : https://archive.fo/29FhF
Short comment/info : While there are many obstacle, removing pool from Bitcoin mining could prevent potential centralization/censorship by powerful multiple pools working together.


#2
Bitcoin wiki has a pretty good step-by-step explanation of how to go from a public key to a base58_encoded address which contains the values for each step of the way[1]. But unfortunately I could not find anything similar for Bech32_encoding. Additionally I found the reference implementations a bit confusing[2]! The information is out there[3] but I feel like having it step-by-step like "[1]" can make it a lot easier specially for developers. For example during unit testing I was getting a different address (bc1qp63uahgrxged4z5jswyt5dn5v3lzsem6c0qqhg8) for below public key and I wasn't sure where the bug was coming from, this visualization helped me [4] realize I was appending the version byte before converting the bits instead of after. So hopefully these steps can help someone like me looking for them.


How to create a Bech32 address from a public key:

1. Having a compressed[5] public key (0x02 or 0x03 followed by 32 byte X coordinate):
Code:
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

2. Perform SHA-256 hashing on the public key:
Code:
0f715baf5d4c2ed329785cef29e562f73488c8a2bb9dbc5700b361d54b9b0554

3. Perform RIPEMD-160 hashing on the result of SHA-256:
Code:
751e76e8199196d454941c45d1b3a323f1433bd6

4. The result of step 3 is an array of 8-bit unsigned integers (base 2^8=256) and Bech32 encoding converts this to an array of 5-bit unsigned integers (base 2^5=32) so we "squash" the bytes to get:
in hex:
Code:
0e140f070d1a001912060b0d081504140311021d030c1d03040f1814060e1e16
in numbers:
Code:
14 20 15 07 13 26 00 25 18 06 11 13 08 21 04 20 03 17 02 29 03 12 29 03 04 15 24 20 06 14 30 22
5 bits binary:
Code:
01110 10100 01111 00111 01101 11010 00000 11001 10010 00110 01011 01101 01000 10101 00100 10100 00011 10001 00010 11101 00011 01100 11101 00011 00100 01111 11000 10100 00110 01110 11110 10110

5. Add the witness version byte in front of the step 4 result (current version is 0):
Code:
000e140f070d1a001912060b0d081504140311021d030c1d03040f1814060e1e16

6. Compute the checksum by using the data from step 5 and the H.R.P (bc for MainNet and tb for TestNet)
Code:
0c0709110b15

7. Append the checksum to result of step 5 (we now have an array of 5-bit integers):
Code:
000e140f070d1a001912060b0d081504140311021d030c1d03040f1814060e1e160c0709110b15

8. Map each value to its corresponding character in Bech32Chars (qpzry9x8gf2tvdw0s3jn54khce6mua7l) 00 -> q, 0e -> w,...
Code:
qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

9. A Bech32_encoded address consists of 3 parts: HRP + Separator + Data:
Code:
bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

The final result from step 9 is the same as example in BIP173[6]

References:
[1] https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
[2] https://github.com/sipa/bech32
[3] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
[4] https://en.bitcoin.it/w/images/en/4/48/Address_map.jpg
[5] Only compressed public keys are allowed: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#restrictions-on-public-key-type
[6] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#examples
Archive link : https://archive.fo/h1S2D
Short comment/info : While i haven't try make script based on this guide to test it, developer guide/wiki should able to use this guide


#3
Superspace: Scaling Bitcoin Beyond SegWit

Steve Kallisteiros
August 25, 2018

Abstract. SegWit, or Segregated Witness, a soft fork successfully activated mid-2017 on Bitcoin blockchain, provided among other benefits a backward-compatible increase to the block size limit, all while not introducing consensus breaking changes to Bitcoin protocol and not resulting in a hard fork network partitioning. The potential space increase is estimated at being close to 2 MB total for practical purposes. In this paper, the author argues that it is possible, using the same mechanism, increase the block size further up to any agreed-upon limit, while still providing the same security guarantees SegWit does.

Complete paper: https://files.zazzylabs.com/LNx2ud/superspace.pdf

===

Keep in mind, it's only the first draft. I would really appreciate your feedback.
Archive link : https://archive.fo/yZqOZ
Short comment/info : While it's over complicated and only increase maximum transaction in block, it could be used as last resort if hard-fork isn't option. Changing address prefixes from "bz" to "bc1p" (use next witness version)


#4
If you have ...
- The seed (set of words)
- The master private key (a long string starting with "xrpv")
Then you can get all the addresses that can ever exist with any path that you like as long as it comes after this extended key.

If you have ...
- Master public key (a long string starting with "xpub")
Then you can only get addresses that are not hardened

If you have ...
- Individual private key(s)
- Individual public key(s)
- Individual address(es)
Then you can't associate them together or find their master key.

If you have ...
- A master public key + a derived non-hardened private key
Then there may be a way for an attacker to find the master key.
Archive link : https://archive.fo/vfZEc
Short comment/info : A neat list to find all correlated address with/without private key from piece of information that you have.

#5
How far can possibly bitcoin blockchain height diverge from the ideal one- block-per-10-minutes measure?

Motivation
During a discussion with @gmaxwell about a hypothetical DoS vulnerability, in response to my suggestion for blacklisting peers that send block locators unreasonably large, he objected to my proposal by asserting that a loyal node may become maliciously bootstrapped and fooled to commit to a very long chain with trivial difficulty, so blocking it won't be helpful. I responded with a moderate version, ... but after further assessments, I realized that the whole situation is somewhat abnormal, the possibility of having honest nodes with an unreasonable perception of chain height.

In bitcoin, 10 minutes block time interval is not imposed synchronously nor integrally. Protocol adjusts the difficulty every 2016 blocks to keep the generation pace at 10 minutes target but a steady growth in network hash power makes it a possibility for chain height to exceed the ideal number based on 10 minutes generation rate. Actually maximum block height of the network as of this writing is #535461 while it is supposed to be ~504300 showing  a +6% divergence.

Not satisfied with the situation, I asked myself:
Why should we accept a proposed chain with an unreasonable longitude like 10 times or 1000 times longer than normal in the first place?
Why shouldn't we simply reject such proposals and shut down the peers who made them? Putting difficulty requirements aside, is it possible to have a chain orders of magnitude longer than normal?

In the malicious block locator scenario, a peer node, very commonly a spv, sends us a getheaders message with a payload of hundreds of thousands stupid hashes as block locator and instead of being rejected and banned we hopefully and exhaustively try to locate them one by one.

At first, @gmaxwell didn't believe it to be an attack vector because of the cpu bound nature of the processing involved but finally he made a pull request out of that discussion and it was committed to the source. Bitcoin core now puts a MAX_LOCATOR_SZ hardcoded to be equal to 101. So, we have block locator problem fixed now.

A block locator in bitcoin is a special data structure that spontaneously represents (partially) a node's interpretation of block headers in the chain. The spontaneous nature of block locator generation algorithm guarantees its length to be of O(log(n)) where n is the maximum block height in the chain, it is exactly 10+(log2(n)) . For current block height of 535461 a legitimate block locator should carry a maximum of 29 hashes and a node sending 30 hashes is claiming a chain with 1,073,741,824 height which is almost twice longer and it would be 2 million times longer if block locator was holding 50 hashes. Yet we were worried about block locators holding thousands of hashes which represent chains with astronomical heights.

Although the issue is fixed now, the underlying theoretical base didn't get the attention it deserves: A boundary for the divergence of actual block chain's height  from what we could trivially calculate by dividing the minutes elapsed from an accepted checkpoint block's  timestamp by 10 (normal block interval).

At the time of this writing, the divergence is  6+% but we have no measure to consider 60%, 600% , 6,000,000,000% , ... divergence indexes infeasible, until now.

In  this article I'm trying to establish a mathematical framework for further research on this problem, by introducing a relation between hash power increase requirements for a specific divergence within a relatively large window of time.

I also found it useful to include a background section for interested readers, if you are familiar with the subjects, just skip this section.

Background

Difficulty adjustment: How bitcoin keeps the pace
Two rules are applied in bitcoin protocol for regulating the rate by which blocks are generated:
1- Increase/decrease difficulty every 2016 blocks by comparing the actual time elapsed with an expected 2 week period.
2- Don't Increase/decrease difficulty with a factor greater than 4.

The latter constraint is commonly overlooked because such a large retargeting is very unlikely to happen with the huge inertia of the currently installed hash power but as we are studying extreme conditions, the 4 times increase factor is of much importance.

Longest Chain Rule: How Bitcoin chooses between forks
In bitcoin and its clones, LRU is not interpreted naively as selecting the chain with biggest height as the main, instead it is defined as the chain with most work needed to generate it.
To calculate accumulative work done on each chain:
1-work for each block is calculated as:  floor(2^256 / (target + 1))
This is done in chain.cpp of bitcoin source code via GetBlockProof function:
Code:
arith_uint256 GetBlockProof(const CBlockIndex& block)
  122 {
  123     arith_uint256 bnTarget;
  124     bool fNegative;
  125     bool fOverflow;
  126     bnTarget.SetCompact(block.nBits, &fNegative, &fOverflow);
  127     if (fNegative || fOverflow || bnTarget == 0)
  128         return 0;
  129     // We need to compute 2**256 / (bnTarget+1), but we can't represent 2**256
  130     // as it's too large for an arith_uint256. However, as 2**256 is at least as large
  131     // as bnTarget+1, it is equal to ((2**256 - bnTarget - 1) / (bnTarget+1)) + 1,
  132     // or ~bnTarget / (bnTarget+1) + 1.
  133     return (~bnTarget / (bnTarget + 1)) + 1;
  134 }

2- During loading/adding a block to block index in memory, not only the block work is computed by calling the above function but also an accumulated chain work is aggregated in nChainWork with this ocde:
Code:
pindex->nChainWork = (pindex->pprev ? pindex->pprev->nChainWork : 0) + GetBlockProof(*pindex);
which is executed both in LoadBlockIndex and AddToBlockIndex.

The forks are compared based on nChainWork of BlockIndex item of their respective last block and once a chain is found heavier than current active chain a reorg will be performed mainly by updating UTXO and pointing to new chain as the active fork.

Between two difficulty adjustments, this the-most-difficult-chain-is-the-best-chain approach is identical to the-longest-chain-is-the-best-chain originally proposed by Satoshi but when we have to choose between two forks with at least one difficulty adjustment (typically in both forks) there is no guarantee for the results to be identical.

Block timestamp:How bitcoin keeps track of time
In bitcoin few rules apply to block time and current time. This is an important topic for the purpose of this article, defining an upper bound for the height of forks, because to impose such a boundary a node should eventually have a measure of  time and it is not simply its own system clock for obvious reasons.

1- Bitcoin defines a concept named network-adjusted time. It is defined to be the median of times reported by all the peers a node is connected to.

2- In any case network-adjusted time shouldn't offset node's local time more than 70 minutes.

3- Blocks should be marked with a timestamp greater than the median of previous 11  blocks and less than 2 hours after node's network-adjusted-time.

These constraints make it very hard for an adversary to manipulate block times and forging fake chains with fake difficulty and height which is our concern.


Abstract
The short-range difficulty adjustment policy of bitcoin causes a divergence of expected chain height (expected from ideal 10 minutes block time) because of increased hashpower during each epoch, we show that this divergence is exponentially difficult by proving a functional dependency between the ratios by which hash power and the divergence increase: F = (n/N)^n

To prove this relation, we primarily show the maximum divergence caused by introducing any amount of new hashpower to the network in a specific period of time is achieved when its distribution in epochs, is representable by a geometric  progress.

The 4 times maximum threshold imposed by difficulty adjustment algorithm of network is deliberately ignored to to avoid complicating the discussion. It is a justifiable simplifying assumption in the context of this article because a 4+ times per epoch increase in hashpower is not feasible  anyway, as we shortly discuss at the end of the article.

After proving the exponential dependency, we briefly illustrate and discuss its relevance to block locator size problem and other interesting potentials for dealing with similar problems generally.

Lemma:
Suppose at the end of a difficulty adjusting epoch we have already chosen as  a check point and has started at time t0 we have calculated an average hashpower C as current network hashpower and begun to introduce Q as a relatively large hashpower in a period of time t, greater than or equal to 1 ideal difficulty adjustment epoch time T0. The number of epochs n that occur in period [t0, t0+t], is at its maximum when Q is distributed in a way that the network hashrate would go through a geometrical progression With:
 
Ci = C*qi
and we have Sum(Ci-Ci-1)=Q the increased hash power:
proof:
For a network state at the end of a given epoch that is in equilibrium with hashpower C and an arbitrary distribution of new power Q in n epochs we have the sequence
C, C*k1, (C*k1)*k2, ...,  (C*ki-1)*ki, ..., (C*kn-1)*kn
defined recursively as :
Ci=Ci-1*ki , C0 = C
Observing that for n+1>i>0:
Ci=C*K1*k2*...*ki=C*K1k2...*ki
and in the end of application of power Q, we have a total hashpower of C+Q that is equal to the last term of the sequence
We have to prove for n+1>i>0 we have k1=k2=...=kn=q for the n epochs to occur in the least possible actual time. For this, we note that in the end of each epoch the difficulty adjustment algorithm of bitcoin  (4 times limit temporarily being ignored) resets block generation pace to T0 for future epochs, so in each epoch we have:
ti= Ci/Ci-1 = (C*K1k2...ki-1)/ (C*K1k2...ki) = 1/ki
For total elapsed time t during n epochs, we have:
T = T0+T0*1/k1+T0*1/k2+... +T0*1/kn
Then:
T/T0 =1+1/k1+1/k2+...+ 1/kn
                        = 1+ f(k)/(k1k2...kn-1kn
                         = 1+f(k)/ ((C+Q)/C) )
Where f(k) is the sum of the sequence:
ai = k1k2...kn/ki
, now we need to have this sum in its minimum. We first calculate the product of the terms as prod(ai) = (k1k2...kn)n-1 = ((C+Q)/C)n-1

where ((C+Q)/C) and n-1 are constants and the sum is minimum when a1=a2=...=an hence:
k1=k2=...=kn
Now we have proof because for the minimum time to be elapsed the power sequence definitively should be rewritten as:
Ci = Ci-1*q = C0*qi
where C0 = C and n+1>i>1  which is a sequence with geometric progression.

Theorem
Minimum hashpower growth factor F = (Q+C)/C needed for bitcoin blockchain* to grow by an abnormal ratio n/N is determined by F=(n/N)^n
 
where C is current  hashpower of the network and Q is the absolute increase during a period of N*T0.

*Note: Bitcoin difficulty adjustment algorithm applies 4 times maximum threshold that is ignored deliberately for practical purposes

Proof
For a given F = (Q+C)/C Using the geometric progress lemma above we have:
t=T0*n/q    ==> t/T0=N=n/q ==> n/N = q
and
Q=C*(qn-1) ==> (Q+C)/C=F=qn
eliminating q:
F=(n/N)n

Discussion
The exponential relationship with the ratio of power increase and the ratio by which blockchain height diverges from normal N=t/T0 is an important key to understand how impractical would be for a network like bitcoin with tens of thousands penta hash inertia (C) to diverge from its normal behavior in terms of longitude (chain height).
Let's have a graphical illustration of this function. We replace n with N+d where d is the number of abnormally added epochs. So F=((N+d)/N)(n+d)
This form of the equation illustrates how F (relative hashpower) should grow to have N+d epochs instead of N, normal epochs.

figure 1: F/d diagram with various N values for F up to 30 times hashpower increase
Figure 1 illustrates how hard is achieving to 2-3 epochs divergence in 3,6,12,24 standard epoch times (two weeks long each) e.g for reaching to 3 epochs divergence within 24 weeks (12 epochs) even 40 times increase in network hashpower doesn't suffice.

Figure 2 (below) illustrates the same function in larger scale (1000 times hashpower increase). To diverge 6 epochs within 48 weeks we need 800 times increase in network hash power and within 24 weeks even with 1000 times increase divergence can't approach 6.
figure 2: F/d diagram with various N values for F up to 1000 times hashpower increase

This exponential behavior is very interesting and  potentially can be used as a basis for confronting malicious bootstrap attacks and issues like what we mentioned in the beginning of this article: bogus block locator issue.

As of the 4 times maximum threshold bitcoin uses for difficulty adjustment, obviously having a 4 times or more increase in each epoch for the network is infeasible specially when it comes to large windows of time, like 1-2 years that cause exponential network hash power increase up to infeasible quantities. Hence, ignoring that threshold practically won't affect this analysis.

Archive link : https://archive.fo/wzCf9
Short comment/info : An interesting analysis which shows actual mean block time is only 9.4 minutes, not 10 minutes mainly due to difficulty adjustment every 2 weeks. Simply calculate (timestamp of current block height - timestamp of block #1) / current block height if you doubt it.


#6
Hi together,

I'm an IT-student and writing a thesis about atomic swaps on BTC and BTC-like blockchains. For the thesis I decided to use BTC, LTC, BCH and DCR. These chains have a somehow similar codebase and the same scripting language (I'm not a professional, so there might be differences, but they are not that serious). And they all have a high enough marketcap to be relevant for atomic swaps.
So the goal of the thesis is to find hashed timelock contracts (HTLCs) and connect matching HTLCs from different chains to get the atomic swap. Therefore I first searched the web for anything on atomic swaps [1] and analyzed the input script of this transaction [2] to get a basic understanding how atomic swaps work and what they look like.
Then I wrote a go program to search for any script longer than simple P2PKH scripts. This gave me a list of many different scripts which I analyzed by hand to only take the HTLC ones. (Besides many multisig scripts, there is not much to find on BTC^^)
At this point I found multiple different types of HTLCs as listed below. Afterwards I crawled* BTC again saving all transactions with HTLC scripts, storing the interesting data like tx-id, input value, pubKeyHashes, the secrets and their hashes. I found about one hundret HTLCs on BTC so far.
I did the same for LTC and found about 400 HTLCs.
As far as I understood, the secrets of HTLCs have to be the same on both chains. So I wrote another go program to match the found HTLCs from BTC and LTC and got around 30 matches. The next steps would then be to crawl BCH and DCR and also match the HTLCs found there.

* Crawling in this case means that I start to search the blockchain backwards (to get the newest first, the beginning years are not that interesting in this case^^) until the beginning of 2017. So about 18 months. As stated in [1] the first known atomic swap between BTC and LTC was made on 19th April 2017 (or April 19th 2017 or 19.4.2017 or whatever you like). So there is not much sense in crawling any further.

My questions now are the following:

  • Why are there so many different types? Is it compatibility with other chains? Or what?
  • What are the differences between these types (besides length and hashing algorithm)?
  • What are the advantages and disadvantages of these types?
  • Why are there so many HTLCs on LTC and so few on BTC?
  • Do you know other such HTLC scripts?
  • Can you provide interesting resources on this topic?

I'm open to any constructive input and hope you have a few answers for me. Thank you in advance.

Type 1: sha256 secret, length=97byte
Code:
63 if
82 size
01 data1
20
88 equalverify
a8 sha256
20 data32
<secret_hash 32byte>
88 equalverify
76 dup
a9 hash160
14 data20
<pubkey_hash1 20byte>
67 else
04 data4
<timelock 4byte>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
68 endif
88 equalverify
ac checksig

Type 2a: sha256 secret, length=94byte
Code:
63 if
a8 sha256
20 data32
<secret_hash 32byte>
76 dup
a9 hash160
14 data20
<pubkey_hash1 20byte>
88 equalverify
ac checksig
67 else
04 data4
<timelock 4byte>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
88 equalverify
ac checksig
68 endif

Type 2b: sha256 secret, length=93byte
Code:
63 if
a8 sha256
20 data32
<secret_hash 32byte>
88 equalverify
76 dup
a9 hash160
14 data20
<pubkey_hash1 20byte>
67 else
04 data4
<timelock 4byte>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
68 endif
88 equalverify
ac checksig

Type 3: ripemd160 secret, length=81byte
Code:
63 if
a6 ripemd160
14 data20
<secret_hash 20byte>
88 equalverify
76 dup
a9 hash160
14 data20
<pubkey_hash1 20byte>
67 else
04 data4
<timelock 4byte>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
68 endif
88 equalverify
ac checksig

Type 4a: hash160 secret, length=86byte
Code:
63 if
03 data3
<timelock 3byte>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
88 equalverify
ac checksig
67 else
76 dup
a9 hash160
14 data20
<secret_hash 20byte>
88 equalverify
ad checksigverify
82 size
01 data1
21 -> 33
88 equalverify
a9 hash160
14 data20
<pubkey_hash1 20byte>
87 equal
68 endif

Type 4b: hash160 secret, length=82byte
Code:
63 if
03 data3
<timelock 3byte>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
88 equalverify
ac checksig
67 else
76 dup
a9 hash160
14 data20
<secret_hash 20byte>
88 equalverify
ad checksigverify
a9 hash160
14 data20
<pubkey_hash1 20byte>
87 equal
68 endif

Type 5a: hash160 secret, length=81byte
Code:
63 if
a9 hash160
14 data20
<secret_hash 20byte>
88 equalverify
76 dup
a9 hash160
14 data20
<pubkey_hash1 20byte>
67 else
04 data4
<timelock 4byte>
b2 checksequenceverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
68 endif
88 equalverify
ac checksig

Type 5b: hash160 secret, length=78byte
Code:
63 if
a9 hash160
14 data20
<secret_hash 20byte>
88 equalverify
76 dup
a9 hash160
14 data20
<pubkey_hash1 20byte>
67 else
01 data1
<timelock 1byte>
b2 checksequenceverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
68 endif
88 equalverify
ac checksig

Type 6: hash160 secret, length=79byte
Code:
63 if
54 <timelock op>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
88 equalverify
ac checksig
67 else
76 dup
a9 hash160
14 data20
<secret_hash 20byte>
88 equalverify
ad checksigverify
a9 hash160
14 data20
<pubkey_hash1 20byte>
87 equal
68 endif

Type 7: multiple ripemd160 secrets, length=80 + n*23byte
Code:
63 if
a6 ripemd160
14 data20
<secret_hash1 20byte>
88 equalverify
a6 ripemd160
14 data20
<secret_hash2 20byte>
...
88 equalverify
a6 ripemd160
14 data20
<secret_hash_n 20byte>
88 equalverify
21 data33
<signature1 33byte>
ac checksig
67 else
04 data4
<timelock 4byte>
b1 checklocktimeverify
75 drop
21 data33
<signature2 33byte>
ac checksig
68 endif

Type 8: multiple ripemd160 secrets, length=81 + n*23byte
Code:
74 depth
60 16
87 equal
63 if
a6 ripemd160
14 data20
<secret_hash1 20byte>
88 equalverify
a6 ripemd160
14 data20
<secret_hash2 20byte>
...
88 equalverify
a6 ripemd160
14 data20
<secret_hash15 20byte>
88 equalverify
21 data33
<signature1>
67 else
03 data3
<timelock 3byte>
b1 checklocktimeverify
75 drop
21 data33
<signature2>
68 endif
ac checksig

[1] http://www.cryptovibes.com/crypto-news/charlie-lees-atomic-swap-between-litecoin-and-bitcoin-was-a-success/
[2] https://insight.bitpay.com/tx/0bb5a53a9c7e84e2c45d6a46a7b72afc2feffb8826b9aeb3848699c6fd856480
Archive link : https://archive.fo/TXnno
Short comment/info : Interesting research since few people thought atomic-swaps could bring better privacy while atomic-swaps transaction on both coins have same secret which could lead to de-anonymization. He also release his thesis and script on below posts (https://bitcointalk.org/index.php?topic=4686439.msg45980025#msg45980025), even though the paper is in German and the script only works with their own daemon.
392  Other / Ivory Tower / Re: New Goldman Sachs stable coin. Tether doomed? on: October 08, 2018, 03:46:55 PM
It also has many advantages:
- You can postpone taxes.
- You can trader easier and faster, without payment taxes and anonymously.
- there are nice trading pairs. There are more USDT pairs than EUR pairs, for example.


There are many other risks associated, and you have no guarantee that tether will pay 1 usd for each usdt.... but it's very convenient

Thanks for the information, the advantage seems tempting to those who prefer convenience over security/decentralization. At least, it's better than using banks in many ways.

Fortunately, somebody came up with a decentralized version of a stablecoin, so nobody has to trust a company, unless they want to. It's all done through a smart contract so completely autonomous, always worth ~1$ and backed by ethereum value, so you don't have to wonder or trust an institution to hold the counter value. It's quite amazing  Smiley

More details in here:

https://medium.com/@james_3093/the-dai-stablecoin-is-a-game-changer-for-ethereum-and-the-entire-cryptocurrency-ecosystem-13fb412d1e75

And as you can see in here people are using it https://coinmarketcap.com/currencies/dai/

I'm sure it can't be categorized as stable coins since CDP owners participation is required to keep it stable and i doubt it would work on reality. I only can agree the concept is amazing.
393  Bitcoin / Development & Technical Discussion / Re: Semi-Full Bitcoin Node. Downloading from ONLY pruned nodes. on: October 08, 2018, 03:32:32 PM
The impression I get is that people either decide to run a full node on purpose or just go straight for a SPV wallet. Running a "semi-full" node (eg. Bitcoin Core with pruning enabled) seems to be the exception. Accordingly I doubt that providing the ability to run a semi-full node increases the overall node count much. However I'm just extrapolating from anecdotal observations without having anything substantial to back this claim up, so don't take my word for it.

Furthermore, the cost of running pruned nodes isn't much difficult compared to full-nodes excluding :
1. storage space requirement
2. bandwidth used to sent transaction/block which it's UTXO already spend/no longer pruned

SPV wallet with Tor/similar and Dandelion is better choice while preserve some anonymity/security.

I think the problem at hand is, that the fewer full nodes there are, the more traffic they need to bear. This in turn will make running a full node even harder, causing more full nodes to drop off, further increasing the traffic on the remaining nodes until only a handful of very costly full nodes are left. And every new pruned node that comes online needs these full nodes to bootstrap, lest they won't even become a semi-full node.

Ethereum is the prime example, running full/archive node already expensive since you need SSD due to intensive I/O operation which makes most people only pruned/warp/fast node and light/SPV wallet. I hear both full/archive node and pruned/warp/fast accessed by more lesser nodes and means higher bandwidth usage.
394  Bitcoin / Development & Technical Discussion / Re: open source web wallet for the cryptocurrency on: October 08, 2018, 03:09:06 PM
The easiest way is cloning from existing web wallet which is open-source such as :
1. Blockchain.info at https://github.com/blockchain
2. coin.space at https://github.com/CoinSpace/CoinSpace
3. MyEthereWallet at https://github.com/MyEtherWallet/MyEtherWallet. This is probably what you're looking for since AFAIK they don't store private key/seed at their server.

But looks like none of them using language you prefer.
395  Bitcoin / Bitcoin Technical Support / Re: Transfer status Local on: October 08, 2018, 02:57:33 PM
I only sent to one address as i normally do in mbtc. Form...51mbtc still stored locally...ive tried over and over to broadcast. But get the same error message....a bug?  Strange..  If it wasent for bad luck id have no luck at all

Thank guys

At this point, i only can suggest 2 things :
1. Import your seed to Electrum desktop and remake your transaction from there, Electrum desktop is more "matured" compared to it's android version.
2. Backup your seed, delete Electrum, reinstall Electrum & choose "Restore your seed" when create new wallet.

p.s. there's no luck involved at all Tongue
396  Bitcoin / Development & Technical Discussion / Re: Why hardware personal wallets are almost impossible to hack unlike exchanges? on: October 08, 2018, 02:48:05 PM
Canít exchanges function like big hardware wallets where he who hasnít the seeds canít control the funds?

In theory it's possible by :
1. Generate bunch of hardened child address from xpub/xprv and assign it to each users
2. Process all withdraw manually every few hours / day with extra checking/confirmation as additional security in case there's data manipulation attempt
p.s. exchange who do it might want to generate unsigned transactions automatically automatically

But obviously it's pain in ass and make the exchange non-competitive.

But in this specific case, i don't see it as a exchange-related problem. Sure, an exchange was used to monetize a 51% attack, but a hardware wallet wouldn't have protected you either.

For example:
  • you were selling irreversible digital goods and accepted "Bitcoin Gold" as a payment method
  • you generated a "Bitcoin Gold" address using your hardware wallet
  • the "bad guy" funded your address
  • You transfered the digital goods without waiting for sufficient confirmations
  • the "bad guy" executed the 51% attack, excluding the tx funding your address and including a tx that spends the unspent output used to fund your address

In this case, you would have been robbed, even when you were using a HW wallet...

FYI, Bitcoin Gold also use 10 minutes block interval and previous attack reverse 21 blocks which is far above common minimum required confirmation (which is between 1-6 blocks). In this case, almost all user/services would be affect and the only solutions are another rollback or/and ridiculous minimum confirmation amount.
397  Other / Ivory Tower / Re: New Goldman Sachs stable coin. Tether doomed? on: October 07, 2018, 06:53:20 PM
I don't see why people like stable coins, i mean there are many disadvantage including :
1. I don't see how people could earn profit since the price supposed to be stable
2. High-degree of trust towards company/developer is required
3. No guarantee it's no censorship-resistance or could provide anonymity in any way
4. I doubt any of stable coins can be redeemed back to USD or other pegged currencies easily

Looks like this coins might succeed since investor feel their money/investment is safe since it's created by Goldman Sachs and regulated, but i doubt Tether is doomed since any early product/technology which gain popularity shortly after launch won't die easily even if there's better product/technology.
398  Economy / Gambling discussion / Re: Anyone betting on PUBG? on: October 07, 2018, 05:55:17 PM
I wouldn't bet my money on PUBG with that rules even if i'm skilled, because :
1. High rate of cheater (since there's 13 million banned player)
2. Few ridiculous bug which means you could survive or die in dumb way
3. Few skilled people could work together and have higher kill count/person as team

But, there's no problem if we're talking about betting on PUBG's professional match with reputable host
399  Alternate cryptocurrencies / Marketplace (Altcoins) / Re: 💎Amber Game💎 Ignite Gems and Reap Rewards on the Ethereum Blockchain 💎 on: October 07, 2018, 05:40:07 PM
Clearly it's ponzi/MLM combined with refferal/downline which uses video game and stylish visualization as camouflage to trick newcomers. ETH users isn't that stupid, especially after infamous FOMO3D with it's war attrition concept.
400  Other / Meta / Re: Small QOL change to consider on: October 07, 2018, 05:31:10 PM
Existing database will require a field alteration.

There's an ugly solution which is storing enter as "\n" on comment field.
Also, we actually don't know the field type and perhaps it already supports enter.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [20] 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 ... 294 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!