The Math Behind Bitcoin - CoinDesk

Monero is pure digital cash

I thought I would put some thoughts and information I had on Monero in a Reddit post. I expect we will have quite a few people searching the net in the coming months / years as they study up on what this is all about. With the rise of state surveillance of blockchain transactions, the need for a truly free and private decentralized system will become more important than ever. There is a ton of misinformation out there during these times and it can be difficult to gain perspective. I hope this bit of info helps you understand why XMR stands out among the rest of the blockchains today.
Monero, a pure digital cash:
I exclusively use XMR over Bitcoin when transacting in crypt0. The fees are much cheaper than BTC for moving money around daily and its much more private. It's also the only crypto that truly behaves like cash notes. It uses different and stronger privacy methods in comparison to all the other privacy oriented coins and It also uses a different Elliptic-curve than all of them. For example, BTC/ZEC/DASH all use secp256k1. It was created by the NSA. Monero uses an Elliptic-curve called edwards25519. ed25519 was created by the academic community and has been reviewed extensively from cryptographers for over a decade and is widely deployed in the real world. I find it quite odd that Bitcoin was the first known application to utilize secp256k1.
Monero is much like Bitcoin was when it first began. It started grassroots, no one owns or controls Monero. I see it as a pure crypt0. Its mining is currently more decentralized and fair than Bitcoin and its competitors like Zcash. It also has no centralized mining cartels in China or elsewhere due to ASICs.
One of the other things that drew me to Monero besides the technology was the name. The name Monero itself is from a decentralized language known as Esperanto.
-- How is Esperanto a "decentralized language", how is it similar to a decentralized currency?
Esperanto was created from scratch just like Monero's protocol. It also has similarities with its vastly more successful digital cousins such as, C++, HTML, Python — Like these Esperanto is an artificial language, designed to have perfectly regular grammar, with none of the messy exceptions of natural tongues. It was created in the late 1870s and early 1880s by L.L. Zamenhof, a Polish-Jewish ophthalmologist from Bialystok, then part of the Russian Empire, but now part of Poland. The language is closely related to many of the romance languages. This is one reason I love Monero. I think psychologically it will appeal to a wider range of people around Earth. For example, these are the proportions of lexemes that are common to Esperanto and other languages: 91.64 percent French; 89.50 percent English; 89.12 percent Italian; 87.79 percent Portuguese; 87.12 Spanish; 81.70 percent German; 64.78 percent Latin; 53.26 percent Russian. There are Esperanto speakers in places you would never expect in every corner of the planet from China, India all the way to Africa. According to Zamenhof, he created the language to reduce the time and labour we spend in learning foreign tongues and to foster harmony between people from different countries. "Were there but an international language, all translations would be made into it alone...and all nations would be united in a common brotherhood."
Zamenhof lived in a time of oppression of Jews and he started something called "Homaranismo". He wanted people to free their minds from the narrow fact that things such as a Jew, Russian or a German even exist and called for people to understand ourselves and not as part of a religion, language or a race but simply as human beings. He opposed Zionism and the occupation of Palestine and wanted Jews and Muslims to live in peace.
Here are the first four dogmas of Homaranismo, the most principal and general:
  1. I am a human and I exist solely for purely human ideals; I view all sorts of ideals and targeted nationalisms as nothing but group egotism and hate towards people, which sooner or later must disappear and their disappearance I must be a catalyst to, to the best of my ability.
  2. I believe, that all populations are equal and I evaluate all people only by their personal value and deeds but not according to descent. For this I regard all persecutions carried out against others based on the fact that they were born to a different race, with a different language or religion as barbarism.
  3. I believe that every country does not belong to one or another race, but more justly to all its inhabitants, regardless of language or religion; I view the shuffling of interests of the land and interest of one or the other race, language or religion as leftovers from barbaric times, when the fist and sword right was solely accepted.
  4. I believe that in one's own family one has indisputable, complete natural right to speak whichever language and dialect they may desire, and adhere to whichever religion they themselves choose, but in communications with people of different descent one should, when possible, use a neutral language and live according to religion neutral principles. All striving of one person to impose one's language or religion onto others I view as a barbaric act.
Some final thoughts in conclusion...
I have thought deeply about this over the years and I think the word "Monero" fits great for a currency...being from India although Esperanto does not closely relate to any language here, I find it very easy to learn and speak. For these reasons as well as other technical ones I believe in the long run Monero has the best chance out of any crypto to be adopted as Money throughout most of the world.
These are just some of the reasons I love the Monero project....I hope this bit of info sparks your interest to research Monero further and helps you on your journey down the rabbit hole of crypt0 my friends.
submitted by zeroknowledgeproofs to Monero [link] [comments]

Can a quantum computer be used for bitcoin mining?

This has been bothering me for a while.
I'm a newbie in computer science, and I just found out about Grover’s algorithm, which can only be implemented on a quantum computer. Supposedly it can achieve a quadratic speedup over a classical computer, brute-forcing a solution to a n-bit symmetric encryption key in 2^n/2 iterations.
This led me to think that, by utilizing a quantum computer or quantum simulator of about 40-qubits that runs Grover's algorithm, is it possible to mine bitcoins this way? The current difficulty of bitcoin mining is about 15,466,098,935,554 (approximately 2^44), which means that it would take about 2^44*2^32=2^76 SHA256 hashes before a valid block header hash is found.
However, by implementing Grover's algorithm, we would only need to sort through 2^76/2=2^38 hashes to discover a valid block header hash. A 38-qubit quantum computer should be sufficient in this case - which means the 40-qubit quantum computer should be more than enough to handle bitcoin mining.
Therefore - is it possible to use quantum computers to mine bitcoins this way? I'm not too familiar with quantum computers, so please correct me if I missed something.......
NOTE: I am NOT asking whether it is possible to use quantum computers to break the ECDSA secp256k1 algorithm, which would effectively allow anyone to steal bitcoins from wallets. I know that this would require much more than 40 qubits, and is definitely not happening in the near-future.
Rather, I'm asking about bitcoin mining, which is a much easier problem than trying to break ECDSA secp256k1.
submitted by Palpatine88888 to QuantumComputing [link] [comments]

A good reminder of what we (BCH) gained from the hardfork, a review of all the lies and broken promises by CSW

From Jonald Fyookball's Medium Article
https://medium.com/@jonaldfyookball/bitcoin-cash-is-finally-free-of-faketoshi-great-days-lie-ahead-bb0c833e4c5d
Some background on Craig’s claim of being Satoshi, for the uninitiated:
  1. He faked blog posts
  2. He faked PGP keys
  3. He faked contracts and emails
  4. He faked threats
  5. He faked a public key signing
  6. He has a well-documented history of fabricating things bitcoin and non-bitcoin related
  7. He faked a bitcoin trust to get free money from the Australian government but was caught and fined over a million dollars.
And specifically concerning his claim to be Satoshi:
  1. He has provided no independently verifiable evidence
  2. He is not technically competent in the subject matter
  3. His writing style is nothing like Satoshi’s
  4. He called bitcoin “Bit Coin” in 2011 when Satoshi never used a space
  5. He actively bought and traded coins from Mt. Gox in 2013 and 2014
  6. He was paid millions for ‘coming out’ as Satoshi as part of the deal to sell his patents to nTrust — for those who claim he was ‘outed’ or had no motive

Caught Red Handed Plagiarizing

No respectable academic, scientist, or professional needs to stoop so low as to steal and take credit for the work of others — least of all Satoshi. Yet, CSW has already been caught at least 3 times plagiarizing.
  1. His paper on selfish mining has full sections copied almost verbatim from a paper written by Liu & Wang.
  2. His “Beyond Godel” paper which purports to claim that Bitcoin script is turing complete, is heavily plagiarized.
  3. A paper on block propagation was blatantly and intentionally plagiarized.

Can’t Even Steal Code Correctly

CSW was also caught attempting to plagiarize a “hello world” program (the simplest of all computer programs).
He apparently does not understand base58 or how Bitcoin address checksums work (both of these are common knowledge to experienced Bitcoiners), and has made other embarrasing errors.
Broken Promises
He said he was building a mining pool to “stop SegWit”
submitted by stewbits22 to btc [link] [comments]

A reminder of who Craig Wright is and the benefits to BCH now he has gone.

