Bitcoin keys - Pastebin.com

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]

[ 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]

Upcoming Updates to Bitcoin Consensus

Price and Libra posts are shit boring, so let's focus on a technical topic for a change.
Let me start by presenting a few of the upcoming Bitcoin consensus changes.
(as these are consensus changes and not P2P changes it does not include erlay or dandelion)
Let's hope the community strongly supports these upcoming updates!

Schnorr

The sexy new signing algo.

Advantages

Disadvantages

MuSig

A provably-secure way for a group of n participants to form an aggregate pubkey and signature. Creating their group pubkey does not require their coordination other than getting individual pubkeys from each participant, but creating their signature does require all participants to be online near-simultaneously.

Advantages

Disadvantages

Taproot

Hiding a Bitcoin SCRIPT inside a pubkey, letting you sign with the pubkey without revealing the SCRIPT, or reveal the SCRIPT without signing with the pubkey.

Advantages

Disadvantages

MAST

Encode each possible branch of a Bitcoin contract separately, and only require revelation of the exact branch taken, without revealing any of the other branches. One of the Taproot script versions will be used to denote a MAST construction. If the contract has only one branch then MAST does not add more overhead.

Advantages

Disadvantages

submitted by almkglor to Bitcoin [link] [comments]

[ELI5] Why you should NEVER use a third-party wallet with another third-party service

We've all done this, right?

I know I have. Because when I started out, I was lazy and stupid. And then later when it came to shitcoins, I was lazy, stupid AND disinterested. And I paid the price. Repeatedly. Still paying it now that I'm not stupid and a little less lazy in fact.

So, what's the problem, exactly?

Never forget, ANY wallet you do not personally hold the keys to (and I would add can read with your own eyeballs) IS NOT YOUR WALLET!

What could POSSIBLY go wrong?

