bitcoind - How can I create a multi signature 2-of-3 ...

BitBulls

For Reddittors that are Bullish on Bitcoin and Bullion.
[link]

How to bet safely on Reddit with Bitcoins

We all love Reddit, almost as much as we love sports betting.
So what could be better than betting with fellow Redditors without running the risk of getting scammed?
How can you achieve this wonderful situation? With Bitcoin and multi-signature transactions.
In short, what Bitcoin+Multisignature transactions lets you do is add an arbiter to the betting process, without giving that person control of the funds in the bet.
In fact, the arbiter doesn't even need to be involved in setting up the bet. The entire process can take place without them; the arbiter only needs to get involved if there's a dispute about who won.
Here's how it works. Each bettor has a bitcoin address with some funds tied to it. They also have a set of public and private keys used to "sign" transactions.
You can think of a multisignature transaction like checks for an account that requires more than one signature to be depositable. In our example, the transaction has 3 possible signers, both bettors and the arbiter. It is valid when two of the three sign it.
The two bettors combine their public keys with the arbiter's to create the multisignature "account" address. (The arbiter's key will be publicly posted) Each bettor sends the amount of the bet to that address. They PM the terms of the bet to each other and to the arbiter.
After the bet, the winner creates a transaction (a "check") that sends the winnings to them. They sign the transaction. They send the transaction to the loser for the loser to sign it and broadcast it ("deposit" it into the winners bank).
In the event that the loser decides to be a dick, the winner sends the transaction to the arbiter. The arbiter looks at the terms of the bet he received in the PMs, checks that the winner actually won, and signs the transaction and broadcasts it.
The key takeaway here is this: the arbiter never has sole control of the funds. If both bettors are honest, the arbiter never has to get involved.
It's really that simple. I have a walkthrough of the step by step in this thread That said, I recommend the process only for techies, or for individuals experienced in bitcoin.
If you have any questions, post them below or PM me.
Check the walkthrough post comments for arbiters (the mod of /dogebetting is setting his up right now {He's got a great track record of doing escrow}, so he should be online to do bets very, very soon)
submitted by harddata to sportsbook [link] [comments]

Do vendors still get paid for multisignature transactions on marketplace's if they go down? /r/Bitcoin

Do vendors still get paid for multisignature transactions on marketplace's if they go down? /Bitcoin submitted by HiIAMCaptainObvious to BitcoinAll [link] [comments]

Resources for multisignature transactions? - Bitcoin StackExchange

Resources for multisignature transactions? - Bitcoin StackExchange submitted by ThePiachu to Bitcoin [link] [comments]

What prevents double spending in a multisignature bitcoin transaction?

Alice uses an address that contains one bitcoin. She enters into a 2 of 3 transaction in which this address is the only input. Assume the purpose is to ensure Alice can be refunded in the event of not receiving goods from an online order.
I'm wondering about whether Alice can double spend the funds at her address during his transaction. But I suspect I don't actually understand how such a transaction would work in practice.
  1. When does Alice sign the transaction? When she places the order, or when the goods are delivered intact?
  2. When does the transaction get posted to the network?
  3. What prevents Alice from double spending the funds at her address while the goods are in transit?
submitted by BobAlison to Bitcoin [link] [comments]

How to do a Multisignature Bitcoin Transaction with Coinbin

How to do a Multisignature Bitcoin Transaction with Coinbin submitted by TheAlexGalaxy to Bitcoin [link] [comments]

Update coming soon: Multisignature transactions, buyer and vendor ratings and disputes. (Open source bitcoin marketplace) : bitwasp

Update coming soon: Multisignature transactions, buyer and vendor ratings and disputes. (Open source bitcoin marketplace) : bitwasp submitted by Vespco to opensource [link] [comments]

Technical: Taproot: Why Activate?

This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/
Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else wants it, but why would I, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else because I swapped XXX fiat for Bitcoin unlike all those nocoiners?
And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess.
First, let's consider some principles of Bitcoin.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can get privacy, it just requires effort to do so).
So, how does Taproot affect those principles?

Taproot and Your /Coins

Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash).
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input).
However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits!
Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh?
With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save!
And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a softfork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well!
(P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1)
Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least 2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service!
So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win!
(even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot)
And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally. First do no harm!

Taproot and Your Contracts

No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade.
So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust.
Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade.
However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade.
In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address.
Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants).
But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer).
Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables more of these setups to happen for more gains from trade for everyone, also, moon and lambos).
(technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).

Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code.
This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded.
And you can do that, with HTLCs, today.
Of course, HTLCs do have problems:
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar".
Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given public key to you.
Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige).
(Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key).
So:
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script.
(technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)

Quantum Quibbles!

Now if you were really paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable??
Well, in theory yes. In practice, they probably are not.
It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P2WPKH/P2PKH pay-to-public-key-hash.
When you spend from a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key.
So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key.
(public keys should be public, that's why they're called public keys, LOL)
And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions.
So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort.
Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers.
For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
So:
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).

Summary

I Wanna Be The Taprooter!

So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do!

But I Hate Taproot!!

That's fine!

Discussions About Taproot Activation

submitted by almkglor to Bitcoin [link] [comments]

Technical: The Path to Taproot Activation

Taproot! Everybody wants to have it, somebody wants to make it, nobody knows how to get it!
(If you are asking why everybody wants it, see: Technical: Taproot: Why Activate?)
(Pedants: I mostly elide over lockin times)
Briefly, Taproot is that neat new thing that gets us:
So yes, let's activate taproot!

The SegWit Wars

The biggest problem with activating Taproot is PTSD from the previous softfork, SegWit. Pieter Wuille, one of the authors of the current Taproot proposal, has consistently held the position that he will not discuss activation, and will accept whatever activation process is imposed on Taproot. Other developers have expressed similar opinions.
So what happened with SegWit activation that was so traumatic? SegWit used the BIP9 activation method. Let's dive into BIP9!

BIP9 Miner-Activated Soft Fork

Basically, BIP9 has a bunch of parameters:
Now there are other parameters (name, starttime) but they are not anywhere near as important as the above two.
A number that is not a parameter, is 95%. Basically, activation of a BIP9 softfork is considered as actually succeeding if at least 95% of blocks in the last 2 weeks had the specified bit in the nVersion set. If less than 95% had this bit set before the timeout, then the upgrade fails and never goes into the network. This is not a parameter: it is a constant defined by BIP9, and developers using BIP9 activation cannot change this.
So, first some simple questions and their answers:

The Great Battles of the SegWit Wars

SegWit not only fixed transaction malleability, it also created a practical softforkable blocksize increase that also rebalanced weights so that the cost of spending a UTXO is about the same as the cost of creating UTXOs (and spending UTXOs is "better" since it limits the size of the UTXO set that every fullnode has to maintain).
So SegWit was written, the activation was decided to be BIP9, and then.... miner signalling stalled at below 75%.
Thus were the Great SegWit Wars started.

BIP9 Feature Hostage

If you are a miner with at least 5% global hashpower, you can hold a BIP9-activated softfork hostage.
You might even secretly want the softfork to actually push through. But you might want to extract concession from the users and the developers. Like removing the halvening. Or raising or even removing the block size caps (which helps larger miners more than smaller miners, making it easier to become a bigger fish that eats all the smaller fishes). Or whatever.
With BIP9, you can hold the softfork hostage. You just hold out and refuse to signal. You tell everyone you will signal, if and only if certain concessions are given to you.
This ability by miners to hold a feature hostage was enabled because of the miner-exit allowed by the timeout on BIP9. Prior to that, miners were considered little more than expendable security guards, paid for the risk they take to secure the network, but not special in the grand scheme of Bitcoin.

Covert ASICBoost

ASICBoost was a novel way of optimizing SHA256 mining, by taking advantage of the structure of the 80-byte header that is hashed in order to perform proof-of-work. The details of ASICBoost are out-of-scope here but you can read about it elsewhere
Here is a short summary of the two types of ASICBoost, relevant to the activation discussion.
Now, "overt" means "obvious", while "covert" means hidden. Overt ASICBoost is obvious because nVersion bits that are not currently in use for BIP9 activations are usually 0 by default, so setting those bits to 1 makes it obvious that you are doing something weird (namely, Overt ASICBoost). Covert ASICBoost is non-obvious because the order of transactions in a block are up to the miner anyway, so the miner rearranging the transactions in order to get lower power consumption is not going to be detected.
Unfortunately, while Overt ASICBoost was compatible with SegWit, Covert ASICBoost was not. This is because, pre-SegWit, only the block header Merkle tree committed to the transaction ordering. However, with SegWit, another Merkle tree exists, which commits to transaction ordering as well. Covert ASICBoost would require more computation to manipulate two Merkle trees, obviating the power benefits of Covert ASICBoost anyway.
Now, miners want to use ASICBoost (indeed, about 60->70% of current miners probably use the Overt ASICBoost nowadays; if you have a Bitcoin fullnode running you will see the logs with lots of "60 of last 100 blocks had unexpected versions" which is exactly what you would see with the nVersion manipulation that Overt ASICBoost does). But remember: ASICBoost was, at around the time, a novel improvement. Not all miners had ASICBoost hardware. Those who did, did not want it known that they had ASICBoost hardware, and wanted to do Covert ASICBoost!
But Covert ASICBoost is incompatible with SegWit, because SegWit actually has two Merkle trees of transaction data, and Covert ASICBoost works by fudging around with transaction ordering in a block, and recomputing two Merkle Trees is more expensive than recomputing just one (and loses the ASICBoost advantage).
Of course, those miners that wanted Covert ASICBoost did not want to openly admit that they had ASICBoost hardware, they wanted to keep their advantage secret because miners are strongly competitive in a very tight market. And doing ASICBoost Covertly was just the ticket, but they could not work post-SegWit.
Fortunately, due to the BIP9 activation process, they could hold SegWit hostage while covertly taking advantage of Covert ASICBoost!

UASF: BIP148 and BIP8

When the incompatibility between Covert ASICBoost and SegWit was realized, still, activation of SegWit stalled, and miners were still not openly claiming that ASICBoost was related to non-activation of SegWit.
Eventually, a new proposal was created: BIP148. With this rule, 3 months before the end of the SegWit timeout, nodes would reject blocks that did not signal SegWit. Thus, 3 months before SegWit timeout, BIP148 would force activation of SegWit.
This proposal was not accepted by Bitcoin Core, due to the shortening of the timeout (it effectively times out 3 months before the initial SegWit timeout). Instead, a fork of Bitcoin Core was created which added the patch to comply with BIP148. This was claimed as a User Activated Soft Fork, UASF, since users could freely download the alternate fork rather than sticking with the developers of Bitcoin Core.
Now, BIP148 effectively is just a BIP9 activation, except at its (earlier) timeout, the new rules would be activated anyway (instead of the BIP9-mandated behavior that the upgrade is cancelled at the end of the timeout).
BIP148 was actually inspired by the BIP8 proposal (the link here is a historical version; BIP8 has been updated recently, precisely in preparation for Taproot activation). BIP8 is basically BIP9, but at the end of timeout, the softfork is activated anyway rather than cancelled.
This removed the ability of miners to hold the softfork hostage. At best, they can delay the activation, but not stop it entirely by holding out as in BIP9.
Of course, this implies risk that not all miners have upgraded before activation, leading to possible losses for SPV users, as well as again re-pressuring miners to signal activation, possibly without the miners actually upgrading their software to properly impose the new softfork rules.

