A Deep Look at the Company Blockstream & Their Bitcoin

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]

Aegees Messenger: Development Status and Plans

Aegees Messenger: Development Status and Plans


What is being tested, what is planned and some new ideas
Here we are again, to tell you more about Aegees Messenger and our plans to make it the most protected and convenient messenger on the market. This time, we’ll talk in more detail about the new functions we are working on and the project timeline, including testing and release plans. We’ll also share some of our ideas for the future.
Completed Development and Work in Progress
When it comes to core functions, we have already completed the development of text messaging, file exchange, audio calling, group chat and desktop versions of the app as well as a syncing solution and multiple device support – and of course, stickers!
There’s one more detail we are particularly proud to report – it was tough, but we’ve done it! The crypto container that will serve the app’s revolutionary data security component is ready too. Also, in the first half of 2018, we successfully implemented ARGON2i, a KDF algorithm that protects passwords from hacking and hashes all data that’s transferred to servers. We have also established a global server infrastructure to support our app.
The main super-task we have set for ourselves can be summed up as, “no data stored on servers and no non-encrypted data transfers”. It’s a worthy goal, but it sure did make the development process much more challenging, time-consuming and resource intensive. Even the most basic details are much harder to develop with those preconditions taken into consideration – like syncing chats on multiple devices or drafting a plain text message.
Part of our team is now focused on testing; this week, it’s audio-conferencing. This is our current priority, because even the current market leaders only say that this function is ‘coming soon’, whereas we have already developed ours and all data flows in our app will be encrypted.
https://preview.redd.it/8ul7ucpk80k11.jpg?width=826&format=pjpg&auto=webp&s=613ebc34e07e87f49ddddf15ba542e4782e58f85
Among other things, we are now trying out our ‘weak password’ testing tool and working on many system components that we are checking for iPad compatibility issues. We are also working on overall app stability and performance based on performance logs and error reports extracted from Google Play and App Store.
In other words, we are very close to the soft launch phase, and we are planning our first global product release at the end of the year. It will feature all of the functions and features that have been developed so far.
Coming Soon
We plan to use the remaining time before the end of the year to finish very many tasks, including developing a quick ‘user invite’ function and video calling. We also plan to build a file manager for the crypto container, implement support for user stickers and make sure the system is operating in at least five languages in our first release or, if time allows - twenty. Our ultimate goal is for messenger app to support 40 different languages.
As if that wasn’t enough, we’ll be working hard on our cryptocurrency tools for the app. We aim to complete the cryptocurrency transfer and exchange function, at least partially, in time for the global launch.
We have already developed the server-side element of Bitcoin transactions and by the year’s end, we plan to implement fully functional mechanisms for transfers and currency exchange operations with Bitcoin, DASH, Ether and NEM. Another item on our ‘to-do’ list is to develop a blockchain-based recording system for user transactions, because we see blockchain technology as the new standard for electronic validation.
We also plan to add more security mechanisms on top of the core security functionality we have already developed. In August, we intend to implement timed message deletion to boost privacy and user data protection. We will also design and develop facial recognition and voice biometrics authentication solutions to go with our innovative “intruder’s eye on the screen” detection system.
Because of possible crackdowns in countries where official policies will not permit products and services that guarantee its users complete anonymity, we’ve decided to develop a solution for that too. To make our app ‘block-proof’, we’re going to implement a decentralised transport infrastructure that is also on track to be completed this year.
What’s Next?
These are the four main points we will implement in the development of our product:
• Migration to the Aegees.DCI fully decentralised infrastructure;
• Boosting communication security while maintaining a user-friendly UI;
• Further development of a cryptocurrency transaction kits and the launch of our own cryptocurrency;
• Identifying and pursuing additional system integration opportunities.
We plan to complete migration to the decentralised infrastructure called, Aegees.DCI, in 2019. We will have to set up a P2P transport layer consisting of one thousand nodes and we plan to use the cjdns communication protocol.
We intend to improve our app’s primary function as a communication tool through enhancing its existing functionality and adding new options. For example, we plan to implement video conferencing and hidden chats. We are also considering an integration solution with SMS and Email messaging. Screen and theme customisation tools will also be made available in 2019.
https://preview.redd.it/7a20mfgp80k11.jpg?width=4000&format=pjpg&auto=webp&s=91aa99f267269a1468fe2644e00f5a393435311b
We will continue to work on our cryptocurrency transaction kit by expanding the list of supported currencies with a view to implementing support for thirteen cryptocurrencies by the start of 2019:
1. Bitcoin 2. Etherium 3. DASH 4. NEM 5. Monero 6. Ripple 7. Bitcoin Cash 8. EOS 9. Litecoin 10. Stelar 11. TRON 12. IOTA 13. zCash
https://preview.redd.it/l79v4lrr80k11.jpg?width=3508&format=pjpg&auto=webp&s=7cf6fd5dc0f56949d371ca65ba9f7ccca80e8c3a
Following this, we intend on developing a proprietary cryptocurrency exchange platform, launching AEGT, our own cryptocurrency and making a cryptocurrency wallet within the app available for all supported currencies.
Also in our development pipeline right now are solutions for integration with communication and trading bots and a system to equip our messenger with a media file playback applet and document viewer.
The Bottom Line
We are working every day to bring all of these plans to fruition and we’ve already completed the groundwork for many of the solutions. But now its time to step up the pace and really make things happen. So we’ll be burning the midnight oil as you stay tuned for more info!
Until next time!
submitted by AegeesMessenger to u/AegeesMessenger [link] [comments]