Service A may, and often does, generate a new wallet for you, expiring the old one. The wallet they give you may only be good for 24 hours, and they may claim to no longer have access after that. They may suspend or cancel your account if you use it as a wallet rather than the purpose it was intended for. They may get hacked. They may collapse. They may steal or lose your coins. Basically, anything can happen, because, well, its their wallet, not yours, and you can't force them to do squat. There is no government backing, guarantee, regulation or oversight.
Meanwhile, Service B may, and usually does, permanently associate the wallet address you gave them with your account (and IP, email and whatever else they may decide to... aren't cookies great?). So you can't change it when Service A goes belly up. You get to lose your money or abandon your account, usually both.
If you're lucky, you may only lose a handful of coins. But depending on the service, and how you use it, the amounts can get insane pretty quickly. I've had some $3,000 in referral income from one service for example (admittedly in cash, but that's beside the point), and if you were around really early when a Bitcoin was worthless dust, you could be talking millions now. Money matters, in any amount.

So what's the alternative?

  1. READ THE ELI5s! https://www.reddit.com/dogecoin/comments/3b3h5d/eli5_how_wallets_work/ (its right there, in the pinned topics at the top right) https://www.reddit.com/dogecoin/comments/2vc016/eli5_everything_you_didnt_know_you_needed_to_know/ https://www.reddit.com/dogecoin/comments/6e5hsq/eli5_extracting_privkeys_from_qtcore/ https://www.reddit.com/dogecoin/comments/5lxjrh/eli5_what_is_a_dogecoin/ https://www.reddit.com/dogecoin/comments/4yts6h/start_here_for_much_wallet_wow/ (that last one was stickied for over 9 months, BTW)
  2. Go to https://walletgenerator.net/ and https://coinb.in/#settings and learn to use them both. Download them so you can run them locally and offline. There is no limit to how many wallets you can own, so there is NO reason to rely on anyone other than yourself.
  3. Keep your keys safe and secure. Even if its just a text file, backed up, printed out, and stored in safe places where it won't be lost, destroyed or stolen, your record of your private keys and addresses IS your money. Treat this record like you would a bundle of cash. Because that's what it is, actually.
  4. Make Lists! Apart from your key file above, which must be kept secret, you should have a list of all your wallets AND what they're for. Again, I speak from bitter experience. Looking at one of my faucet referral links, I see ?ref=8c0963b5453b but I have absolutely NO idea what wallet I used with it, where it is, or even if its receiving payouts. If I'd written it down 3 years ago, I would know. Oh, and while you're at it, include other peoples' wallets in your lists. If you've ever sent or received coins from someone, you should have a record, because, have you ever tried to trace coins in the blockchain? I have, for an article in VeryMuchWow, and it was a huge PITA. Save yourself some grief.
submitted by Fulvio55 to dogecoin [link] [comments]

12-30 21:33 - 'That's not true. The core has more features than electrum- it just requires use of the CLI. Honestly, you shouldn't be using multi-sig in the first place if you can't figure out how to generate an address using the CLI...' by /u/Nycmdthroaway removed from /r/Bitcoin within 43-53min

'''
That's not true. The core has more features than electrum- it just requires use of the CLI. Honestly, you shouldn't be using multi-sig in the first place if you can't figure out how to generate an address using the CLI.
Open up the debug window CLI tab, type `help' and you'll see how much you can do and the information you can ascertain with the core node that you can't with electrum.
Electrum relies on the core node for all of its functionality, save their proprietary mnemonic seed backup algorithm, which is much less secure than BIP33 (which can be generated with the core; electrum literally provides you with the dictionary to carry out an attack on its addresses, and it doesn't use an EC in its cryptographic process, meaning the encryption entropy is low and the nonces are predictable).
I could order some RIPEMD-160 ASIC chips for $2/piece and have a Chinese fabricator design a PCB using some cheap 22nm SHA-256 chips and the RIPEMD chips, replace cgminer or bfgminer's computational sections with the ultra optimized vanitygen algos for brute forcing priv keys, switch out stratum for JTR-style threaded rainbow tables based on a few hundred thousand rounds of mnemonic generation using electrum's suite- along with some open source code analysis, and in a month I could create a machine that could generate and test hundreds of thousands to millions of mnemonics per second.
The only reason this hasn't been an active practice is because destroying bitcoins keypair-cryptography (or at least appearing to have done so) would send the price under a dollar in 24hours. An update would be patched within a few days and it should be a lot of hard work for nothing. But I wouldn't be surprised if this is occurring actively on a small scale, with old addresses presumed to be "lost." Even if an active address was hit, as long as it wasn't overdone, people would shrug it off as a physical compromise of their own network/machine/software, not an epidemic- but considering the frequency of exchanges getting "hacked" and the actual ease by which the attack could be carried out, I think there's an equal possibility that the security is already completely compromised.
Theoretically all mnemonic backups are inherently insecure (as is any password using dictionary words, no matter how long) but at least using ECDHE and a deterministic seed, you're actually getting a password with a strength equal to that of the sum of its characters as ASCI to BASE/56 encoded bits. Without that, you may as well have a 12 character passphrase (with the possible characters equal to the number of words in the abridged electrum dictionary.) So it's {POSSIBLE WORDS}12 for electrum vs. something closer to {(POSSIBLE WORDS60)(POSSIBLE HD-SEEDS)}256 for a BIP33 mnemonic using SecP256k ECDHE algo (assuming average number of letters in a word are 5 and HD seeds are pseudo-random.) But mnemonic seeds are still insecure even with BIP33. Use the core wallet and you get a key with true randomness using entropy from blockchain derived sources, 2 rounds of SHA-256 and a final RIPEMD-160 round with a 256-Bit secret generated in conjunction with with an extremely secure ECDHE curve=trillions upon trillions of possibilities. That not only makes a single key harder to break, it means there is a much less likely chance of someone randomly guessing secrets and testing them to see if they come out to a funded address in the whole scheme of things.
It's like if I tried to break into every Dell server. If many people were using weak passwords, and I could try a password on all of them at the same time- I'd surely crack a bunch, and make Dell look bad as a company, even though the servers were inherently fine. Keeping the network strong means making sure you do your part to save face, after all bitcoin is owned and CONTROLLED by the userbase.
As a side note, RIPEMD was only used in the public scheme along with SHA256 (despite being significantly weaker) because at the time SHA256 was the only widely implemented and highly secure algorithm- meaning it could be as widely adopted and widely mined as possible. So SHA-256 was the logical choice for the main block algorithm. There wasn't another option for the wallet address' scheme that would be secure tunneling enough and still computationally feasible and easy to integrate. So SHA-256 was most secure, but without the round of RIPEMD-160 as the deterministic round, wallets could be brute forced at the same time as mining, with the same hardware.
For the most secure, fool-proof, uncrackable wallet, here's what I do/used to do: Use the Core node to bake Segwit P2SH addresses. I don't use HD wallets period, but HD is secure enough as long as you're using a truly random secret. Remember that the secret in a BIP33 HD wallet is the master privkey, additionally, each address has it's own xpriv, which, considering the combinations possible, saving the individual xprivs makes the most sense anyway. If you plan on spending the coins soon, just secure the wallet .dat file with a strong 16+ character (A-Z,a-z,()$&@#$/?¿%÷,0-9) passphrase (this is just the wallet file pw it has nothing to do with your addresses) then just throw the wallet on a flash drive or better yet an SD card or 2 and call it a day.
For addresses you plan to put on ice for a while, concat your coins into a handful of accounts, don't store more than $1,000/address. Then using the `dumpprivkey' Core CLI command (I think that's the command, it's something like that, type help and you'll see it if I'm wrong), a text encrypting program (for good measure) and a barcode/QR code generator (all offline!), get the private keys for each address, encrypt the text with an easy to remember password (you'll be taking the keys offline, and storing physically, so no need to worry too much about that pass, it's better to just keep them physically safe), and then generate QR codes for each. Paste them all into a word doc with the corresponding (lightly) encrypted numbers you generated the QRs with. Print out a couple copies and then delete the addresses from the wallet.
Put those paper wallets somewhere safe. You could also split the key down the middle and store the 2 parts of the paper wallets in different places instead of encrypting the plaintext xprivs. So you'd need to scan both paper keys and paste the solutions together to access the coins.
That's all a bit extreme... in reality, unless you're super paranoid and storing millions, you'll be fine by keeping your coins in the core node with decent firewall and a good .dat passphrase.
BUT ELECTRUM IS NO GOOD!
'''
Context Link
Go1dfish undelete link
unreddit undelete link
Author: Nycmdthroaway
submitted by removalbot to removalbot [link] [comments]

Bitcoin is controlled by a smaller group than the FED, and it's not owned by anyone.

People should understand that Bitcoin is not owned by anyone, but controlled. In the same way as its not decentralized, but distributed. There are basically 10 people in the world who ultimately control Bitcoin right now, so it’s not decentralized. You’ve got 5-10 Bitcoin core developers who contribute updates to the code base only if they are accepted by the 5-10 mining behemoths that call the shots. In theory, anyone can “fork” the Bitcoin core if they don’t like the miners’ rules, but most people will agree that this is in-feasible at best. It doesn’t help that no one knows who controls most of the global mining power or even who invented Bitcoin. Sounds shady, and in truth, it is more of a black box than most will admit. The good news is that the block chain is universally distributed, so at least people can see the global ledger of transactions, even if they don’t appreciate that a group smaller than the Fed actually controls Bitcoin.
submitted by ProCoin to Bitcoin [link] [comments]

Dogevelopments: Neat recent projects that haven't gotten a lot of attention. I bet there's a few things here you haven't heard of.

Cross-posted to Backed.io
Amidst some recent talk of how this subreddit is slowing down, development of services on top of dogecoin is still alive and strong. No other altcoin (except maybe litecoin) has the amount of development framework, nor merchant adoption, nor community size and activity that we do. So, I've compiled a list of some neat dogecoin projects that I've seen over the past few months to prove it. I'm sure I've missed stuff myself, let me know in the comments so I can edit it in!
Cryptowoo. By DRDoGE1. The first thing I want to mention is cryptowoo. Now in the beta testing phase of development, it is primarily a plugin for wordpress which allows merchants and sellers to accept doge right on their website, confirm payment, and send confirmations to the customer and vendor alike. Here's the kicker, no third party payment processor required! This is the stuff cryptocurrency was made for, no more middleman taking a cut, just crypto directly from the customer to the merchant, all in a nice and easy to install package. It uses a combination of Block.io generated webwallets, the Chain.so API, and autowithdraws to a local wallet address to accomplish this. Which brings me to the next project:
Chain.so, Block.io, and Dogechain.info. These guys are not new, everyone has heard of them, but regardless they deserve a shoutout for the continuing fantastic work they are doing. Our own dogecoin core developer patricklodder works on these three sites. Block.io offers the best in class web wallet security, with multi-sig addresses. Multi-sig means that both block.io and you have to sign your transactions, making a web-wallet hack much harder than it used to be in the old dogevault days. Chain.so is more than an awesome blockchain explorer, it's also a powerful API. You can use their diverse and well documented set of tools to build your own applications, much like Cryptowoo has done to build that plugin.
Blockstrap.com Speaking of blockchain APIs, blockstrap is a relative newcomer in the field, running around reddit as blockstrap. They too offer a powerful suite of API commands to draw whatever information you need from the bit, lite, or doge blockchains. Their tools go a step further though, offering an HTML5 framework with prebuilt modules using their API calls to run on your website.
Coinleap. Just announced yesterday by bugnuker, this app sure does promise a lot. At its core, it's a web-wallet. But it's also an app with social features like sending to contacts, friends, and groups. It's also a platform, with yet another API, it promises to do SMS transactions, it even promises a debit card. Let's watch this one and see what actually gets delivered on it's public beta release on Feb 8. People are right to be skeptical of such big claims, but let's at least give them a chance on their launch (small amounts of coin people, it's a web-wallet).
TextDoge. Speaking of SMS transactions, this recent announcement by textdoge and ieaung is a sneak peak at a text tipping service for dogecoin. It's US only for the time being and hasn't had a full release yet, but this is one to keep an eye on for sure. Especially if we can get it to the billions of unbanked people in the world without much access to internet, but plenty of access to SMS.
SendChat. A messaging service (through the internet, not SMS) that allows tipping dogecoin to your friends you communicate with. It's also a wallet, and there is even talk of it becoming an exchange. It is the primary platform built by the devs of a different coin called SendCoin but it has also promised integrated doge. It's a crowdfunding effort, let's see where this lands.
Universal web forum tipping. Also announced yesterday by MachoSmurf, this open source PHP plugin for mysql webservers is pretty exciting to me. What it promises is any website with a sql database of users can load up this PHP script and add a few columns to the user database to give everyone a dogecoin address. The script also comes with tipping commands that those users can use to send each other doge. So yes, this is a plugin that any forum administrator can implement that will easily allow dogecoin tipping amongst the users. This could be big. Initial review of the code suggests it may have some security vulnerabilities. Let's hope they get that code up on github soon, have some security shibes audit it and get it working securely!
Toshi. Forked for doge by our own dogecoin core dev rnicoll, Toshi is an open source node built to power large scale web applications. It was developed by Coinbase as the platform their enterprise is built on top of. I'd be lying if I claimed I understood everything Toshi for dogecoin is capable of, but I'm pretty sure it opens up a world of possibilities. Think the power of the blockchain APIs mentioned previously, but instead of calling another server, all of that capability is right there on your own server.
Doughwallet. Finally, a native iOS mobile wallet with privkeys stored locally on your device for dogecoin! Based on Breadwallet for bitcoin, and ported to doge by peritus1000, this has been a long time coming. Now when your friend with an iPhone asks how to store their doge, you don't have to recommend a risky web-wallet!
Coinomi. Another mobile wallet, developed by gidze, this time for android, and this time with support for lots of coins, all with the privkeys stored locally on your device. I wanted to describe one neat thing you can do with this that shibes might not realize. Nubits are supported by this wallet, which is a newcomer crypto that has it's price pegged at $1 and backed by NuShares. Nubits can also be easily traded for doge (and vice versa) on Shapeshift.io, which is by now a well known coin switching service. Next time you feel in your gut that dogecoin price is going to crash, try trading them out for Nubits on Shapeshift, sent to your Coinomi wallet. When the price is bottomed out, trade the Nubits back for even more doge than you had before! It's a way of exchanging for USD, without having to provide personal info and bank accounts, and without having to store it in an exchange. Nubits+coinomi+shapeshift really lowers the entry bar for new traders, imo.
Koinyx. A new exchange that hasn't yet opened it's doors, CEO'd by therealmage, a director of the Litecoin Association (AKA TheMage / Andrew Vegetabile). It promises to be the first exchange regulated in the USA to offer full dogecoin trading pairs. Incorporating fiat is on its roadmap. It’s current announcement/news thread is located here on Litecointalk.org
Dogelisten. Lastly, for your enjoyment and as a thank you for reading this far, please check out dogelisten, forked from bitlisten by our own dogecoin core lead developer langer_hans. This cool app visualizes dogecoin blockchain transactions as they happen in real time, using the dogechain.info API! Such wow :)
/dogecoin - We'll try to keep the CSS and everything else much wow. BTW, there's still an easter egg that, to my knowledge, only one shibe has found.
Dogecoin is alive and strong shibes! Again, let me know in the comments what I've missed :)
submitted by peoplma to dogecoin [link] [comments]

Achieving consensus in distributed systems – that chink in the armor hasn't gone away

First a disclosure: My name is Will, I founded Novauri, and our team is building a service that will allow users to buy and sell bitcoin in the US while keeping full control of their private keys as a mandatory design element, not an option.
Please SIGN UP for our US only closed beta test in 2015 here. It's super fast, takes 20 seconds, and we'll guarantee no transaction fees for the life of your account. Plus our rates will be highly competitive. Read all about it on the website!
I don’t like marketing, I intensely hate the spam I see on the forums, so my approach is going to be to write (semi) intelligent posts and hopefully gain customers through interaction and discourse, as opposed to spamming it up with astroturf and pictures of hipsters having fun that you could be like if you used our product. Now… my thoughts.
Proof of work – a tragedy of the commons
Not very long ago a mining pool called ghash.io reached 55% bitcoin mining power. It’s widely known that POW suffers from the tragedy of the commons. Mining is SHA256x2, which makes it really simple to build coin flipping application specific integrated circuits (ASICs) that run this faster than general purpose processors. This creates an economic incentive towards centralization where miners who can access the best ASICs first have a major advantage in hashing power per dollar.
Pools, a solution to a market demand that exacerbates the problem
A second problem is a solution to an economic demand, the existence of mining “pools”. Because a block is solved only every 10 minutes, as bitcoin scales, it becomes increasingly unlikely to ever solve a block by yourself, even with substantial processing power. Mining pools allow the “little guys” to participate too and contribute their hashing power to a pool of miners. This way they receive a portion of any block solved by the pool, enabling a steady and more consistent return on their investment in hardware, facilities and electricity.
Yet while pools solve a problem, they create a second issue, the centralization of mining power by pool operators. Because the blocks are “solved” by the managing pool directly, this gives the pool the same controls and ability to act poorly as if they had the hardware themselves.
One might argue that market forces will naturally correct things if a mining pool approaches 51%, but this has been disproven in practice with ghash.io. Selfish miners using ghash.io essentially put the entire system in dire peril by letting ghash.io reach 55%. They waited for others to “go first” before switching pools. This is the very definition of “tragedy of the commons”. I would argue it was only the price of bitcoin that changed the miners’ behavior, and reviewing the charts shows that the prices did not lead the mining power concentrations at all, which also defies common wisdom, but in reality is entirely true. P2P pool is a great idea, but it has not offered the same economic benefits to miners as other privately run pools on a balance sheet. Until it does, don't look there for a long term answer. Miners are trying to make a return, and if a pool gives them an advantage, most will use that pool over P2P. Mining is not a charity.
Proof of state – lack consensus and bring monopoly issues
Some might point to proof of stake as a potential solution (POS). Put very simply, POS is where by virtue of the fact that you own X virtual currency, you have a proportionate chance to win a vote or tiebreaker when confirming transactions.
Unfortunately, POS fails to provide a disincentive to fork and suffers from the monopoly problem. Ownership carries voting rights, and there is nothing wasted (no work) by voting for both sides of a fork. There is no consensus, so POS systems are generally hybrid models where POW is used to achieve consensus of forks regardless. POS also has a monopoly problem, which are as serious as POW’s problems. So solving bitcoin's problems with POS seems like a dead end. Very smart people have tried, and so far nothing viable has materialized that is stable enough to be trusted with something as mature and valuable as bitcoin.
So… let’s relist all of the bad news!!!
Solutions thus far are myopic, influenced by personal interests or blimp sized egos (I am one to talk), and are often more academic than pragmatic. Most are just to complicated to work or to be implemented safely without years of refinement in an alt coin.
Well, is there hope? What is the practical thing to do? Should we do nothing?
I would argue that there are three problems we must solve at once, and all three problems are very much interrelated. It’s one @[email protected]@ of a puzzle. We need to:
1) Make pooled mining uneconomical
2) Figure out a way to make small scale mining cost advantageous
3) Do 1 and 2 but allow normalized returns for little guys so they can run a small business or profitable hobby, without it being a lottery ticket.
Some say that a 51% issue would not be the end because we would know very quickly who the bad actor is and could react accordingly. I’m a little more concerned. A real shakeup in the core of bitcoin would shake confidence, and could set us back years. I feel we should as a community put a much higher priority on finding a practical, viable solution. Nothing academic, nothing incredibly complicated, but something that can shift the economics of the situation and solve the three problems listed above. While we have plenty of issues around individual usability, this is, in my humble opinion, the largest remaining vulnerability in bitcoin today.
So… what to do? How do we solve all three of these problems at once? What are the possible combinations of solutions that work? Let me take a stab at it…
1) Deterring pooled mining
Let’s give more serious consideration to two-phase mining.
The idea is to keep (SHA256(SHA256(header))) and add a requirement for (SHA256(SIG(header, privkey))), requiring the block to be signed with the private key of the miner. This kills pooled mining, dead. Miners can solve SHA256x2 but the pool needs the miner’s private key to sign the block header, which would allow the miner to steal the reward, which kills pools very fast.
2) Disincentivizing centralization of mining power
2a) Small scale heat recovery systems
We need to get people thinking about small scale heat recovery systems built around mining hardware. This will allow mining activity to serve as a source of heat in cold climates, or perform work where heat is required.
One example might be liquid submersion of the asic or heatsinks couples with a pump, radiator and fan in small, modular design might be economically viable. Electric heat is used very commonly, and when powered from clean power sources like solar, geothermal, nuclear (yes, nuclear I would count in the “clean” bucket) and wind, the net is a zero emission system that heats like an electric heater but adds security to the financial system in return, and generates profit for the beneficiary.
2b) Rotating or amorphous block hashing algorithms
Another possibility is to rotate or add complexity to the hash algorithms used to solve blocks. Instead of SHA256x2, perhaps SHA256x2 is rotated with scrypt? Perhaps there are many algorithms that rotate to add even more complixity. This would at a minimum make it much harder to design ASICs, and would institute a memory requirement as well. This would at least close the gap between specialized mining operations and home hobbyists. The problem is, what miner in their right mind would go with a hard fork in this direction? This is likely unviable because of economics.
2a is probably the way to go. Is there a 2c or d?
3) Normalizing returns
The issue here is that coinbase generation in a decentralized model is like winning the lottery. Your 2a heater would be unlikely to ever solve a block in it’s lifetime.
So this last issue is even harder to solve than 2. 3 is the reason mining pools were created in the first place. How do you increase reward frequency while lowering reward to generate a more predictable return?
Or maybe we are asking the wrong question or thinking in the wrong direction or dimension? Is there a way to centralize and normalize rewards in a safer way? Could the heater's price be subsidized by the mining activity if that activity was safely hard wired in the heater's hardware to pay block rewards to the reseller or manufacturer? Could electricity rates be offset by rewards going to electricity companies as a subsidy to completely smooth out the return on investment for a bitcoin heater?
That last one is tough and would need a really great strategy to reach a critical mass.
Does anyone smarter than me have an idea? This is really the problem. It’s three interrelated issues.
In closing, sign up for our closed US beta. There are still some spots left. We're poor but talented and our hearts are in the right place. Thank you!
submitted by MrMadden to Bitcoin [link] [comments]