BIP91, SegWit2X, and The Aftermath

BIP148 inspired countermeasures, possibly from the Covert ASiCBoost miners, possibly from concerned users who wanted to offer concessions to miners. To this day, the common name for BIP148 - UASF - remains an emotionally-charged rallying cry for parts of the Bitcoin community.
One of these was SegWit2X. This was brokered in a deal between some Bitcoin personalities at a conference in New York, and thus part of the so-called "New York Agreement" or NYA, another emotionally-charged acronym.
The text of the NYA was basically:
  1. Set up a new activation threshold at 80% signalled at bit 4 (vs bit 1 for SegWit).
    • When this 80% signalling was reached, miners would require that bit 1 for SegWit be signalled to achive the 95% activation needed for SegWit.
  2. If the bit 4 signalling reached 80%, increase the block weight limit from the SegWit 4000000 to the SegWit2X 8000000, 6 months after bit 1 activation.
The first item above was coded in BIP91.
Unfortunately, if you read the BIP91, independently of NYA, you might come to the conclusion that BIP91 was only about lowering the threshold to 80%. In particular, BIP91 never mentions anything about the second point above, it never mentions that bit 4 80% threshold would also signal for a later hardfork increase in weight limit.
Because of this, even though there are claims that NYA (SegWit2X) reached 80% dominance, a close reading of BIP91 shows that the 80% dominance was only for SegWit activation, without necessarily a later 2x capacity hardfork (SegWit2X).
This ambiguity of bit 4 (NYA says it includes a 2x capacity hardfork, BIP91 says it does not) has continued to be a thorn in blocksize debates later. Economically speaking, Bitcoin futures between SegWit and SegWit2X showed strong economic dominance in favor of SegWit (SegWit2X futures were traded at a fraction in value of SegWit futures: I personally made a tidy but small amount of money betting against SegWit2X in the futures market), so suggesting that NYA achieved 80% dominance even in mining is laughable, but the NYA text that ties bit 4 to SegWit2X still exists.
Historically, BIP91 triggered which caused SegWit to activate before the BIP148 shorter timeout. BIP148 proponents continue to hold this day that it was the BIP148 shorter timeout and no-compromises-activate-on-August-1 that made miners flock to BIP91 as a face-saving tactic that actually removed the second clause of NYA. NYA supporters keep pointing to the bit 4 text in the NYA and the historical activation of BIP91 as a failed promise by Bitcoin developers.

Taproot Activation Proposals

There are two primary proposals I can see for Taproot activation:
  1. BIP8.
  2. Modern Softfork Activation.
We have discussed BIP8: roughly, it has bit and timeout, if 95% of miners signal bit it activates, at the end of timeout it activates. (EDIT: BIP8 has had recent updates: at the end of timeout it can now activate or fail. For the most part, in the below text "BIP8", means BIP8-and-activate-at-timeout, and "BIP9" means BIP8-and-fail-at-timeout)
So let's take a look at Modern Softfork Activation!

Modern Softfork Activation

This is a more complex activation method, composed of BIP9 and BIP8 as supcomponents.
  1. First have a 12-month BIP9 (fail at timeout).
  2. If the above fails to activate, have a 6-month discussion period during which users and developers and miners discuss whether to continue to step 3.
  3. Have a 24-month BIP8 (activate at timeout).
The total above is 42 months, if you are counting: 3.5 years worst-case activation.
The logic here is that if there are no problems, BIP9 will work just fine anyway. And if there are problems, the 6-month period should weed it out. Finally, miners cannot hold the feature hostage since the 24-month BIP8 period will exist anyway.

PSA: Being Resilient to Upgrades

Software is very birttle.
Anyone who has been using software for a long time has experienced something like this:
  1. You hear a new version of your favorite software has a nice new feature.
  2. Excited, you install the new version.
  3. You find that the new version has subtle incompatibilities with your current workflow.
  4. You are sad and downgrade to the older version.
  5. You find out that the new version has changed your files in incompatible ways that the old version cannot work with anymore.
  6. You tearfully reinstall the newer version and figure out how to get your lost productivity now that you have to adapt to a new workflow
If you are a technically-competent user, you might codify your workflow into a bunch of programs. And then you upgrade one of the external pieces of software you are using, and find that it has a subtle incompatibility with your current workflow which is based on a bunch of simple programs you wrote yourself. And if those simple programs are used as the basis of some important production system, you hve just screwed up because you upgraded software on an important production system.
And well, one of the issues with new softfork activation is that if not enough people (users and miners) upgrade to the newest Bitcoin software, the security of the new softfork rules are at risk.
Upgrading software of any kind is always a risk, and the more software you build on top of the software-being-upgraded, the greater you risk your tower of software collapsing while you change its foundations.
So if you have some complex Bitcoin-manipulating system with Bitcoin somewhere at the foundations, consider running two Bitcoin nodes:
  1. One is a "stable-version" Bitcoin node. Once it has synced, set it up to connect=x.x.x.x to the second node below (so that your ISP bandwidth is only spent on the second node). Use this node to run all your software: it's a stable version that you don't change for long periods of time. Enable txiindex, disable pruning, whatever your software needs.
  2. The other is an "always-up-to-date" Bitcoin Node. Keep its stoarge down with pruning (initially sync it off the "stable-version" node). You can't use blocksonly if your "stable-version" node needs to send transactions, but otherwise this "always-up-to-date" Bitcoin node can be kept as a low-resource node, so you can run both nodes in the same machine.
When a new Bitcoin version comes up, you just upgrade the "always-up-to-date" Bitcoin node. This protects you if a future softfork activates, you will only receive valid Bitcoin blocks and transactions. Since this node has nothing running on top of it, it is just a special peer of the "stable-version" node, any software incompatibilities with your system software do not exist.
Your "stable-version" Bitcoin node remains the same version until you are ready to actually upgrade this node and are prepared to rewrite most of the software you have running on top of it due to version compatibility problems.
When upgrading the "always-up-to-date", you can bring it down safely and then start it later. Your "stable-version" wil keep running, disconnected from the network, but otherwise still available for whatever queries. You do need some system to stop the "always-up-to-date" node if for any reason the "stable-version" goes down (otherwisee if the "always-up-to-date" advances its pruning window past what your "stable-version" has, the "stable-version" cannot sync afterwards), but if you are technically competent enough that you need to do this, you are technically competent enough to write such a trivial monitor program (EDIT: gmax notes you can adjust the pruning window by RPC commands to help with this as well).
This recommendation is from gmaxwell on IRC, by the way.
submitted by almkglor to Bitcoin [link] [comments]

Taproot, CoinJoins, and Cross-Input Signature Aggregation

It is a very common misconception that the upcoming Taproot upgrade helps CoinJoin.
TLDR: The upcoming Taproot upgrade does not help equal-valued CoinJoin at all, though it potentially increases the privacy of other protocols, such as the Lightning Network, and escrow contract schemes.
If you want to learn more, read on!

Equal-valued CoinJoins

Let's start with equal-valued CoinJoins, the type JoinMarket and Wasabi use. What happens is that some number of participants agree on some common value all of them use. With JoinMarket the taker defines this value and pays the makers to agree to it, with Wasabi the server defines a value approximately 0.1 BTC.
Then, each participant provides inputs that they unilaterally control, totaling equal or greater than the common value. Typically since each input is unilaterally controlled, each input just requires a singlesig. Each participant also provides up to two addresses they control: one of these will be paid with the common value, while the other will be used for any extra value in the inputs they provided (i.e. the change output).
The participants then make a single transaction that spends all the provided inputs and pays out to the appropriate outputs. The inputs and outputs are shuffled in some secure manner. Then the unsigned transaction is distributed back to all participants.
Finally, each participant checks that the transaction spends the inputs it provided (and more importantly does not spend any other coins it might own that it did not provide for this CoinJoin!) and that the transaction pays out to the appropriate address(es) it controls. Once they have validated the transaction, they ratify it by signing for each of the inputs it provided.
Once every participant has provided signatures for all inputs it registered, the transaction is now completely signed and the CoinJoin transaction is now validly confirmable.
CoinJoin is a very simple and direct privacy boost, it requires no SCRIPTs, needs only singlesig, etc.

Privacy

Let's say we have two participants who have agreed on a common amount of 0.1 BTC. One provides a 0.105 coin as input, the other provides a 0.114 coin as input. This results in a CoinJoin with a 0.105 coin and a 0.114 coin as input, and outputs with 0.1, 0.005, 0.014, and 0.1 BTC.
Now obviously the 0.005 output came from the 0.105 input, and the 0.014 output came from the 0.114 input.
But the two 0.1 BTC outputs cannot be correlated with either input! There is no correlating information, since either output could have come from either input. That is how common CoinJoin implementations like Wasabi and JoinMarket gain privacy.

Banning CoinJoins

Unfortunately, large-scale CoinJoins like that made by Wasabi and JoinMarket are very obvious.
All you have to do is look for a transactions where, say, more than 3 outputs are the same equal value, and the number of inputs is equal or larger than the number of equal-valued outputs. Thus, it is trivial to identify equal-valued CoinJoins made by Wasabi and JoinMarket. You can even trivially differentiate them: Wasabi equal-valued CoinJoins are going to have a hundred or more inputs, with outputs that are in units of approximately 0.1 BTC, while JoinMarket CoinJoins have equal-valued outputs of less than a dozen (between 4 to 6 usually) and with the common value varying wildly from as low as 0.001 BTC to as high as a dozen BTC or more.
This has led to a number of anti-privacy exchanges to refuse to credit custodially-held accounts if the incoming deposit is within a few hops of an equal-valued CoinJoin, usually citing concerns about regulations. Crucially, the exchange continues to hold private keys for those "banned" deposits, and can still spend them, thus this is effectively a theft. If your exchange does this to you, you should report that exchange as stealing money from its customers. Not your keys not your coins.
Thus, CoinJoins represent a privacy tradeoff:

Taproot

Let's now briefly discuss that nice new shiny thing called Taproot.
Taproot includes two components:
This has some nice properties:

Taproot DOES NOT HELP CoinJoin

