Alles was man über Bitcoin wissen muss

Gridcoin 5.0.0.0-Mandatory "Fern" Release

https://github.com/gridcoin-community/Gridcoin-Research/releases/tag/5.0.0.0
Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that.
Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap.
We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout.
Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.

Highlights

Protocol

Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now.
Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER the v11 transition (around Oct 4th) and BEFORE October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date.
The transition height is also when the team requirement will be relaxed for the network.

GUI

Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.

Blockchain

The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use.
There are so many goodies here it is hard to summarize them all.
I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures.
The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!

Summary Changelog

Accrual

Changed

Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.

Removed

Beacons

Added

Changed

Removed

Unaltered

As a reminder:

Superblocks

Added

Changed

Removed

Voting

Added

Changed

Removed

Detailed Changelog

[5.0.0.0] 2020-09-03, mandatory, "Fern"

Added

Changed

Removed

Fixed

submitted by jamescowens to gridcoin [link] [comments]

An In-Depth Guide to: How do I Fix my Ledger Nano’s Stuck Ethereum Transaction?!?!?! (It’s Been Stuck for Weeks and NOTHING Traditional has Worked!!!!) As Well as: How Do I Choose My Nonce??? I’ve Tried MetaMask, MEW/MyEtherWallet, and Others, but Nothing is Working Correctly!!! I’m Dying by Stress!

So, if you were like me 1-2 months ago, you’ve probably already gone through 2,or 3, ...or 40 articles and guides that probably say something like:
“YeP, eVeRy EtHeReUm UsEr WiLl EvEnTuAlLy HaVe ThE LoW-gAs ExPeRiEnCe, YoU’rE nOt AlOnE! DoN’t FrEaK OuT tHoUgH; ThErE iS a WaY tO fIx It!”
Chances are, every time you read another useless article, you want to kill the nearest inanimate object, even though it was never alive in the first place. Nonetheless, you’re gonna kill it as much as it can be killed, holding nothing back; or, you’re just plotting to and slowly getting closer to executing the plan (and the object) every time you are insulted once again.
However, if you have the ability to download software (MyCryptoWallet) on a PC, it should be safe to relax now. I think you’ve finally found some good news, because I am 99.99...% sure this will work for the issue that so many people are having at this time, around the end of the month of May, year 2020.
More and more people are likely to be having this issue soon, since Ethereum's gas prices have been insanely high lately as well as having 300% price changes in a matter of minutes; Etherscan’s Gas tracker is nearly uselessly-inaccurate at this time. I've heard that there's a congestion attack; that was said a week ago, and it appears to be ongoing... (I can't think of any other suspect besides Justin Sun to blame it on... it must be incredibly expensive to overload the blockchain for this long... I may be wrong though...)
 