PSA: Don't forget to dump the fork coins

What are fork coins?

Do you know how in China they make knock-off brands? Like, instead of Adidas they might make Adibas, hoping people won't notice the difference and buy inferior products.
Now they do it with Bitcoin too. Just to clarify, some of forks have nothing to do with China, but most forks are made in China, supported by Chinese pools and are traded on Chinese exchanges.
Obviously, Bitcoin forks have none of Bitcoin's security, safety or adoption, but some people still buy them (most likely just to speculate).
Worth noting that not every coin with "Bitcoin" in the name is a hard fork/spin-off. Many of them are just alt-coins which you can't dump unless you buy them first.

Why should I dump forks?

The obvious reason is to embiggen your Bitcoin stash. Some forks give you 1-2% per Bitcoin which is kinda nice.
But it's not just good for you, dumping forks is actually good for Bitcoin: it sends a market signal that forks are worthless, thus discouraging making and trading them. Thus it helps to fight with confusion and brand dilution.
Sadly brand dilution is an actual problem now. My local financial news site which doesn't post much about Bitcoin now happily reports forks on a fairly regular basis. People who are new to Bitcoin get a wrong impression that there are now many different Bitcoins. They might wrong assume that Bitcoin isn't scarce because everybody can fork it.

List of forks

There's a rather comprehensive list here: https://iconow.net/list-of-bitcoin-forks/
The only fork which I know exists in the wild but isn't in that list is Bitcore (BTX).
Not all forks on that list are alive. As a rule of thumb, check CoinMarketCap. It's only worth trying to dump a fork if it's listed on CoinMarketCap and is traded on exchanges.