So let's review!
CoinJoin:
Taproot:
There is absolutely no overlap. Taproot helps things that CoinJoin does not use. CoinJoin uses things that Taproot does not improve.

B-but They Said!!

A lot of early reporting on Taproot claimed that Taproot benefits CoinJoin.
What they are confusing is that earlier drafts of Taproot included a feature called cross-input signature aggregation.
In current Bitcoin, every input, to be spent, has to be signed individually. With cross-input signature aggregation, all inputs that support this feature are signed with a single signature that covers all those inputs. So for example if you would spend two inputs, current Bitcoin requires a signature for each input, but with cross-input signature aggregation you can sign both of them with a single signature. This works even if the inputs have different public keys: two inputs with cross-input signature aggregation effectively define a 2-of-2 public key, and you can only sign for that input if you know the private keys for both inputs, or if you are cooperatively signing with somebody who knows the private key of the other input.
This helps CoinJoin costs. Since CoinJoins will have lots of inputs (each participant will provide at least one, and probably will provide more, and larger participant sets are better for more privacy in CoinJoin), if all of them enabled cross-input signature aggregation, such large CoinJoins can have only a single signature.
This complicates the signing process for CoinJoins (the signers now have to sign cooperatively) but it can be well worth it for the reduced signature size and onchain cost.
But note that the while cross-input signature aggregation improves the cost of CoinJoins, it does not improve the privacy! Equal-valued CoinJoins are still obvious and still readily bannable by privacy-hating exchanges. It does not improve the privacy of CoinJoin. Instead, see https://old.reddit.com/Bitcoin/comments/gqb3udesign_for_a_coinswap_implementation_fo

Why isn't cross-input signature aggregation in?

There's some fairly complex technical reasons why cross-input signature aggregation isn't in right now in the current Taproot proposal.
The primary reason was to reduce the technical complexity of Taproot, in the hope that it would be easier to convince users to activate (while support for Taproot is quite high, developers have become wary of being hopeful that new proposals will ever activate, given the previous difficulties with SegWit).
The main technical complexity here is that it interacts with future ways to extend Bitcoin.
The rest of this writeup assumes you already know about how Bitcoin SCRIPT works. If you don't understand how Bitcoin SCRIPT works at the low-level, then the TLDR is that cross-input signature aggregation complicates how to extend Bitcoin in the future, so it was deferred to let the develoeprs think more about it.
(this is how I understand it; perhaps pwuille or ajtowns can give a better summary.)
In detail, Taproot also introduces OP_SUCCESS opcodes. If you know about the OP_NOP opcodes already defined in current Bitcoin, well, OP_SUCCESS is basically "OP_NOP done right".
Now, OP_NOP is a do-nothing operation. It can be replaced in future versions of Bitcoin by having that operation check some condition, and then fail if the condition is not satisfied. For example, both OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY were previously OP_NOP opcodes. Older nodes will see an OP_CHECKLOCKTIMEVERIFY and think it does nothing, but newer nodes will check if the nLockTime field has a correct specified value, and fail if the condition is not satisfied. Since most of the nodes on the network are using much newer versions of the node software, older nodes are protected from miners who try to misspend any OP_CHECKLOCKTIMEVERIFY/OP_CHECKSEQUENCEVERIFY, and those older nodes will still remain capable of synching with the rest of the network: a dedication to strict backward-compatibility necessary for a consensus system.
Softforks basically mean that a script that passes in the latest version must also be passing in all older versions. A script cannot be passing in newer versions but failing in older versions, because that would kick older nodes off the network (i.e. it would be a hardfork).
But OP_NOP is a very restricted way of adding opcodes. Opcodes that replace OP_NOP can only do one thing: check if some condition is true. They can't push new data on the stack, they can't pop items off the stack. For example, suppose instead of OP_CHECKLOCKTIMEVERIFY, we had added a OP_GETBLOCKHEIGHT opcode. This opcode would push the height of the blockchain on the stack. If this command replaced an older OP_NOP opcode, then a script like OP_GETBLOCKHEIGHT 650000 OP_EQUAL might pass in some future Bitcoin version, but older versions would see OP_NOP 650000 OP_EQUAL, which would fail because OP_EQUAL expects two items on the stack. So older versions will fail a SCRIPT that newer versions will pass, which is a hardfork and thus a backwards incompatibility.
OP_SUCCESS is different. Instead, old nodes, when parsing the SCRIPT, will see OP_SUCCESS, and, without executing the body, will consider the SCRIPT as passing. So, the OP_GETBLOCKHEIGHT 650000 OP_EQUAL example will now work: a future version of Bitcoin might pass it, and existing nodes that don't understand OP_GETBLOCKHEIGHT will se OP_SUCCESS 650000 OP_EQUAL, and will not execute the SCRIPT at all, instead passing it immediately. So a SCRIPT that might pass in newer versions will pass for older versions, which keeps the back-compatibility consensus that a softfork needs.
So how does OP_SUCCESS make things difficult for cross-input signatur aggregation? Well, one of the ways to ask for a signature to be verified is via the opcodes OP_CHECKSIGVERIFY. With cross-input signature aggregation, if a public key indicates it can be used for cross-input signature aggregation, instead of OP_CHECKSIGVERIFY actually requiring the signature on the stack, the stack will contain a dummy 0 value for the signature, and the public key is instead added to a "sum" public key (i.e. an n-of-n that is dynamically extended by one more pubkey for each OP_CHECKSIGVERIFY operation that executes) for the single signature that is verified later by the cross-input signature aggregation validation algorithm00.
The important part here is that the OP_CHECKSIGVERIFY has to execute, in order to add its public key to the set of public keys to be checked in the single signature.
But remember that an OP_SUCCESS prevents execution! As soon as the SCRIPT is parsed, if any opcode is OP_SUCCESS, that is considered as passing, without actually executing the SCRIPT, because the OP_SUCCESS could mean something completely different in newer versions and current versions should assume nothing about what it means. If the SCRIPT contains some OP_CHECKSIGVERIFY command in addition to an OP_SUCCESS, that command is not executed by current versions, and thus they cannot add any public keys given by OP_CHECKSIGVERIFY. Future versions also have to accept that: if they parsed an OP_SUCCESS command that has a new meaning in the future, and then execute an OP_CHECKSIGVERIFY in that SCRIPT, they cannot add the public key into the same "sum" public key that older nodes use, because older nodes cannot see them. This means that you might need more than one signature in the future, in the presence of an opcode that replaces some OP_SUCCESS.
Thus, because of the complexity of making cross-input signature aggregation work compatibly with future extensions to the protocol, cross-input signature aggregation was deferred.
submitted by almkglor to Bitcoin [link] [comments]

The implementation of the Schnorr/Taproot consensus rules has been merged into Bitcoin Core.

What Are Schnorr and Taproot?
Schnorr is an alternative algorithm to ECDSA, which is currently used to generate cryptographic signatures. Schnorr signatures would enable the flexible creation and execution of multisignature transactions by combining scripts to reduce their size and provide the subsequent benefit of added privacy, as multisignature transactions would become indistinguishable from regular Bitcoin transactions.
Taproot is the specific method in which Schnorr signatures will be leveraged to create multisignature transactions. It was first proposed by former Blockstream CTO Gregory Maxwell in the Bitcoin-dev mailing list. Since then, several iterations have taken place, leading to the pull request that was merged today.
Bitcoin’s Future: Exactly How a Coming Upgrade Could Improve Privacy and Scaling
submitted by mishax1 to CryptoCurrency [link] [comments]

Zano Newcomers Introduction/FAQ - please read!

Welcome to the Zano Sticky Introduction/FAQ!

https://preview.redd.it/al1gy9t9v9q51.png?width=424&format=png&auto=webp&s=b29a60402d30576a4fd95f592b392fae202026ca
Hopefully any questions you have will be answered by the resources below, but if you have additional questions feel free to ask them in the comments. If you're quite technically-minded, the Zano whitepaper gives a thorough overview of Zano's design and its main features.
So, what is Zano? In brief, Zano is a project started by the original developers of CryptoNote. Coins with market caps totalling well over a billion dollars (Monero, Haven, Loki and countless others) run upon the codebase they created. Zano is a continuation of their efforts to create the "perfect money", and brings a wealth of enhancements to their original CryptoNote code.
Development happens at a lightning pace, as the Github activity shows, but Zano is still very much a work-in-progress. Let's cut right to it:
Here's why you should pay attention to Zano over the next 12-18 months. Quoting from a recent update:
Anton Sokolov has recently joined the Zano team. ... For the last months Anton has been working on theoretical work dedicated to log-size ring signatures. These signatures theoretically allows for a logarithmic relationship between the number of decoys and the size/performance of transactions. This means that we can set mixins at a level from up to 1000, keeping the reasonable size and processing speed of transactions. This will take Zano’s privacy to a whole new level, and we believe this technology will turn out to be groundbreaking!
If successful, this scheme will make Zano the most private, powerful and performant CryptoNote implementation on the planet. Bar none. A quantum leap in privacy with a minimal increase in resource usage. And if there's one team capable of pulling it off, it's this one.

What else makes Zano special?

You mean aside from having "the Godfather of CryptoNote" as the project lead? ;) Actually, the calibre of the developers/researchers at Zano probably is the project's single greatest strength. Drawing on years of experience, they've made careful design choices, optimizing performance with an asynchronous core architecture, and flexibility and extensibility with a modular code structure. This means that the developers are able to build and iterate fast, refining features and adding new ones at a rate that makes bigger and better-funded teams look sluggish at best.
Zano also has some unique features that set it apart from similar projects:
Privacy Firstly, if you're familiar with CryptoNote you won't be surprised that Zano transactions are private. The perfect money is fungible, and therefore must be untraceable. Bitcoin, for the most part, does little to hide your transaction data from unscrupulous observers. With Zano, privacy is the default.
The untraceability and unlinkability of Zano transactions come from its use of ring signatures and stealth addresses. What this means is that no outside observer is able to tell if two transactions were sent to the same address, and for each transaction there is a set of possible senders that make it impossible to determine who the real sender is.
Hybrid PoW-PoS consensus mechanism Zano achieves an optimal level of security by utilizing both Proof of Work and Proof of Stake for consensus. By combining the two systems, it mitigates their individual vulnerabilities (see 51% attack and "nothing at stake" problem). For an attack on Zano to have even a remote chance of success the attacker would have to obtain not only a majority of hashing power, but also a majority of the coins involved in staking. The system and its design considerations are discussed at length in the whitepaper.
Aliases Here's a stealth address: ZxDdULdxC7NRFYhCGdxkcTZoEGQoqvbZqcDHj5a7Gad8Y8wZKAGZZmVCUf9AvSPNMK68L8r8JfAfxP4z1GcFQVCS2Jb9wVzoe. I have a hard enough time remembering my phone number. Fortunately, Zano has an alias system that lets you register an address to a human-readable name. (@orsonj if you want to anonymously buy me a coffee)
Multisig
Multisignature (multisig) refers to requiring multiple keys to authorize a Zano transaction. It has a number of applications, such as dividing up responsibility for a single Zano wallet among multiple parties, or creating backups where loss of a single seed doesn't lead to loss of the wallet.
Multisig and escrow are key components of the planned Decentralized Marketplace (see below), so consideration was given to each of them from the design stages. Thus Zano's multisig, rather than being tagged on at the wallet-level as an afterthought, is part of its its core architecture being incorporated at the protocol level. This base-layer integration means months won't be spent in the future on complicated refactoring efforts in order to integrate multisig into a codebase that wasn't designed for it. Plus, it makes it far easier for third-party developers to include multisig (implemented correctly) in any Zano wallets and applications they create in the future.
(Double Deposit MAD) Escrow
With Zano's escrow service you can create fully customizable p2p contracts that are designed to, once signed by participants, enforce adherence to their conditions in such a way that no trusted third-party escrow agent is required.
https://preview.redd.it/jp4oghyhv9q51.png?width=1762&format=png&auto=webp&s=12a1e76f76f902ed328886283050e416db3838a5
The Particl project, aside from a couple of minor differences, uses an escrow scheme that works the same way, so I've borrowed the term they coined ("Double Deposit MAD Escrow") as I think it describes the scheme perfectly. The system requires participants to make additional deposits, which they will forfeit if there is any attempt to act in a way that breaches the terms of the contract. Full details can be found in the Escrow section of the whitepaper.
The usefulness of multisig and the escrow system may not seem obvious at first, but as mentioned before they'll form the backbone of Zano's Decentralized Marketplace service (described in the next section).