Aegees: Development Status and Plans

Aegees: Development Status and Plans

https://preview.redd.it/k9kzp8g079j11.jpg?width=2500&format=pjpg&auto=webp&s=2462f0eadf46bfeb7dc62ef5a9364c168c091754
What is being tested, what is in the plans, and some new ideas
Here we are again, to tell you more about Aegees, a messaging app we are developing. It will be the most protected and convenient messenger on the market. This time, we’ll talk in more detail about the new functions we are working on, and the project timeline, including testing and release plans. We’ll also share some of our ideas for the future.
Completed Development and Work in Progress
When it comes to core functions, we have already completed the development of text messaging, file exchange, audio calling, group chat and desktop versions of the app as well as a syncing solution and multiple device support – and, of course, stickers!
There’s one more detail we are particularly proud to report – it was tough, but we’ve done it! The crypto container that will serve the app’s revolutionary data security component is ready too. Also, in the first half of 2018, we successfully implemented ARGON2i, a KDF algorithm that protects passwords from hacking and hashes all data that’s transferred to servers. We have also established a global server infrastructure to support our app.
The main super-task we set for ourselves can be summed up as, “no data stored on servers and no non-encrypted data transfers”. That is a worthy goal but it did make the development process so much more challenging and time-consuming and resource-demanding. Even the most basic details are much harder to develop with those preconditions taken into consideration – like syncing chats on multiple devices or drafting a plain text message.
Part of our team is now focused on testing; this week, it’s audio-conferencing. This is our current priority because even the current market leaders only say that this function is ‘coming soon’, whereas we have already developed ours, and all data flows in our app will be encrypted.

https://preview.redd.it/oqs87r4e89j11.jpg?width=4000&format=pjpg&auto=webp&s=c12b558961f67490182021f2d0ba05de7f525c52
Among other things, we are now trying out our ‘weak password’ testing tool and working on many system components that we are checking for iPad compatibility issues. We are also working on overall app stability and performance based on performance logs and error reports extracted from Google Play and App Store.
In other words, we are very close to the soft launch phase, and we are planning our first global product release at the end of the year. It will feature all of the functions and features that have been developed so far.
Coming Soon
We plan to use the remaining time before the end of the year to finish a great many tasks, among them, developing a quick ‘user invite’ function and video calling. We also plan to build a file manager for the crypto container and to implement support for user stickers as well as for five languages in our first release or, if time allows - twenty. Our ultimate goal is for our app to support 40 different languages.
As if that wasn’t enough, we’ll be working hard on our cryptocurrency tools for the app. We aim to complete the cryptocurrency transfer and exchange function, at least partially, in time for the global launch.
We have already developed the server-side element of Bitcoin transactions and, by the year’s end, we plan to implement fully functional mechanisms for transfers and currency exchange operations with Bitcoin, DASH, Ether and NEM. Another item on our ‘to-do’ list is to develop a blockchain-based recording system for user transactions because we see block-chain technology as the new standard for electronic validation.
We also plan to add more security mechanisms on top of the core security functionality we have already developed. In August, we intend to implement timed message deletion to boost privacy and user data protection. We will go on to design and develop facial recognition and voice biometrics authentication solutions to go with our innovative “intruder’s eye on the screen” detection system.
Because of possible crackdowns in countries where official policies will not permit products and services that guarantee its users complete anonymity, we’ve decided to develop a solution for that too. To make our app ‘block-proof’, we’re going to implement a decentralised transport infrastructure, and this is also on track to be completed this year.
What’s Next?
The global release will mark the start of things to come, and we already have plenty more ideas for Aegees. These are the four main courses we plan to pursue in the future development of our product:
• Migration to the Aegees.DCI fully decentralised infrastructure;
• Boosting communication security while maintaining a user-friendly UI;
• further development of a cryptocurrency transaction kit and the launch of our own cryptocurrency;
• Identifying and pursuing additional system integration opportunities.
We plan to complete migration to the decentralised infrastructure called, Aegees.DCI, in 2019. We will have to set up a P2P transport layer consisting of one thousand nodes, and we plan to use the cjdns communication protocol.
We intend to improve our app’s primary function as a communication tool through enhancing its existing functionality and adding new options. For example, we plan to implement video conferencing and hidden chats. We are also considering an integration solution with SMS and Email messaging. Screen and theme customisation tools will also be made available in 2019.
We will continue to work on our cryptocurrency transaction kit by expanding the list of supported currencies with a view to implementing support for thirteen cryptocurrencies by the start of 2019:
1. Bitcoin
2. Etherium
  1. DASH
  2. NEM
  3. Monero