The practice of dumping

First of all, it's convenient to dump fork if you have your bitcoins concentrated in few addresses, e.g. in a cold paper wallet. Otherwise it might be too much hassle.
It's strongly advised to move your actual bitcoins to a new wallet/address before dumping fork coins. This is necessary because dumping often requires importing private keys into poorly tested and untrustworthy wallets. If you use HD wallet, you might need to create a new wallet because a non-hardened privkey will reveal your master private key, i.e. it might compromise your entire wallet, not just an address. Also note that dumping might be bad for privacy. So if you are not sure, just forget about it, 1-2% gain isn't that much.
Note that shitcoin wallets might try to steal your bitcoins, so it's better to install them on separate VM or phone. Be careful!
Here's a typical dumping process:
  1. You start with a private key of an address which used to hold your bitcoins at time of fork, but no longer does. A private key in WIF format works with all wallets, but sometimes HD wallet seed might work too.
  2. Import this private key into a wallet which supports forked coin. Sometimes you can find a mobile wallet which does that, this is more convenient than installing full-node software.
  3. Move your coins to an exchange which supports this fork.
  4. Sell them.
  5. Withdraw bitcoins to your normal wallet.

Practically dumpable forks

Not all fork coins are really worth dumping: they might be worthless, traded only on some obscure exchanges (if at all), have no working wallet, etc. Here I assembled a list of fork coins which actually can be dumped relatively easily. Enjoy!
(All prices are actual only at time of writing, obviously.)
Bitcoin Cash, BCH. This is the mother of all forks which really started this spin-off coin craze. Some people say it's even a legit coin. It's fairly easy to find information on wallets and exchanges so I won't go into details. Value per bitcoin: $1700, or 14.5% of Bitcoin value.
Bitcoin Gold, BTG. Well-established fork which is GPU-mineable. Supported wallet: Coinomi (which is quite nice) and other. Supported exchanges: many, including HitBTC, Bitfinex, OKex. These exchanges do not require ID. Note that OKex UI is pain in the ass, but they support many forks, so consider making an account. Value per bitcoin: $189 or 1.5%
Super Bitcoin, SBTC. Now we are in the weird territory. Wallet: I used a combination of Bither + Bitpie, but presumably Bitpie might work by itself. Note that Bither can only move this coin to Bitpie address. Exchange: OKex. As mentioned above, quite a PITA, but doesn't require ID. Value per bitcoin: $58, or 0.5% if you use OKex. There are exchanges with higher price, e.g. HitBTC, but they do not support deposits. I.e. people can only dump it on OKex, which is why price is lower there.
Bitcon Diamond, BCD. Wallet: Bither + Bitpie (same as Super Bitcoin). Exchange: OKex. How much you get: 1% on OKex. Note that you get 10 diamonds for 1 BTC, so $11.37 per diamond translates to $113 per bitcoin.
This ends the list of coins I already dumped, the rest is only a theory.