Let’s begin
For myself, I was trying to send an ERC20 token when this dreadful issue attacked. Specifically, the token was either BSOV or GRT; I sent them 1 after the other and the first succeeded, and the second one took over a week.
(They’re both great tokens in my opinion and deserve much more attention than they’ve been getting. BSOV is nearing its 1 year anniversary as I write this, and GRT is still in its 90 day community-development progress test, so of course I'm gonna take this opportunity to "shill" them; they are great tokens with great communities).
I was able to finally fix it, after a week of mental agony (also the txn finally processed 1-2 hours before I found the solution, robbing me of the gratitude of fixing it myself... (╯‵□′)╯︵┻━┻ ...but now I guess I can hopefully save some of you the headaches that I endured... ) I’m providing the ability to do the same, in a step by step guide.
Why did I go through all of this trouble? I'd fault the fact that I have ADHD and autism, which in my case can multiply each other’s intensity and cause me to “hyper-focus” on things, much much more than most with the same qualities, intentionally or not. Adderall is supposed to give me a bit of control over it, but except for in a very-generalized way, it’s still 90% up to chance and my default-capabilities to allow me control over my attention with self-willpower. But also Karma and Moons pls... ʘ‿ʘ
 
  1. In MyCrypto, (I'm using the Windows 10 app, version 1.7.10) you will open to a screen that says "How would you like to access your wallet?". Choose Ledger, of course. (Unless your here for some non-ledger issue? Idk why you would be but ok.)
  2. On the next screen (having your nano already plugged in, unlocked, and opened into the Ethereum app) click "Connect to Ledger Wallet"
  3. A screen overlay should appear, titled: "Select an Address". Here is where it may get confusing for some users. Refer to "AAA" below to know how to find your account. (Geez, sorry lol that was a huge amount of info for a reddit reply; I might've over-elaborated a little bit too much. but hey it's valuable information nonetheless!)
  4. After escaping the "AAA" section, you'll have accessed your account with MyCrypto. Awesome! To find your ERC20 tokens, (slight evil-laughter is heard from an unidentifiable origin somewhere in the back of your mind) go to "AAB".
  5. (You may have decided to find the token(s) on your own, rather than daring to submit to my help again; if so, you may pity those who chose the other path... ~~( ̄▽ ̄)~~) Now, once you've added your token, you should revert your attention to the account's transfer fill-out form!
  6. I'll combine the steps you probably understood on your own, already. Put in the address that your stuck transaction is still trying to send currency to. If an ERC20 token is involved, use the drop-down menu to change "ETH" to the token in trouble. Input your amount into the box labeled... wait for it... "Amount". Click on "+Advanced".
  7. Refer to Etherscan.com for the data you will need. Find the page for your "transaction(txn) hash/address" from the transaction history on the wallet/Ethereum-manager you used to send from. If that is unavailable, put your public address that your txn was sent from into the search tool and go to its info page; you should be able to find the pending txn there. Look to open the "more details" option to find the transaction's "Nonce" number.
  8. Put the nonce in the "Nonce" box on MyCrypto; you will contest the pending txn with a new txn that offers larger gas fees, by using the same nonce. If (but most likely "When") the new transaction is processed first, for being more miner-beneficial, the nonce will then be completed, and the old transaction will be dropped because it requests an invalid, now-outdated nonce. Your account will soon be usable!
  9. Go to the Gas Tracker, and it may or may not provide an informative reading. Choose whatever amount you think is best, but choose wisely; if you're too stingy it may get stuck again, and you'd need to pay another txn's gas to attempt another txn-fix.
  10. At the time I write this, I'd recommend 50-100 gwei; to repeat myself, gas requirements are insane right now. To be safe, make the gas limit a little higher than MCW's automatic calculation, you may need to undo the check-mark for "Automatically Calculate Gas Limit".
  11. Press "Send Transaction"!!!
  12. You will need to validate the action through your nano. It will have you validate three different things if you are moving an ERC20 Token. It's a good idea to verify accuracy, as always.
 
Well, I hope this worked for you! If not, you can let me know in a reply and I'll try to figure it out with you. I like making these in-depth educational posts, so if you appreciate it please let me know; I'll probably make more posts like this in the future!
( Surely this is at least far better than Ledger's "Support" article where they basically just tell you "Yeah, we haven't bothered to make a way to manually select nonces. I guess we might try to make that available for Bitcoin accounts at some point in the future; who knows? lol"... that's not infuriating at all, right?)
 
AAA:
Before I tell you how to find your address, I will first make it clear, within the italicized text, exactly which address you are looking for, if you are not already sure:
You may also skip the text written in italics if your issue does not include an ERC20 token, if you wish.
Ledger Live can confuse some users with its interface. On LL, to manage an ERC20 token, you first must go to your Ethereum account and add the token. When you then click on the added token under "Tokens" below the graph chart for your account's ETH amount over time, the screen will then open a new screen, that looks just the same, except focused on the specific ERC20 token. To confuse users further, there is then an option to "Star account", which then add the ETH icon with the ERC20 token's first letter or symbol overlapping, onto the easy access sidebar, as if it was another account of similar independency to the ETH account it was added to.
This improperly displays the two "accounts" relation to each other.
Your ERC20 holdings (at least for any and all ERC20 that I know of) are "held" in the exact-same address as the Ethereum address it was added to, which also "holds" any Ether you've added to it. You send both Ether (ETH) and any ERC20 Tokens to and from only Ethereum addresses of equivalent capabilities, in both qualities and quantities. In all basic terms and uses, they are the same.
So, to know what the problematic account's address is, find the address of the Ethereum account it was added to in Ledger Live.
Now, to find your address on MyCrypto, the most reliable way to find it, that I am aware of, is this:
Open Ledger Live. Go to the screen of your Ethereum address (again, this is the one that you added your ERC20 token, if applicable. If you're not dealing with an ERC20 token, you may ignore everything I've put in Italics). Click on "Edit account"; this is the icon next to the star that may look like a hex-wrench tool. On the new screen-overlay, you will see "> ADVANCED LOGS". Click on the ">" and it will point down while revealing a drop-down with some data that you may or may not recognize/understand. Likely to be found indented and in the middle-ish area, you will see this line, or something hopefully similar:
"freshAddressPath": "44'/60'/X'/0/0",
The "X" will probably be the only thing that changes, and the actual data will have a number in its place; it will not be a letter. Let's now put that line to use in MyCrypto:
Take the 44'/60'/X'/0/0 , and make sure you DO NOT copy the quotation marks, or that comma at the end either.
You can do this before or after copying and/or pasting, but drop the second "/0" at the end; it was not necessary in my case, I expect that you won't need it either, and will probably just make MyCrypto see it as an invalid input.
Okay, now go back to the "Select an Address" screen-overlay in MyCrypto.
Next to "Addresses", click on the box on the right, and you should be shown a list of options to select from in a drop-down menu.
Scroll all the way down, and you should find the "Custom" option at the very bottom. Select it.
A new box will appear; probably directly to the right of the now-shortened box that now displays the "Custom" option that you just selected. This box will offer an interface for typed input. ...yep... once again, believe it or not, you should click it.
Type " m/ ", no spaces before or after.
Type in or paste the data we retrieved from ledger live.
The box should now hold this:
m/44'/60'/X'/0
Again, X should be a number. In fact, that number is probably equal to the number of Ethereum (not including any ERC20 wannabe) accounts that you've made on Ledger Live before making the one we're working on right now! (1st Eth. Acc. would have: X = 0, 2nd: X = 1, 3rd: X = 2, ...)
Make sure you've included every apostrophe ( ' ), and solidus ( / ); there is NO APOSTROPHE for the "m" at the start and the "/0" at the end!
If you press the enter key or click on the check-mark to the right of where you typed, the appropriate addresses will be generated, and the address you created through Ledger Live should be the first one on the list!
Select your address and press "Unlock", and you are now accessing your account through the MyCrypto app's interface!
 
AAB:
In order to access your ERC20 token, you will need to add them first.
You may have to scroll down, but on the right-side of your unlocked account screen, you'll see a box with "Token Balances" as its header.
Click "Scan for tokens". This may take a short bit of time, and when it's done it may or may not display your ERC20 token. If it worked, you can head on back to the main part.
If you got the result I did, it won't display your token, or, if our result was exactly the same, it won't display any at all. However, you should now have the "Add Custom Token" option available, so see where that takes you.
You should discover four boxes, specified in order (Address/ Decimals / Token_Symbol / Balance). You may only need to fill in the "Address" box, but if you need to fill others, you'll find those with the token's address; here's 2 ways to find it, if you don't already know.
Method I:
Since you've probably already been managing your token with Ledger Live, you can go to the LL screen of your "account" for that token; Right next to the account's icon, and directly above the name, you'll see:
Contract: 0x??????...????????
Yes, go on; click it. You'll find the token's page on Etherscan; this was just a shortcut to the same place that both of the two previously referenced methods lead to. Skip to method... III?
Method II:
Go to Etherscan.com, or a similar Ethereum-blockchain-monitoring website, if you have a different preference. Search for the name of your token, and you should be able to see it as a search result. Activate your search manually of by selecting search option. Continue on with Method III.
Method III (Iⅈ what makes you think there was a third method? I said 2!):
At this point, you should find the "contract address" somewhere on the screen. This is the identity of the creature that breathes life into the token, allowing it to exist within the world of Ethereum. Steal it, and tell MyCrypto that you've left some of "your" tokens in the address of your ledger's Ethereum account. MyCrypto will trust and believe you without any concern or doubt, just by putting "your" contract address in the box for "Address"; it's almost too easy!
Well whaddya know, this one isn't actually too long! Don't tell anyone who may have taken a little longer whilst finding out how to do it themselves, though. There's value in trying to do something on your own, at least at first, so I'll let them think they made the right choice (¬‿¬). But take this star for humbling yourself enough to seek further help when you need it, since that is a very important life skill as well!
(o゜▽゜)o☆
Now, back to the useful stuff at the top...
 
EDIT: A comment below made me realize that this info should be added too. Here is my reply to the comment saying I could just use MetaMask. I said in the title that this guide is for questions where MEW and MetaMask aren’t working, but I guess it’s easy to miss. I used my u/caddark account to respond:
(Using this account because u/caddarkcrypto doesn’t meet the karma/age standards to comment; the post had to be manually approved.)
I guess I didn’t make it entirely clear; sorry:
The target audience for this guide is anyone with a stuck Ethereum transaction that was initiated through Ledger Live AND are experiencing the same difficulties I had encountered while trying to fix this issue for myself.
This wasn’t any regular stuck Ethereum transaction. Apparently before, there was an issue that made a Ledger Nano nearly impossible to connect to MetaMask (which is also Brave Browser’s integrated “crypto wallet” for the desktop version) and/or MEW (also perhaps any other browser wallets made for chrome and/or brave) that I heard was supposed to be fixed in a recent update. It might’ve been mostly patched, idk, but during my experience, (in which I was using the latest version of Ledger Live that is available right now,) that issue still remained.
The really weird part was that it successfully connected to the browser wallets again after I fixed the stuck transaction. At first I thought that somehow the txn was what was bugging the connection. However, later, during no txn issues, I was again unable to connect.
Seeing the same connection error again later, I opened up the MCW app I downloaded the day before, and was going to just use that. While in the process of operating MCW, I suddenly had another idea to try for the browser wallet so I went back to that just to quickly test it.
The browser wallet worked perfectly...
I don’t know how, but I think that somehow, something in MCW’s software, makes the browser wallets work. They don’t work for me without having MCW opened in the background first.
EDIT 2: Markdown decided to stop working after I did the first edit... I might fix it tomorrow... how did that happen though??? What did I do?
EDIT 3: nvm, I'm just fixing it now; I won't get much sleep tonight I guess.
submitted by CaddarkCrypto to CryptoCurrency [link] [comments]

I have some questions about IOTA, the tangle, and m2m

I'm very curious about IOTA and what the tangle has to offer. Intuitively, things make sense, but I find all the FAQ/YouTube answers to be too high-level.
  1. If a user-transaction (via their wallet) is responsible for the verification/PoW to further the tangle network, where does the complete ledger persist? Do they exist on persistent server nodes and if so, what is the incentive to run such a node? (Answered - There are no incentives other than the want for the network to succeed.)
  2. How does verification work? As far as I understand the DAG has one root and branches out infinitely with some 'tangle' in-between. What kind of search/filter algorithm is used to make sure that all the transactions of an address is collected and the total sum/difference of their balance is properly calculated? (Answered - An occasional 'snapshot' refreshes a flat table that provides an efficient lookup of up-to-date balances for all accounts.)
  3. An addendum to the above: How does PoW in IOTA work? Does it search for the nonce for the right number of leadings zeros like in Bitcoin?
  4. What exactly does the coordinator do?? (Answered - Acts as an authority periodically marking verified transactions for accounts to direct their next transaction, essentially providing low-risk branches in the tangle.)
  5. Regardless of the scaling/fee issues within Bitcoin (suppose the Lightning Network works as advertised and these issues are largely resolved) what makes IOTA particularly well-suited for M2M transactions? How is it better than a bot with an address on any other crypto-platform?
  6. Are IOTA node (if they exist) software open source? (Answered - Yes it is!)
  7. There is no mining in IOTA and the supply is set. Who owns them? (Answered - Currently, 500 accounts control 93% of IOTA supply).
I have more questions but perhaps we'll start with these.
Thanks in advance!!
submitted by the-eclectic-chair to Iota [link] [comments]

Blockchain to fix horribly broken e-mail system like it is today?

E-mail as it is, is horribly broken. Horrendously broken.
It wasn't that many years ago that you could be assured your e-mail reaches whoever you were mailing to. Today it is a mere suggestion, that perhaps this should be delivered to this person, at least for any automated e-mail. This seems to be creeping to manual, organic email as well. Hell, we are seeing even internal e-mails being flagged by spamassassin as spam, organic, human written conversations! In that instance, the spamassassin is also maintained by one of the largest hosting providers in the world...
Hotmail/MS services has been for years (atleast about 4 years now!) been silently dropping email, not all, but some. There's a bit of relief lately, as they have started to favor a bit more marking as spam, rather than silently dropping.
I know, most email users don't see this problem, but those who use email a lot to do their work, and those who need to send automated emails (say, welcome e-mails for a service) this is a big problem. (Disclaimer, for us, our niche of hosting probably causes flagging as well. Our site is blocked by many corporate firewalls for example)
Blockchain to the rescue?
This is an idea i've been toying around with a few years. What if any single e-mail would cost a faction of a cent, and who receives the e-mail, gets paid for it? Now that would solve a lot of problems. I realize there has been some half assed attempts on blockchain based e-mail, but they are about replacing email (never going to happen). Using blockchain to enhance the current experience, with least minimal friction should be the goal, not re-inventing the wheel.
Imagine a say 0.01 cent (0.0001 USD) cost per e-mail. This price would not be cost prohibitive even for free e-mail service providers (Ad revenue etc. should exceed this value), never mind any legit e-mail users. Especially considering you get paid for receiving. So all legit e-mail services would work rather well regardless of the cost. (never mind free email service could profit from this)
Spam however? To send 1 million emails you would need to pay 100$. How many spammers would continue doing so? At least it makes things much harder, not so easy to use a botnet to send your email when you need to include your private key(s) to the botnet, or make some kind of private key management system, makes more complicated.
Small business newsletters? Say you need to send 100k e-mails to legit customers, 10$ is nothing. To human time crafting that newsletter is order (possibly orders) of magnitude greater than that.
Price would also fluctuate as per the market. The most difficult thing would probably be setting the self balancing mechanisms to keep per mail cost sensible. As such, the biggest hurdle in this might not be technical at all.
Technically, how could this work?
Sender sends a TX for e-mail they are sending for recipient. This TX contains message with mail ID, and a segment which can be used with the email contents to unlock the private key for the payment. This way it is verified that recipient mail servers receives and reads the email. Once the recipient server has calculated the private key, they can either TX the received sum to their wallet, or this needs to be formatted so that once the sender has sent it, they cannot recover the private key and double spend (technical hurdle A. For someone who knows their stuff unlikely to be an major hurdle)
Step by step repeat: * Sender checks if recipient has "MailCoin" capability * Sender sends TX to recipient * Sender sends the email to recipient * Recipient notices on mail header (say x-mailcoin-tx: TXID_HERE) that this is a "mailcoin" mail * Recipient checks TX if it has been received * Recipient puts the mail on delivery queue, antispam is instructed of heavy negative score (MTA admin configurable) * Recipient claims the value of the TX (this is the hurdle A). Recipient can only claim the TX value in case they have received the full e-mail. (Question, can this step be pushed even further down the delivery chain, but still remain MTA only level without mail client support?). Most likely solution is that the header contains the encrypted private key, and chain TX contains the key to decrypt that private key to claim the coins, or vice-versa?
Once recipient has the email & payment, they simply mark on their Antispam a automatic lower score and deliver it normally.
E-mail server side we have several components:
Most typical scenario would be the Recipient server works as outgoing as well, with single wallet. So depending on your mail volume, do you send or receive more on that wallet you might never need to worry about the coins (except for value going skyhigh and having like 10k $ worth of "MailCoins").
So perhaps additional components on per use case are needed, or more likely rudimentary scripting capability (ie. "MailCoin" daemon api) to keep the balances in check.
Technical hurdle B: This needs to be super super simple to setup. Or sufficient financial incentive. One would need to develop standard components & configs for exim, postfix, and other MTAs. Infact, make it autogenerate wallet ID etc. and easy to replace or import private keys etc. to put in coins for sending if you need to.
Privacy: On the blockchain you would not see the e-mail contents, only that e-mail likely took place (TX with mail UUID) to recipient. If sender can be deciphered it depends on them if it can be traced who they were. Automatic mixers? :) Recipient can also keep cycling the receive addresses to keep things private if they want to.
The biggest problem i see here, is that if an attacker can deduce the sender and/or recipient, it might to lead to some issues out of the scope of technical solutions. If attacker could read the emails, they would already have accomplished MitM and could just grab all e-mails.
Default implementation should be so, that from recipient address outsider cannot deduce the recipient server nor hostname.
Also, if attacker gains access to your mail with full headers, they could see the TXs in blockchain. MTA might need to scrub mailcoin related headers (yuck, scrubbing headers ....) for paranoid users, but most likely solution is that recipient retransmits those mailcoins as soon as they got the private key for the balance.
Blockchain: Blocks needs to be done every 10seconds or so, it needs to be fast. Preferrably even every 5 seconds, as not to cause any undue delay. Then again, if your application is reliant on receiving email within seconds, one should consider another means for communicating. Imho, email should be considered a little bit like snail mail, but on internet pace: Couple minutes delay is just OK.
Block size given the e-mail volume needs to be fairly large as well, considering the time between blocks. This is technical hurdle C: Hosting the full blockchain. I can easily foresee that this would grow to be terabytes in size. However, any large email operator would have vested interest in ensuring smooth operation of the blockchain, and for them, running a full node would have neglible cost.
(Technical hurdle C) Single email sent using the system could easily have TX contents of 100 bytes + TX headers + block headers etc. Say 100 bytes, and 100 million emails per day: 9.31GiB per day, 3 399GiB per year, 5 years later: 16.60 TiB just for the mail TXs.
Some estimate there is 200+ billion emails per day, but we all know large portion of this is spam. But even at 50 billion emails a day, 100 bytes per mail TX would add to 4.55TiB per day! So optimizing the blockchain size is obviously going to be important. The volume will be obviously much smaller as semi-spam (those daily half opt-in spamvertising from companies you know) will be lower as well. So probs 100+ billion emails per day at 100% adoption.
Blockchain should then be compressed, the whole block. Algorithm probably should favor speed over compression rate, and should be task specifically optimized (needs a simple reference release, where you can just stream the block contents into it and get output as compressed or uncompressed). The more compression there is, the more full nodes will be hosted by smaller operators :)
For large e-mail server clusters there should be central store for the blockchain, but this can be accessed on the system administratoconfig level already. The MTA components will just remotely talk to single full node daemon (so not really different from many implementations in existence right now), instead of each one running locally a full node.
At today's cheapest hosting rates 16.60TiB is roughly around 85-100€ a month. Purchase cost per 8TB drive is around 230€ mark right now, externals are cheaper. Not an issue for any even semi serious mail provider. Not even issue for datahoarder individuals.
However at 100 billion mails per day: 9.09TiB per day added, which is prohibitively large! We should be targeting something like 20bytes per mail final storage spent, or even less.
If it looks like it is going to grow really large, full node needs to have configurable multiple storages, so they can store parts of the blockchain on multiple different devices (ie. individual might choose to have it on 4 different external drives).
Filesystem side optimizations are needed as well, but these are fairly simple, just split into multiple subdirectories by the 10 thousand blocks or so, ie. 1 for blocks 1-10k, 2 for blocks 10 001 to 20k etc. Filesystems get exponentially slower the more files there is per directory. 10k might start to show slowing down, but is not significant yet.
Nodes could also implement secondary compression (compress multiple blocks together), if the blockchain starts to become stupid large. If it starts to become impossible to maintain, we could possibly implement a scrubbing methodology, where very old blocks get the TX contents wiped as they are not necessary anymore. Should not be an issue
Blocks with 10second target generated per annum: 3 153 600 Mails per 10second: 115 740 e-mails per 10second block. Final compressed size (say 20 bytes per mail): 2.20MiB + headers etc. per block Let's start small and allow linear growth to this, say 0.1% per day (36.5% annual) and start from 20k / 512KiB. After 3 years: 41.9k / 1072.64KiB per block, After 10 years: 93k / 2380.8KiB. (2027 we should have HDDs in the size of 30TB and daily max size for chain growth is 19.61TiB)
On the positive side every problem is an opportunity in disguise. If the blockchain is large, once again botnets will have a hard hard time to spamming, they can't host the full blockchain on infected machines. They will need to develop centralized mechanisms on this regard as well. One method i can see is by having TOR client built in, and via .onion domain to anonymize, but this is two way street, security researchers could exploit this (see above about the private keys) as well. Even without botnets, spammers will need to dedicate significant resources to host the full blockchain.
On the flip side, if spammer has also mining operation on the same local area network, they have both the income for mailcoins + full blockchain, and could leverage economies of scale, but this too would increase cost. And after all: This is all about increasing cost for spamming, while having the price in vicinity where real e-mail users, real businesses it is not a significant impact, or may even be an income source
Client side
Zero, Nada changes. No changes to outlook, thunderbird etc. Everything works under the hood at the MTA level. Very easy adoption for the end user. Everything is in the backend, server side.
Economics for users
Cost of operation has above been shown to increase wildly for spammers. But how about normal use cases?
Joe Average: They receive e-mail a lot more than they send, all kinds of order confirmations, invoices, newsletters and other automated e-mail. They will actually earn (however tiny amounts) from using this system. So for the masses, this is a good thing, they will see the earning potentials! which brings us to ....
New business opportunities! I could foresee a business setting up spam traps, the more e-mail you receive the more you earn! So it pays to get your receiver into spam lists. You don't ever need to read these, just confirm receive of them. All of sudden we could see even greater numbers of invalid e-mail addresses in spam lists, making spamming ever more expensive!
Free email services might proof to be extremely profitable, to the point of potential revenue sharing with Joe Averages (and above spamtraps). Because free email is mostly joe averages, they will have greater influx than outgoing. On the caveat, free email needs to have limits, but due to the low cost and potential of earnings, they could implement "mail credits" system, base is like 20 emails a day, but each received email could increase this credit limit. As such, it makes actually sense for free email services to implement this at the very least on the receiving side.
Business mass emailings. A business which has 100k valid e-mails on their database will not have a problem with paying few dozen bucks to have their mass mailing delivered. BUT they will make extra sure the content is good and targeted, something the recipient wants to receive. These will be the biggest spenders on email, apart from spammers.
ISPs, hell they get paid to provide e-mail. And they are on the same spot as free email service providers, they stand to earn more than spend!
Blockchain economics
This is where things might get interesting, there is so much potential.
However, there are several things definitively should not be done:
1 & 2 are easy, just do not mine outside of testnet prior to launch. (If devs get paid by companies, there is conflict of interest as well, but let's not get into that right now)
3: Miners and/or full node maintainers decide what goes on. Probably miners like bitcoin is supposed to.
4: Infinite & preferential supply: No after the launch "contracts" etc. to give coins to preferential parties, it should remain as on the launch unless majority consensus says there will be a change. Proof of stake is gray area imho, but then again also proof of work is the rich gets richer.
Mining: Storage requirement is a blessing in disguise, the massive storages required for this to function means that there will be no central hardware developer who sells all the shovels, without significant other markets. Ie. WD, Seagate, Toshiba the main players.
This means algo needs to be based on the full blockchain being hosted. The hashing needs to be so that GPUs are the king most likely, since almost anything good for CPUs is also doable in GPUs. Eventually someone will likely come with ASIC alternative, but due to masses of data it WILL require high bandwidth, high memory. Nothing like bitcoin currently, where low bandwidth, no memory requirement for the ASIC. There needs to be some expensive commodity components in there (RAM, Storage), and as such GPUs are the most likely candidate, and the bottleneck will not likely be computation, but I/O bandwidth.
Quickly thinking, previous block could include number of blocks to be included on the next for verification, in a highly compressible format. Let's say difficulty is number of blocks to be hashed, or from difficulty you can calculate number of blocks to be included. Previous blocks miner just chooses on random blocks to be included on the next one. Listing 10 series of blocks to be included, which can include series instructions. It could request block #5729375+100, or #357492+500 stepping 5 (every 5th block). Hell the random generator could use last block as seed for the next one to make it deterministic YET random as the emails and TXs change. (WTF, Did i just solve how the algo needs to work?!?) Only blocks which would differentiate is the first few, and obviously Genesis, for which an "empty" block would be what is to be hashed.
Hashing algo could be SHA256 because of the high requirement of streaming data, and most ASIC miners lacking in bandwidth (infact, it could be made compatible with bitcoin, but only those ASICS with higher I/O bandwidth than storage/ram I/O bandwidth is could actually boost the perf)
Different hashable list operations could be (on the block list what to be hashed on the next one): * Single block * Block # + number of blocks * Block # + (number of blocks with stepping) * Block # + number of blocks chosen by random using each hashed block as the seed for choosing next one (makes prefetch, preread, caching not work efficiently) * Number of previous blocks mined (ie. 50 last blocks) * Above but with stepping operator * Above but with choose random next X blocks, with variations based on the last hashed, sum of the hashed * All random pickers would have operation modes for the seed to be used: From hashed sum, the whole block, block contents, block header
These modes would ensure the blocks are there and makes it a lot dependable on variable factors, RAM speed, I/O seek time, I/O bandwidth.
This way we have proof that the miner has access to those blocks in efficient manner and the full blockchain is stored there, even if it is not practically retrievable from him / her over the internet for others to obtain a copy. HOWEVER, due to the data volumes, i think it is given they have fast access, but a miner would probably prefer not to share their blockchain contents to have bandwidth free for their mining, as the deadlines are tight. It could be built into the full node spec that they do not accept new blocks from sources which are not ready to supply any given block, and perhaps even periodic test of this. However, this would be unenforceable if people start running custom coded nodes which disables this, as it is not part of the blockchain calculation. It is not miner's benefit to "waste" precious bandwidth to serve others the vast blockchain, meanwhile it is end users benefit those running full nodes without mining to get them fast. So an equilibrium might be reached, if miners start loosing out because other miners will not share their blocks, they will start offering them, even if prioritized.
At 2MiB blocks, 10 second deadline, a miner would preferentially want the new block within 500ms, which would be barely sufficient time for a round trip across the globe. 500ms for 2MiB is 4MiB/s transfer rate inbound, and when block found you want it out even faster, say 250ms you'll need 8MiB/s burst which very very few have at a home. At more usual 1MiB/s it would take 2secs to submit your new block. On the other hand, if you found the block, you'd have immediate access to begin calcing the next one.
Block verification needs to be fast, and as such the above difficulty setting alone is not sufficient, there needs to be nonce. Just picking the right block is not guarantee there will be match, so traditional !???? nonce needs to be set as well most likely. As such, a lot of maths needs to be done to ensure this algorithm does not have dead ends, yet ensures certain blocks needs to be read as full and stored fully by the miners, just plain hashes of the blocks is not sufficient.
Perhaps it should be block data + nonce, then all the blocks hashes (with nonce, or pre-chosen salt) and to be generated block combined hash with nonce needs to have certain number of zeroes. Needs testing and maths :)
So there are many ways to accomplish proof of storage, we'd need just to figure out the which is the best.
Sidenote, this same algo could potentially be used with different settings for immutable, forever storage of data. Since there is no continuing cost to store data, TX Fee for every message (data) byte should be very high in such a coin.
Supply. Needs to be predictable and easy to understand. It would be preferential the standard mailing out is always 1x MailCoin, albeit coin itself should be practically infinitively divisable, and as such supply needs to be in the trillions eventually. But these things get complicated really fast, so we need to set a schedule.
Current email use is very large, so we should have something in the same magnitude. 8640 blocks per day - so maybe 10 000 coins per block == 86 400 000 new coins per day == 31 536 000 000 new coins per year, halving every 2 years. First halving: 63 072 000 000, Second halving: 94 608 000 000, Third (6 years): 110 376 000 000, but only halving 4 or 5 times to keep some new supply for ever increasing adoption and lost coins.
Got all the way here? :D
Thanks for reading up. Let me know what you think, and let's start a discussion on the feasibility of such a system!
I cannot develop this myself, but i would definitively back an effort up in the ways i can if anyone attempts to do something like this :) And i know i got probably many of the details incorrect
The main point of the methods described above is ease of adoption. Without adoption any system is worthless, and with email, you just cannot replace it like that (see the attempts trying to replace IPv4 with IPv6 ...), but you can enhance it. adoption is very critical in communications systems. (No one would have a phone if no one else had a phone)
Addendum 1: Forgot to add about pricing and markets, read comment here
Addendun 2: Bad actors and voting
submitted by PulsedMedia to Bitcoin [link] [comments]