What does the future hold for Zano?

The planned upgrade to Zano's privacy, mentioned at the start, is obviously one of the most exciting things the team is working on, but it's not the only thing.
Zano Roadmap
Decentralized Marketplace
From the beginning, the Zano team's goal has been to create the perfect money. And money can't just be some vehicle for speculative investment, money must be used. To that end, the team have created a set of tools to make it as simple as possible for Zano to be integrated into eCommerce platforms. Zano's API’s and plugins are easy to use, allowing even those with very little coding experience to use them in their E-commerce-related ventures. The culmination of this effort will be a full Decentralized Anonymous Marketplace built on top of the Zano blockchain. Rather than being accessed via the wallet, it will act more as a service - Marketplace as a Service (MAAS) - for anyone who wishes to use it. The inclusion of a simple "snippet" of code into a website is all that's needed to become part a global decentralized, trustless and private E-commerce network.
Atomic Swaps
Just as Zano's marketplace will allow you to transact without needing to trust your counterparty, atomic swaps will let you to easily convert between Zano and other cyryptocurrencies without having to trust a third-party service such as a centralized exchange. On top of that, it will also lead to the way to Zano's inclusion in the many decentralized exchange (DEX) services that have emerged in recent years.

Where can I buy Zano?

Zano's currently listed on the following exchanges:
https://coinmarketcap.com/currencies/zano/markets/
It goes without saying, neither I nor the Zano team work for any of the exchanges or can vouch for their reliability. Use at your own risk and never leave coins on a centralized exchange for longer than necessary. Your keys, your coins!
If you have any old graphics cards lying around(both AMD & NVIDIA), then Zano is also mineable through its unique ProgPowZ algorithm. Here's a guide on how to get started.
Once you have some Zano, you can safely store it in one of the desktop or mobile wallets (available for all major platforms).

How can I support Zano?

Zano has no marketing department, which is why this post has been written by some guy and not the "Chief Growth Engineer @ Zano Enterprises". The hard part is already done: there's a team of world class developers and researchers gathered here. But, at least at the current prices, the team's funds are enough to cover the cost of development and little more. So the job of publicizing the project falls to the community. If you have any experience in community building/growth hacking at another cryptocurrency or open source project, or if you're a Zano holder who would like to ensure the project's long-term success by helping to spread the word, then send me a pm. We need to get organized.
Researchers and developers are also very welcome. Working at the cutting edge of mathematics and cryptography means Zano provides challenging and rewarding work for anyone in those fields. Please contact the project's Community Manager u/Jed_T if you're interested in joining the team.
Social Links:
Twitter
Discord Server
Telegram Group
Medium blog
I'll do my best to keep this post accurate and up to date. Message me please with any suggested improvements and leave any questions you have below.
Welcome to the Zano community and the new decentralized private economy!
submitted by OrsonJ to Zano [link] [comments]

Storing your coins safely while not risking loss of keys

This was originally an answer to a question that was asked here, but OP deleted their post.
This might help some newbies (especially the multisig edit at the end), so I want to make sure it's still accessible here.
The original question was whether the Electrum wallet stores a Trezor's private key when using a passphrase.
OP noticed that their Trezor wouldn't connect to their Electrum wallet when entering a different passphrase than they used when creating the wallet. Thus, OP (likely) assumed that the wallet stored the private key, as it somehow knew that a different private key was now used.
Here is my original answer (with some modifications):
IMPORTANT: I'm assuming here that you connected your Trezor by choosing the "hardware wallet" option in Electrum, rather than giving Electrum your 12/24 seed words.
TL;DR: No, your coins are safe :)
I'm assuming by passphrase) you mean the 25th (or 13th) word. When you have this feature enabled, a private key gets generated every time you enter a passphrase. When you enter the same passphrase you used to create the wallet, the wallet with your funds shows up.
Whenever you enter something different, a different private key is generated on your Trezor. This allows you to have multiple different wallets, for example by choosing the passphrases "First Wallet", "Second Wallet", "Third Wallet", or a secret wallet with a secret passphrase.
So whenever you enter a new passphrase when connecting your Trezor to Electrum, the Trezor will send a new public key to Electrum. Electrum will then derive addresses from this public key and check those for balances. It won't find any, as you used a new passphrase.
EDIT: I just realized that you said your wallet doesn't connect to Electrum when you use a different passphrase. This is simply because Electrum doesn't receive the correct public key from the Trezor and therefore Electrum thinks it's a different wallet (which it is).
When you enter the passphrase you used during creation of your wallet, the Trezor will send your actual public key to Electrum, which will then find addresses with balances, which it will show to you. EDIT (to clarify): Connecting your Trezor after creating the wallet is only necessary to send funds or verify addresses, as the public key is already stored in the wallet.dat.
The only thing Electrum actually stores is the public key, which can only be used to look at your Bitcoin, not to move them. You might want to keep this public key a secret as well though, since it links all your funds to you. This is what Electrum stores in the wallet.dat file, which you can just encrypt by choosing a password for it.
Well done using a passphrase by the way! Should someone get their hands on your Trezor, a sophisticated attacker can get the secret key off the device in 15 minutes. Using a passphrase makes this attack almost useless, as the both secret key AND the passphrase are needed to move your funds, and the passphrase is not stored on the device. A passphrase also allows you to hide funds from potential robbers that force you to unlock your wallet.
You can do this by activating the passphrase feature and sending your funds to a wallet with a secret passphrase (do NOT lose this, as losing your passphrase renders your funds inaccessible). Afterwards, you can safely deactivate the passphrase feature, so the device doesn't even ask for one should you get robbed. Simply reactivate it when you need to access your funds.
EDIT: Should you be worried that you might forget your passphrase, you should look into multisig wallets. Depending on how you set this up, you can make it more secure against theft and less likely for you to lose access to your funds.
Say for example you get four wallets: two hardware wallets, a well-protected (airgapped) laptop with Electrum, and a secure mobile wallet that allows for multisig (like Fully Noded).
You can then create a 2-of-4 multisig wallet that requires you to sign transactions with any two of these four wallets.
The increase in security comes from the fact that an attacker now needs full access to two of your devices (or their stored private keys) at once.
At the same time, the fact that you yourself now also need access to only half of your devices means that in the event of a total loss of one (or even two) of them, you can still move your funds to a new wallet.
As long as you do regular checks (e.g. first day of each month), ensuring that you still have access to all your devices' stored private keys, you can always catch a loss of keys and fix this without losing funds (by creating a new multisig wallet and sending the funds there).
This allows you to use a passphrase on your wallets without storing it anywhere physically or digitally. This would usually be very risky, as forgetting the passphrase would lead to a loss of funds, but this risk is now close to eliminated.
(The following part was not in the original answer)
Some IMPORTANT general secruity tips:
  1. Consider including trusted friends and/or family members as co-signers for a multisig wallet. This ensures that it's not even possible for you alone to hand over funds to an attacker. Depending on your level of trust, you might want to make sure that your co-signers can't collaborate to steal your funds (if you include 3 people, create at least a 4-of-n multisig). You could also deliberately make it possible for all or even just some of your co-signers to move your funds (3 co-signers, 3(or less)-of-n multisig) to make sure your funds aren't lost should pass away unexpectedly.
  2. Consider running your own full node and Electrum server (also check the alternatives), which you connect your Electrum wallet to. This ensures that you don't send your public key to anyone else. If someone knows your public key, they know how much BTC you own, making you a potential target.
  3. Always encrypt your wallet.dat (or whatever you called your wallet file), even if it's a watch-only wallet. This protects your public key (see 1. for why you want that).
  4. Create watch-only wallets: Use an airgapped) device to create a wallet with Electrum (make sure to back up the seed phrase) and export the public key. Then create a new watch-only wallet on another device (like your everyday laptop) with that public key to be able to check your funds. To create the initial wallet, you can also use any other hard- or software wallet that allows you to export the master public key.
  5. Hide, or (when using a hardware wallet with a passphrase) even delete your watch-only wallets. Hiding your funds makes you less of a target. When using a hardware wallet, recreating the watch-only wallet is fast and simple, so you don't need to store it if you don't want to check your funds every day. Note that this approach doesn't help much when you don't use a passphrase, as an attacker will obviously check the passphrase-less wallet no matter what.
  6. Keep some funds on your hardware wallet(s). If an attackers sees funds on the wallet(s), they might not force you to enter a passphrase or ask if you have any multisig wallets (lying under pressure is hard).
  7. Hide all your wallets in different places. If someone sees that you have multiple wallets lying around, they might realize you have a multisig wallet.
  8. Don't risk a robber getting (for example) two keys to your 2-of-4 multisig wallet and then racing them to move your funds with the other two keys when they leave. They're gonna come back and be pissed. If it comes to this, you need protection until the robber is caught. STAY SAFE!
  9. The easiest way to solve a problem is to never have it. Don't make yourself a target. If nobody even suspects that you have a multisig (or any wallet at all), they're probably not gonna look for it.