Forks to watch

For coins below I see no easy way to dump, but they seem to have non-negligible value so worth checking out in future.
BitcoinX, BCX. Wallet: Full node wallet from github. Exchange: It seems no exchanges support deposits (I checked gate.io and OKex). Potentially you get $270 per bitcoin because you get 10000 of these coins per 1 bitcoin.
Bitcoin God, GOD. Shit wallets and exchanges, but $70 per coin.
Bitcoin Atom, BCA. Just launched so no support, but very fancy web site promises many features, so I assume it will get a lot of marketing. Futures are traded at $76 per coin.
Lightning Bitcoin, LBTC. Some Chinese crap with no wallets, but futures are traded at $218 at some shit exchange called EXX.
Happy dumping!
submitted by killerstorm to Bitcoin [link] [comments]

02-13 05:03 - 'Be Careful! Confirmed Malware Theft from fake Electron Atom client' (self.Bitcoin) by /u/Drewski1385 removed from /r/Bitcoin within 56-66min

'''
Reposting this here. I took down the original so as not to tip off the hacker, but that seems fruitless at this point. Hope my story serves as a reminder, be careful out there.
Like many Bitcoiners, over the past few months I've been happily claiming & selling all the forked coins. I've synced half a dozen clients and light wallets before learning to use the python scripts. As you probably know, the price of these coins declines quickly as they become available on exchanges, so I was eager to get out ahead to make a bit of profit.
A few weeks ago I came across a post for "Bitcoin Atom: Electrum Wallet" on github. Awesome, another airdrop to flip! Everything looked like all the other forks, just a light wallet to install, but unfortunately it was a fake client that installed the "Man in the Middle" address changing malware. It changes the bitcoin address you copy/paste, leaving the first few characters so they look similar. For example:
Copy: 1CZinhiGqCgSQXJ6PMNh1SW3CKVy7gyjwu Paste: 1CZioyptarnQ3rdT9np2rwMwXftMX9ATT7
The Electrom Atom client didn't work, of course, so I deleted it, but the damage was done. Ironically, I was moving my BTC to a new wallet/privkey as a security measure, copy/pasting some new addresses into a spreadsheet, and I did not catch the difference in addresses. Oh boy.
Sad to say, I got wiped out. I sent all my BTC to a similar looking address, but it wasn't mine. I realized it a week later when pasting addresses "hey, these don't look right...ohh shit..." and then - gulp - opened the new wallet. The past four years, slowly building a nest egg, falling in love with the promise of Bitcoin, dreams of buying a house this year – all gone in an instant, because I got careless. Now I know how Mt. Gox must have felt, just a devastating, sickening feeling.
I don't post this here for sympathy. I made a careless mistake and am accepting the consequences. I will rebuild. If nothing else I hope this serves as a lesson to be careful when messing with unknown software. Unfortunately I had to learn the hard way. Be extremely careful, only use trusted sources, double & triple check addresses before making transactions.
Ironically enough, I'm not even sure the new address has an owner, or at least they haven't realized anything yet. Nothing has been moved, they're just sitting there. If the Gods be merciful, and the hacker happens to see this post, I kindly ask you to return the funds to the sending address. I certainly would appreciate it.
And please, if you feel compelled to reply to this post with "dumbass, you had it coming, got what you deserved, etc" - I get it, please save your breath.
'''
Be Careful! Confirmed Malware Theft from fake Electron Atom client
Go1dfish undelete link
unreddit undelete link
Author: Drewski1385
submitted by removalbot to removalbot [link] [comments]