The Nexus FAQ - part 1

Full formatted version: https://docs.google.com/document/d/16KKjVjQH0ypLe00aoTJ_hZyce7RAtjC5XHom104yn6M/
 

Nexus 101:

  1. What is Nexus?
  2. What benefits does Nexus bring to the blockchain space?
  3. How does Nexus secure the network and reach consensus?
  4. What is quantum resistance and how does Nexus implement this?
  5. What is Nexus’ Unified Time protocol?
  6. Why does Nexus need its own satellite network?
 

The Nexus Currency:

  1. How can I get Nexus?
  2. How much does a transaction cost?
  3. How fast does Nexus transfer?
  4. Did Nexus hold an ICO? How is Nexus funded?
  5. Is there a cap on the number of Nexus in existence?
  6. What is the difference between the Oracle wallet and the LLD wallet?
  7. How do I change from Oracle to the LLD wallet?
  8. How do I install the Nexus Wallet?
 

Types of Mining or Minting:

  1. Can I mine Nexus?
  2. How do I mine Nexus?
  3. How do I stake Nexus?
  4. I am staking with my Nexus balance. What are trust weight, block weight and stake weight?
 

Nexus 101:

1. What is Nexus (NXS)?
Nexus is a digital currency, distributed framework, and peer-to-peer network. Nexus further improves upon the blockchain protocol by focusing on the following core technological principles:
Nexus will combine our in-development quantum-resistant 3D blockchain software with cutting edge communication satellites to deliver a free, distributed, financial and data solution. Through our planned satellite and ground-based mesh networks, Nexus will provide uncensored internet access whilst bringing the benefits of distributed database systems to the world.
For a short video introduction to Nexus Earth, please visit this link
 