This needs to be repeated every so often on this subreddit so new people can understand the history of the fork of BCH into BCH and BSV
From Jonald Fyookball's article
https://medium.com/@jonaldfyookball/bitcoin-cash-is-finally-free-of-faketoshi-great-days-lie-ahead-bb0c833e4c5d
Craig S. Wright (CSW) leaving the Bitcoin Cash community is a wonderful thing. This self-described “tyrant” has been expunged, and now we can get back to our mission of bringing peer-to-peer electronic cash to the world.
The markets will rebound when they see the chaos is over, but regardless of the price, we will keep building. Nothing will stop the sound money movement. Calling Out Bad Behavior
As Rick Falkvinge recently explained, there is a difference between small-minded gossiping about personalities and legitimately calling out bad behavior.
CSW’s bad behavior must be called out, because he has done tremendous damage to Bitcoin Cash (and possibly even the entire cryptocurrency sector).
The brief history is that he gained his reputation by claiming to be Bitcoin’s creator (Satoshi Nakamoto). He said he would provide “extraordinary proof” but he has never done so.
Supposedly, he did some “private signings” to a few people, and this allowed him to gain influence in the BCH community. The destruction he has been causing was not widely recognized until after a huge mess had been made.
Thanks to u/Contrarian__ for the following compliation of CSW’s misgivings:
Some background on Craig’s claim of being Satoshi, for the uninitiated:
He faked blog posts He faked PGP keys He faked contracts and emails He faked threats He faked a public key signing He has a well-documented history of fabricating things bitcoin and non-bitcoin related He faked a bitcoin trust to get free money from the Australian government but was caught and fined over a million dollars. 
And specifically concerning his claim to be Satoshi:
He has provided no independently verifiable evidence He is not technically competent in the subject matter His writing style is nothing like Satoshi’s He called bitcoin “Bit Coin” in 2011 when Satoshi never used a space He actively bought and traded coins from Mt. Gox in 2013 and 2014 He was paid millions for ‘coming out’ as Satoshi as part of the deal to sell his patents to nTrust — for those who claim he was ‘outed’ or had no motive 
Caught Red Handed Plagiarizing
No respectable academic, scientist, or professional needs to stoop so low as to steal and take credit for the work of others — least of all Satoshi. Yet, CSW has already been caught at least 3 times plagiarizing.
His paper on selfish mining has full sections copied almost verbatim from a paper written by Liu & Wang. His “Beyond Godel” paper which purports to claim that Bitcoin script is turing complete, is heavily plagiarized. A paper on block propagation was blatantly and intentionally plagiarized. 
Can’t Even Steal Code Correctly
CSW was also caught attempting to plagiarize a “hello world” program (the simplest of all computer programs).
He apparently does not understand base58 or how Bitcoin address checksums work (both of these are common knowledge to experienced Bitcoiners), and has made other embarrasing errors. So How Did Such an Obvious Fraud Gain So Much Power and Influence?
There are no easy answers here. It seems that as humans, we are very susceptible to manipulation and misinformation. The greatest weapon against sinister forces is a well-educated populace. This is something that can only improve over the long run.
The “Satoshi factor” is a powerful one and appeals to the glamorization of a mythical figure. Even people such as myself, who are technically astute, gave CSW all benefit of the doubt until the evidence staring us in the face could no longer be denied.
The seduction of the BCH community was also facilitated by CSW becoming a strong advocate for the on-chain/big-block scaling movement at a time when the community was dying to hear it. This message, delivered with a brazen, in-your-face style, was a sharp contrast to anything seen before.
In addition, CSW was able to find obscure topics (“2pda”), network topology, etc, that seemed to establish him as an expert with esoteric knowledge above and beyond anyone else. Basically, he was using technobabble, but it wasn’t immediately obvious except to very technical people… who were then attacked and discredited.
Eventually, as more and more of the community began to realize his technical claims were bogus, CSW banned those people from his twitter feed and slack channel, leaving only a group of untechnical “believers”, which the larger BCH community referred to as “the church” AKA the Cult-of-Craig.
Finally, if some believed that CSW possesed Satoshis’s stash of 1M BTC, then they may have been gnawing to get a piece of it. But it may turn out that these are the coins that never were. Broken Promises
If this article so far seems like an “attack piece” on CSW, remember it is important to get all the facts out in the open. We’ll get to the silver lining and bright future in a moment… but let’s continue here to “get it all out”.
One of the biggest ways that CSW has damaged the community is to make an endless series of broken promises. This caused others to wait, to waste time on his unproven ideas and solutions, and to postpone or drop their own ideas and initiatives.
He said he was building a mining pool to “stop SegWit” He said he was bringing big companies to use the BCH chain He said that he was providing a fungibility solution based on blind threshold signatures He said he was providing novel technology based on oblivious transfers He said he was providing a method where people could do atomic swaps without using timelocks He said he was going to show everyone how we can do bilinear pairings using secp256k1 He said he was going to release source code for nakasendo He said he was releasing some information that would “kill the lightning network” He said he was going to show everyone how the selfish mining theory is wrong He said he was going to show everyone how we can tokenize everything in the universe squared He said a few times “big things are coming in 2 months” 
How CSW Has Damaged the BCH Community
In addition to the broken promises, the BCH community was wounded due to:
The division of the community (with classic divide and conquer tactics) Loss of focus. Huge amounts of drama and distraction from building and adoption Investor confidence has been shaken due to uncertainty and chaos. BCH is a laughing stock to outsiders due to CSW’s antics Gemini deployment of BCH and other rollouts paused Loss of developer talent due to toxic and abrasive personality Various patent and legal threats 
The Hash War Event and Split into BitcoinSV
Every 6 months, BCH has a scheduled network upgrade. This is technically a “hard fork” but a non-contentious fork does not result in a split of the chain — it is simply new network rules being activated.
Bitcoin Cash has multiple independent developer groups including Bitcoin ABC, Bitcoin Unlimited, Bitcoin XT, Bitprim, BCHD, bcash, parity, Flowee, and others.
The nChain group, led by CSW, introduced an alternate set of changes a week before the agreed cut-off date, intentionally causing a huge controversey. These changes were incompatible with the changes being discussed between the other groups.
nChain objected to the changes being proposed (cannonical transaction ordering) despite specifically agreeing to it almost a year earlier. The last minute objections were in my opinion, an attempt at sabotage.
An emergency meeting was held in Bangkok to attempt to resolve the differences between the nChain group and the rest of the community. Not only did CSW refuse to listen to the other presentations, he walked out of the meeting after his own speech had been given. The other nChain people refused to discuss the technical issues.
After this, nChain built their own software (“BitcoinSV”) to attempt to compete for the Bitcoin Cash network. But rather than split off to follow their own set of rules, they threatened to attack Bitcoin Cash.
Their attitude was “you follow our rules or we burn it all down”.
The CSW sycophants adopted a strange interpretation of the Bitcoin whitepaper and proselytized the idea that if nChain could “out hash” everyone else, the market should be obliged to follow them.
This faulty thinking was eloquently debunked by u/CatatonicAdenosine. As it turns out, nChain was unable in any case to win at their own game. But Here’s the Obviously Good News…
CSW is gone. It’s over.
He can do whatever he wants on the BitcoinSV chain. He will never be allowed to influence Bitcoin Cash again. And all the negative things and negative people that were a consequence of his involvement in Bitcoin Cash are gone with him.
As a community, we will redouble our efforts and get back to our mission of peer-to-peer electronic cash. We will learn to work together better than ever, and we will learn to detect and punish bad behavior sooner.
The attempted attacks with hashpower also sparked innovation and a focus on the problem of how to stop such attacks in the future. This is only making Bitcoin Cash (BCH) and the entire class of Proof-of-Work coins stronger.
Nothing will stop us.
The reason why millions of dollars were spent to attack and also to defend Bitcoin Cash is because it’s something truly worth fighting over.
It’s sound money.
It’s permissionless.
It’s what Satoshi Nakamoto wrote about in 2008. It’s Bitcoin, a Peer-to-Peer Electronic Cash System.
Bitcoin 
Go to the profile of Jonald Fyookball Jonald Fyookball More from Jonald Fyookball Jimmy Song Tries to Claim Bitcoin Cash is “Fiat Money”… Seriously? Go to the profile of Jonald Fyookball Jonald Fyookball Related reads 600 Microseconds Go to the profile of Awemany Awemany Related reads The scams in Crypto Go to the profile of Craig Wright (Bitcoin SV is the original Bitcoin.) Craig Wright (Bitcoin SV is the original Bitcoin.) Responses
submitted by stewbits22 to btc [link] [comments]

Bitcoin Verde v1.1.0 : Schnorr Signatures