[uncensored-r/Bitcoin] Be Careful! Confirmed Malware Theft from fake Electron Atom client

The following post by Drewski1385 is being replicated because the post has been silently removed.
The original post can be found(in censored form) at this link:
np.reddit.com/ Bitcoin/comments/7x6pyv
The original post's content was as follows:
Reposting this here. I took down the original so as not to tip off the hacker, but that seems fruitless at this point. Hope my story serves as a reminder, be careful out there.
Like many Bitcoiners, over the past few months I've been happily claiming & selling all the forked coins. I've synced half a dozen clients and light wallets before learning to use the python scripts. As you probably know, the price of these coins declines quickly as they become available on exchanges, so I was eager to get out ahead to make a bit of profit.
A few weeks ago I came across a post for "Bitcoin Atom: Electrum Wallet" on github. Awesome, another airdrop to flip! Everything looked like all the other forks, just a light wallet to install, but unfortunately it was a fake client that installed the "Man in the Middle" address changing malware. It changes the bitcoin address you copy/paste, leaving the first few characters so they look similar. For example:
Copy: 1CZinhiGqCgSQXJ6PMNh1SW3CKVy7gyjwu Paste: 1CZioyptarnQ3rdT9np2rwMwXftMX9ATT7
The Electrom Atom client didn't work, of course, so I deleted it, but the damage was done. Ironically, I was moving my BTC to a new wallet/privkey as a security measure, copy/pasting some new addresses into a spreadsheet, and I did not catch the difference in addresses. Oh boy.
Sad to say, I got wiped out. I sent all my BTC to a similar looking address, but it wasn't mine. I realized it a week later when pasting addresses "hey, these don't look right...ohh shit..." and then - gulp - opened the new wallet. The past four years, slowly building a nest egg, falling in love with the promise of Bitcoin, dreams of buying a house this year – all gone in an instant, because I got careless. Now I know how Mt. Gox must have felt, just a devastating, sickening feeling.
I don't post this here for sympathy. I made a careless mistake and am accepting the consequences. If nothing else I hope this serves as a lesson to be careful when messing with unknown software. Unfortunately I had to learn the hard way. Be extremely careful, only use trusted sources, double & triple check addresses before making transactions.
Ironically enough, I'm not even sure the new address has an owner, or at least they haven't realized anything yet. Nothing has been moved, they're just sitting there. If the Gods be merciful, and the hacker happens to see this post, I kindly ask you to return the funds to the sending address. I certainly would appreciate it.
submitted by censorship_notifier to noncensored_bitcoin [link] [comments]