Please correct any mistakes you find and I will edit my post. I will also gladly add more tips to the list. I will of course credit anyone who helps.
Tip for devs who want something cool and important to work on: Make the creation and usage of multisig wallets as noob-friendly as possible. If someone expresses worries about losing access to their funds by forgetting the seed phrase, wallet pin, etc. (someone in my family actually brought this up to me), multisig wallets are the perfect solution as they add redundancy.
submitted by Fittiboy to Bitcoin [link] [comments]

WaykiChain (WICC) Monthly Report (September 2020)

WaykiChain (WICC) Monthly Report (September 2020)

https://preview.redd.it/nnuhfz6q01t51.png?width=700&format=png&auto=webp&s=15ce35581f2ebad02af140180f5a8b1fe7931f00
Technology & Products
Public Chain Development
· WASM AMPL contract debugging (100%)
· Research on WASM zero-knowledge proof anonymous transfer (50%)
· WASM Sushi contract coding (100%)
· WASM RPC iOS asynchronous library commissioning (100%)
· Verification of the signature push public key algorithm and testing its codability (C++, go) through RPC (100%)
· The new lock-up airdrop contract function: lock-up users can claim the unlocked assets by entering RegID (100%)
· Porting ASWAP contract to public chain 3.0, adding platform fee processing (100%)
· Optimization of Yield Farming contract reward distribution (100%)
· Optimization of Yield Farming contract penalty distribution mechanism (100%)
· Yield Farming contract testing (100%)
· Deployment and initial configuration of WICC and WGRT yield farming contracts and Wayki-X contract completed (100%)
· Ownership of issuance and transfer rights of the bottom-level token ROG transferred to Wayki-X contract (100%)
· The initial generation of ROG completed. 10.08M ROG entered the WICC pool, 2.52M ROG entered the WGRT pool (100%)
· The first 189,000 ROG was minted in Wayki-X contract for rewards by inflation (12.6M × 1.5%) (100%)
· Transfer of 70,000 ROG to AEX for Ecosystem Yield Farming completed (100%)
· WASM developer documentation: added detailed WASM table (Simplified Chinese) (100%)
· WASM developer documentation: added call of multiple contracts and multisignature transactions in WASM contract (Simplified Chinese) (100%)
Application Development
· Yield Farming back end API (100%)
· Yield Farming front end page optimization (100%)
· Yield Farming front end localization (100%)
· Yield Farming pre-release initial API docking (100%)
· Yield Farming application testing (100%)
· Yield Farming application release (100%)
· xUSD & ROG added to Instant in WaykiTimes Android (100%)
· Memory leak issue fixed in Instant in WaykiTimes (100%)
· Data loading error when swiping in Discover fixed in WaykiTimes (100%)
· Data display optimized in Getting Started in WaykiTimes
· UI debugging of several pages in WaykiTimes (100%)
· WaykiTimes 3.0.4 released (100%)
· WaykiTimes Help Center released (100%)
· WaykiTimes Getting Started released (100%)
· WaykiTimes remember password function released (100%)
· WaykiTimes iOS App Store version tested (100%)
· Google crash analysis and testing added to WaykiTimes Android (100%)
· Solved the data loading issue when swiping in Wayki-X Synths (100%)
· Wayki-X price feed delay fixed (100%)
· Amount issue in the plug-in wallet fixed (100%)
· Display error of release contract type of universal transactions fixed on the blockchain explorer (100%)
· WASM contract display specifications for the blockchain explorer completed (100%)
· Development of the Coinbase integration project (wicc-rosetta-api) (85%)
Plan for October
Public Chain Development
· Research on WASM zero-knowledge proof anonymous transfer
· Correction of ASWAP contract proof of liquidity token generation rules
· ASWAP contract testing
· Docking of ASWAP contract with third parties
· Continuous updating of coind RPC interface documentation
Application Development
· Trade — transaction details HTML5 page to native page transfer in WaykiTimes
· Development of the Coinbase integration project (wicc-rosetta-api)
Market
International Market
· On September 4, Russian volunteers opened the second WaykiChain Russian group in Telegram: https://t.me/waykichainrussian.
· On September 6, WaykiChain opened the official community in Discord: https://discord.gg/XyAkqa.
· On September 6, WaykiChain CTO Richard Chen was invited to the Blockchain + Innovative Service and Industrial Application Conference and the China Chamber of International Commerce Blockchain Innovation Service Industry Committee Establishment Conference as a member of the expert group.
· On September 11, the famous US blockchain TV program Exploring the Block tweeted about WaykiChain, showing it is optimistic about the future development of the integrated DeFi ecology of WaykiChain.
· On September 11, the famous business platform Yahoo Finance released WaykiChain project information and announced that WaykiChain CEO Gordon Gao gives an interview to NASDAQ MarketSite’s Jane King on September 12.
· At 7:00 PM EDT on September 12, world’s largest financial channel Bloomberg TV reported that WaykiChain CEO Gordon Gao was interviewed by Jane King of NASDAQ MarketSite. The interview aired on Fox Business Network at 10:30 PM EDT on September 14.
· On September 12, cryptocurrency Twitter account Crypto Catalog tweeted about WaykiChain, showing it is optimistic about the future development of the integrated DeFi ecology of WaykiChain.
· On September 13, DeFi List added WaykiChain governance token WGRT.
· On September 13, WaykiChain reached market cooperation with the Indian blockchain influencer Gmadvice who started to serve as WaykiChain community manager in India.
· On September 16, WaykiChain released “WaykiChain Launches Phoenix Yield Farming with WICC/WGRT Dual-pool for ROG Genesis Issuance” on Twitter. Up to September 21, the news hit 2,400+ retweets.
· On September 17, the cryptocurrency influencer DeFi List retweeted “WaykiChain Launches Phoenix Yield Farming with WICC/WGRT Dual-pool for ROG Genesis Issuance”.
· On September 18, WaykiChain reached strategic market cooperation with the Korean crypto influencer Pantera who will help WaykiChain establish a broad and strong consensus in Korea.
· On September 19, “WaykiChain Dual-pool ROG Yield Farming Korean Group” community established.
· On September 20, the influencer Crypto Wendy retweeted “WaykiChain Launches Phoenix Yield Farming with WICC/WGRT Dual-pool for ROG Genesis Issuance”.
· On September 21, 130+ Korean media outlets published “WaykiChain Launches Phoenix Yield Farming with WICC & WGRT Dual-pool for ROG Genesis Issuance”.
· On September 23, WaykiChain co-founder and CEO Gordon Gao was invited to an AMA session with ICO Pantera Group, Korea’s top Telegram group (stats by u/combot), where he shared his insights into DeFi with 4,000+ Korean users and introduced WaykiChain’s ROG Genesis Yield Farming.
· On September 24, WaykiChain tweeted “ROG Genesis Yield Farming FAQ” and “Leave your question/problem toward WaykiTimes/Wayki-X/ROG Genesis Yield Farming in the Google forms below to share 800 WICC Giveaway!”, the number of engagements is 1,500+.
· On September 24, WaykiChain global partner Vincent Lionheart was invited to an AMA session to D’va Community.
· On September 24, The Business Telegraph, Bitcoin Garden, and other media published “WaykiChain Launches Phoenix Yield Farming with WICC & WGRT Dual-pool”.
· On September 24, WaykiChain tweeted the ROG Genesis Yield Farming Countdown. The news hit 1,000+ retweets.
· On September 25, ROG Genesis Yield Farming news was the day’s hit in Korea with 5,000+ views on Korean cryptocurrency forums.
National Market
· On September 1, CoinTiger listed WaykiChain governance token WGRT and opened the WGRT/USDT pair. WGRT net buy & hold competition started and the CoinTiger community joined a series of WGRT-themed challenges.
· On September 1, WaykiChain governance token WGRT successfully mapped to Ethereum and ERC-20 WGRT was created. The world’s largest DEX Uniswap officially supported it and listed the WGRT/USDT pair.
· On September 2, WaykiChain Strategic Analyst Jing Tao gave the speech “WGRT Dragon, Fly, Tiger, and Leap: Community Governance Upstart” to the MXC community and distributed 3 gold bars to the event participants.
· On September 7, WaykiChain Strategy Analyst Jing Tao attended [This Is Coin Coffee] live DeFi contest co-sponsored by Coinka, fogwu.com, and tuoniaox.com. WEDEX founder & CEO, Loopring co-founder Chen Xiaoliang and ChainNews Research Director Pan Zhixiong joined the event.
· On September 9, Gate.io selected WaykiChain governance token WGRT for the Listing Vote. Each voter had a chance to share an airdrop of 420,875.43 WGRT. WGRT passed the voting with 53,293,775 votes and was successfully listed on Gate.io.
· On September 10, WGRT/USDT trading pair and WGRT withdrawals opened on Gate.io.
· On September 10, WaykiChain released WaykiChain Governance Token WGRT Information and Addresses. The team announced that before July 1, 2021, WGRT circulating supply will be strictly controlled at 10% of the total supply, or 2.1 billion.
· On September 9 to 11, WaykiChain was invited to IoT World China & 5G China along with 400+ exhibitors including Huawei, Baidu, and Tencent. WaykiChain demonstrated the integrated public chain DeFi ecosystem that will help China’s digital construction.
· On September 11, WaykiChain Strategy Analyst Jing Tao was invited to the Bepal community and shared the speech “WaykiChain Governance Token WGRT: Accumulation and Breakout”. WaykiChain airdropped 3,000 WGRT and cash red envelopes to the Bepal community members.
· On September 12, WaykiChain Technology & Development Manager Yuanhang Xiao and Strategy Analyst Jing Tao introduced [New WaykiChain DeFi Product: Decentralized Synthetic Asset Issuance Protocol Wayki-X] in the official WaykiChain yizhibo account. During the live broadcast, WaykiChain distributed pure gold bars and branded gifts to lucky users.
· On September 13, WaykiChain co-founder & CEO Gordon Gao and Overseas Director Qiyuan Mei shared the speech “WaykiChain Opens the Era of Integrated DeFi Public Chains” in the Gate.io live broadcast room. Gate.io CPO Jiuer was the broadcast host. The guests explained WaykiChain’s DeFi strategy and revealed the launch of Yield Farming.
· On September 15, WaykiChain CEO Gordon Gao and BTC38 co-founder Tianwei Huang held the live stream titled “Eight Questions to Explain DeFi Trends and Opportunities” in yizhibo. The hosts analyzed the status and trends of DeFi, discussed DeFi deployment by public chains and exchanges, and new opportunities in synthetic asset trading. WaykiChain distributed pure gold bars and branded gifts to lucky viewers of the stream.
· On September 16, WaykiChain Strategy Analyst Jing Tao shared the speech titled “WaykiChain’s Integrated DeFi Ecosystem Layout” as the guest of btcmoney.cc.
· On September 18, Bying community invited WaykiChain Strategy Analyst Jing Tao to share the speech “New DeFi Opportunity: Phoenix Yield Farming”. WaykiChain held a WICC airdrop for Bying community members.
· On September 18, WaykiChain published the article “No Pre-mining, ICO, or Reserve! WaykiChain Launches Dual-pool Phoenix Yield Farming”.
· On September 19, WaykiChain published the article “Chapter 1. The Financial Innovation of Blockchain Reformation. The Origin, Logic, and Value of WaykiChain ROG” introducing the background of ROG, the operation mechanism of the decentralized synthetic asset system Wayki-X, and the value foundation of ROG in detail.
· On September 23, “No Pre-mining, ICO, or Reserve! WaykiChain ROG Genesis Farming and Early Release Guide” was released across Chinese media.
· On September 24, WaykiChain CEO Gordon Gao, CTO Richard Chen, and CPO Xi Zhang held a joint live stream on yizhibo explaining the future planning of WaykiChain decentralized synthetic asset issuance protocol Wayki-X, ROG, and WaykiChain DeFi in terms of business model, technology, and products. WaykiChain distributed 1 pure gold bar and 6 branded gifts to the lucky stream viewers.
· On September 24, Gate.io and WaykiChain launched the WGRT Investment Competition. The prizes are a BMW G 310 R motorcycle, a 13” MacBook Pro, a 10.2” iPad, 17 pure gold bars and 99,000 WGRT.
· On September 25, various Chinese media released “Wayki-X 101: WaykiChain Decentralized Synthetic Asset Protocol” introducing the functions and mechanism of the decentralized synthetic asset issuance protocol Wayki-X and the value of its token ROG in detail.
· On September 25, WaykiChain launched the “Looking for the Genesis Prophet” community event. The winners received 10 branded gifts.
· On September 25, WaykiChain ROG Genesis Yield Farming launched. WICC and WGRT pool quotas (5 million and 25 million, respectively) were full within just one hour.
· On September 25, WaykiChain reached ecosystem partnership with AEX. AEX became the first platform to join ROG Ecosystem Yield Farming.
· On September 25, WaykiChain partnered with Bying wallet. ROG Genesis Yield Farming is available in Bying wallet.
· On September 26, ROG, the main token of WaykiChain’s decentralized synthetic asset issuance protocol Wayki-X, was listed on AEX. ROG/USDT trading pair is available.
· On September 26, WaykiChain CEO Gordon Gao gave lectures “DeFi Financial Principles and Commercial Applications” and “DeFi Industry Panoramic Scan” at The First Offline Practical Training Camp of Hash Power University, Shanghai Station. Participants included Ontology founder Jun Li, Chainlink Labs — China Head Philip Fei, Digital Renaissance Foundation Managing Director Cao Yin, and Waterdrip Capital founding partner Zheng Yushan.
· On September 28, WaykiChain co-founder and CEO Gordon Gao was a guest at Hash Power Knowledge Base Private Meeting, Shenzhen Station where he shared the speech titled “Feasible Ways of DeFi Application Popularization”. Other guests included Ontology founder Jun Li, DeBank founder and CEO Tang Hongbo, and Huobi Research Chief Technical Researcher Tianyuan Ma.
submitted by Waykichain to WICCProject [link] [comments]