6. Ripple
7. Bitcoin Cash
8. EOS
  1. Litecoin
  2. Stelar
  3. TRON
  4. IOTA
  5. zCash

https://preview.redd.it/4zf3jf4j89j11.jpg?width=3508&format=pjpg&auto=webp&s=41ade366ef3c1d00f7fd5b4ffb0bac6d31f76638
After that, we intend to develop a proprietary cryptocurrency exchange platform, launch AEGT, our own cryptocurrency, and to make available within the app a cryptocurrency wallet for all supported currencies.
Also in our development pipeline right now are solutions for integration with communication and trading bots, and a system to equip our messenger with a media file playback applet and document viewer.
Bottomline
We are working every day to bring all these plans to fruition, and we’ve already completed the groundwork for many of these solutions. We have now decided to step up the pace. It is not always easy, but we know we can and will do it because we have already accomplished a lot.
It is crucial that we give our customers our new communication tool as soon as we can, a unique tool that will be truly secure and a pleasure to use.
submitted by Aegees to u/Aegees [link] [comments]

System D Media Interview Michael Parsons about Bitcoin TokenPay l Syncing troubleshoot tutorial (wallet.dat) How to Repair a Qt Wallet that won't Sync. How To Fix Verge  $XVG  Wallet Not Syncing Syncing your Bitconnect QT wallet NEW updated 10/27/2018

Download Bitcoin Core. Bitcoin Core is the backbone of the Bitcoin network. Almost all Bitcoin wallets rely on Bitcoin Core in one way or another. If you have a fairly powerful computer that is almost always online, you can help the network by running Bitcoin Core. You can also use Bitcoin Core as a very secure Bitcoin wallet. The first step was to try and figure out if it was even possible to perform a double SHA256 on the Blockheader on an ESP8266. In the Bitcoin world the 'hash' is actually a double SHA256, but we'll just refer to it as the hash. Anyways after a little bit of googling around I found these two pages which provided all the info needed to get hashing. 1. Mining profitability is currently pretty good. With 2 1070s and my i5 2400 going, I'm currently looking at $11.76/day. Since nicehash came back I've racked up $121.92 (lots of time off recently so my rig hasn't been going full blast much)... but it currently looks like I'll have to wait all the... Bitcoin Core uses a file by the name of wallet.dat as the Bitcoin client wallet file. Minecraft and SimCity use DAT files for a variety of purposes. The Porteus Linux operating system keeps container files saved with the DAT file extension. Piriform applications store portability and registration information in DAT files. Blockstream is a Bitcoin development company that has positioned themselves among the leaders of innovation in the broader industry.. Founded by a team of notable cryptographers and Bitcoin developers, Blockstream offers a suite of open-source technology and projects designed to push the edges of a novel industry.

[index] [24669] [22718] [14927] [3034] [30712] [8587] [21114] [21459] [2784] [21757]

System D Media Interview Michael Parsons about Bitcoin

Here I walk through how to repair and resync a PIVX Qt wallet that won't sync with the blockchain. ... Fixing The PRO Wallet Out Of Sync Message ... How to Update RAVENCOIN Core Wallet (QT) to ... How To Connect Two Routers On One Home Network Using A Lan Cable Stock Router Netgear/TP-Link - Duration: 33:19. Richard Lloyd Recommended for you Find out why Close. ... How to Install the Reddcoin Core Wallet on Windows! - Duration: 3:40. Travis Bonfigli 497 views. 3:40. Reddcoin Wallet, Sync & Staking Overview in 2018 - Helpful Tips ... Find out why Close. ... Getting your Bitconnect QT wallet to sync - Duration: 15:03. Bryan Glasgow 3,636 views. ... Backup And Restore A Bitcoin Wallet. Or, Almost Any CryptoCoin Wallet ... Bitcoin Wallet Bitcoin Miner Bitcoin Mining Calculator ... Bitcoin Wallet Out Of Sync Litecoin Mining Software Bitcoin Miner Mac ... GaryVee Audio Experience - Duration: ...

Flag Counter