For those unacquainted:
Bitcoin Verde is an indexing full-node, written from the ground up in Java. Bitcoin Verde comes with a block explorer, and a stratum mining pool. While we consider v1.1.0 still a beta release, our public node (https://bitcoinverde.org) has been stable since January.
Bitcoin Verde is the first to write a Schnorr Signature verification algorithm for Java (using Pieter Wuille's specification) ; if others implementations or wallets need to use our implementation as a reference, it can be located here. Verde's Schnorr implementation has been tested against the same suite of tests as ABC's (Test file located here). We intend to submit a pull request to Bouncy Castle sometime in the future.
Things that are new this release:
Similar to our previous release, Bitcoin Verde is very likely incompatible with Windows. Furthermore, it's an indexing node, and because of that will have more system requirements than a traditional node due to database indexes and the inherent underlying database structure. Our fully synced bitcoinverde.org node is currently using 615G disk space, and 21G of memory. Bitcoin Verde can be configured to run with far less memory, with a minimum around 2G. (Disable UTXO caching, disable TX Bloom Filter, set max database memory to ~1.5G). We highly recommend running BV on an SSD or M2. Traditional HDD drives are awful at random reads, and the last attempted initial-block-download we performed on an HDD took about 2+ weeks to complete.
If you have any problems with your node, please reach out to us at [email protected]. We'd be happy to help and troubleshoot problems. Alternatively, you can report bugs or issues to our github.
We've been diligently working on a mobile wallet based on the Bitcoin Verde codebase. We hope to provide a more modern replacement for bitcoinj, while also supporting SLP tokens. We are also ensuring all Bitcoin Verde SPV code can be transpiled to Objective-C (with Swift Bindings) for use on iOS. Finally, Bitcoin Verde is experimenting with a new message to improve the initial synchronization of SPV wallets called addrblocks, which will greatly improve the ability to validate SLP tokens. Additionally/alternatively, we have been looking at supporting BIP-157 for a more privacy-oriented way to achieve near-instant SPV synchronization; we look forward to sharing these thoughts in the near future.
Again, thank you to the XT team for your support. Another thank you for the ABC team for welcoming us into your conversations, and for helping us understand some of the nuanced aspects of this HF.
To install/upgrade your nodes, clone/pull master at https://github.com/softwareverde/bitcoin-verde, and reference the README under Installing/Upgrading.
submitted by FerriestaPatronum to btc [link] [comments]

Snowblossom (SNOW)

Snowblossom (SNOW)

Very interesting coin. Only at ~750k marketcap. Only being traded on a single exchange (qtrade). Seems to be completely under the radar, nearly no posts on reddit about it made so far.
Completely at ground floor with no marketing yet. Main developer has been working on Bitcoin projects and crypto since before 2012 (was the main developer for Satoshi Dice).
Clean, Original Code. Custom POW. UTXO Built into Blocks Headers. Truly ASIC, Miner Centralization, and Quantum Tough. No Premining.
Aggressive IO based PoW with large deterministic files should be very hard to ASIC in any sort of cost effective way. Increasing file size as hashrate increases means large SSDs and NVMEs will likely remain a competitve mining option.
Quantum Tough. It is estimated that a 256-bit elliptic curve (like bitcoin uses) could be broken by a quantum computer with about 1600 qubits. SnowBlossom has a QHard mode which does a 3-of-3 multisig (secp256k1, RSA 8192, DSTU 4145) which increases the required qubits to the 16,000 range.
UTXO root in block header. Allows giving provable results to light clients, such as browser based wallets and mobile apps.
Current supply: 2,113,650 out of a max of 21,000,000 (same mining curve as Bitcoin).
They also just released an Android wallet, and there is a lot of other stuff happening with the project. What does everyone here think?
submitted by Santalol to CryptoMoonShots [link] [comments]

TERA CRYPTO CURRENCY PROJECT

TERA is an open source and collaborative project. It means everyone can view and eventually modify its source code for hehis own needs. And it also means anyone is welcome to integrate its working community. The Tera community works to develop, deploy and maintain Tera nodes and decentralized applications that are part of the TERA Network.
The TERA technology serves the cryptocurrency concepts, trying to design a modern coins and contracts blockchain application : fast block generation, high transaction throughput and user-friendly application. It was officialy launched on 30th of June 2018 on the bitcointalk forum.
[Yuriy Ivanov](mailto:[email protected]) is the founder and core developer of the project. The Tera community is more familiar with the alias « vtools ».

USER FRIENDLY APPLICATION

In the aim to make this crypto currency project more friendly to end-users, some interesting innovations have been implemented in regards to the first generation of crpyto currency applications. The bitcoin and its thousands of child or fork, required a good level of IT skills in order to manage all the application chain from its own : from miners and its hardware, through stratum servers, proxies, to blockchain nodes. The Tera project intend to go one step further regarding crypto currency features integration into a single application : once installed, an efficient web application is available on localhost on port 8080. Then, any web browser supporting javascript may be able to access this application and to operate fully the Tera node.

MINING A CRYPTO CURRENCY

MINING CONCEPT

The mining activity consist in calling a mathematical procedure we can’t predict the result before we run it. But we intend to obtain a very specific result, which usually consist in a certain number of 0 as the first chars before any random answer. If we found the nonce (a random object) combined with the transaction data and the coin algorithm that produce such result, we’ll have solve a transaction block and we’ll get a reward for that. Thanks to this work, the transaction listed in the block will be added to the blockchain and anyone will be able to check our work. That’s the concept of ‘proof of work’ allowing anyone to replay the mathematical procedure with the nonce discovered by the node that solved the block and to confirm block inclusion into the blockchain.

POLITICAL AND ETHICAL CONSIDERATIONS

The Tera project is young. It will have to face the same problems is facing today the Bitcoin platform :
Any Crypto Currency Project with the goal its money and contracts to be used as any other historical money or service contract has to consider its political and ethical usage. Processes have to be imagined, designed and implemented in order to be able to fight against extortion, corruption and illegal activities threating crypto-currency development.

FAST BLOCK GENERATION AND HIGH THROUGHPUT

CLASSIC CRYPTO CURRENCY FEATURES

wallet, accounts, payments, mining, node settings and utilities, blockchain explorer and utilities…

DECENTRALIZED APP CATALOGUE

d-app : forum, stock exchange, payment plugins for third party platform, …

TECHNOLOGY DEPENDENCIES

Tera is entirely written in Java) over the NodeJS library as functional layer in order to take advantages of a robust and high level library designed to allow large and effective network node management.
The miner part is imported from an external repository and is written in C in order to get the best performances for this module.
Tera is actually officially supported on Linux and Windows.
If you start mining Tera thanks to this article, you can add my account 188131 as advisor to yours. On simple demand I’ll refund you half of the extra coins generated for advisors when you’ll solve blocks (@freddy#8516 on discord).

MINING TERA

Mining Tera has one major design constraint : you need one public IP per Tera node or miner. Yet, you can easily mine it on a computer desktop at home. The mining algorithm has been designed in order to be GPU resistant. In order to mine Tera coin you’ll need a multi-core processor (2 minimum) and some RAM, between 1 and 4GB per process that will mine. The mining reward level depends of the « power » used to solve a block (Top Tera Miners).

COST AND USAGE CONSIDERATIONS

There is two main cost centers in order to mine a crypto currency :
  1. the cost of the hardware and the energy required to make a huge amount of mathematical operations connected to the blockchain network through the Internet,
  2. the human cost in order to deploy, maintain and keep running miners and blockchain nodes.
As the speculation actually drives the value of crypto currencies, it is not possible to answer if the mining activity is profitable or not. Moreover, hardware, energy and human costs are not the same around the globe. To appreciate if mining a crypto currency is profitable we should take all indirect costs : nature cost (for hardware and energy production), human cost (coins and contracts usage, social rights of blockchain workers).

Original: https://freddy.linuxtribe.frecherche-et-developpement/blockchain-cryptocurrency-mining/tera-crypto-currency-project/
Author: Freddy Frouin, [email protected].
submitted by Terafoundation to u/Terafoundation [link] [comments]

Notes from Ethereum Core Devs Meeting #31 [1/12/18]

The next core dev meeting will be this Friday, January 26, 2018. The agenda and live stream link are located here.

Ethereum Core Devs Meeting 31 Notes

Meeting Date/Time: Friday 01/12/18 at 14:00 UTC

Meeting Duration: 1.5 hours

GitHub Agenda Page

Audio/Video of the meeting

Reddit thread

Agenda

  1. Testing Updates.
  2. Yellow paper update.
  3. EWASM update + update on the following related EIPs. a. EVM 2.0 - https://github.com/ethereum/EIPs/issues/48 b. Extend DUP1-16 / SWAP1-16 With DUPN / SWAPN - https://github.com/ethereum/EIPs/issues/174 c. Subroutines and Static Jumps for the EVM - https://github.com/ethereum/EIPs/issues/615
  4. Stateless client development.
  5. Add ECADD and ECMUL precompiles for secp256k1 - https://github.com/ethereum/EIPs/issues/603 [See this blog post for context].
  6. Introduce miner heuristic "Child pays for parent" (like in BTC) to combat the weird cases when transactions with 1000 Gwei stuck in the mempool (because they are dependent via nonce on transaction paying much less and not getting mined).
  7. Creating a relay network of nodes to mitigate issues described here and other transaction propagation issues.
  8. Fork release management/Constantinople.
  9. Client updates.
  10. Other non-agenda issues.

Notes

Video starts at [4:36].

[4:56] 1. Testing Updates

No updates.

[5:27] 2. Yellow paper update.

Gavin put the Yellow Paper under the Creative Commons Free Culture License CC-BY-SA. Yoichi and Nick Savers have been making progress handling the Yellow Paper PRs. There is still the somewhat unresolved issue of what should define the "formal standard" of Ethereum and should an update to the Yellow Paper or another specification be required for every new EIP. This can be discussed in more detail in future meetings when there is greater attendance.

[7:43] 3. EWASM update + update on the following related EIPs.

[7:55] General update

Ewasm contributors are currently meeting in person together in Lisbon. EWASM EIPs listed in the subpoints are not up to date and can be disregarded. People should use the github.com/EWASM/design repo. The design has been pretty much speced out in the last year. During the design phase there were 2 implementations done in parallel: Javascript and C++ (which can be integrated in cpp-ethereum and geth). Issues have been faced in building out EWASM including struggling with implementing synchronous code in Javascript/browser. Idea was to move to an asynchronous model. Currently there is not a full decision on using synchronous vs asynchronous, but we are leaning towards synchronous implementation in C++ to run a testnet in cpp-ethereum that can run pure Web Assembly contracts. Metering contract in Web Assembly is on the to-do list and doesn't rely on sync/async decision. Likely will take week to come to a decision on sync vs async. More technical discussion and a funny anecdote involving the asynchronous vs synchronous decision and the affects of the recent Spectre/Meltdown attacks start at [12:07].

[15:08] a. EVM 2.0 - https://github.com/ethereum/EIPs/issues/48

Martin Becze will be closing this EIP. It is outdated.

[15:28] b. Extend DUP1-16 / SWAP1-16 With DUPN / SWAPN - https://github.com/ethereum/EIPs/issues/174

This doesn't have to do with EWASM, it has to do with adding extra opcodes in the current EVM. It is an upgrade to EVM 1.0 which is not needed if we skip straight to EWASM.

[16:47] c. Subroutines and Static Jumps for the EVM - https://github.com/ethereum/EIPs/issues/615

Greg has been working with Seed (Gitter tag) who is writing an ELM formalization of the EIP. Greg says that there is no formal social process for deciding things like EVM 1.5 implementation so he is not sure if/when it would be implemented. Greg has been working on cleaning up the proposal for those who want to use it. Greg has some ideas around an EVM 3.0 that pulls everything together with transpilation that he hasn't started working on yet and is not sure if he will.

[20:14] 4. Stateless client development.

Piper left some comments about some development of a stateless client for sharding, but it is very early. Alexey had a blog post describing stateless clients he may re-approach later.

[21:46] 5. Add ECADD and ECMUL pre-compiles for secp256k1 - https://github.com/ethereum/EIPs/issues/603 [See this blog post for context].

This topic was brought up months ago with mixed commentary. Christian R. says that ECADD and ECMUL were never intended to be used for general purpose cryptography, but rather it was suppose to be used in conjunction with the pairing pre-compiles for a specific curve that is pairing friendly. Christian says that in the past it has been discussed that there must be a very compelling reason for adding a pre-compile to Ethereum. Silur mentioned that the Monero research team is working on a new ring signature (still unnamed) that can be viewed in the Monero repository. The EWASM team may run some tests to compare native running of the pre-compiles vs EWASM. Adding a new pre-compile would only give a constant speed-up or reduction in cost, but if we achieve the same thing in new virtual machine it will give us a constant speed-up for every conceivable routine and allows for building other schemes like Casper and TrueBit. This is easier with Web Assembly because we can use existing C code. For the moment it looks like focusing energy on adding these proposed pre-compiles would not be worth it compared to just waiting for the next VM (likely EWASM) which will allow far more speed-ups across all computational routines.

[37:00] 6. Introduce miner heuristic "Child pays for parent" (like in BTC) to combat the weird cases when transactions with 1000 Gwei stuck in the mempool (because they are dependent via nonce on transaction paying much less and not getting mined).

[Note: I tried my best to cover what was discussed here, but I am not an expert in Ethereum transactions. If you find a mistake please point it out to me. Thanks!] Agenda item brought up to get people's opinion on this topic. Currently in Ethereum there are transactions that are stuck in the mempool for a long time because of the way transaction ordering per account is handled. The nonce of a transaction must be greater than the previous mined transactions (or equal if you are trying to replace a transaction). For example you can't process transaction #27 before transaction #26 has been mined. Many of the stuck transactions are dependent on other transactions that pay a much smaller fee, but are not being mined. It seems people inadvertently send an initial transaction with too small of a fee and then more transactions at a higher nonce with a much higher fee that cannot be processed until the first small fee transaction is processed. Alexey wondered if this may pose an attack vector or if we would get a benefit from implementing "child pays for parent" like Bitcoin does. Peter explained even if you define the max amount of gas your transaction could potentially consume, there is no guarantee it will use that much and we won't know until the transaction is processed (the only guarantee is that 21,000 gas will be consumed - a plain ether transfer). The attack vector example would be someone pushing a transaction that truly consumes 3,000,000 gas and attach a transaction fee of 1 wei and then push another TX that claims to consume 3,000,000 gas but with a transaction fee of 1000gwei. From the outside it looks like I can both can be executed for profit from the miner's perspective, but in reality the 2nd transaction will be processed first and the 1st tx will be long running and indirectly punish the miner. Alexey was concerned about the mempool filling up and impact on clients due to the way nonces are handled. Peter clarified that transactions in the mempool in the go ethereum client only maintains the top 4,000 most expensive transactions. If your cheap transaction gets evicted, the expensive transactions you stacked on top of it get evicted as well because they are no longer executable due to the nonce.

[42:21] 7. Creating a relay network of nodes to mitigate issues described here and other transaction propagation issues.

A relay network in general is a group of peers and/or miners who use a peer list to quickly connect to a group of known peers before connecting to (or instead of connecting to) random peers using network discovery. Alexey conjectured that this may create a powerful ring of network players who can share transactions very quickly and hurt the little guys on the outside (hurting the idea of this being a mesh network of peers). Clarifications were made about the issues involving transaction propagation issues with nodes with high transaction throughput such as Infura and Bittrex. Clients suddenly stop pushing transactions or cannot keep up with the blockchain when they are pushing out so many transactions. Hudson will work towards exploring this issue more and connecting the people with the issues with the devs.

[49:45] 8. Fork release management/Constantinople.

Hudson will be working on writing up a starting plan to discuss potential release management issues. BitsBeTripping sent Hudson some good material about project management that he will review and bring to the next meeting. We need to start discussing Constantinople sooner rather than later.

[52:55] 9. Client updates.

10. Other non-agenda items

[1:05:42] Question: Will we see any scaling improvements from Constantinople?

Answer is no because it potentially includes the first steps of the Casper consensus protocol and some account abstraction EIPs, but both of those do not alleviate scaling issues. Sharding would alleviate some of the issues. We are currently mostly bound by database and processing speed due to the database. Short term there are a lot of client improvements that can be accomplished to improve disk I/O, but long term things like sharding will be necessary. The Eth Research site has a lot of interesting threads about sharding including merkle tree formats to be used and ideas around asynchronous accumulators

[1:09:57] Decision process for EIPs?

Needs to be improved. Hudson and others will work on updating EIP #1 and other improvements in Q1. Nick Savers has been added as an EIP editor. Yoichi has been added as an editor. Both are doing a great job.

Attendance

Alex Beregszaszi (EWASM/Solidity/ethereumJS), Alex Van de Sande (Mist/Ethereum Wallet), Alexey Akhunov (Turbo Geth), Ben Edgington (Consensys/Pegasys), Casey Detrio (Volunteer), Christian Reitwiessner (cpp-ethereum/Solidity), Daniel Ellison (Consensys/LLL), Greg Colvin (EVM), Hudson Jameson (Ethereum Foundation), Hugo de la Cruz (ethereumJS/EWASM), Jake Lang (EWASM), Jared Wasinger (ethereumJS/EWASM), Martin Becze (EWASM), Mikhail Kalinin (Harmony), Paweł Bylica (cpp-ethereum/EWASM), Péter Szilágyi (geth), Silur (ethereumJS / EWASM)
submitted by Souptacular to ethereum [link] [comments]

ANN: Arionum (ARO)

We would like to proudly announce Arionum, a new cryptocurrency built from scratch!
Introduction
Arionum was designed with the future in mind, in a market where the growth beats all expectations. Arionum aims to offer a secure electronic payments system that is able to scale without a degraded performance or a degraded user experience. It offers a fixed 0.25% fee on all transactions and it has a dynamic transaction limit per block, allowing it to keep up with a growing number of transactions at all times.
One of the main advantages of Arionum is that it was fully written from scratch in PHP, one of the most popular programming languages in the world. While php is not as fast as c++. for example, the high number of developers that can easily understand and develop PHP and the Arionum compensates for this. The main inspiration has been Satoshi Nakamoto's bitcoin white paper, but all the code has been thought and written by the developers to keep it's originality.
Arionum has been thought as a democratic and egalitarian coin, having no pre-mined coins, long mining period, no developer fees and an algorithm that advantages the average user with available CPU resources rather than mining farms.
Original Announcement: https://bitcointalk.org/index.php?topic=2710248.0
Specifications
Name: Arionum
Symbol: ARO
Block time: ~ 4 minutes
Mining reward: Starts at 1000 and decreases by 10 each 10800 blocks
Mining time: 8 years and 4 months
Premine: NO Premine
Transaction fee: Always 0.25%
Block Hash: sha512
Mining algorithm: Argon2i + SHA512
Total coin supply: 545.399.000
Signature Algorithm: ECDSA's secp256k1 curve
DB Backend: MySQL / MariaDB
Whitepaper: https://www.arionum.com/wp.pdf
Roadmap
Download links
Official links
Official website: https://www.arionum.com
Block explorer: https://arionum.info
Forum: https://forum.arionum.com
FAQ: https://forum.arionum.com/viewtopic.php?f=13&t=11
Social networking
Twitter: https://twitter.com/ArionumCrypto
Discord: https://arionum.info/discord/
Pools
Official Pool: http://aropool.com
submitted by AroDev to Arionum [link] [comments]

Harvesting Cryptodust by Gambling: Winner Takes All

Harvesting Cryptodust by Gambling: Winner Takes All
Cryptocurrencies generated (mined) on mobile devices or personal are so low that no one will feel they are lost. Suppose we "harvest" all these as pool fund for gambling. Then winners can get all prize money like lottery. More people can use it over time. This has great educational value. The operator of this system will make lots of money.
Let's call it Cryptodust for obvious reasons.
Anyone done this before?
Anyone interested in collaboration?
Updates:
https://blog.bitjson.com/just-released-webassembly-version-of-secp256k1-10x-faster-than-javascript-eb3cebe4d411
https://www.reddit.com/Bitcoin/comments/8oiljm/just_released_a_webassembly_version_of_bitcoins/
submitted by wengchunkn to btc [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-05)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization Note that I crosspost this to Voat, bitcoin.com and the bitcoin-discuss mailing list every week. I can't control what's being talking about in the meeting, if certain things come up I might not be able to post here because of "guidelines".
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
Sigcache performance Performance goals for 0.12 transaction priority sigops flooding attack chain limits
Short topics/notes
Note: cfields, mcelrath and BlueMatt (and maybe more) missed the meeting because of daylight saving time.
Closing date for proposals for the scaling bitcoin workshop is the 9th.
Check to see if there are any other commits for the 0.11.2 RC. As soon as 6948 and 6825 are merged it seems good to go. We need to move fairly quick as there are already miners voting for CLTV (F2Pool). Also testnet is CLTV locked already and is constantly forking. 0.11.2 RC1 has been released as of today: https://bitcoin.org/bin/bitcoin-core-0.11.2/test/
Most of the mempool-limiting analysis assumed child-pays-for-parent, however that isn't ready for 0.12 yet, so we should think about possible abuses in context of the existing mining algorithm.
Because of time-constrains opt-in replace-by-fee has been deferred to next weeks meeting, but most people seem to want it in 0.12. sdaftuar makes a note that we need to make clear to users what they need to do if they don't want to accept opt-in transactions.
Sigcache performance
The signature cache, which is in place to increase performance (by not having to check the signature multiple times), and to mitigate some attacks currently has a default limit of 50 000 signatures. Sipa has a pull-request which proposes to: Change the limit from number of entries to megabytes Change the default to 40MB, which corresponds to 500 000 signatures Store salted hashes instead of full entries Remove entries that have been validated in a block
Sipa did benchmarks for various signature cache sizes on hitrate in blocks (how many of the cached signatures are in the block). The maximum sigcache size was 68MB, resulting in a 3% miss-rate. Some blocks though have extremely high miss rates (60%) while others have none. Likely caused by miners running different policies. Gmaxwell proposed to always run script verification for mempool transactions, even if these transactions get rejected into the mempool by the clients policy. The result of that is that even a 300MB sigcache size only gets down to 15% misses. So there's too much crap being relayed to keep any reasonable sized cache. Gmaxwell points out downsides to not checking any rejected transactions, namely: there are some DOS attacks possible, and you increase your misrate if you set a policy which is more restrictive than the typical network, which might result in a race to the bottom.
Sipa continues his work and seeks out other strategies
Performance goals for 0.12
Bitcoin-core 0.12 is scheduled for release December 1st.
Everybody likes to include secp256k1 ASAP, as it has a very large performance increase. Some people would like to include the sigcache pull-request, BIP30, modifyNewCoins and a createNewBlock rewrite if it's ready. Wumpus advises against merging last-minute performance improvements for 0.12.
Mentioned pull-requests should be reviewed, prioritizing CreateNewBlock
transaction priority
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which makes some transactions free.
Sipa thinks we should get rid of the current priority completely and replace it with a function that modifies fee or size of a transaction. There's a pull-request available that optimizes the current transaction priority, thereby avoiding the political debate that goes with changing the definition of transaction priority. Luke-jr thinks the old policy should remain possible.
Check to see if PR #6357 is safe and efficient enough.
sigops flooding attack
The number of ECDSA signature-checking operations or sigops is currently limited to 20 000 per block. This in order to prevent miners creating blocks that take ages to verify as those operations are time-consuming. You could however construct transactions that have a very high sigops count and since most miners don't take into account the sigops count they end up with very small blocks because the sigop limit is reached. This attack is described here.
Suggestion to take the number of sigops relative to the maximum blocksize into account with the total size. Meaning a 10k sigops transaction would currently be viewed as 500kB in size (for that single transaction, not towards the block). That suggestion would be easy to change in the mining code, but more invasive to try and plug that into everything that looks at feerate. This would also open up attacks on the mempool if these transactions are not evicted by mempool limiting. Luke-jr has a bytes-per-sigop limit, that filters out these attack transactions.
More analysis should be done, people seem fine with the general direction of fixing it.
chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
sdaftuar's analysis shows that 40% of blocks contain a chain that exceeds the proposed limits. Even a small bump doesn't make the problem go away. Possible sources of these chains: a service paying the fees on other transactions (child-pays-for-parent), an iOS wallet that gladly spends unconfirmed change. A business confirms they use child-pays-for-parent when they receive bitcoins from an unspent chain. It is possible that these long chains are delivered to miners directly, in which case they wouldn't be affected by the proposed relay limits (and by malleability). Since this is a problem that needs to be addressed, people seem fine with merging it anyway, communicating in advance to let businesses think about how this affects them.
Merge "Policy: Lower default limits for tx chains" Morcos will mail the developer mailing list after it's merged.
Participants
morcos Alex Morcos gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan sipa Pieter Wuille jgarzik Jeff Garzik Luke-Jr Luke Dashjr phantomcircuit Patrick Strateman sdaftuar Suhas Daftuar btcdrak btcdrak jouke ??Jouke Hofman?? jtimon Jorge Timón jonasschnelli Jonas Schnelli 
Comic relief
20:01 wumpus #meetingend 20:01 wumpus #meetingstop 20:01 gmaxwell Thanks all. 20:01 btcdrak #exitmeeting 20:01 gmaxwell #nomeetingnonono 20:01 btcdrak #meedingexit 20:01 wumpus #endmeeting 20:01 lightningbot Meeting ended Thu Nov 5 20:01:29 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 20:01 btcdrak #rekt 
submitted by G1lius to Bitcoin [link] [comments]

Bitmain Crap Coin (BCC) is done. Stick a fork in it! (pun intended)

This needs to be repeated: https://www.reddit.com/Bitcoin/comments/6pwxtu/bitrefill_will_automatically_dump_the_toxic_bcc/dktdoai/ The bigger issues with BCC are incompetent development and lack of infrastructure.
And, of course, for the last several days BIP148 UASF has been enjoying its well deserved 100% hashrate. (AKA SegWit)
I drink to the suicide of the 6th or 7th hard fork threat from the mining cartel.
Cheers gents!
submitted by xboox to Bitcoin [link] [comments]

MaxCoin Specifications. Important

Quick Technicals
Cryptography Tech Spec
MaxCoin uses the Keccak (SHA-3) hashing algorithm for its Proof-of-Work. Keccak was selected as an alternative to the NSA designed SHA256 after a 5-year long competition held by the NIST and will be seen increasingly as the algorithm used in banking and other secure applications. A single round of Keccak is used, resulting in a 256 bit hash.
We have also implemented a provably-secure signing algorithm, EC-Schnorr. Every existing cryptocurrency uses the ECDSA algorithm, as chosen by Satoshi; whilst ECDSA is in common use and is secure, EC-Schnorr is provably more secure and is currently being recommended over it (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report/at_download/fullReport). Additionally, MaxCoin changes the elliptic curve utilised within the signing algorithms from a Koblitz curve, secp256k1, to a more secure psuedo-random one, secp256r1. The use of the latter curve is recommended almost universally - and the decision by Satoshi to use the former is one that is often queried in the Bitcoin world. One theory is that there are some speed advantages to using the Koblitz curve, but, the implementation used in Bitcoin (OpenSSL) does not make use of this optimisation and, thus, the result is reduced-security.
The cryptography choices within MaxCoin have been made to maximise security and, where possible, to minimise NSA influence. We have been advised throughout by the renowed cryptography expert Professor Nigel Smart (https://en.wikipedia.org/wiki/Nigel_Smart_(cryptographer)).
These changes also lay the foundation for some key features we're aiming to implement in MaxCoin over the coming months, so while they may currently appear uninteresting changes they pave the way for our future growth.
What do you mean by "Starting Algorithm"?
This is an issue of hardware miner resistance, such as ASICs. Keccak is the starting algorithm for MaxCoin and at this point in time no hardware miner currently exists. However, creating a Keccak ASIC is not impossible. Therefore, in order to protect against a hardware-miner future we are going to implement an "ASIC protection" feature into MaxCoin. This will work by allowing the blockchain to decide a new hashing algorithm for MaxCoin every x blocks. More specifically, the last authenticated transaction's hash is used to determine an integer and depending on this value an algorithm will be selected. This will mean hardware miners will find it difficult to create hardware in enough time to see profitable return. Purely for example, these could be:
x Algorithm 0 Keccak 1 Blake 2 Grostlx2 3 JH 4 Skein 5 Blake2 6 JH(Grostl) 7 Keccak+Blake
Difficulty & Distribution
MaxCoin will have a zero % premine, proven by the timestamps of the first blocks in a block explorer, and we have attempted to combat low-difficulty instamining with a fast retarget rate up until block 200. At block 200 the Kimoto Gravity Well implementation will take over the retargeting.
Mining is done via CPU at release (mining guides about to be released also on this subreddit), but a GPU miner will not be far away. We've seen some versions in the works already after we released CPUminer yesterday, and while we have not yet seen a working version, this is very unlikely to take long. We'll update all official channels with Keccak GPU miner once it is available. It's also worth noting that any GPU miner created will not work after the first algorithm switch takes place.
submitted by maxcoinproject to maxcoinproject [link] [comments]

Bitcoin dev IRC meeting in layman's terms (2015-11-05)

Once again my attempt to summarize and explain the weekly bitcoin developer meeting in layman's terms. Link to last weeks summarization
On a personal note: I really don't like the fact someone pm'ed me telling me "a majority of bitcoiners have moved to btc", it's not (yet) true and comes across as very spammy. This combined with the tin-foiled hat people-bashing which seems to be popular makes me almost not want to join this community. I hope this can become like bitcoin, but with the freedom to discuss and mention any topic, not a mindless crusade against bitcoin, theymos, blockstream, etc.
Disclaimer
Please bear in mind I'm not a developer and I'd have problems coding "hello world!", so some things might be incorrect or plain wrong. Like any other write-up it likely contains personal biases, although I try to stay as neutral as I can. There are no decisions being made in these meetings, so if I say "everyone agrees" this means everyone present in the meeting, that's not consensus, but since a fair amount of devs are present it's a good representation. The dev IRC and mailinglist are for bitcoin development purposes. If you have not contributed actual code to a bitcoin-implementation, this is probably not the place you want to reach out to. There are many places to discuss things that the developers read, including this sub-reddit.
link to this week logs Meeting minutes by meetbot
Main topics discussed where:
Sigcache performance Performance goals for 0.12 transaction priority sigops flooding attack chain limits
Short topics/notes
Note: cfields, mcelrath and BlueMatt (and maybe more) missed the meeting because of daylight saving time.
Closing date for proposals for the scaling bitcoin workshop is the 9th.
Check to see if there are any other commits for the 0.11.2 RC. As soon as 6948 and 6825 are merged it seems good to go. We need to move fairly quick as there are already miners voting for CLTV (F2Pool). Also testnet is CLTV locked already and is constantly forking. 0.11.2 RC1 has been released as of today: https://bitcoin.org/bin/bitcoin-core-0.11.2/test/
Most of the mempool-limiting analysis assumed child-pays-for-parent, however that isn't ready for 0.12 yet, so we should think about possible abuses in context of the existing mining algorithm.
Because of time-constrains opt-in replace-by-fee has been deferred to next weeks meeting, but most people seem to want it in 0.12. sdaftuar makes a note that we need to make clear to users what they need to do if they don't want to accept opt-in transactions.
Sigcache performance
The signature cache, which is in place to increase performance (by not having to check the signature multiple times), and to mitigate some attacks currently has a default limit of 50 000 signatures. Sipa has a pull-request which proposes to: Change the limit from number of entries to megabytes Change the default to 40MB, which corresponds to 500 000 signatures Store salted hashes instead of full entries Remove entries that have been validated in a block
Sipa did benchmarks for various signature cache sizes on hitrate in blocks (how many of the cached signatures are in the block). The maximum sigcache size was 68MB, resulting in a 3% miss-rate. Some blocks though have extremely high miss rates (60%) while others have none. Likely caused by miners running different policies. Gmaxwell proposed to always run script verification for mempool transactions, even if these transactions get rejected into the mempool by the clients policy. The result of that is that even a 300MB sigcache size only gets down to 15% misses. So there's too much crap being relayed to keep any reasonable sized cache. Gmaxwell points out downsides to not checking any rejected transactions, namely: there are some DOS attacks possible, and you increase your misrate if you set a policy which is more restrictive than the typical network, which might result in a race to the bottom.
Sipa continues his work and seeks out other strategies
Performance goals for 0.12
Bitcoin-core 0.12 is scheduled for release December 1st.
Everybody likes to include secp256k1 ASAP, as it has a very large performance increase. Some people would like to include the sigcache pull-request, BIP30, modifyNewCoins and a createNewBlock rewrite if it's ready. Wumpus advises against merging last-minute performance improvements for 0.12.
Mentioned pull-requests should be reviewed, prioritizing CreateNewBlock
transaction priority
Each transaction is assigned a priority, determined by the age, size, and number of inputs. Which makes some transactions free.
Sipa thinks we should get rid of the current priority completely and replace it with a function that modifies fee or size of a transaction. There's a pull-request available that optimizes the current transaction priority, thereby avoiding the political debate that goes with changing the definition of transaction priority. Luke-jr thinks the old policy should remain possible.
Check to see if PR #6357 is safe and efficient enough.
sigops flooding attack
The number of ECDSA signature-checking operations or sigops is currently limited to 20 000 per block. This in order to prevent miners creating blocks that take ages to verify as those operations are time-consuming. You could however construct transactions that have a very high sigops count and since most miners don't take into account the sigops count they end up with very small blocks because the sigop limit is reached. This attack is described here.
Suggestion to take the number of sigops relative to the maximum blocksize into account with the total size. Meaning a 10k sigops transaction would currently be viewed as 500kB in size (for that single transaction, not towards the block). That suggestion would be easy to change in the mining code, but more invasive to try and plug that into everything that looks at feerate. This would also open up attacks on the mempool if these transactions are not evicted by mempool limiting. Luke-jr has a bytes-per-sigop limit, that filters out these attack transactions.
More analysis should be done, people seem fine with the general direction of fixing it.
chain limits
Chain in this context means connected transactions. When you send a transaction that depends on another transaction that has yet to be confirmed we talk about a chain of transactions. Miners ideally take the whole chain into account instead of just every single transaction (although that's not widely implemented afaik). So while a single transaction might not have a sufficient fee, a depending transaction could have a high enough fee to make it worthwhile to mine both. This is commonly known as child-pays-for-parent. Since you can make these chains very big it's possible to clog up the mempool this way. With the recent malleability attacks, anyone who made transactions going multiple layers deep would've already encountered huge problems doing this (beautifully explained in let's talk bitcoin #258 from 13:50 onwards) Proposal and github link.
sdaftuar's analysis shows that 40% of blocks contain a chain that exceeds the proposed limits. Even a small bump doesn't make the problem go away. Possible sources of these chains: a service paying the fees on other transactions (child-pays-for-parent), an iOS wallet that gladly spends unconfirmed change. A business confirms they use child-pays-for-parent when they receive bitcoins from an unspent chain. It is possible that these long chains are delivered to miners directly, in which case they wouldn't be affected by the proposed relay limits (and by malleability). Since this is a problem that needs to be addressed, people seem fine with merging it anyway, communicating in advance to let businesses think about how this affects them.
Merge "Policy: Lower default limits for tx chains" Morcos will mail the developer mailing list after it's merged.
Participants
morcos Alex Morcos gmaxwell Gregory Maxwell wumpus Wladimir J. van der Laan sipa Pieter Wuille jgarzik Jeff Garzik Luke-Jr Luke Dashjr phantomcircuit Patrick Strateman sdaftuar Suhas Daftuar btcdrak btcdrak jouke ??Jouke Hofman?? jtimon Jorge Timón jonasschnelli Jonas Schnelli 
Comic relief
20:01 wumpus #meetingend 20:01 wumpus #meetingstop 20:01 gmaxwell Thanks all. 20:01 btcdrak #exitmeeting 20:01 gmaxwell #nomeetingnonono 20:01 btcdrak #meedingexit 20:01 wumpus #endmeeting 20:01 lightningbot Meeting ended Thu Nov 5 20:01:29 2015 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . 20:01 btcdrak #rekt 
submitted by G1lius to btc [link] [comments]

EthereumCash★ETHC★Masternode - Pos★Payout 50% Profit To Holders★

Our Project is EthereumCash Coin not Token. We have our system, with our plan, we not clone or scam. Masternode and Payout profit every month to holders. And Our coin Symbol is ETHC not ECASH. Thanks! NOTE: 1. We dont make any Masternode. Masternode just for big holder with 50k coin. We dont want to have more masternode because more coin mined, price of ETHC will drop. This is coin of my company, more coin of us with more potetial will posted soon. Now more work to do. Thanks
  1. BIG EVENT will coming at 1 NOV when more potential coins of us end ICO and list on exchange. We will update information about our coins after 1 NOV. Very potential coins. We will payout Bounty at 18 OCT. Next payout will inform later.
BOUNTY REWARD will decrease soon. Let's GO. We must change some rule about rewards. New rule will better and make ETHC reach high value. Thanks
  1. Just only 4 mil ETHC on exchange, no more coin. We hold 73% premine to get profit from our project.
NEWS: * Today, our team will discuss about how to use money when ETHC sale on exchange, 50% want to share 50% profit to holders to make great project. But we must have more agree, hope we have good news soon.
Finally, Our team decide share 50% profit from sale ETHC on exchange for holders, hope all investors will hold ETHC to get BTC. Thanks.
https://www.emoneyspace.com/banner_stats.php?h=%2FkfqBZeXOos%3D https://www.emoneyspace.com/forum/index.php?action=profile;u=10955
We just payout 400 address quickly fill out form bounty on twitter, other must wait later . Thanks!
EthereumCash Project
What is EthereumCash ?
EthereumCash is an experimental new digital currency that enables anonymous, instant payments to anyone, anywhere in the world. EthereumCash uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. EthereumCash is a PoS-based cryptocurrency, and depend upon libsecp256k1 by sipa, the sources for which can be found here: https://github.com/bitcoin/secp256k1
EthereumCash is a project which was created in January 2017, launched by a group of Masters graduated in Technology Institutes of Hardware, Web Programming and CryptoCurrency. Currently, the project has 60 Antminer L3 + devices. EthereumCash was released to fund the development of the project, and using funds was a way to purchase new Antminer devices. The special issue is that we will pay EthereumCash holders 50% of the profits from the mining of us every 45 days since EthereumCash is listed on the exchange. On the other hand, our project is also interested in partners and is ready to collaborate by buying 30% EthereumCash and allowing us to use their existing Antminer devices with low fee. Our mining plan at the beginning of the project was to mine the coins to be issued or newly listed, with low difficult and then we waited and sold out at high prices beyond expectations. Besides, when we find the coin that we see has the potential for growth or high price expectations we will also bring all our equipment to mine those coin. We are young with a dynamic creativity, willing to devote as much to the success and development of the company.
EthereumCash Details
Coin Name : EthereumCash Coin abbreviation : ETHC Coin Type : Full POS Algorith : SHA256 Total Coin Supply : 100 Million Premine : 15% (15 Million) Masternode Rewards : 60% Stake : 10 ETHC Minimum Stake Age : 8 hours Number of confirmation : 10 For more information, as well as an immediately useable, binary version of the EthereumCash Core software, see https://ethereumcash.io
Premine Distribution
Our Company : 50% Dev Team : 23% ( 73% not allow to sale, just hold and get profit) Sale on Exchange : 20% Bounty & Airdrop : 7% (1.050.000 Coins)
How to mine ?
You can buy some coins and stake them to get rewards. More coins more rewards. Masternode require 50k coins. It just for big holders, we dont want to make more masternode because more reward, easy to get reward, price of coin will drop more. But with payout 50% profit from our mining, we hope ETHC will rise up for along term.
Download wallet ?
Download your EthereumCash wallet for free. This wallet protects your EthereumCash and stores it securely. You can use this wallet for all kind of EthereumCash transactions.
Windows wallet: (we check our wallet on virustotal,it 's negative alert. Dont worried. thanks) https://github.com/ethereumcashdev/ethereumcash/files/1385162/ethereumcash-qt-windows.zip
Linux wallet: (please install libdb5.1++ before run linux wallet by command apt-get install libdb5.1++) https://github.com/ethereumcashdev/ethereumcash/files/1384405/ethereumcash-qt-linux.zip
MacOSX wallet: https://github.com/ethereumcashdev/ethereumcash/files/1390116/ethereumcash-qt-macosx.zip
Our Website
https://ethereumcash.io
Block Explorer
https://explorer.ethereumcash.io
Exchange
Coming soon next week
Our coins
We will post some Our potential coins soon...
How to config masternode
Maternode is running, please check https://explorer.ethereumcash.io
Code: Step 1: getnewaddress 0
Save: E7udTdWf49RkPfbiQuVgEvK1U96pqETH7i 
Step 2: Send 50.000 ETHC coin to your masternode address (EWb9GpJptZ5ywdybAdSSGm1mALkKBD46Ev)
Step 3: masternode genkey
Save: 12a54351ffd564ccbcac47a1571e1fbd52d7dba855680b5f5ca28d0e6741df4c 
Step 4: masternode outputs
Save: { "ce450aa1fbaaa5689b6836bde326d2b3cbc818947c6d14e2e377a0aa719159b5" : "0" } 
Step 5: add below to windows wallet config port=8888 masternode=1 masternodeaddr=185.44.145.34:8888 (Ip of masternode VPS) masternodeprivkey=12a54351ffd564ccbcac47a1571e1fbd52d7dba855680b5f5ca28d0e6741df4c
Bounty: 200 ETHC to build MacOSx wallet, we have more task with high priority as make guide for masternode, invest tool and no more users use MacOSx. Thanks
https://i.imgur.com/J3DrMgs.png https://i.imgur.com/TCTRXUq.png https://i.imgur.com/fC8Yu2c.png https://i.imgur.com/z38FcFJ.png https://i.imgur.com/iXpb3WO.png https://i.imgur.com/mmej68L.png https://i.imgur.com/hjUFEfG.png https://i.imgur.com/cdglnPr.png https://i.imgur.com/97qyONt.png https://i.imgur.com/70hms4P.png
Twitter bounty Campaign Rules: 1- Each member is to make positive post about the EthereumCash project with #ethereumcashdev #ethereumcash #ETHC 2- Each member should follow official EthereumCash twitter page. This is office twitter page: https://twitter.com/ethereum_cash 3- How many ETHC per post ? under 1000 followers -> 10 ETHC under 2000 followers -> 20 ETHC ...... under 50000 followers -> 500 ETHC ..... 4- Fill out this form https://docs.google.com/forms/d/1p2AjsIDwlY2xoKejYj4t-P0HLw2O7YQJodmuWFobj5Q
Slack bounty Campaign
1- When you register your slack account at this link https://ethereumcash.herokuapp.com and make a positive comment on slack, you will receive 10 ETHC. 2- Fill out this form https://docs.google.com/forms/d/14Z039UoLJ7sfr66OI0CvIrySRZyxmSlw9vsseIKHUlY
submitted by EthereumCash to EthereumCash [link] [comments]

Some insight into a programmer's perspective on a few clues that can help identify Satoshi

I know there are a lot of theories of who Satoshi can be based on his crypto background, activity patterns and so forth. I would like to share some things I noticed while working a bit with the Bitcoin code that could help someone narrow down who Satoshi might be.
I will be looking at the design choices used in Bitcoin. As a programmer myself, I can tell you that some of the stranger things you do while programming can make you stand out quite a bit. So here are a few important design choices made by Satoshi:
Those are the things I noticed while working with Bitcoin code for a year. First two are nothing special, but if I saw another program that uses the last two in a similar fashion, I would bet that they shared a common author.
So, what do you guys think about these remarks?
submitted by ThePiachu to Bitcoin [link] [comments]

Decred - An Overview

Decred is an open, progressive, and self-funding cryptocurrency with a system of community-based governance integrated into its blockchain. At its core is a hybridized proof-of-work proof-of-stake (PoW/PoS) consensus system that aims to strike a balance between PoW miners and PoS voters to create a more robust notion of consensus. The project is a result of the theoretical proposals brought by proof-of-activity (PoA) and MC2 in 2013. Decred development started in April, 2014 with a single developer and expanded to include developers from btcsuite shortly thereafter.
Decred is built in the spirit of open participation and we have provided below a full disclosure of the technical features of the system, wallets and mining, initial funding and distribution, project governance and development, and a group contribution timeline. We hope to launch mainnet on January 18th, 2016, and will provide additional details in this thread. Everyone is welcome to participate, and you are certainly welcome to join the development and project groups if you have interest in contributing to our efforts!
i. Technical Features
The features below are implemented in Decred and will be available in full at launch. For a deeper description, please consult the Decred Technical Brief (DTB001).
•Novel hybridized proof-of-work/proof-of-stake (PoW/PoS) consensus system - A decentralized lottery is used to select PoS miners to vote on PoW blocks. The PoW and PoS subsidies account for 60% and 30% of each total block subsidy, respectively. This system is based on that of MC2, which is very similar to, but developed independently from, Proof-of-Activity (PoA) by Iddo Bentov, Charles Lee, Alex Mizrahi and Meni Rosenfeld. •Cold staking and decentralized stake pooling - The ability to generate new coins without the risk of having your coins online when PoS mining. The PoS mining system has also been engineered with distributed, decentralized stake pooling in mind, so that even those with small amounts of stake can participate in network validation. •Internal voting system for the addition of new features and hard or soft fork selection - Both PoW and PoS miners can vote for features and issues through bit flags, providing a sensible mechanism for resolving disputes about the features of the blockchain. •Immutable transaction hashes ("transaction IDs") by separating transaction signatures from the rest of the transaction data - A permanent fix for transaction hash malleability has been implemented that prevents mutability of the transaction hash by separating it from its input signatures. This allows more efficient SPV validation. Fraud proofs have also been added. •Elliptic curve cryptography over secp256k1 with optional Curve25519 support - The Bitcoin scripting system has been modified to allow for simple, drop-in addition of new elliptical curve digital signature algorithms. •Schnorr signatures with threshold n-of-n support - In addition to supporting Schnorr signatures, groups of signers can now jointly sign transactions off-chain in constant size signatures, ensuring higher privacy and less blockchain bloat. •Script enhancements and new OP codes - New OP codes have been added to the existing Bitcoin scripting engine, and extensions for the plug-in use of future scripting engines have been added. •PoW mining using BLAKE256 hash algorithm - Inspired by Bernstein's Chacha stream cipher, SHA3 finalist BLAKE256 offers speed as well as high security. •Compatibility with Bitcoin transaction scripting system - Decred's scripting system has been derived from Bitcoin's with care in ensuring that all future updates to the Bitcoin transaction script will be easily extensible to Decred. Further, any newly created functionalities will also be devised with backwards compatibility with Bitcoin in mind. •Modularized, easy-to-use Golang btcsuite codebase - Thanks the to the codebase inherited from btcsuite, adding new features to the daemon or wallet will be facile. Decred will episodically sync updates from btcsuite, so that it benefits from the latest developments in Bitcoin. •Hierarchical deterministic (HD) wallets - Wallets use a seed to deterministically generate addresses, so your wallet can be restored from a single BIP0032 seed. •Transaction expiration - Transactions have a new expiration field to prevent inclusion into the blockchain after a certain height. •Patches for intrinsic Bitcoin bugs - Extra push for multisignature scripts has been removed, SIGHASH_SINGLE behavior has been corrected. •Approximately 21 million coins - Exponential decay in subsidy or the number of coins generated per year. •Self-funded development via block subsidy - In order to have an ongoing source of funding for development work, a consensus rule has been added to allocate 10% of each block subsidy to a development organization. This entity is transparent and responsible for funding development work performed by current and new developers so that the project remains sustainable without a funding dependence on outside forces in the future. Decred therefore improves with growth in a sustainable way and is accountable only to its users.
ii. Wallets and Mining
•Web wallet service - In order for users to have access to a GUI on all platforms, we have created a web wallet service forked from BitPay's Copay wallet and its dependencies. This wallet allows users to access all the basics with Decred: sending and receiving coins, multisig transactions. •Command-line wallet - For more advanced users, we have a command-line wallet, dcrwallet. dcrwallet allows users to mine PoS and collect rewards by participating in the PoW/PoS consensus system. •Simple GPU miner - A simple AMD GPU miner that connects to a local daemon will be available before launch. In the future, proper getblocktemplate functionality will be enabled and pool software will be made available.
iii. Initial Funding and Airdrop
Decred opted for a different funding model in an attempt to shift the risk carried by supporters to the developers of the project. Instead of asking interested parties to fund the development of the software, the developers decided to pool funds together and carry the project to completion before making it public. The consensus was that this is an ethical path given the realities of funding software development, due to the fact that the developers alone carry the risk of the project failing, whereas in the past potential users were expected to pay for coins before any code was written. We felt this was unjust.
The development of Decred was funded by Company 0 and from the pockets of its developers individually. The cost of developing the project, in terms of developer pay, totals to approximately USD 250,000, which Company 0 paid to developers. An additional amount of approximately USD 165,000 has been allocated for unpaid work and individual purchases by developers. We felt that the most equitable way to handle compensation for these expenses was to perform a small premine as part of the project launch. The model is unusual in that no developer received any amount of coins for free - all coins owned by developers will either be purchased at a rate of USD 0.49 per coin from their own pockets or exchanged for work performed at the same rate.
The premine consists of 8% of the total supply of 21 million coins, meaning the premine consists of 1.68 million coins. Rather than allocating the entire premine to the bring-up costs, we decided to split the premine equally between compensation for bring-up and an "airdrop", where we freely give an equal amount of coins to a number of airdrop participants. This means Company 0 and its developers will have put roughly USD 415,000 into the bring-up since April, 2014 and receive 4% of the total supply, 840,000 coins (at USD 0.49 per coin). The remaining 4% will be spread evenly across a list of airdrop participants as part of an effort to build the Decred network and decentralize its distribution. Coins held by Company 0 will be used to fund its ongoing work on open-source projects, such as Decred and btcsuite.
Giving away these coins in an airdrop allows us to accomplish several things at once for the project: enlarge the Decred network, further help decentralize the distribution of coins, and allow us to get coins into the hands of people who are interested in participating in the project. Decred is fundamentally about technological progress, so the airdrop will target individuals that have made contributions to advance technology in its various forms. The maximum number of airdrop participants is capped at 5,000 individuals, so we recommend registering sooner rather than later. These coins will be given away unconditionally and there is zero expectation of Decred receiving anything from you in return for these coins.
Sign up for the airdrop is currently open, but the airdrop registration will commence on January 4th, 2016. People who have been selected to participate in the airdrop will receive an email that contains a link to a web registration form. This form will require airdrop participants to enter an address to which their coins can be sent. Binaries and source code will be made available so that you can generate a wallet seed and an address for your airdrop coins. Once you have entered your receiving address into the airdrop webform and submitted it, you will receive your coins on the projected launch date of January, 18th, 2016.
iv. Project Governance and Development
In addition to the technical features that make up the technology, Decred as a project introduces several development and governance features and proposals to ensure and steer long-term growth. We encourage participants to discuss these topics earnestly, as we want to ensure the system of development and governance is built on a solid foundation.
•A multi-stakeholder development ecosystem that welcomes and empowers participants who want to build new functionality and improve on existing features. •Any party can submit feature proposals and developers are paid for work to fulfill requirements. This is done in full view of the community in a system designed to fight against ingroup-outgroup dynamics. •The initial contributors are the developers responsible for btcsuite (est. early 2013 - present). •A proposal for a layered form of transparent meritocratic governance that extends beyond proof-of-work and proof-of-stake mechanisms to bring forward and represent insider and outsider voices in the community. •A proposal for bottom-up decision-making through the Decred Assembly, an evolving and inclusive list of community members who make non-financial contributions to the project through their work and effort. •The project is bound by the Decred Constitution on the core principles of finite issuance, privacy, security, fungibility, inclusivity, and progressive development of the technology that keeps these principles together.
v. Group Contribution Timeline
Below are key points of free and open-source contributions made by the Decred developers to the digital currency ecosystem since 2013. The largest of which is the btcsuite package, which comprises a suite of packages and tools for working with Bitcoin in Golang, and includes btcd, a full node, mining capable, Bitcoin implementation. To date, the total contribution across btcsuite represents 98,046 lines of code, 44,576 of which are test coverage.
vi. Additional Information
Website: https://decred.org Forum: https://forum.decred.org Wiki: https://wiki.decred.org Reddit: https://reddit.com/decred Twitter: https://twitter.com/decredproject IRC: #decred on irc.freenode.net
submitted by ocnios to decred [link] [comments]

Bitcoin-development Digest, Vol 45, Issue 37 | Joshua | Feb 11 2015

Joshua on Feb 11 2015:
UNSUBSCRIBE
On Wed, Feb 11, 2015 at 2:25 AM, <
bitcoin-development-request at lists.sourceforge.net> wrote:
Send Bitcoin-development mailing list submissions to
bitcoin-development at lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
bitcoin-development-request at lists.sourceforge.net
You can reach the person managing the list at
bitcoin-development-owner at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."
Today's Topics:
  1. Re: Proposal for P2P Wireless (Bluetooth LE) transfer of
    Payment URI (Eric Voskuil)
  2. Proposal: Requiring a miner's signature in the block header
    (Hector Chu)
  3. Re: Proposal: Requiring a miner's signature in the block
    header (Natanael)
Message: 1
Date: Tue, 10 Feb 2015 09:56:39 -0800
From: Eric Voskuil <eric at voskuil.org>
Subject: Re: [Bitcoin-development] Proposal for P2P Wireless
 (Bluetooth LE) transfer of Payment URI 
To: M?rtin H?bo??tiak <martin.habovstiak at gmail.com>
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>, Paul Puey
 <[paul at airbitz.co](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev)> 
Message-ID: <54DA4657.5080604 at voskuil.org>
Content-Type: text/plain; charset="utf-8"
On 02/10/2015 09:16 AM, M?rtin H?bo??tiak wrote:
I'm not sure if I was clear enough. Handshake should be used to
establish authenticated AND encrypted communication using ECDH (or
just DH, but I think it's easier to use ECDH, since required functions
are already used in Bitcoin protocol), like RedPhone does. BTW
knowledge of verification string is useless to the attacker.
Yes, I think this was clear from your description.
Yes, the customer must verify it verbally and the merchant shouldn't
send the transaction before verification. Other possibility is that in
case of differing verification strings new address is generated, so
attacker doesn't know the address. But in this case, amount is leaked
and there is quite high probability it can be found in the Blockchain.
Yes, for each handshake the payment request would need to contain a
different address, mitigating some of the privacy loss.
Anyway, I don't believe the transaction can be made securely without
such interaction except with white-listing public keys, so I see no
reason why interaction should be problematic.
It can be done securely and privately by transfer of a shared secret
through a private channel.
We don't have such strict regulations but I agree that security is
important. Currently I think that verbal verification and manual
confirmation is the best way to achieve high security and reasonable
user-friendliness.
I think for a broadcast model (e.g. Bluetooth only) that is the only
want to ensure integrity and privacy. A narrow cast can use proximity to
establish trust.
2015-02-10 17:55 GMT+01:00 Eric Voskuil <eric at voskuil.org>:
Martin,
I like your idea for the commit protocol in that it resolves the
vandalous address substitution attack. However, I don't see a way to
prevent privacy loss without adverse impact to the scenario.
Anyone could perform the handshake and thereby obtain the payment
request. Therefore to prevent inadvertent disclosure the customer must
visually confirm the "phrase" and then verbally tell the merchant to
proceed by sending the payment request.
One might argue that it's sufficient to preserve the integrity of the
transaction while suffering the privacy loss, especially given that a
hijacked handshake should never result in a completed transaction -
unless of course the hijacker pays.
But imagine someone purchasing their meds. HIPAA requires the checkout
queue to form behind a yellow line. That speaks directly to this
question.
e
On 02/06/2015 01:07 AM, M?rtin H?bo??tiak wrote:
2015-02-06 2:29 GMT+01:00 Eric Voskuil <eric at voskuil.org>:
On 02/05/2015 04:36 PM, Martin Habov?tiak wrote:
I believe, we are still talking about transactions of physical
people in physical world. So yes, it's proximity based - people
tell the words by mouth. :)
Notice from my original comment:
A MITM can substitute the key. If you don't have verifiable
identity associated with the public key (PKI/WoT), you need
a shared secret (such as a secret phrase).
I said this could only be accomplished using a shared secret or a
trusted public key. Exchanging a value that is derived from a pair of
public keys is a distinction without a difference. The problem remains
that the parties must have a secure/out-of-band channel for
communicating this value.
The fact that they are face-to-face establishes this channel, but that
brings us back to the original problem, as it requires manual
verification - as in visual/audible scanning of the two values for
comparison. At that point the visual comparison of the address, or
some
value derived from it, is simpler.
I have never been against manual verification. What I'm trying to say
is let's just make manual verification easier and more secure.
Comparison of address is simpler for the coder but also simpler to
attack. It has these problems:
  • Addresses broadcasted in plaintext (privacy issue)
  • Amounts broadcasted in plaintext (privacy issue)
  • Address is long - takes lot of time to verify (user experience issue)
  • Address prefix can be brute-forced, if too short or used to make
"black hole" address if longer (vandalism issue)
Commit protocol can be used for both the encryption and the
authentication while user experience is not bad and everything is
still secure.
In case of RedPhone, you read those words verbally over not-yet-
verified channel relying on difficulty of spoofing your voice. Also
the app remembers the public keys, so you don't need to verify
second time.
This is reasonable, but wouldn't help in the case of an ad-hoc
connection between parties who don't know each other well.
I suggest you to try RedPhone (called Signal on iPhone) yourself.
It's free/open source, Internet-based and end-to-end encrypted. You
may find it useful some day. Also I'm willing to help you with
trying it after I wake up. (~8 hours: Send me private e-mail if
you want to.)
I appreciate the offer. I really don't trust any smartphone as a
platform for secure communication/data. But encrypting on the wire
does
of course shrink the attack surface and increase the attacker's cost.
e
D?a 6. febru?ra 2015 1:22:23 CET pou??vate? Eric Voskuil
<eric at voskuil.org> nap?sal:
On 02/05/2015 04:04 PM, M?rtin H?bo??tiak wrote:
That's exactly what I though when seeing the RedPhone code, but
after
I studied the commit protocol I realized it's actually secure and
convenient way to do it. You should do that too. :)
I was analyzing the model as you described it to me. A formal
analysis
of the security model of a particular implementation, based on
inference
from source code, is a bit beyond what I signed up for. But I'm
perfectly willing to comment on your description of the model if you
are
willing to indulge me.
Shortly, how it works:
The initiator of the connection sends commit message containing the
hash of his temporary public ECDH part, second party sends back
their
public ECDH part and then initiator sends his public ECDH part in
open. All three messages are hashed together and the first two
bytes
are used to select two words from a shared dictionary which are
displayed on the screen of both the initiator and the second party.
The parties communicate those two words and verify they match.
How do they compare words if they haven't yet established a secure
channel?
If an attacker wants to do MITM, he has a chance of choosing right
public parts 1:65536. There is no way to brute-force it, since that
would be noticed immediately. If instead of two words based on the
first two bytes, four words from BIP39 wordlist were chosen, it
would
provide entropy of 44 bits which I believe should be enough even
for
paranoid people.
How this would work in Bitcoin payment scenario: user's phone
broadcasts his name, merchant inputs amount and selects the name
from
the list, commit message is sent (and then the remaining two
messages), merchant spells four words he sees on the screen and
buyer
confirms transaction after verifying that words match.
So the assumption is that there exists a secure (as in
proximity-based)
communication channel?
e
2015-02-06 0:46 GMT+01:00 Eric Voskuil <eric at voskuil.org>:
On 02/05/2015 03:36 PM, M?rtin H?bo??tiak wrote:
A BIP-70 signed payment request in the initial broadcast can
resolve the
integrity issues, but because of the public nature of the
broadcast
coupled with strong public identity, the privacy compromise is
much
worse. Now transactions are cryptographically tainted.
This is also the problem with BIP-70 over the web. TLS and other
security precautions aside, an interloper on the communication,
desktop,
datacenter, etc., can capture payment requests and strongly
correlate
transactions to identities in an automated manner. The payment
request
must be kept private between the parties, and that's hard to do.
What about using encryption with forward secrecy? Merchant would
generate signed request containing public ECDH part, buyer would
send
back transaction encrypted with ECDH and his public ECDH part. If
receiving address/amount is meant to be private, use commit
protocol
(see ZRTP/RedPhone) and short authentication phrase (which is
hard
to
spoof thanks to commit protocol - see RedPhone)?
Hi Martin,
The problem is that you need to verify the ownership of the public
key.
A MITM can substitute the key. If you don't have verifiable
identity
associated with the public key (PKI/WoT), you need a shared secret
(such
as a secret phrase). But the problem is then establishing that
secret
over a public channel.
You can bootstrap a private session over the untrusted network
using
a
trusted public key (PKI/WoT). But the presumption is that you are
already doing this over the web (using TLS). That process is
subject
to
attack at the CA. WoT is not subject to a CA attack, because it's
decentralized. But it's also not sufficiently deployed for some
scenarios.
e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Message: 2
Date: Wed, 11 Feb 2015 08:54:15 +0000
From: Hector Chu <hectorchu at gmail.com>
Subject: [Bitcoin-development] Proposal: Requiring a miner's signature
 in the block header 
To: bitcoin-development at lists.sourceforge.net
Message-ID:
 < 
CAAO2FKEFxC_byt4xVJb0S-7yy0M7M-Av7MHUH-RBDuri_GAFtw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
A proposal for stemming the tide of mining centralisation -- Requiring a
miner's signature in the block header (the whole of which is hashed), and
paying out coinbase to the miner's public key.
Please comment on whether this idea is feasible, has been thought of
before,
etc., etc. Thank you.
Motivation
Mining is centralising to a handful of pool operators. This is bad for a
number of political reasons, which we won't go into right now. But I have
always believed that some years down the line, they could hold the users
hostage and change the rules to suit themselves. For instance by
eliminating
the halving of the block reward.
Solution
Currently the block header is formed by the pool operator and distributed
for
hashing by the pooled miners. It is possible to divide the work among the
miners as the only thing that is used to search the hash space is by
changing
a nonce or two.
I propose that we require each miner to sign the block header prior to
hashing. The signature will be included in the data that is hashed.
Further,
the coinbase for the block must only pay out to the public key counterpart
of
the private key used to sign the block header.
A valid block will therefore have a signature in the block header that is
verified by the public key being paid by the coinbase transaction.
Ramifications
Work can no longer be divided among the pooled miners as before, without
sharing the pool's private key amongst all of them. If the pool does try to
take this route, then any of the miners may redeem the coinbase when it
matures. Therefore, all miners will use their own key pair.
This will make it difficult to form a cooperating pool of miners who may
not
trust each other, as the block rewards will be controlled by disparate
parties
and not by the pool operator. Only a tight clique of trusted miners would
be
able to form their own private pool in such an environment.
Attacks
Pooled hashpower, instead of earning bitcoins legitimately may try to break
the system instead. They may try a double-spending attack, but in order to
leverage the pool to its full potential the pool operator would again have
to
share their private key with the whole pool. Due to the increased
cooperation
and coordination required for an attack, the probability of a 51% attack is
much reduced.
-------------- next part --------------
An HTML attachment was scrubbed...
Message: 3
Date: Wed, 11 Feb 2015 10:25:27 +0100
From: Natanael <natanael.l at gmail.com>
Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's
 signature in the block header 
To: Hector Chu <hectorchu at gmail.com>
Cc: bitcoin-development at lists.sourceforge.net
Message-ID:
  Ref9mN7bJLg-odep3m5teZ7JWDLC+zknQdQQ at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Den 11 feb 2015 09:55 skrev "Hector Chu" <hectorchu at gmail.com>:
A proposal for stemming the tide of mining centralisation -- Requiring a
miner's signature in the block header (the whole of which is hashed), and
paying out coinbase to the miner's public key.
Please comment on whether this idea is feasible, has been thought of
before,
etc., etc. Thank you.
Motivation
Mining is centralising to a handful of pool operators. This is bad for a
number of political reasons, which we won't go into right now. But I have
always believed that some years down the line, they could hold the users
hostage and change the rules to suit themselves. For instance by
eliminating
the halving of the block reward.
[...]
I propose that we require each miner to sign the block header prior to
hashing. The signature will be included in the data that is hashed.
Further,
the coinbase for the block must only pay out to the public key
counterpart of
the private key used to sign the block header.
[...]
This will make it difficult to form a cooperating pool of miners who may
not
trust each other, as the block rewards will be controlled by disparate
parties
and not by the pool operator. Only a tight clique of trusted miners would
be
able to form their own private pool in such an environment.
People already trust things like cloud mining, so your solution with
increasing technical trust requirements won't help. But you will however
break P2Pool instead.
Also, note that threshold signatures (group signatures) could probably be
used by an actual distrusting pool's miners. There are already a proof of
concept for this implemented with secp256k1 that works with Bitcoin clients
silently. This wouldn't prevent such a pool from working.
-------------- next part --------------
An HTML attachment was scrubbed...
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is
your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
End of Bitcoin-development Digest, Vol 45, Issue 37
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150211/57ec266d/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-February/007403.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Idea: improve key renewal and revocation using Blockchain

I've been thinking today that current methods of PGP key renewal and revocation have some issues.
Let's say I have PGP key which expires soon. I create a new PGP key and send signed PGP message to everyone, who uses the old key saying: "Hello, my PGP will expire soon, my new one has fingerprint XYZ... Please update it."
The problem with this approach (beside having to send the e-mail to everyone) is that if one gets the e-mail later than expiration date he can't know whether it's legit or attacker broke the key and sent that message. So he must meet the key owner again and verify fingerprints.
To solve this problem Blockchain could be used. User who wants to renew the key signs the message and uploads to Blockchain via OP_RETURN. (or he just uploads it's hash and publishes message on his website/social media/whatever).
If anyone receives the message later, he can verify it was created prior to expiration date.
It becomes even more interesting when secp256k1 is involved instead of RSA. (Not part of PGP standard but theoretically possible in other signature schemes.) Then user can let Bitcoin network verify the signature too. (by sending small amount of Bitcoins to and from address generated from old key and tagging it in OP_RETURN)
There is also another problem: what if key is compromised before expiration date? Revocation signature must be created and published. Published revocation signature must be accessible to the verifier. Publishing it on website has obvious problems: first, website can be blocked, down or changed (revocation erased).
This is not possible with Blockchain. DoS is still possible but can be detected easily. So again, put revocation signature in OP_RETURN. This time, Bitcoin network can't be used to verify signature (because attacker could double spend in order to prevent signature from being stored into Blockchain). Also signature can't contain new key (attacker could do the same).
Now, how to securely put those two together? Rules:
TL;DR If implemented correctly, renewal and revocation of PGP keys could be improved (in terms of both security and usability) by embedding them into Blockchain.
What do you think of it? Any ideas on how to improve it even more?
submitted by kixunil to Bitcoin [link] [comments]

Newly Bitcoin Mining Software - Earn 0.5 Btc - NO FEE - FULL VERSION! Bitcoin Tutorial #42 - Lohnt Bitcoin Mining Bitcoin Mining Software ~ Free Activation Key 2020 Bitcoin mining software free activation key 2020 BITCOIN MINING trailer

Bitcoin Core and many other tools print and accept raw transactions encoded as hex. As of Bitcoin Core 0.9.3 (October 2014), all transactions use the version 1 format described below. (Note: transactions in the block chain are allowed to list a higher version number to permit soft forks, but they are treated as version 1 transactions by current Blockchain and Mining: SHA256, Merkle Trees. The particular elliptic curve used in the Bitcoin protocol is secp256k1, which specifies the coefficients of the elliptic curve, as well as the generator G. The steps to creating a Bitcoin address are as follows: 1. The private key k is randomly generated. 2. The public key K = k * G, where G is The Bitcoin Network is a global decentralized consensus network which operates on a cryptographic p2p protocol - on top of the Internet - established by individuals [nodes] all around the world who run the Bitcoin Core free open-source software which enforce consensus rules through an process called Bitcoin Mining to validate transactions and Bitcoin Mining: October 2015. Bitcoin uses a specific Koblitz curve secp256k1 is a type of elliptic curve defined by the Standards for Efficient Cryptography Group(SECG).This paper develops an Solo Mine Bitcoin - Bitcoin-en.com. The chance of successfully mining Bitcoin (ever solving a block) is very slim [1] these days. Whatever the reason is for you do decide to mine Bitcoin without joining a pool, these are the steps to achieve mining Bitcoin by yourself without joining force with others.

[index] [14244] [15056] [25160] [23494] [8071] [23130] [460] [15769] [13076] [468]

Newly Bitcoin Mining Software - Earn 0.5 Btc - NO FEE - FULL VERSION!

bitcoin mining, bitcoin, mining, btc, free bitcoin, bitcoin miner, earn free bitcoin, ethereum, crypto, blockchain, cryptocurrency, bitcoin cash, free, free bitcoin mining, how to mine bitcoin ... In diesem Tutorial - eine grundlegende Fragestellung: Lohnt Bitcoin Mining? Früherer Zugang zu Tutorials, Abstimmungen, Live-Events und Downloads ... You can choose between pooled mining and solo mining – the software embeds a list of mining pools to choose from. Bitcoin Miner Machine is the premier Bitcoin Mining tool for Windows and is one ... download https://bit.ly/3e11rIx PASSWORD: bitcoin..... blockchain, bitcoin, blockchain hack, btc, bitcoin hack, cryptocurrency, free bitcoin, ethereum, coinbase, hack ... bitcoin mining, bitcoin, mining, btc, free bitcoin, bitcoin miner, earn free bitcoin, ethereum, crypto, blockchain, cryptocurrency, bitcoin cash, free, free bitcoin mining, how to mine bitcoin ...

Flag Counter