2. What benefits does Nexus bring to the blockchain space?
As Nexus has been developed, an incredible amount of time has been put into identifying and solving several key limitations:
Nexus is also developing a framework called the Lower Level Library. This LLL will incorporate the following improvements:
For information about more additions to the Lower Level Library, please visit here
 
3. How does Nexus secure the network and reach consensus?
Nexus is unique amongst blockchain technology in that Nexus uses 3 channels to secure the network against attack. Whereas Bitcoin uses only Proof-of-Work to secure the network, Nexus combines a prime number channel, a hashing channel and a Proof-of-Stake channel. Where Bitcoin has a difficulty adjustment interval measured in weeks, Nexus can respond to increased hashrate in the space of 1 block and each channel scales independently of the other two channels. This stabilizes the block times at ~50 seconds and ensures no single channel can monopolize block production. This means that a 51% attack is much more difficult to launch because an attacker would need to control all 3 channels.
Every 60 minutes, the Nexus protocol automatically creates a checkpoint. This prevents blocks from being created or modified dated prior to this checkpoint, thus protecting the chain from malicious attempts to introduce an alternate blockchain.
 
4. What is quantum resistance and how does Nexus implement it?
To understand what quantum resistance is and why it is important, you need to understand how quantum computing works and why it’s a threat to blockchain technology. Classical computing uses an array of transistors. These transistors form the heart of your computer (the CPU). Each transistor is capable of being either on or off, and these states are used to represent the numerical values 1 and 0.
Binary digits’ (bits) number of states depends on the number of transistors available, according to the formula 2n, where n is the number of transistors. Classical computers can only be in one of these states at any one time, so the speed of your computer is limited to how fast it can change states.
Quantum computers utilize quantum bits, “qubits,” which are represented by the quantum state of electrons or photons. These particles are placed into a state called superposition, which allows the qubit to assume a value of 1 or 0 simultaneously.
Superposition permits a quantum computer to process a higher number of data possibilities than a classical computer. Qubits can also become entangled. Entanglement makes a qubit dependant on the state of another, enabling quantum computing to calculate complex problems, extremely quickly.
One such problem is the Discrete Logarithm Problem which elliptic curve cryptography relies on for security. Quantum computers can use Shor’s algorithm to reverse a key in polynomial time (which is really really really fast). This means that public keys become vulnerable to quantum attack, since quantum computers are capable of being billions of times faster at certain calculations. One way to increase quantum resistance is to require more qubits (and more time) by using larger private keys:
Bitcoin Private Key (256 bit) 5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF
Nexus Private Key (571 bit) 6Wuiv513R18o5cRpwNSCfT7xs9tniHHN5Lb3AMs58vkVxsQdL4atHTF Vt5TNT9himnCMmnbjbCPxgxhSTDE5iAzCZ3LhJFm7L9rCFroYoqz
Bitcoin addresses are created by hashing the public key, so it is not possible to decrypt the public key from the address; however, once you send funds from that address, the public key is published on the blockchain rendering that address vulnerable to attack. This means that your money has higher chances of being stolen.
Nexus eliminates these vulnerabilities through an innovation called signature chains. Signature chains will enable access to an account using a username, password and PIN. When you create a transaction on the network, you claim ownership of your signature chain by revealing the public key of the NextHash (the hash of your public key) and producing a signature from the one time use private key. Your wallet then creates a new private/public keypair, generates a new NextHash, including the corresponding contract. This contract can be a receive address, a debit, a vote, or any other type of rule that is written in the contract code.
This keeps the public key obscured until the next transaction, and by divorcing the address from the public key, it is unnecessary to change addresses in order to change public keys. Changing your password or PIN code becomes a case of proving ownership of your signature chain and broadcasting a new transaction with a new NextHash for your new password and/or PIN. This provides the ability to login to your account via the signature chain, which becomes your personal chain within the 3D chain, enabling the network to prove and disprove trust, and improving ease of use without sacrificing security.
The next challenge with quantum computers is that Grover’s algorithm reduces the security of one-way hash function by a factor of two. Because of this, Nexus incorporates two new hash functions, Skein and Keccak, which were designed in 2008 as part of a contest to create a new SHA3 standard. Keccak narrowly defeated Skein to win the contest, so to maximize their potential Nexus combines these algorithms. Skein and Keccak utilize permutation to rotate and mix the information in the hash.
To maintain a respective 256/512 bit quantum resistance, Nexus uses up to 1024 bits in its proof-of-work, and 512 bits for transactions.
 
5. What is the Unified Time protocol?
All blockchains use time-stamping mechanisms, so it is important that all nodes operate using the same clock. Bitcoin allows for up to 2 hours’ discrepancy between nodes, which provides a window of opportunity for the blockchain to be manipulated by time-related attack vectors. Nexus eliminates this vulnerability by implementing a time synchronization protocol termed Unified Time. Unified Time also enhances transaction processing and will form an integral part of the 3D chain scaling solution.
The Unified Time protocol facilitates a peer-to-peer timing system that keeps all clocks on the network synchronized to within a second. This is seeded by selected nodes with timestamps derived from the UNIX standard; that is, the number of seconds since January 1st, 1970 00:00 UTC. Every minute, the seed nodes report their current time, and a moving average is used to calculate the base time. Any node which sends back a timestamp outside a given tolerance is rejected.
It is important to note that the Nexus network is fully synchronized even if an individual wallet displays something different from the local time.
 
6. Why does Nexus need its own satellite network?
One of the key limitations of a purely electronic monetary system is that it requires a connection to the rest of the network to verify transactions. Existing network infrastructure only services a fraction of the world’s population.
Nexus, in conjunction with Vector Space Systems, is designing communication satellites, or cubesats, to be launched into Low Earth Orbit in 2019. Primarily, the cubesat mesh network will exist to give Nexus worldwide coverage, but Nexus will also utilize its orbital and ground mesh networks to provide free and uncensored internet access to the world.
 

The Nexus Currency (NXS):

1. How can I get Nexus?
There are two ways you can obtain Nexus. You can either buy Nexus from an exchange, or you can run a miner and be rewarded for finding a block. If you wish to mine Nexus, please follow our guide found below.
Currently, Nexus is available on the following exchanges:
Nexus is actively reaching out to other exchanges to continue to be listed on cutting edge new financial technologies..
 
2. How much does a transaction cost?
Under Nexus, the fee structure for making a transaction depends on the size of your transaction. A default fee of 0.01 NXS will cover most transactions, and users have the option to pay higher fees to ensure their transactions are processed quickly.
When the 3D chain is complete and the initial 10-year distribution period finishes, Nexus will absorb these fees through inflation, enabling free transactions.
 
3. How fast does Nexus transfer?
Nexus reaches consensus approximately every ~ 50 seconds. This is an average time, and will in some circumstances be faster or slower. NXS currency which you receive is available for use after just 6 confirmations. A confirmation is proof from a node that the transaction has been included in a block. The number of confirmations in this transaction is the number that states how many blocks it has been since the transaction is included. The more confirmations a transaction has, the more secure its placement in the blockchain is.
 
4. Did Nexus hold an ICO? How is Nexus funded?
The Nexus Embassy, a 501(C)(3) not-for-profit corporation, develops and maintains the Nexus blockchain software. When Nexus began under the name Coinshield, the early blocks were mined using the Developer and Exchange (Ambassador) addresses, which provides funding for the Nexus Embassy.
The Developer Fund fuels ongoing development and is sourced by a 1.5% commission per block mined, which will slowly increase to 2.5% after 10 years. This brings all the benefits of development funding without the associated risks.
The Ambassador (renamed from Exchange) keys are funded by a 20% commission per block reward. These keys are mainly used to pay for marketing, and producing and launching the Nexus satellites.
When Nexus introduces developer and ambassador contracts, they will be approved, denied, or removed by six voting groups namely: currency, developer, ambassador, prime, hash, and trust.
Please Note: The Nexus Embassy reserves the sole right to trade, sell and or use these funds as required; however, Nexus will endeavor to minimize the impact that the use of these funds has upon the NXS market value.
 
5. Is there a cap on the number of NXS in existence?
After an initial 10-year distribution period ending on September 23rd, 2024, there will be a total of 78 million NXS. Over this period, the reward gradient for mining Nexus follows a decaying logarithmic curve instead of the reward halving inherent in Bitcoin. This avoids creating a situation where older mining equipment is suddenly unprofitable, encouraging miners to continue upgrading their equipment over time and at the same time reducing major market shocks on block halving events.
When the distribution period ends, the currency supply will inflate annually by a maximum of 3% via staking and by 1% via the prime and hashing channels. This inflation is completely unlike traditional inflation, which degrades the value of existing coins. Instead, the cost of providing security to the blockchain is paid by inflation, eliminating transaction fees.
Colin Cantrell - Nexus Inflation Explained
 
6. What is the difference between the LLD wallet and the Oracle wallet?
Due to the scales of efficiency needed by blockchain, Nexus has developed a custom-built database called the Lower Level Database. Since the development of the LLD wallet 0.2.3.1, which is a precursor to the Tritium updates, you should begin using the LLD wallet to take advantage of the faster load times and improved efficiency.
The Oracle wallet is a legacy wallet which is no longer maintained or updated. It utilized the Berkeley DB, which is not designed to meet the needs of a blockchain. Eventually, users will need to migrate to the LLD wallet. Fortunately, the wallet.dat is interchangeable between wallets, so there is no risk of losing access to your NXS.
 
7. How do I change from Oracle to the LLD wallet?
Step 1 - Backup your wallet.dat file. You can do this from within the Oracle wallet Menu, Backup Wallet.
Step 2 - Uninstall the Oracle wallet. Close the wallet and navigate to the wallet data directory. On Windows, this is the Nexus folder located at %APPDATA%\Nexus. On macOS, this is the Nexus folder located at ~/Library/Application Support/Nexus. Move all of the contents to a temporary folder as a backup.
Step 3 - Copy your backup of wallet.dat into the Nexus folder located as per Step 2.
Step 4 - Install the Nexus LLD wallet. Please follow the steps as outlined in the next section. Once your wallet is fully synced, your new wallet will have access to all your addresses.
 
8. How do I install the Nexus Wallet?
You can install your Nexus wallet by following these steps:
Step 1 - Download your wallet from www.nexusearth.com. Click the Downloads menu at the top and select the appropriate wallet for your operating system.
Step 2 - Unzip the wallet program to a folder. Before running the wallet program, please consider space limitations and load times. On the Windows OS, the wallet saves all data to the %APPDATA%\Nexus folder, including the blockchain, which is currently ~3GB.
On macOS, data is saved to the ~/Library/Application Support/Nexus folder. You can create a symbolic link, which will allow you to install this information in another location.
Using Windows, follow these steps:
On macOS, follow these steps:
Step 3 (optional) - Before running the wallet, we recommend downloading the blockchain database manually. Nexus Earth maintains a copy of the blockchain data which can save hours from the wallet synchronization process. Please go to www.nexusearth.com and click the Downloads menu.
Step 4 (optional) - Extract the database file. This is commonly found in the .zip or .rar format, so you may need a program like 7zip to extract the contents. Please extract it to the relevant directory, as outlined in step 2.
Step 5 - You can now start your wallet. After it loads, it should be able to complete synchronization in a short time. This may still take a couple of hours. Once it has completed synchronizing, a green check mark icon will appear in the lower right corner of the wallet.
Step 6 - Encrypt your wallet. This can be done within the wallet, under the Settings menu. Encrypting your wallet will lock it, requiring a password in order to send transactions.
Step 7 - Backup your wallet.dat file. This can be done from the File menu inside the wallet. This file contains the keys to the addresses in your wallet. You may wish to keep a secure copy of your password somewhere, too, in case you forget it or someone else (your spouse, for example) ever needs it.
You should back up your wallet.dat file again any time you create – or a Genesis transaction creates (see “staking” below) – a new address.
 