[ Bitcoin ] Technical: Taproot: Why Activate?

Topic originally posted in Bitcoin by almkglor [link]
This is a follow-up on https://old.reddit.com/Bitcoin/comments/hqzp14/technical_the_path_to_taproot_activation/
Taproot! Everybody wants it!! But... you might ask yourself: sure, everybody else wants it, but why would I, sovereign Bitcoin HODLer, want it? Surely I can be better than everybody else because I swapped XXX fiat for Bitcoin unlike all those nocoiners?
And it is important for you to know the reasons why you, o sovereign Bitcoiner, would want Taproot activated. After all, your nodes (or the nodes your wallets use, which if you are SPV, you hopefully can pester to your wallet vendoimplementor about) need to be upgraded in order for Taproot activation to actually succeed instead of becoming a hot sticky mess.
First, let's consider some principles of Bitcoin.
I'm sure most of us here would agree that the above are very important principles of Bitcoin and that these are principles we would not be willing to remove. If anything, we would want those principles strengthened (especially the last one, financial privacy, which current Bitcoin is only sporadically strong with: you can get privacy, it just requires effort to do so).
So, how does Taproot affect those principles?

Taproot and Your /Coins

Most HODLers probably HODL their coins in singlesig addresses. Sadly, switching to Taproot would do very little for you (it gives a mild discount at spend time, at the cost of a mild increase in fee at receive time (paid by whoever sends to you, so if it's a self-send from a P2PKH or bech32 address, you pay for this); mostly a wash).
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash, so the Taproot output spends 12 bytes more; spending from a P2WPKH requires revealing a 32-byte public key later, which is not needed with Taproot, and Taproot signatures are about 9 bytes smaller than P2WPKH signatures, but the 32 bytes plus 9 bytes is divided by 4 because of the witness discount, so it saves about 11 bytes; mostly a wash, it increases blockweight by about 1 virtual byte, 4 weight for each Taproot-output-input, compared to P2WPKH-output-input).
However, as your HODLings grow in value, you might start wondering if multisignature k-of-n setups might be better for the security of your savings. And it is in multisignature that Taproot starts to give benefits!
Taproot switches to using Schnorr signing scheme. Schnorr makes key aggregation -- constructing a single public key from multiple public keys -- almost as trivial as adding numbers together. "Almost" because it involves some fairly advanced math instead of simple boring number adding, but hey when was the last time you added up your grocery list prices by hand huh?
With current P2SH and P2WSH multisignature schemes, if you have a 2-of-3 setup, then to spend, you need to provide two different signatures from two different public keys. With Taproot, you can create, using special moon math, a single public key that represents your 2-of-3 setup. Then you just put two of your devices together, have them communicate to each other (this can be done airgapped, in theory, by sending QR codes: the software to do this is not even being built yet, but that's because Taproot hasn't activated yet!), and they will make a single signature to authorize any spend from your 2-of-3 address. That's 73 witness bytes -- 18.25 virtual bytes -- of signatures you save!
And if you decide that your current setup with 1-of-1 P2PKH / P2WPKH addresses is just fine as-is: well, that's the whole point of a softfork: backwards-compatibility; you can receive from Taproot users just fine, and once your wallet is updated for Taproot-sending support, you can send to Taproot users just fine as well!
(P2WPKH and P2WSH -- SegWit v0 -- addresses start with bc1q; Taproot -- SegWit v1 --- addresses start with bc1p, in case you wanted to know the difference; in bech32 q is 0, p is 1)
Now how about HODLers who keep all, or some, of their coins on custodial services? Well, any custodial service worth its salt would be doing at least 2-of-3, or probably something even bigger, like 11-of-15. So your custodial service, if it switched to using Taproot internally, could save a lot more (imagine an 11-of-15 getting reduced from 11 signatures to just 1!), which --- we can only hope! --- should translate to lower fees and better customer service from your custodial service!
So I think we can say, very accurately, that the Bitcoin principle --- that YOU are in control of your money --- can only be helped by Taproot (if you are doing multisignature), and, because P2PKH and P2WPKH remain validly-usable addresses in a Taproot future, will not be harmed by Taproot. Its benefit to this principle might be small (it mostly only benefits multisignature users) but since it has no drawbacks with this (i.e. singlesig users can continue to use P2WPKH and P2PKH still) this is still a nice, tidy win!
(even singlesig users get a minor benefit, in that multisig users will now reduce their blockchain space footprint, so that fees can be kept low for everybody; so for example even if you have your single set of private keys engraved on titanium plates sealed in an airtight box stored in a safe buried in a desert protected by angry nomads riding giant sandworms because you're the frickin' Kwisatz Haderach, you still gain some benefit from Taproot)
And here's the important part: if P2PKH/P2WPKH is working perfectly fine with you and you decide to never use Taproot yourself, Taproot will not affect you detrimentally. First do no harm!

Taproot and Your Contracts

No one is an island, no one lives alone. Give and you shall receive. You know: by trading with other people, you can gain expertise in some obscure little necessity of the world (and greatly increase your productivity in that little field), and then trade the products of your expertise for necessities other people have created, all of you thereby gaining gains from trade.
So, contracts, which are basically enforceable agreements that facilitate trading with people who you do not personally know and therefore might not trust.
Let's start with a simple example. You want to buy some gewgaws from somebody. But you don't know them personally. The seller wants the money, you want their gewgaws, but because of the lack of trust (you don't know them!! what if they're scammers??) neither of you can benefit from gains from trade.
However, suppose both of you know of some entity that both of you trust. That entity can act as a trusted escrow. The entity provides you security: this enables the trade, allowing both of you to get gains from trade.
In Bitcoin-land, this can be implemented as a 2-of-3 multisignature. The three signatories in the multisgnature would be you, the gewgaw seller, and the escrow. You put the payment for the gewgaws into this 2-of-3 multisignature address.
Now, suppose it turns out neither of you are scammers (whaaaat!). You receive the gewgaws just fine and you're willing to pay up for them. Then you and the gewgaw seller just sign a transaction --- you and the gewgaw seller are 2, sufficient to trigger the 2-of-3 --- that spends from the 2-of-3 address to a singlesig the gewgaw seller wants (or whatever address the gewgaw seller wants).
But suppose some problem arises. The seller gave you gawgews instead of gewgaws. Or you decided to keep the gewgaws but not sign the transaction to release the funds to the seller. In either case, the escrow is notified, and if it can sign with you to refund the funds back to you (if the seller was a scammer) or it can sign with the seller to forward the funds to the seller (if you were a scammer).
Taproot helps with this: like mentioned above, it allows multisignature setups to produce only one signature, reducing blockchain space usage, and thus making contracts --- which require multiple people, by definition, you don't make contracts with yourself --- is made cheaper (which we hope enables more of these setups to happen for more gains from trade for everyone, also, moon and lambos).
(technology-wise, it's easier to make an n-of-n than a k-of-n, making a k-of-n would require a complex setup involving a long ritual with many communication rounds between the n participants, but an n-of-n can be done trivially with some moon math. You can, however, make what is effectively a 2-of-3 by using a three-branch SCRIPT: either 2-of-2 of you and seller, OR 2-of-2 of you and escrow, OR 2-of-2 of escrow and seller. Fortunately, Taproot adds a facility to embed a SCRIPT inside a public key, so you can have a 2-of-2 Taprooted address (between you and seller) with a SCRIPT branch that can instead be spent with 2-of-2 (you + escrow) OR 2-of-2 (seller + escrow), which implements the three-branched SCRIPT above. If neither of you are scammers (hopefully the common case) then you both sign using your keys and never have to contact the escrow, since you are just using the escrow public key without coordinating with them (because n-of-n is trivial but k-of-n requires setup with communication rounds), so in the "best case" where both of you are honest traders, you also get a privacy boost, in that the escrow never learns you have been trading on gewgaws, I mean ewww, gawgews are much better than gewgaws and therefore I now judge you for being a gewgaw enthusiast, you filthy gewgawer).

Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

Now suppose you want to buy some data instead of things. For example, maybe you have some closed-source software in trial mode installed, and want to pay the developer for the full version. You want to pay for an activation code.
This can be done, today, by using an HTLC. The developer tells you the hash of the activation code. You pay to an HTLC, paying out to the developer if it reveals the preimage (the activation code), or refunding the money back to you after a pre-agreed timeout. If the developer claims the funds, it has to reveal the preimage, which is the activation code, and you can now activate your software. If the developer does not claim the funds by the timeout, you get refunded.
And you can do that, with HTLCs, today.
Of course, HTLCs do have problems:
Fortunately, with Schnorr (which is enabled by Taproot), we can now use the Scriptless Script constuction by Andrew Poelstra. This Scriptless Script allows a new construction, the PTLC or Pointlocked Timelocked Contract. Instead of hashes and preimages, just replace "hash" with "point" and "preimage" with "scalar".
Or as you might know them: "point" is really "public key" and "scalar" is really a "private key". What a PTLC does is that, given a particular public key, the pointlocked branch can be spent only if the spender reveals the private key of the given private key to you.
Another nice thing with PTLCs is that they are deniable. What appears onchain is just a single 2-of-2 signature between you and the developemanufacturer. It's like a magic trick. This signature has no special watermarks, it's a perfectly normal signature (the pledge). However, from this signature, plus some datta given to you by the developemanufacturer (known as the adaptor signature) you can derive the private key of a particular public key you both agree on (the turn). Anyone scraping the blockchain will just see signatures that look just like every other signature, and as long as nobody manages to hack you and get a copy of the adaptor signature or the private key, they cannot get the private key behind the public key (point) that the pointlocked branch needs (the prestige).
(Just to be clear, the public key you are getting the private key from, is distinct from the public key that the developemanufacturer will use for its funds. The activation key is different from the developer's onchain Bitcoin key, and it is the activation key whose private key you will be learning, not the developer's/manufacturer's onchain Bitcoin key).
So:
Taproot lets PTLCs exist onchain because they enable Schnorr, which is a requirement of PTLCs / Scriptless Script.
(technology-wise, take note that Scriptless Script works only for the "pointlocked" branch of the contract; you need normal Script, or a pre-signed nLockTimed transaction, for the "timelocked" branch. Since Taproot can embed a script, you can have the Taproot pubkey be a 2-of-2 to implement the Scriptless Script "pointlocked" branch, then have a hidden script that lets you recover the funds with an OP_CHECKLOCKTIMEVERIFY after the timeout if the seller does not claim the funds.)

Quantum Quibbles!

Now if you were really paying attention, you might have noticed this parenthetical:
(technical details: a Taproot output is 1 version byte + 32 byte public key, while a P2WPKH (bech32 singlesig) output is 1 version byte + 20 byte public key hash...)
So wait, Taproot uses raw 32-byte public keys, and not public key hashes? Isn't that more quantum-vulnerable??
Well, in theory yes. In practice, they probably are not.
It's not that hashes can be broken by quantum computes --- they're still not. Instead, you have to look at how you spend from a P2WPKH/P2PKH pay-to-public-key-hash.
When you spend from a P2PKH / P2WPKH, you have to reveal the public key. Then Bitcoin hashes it and checks if this matches with the public-key-hash, and only then actually validates the signature for that public key.
So an unconfirmed transaction, floating in the mempools of nodes globally, will show, in plain sight for everyone to see, your public key.
(public keys should be public, that's why they're called public keys, LOL)
And if quantum computers are fast enough to be of concern, then they are probably fast enough that, in the several minutes to several hours from broadcast to confirmation, they have already cracked the public key that is openly broadcast with your transaction. The owner of the quantum computer can now replace your unconfirmed transaction with one that pays the funds to itself. Even if you did not opt-in RBF, miners are still incentivized to support RBF on RBF-disabled transactions.
So the extra hash is not as significant a protection against quantum computers as you might think. Instead, the extra hash-and-compare needed is just extra validation effort.
Further, if you have ever, in the past, spent from the address, then there exists already a transaction indelibly stored on the blockchain, openly displaying the public key from which quantum computers can derive the private key. So those are still vulnerable to quantum computers.
For the most part, the cryptographers behind Taproot (and Bitcoin Core) are of the opinion that quantum computers capable of cracking Bitcoin pubkeys are unlikely to appear within a decade or two.
So:
For now, the homomorphic and linear properties of elliptic curve cryptography provide a lot of benefits --- particularly the linearity property is what enables Scriptless Script and simple multisignature (i.e. multisignatures that are just 1 signature onchain). So it might be a good idea to take advantage of them now while we are still fairly safe against quantum computers. It seems likely that quantum-safe signature schemes are nonlinear (thus losing these advantages).

Summary

I Wanna Be The Taprooter!

So, do you want to help activate Taproot? Here's what you, mister sovereign Bitcoin HODLer, can do!

But I Hate Taproot!!

That's fine!

Discussions About Taproot Activation

almkglor your post has been copied because one or more comments in this topic have been removed. This copy will preserve unmoderated topic. If you would like to opt-out, please send a message using [this link].
[deleted comment]
[deleted comment]
[deleted comment]
submitted by anticensor_bot to u/anticensor_bot [link] [comments]

What is Bitcoin's Lightning Network?

Tackling bitcoin’s scalability isn’t easy, but developers Thaddeus Dryja and Joseph Poon had an idea. In a 2016 white paper, they proposed the concept of a protocol called “the lightning network” that would enable faster and cheaper transactions while not having to change the block size.
The network creates a second layer on top of the bitcoin blockchain and comprises user-generated channels. You can securely send payments back and forth without the need to trust or even know your counterparty.
Say, for instance, that I wanted to pay you for each minute of video that I watched. We would open up a lightning channel, and as the minutes rolled by, periodic payments would be made from my wallet to yours. When I’m done watching, we would close the channel to settle the net amount on the bitcoin blockchain.
Because the transactions are just between me and you and don’t need to be broadcast to the whole network, they are almost instantaneous. And because there are no miners that need incentivizing, transaction fees are low or even non-existent.
How it works
First, two parties who wish to transact with each other set up a multisignature wallet (which requires more than one signature to enact a transaction). This wallet holds some amount of bitcoin. The wallet address is then saved to the bitcoin blockchain. This sets up the payment channel.
The two parties can now conduct an unlimited number of transactions without ever touching the information stored on the blockchain. With each transaction, both parties sign an updated balance sheet to always reflect how much of the bitcoin stored in the wallet belongs to each.
Once the two parties finish transacting and close out the channel, the resulting balance is registered on the blockchain. In the event of a dispute, both parties can use the most recently signed balance sheet to recover their share of the wallet.
It is not necessary to set up a direct channel to transact on lightning – you can send payments to someone via channels with people that you are connected with. The network automatically finds the shortest route.
Development of the technology got a significant boost with the adoption of SegWit on the bitcoin and litecoin networks. Without the upgrade’s transaction malleability fix, transactions on the lightning network would have been too risky to be practical.
Without the security of the blockchain behind it, the lightning network will not be as secure, which implies that it will largely be used for small or even micro transactions which carry a lower risk. Larger transfers that require decentralized security are more likely to be done on the original layer.
Where are we now?
In March 2018, California startup Lightning Labs announced the launch of a beta version of its software, making available what investors and project leads say is the first thoroughly tested version of the tech to date. It is still early days, however – transaction sizes are limited, and the release is aimed at developers and “advanced users”. Recent research on the lightning network shows signs of increased vulnerability due to the centralization of a number of nodes in the network that control a majority of funds. Developers are continuously exploring new possibilities to enhance the privacy and efficiency of the lightning, as well as ways to incorporate other technologies such as Schnorr into the network. There’s no doubt that it’ll be some time before such system-wide updates can successfully take place.
submitted by hackatoshi to u/hackatoshi [link] [comments]

Ethereum /r/ETH FAQs

This post covers some frequently asked questions about Ethereum (ETH). All of these FAQs come directly from the ETH Docs. For a complete list of FAQs and information, please visit and review https://ethdocs.org. See the sidebar for more resources and subreddit rules.

What is Ethereum?

Ethereum is a decentralized smart contracts platform that is powered by a cryptocurrency called Ether. A good starting point to learn more about its workings would be the “What is Ethereum?” page.

Is Ethereum based on Bitcoin?

Only in the sense that it uses a blockchain, which Bitcoin pioneered. Ethereum has a separate blockchain that has several significant technical differences from Bitcoin’s blockchain. See this Ethereum StackExchange answer for a detailed explanation.

What’s the future of Ethereum?

Ethereum developers are planning a switch from a Proof-of-Work consensus model to a Proof-of-Stake consensus model in the future. They are also investigating scalability solutions and how to store secrets on the blockchain.

What’s the difference between account and “wallet contract”?

An account is your public / private key pair file that serves as your identity on the blockchain. See “account” in the glossary. A “wallet contract” is an Ethereum contract that secures your ether and identity with features such as multisignature signing and programmed deposit/withdrawal limits. A wallet contract can be easily created in the Mist Ethereum Wallet GUI client.

Can a contract pay for its execution?

No this is not possible. The gas for the execution must be provided by the address submitting the execution request.

Can a contract call another contract?

Yes, this is possible, read about interactions between contracts.

How will Ethereum deal with ever increasing blockchain size?

There are many discussions around blockchain scalability. This questioned has been partially answered on this Ethereum StackExchange post and this blog post from Vitalik Buterin.

How will Ethereum ensure the network is capable of making 10,000+ transactions-per-second?

Ethereum is planning on implementing a proof-of-stake consensus protocol change during the Serenity phase of their development roadmap. More information on the likely Ethereum PoS candidate and how it may increase transactions-per-second can be found here.
submitted by BitcoinXio to eth [link] [comments]

How to Cold Store Your Cryptocurrency for Safekeeping

According to CipherTrace (which specializes in litigation tools and services for cryptographic markets), between 2018 and 2019, the amount of theft from cryptographic wallets exceeds $2 billion. Thefts and break-ins are caused by a variety of reasons: simple incompetence in cryptographic storage, as well as by companies that provide storage services. It is not unusual for holders of crypto currency to lose access to their wallets by themselves, one of the last known cases occurred in Ireland: ,57 million dollars couldn’t be confiscated from a detained drug dealer, which were stored in bitcoins. The problem was that the wallets keys were lost.
The most secure way is a cold storage — all account data and private keys are kept offline and all transactions are manual. This storage method is great because it is fully protected from hacking and interception of data, but it is not suitable for those who make daily transfers of cryptocurrency, it is simply inconvenient.
If you compare “cold and hot” wallets, you can give a simple example: A hot wallet can be compared to a wallet that can be lost and stolen. But you can always access your funds. A cold wallet is safe, and access to it is not permanent. You can also take or put money, but it will require a special code.
In this article we will tell you about the most popular types of cold wallets and we will analyze their pros and cons.

Types of cold wallets

All cold wallets have one common thing — the data is stored offline. However, there are several types of cold wallets, which differ in the degree of protection, physical embodiment and cost of the wallet.

Desktop wallet

Desktop wallets are also known for a high level of protection, in addition to the ability to store crypto currency offline. There are so-called “light” wallets weighing less than 1 gb, and “heavy” wallets weighing more than 1 gb. Two of the desktop wallets can be distinguished:

Exodus Wallet

Multicurrency wallet. It was created in 2016 and supports more than 100 crypto currencies, since 2019 has a phone application. The wallet allows you to export private keys that are created locally, and then to upload them back. Private keys can be discounted to removable media and downloaded only when the transaction is completed. If the user decides to leave private keys on the same computer where the wallet is located, keys are securely encrypted. In order to use your wallet ,there is no need to register or to download the entire blockchain — synchronization is taking place online. In addition to wallet services Exodus Wallet provides an integrated crypto-exchange. The installation file weighs 85 mb.

Bitcoin Core

Bitcoin Core is the official Bitcoin wallet. The size of the wallet is 160 gb, but according to the developers of the company, it’s better to give it a separate winchester with the size of 500 gb. From the security viewpoint, it’s suggested to install a security code or a seed phrase, which may consist 8 words. It is also suggested to copy wallet.dat file. — private wallet key, which will allow you to restore access to your funds.

Hardware wallets

Appears like a regular flash drive with an interface (screen, control keys). This wallet can safely store information about the balance and keys, full functionality is available only when connected to a computer, but the latest models have a special button that allows you to confirm the transaction without connecting to a PC. Each time the device offers to generate a new code-password to confirm the transaction, which significantly reduces the probability of hacking. After generating the code, you need to set a mnemonic phrase (seed) — it consists of 12 or 24 words, which are not related to each other in any way. Such type of wallets has a special protection system that allows you to connect even to potentially infected PCs. The wallets themselves won’t be affected by malware.
The obvious cons of hardware wallets are the following:
  1. It is also possible to lose a device that is so small in size.
  2. A physical device can easily fail due to a variety of damages.
  3. It is not recommended to buy such wallets from “hand”, even from friends, as they can be pre-installed with malware.
As you can see, storing crypto currency with a hardware wallets is very safe and secure, however you should take care about the device. Many people who hold a large amount of crypto currency, in order to not to lose a hardware wallet, store it in a safe deposit box, depriving someone of access to it.

Popular Hardware Wallets models

Trezor One

The first hardware wallet produced in 2013 by the Czech company Satoshi Labs. The device has an OLED display with a pin code, public addresses and Seed phrases. Trezor One has won recognition from users due to its multicurrency and affordable price ($65), it is also considered one of the most secure hardware wallets.
Ledger Nano S
The wallet was released in 2016 by the French company Ledger SAS. Distinctive feature from the other wallets, is the Secure Element controller, which meets banking standards and is certified CC EAL 5+. Also, in order to work with each crypto currency you need to install a special application for this currency on the device, it is not quite convenient, however more secure. The average price of the device is $85.
KeepKey
The purse was released in 2015 in the U.S.. Distinctive feature is OLED display — 256 by 64 pixels. Due to this, you can fully see both the address of the wallet, and the seed phrase. Also, the wallet has a built-in exchange service ShapeShift — an opportunity to exchange crypto currency without entering the exchange. The average price of the device is $50.
BitBox01
Ionos Schnelly’s wallet was invented in Switzerland. In size it’s almost the most compact among all representatives of the hardware wallets. A distinctive feature is the availability of a backup — the card can be multiplied and kept in several places, by analogy with the seed-phrase. In November 2020, support for these wallets will be discontinued, but all owners will be given a 30% discount on the new model. The average price of the device is $55.
CoolWalletS
Developed in Taiwan by CoolBitX, which has long been manufacturing components for Visa and MasterCard. As well as Ledger Nano S has a security standard CC EAL 5+. This wallet works only through smartphones, connecting to them through Bluetooch. The average price of the device is $100.

Paper Wallet

In the age of technological process, plain paper has become a rather reliable method for storing cryptocurrency. With the help of special services, such as bitaddress.org, you can generate public and private keys, then writing them down on paper. You can also print keys as a QR code. To accept transactions with such a wallet, you provide the sender with a public key. To access the funds, you need to find any online wallet that supports your crypto currency. Enter your private key into your online wallet, thus integrating your funds into the system. However, you should understand that after this procedure your wallet will become “hot”.
The best of this storage method — paper wallet is free, its safety depends only from you. When storing a paper wallet to protect it from the fire, water and aging. Also, do not tell other people about where your paper wallet is hidden.
The disadvantages of this storage:
  1. If your wallet is lost, it will be impossible to restore it.
  2. Exposed to a physical damage.
  3. After sending the transaction, you will have to create a new cold wallet.

Offline transaction signature

For this storage method, you will need two PCs. The essence is that the secret keys are never in contact with the Internet, but are stored digitally. Offline transaction method is suitable for people who do not make a daily transactions and have an access to two devices. The process is below:
  1. A hot wallet is installed on a PC with the Internet. The transaction is created without entering private keys and authorization.
  2. The file with transaction is copied and transferred to the second PC without Internet, where private keys are stored.
  3. The transaction is signed offline, copied and transferred back to the PC with the Internet.
In fact, you can do it with one PC and a USB drive. The USB drive will store private keys. Also, you can create a transaction without entering private keys and authorization, after disconnecting the Internet, connect the flash drive, sign the transaction, turn on the Internet. In this case, you should take care of the antivirus system.
The disadvantages of this method:
  1. Using two PCs or a USB drive involves a lot of actions, which is time consuming.
  2. You need to back up your keys in case your PC or flash drive fails.

Multi-signature wallet

This method implies the creation of a wallet, which can be only withdrawn on condition that the transaction is verified by a predetermined number of users. The maximum number of users who can hold private keys of the wallet- is 15. It is considered as one of the most reliable ways of storage, in fact private keys are not only stored offline, but also divided between different people. Often the wallet with multisignatures is used by large crypto-companies, whose management believes that individually employees can not spend the budget. Moreover, when creating this wallet, the number of required multisignatures is minimal. For example: if one of the six keys is lost, the remaining ones will be enough for the transaction.
The disadvantages of this storage:
  1. If most of the keys are lost, access to the funds cannot be restored.
  2. You will not be able to make transactions on your own without the participation of other key holders.

Private Key Fragmentation

The private wallet key consists of 64 symbols. The key is divided into several fragments. They don’t represent anything separately, but if you put all the fragments together, you can access the funds. The key fragments are similar to multisignatures, but in this case you don’t need a multisig-wallet, and the whole process can be done manually.
The disadvantages of this method:
  1. If one fragment is lost, access to funds will be lost.
  2. The maximum level of protection can only be reached when key fragments are distributed to different places, for example: bookshelf, safe deposit box, car. If you divide the key fragments and put them in different boxes — the required level of protection will not be achieved.
When writing down key fragments on paper, protect the key from fire, water and aging.

Conclusion

Digital currencies are not physically expressed and exist only in the digital code, so cold wallets that doesn’t have an access to the Internet, protect cryptocurrencies from the most important and common problem — hacker theft. However, holders of cold wallets need to understand that the safety of a private key depends only on them. There are different ways to store private keys outside the network, but each of them makes it difficult for the user to make transactions.
Hardware wallets that have been specifically designed for this purpose are considered to be the best option for storing cryptocurrencies. With their help it is possible both to store funds off the network and to make transactions easily, without risking the safety of a private key. If you use other cold wallets, it is recommended to combine them with hot wallets. Keep the required crypto currency for daily transfers on hot wallets, and keep all other crypto on cold wallets.
Please don’t forget to follow us on Telegram and stay updated!
YOUR CRYPTO BOSS
submitted by yourcryptoboss19 to u/yourcryptoboss19 [link] [comments]

Multi-Signature Batch Transactions on EOSIO in Under 5 Minutes Blockchain - Use cases MultiSignature Wallets a brief intro Looking into Cardano ADA & Multisignature Transactions How To Use Bitcoin Multi-Signature with CoPay How To Create a Secure Multisignature Wallet and Send Multisignature Transactions

Description []. Multisignature (multisig) refers to requiring more than one key to authorize a Bitcoin transaction.It is generally used to divide up responsibility for possession of bitcoins. Standard transactions on the Bitcoin network could be called “single-signature transactions,” because transfers require only one signature — from the owner of the private key associated with the ... Multi-signature Transactions. To read more. BIP11 - M-of-N Standard Transactions; bitcoinwiki.org - Multisignature; P2P trading exchange based on Bitcoin multi-signature hodlhodl.com; Multi-signature (multisig) refers to requiring more than one key to authorize a Bitcoin transaction. Multisignature (multisig) refers to requiring multiple keys to authorize a Bitcoin transaction, rather than a single signature from one key. It has a number of applications. Dividing up responsibility for possession of bitcoins among multiple people. Avoiding a single-point of failure, making it substantially more difficult for the wallet to be compromised. M-of-N backup where loss of a single ... Multisignature (multisig) refers to requiring more than one key to authorize a Bitcoin transaction. It is generally used to divide up responsibility for possession of bitcoins. Standard transactions on the Bitcoin network could be called “single-signature transactions,” because transfers require only one signature — from the owner of the private key associated with the Bitcoin address ... What is the Multi-Signature Bitcoin Wallet? Multi-signature wallets are also commonly known as multisig wallets. They require more than one user to sign and process the transactions.

[index] [43011] [10159] [31469] [32018] [1923] [9842] [49695] [20599] [47814] [5494]

Multi-Signature Batch Transactions on EOSIO in Under 5 Minutes

This video is about a new feature on the cardano blockchain. Multisignature Transactions is feature under the Shelley project within the Cardano roadmap. This feature will allow users to have an ... The EOSIO software allows you to secure your funds through a multi-signature permission system. In this five minute video, we demonstrate some scripts we've made to automate sending out multiple ... How to use public and private keys to create a multi-signature address and then spend bitcoin from that address. Bitcoin SF Devs Multisig Transaction class with Andreas Antonopoulos covering simple transactions,simple multisig transactions and P2SH transactions in bitcoin A RAW PPT of this presentation can ... This is the first part of a more technical talk where Andreas explores Bitcoin script, with examples from the 2nd edition of Mastering Bitcoin, focusing on t...

#