Hack bitcoin private keys PRIVATE BITCOIN WEEKLY ROAD MAP PRIVATE. URGENT BITCOIN FORECAST. DUMP INCOMING?! Bitcoin Price Predictions How to Convert Massive #Bitcoin Private keys extended hex to WIF at once

Statistics. The Bitcoin Private price is currently $ 0.077870 with a 24-hour trading volume of $ 218.20 across 4 exchanges. The BTCP price is down -50.28% in the last 24 hours. Bitcoin Private reached its highest price on March 7, 2018, when it was trading at its all-time high of $ 138.09. It has a circulating supply of 4.79M BTCP. Ethereum’s price is expected to reach $331, $3,549, and $3,644 respectively while bitcoin cash’s price should climb to $414, $6,690, and $13,016 during the same time periods. In this site you can buy Bitcoin Private Keys with million in balance fresh hacked from exchnage all the wallets am offering now are big ones recently hacked from some crypto exchange binance and they are a 100% legit. Bitcoin Private price today is $0.104453 with a 24-hour trading volume of $4,309.61. BTCP price is up 8.8% in the last 24 hours. It has a circulating supply of 4.8 Million coins and a max supply of 21 Million coins. Sistemkoin is the current most active market trading it. Bitcoin Private Keys Directory. PrivateKeys.pw is the most complete Bitcoin, Bitcoin Segwit, Bitcoin Cash, Bitcoin SV, Ethereum, Litecoin, Dogecoin, Dash, Zcash, CLAM private keys explorer. Our directory contains all possible Elliptic Curve Digital Signature Algorithm (ECDSA) secp256k1 private keys in decimal, hexadecimal, raw, and WIF formats.

[index] [18083] [18814] [28591] [19991] [1628] [15936] [8587] [8759] [4893] [12342]

Hack bitcoin private keys

Bitcoin price drops 15% in a matter of minutes. What does this mean for bitcoin bulls? Is btc even bullish anymore? Here is what you can look out for on the bitcoin charts. Bitcoin (BTC) Price Prediction - Here's Where Bitcoin Is Going? - Duration: 5:30. HueFin News 979 views. 5:30 🔴You ONLY Need 2 Bitcoin To Be A MILLIONAIRE In The Next 5 Years. GET READY! BTC price is converging on the apex of 3 separate patterns at the same time. As bitcoin gets squeezed into this area, many people are now thinking that a big btc move is coming. HOW TO USE BITCOIN PRIVATE KEY GENERATOR PRICE : $420 VERSION: 2.1.5 Contact Seller Text, Telegram and WhatsApp Only : +1(409) 276 8624 REQUIREMENT Active Internet Network No Restriction on VPN ... This tool convert private keys bitcoin hexadecimal format to WIF for import on Wallet, accept massive volume, millions of keys at once. #Use : 1) Copy and Past all private keys in hexadecimal ...

Flag Counter