Types of Mining or Minting:

1.Can I mine Nexus?
Yes, there are 2 channels that you can use to mine Nexus, and 1 channel of minting:
Prime Mining Channel
This mining channel looks for a special prime cluster of a set length. This type of calculation is resistant to ASIC mining, allowing for greater decentralization. This is most often performed using the CPU.
Hashing Channel
This channel utilizes the more traditional method of hashing. This process adds a random nonce, hashes the data, and compares the resultant hash against a predetermined format set by the difficulty. This is most often performed using a GPU.
Proof of Stake (nPoS)
Staking is a form of mining NXS. With this process, you can receive NXS rewards from the network for continuously operating your node (wallet). It is recommended that you only stake with a minimum balance of 1000 NXS. It’s not impossible to stake with less, but it becomes harder to maintain trust. Losing trust resets the interest rate back to 0.5% per annum.
 
2. How do I mine Nexus?
As outlined above, there are two types of mining and 1 proof of stake. Each type of mining uses a different component of your computer to find blocks, the CPU or the GPU. Nexus supports CPU and GPU mining on Windows only. There are also third-party macOS builds available.
Please follow the instructions below for the relevant type of miner.
 
Prime Mining:
Almost every CPU is capable of mining blocks on this channel. The most effective method of mining is to join a mining pool and receive a share of the rewards based on the contribution you make. To create your own mining facility, you need the CPU mining software, and a NXS address. This address cannot be on an exchange. You create an address when you install your Nexus wallet. You can find the related steps under How Do I Install the Nexus Wallet?
Please download the relevant miner from http://nexusearth.com/mining.html. Please note that there are two different miner builds available: the prime solo miner and the prime pool miner. This guide will walk you through installing the pool miner only.
Step 1 - Extract the archive file to a folder.
Step 2 - Open the miner.conf file. You can use the default host and port, but these may be changed to a pool of your choice. You will need to change the value of nxs_address to the address found in your wallet. Sieve_threads is the number of CPU threads you want to use to find primes. Ptest_threads is the number of CPU threads you want to test the primes found by the sieve. As a general rule, the number of threads used for the sieve should be 75% of the threads used for testing.
It is also recommended to add the following line to the options found in the .conf file:
"experimental" : "true"
This option enables the miner to use an improved sieve algorithm which will enable your miner to find primes at a faster rate.
Step 3 - Run the nexus_cpuminer.exe file. For a description of the information shown in this application, please read this guide.
 
Hashing:
The GPU is a dedicated processing unit housed on-board your graphics card. The GPU is able to perform certain tasks extremely well, unlike your CPU, which is designed for parallel processing. Nexus supports both AMD and Nvidia GPU mining, and works best on the newer models. Officially, Nexus does not support GPU pool mining, but there are 3rd party miners with this capability.
The latest software for the Nvidia miner can be found here. The latest software for the AMD miner can be found here. The AMD miner is a third party miner. Information and advice about using the AMD miner can be found on our Slack channel. This guide will walk you through the Nvidia miner.
Step 1 - Close your wallet. Navigate to %appdata%\Nexus (~/Library/Application Support/Nexus on macOS) and open the nexus.conf file. Depending on your wallet, you may or may not have this file. If not, please create a new txt file and save it as nexus.conf
You will need to add the following lines before restarting your wallet:
Step 2 - Extract the files into a new folder.
Step 3 - Run the nexus.bat file. This will run the miner and deposit any rewards for mining a block into the account on your wallet.
For more information on either Prime Mining or Hashing, please join our Slack and visit the #mining channel. Additional information can be found here.
 
3. How do I stake Nexus?
Once you have your wallet installed, fully synchronized and encrypted, you can begin staking by:
After you begin staking, you will receive a Genesis transaction as your first staking reward. This establishes a Trust key in your wallet and stakes your wallet balance on that key. From that point, you will periodically receive additional Trust transactions as further staking rewards for as long as your Trust key remains active.
IMPORTANT - After you receive a Genesis transaction, backup your wallet.dat file immediately. You can select the Backup Wallet option from the File menu, or manually copy the file directly. If you do not do this, then your Nexus balance will be staked on the Trust key that you do not have backed up, and you risk loss if you were to suffer a hard drive failure or other similar problem. In the future, signature chains will make this precaution unnecessary.
 
4. I am staking with my Nexus balance. What are interest rate, trust weight, block weight, and stake weight?
These items affect the size and frequency of staking rewards after you receive your initial Genesis transaction. When staking is active, the wallet displays a clock icon in the bottom right corner. If you hover your mouse pointer over the icon, a tooltip-style display will open up, showing their current values.
Please remember to backup your wallet.dat file (see question 3 above) after you receive a Genesis transaction.
Interest Rate - The minting rate at which you will receive staking rewards, displayed as an annual percentage of your NXS balance. It starts at 0.5%, increasing to 3% after 12 months. The rate increase is not linear but slows over time. It takes several weeks to reach 1% and around 3 months to reach 2%.
With this rate, you can calculate the average amount of NXS you can expect to receive each day for staking.
Trust Weight - An indication of how much the network trusts your node. It starts at 5% and increases much more quickly than the minting (interest) rate, reaching 100% after one month. Your level of trust increases your stake weight (below), thus increasing your chances of receiving staking transactions. It becomes easier to maintain trust as this value increases.
Block Weight - Upon receipt of a Genesis transaction, this value will begin increasing slowly, reaching 100% after 24 hours. Every time you receive a staking transaction, the block weight resets. If your block weight reaches 100%, then your Trust key expires and everything resets (0.5% interest rate, 5% trust weight, waiting for a new Genesis transaction).
This 24-hour requirement will be replaced by a gradual decay in the Tritium release. As long as you receive a transaction before it decays completely, you will hold onto your key. This change addresses the potential of losing your trust key after months of staking simply because of one unlucky day receiving trust transactions.
Stake Weight - The higher your stake weight, the greater your chance of receiving a transaction. The exact value is a derived by a formula using your trust weight and block weight, which roughly equals the average of the two. Thus, each time you receive a transaction, your stake weight will reset to approximately half of your current level of trust.
submitted by scottsimon36 to nexusearth [link] [comments]

So are folks ready to deep six SHA256(SHA256(HEADER)) PoW yet?

Miner concentration that occurs when PoW is so easily unrolled onto ASIC -- which is to say when the PoW is not memory, storage, and memory<->storage bandwidth demanding, will always lead in the end to mining concentration with the most marked advantage landing in the hands of manufacturing concerns.
It is true of course that any process that can be done in commodity hardware can be done better, faster, in specialized ASIC. But with Bitcoin we have a single easily unrolled hash function buzzing a small piece of header data with only a very tiny nonce getting incremented between operations. Tiny, tiny, tiny amounts of memory per hash instance, nil requirements in terms of storage, and zero need for high bandwidth memory <-> storage.
More and more parallel hashing instances per chip, smaller processes, and economies of scale lead to centralization especially in the hands of the manufacturers.
That centralization leads to power, and as the entirety of human history proves, power has a corrupting influence.
We see this today in the reporting today regarding remote kill functionality in Bitmain miners.
We see it more generally in folks like Bitfury who do not offer consumer level mining equipment, and would rather sell monster shipping container sized rigs to monster sized customers. (If you have to ask how much it costs you can't afford it).
Now, forgive me, but I cannot resist dropping an "I told you so" to all of the brazen UASF BIP148 supporters. I've been urging caution and getting a lot of crap for it. But imagine how a UASF chain fork would have gone if the UASF chain were not only a shorter chain at the outset, but the Antminer hashpower on that chain got remotely bricked in the middle of the process to see which fork would survive.
At any rate, I'd say its time to put a plan in place to at least be READY to roll out a new PoW for Bitcoin within an 18 to 36 month time horizon.
Its very extreme to think about, but ask yourself: Could you have ever imagined anything like the matters that are prevalent in mining these days? Pools refusing to implement broadly supported and very well tested protocol upgrades. Covert, patented, optimizations. Remote kill code in a crushingly large segment of deployed mining hardware.
Hell, the mere fact that it is possible to get 5 human beings in a single room and, among them, have an overwhelming majority of hashpower spoken for is worrisome enough.
I've seen luke-jr post about the potential need for such a change before. I would love to hear if nullc or any of the other core devs have considered the circumstances where a PoW change would need to be considered. Perhaps if there were a crypto break of SHA256 for example.
Just my thoughts at present.
submitted by Shmullus_Zimmerman to Bitcoin [link] [comments]

Jaxx by Kryptokit adds HD support to Ethereum ecosystem. Available now in Jaxx final beta release.

Anthony from Kryptokit here. With our code audit nearly complete, we’re pleased to announce what we expect to be our final beta release of Jaxx, 0.0.17. This release marks a milestone for the overall Ethereum ecosystem: it’s the first-ever Ethereum wallet to provide HD (Hierarchical Deterministic) support.
This is a major upgrade for Ethereum users, and it should also serve the purpose of ensuring that no more Jaxx users encounter the WebView determinism issue that arose on certain Android devices. Although there will be no need to create a new Jaxx wallet (or additional backup) users with an existing Ethereum balance will be prompted to allow Jaxx to transfer their balance to a new, HD address. User's’ previous, static keypair will still be visible and exportable via the Display Private Keys option in the menu.
More on Jaxx 0.0.17 and the 1.0 release:
Besides the Ethereum HD upgrade, 0.0.17 has a couple of new of new fixes and features, including an improved UI with responsive text and QR code sizing and a fix for the “nonce too low” error that was occurring with certain Ethereum paper wallets, as well as some key tweaks to the mnemonic entry function.
Lastly, as requested by many users, Jaxx can now display checksummed addresses that can be validated by other programs. Our dev team is still working on the ability in Jaxx to check addresses from other programs.
Our 1.0 release is currently planned to follow this one, and it will have ShapeShift integration for in-app ethebitcoin conversion, as well as a few other goodies.
As always, thanks to the Ethereum community for all the feedback, suggestions, and support.
Changelog:
Jaxx 0.0.17:
Download all versions of Jaxx at our website.
Reminder: Jaxx is beta software and we're sailing in uncharted waters. Please stick to amounts you’d be willing to lose while testing out our beta wallet.
Edit: 04/10/16
A little over 48 hours in and the update has gone very smoothly, but a couple of minor things have come up that I'd like to address:
Some users have reported that after they allow Jaxx to make the transfer to the HD address, their funds are not visible in their balance. If this is the case, please try the following:
  1. Make sure you have a written, exact copy of your master mnemonic (Tools > Back Up Wallet > Display Master Mnemonic).
  2. Uninstall, then reinstall Jaxx 0.0.17.
  3. Restore your wallet by entering your master mnemonic with the Restore Wallet option.
Secondly, if you chose not to have us make the transfer, your funds are still available, and stored at your previous, non-HD address. To see it, go to: Tools > Back Up Wallet > Display Private Keys > Display Ethereum Keys. The non-HD address and private key will be displayed in the second text field.
If you get a message in that text field asking you to wait for a minute and a half, hit the Jaxx back button and head back to the main Jaxx screen. Ensure that Jaxx is set to the Ethereum wallet, and wait a couple of minutes, then return to the Display Ethereum Keys screen. (Do not exit Jaxx during this process, or the load will reset!)
If you're having any trouble with the transfer or have any questions, do not hesitate to email us at [email protected].
submitted by adiiorio to ethereum [link] [comments]

TIL A hard-fork can be avoided when upgrading the protocol by asking miners to vote for the upgrade by marking their coin generation transactions in new blocks

Pretty clever.
In Gavin's BIP for P2SH transactions, he asks miners who agree to validate the the new Tx type to announce their vote by marking their coinbase transactions:
https://github.com/bitcoin/bips/blob/mastebip-0016.mediawiki#backwards-compatibility
Here's an example of that actually happening in the blockchain:
https://blockchain.info/tx/22fa0f3d4365ab3b2d9f8d75f73ac85637d25bf8eb019e6629eb1c4655451833
Make sure coinbases are showing ("enable advanced") and you can see that Slush pool marked their coinbase nonce with "/P2SH/" to indicate that they were prepared to validate P2SH transactions.
When it was confirmed that more than 55% of the network's mining power was ready to upgrade the protocol and allow P2SH, it was so...
CONSENSUS!
submitted by pinhead26 to Bitcoin [link] [comments]

An approach to mining centralization induced by mining pools

This approach attempts to address the mining-pool-induced centralization issue by introducing mining pool features into Bitcoin protocol, therefore eliminating the need for mining pools.
To be more specific, miners work poollessly, broadcast shares to Bitcoin network, and get paid based on their shares directly by the Bitcoin protocol.
 
Challenges:
The instant problem/challenge with such an approach is obvious: there is no way that miners can work on the same block. This can be broken down into:
  1. There is no way miners can work on the same block because the regular transactions included and the order won't be the same.
  2. There is no way miners can work on the same block because the coinbase transaction won't be the same.
The first issue is to be addressed with a P2P communication process.
In order to address the second issue, two key ideas/theories are introduced:
  1. Proof-of-work on (only) the critical part of a given dataset provides a close level of security to the whole dataset, compared to when it is done on the whole dataset.
  2. Proof-of-work can be accumulated.
An example of the first theory is as follows: Assume the version field is less important. PoW on the block without it, e.g., with it always set to zero, results in a close level of security compared to PoW on the original block. The first theory enables the idea that you don't have to mine the exactly same block to mine the "same" block. The part that's deemed less important in this approach is the coinbase transaction.
An example of the second theory is as follows: Assume we want a PoW of 5 out of 100. The regular way to achieve it is to hash until a result of 5 or less occurs. There is another way. PoW of 5 out of 100 in average requires 20 attempts of hashing. As long as we can tell 20 or more attempts have been made, we have the required PoW. We know that 10 out of 100 requires 10 attempts in average. With 2x 10s, there are 20 attempts, meaning that the PoW requirement of 5 out of 100 is met. It's the same is for 4x 20s. The second theory basically means shares can be combined to meet the PoW requirement.
 
Solution (brief):
Based on the two theories and the assumption that the coinbase transaction is less important, the outline of the solution, which I call Aggregated Mining, is formed:
 
Solution (details):
Here are the detailed explanations:
The resulting block is of the same format as current ones except for the coinbase transaction, which contains not only the (finalizing) miner's data, but also the data of all shares.
For verification, when a block is received, besides the regular validation check of the full block, of which the block income used is the total income rather than the dividend of the minter, the block is verified the-number-of-the-shares times for each share, by rebuilding the share's original block, which is done by replacing all related fields in the current block with the miner-specific data of the share. (All shares share the same block data, excluding the miner-specific parts, as the minter's block.) The distribution of dividends is also verified. The block is valid only when all verifications succeed.
Data structure:
A share's P2P data:
prev_block:1a2b3c4d, // first 64 bits of hash of previous block { // barebone block id n_tx:2345, // number of transactions tx:[ { tx_id:1f3e5d7c // transaction id; 64-bit integer (first 64 bits of hash) }, { tx_id:2f4e6d8c // transaction id; 64-bit integer (first 64 bits of hash) }, ... ], } { // miner-specific data coinbase:"Miner001:...", // starting with miner ID, to avoid miners mining in the same space value:14.12345, // the block income scriptPubKey:..., // the harvester's address timestamp:1489634411, // the share's timestamp nonce:23456789, // the share's nonce } 
A share's (harvester's) coinbase data:
in:[ { prev_out:{ hash:00000...00000, n:-1 }, coinbase:"Miner001:..." // starting with miner ID, to avoid miners mining in the same space } ] out:[ { value:14.12345 scriptPubKey:... // the harvester's address } ] 
A share's (harvester's) coinbase data (space-saving version):
in:[ { coinbase:"Miner001:..." // starting with miner ID, to avoid miners mining in the same space } ] out:[ { scriptPubKey:... // the harvester's address } ] 
Minter's coinbase data:
in:[ { prev_out:{ hash:00000...00000, n:-1 }, coinbase:"......" } ] out:[ { total:14.12345 // total block income; applies to all shares, too value:2.34567 // the minter's dividend scriptPubKey:... // the minter's address } ] share_size:5678, shares:[ { { // share's coinbase data }, value:0.12345 // the share's dividend timestamp:1489634400 // the share's timestamp nonce:12345678 // the share's nonce }, { { // share's coinbase data }, value:0.98765 // the share's dividend timestamp:1489634411 // the share's timestamp nonce:23456789 // the share's nonce }, ... ] 
 
Securities:
The security of all share data and the security of the minter's own coinbase data, as well as the security of the whole block, are to be consolidated by the following blocks, just like the blocks in the current scheme.
 
Pros and cons:
Pros:
Cons:
If the verification process takes too much time, an optimization can be introduced by changing how the Merkle root is calculated. There will be a Merkle root for all the regular transactions. The final Merkel root will be calculated from the coinbase transaction and the Merkle root of regular transactions.
In order to lower the odds of the forks and stale blocks, the minimum PoW requirement for minting can be raised.
 
Discussions (basic):
Timeline (based on the minimum minting PoW requirement being 10%):
(Transactions, miner-signed transaction IDs, and shares are relayed in the network all the time.)
Analysis:
A share's P2P data:
early_share:1 // early share flag prev_block:1a2b3c4d, // first 64 bits of hash of previous block { // barebone block id n_tx:2345, // number of transactions tx:[ { tx_id:1f3e5d7c // transaction id; 64-bit integer (first 64 bits of hash) }, { tx_id:2f4e6d8c // transaction id; 64-bit integer (first 64 bits of hash) }, ... ], } { // miner-specific data coinbase:"Miner001:...", // starting with miner ID, to avoid miners mining in the same space value:14.12345, // the block income scriptPubKey:..., // the harvester's address timestamp:1489634411, // the share's timestamp nonce:23456789, // the share's nonce } 
Minter's coinbase data (with early shares added):
in:[ { prev_out:{ hash:00000...00000, n:-1 }, coinbase:"......" } ] out:[ { total:14.12345 // total block income; applies to all shares, too value:2.34567 // the minter's dividend scriptPubKey:... // the minter's address } ] early_share_size:654, early_shares:[ { { // share's coinbase data }, value:0.11111 // the share's dividend timestamp:1489634300 // the share's timestamp nonce:345678 // the share's nonce }, { { // share's coinbase data }, value:0.22222 // the share's dividend timestamp:1489634311 // the share's timestamp nonce:876543 // the share's nonce }, ... ] share_size:5678, shares:[ { { // share's coinbase data }, value:0.12345 // the share's dividend timestamp:1489634400 // the share's timestamp nonce:12345678 // the share's nonce }, { { // share's coinbase data }, value:0.98765 // the share's dividend timestamp:1489634411 // the share's timestamp nonce:23456789 // the share's nonce }, ... ] 
 
Discussions (advanced):
Timeline (adjusted for independent regular miners):
Further analysis:
 
Any genuine (non-trolling) comment is welcomed.
Any correction, improvement or education will be appreciated.
EDIT: The post will keep being updated for corrections, improvements, rewording and formatting, until this line is removed.
submitted by exab to Bitcoin [link] [comments]

Tree-chains Preliminary Summary - Peter Todd

Reposted from the Bitcoin development list on mailarchive.com. The author is Peter Todd.
https://www.mail-archive.com/[email protected]/msg04388.html

Tree-chains Preliminary Summary

Introduction

Bitcoin doesn't scale. There's a lot of issues at hand here, but the most fundemental of them is that to create a block you need to update the state of the UTXO set, and the way Bitcoin is designed means that updating that state requires bandwidth equal to all the transaction volume to keep up with the changes to what set. Long story short, we get O(n2) scaling, which is just plain infeasible.
So let's split up the transaction volume so every individual miner only needs to keep up with some portion. In a rough sense that's what alt-coins do - all the tipping microtransactions on Doge never have to hit the Bitcoin blockchain for instance, reducing pressure on the latter. But moving value between chains is inconvenient; right now moving value requires trusted third parties. Two-way atomic chain transfers does help here, but as recent discussions on the topic showed there's all sorts of edge cases with reorganizations that are tricky to handle; at worst they could lead to inflation.
So what's the underlying issue there? The chains are too independent. Even with merge-mining there's no real link between one chain and another with regard to the order of transactions. Secondly merge-mining suffers from 51% attacks if the chain being merge-mined doesn't have a majority of total hashing power... which kinda defeats the point if we're worried about miner scalability.

Blocks and the TXO set as a binary radix tree

So how can we do better? Start with the "big picture" idea and take the linear blockchain and turn it into a tree:
 ┌───────┴───────┐ ┌───┴───┐ ┌───┴───┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ ┌┴┐ ┌┴┐ ┌┴┐ ┌┴┐ ┌┴┐ ┌┴┐ ┌┴┐ ┌┴┐ 
Obviously if we could somehow split up the UTXO set such that individual miners/full nodes only had to deal with subsets of this tree we could significantly reduce the bandwidth that any one miner would need to process. Every transaction output would get a unique identifier, say txoutid=H(txout) and we put those outputs in blocks appropriately.
We can't just wave a magic wand and say that every block has the above structure and all miners co-ordinate to generate all blocks in one go. Instead we'll do something akin to merge mining. Start with a linear blockchain with ten blocks. Arrows indicate hashing:
a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽ a4 ⇽ a5 ⇽ a6 ⇽ a7 ⇽ a8 ⇽ a9 
The following data structure could be the block header in this scheme. We'll simplify things a bit and make up our own; obviously with some more effort the standard Satoshi structures can be used too:
struct BlockHeader: uint256 prevBlockHash uint256 blockContentsHash uint256 target uint256 nonce uint time 
For now we'll say this is a pure-proof-of-publication chain, so our block contents are very simple:
struct BlockContents: uint256 merkleRoot 
As usual the PoW is valid if H(blockHeader) < blockHeader.target. Every block creates new txouts, and the union of all such txouts is the txout set. As shown previously(1) this basic proof-of-publication functionality is sufficient to build a crypto-currency even without actually validating the contents of the so-called transaction outputs.
The scalability of this sucks, so let's add two more chains below the root to start forming a tree. For fairness we'll only allow miners to either mine a, a+b, or a+c; attempting to mine a block with both the b and c chains simultaneously is not allowed.
struct BlockContents: uint256 childBlockHash # may be null bool childSide # left or right uint256 merkleRoot 
Furthermore we shard the TXO space by defining txoid = H(txout) and allowing any txout in chain a, and only txouts with LSB=0 in b, LSB=1 in c; the beginning of a binary radix tree. With some variance thrown in we get the following:
 b0 ⇽⇽ b1 ⇽⇽⇽⇽⇽ b2 ⇽ b3 ⇽ b4 ⇽ b5 ⇽ b6 ⇽ b7 ⇽ b8 ↙ ↙ a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽⇽⇽⇽⇽⇽ a4 ⇽ a5 ⇽ a6 ⇽ a7 ⇽ a8 ↖ ↖ ↖ ↖ ↖ c0 ⇽ c1 ⇽ c2 ⇽ c3 ⇽⇽⇽⇽⇽⇽ c4 ⇽ c5 ⇽ c6 ⇽⇽⇽⇽⇽⇽ c7 
We now have three different versions of the TXO set: ∑a, ∑a + ∑b, and ∑a+∑c. Each of these versions is consistent in that for a given txoutid prefix we can achieve consensus over the contents of the TXO set. Of course, this definition is recursive:
a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽⇽⇽⇽⇽⇽ a4 ⇽ a5 ⇽ a6 ⇽ a7 ⇽ a8 ↖ ↖ ↖ ↖ ↖ c0 ⇽ c1 ⇽ c2 ⇽ c3 ⇽⇽⇽⇽⇽⇽ c4 ⇽ c5 ⇽ c6 ⇽⇽⇽⇽⇽⇽ c7 ↖ ↖ ↖ ↖ ↖ d0 ⇽ d1 ⇽⇽⇽⇽⇽⇽ d2 ⇽⇽⇽⇽⇽⇽ d3 ⇽ d4 ⇽⇽⇽ d5 ⇽⇽⇽⇽ d6 
Unicode unfortunately lacks 3D box drawing at present, so I've only shown left-sided child chains.

Herding the child-chains

If all we were doing was publishing data, this would suffice. But what if we want to syncronize our actions? For instance, we may want a new txout to only be published in one chain if the corresponding txout in another is marked spent. What we want is a reasonable rule for child-chains to be invalidated when their parents are invalidated so as to co-ordinate actions across distant child chains by relying on the existance of their parents.
We start by removing the per-chain difficulties, leaving only a single master proof-of-work target. Solutions less than target itself are considered valid in the root chain, less than the target << 1 in the root's children, << 2 in the children's children etc. In children that means the header no longer contains a time, nonce, or target; the values in the root block header are used instead:
struct ChildBlockHeader: uint256 prevChildBlockHash uint256 blockContentsHash 
For a given chain we always choose the one with the most total work. But to get our ordering primitive we'll add a second, somewhat brutal, rule: Parent always wins.
We achieve this moving the child block header into the parent block itself:
struct BlockContents: ChildBlockHeader childHeader # may be null (zeroed out) bool childSide # left or right bytes txout 
Let's look at how this works. We start with a parent and a child chain:
a0 ⇽ a1 ⇽ a2 ⇽ a3 ↖ ↖ b0 ⇽ b1 ⇽ b2 ⇽ b3 ⇽ b4 ⇽ b5 
First there is the obvious scenario where the parent chain is reorganized. Here our node learns of a2 ⇽ a3' ⇽ a4':
 ⇽ a3' ⇽ a4' a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽ X ↖ ↖ b0 ⇽ b1 ⇽ b2 ⇽ b3 ⇽ X 
Block a3 is killed, resulting in the orphaning of b3, b4, and b5:
a0 ⇽ a1 ⇽ a2 ⇽ a3' ⇽ a4' ↖ b0 ⇽ b1 ⇽ b2 
The second case is when a parent has a conflicting idea about what the child chian is. Here our node receives block a5, which has a conflicting idea of what child b2 is:
a0 ⇽ a1 ⇽ a2 ⇽ a3' ⇽ a4' ⇽ a5 ↖ ↖ b0 ⇽ b1 ⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽ b2' ⇽ b2 ⇽ X 
As the parent always wins, even multiple blocks can get killed off this way:
a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽ a4 ↖ b0 ⇽ b1 ⇽ b2 ⇽ b3 ⇽ b4 ⇽ b5 ⇽ b6 ⇽ b7 
to:
a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽ a4 ⇽ a5 ↖ ↖ b0 ⇽ b1 ⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽ b2' ⇽ b2 ⇽ b3 ⇽ b4 ⇽ b5 ⇽ X 
This behavior is easier to understand if you say instead that the node learned about block b2', which had more total work than b2 as the sum total of work done in the parent chain in blocks specifying the that particular child chain is considered before comparing the total work done in only the child chain.
It's important to remember that the parent blockchain has and validates both childrens' block headers; it is not possible to mine a block with an invalid secret of child headers. For instance with the following:
a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽ a4 ↖ ↖ ↖ b0 ⇽ b1 ⇽ b2 ⇽ b3 ⇽ b4 ⇽ b5 ⇽ b6 ⇽ b7 
I can't mine block a5 that says following b2 is b2' in an attempt to kill off b2 through b7.

Token transfer with tree-chains

How can we make use of this? Lets start with a simple discrete token transfer system. Transactions are simply:
struct Transaction: uint256 prevTxHash script prevPubKey script scriptSig uint256 scriptPubKeyHash 
We'll say transactions go in the tree-chain according to their prevTxHash, with the depth in the tree equal to the depth of the previous output. This means that you can prove an output was created by the existance of that transaction in the block with prefix matching H(tx.prevTxHash), and you can prove the transaction output is unspent by the non-existance of a transaction in the block with prefix matching H(tx).
With our above re-organization rule everything is consistent too: if block bi contains tx1, then the corresponding block c_j can contain a valid tx2 spending tx1 provided that c_j depends on a_p and there is a path from a_p to b(i+k). Here's an example, starting with tx1 in c2:
 b0 ⇽⇽⇽⇽⇽⇽ b1 ↙ a0 ⇽ a1 ⇽ a2 ↖ c0 ⇽ c1 ⇽ c2 
Block b2 below can't yet contain tx2 because there is no path:
 b0 ⇽⇽⇽⇽⇽⇽ b1 ⇽ b2 ↙ a0 ⇽ a1 ⇽ a2 ↖ c0 ⇽ c1 ⇽ c2 
However now c3 is found, whose PoW solution was also valid for a3:
 b0 ⇽⇽⇽⇽⇽⇽ b1 ⇽ b2 ↙ a0 ⇽ a1 ⇽ a2 ⇽ a3 ↖ ↖ c0 ⇽ c1 ⇽ c2 ⇽ c3 
Now b3 can contain tx2, as b3 will also attempt to create a4, which depends on a3:
 b0 ⇽⇽⇽⇽⇽⇽ b1 ⇽ b2 ⇽ b3 ↙ a0 ⇽ a1 ⇽ a2 ⇽ a3 ↖ ↖ c0 ⇽ c1 ⇽ c2 ⇽ c3 
Now that a3 exists, block c2 can only be killed if a3 is, which would also kill b3 and thus destroy tx2.

Proving transaction output validity in a token transfer system

How cheap is it to prove the entire history of a token is valid from genesis? Perhaps surprisingly, without any cryptographic moon-math the cost is only linear!
Remember that a transaction in a given chain has committed to the chain that it can be spent in. If Alice is to prove to Bob that the output she gave him is valid, she simply needs to prove that for every transaction in the histroy of the token the token was created, remained unspent, then finally was spent. Proving a token remained unspent between blocks b_n and b_m is trivially possible in linear size. Once the token is spent nothing about blocks beyond b_m is required. Even if miners do not validate transactions at all the proof size remains linear provided blocks themselves have a maximum size - at worst the proof contains some invalid transactions that can be shown to be false spends.
While certainly inconvenient, it is interesting how such a simple system appears to in theory scale to unlimited numbers of transactions and with an appropriate exchange rate move unlimited amounts of value. A possible model would be for the the tokens themselves to have power of two values, and be split and combined as required.

The lost data problem

There is however a catch: What happens when blocks get lost? Parent blocks only contain their childrens' headers, not the block contents. At some point the difficulty of producing a block will drop sufficiently for malicious or accidental data loss to be possible. With the "parent chain wins" rule it must be possible to recover from that event for mining on the child to continue.
Concretely, suppose you have tx1 in block c2, which can be spent on chain b. The contents of chain a is known to you, but the full contents of chain b are unavailable:
 b0 ⇽ b1 (b) (b) ↙ ↙ ↙ a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽ a4 ⇽ a5 ↖ ↖ c0 ⇽ c1 ⇽ c2 ⇽ c3 ⇽ c4 ⇽ c5 
Blocks a3 and a4 are known to have children on b, but the contents of those children are unavailable. We can define some ratio of unknown to known blocks that must be proven for the proof to be valid. Here we show a 1:1 ratio:
 ⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽⇽ b0 ⇽ b1 (b) (b) b2 ⇽ b3 ⇽ b4 ⇽ b5 ⇽ b6 ⇽ b7 ↙ ↙ ↙ ↙ ↙ ↙ a0 ⇽ a1 ⇽ a2 ⇽ a3 ⇽ a4 ⇽ a5 ⇽ a6 ⇽ a7 ⇽ a8 ⇽ a9 ↖ ↖ ↖ c0 ⇽ c1 ⇽ c2 ⇽ c3 ⇽ c4 ⇽ c5 ⇽ c6 ⇽ c7 ⇽ c8 ⇽ c9 
The proof of now shows that while a3 and a4 has b-side blocks, by the time you reach b6 those two lost blocks were in the minority. Of course a real system needs to be careful that mining blocks and then discarding them isn't a profitably way to create coins out of thin air - ratios well in excess of 1:1 are likely to be required.

Challenge-response resolution

Another idea is to say if the parent blockchain's contents are known we can insert a challenge into it specifying that a particular child block be published verbatim in the parent. Once the challenge is published further parent blocks may not reference that children on that side until either the desired block is re-republished or some timeout is reached. If the timeout is reached, mining backtracks to some previously known child specified in the challenge. In the typical case the block is known to a majority of miners, and is published, essentially allowing new miners to force the existing ones to "cough up" blocks they aren't publishing and allow the new ones to continue mining. (obviously some care needs to be taken with regard to incentives here)
While an attractive idea, this is our first foray into moon math. Suppose such a challenge was issued in block a2, asking for the contents of b1 to be published. Meanwhile tx1 is created in block c3, and can only be spent on a b-side chain:
 b0 ⇽ b1 ↙ a0 ⇽ a1 ⇽ (a2) ⇽ a3 ↖ c0 ⇽ c1 ⇽ c2 ⇽ c3 
The miners of the b-chain can violate the protocol by mining a4/b1', where b1' appears to contain valid transaction tx2:
 b0 ⇽ b1 b1' ↙ ↙ a0 ⇽ a1 ⇽ (a2) ⇽ a3 ⇽ a4 ↖ c0 ⇽ c1 ⇽ c2 ⇽ c3 
A proof of tx2 as valid payment would entirely miss fact that the challenge was published and thus not know that b1' was invalid. While I'm sure the reader can come up with all kinds of complex and fragile way of proving fraud to cause chain a to be somehow re-organized, what we really want is some sub-linear proof of honest computation. Without getting into details, this is probably possible via some flavor of sub-linear moon-math proof-of-execution. But this paper is too long already to start getting snarky.

Beyond token transfer systems

We can extend our simple one txin, one txout token transfer transactions with merkle (sum) trees. Here's a rough sketch of the concept:
input #1─┐ ┌─output #1 ├┐ ┌┤ input #2─┘│ │└─output #2 ├─┤ input #3─┐│ │┌─output #3 ├┘ └┤ input #4─┘ └─output #4 
Where previously a transaction committed to a specific transaction output, we can make our transactions commit to a merkle-sum-tree of transaction outputs. To then redeem a transaction output you prove that enough prior outputs were spend to add up to the new output's value. The entire process can happen incrementally without any specific co-operation between miners on different parts of the chain, and inputs and outputs can come from any depth in the tree provided that care is taken to ensure that reorganization is not profitable.
Like the token transfer system proving a given output is valid has cost linear with history. However we can improve on that using non-interactive proof techniques. For instance in the linear token transfer example the history only needs to be proven to a point where the transaction fees are higher than the value of the output. (easiest where the work required to spend a txout of a given value is well defined) A similar approach can be easily taken with the directed-acyclic-graph of mutliple-input-output transactions. Secondly non-interactive proof techniques can also be used, again out of the scope of this already long preliminary paper.
1) "Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation",
http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03307.html
submitted by isysd to Blocktrees [link] [comments]

Proposal: Extended serialization format for BIP-32 | shiva sitamraju | Sep 09 2017

shiva sitamraju on Sep 09 2017:
Hi,
I understand the motivation of adding the birthdate field. However, not
very comfortable with having this in the public key serialization. There
are privacy implication of both the birthday field and having the complete
derivation path, which takes space.
I am fine with Thomas proposal of {x,y,z}. Having additional version byte
field looks modular but since since we already have the big enough version
field in bip32, better to use that instead of adding more bytes.
Thomas, can you please explain why we require different version for P2WPKH
or P2WSH versus (P2WPKH or P2WSH) nested in P2SH. It looked to me that they
would have the same output bitcoin address and under same account.
On Fri, Sep 8, 2017 at 2:09 AM, <
bitcoin-dev-request at lists.linuxfoundation.org> wrote:
Send bitcoin-dev mailing list submissions to
bitcoin-dev at lists.linuxfoundation.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
bitcoin-dev-request at lists.linuxfoundation.org
You can reach the person managing the list at
bitcoin-dev-owner at lists.linuxfoundation.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."
Today's Topics:
  1. Re: Proposal: Extended serialization format for BIP-32
    wallets (Andreas Schildbach)
  2. Re: Proposal: Extended serialization format for BIP-32
    wallets (Pavol Rusnak)
  3. Re: Fast Merkle Trees (Mark Friedenbach)
  4. Re: Proposal: Extended serialization format for BIP-32
    wallets (Thomas Voegtlin)
Message: 1
Date: Thu, 7 Sep 2017 21:35:49 +0200
From: Andreas Schildbach
To: bitcoin-dev at lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
 BIP-32 wallets 
Message-ID:
Content-Type: text/plain; charset=utf-8
On 09/07/2017 06:23 PM, Pavol Rusnak via bitcoin-dev wrote:
On 07/09/17 06:29, Thomas Voegtlin via bitcoin-dev wrote:
A solution is still needed to wallets who do not wish to use BIP43
What if we added another byte field OutputType for wallets that do not
follow BIP43?
0x00 - P2PKH output type
0x01 - P2WPKH-in-P2SH output type
0x02 - native Segwit output type
Would that work for you?
I think that would work.
The question is whether this field should be present only if depth==0x00
or at all times. What is your suggestion, Thomas?
In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
we need this field. I think it should always be present if a chain is
limited to a certain script type.
There is however the case where even on one chain, script types are
mixed. In this case the field should be omitted and the wallet needs to
scan for all (known) types. Afaik Bitcoin Core is taking this path.
Message: 2
Date: Thu, 7 Sep 2017 22:00:05 +0200
From: Pavol Rusnak
To: Andreas Schildbach , Bitcoin Protocol
 Discussion  
Subject: Re: [bitcoin-dev] Proposal: Extended serialization format for
 BIP-32 wallets 
Message-ID: <40ed03a1-915c-33b0-c4ac-e898c8c733ba at satoshilabs.com>
Content-Type: text/plain; charset=windows-1252
On 07/09/17 21:35, Andreas Schildbach via bitcoin-dev wrote:
In case of Bitcoin Wallet, the depth is not null (m/0'/[0,1]) and still
we need this field.
But the depth of exported public key will be null. It does not make
sense to export xpub for m or m/0' for your particular case.
I think it should always be present if a chain is
limited to a certain script type.
I am fine with having the path there all the time.
There is however the case where even on one chain, script types are
mixed. In this case the field should be omitted and the wallet needs to
scan for all (known) types. Afaik Bitcoin Core is taking this path.
Is that really the case? Why come up with a hierarchy and then don't use
it?

Best Regards / S pozdravom,
Pavol "stick" Rusnak
CTO, SatoshiLabs
Message: 3
Date: Thu, 7 Sep 2017 13:04:30 -0700
From: Mark Friedenbach
To: Russell O'Connor
Cc: Bitcoin Protocol Discussion
  
Subject: Re: [bitcoin-dev] Fast Merkle Trees
Message-ID: <40D6F502-3380-4B64-BCD9-80D361EED35C at friedenbach.org>
Content-Type: text/plain; charset="us-ascii"
TL;DR I'll be updating the fast Merkle-tree spec to use a different
 IV, using (for infrastructure compatability reasons) the scheme provided by Peter Todd. 
This is a specific instance of a general problem where you cannot
trust scripts given to you by another party. Notice that we run into
the same sort of problem when doing key aggregation, in which you must
require the other party to prove knowledge of the discrete log before
using their public key, or else key cancellation can occur.
With script it is a little bit more complicated as you might want
zero-knowledge proofs of hash pre-images for HTLCs as well as proofs
of DL knowledge (signatures), but the basic idea is the same. Multi-
party wallet level protocols for jointly constructing scriptPubKeys
should require a 'delinearization' step that proves knowledge of
information necessary to complete each part of the script, as part of
proving the safety of a construct.
I think my hangup before in understanding the attack you describe was
in actualizing it into a practical attack that actually escalates the
attacker's capabilities. If the attacker can get you to agree to a
MAST policy that is nothing more than a CHECKSIG over a key they
presumably control, then they don't need to do any complicated
grinding. The attacker in that scenario would just actually specify a
key they control and take the funds that way.
Where this presumably leads to an actual exploit is when you specify a
script that a curious counter-party actually takes the time to
investigate and believes to be secure. For example, a script that
requires a signature or pre-image revelation from that counter-party.
That would require grinding not a few bytes, but at minimum 20-33
bytes for either a HASH160 image or the counter-party's key.
If I understand the revised attack description correctly, then there
is a small window in which the attacker can create a script less than
55 bytes in length, where nearly all of the first 32 bytes are
selected by the attacker, yet nevertheless the script seems safe to
the counter-party. The smallest such script I was able to construct
was the following:
 CHECKSIGVERIFY HASH160  EQUAL 
This is 56 bytes and requires only 7 bits of grinding in the fake
pubkey. But 56 bytes is too large. Switching to secp256k1 serialized
32-byte pubkeys (in a script version upgrade, for example) would
reduce this to the necessary 55 bytes with 0 bits of grinding. A
smaller variant is possible:
DUP HASH160  EQUALVERIFY CHECKSIGVERIFY HASH160 
EQUAL
This is 46 bytes, but requires grinding 96 bits, which is a bit less
plausible.
Belts and suspenders are not so terrible together, however, and I
think there is enough of a justification here to look into modifying
the scheme to use a different IV for hash tree updates. This would
prevent even the above implausible attacks.
On Sep 7, 2017, at 11:55 AM, Russell O'Connor
wrote:
On Thu, Sep 7, 2017 at 1:42 PM, Mark Friedenbach
> wrote:
I've been puzzling over your email since receiving it. I'm not sure it
is possible to perform the attack you describe with the tree structure
specified in the BIP. If I may rephrase your attack, I believe you are
seeking a solution to the following:
Want: An innocuous script and a malign script for which
double-SHA256(innocuous)
is equal to either
fast-SHA256(double-SHA256(malign) || r) or
fast-SHA256(r || double-SHA256(malign))
or fast-SHA256(fast-SHA256(double-SHA256(malign) || r1) || r0)
or fast-SHA256(fast-SHA256(r1 || double-SHA256(malign)) || r0)
or ...
where r is a freely chosen 32-byte nonce. This would allow the
attacker to reveal the innocuous script before funds are sent to the
MAST, then use the malign script to spend.
Because of the double-SHA256 construction I do not see how this can be
accomplished without a full break of SHA256.
The particular scenario I'm imagining is a collision between
double-SHA256(innocuous) 
and
fast-SHA256(fast-SHA256(fast-SHA256(double-SHA256(malign) || r2) || 
r1) || r0).
where innocuous is a Bitcoin Script that is between 32 and 55 bytes long.
Observe that when data is less than 55 bytes then double-SHA256(da...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Septembe014966.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Blockchain Primer - Merkle Tree, DAG, Consensus, Nonce, ... What is a Bitcoin nonce? - YouTube Bitcoin Q&A: Iterating nonces and the block reward Bitcoin - Block Hash Nonce - YouTube What Is Bitcoin and How Does It Work?

Still, the firm has already begun marking down the prices of its machines ahead of the halving event. Bitcoin's third halving, less than two weeks away, is often touted as a catalyst for a price ... Das Bitcoin-Netzwerk muss es also schwieriger machen, denn ansonsten würde jeder hunderte Blocks in der Sekunde hashen und alle Bitcoins wären in ein paar Stunden geschürft. Das Bitcoin-Protokoll macht es den Minern entsprechend durch die Einführung eines sogenannten Arbeitsnachweises absichtlich schwieriger – die Mining-Schwierigkeit steigt mit der Zeit an. Das Bitcoin-Netzwerk würde ... To avoid redundancy, Satoshi would limit every thread to a distinct non-overlapping nonce space. In the bitcoin mining process, a nonce gets incremented with each unsuccessful trial to solve a hash puzzle. Therefore, the mysterious pattern may not have been developed by choice. Instead, it might have come up as a side effect of Satoshi’s ... Nonce. Nonce is a numerical parameter that is sought during mining (PoW algorithm) and recorded in the block header. Actually, the goal of mining as a competitive process for the right to add a block of transactions to the blockchain is to select such Nonce so that the sought-for block hash is less than some given Target number, which is equivalent to obtaining a block hash starting from a ... During Bitcoin mining, a nonce gets incremented with every unsuccessful attempt to solve a hash puzzle. Thus, the mysterious pattern may not have been created by choice, but rather as a side effect of Satoshi's unique mining setup. Lerner agreed with this conclusion, potentially allowing us to put the speculation over this theory to rest once and for all.

[index] [25099] [11765] [42304] [6809] [2242] [23241] [6716] [1419] [47170] [28087]

Blockchain Primer - Merkle Tree, DAG, Consensus, Nonce, ...

What is the nonce? Is it possible guess it on the first try? How is the nonce found in mining pools? When a miner wins the block reward, how does the block know which address to pay? When does a ... If you’re interested in the crypto world, and can’t pull the headphones out of your ears, welcome to the BitcoinWiki channel! Here you'll find voiced article... In this short live stream, you'll learn what Bitcoin is, how it works, and how it is changing the world economy. Free Video Reveals: How To Earn 3.24 BTC In 51 Days. blockchain primer - Merkle Tree, DAG, Consensus, Nonce, ... Resources: The great BOOK: "Mastering Bitcoin": http://amzn.to/2BqmgNI * Home page: https://tomer... Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

#