Bitcoin Private Keys Directory

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]

I own no bitcoin, but you might.

If I owned a house, I would think it's mine not because I live in it, but because if somebody had a legal claim for it, I would presume that he couldn't take it from me.
There would be some kind of record of the property connected with my identity (in a limited sense, more of my issued ID and some other identificators, not my person) and some form of local municipality or other authority would easily resolve it to my benefit.
If I owned a car, it would be pretty similar situation in practice. A car can be taken from me easier than a house, because a house is harder to move. But there are authorities to help me.
If I owned a computer, I would assume it's mine because I paid for it. It is not connected to my identity, and my ownership in a dispute is provable by owning an invoice/receipt, in best case with matching serial number.
This is not the same kind of ownership as my imaginary house or a car. Let's call this ownership by proxy. Proxy in this instance being an assumption, that it would be very unprobable for someone else than me to be even aware about my dispute, not even think about how weird it would be if multiple people presented a valid receipt/invoice. But we could think of a scenario that if they did, I could lose the dispute.
I do not own any bitcoin.
I may or may not know about some privkeys that may or may not control a couple of sats.
If I had a legal dispute over those few imaginary sats, I have nothing to present to make my case favorable to me. Nobody will insure it for me, while my computer can be insured for physical damage. There is no authority to help me.
If I really controled those few sats, I would think of them as mine because I didn't steal them.
I wouldn't need any help.
But even in a dispute over my house or my car, my body and my thoughts likely won't be enough to fight for them. I'd still likely had to present some kind of plastic card, possibly also stacks of papers. Perhaps even say words and go places.
If you store your bitcoin on an exchange, or with services such as robinhood, paypal soon enough, or countless of others custodians, let me congratulate you.
You own bitcoin.
You own it almost like you own your house, almost like you own your car, maybe somewhat like you own your computer. If it wasn't at your house.
You own bitcoin, don't let anyone tell you otherwise.
But it's not yours like your thoughts and your body is yours.
I would gladly pay taxes for the house, car and a computer. My happiness with these taxes could likely be proportionate to my expectation of relevant authorities helping me in a dispute. There is no difference in which currency did I pay for these things.
I am not paying taxes for my thoughts, that would ruin me financially in a month.
But I think of the community I live in often.
tl;dr not your keys, not your shit. your shit, your choice.
submitted by own_no_bitcoin 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]

Continued censorship involving Ethereum's proposed fork to progPOW.

Our friends at Ethereum are subject to continued manipulation into forking their coin to progPOW. I decided to post this in /btc because it is the last bastion of free speech in the crypto community.
Today, after drawing attention to the sketchy history of progPOW's original proponent, my post was subjected to massive vote manipulation, and eventually deleted.
I have long suspected that progPOW favors NVIDIA miners, given the deep connections that progPOW's development team has to NVIDIA. Today, the progPOW team freely admitted that AMD miners will suffer a larger hashrate decrease compared to NVIDIA miners, so I created a poll:
Ethereum developers want to fork to ETH to progPOW [1], a proof-of-work algorithm that gives AMD GPUs a stronger hashrate penalty compared to NVIDIA [2][3]. Should Ethereum use ProgPOW for Proof-of-Work? Cast your vote with Ethereum [4].
Sources:
Below is my post that was deleted, in its entirety.
If you are curious about the CSW/Coingeek connection, scroll down.
Previous Posts
Criticism and Soft Power
I have received criticism for my posts mostly due to what people call "character attacks." I have two things to say about that:
  1. I have never engaged in any character attacks. In all cases, the character has made their modus operandi known by themselves, and I have simply shined a light on it. I don't need call people "mentally unstable gentlemen" [--source, Ohgodagirl Twitter] to get my point across.
  2. Algorithm change discussions must include economic and political introspection as well as a discussion of the proposed change's technical details. As I have stated before, progPOW would not exist without the people responsible for creating it. We must look at these people's history, character, prior accomplishments, and industry connections. The discussion must exist outside the scope of the proposed change, not inside of it.
Example: When people criticize my posts for "not looking at the technical details", they are making a mistake. If someone asked "which should we kill more often: baby seals or baby kittens?", we don't all immediately start discussing the optimal relation of kittens-per-second to seals-per-second that can be killed. No, our first reaction is "what the fuck, why should we kill anything?"
Onward
Customer complaints from people who bought cloud contracts from Kristy's previous company:
Coingeek Connection
Previously, I had promised to provide information regarding the CSW/Coingeek and Core Scientific connection.
When I was president of ImageShack.com (2003-2011), someone wanted to buy our company. When this happens, the buyer and seller usually write a purchase agreement similar to the business in which they are involved. This is done to ensure that the purchase is executed. In ImageShack's case, the buyer bought $500,000 worth of advertising from us. The logic was that ImageShack would be acquired, so they actually would pay themselves. If they didn't buy ImageShack, they would owe us $500,000.
Given the partnership between Core Scientific (Kristy's employer) and "Squire Mining" (effectively, Coingeek), I would not be surprised if Coingeek and Core Scientific made such an agreement, as well. In their case, it would likely be a hosting agreement. Since Coingeek has many ASICs, and Core Scientific is a large mining facility, I would not be surprised if those Coingeek ASICs are hosted by Core Scientific.
Individuals close to these parties can verify those claims, but I cannot share the proof at this time without revealing the identity of my sources.
Chatlog Dumps
Today, I also provide public comments from chatlog dumps showcasing Kristy Leigh Anne Minehan's deep connection to NVIDIA:
01/28/2018 - 22:34<@OhGodAGirl> Yo. ystarnaud/sling00: **I'll be meeting NV next week**. I think it's next week. The 4th! Anyway; if you have NVIDIA fixes you need for EthOS or something you want special attention on, PM me. 02/05/2018 - 06:47<@OhGodAGirl> Also I got a USB shaped like a NVIDIA GTX. It's the best thing ever. 02/05/2018 - 06:50<@OhGodAGirl> https://usercontent.irccloud-cdn.com/file/ffwT8M2j/IMG_2726.JPG 02/05/2018 - 06:50<@OhGodAGirl> Look at this adorable little shit. 
"Ah, but there's a catch. These USB drives are extremely rare—Nvidia only cranked out a couple thousand of these drives and will be giving them away to press and "influencers" at E3, along with 1,080 registered GeForce Experience members who are opted in to receive communications from Nvidia."
04/22/2018 - 20:17<@sling00> OhGodAGirl: what does ohgodanethlargement do 04/22/2018 - 20:17< cYnIxX3> https://youtu.be/2mj1nCfFvlI?t=2m16s 04/22/2018 - 20:19< cYnIxX3> sling00, about 10-25mh improvement to 1080 gpus. 04/22/2018 - 20:19< __virus__> about 40-50% improvement afaik 04/22/2018 - 20:21< OhGodAGirl> But...it's not under because NVIDIA asked me not to. 04/21/2018 - 16:51< OhGodAGirl> I have a ton of private tools for Mineority 04/21/2018 - 16:51< OhGodAGirl> Right now our Equihash kernel has a 25% advantage over Claymore. 04/21/2018 - 16:52< PL3> 25% on amds? 04/21/2018 - 16:52< OhGodAGirl> NVIDIA ;) 04/21/2018 - 16:52< PL3> you have claymore nvidia equi miner? 04/21/2018 - 16:52< OhGodAGirl> We're a NV only company. For now. 04/29/2018 - 00:53< OhGodAGirl> So uh, NVIDIA showed ETHlargement at an executive meeting 04/29/2018 - 00:53< OhGodAGirl> They thought it was hillarious 04/29/2018 - 00:53< acv_> that is awesome. 04/29/2018 - 01:22< OhGodAGirl> So many dicks on Youtube though 04/29/2018 - 01:22< OhGodAGirl> "RA RA IT'S A SCAM" 04/29/2018 - 01:22< OhGodAGirl> "RA RA IT WILL STEAL ALL YOUR PRIVKEYS" 04/29/2018 - 01:22< OhGodAGirl> "RA RA NO ONE IS EVER NICE IN THIS WORLD' 04/29/2018 - 01:22< OhGodAGirl> Well dammit I'm a nice person. =( 
submitted by ugtarmas to btc [link] [comments]

The original proponent of progPOW, Kristy Leigh Anne Minehan, appears to have scammed people with cloud contracts, criticism, and soft power, and chatlog dumps.

Previous Posts
Criticism and Soft Power
I have received criticism for my posts mostly due to what people call "character attacks." I have two things to say about that:
  1. I have never engaged in any character attacks. In all cases, the character has made their modus operandi known by themselves, and I have simply shined a light on it. I don't need call people "mentally unstable gentlemen" [--source, Ohgodagirl Twitter] to get my point across.
  2. Algorithm change discussions must include economic and political introspection as well as a discussion of the proposed change's technical details. As I have stated before, progPOW would not exist without the people responsible for creating it. We must look at these people's history, character, prior accomplishments, and industry connections. The discussion must exist outside the scope of the proposed change, not inside of it.
Example: When people criticize my posts for "not looking at the technical details", they are making a mistake. If someone asked "which should we kill more often: baby seals or baby kittens?", we don't all immediately start discussing the optimal relation of kittens-per-second to seals-per-second that can be killed. No, our first reaction is "what the fuck, why should we kill anything?"
Onward
Customer complaints from people who bought cloud contracts from Kristy's previous company:
Coingeek Connection
Previously, I had promised to provide information regarding the CSW/Coingeek and Core Scientific connection.
When I was president of ImageShack.com (2003-2011), someone wanted to buy our company. When this happens, the buyer and seller usually write a purchase agreement similar to the business in which they are involved. This is done to ensure that the purchase is executed. In ImageShack's case, the buyer bought $500,000 worth of advertising from us. The logic was that ImageShack would be acquired, so they actually would pay themselves. If they didn't buy ImageShack, they would owe us $500,000.
Given the partnership between Core Scientific (Kristy's employer) and "Squire Mining" (effectively, Coingeek), I would not be surprised if Coingeek and Core Scientific made such an agreement, as well. In their case, it would likely be a hosting agreement. Since Coingeek has many ASICs, and Core Scientific is a large mining facility, I would not be surprised if those Coingeek ASICs are hosted by Core Scientific.
Individuals close to these parties can verify those claims, but I cannot share the proof at this time without revealing the identity of my sources.
Chatlog Dumps
Today, I also provide public comments from chatlog dumps showcasing Kristy Leigh Anne Minehan's deep connection to NVIDIA:
01/28/2018 - 22:34<@OhGodAGirl> Yo. ystarnaud/sling00: **I'll be meeting NV next week**. I think it's next week. The 4th! Anyway; if you have NVIDIA fixes you need for EthOS or something you want special attention on, PM me. 02/05/2018 - 06:47<@OhGodAGirl> Also I got a USB shaped like a NVIDIA GTX. It's the best thing ever. 02/05/2018 - 06:50<@OhGodAGirl> https://usercontent.irccloud-cdn.com/file/ffwT8M2j/IMG_2726.JPG 02/05/2018 - 06:50<@OhGodAGirl> Look at this adorable little shit. 
"Ah, but there's a catch. These USB drives are extremely rare—Nvidia only cranked out a couple thousand of these drives and will be giving them away to press and "influencers" at E3, along with 1,080 registered GeForce Experience members who are opted in to receive communications from Nvidia."
04/22/2018 - 20:17<@sling00> OhGodAGirl: what does ohgodanethlargement do 04/22/2018 - 20:17< cYnIxX3> https://youtu.be/2mj1nCfFvlI?t=2m16s 04/22/2018 - 20:19< cYnIxX3> sling00, about 10-25mh improvement to 1080 gpus. 04/22/2018 - 20:19< __virus__> about 40-50% improvement afaik 04/22/2018 - 20:21< OhGodAGirl> But...it's not under because NVIDIA asked me not to. 04/21/2018 - 16:51< OhGodAGirl> I have a ton of private tools for Mineority 04/21/2018 - 16:51< OhGodAGirl> Right now our Equihash kernel has a 25% advantage over Claymore. 04/21/2018 - 16:52< PL3> 25% on amds? 04/21/2018 - 16:52< OhGodAGirl> NVIDIA ;) 04/21/2018 - 16:52< PL3> you have claymore nvidia equi miner? 04/21/2018 - 16:52< OhGodAGirl> We're a NV only company. For now. 04/29/2018 - 00:53< OhGodAGirl> So uh, NVIDIA showed ETHlargement at an executive meeting 04/29/2018 - 00:53< OhGodAGirl> They thought it was hillarious 04/29/2018 - 00:53< acv_> that is awesome. 04/29/2018 - 01:22< OhGodAGirl> So many dicks on Youtube though 04/29/2018 - 01:22< OhGodAGirl> "RA RA IT'S A SCAM" 04/29/2018 - 01:22< OhGodAGirl> "RA RA IT WILL STEAL ALL YOUR PRIVKEYS" 04/29/2018 - 01:22< OhGodAGirl> "RA RA NO ONE IS EVER NICE IN THIS WORLD' 04/29/2018 - 01:22< OhGodAGirl> Well dammit I'm a nice person. =( 
submitted by ugtarmas to ethereum [link] [comments]

Dogecoin giveaway - Comment here to receive 100 doge. Also, AMA about cryptocurrency.

Once you get tipped, click the +accept link that the bot PMs you. You can then see your balance and recent dogetipbot transaction history with +history
I will also be answering any questions you have. I'm a moderator on /dogecoin and have been studying cryptocurrency for almost 3 years. Here's a glossary of terms you may not know which may help spark some questions if you don't know what to ask:
Hash: The result of an algorithm that takes any input data of arbitrary size and produces a fixed size output. It is impossible to discover the input data based on the resulting hash.
Private keys, public keys and addresses (privkey, pubkey, addr): Put simply, a private key is just a number. A really really big number. There are 2 ^ 160 possible private keys, each is a 256 bit integer in binary. Using the ECDSA your private keys correspond to a public key. And a hash of your public key is your wallet address.
Wallet: Software which generates and stores your keys and addresses.
Transaction (tx): A piece of data that contains where coins are coming from (inputs) and where they are going to (outputs). To be valid, your wallet software must sign the transaction with the private keys of all the inputs, this is how ownership of coins is proven.
Block: A data structure used by cryptocurrency networks which contains transactions.
Blockchain: The collection of blocks in a cryptocurrency network. Each new block contains the hash of the previous block, this is required for it to be valid. In this way, blocks are chained together, each one depends on the previous one to be valid.
Proof of work (POW): The process of hashing random data to discover a hash value that is lower than a predetermined number, that number is the "difficulty".
Mining: Miners collect all the transactions on the network and assemble them into a block. Using POW, miners insert random data (called a nonce, aka number used once) into the block and hash the block. When they find a hash value below the target difficulty, the block is considered valid by the rules of the network and miners broadcast the block to the network. The transactions in the block now have 1 confirmation. Miners are also allowed to claim a block reward (sort of a finder's fee) for their work. This incentivizes miners for their work. Mining is what secures the network from attack. If you have 51% of the entire network's mining power, then you can block transactions or even reverse transactions, so it is important that mining remains as decentralized as possible.
Node: A computer that is running cryptocurrency software which generates, validates and relays transactions and blocks. They download and validate the full blockchain. Nodes can also be wallets, this software is often called "core". The network of nodes IS the cryptocurrency network, they are what make the whole thing work. The node software also contains a friendly JSON API which can be used to perform many functions, such as looking up a transaction in the blockchain history.
submitted by peoplma to RedditDayOf [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]

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]

Ledger HW.1 review and guide for use w/Electrum development version.

Review

I've been really interested in hardware solutions for private key storage. Without jumping in head first and going for the obvious choice I decided to try to least expensive option first: Ledgers HW.1. At the time or writing one can buy a HW.1 for 15€ or 0.0717 btc.
Mine took about 2 weeks to arrive in a hand written envelope from France. Inside was a piece of paper wrapped around a card the exact same dimensions as a US drivers license/credit card. The HW.1 is to be snapped out and folded over as explained on the site. Here is a pic of the device "assembled" next to the card it was snapped out of and plugged into a usb port on a laptop for perspective.
Ledger seems to have some sort of partnership with GreenAddress, but I don't like having a third party involved in my transactions. Regardless how 'ungoxable' they are bitcoin to me is about taking back full control. Therefore I chose to figure out how to use the device with Electrum. There is no guide for this on their site as the process is not simple. However I was able to achieve it and I will share my experience.
I would also like to mention here that this whole process took me about two days of sporadic work to accomplish and a few emails to support. I ended up emailing back and forth with Nicolas Bacca, Ledgers CTO. He was helpful and really quick to answer my questions.
Overall my experience has been really positive and I can honestly recommend purchasing. I'm really excited to try out some other products from Ledger.
The first step is installing electrum development version as described on their site. From a Debian distro I had problems with dependencies, but from a Debian/Ubuntu distro the process was near effortless. I won't go into details on how to install electrum as that is a guide in itself.
Regardless which client you use with the HW.1 you will still need to install the drivers.
What follows is a guide I've put together for the setup and use of the HW.1 with electrum development version on a Debian/Ubuntu os.

Guide

We'll start the electrum gui from the command line along with two options.
-v, --verbose - show debugging information -o, --offline - remain offline 
Here's is what the full command will look like:
$ electrum -v -o 
At which point the gui will open and present you with the entry panel.
Next screen you'll tell it that are making a BTChip wallet.
The next info we receive is explaining the next step. Basically telling us that we can create a completely new wallet now, or re-create one from a seed that we have backed up.
We are now presented with the option to execute creation of a new seed or re-creation of a previous one. For this guide I will choose to create a 'New Wallet'. (Note: it would be really cool if someone could explain to me how to turn a 12 word mnemonic into a 128 bit hexidecimal string as would be inputted here).
The next screen, 2/3 in the creation steps, will have us choose a security profile (2fa or pin only) and a pin. Basically 'hardened' is 2fa with the second factor being a 4 digit pin and the transaction details that the HW.1 will print to a text editor (as you will see with the seed backup in upcoming steps).
Of course we will choose 'Hardened' for the most fun... and security. Then choose a strong PIN.
Since we chose 2fa we now have to tell what type of keyboard we're using.
Next an apt warning about backing up your seed.
Last step before secure backup of seed. We will be removing the HW.1 before hitting next.
Reading this carefully, it's telling us to open a text editor (even a terminal will do), make it the active window, and plug the HW.1 back in.
Opening a text editor, placing the cursor on it, and plugging the HW.1 back in we get a printout in a few seconds in the following format.
Seed 128bitHexidecimalX 
We will remove 'Seed' from the beginning and 'X' from the end. What remains is our seed. We will save it in case of an issue with our HW.1 (lost, damaged, forgotten pin, etc.).
Note: To restore from this Master Private Seed one needs to put 'xpriv' at the beginning of the seed for electrum to recognize it. Using the seed from above if, we didn't have our HW.1 we could input the following to regenerate our private keys:
xpriv128bitHexidecimal 
After backing up our seed we can click the 'Next' button. Where we will be asked if we backed our seed up.
For some reason, I received this after confirming that I had backed my seed up.
Ok, I took the HW.1 out and put it back in. Then clicked 'Yes'. At which point we are presented with the following screen. Enter the pin and complete the setup by clicking 'Finish'.
The wallet/device are now created and we have a backup (at least one). Now we can spend some coins. Let's open our wallet with the HW.1 plugged in. This time we'll add an option for our chosen wallet path and remove the option to remain offline.
-w WALLET_PATH, --wallet=WALLET_PATH - wallet path 
The command should look like this:
$ electrum -v -w /path/to/wallet.file 
Right away we're prompted with the same two screens we saw at the beginning.
We won't see these again if we keep our wallet file, or continuously use the default_wallet created by electrum when the -w option is not used. For now we will answer these questions the same as at the beginning.
The next window will be how electrum will start from now on when this wallet is used with the HW.1.
Now we have electrum running normally. This is a good place to note that a 'watching-only' version of this wallet can be opened even without the presence of the HW.1. So you can retrieve addresses without the privkeys at any time. Funding addresses in normal, spending is a little different.
We'll create the spend from the gui the standard way.
After clicking 'Send' we are presented with this screen. READ THIS SCREEN CAREFULLY!
After careful reading we should have determined that we are to open a text editor and make it the active screen. Take out the HW.1 and put it back in. At this point the HW.1 will print into your text editor the details of your spend and your 2fa pin in the following format.
Powercycle then confirm transfer of x.xxxx BTC to 1xxbitcoinaddress fees x.xxxx BTC change x.xxxx BTC with PIN 1234 
From this output we can see how many btc are being sent to which address. In this case there is no change. The PIN in this scenario is '1234'. This is what will be entered into the 2fa challenge. DO NOT CLICK 'OK' YET.
After entering our PIN we have to remove the HW.1 and then put it back in before clicking 'OK'. After doing this we can click 'OK'. At which point we are presented with a familiar screen.
The transaction is signed and ready for the network. We can broadcast from here or save it for later.
Feedback welcomed.
submitted by mktx to coincode [link] [comments]

Announcing NetVend pre-beta for interested developers. NetVend is a virtual vending machine that runs on Bitcoin and has vast potential for many applications. More info in post.

Hey Bitcoiners. I've been working on this project ever since I heard about the idea about 4 months ago. I'm extremely excited to announce the beginning of the beta testing phase of this project. We're open to any interested developers, and will be funding as much experimentation as we can. The entire project is open-source; you can find the server code here. The service is hard to describe, so I'll be wordy. I'll bold the important parts as a sort of running TL;DR.
EDIT: There is a more technical writeup for those interested here, which also goes into the potential to harness the server for social networking purposes.
Creating a blog is easy, but anything more ambitious gets complex extremely fast. To handle money, a deep understanding of either a country's tax law (and the hassle of handling fiat currency online) or the intricacies of using Bitcoin is required. To offer a truly unique automated service, a very significant depth of computer science must be understood, and a server must be administrated and maintained. Before too long, a person with a new idea is facing extremely daunting hurdles--hurdles that most Internet users have no idea how to even begin overcoming, and would take even experienced developers a significant amount of time to conquer. How many ideas have we lost, not because the idea would fail, but because the cost of implementation is just too high?
Imagine if every internet user had easy and cheap access to a neutral server that solves many of these problems.
NetVend is a server that allows users to create arbitrary online services capable of accepting commands, processing queries, storing data, and accepting payments. The server keeps track of the Bitcoin address of each account, and commands must be signed with the corresponding private key. Each command incurs an extremely tiny fee (for example, a penny would pay for over 100,000 NetVend tips). Interfacing with the server is extremely simple using our open-source apis--we currently have one for Python, we have a javascript one nearly completed, and others are on the way. However, the server can be accessed by any program capable of signing messages and making http requests, and the source code for the apis we do have make it clear how to do this.
There are two very basic steps to begin to use the server. This article assumes use of the Python api.
First, the account must have funds. For the time being, these will be provided to anyone expressing interest in playing around with the server--just let us know which address you'll be using, and we'll send you some credit via a NetVend tip. The server also supports deposits, but we're wary about offering this too freely until the server is more fully tested. If you're interested in trying out the deposit feature, contact me and I'll help you out.
Second, import the api and call one of the two following functions:
netvend.setPrivkey(your_privkey) netvend.setSeed('some seed') 
Alternatively, you could use the api's generateCommand functions to generate any command, return this command to the user, and request that they sign it manually. You can then take that signature, and call sendSignedCommand. This is more of a hassle, but allows trustless apps to interface with the server. This article will assume that the private key is set, as this allows for simpler examples, but a few minor edits would make any application work in a trustless manner.
NetVend has three commands: Data, Tip, and Query. Each command has a fee on the order of 30 milliSatoshis (1000 mSat = 1 Satoshi). Bitcoin deposits are tracked internally and deducted with precision to the microSatoshi (1000000 uSat = 1 Satoshi) automatically and instantly.
Data:
response = netvend.commandData("Your first NetVend data upload!") success = response[0] if (success) data_id = response[1]['command_response'] #the value of data_id can now be used by anyone with the Query command to retrieve this data entry. 
Data stores arbitrary data into the database, which is public and transparent. This data can be retrieved by anyone running the Query command, and is easy to be mined, sorted, and just generally analyzed if anyone's interested enough to structure an SQL query. However, this data may also be encrypted using any encryption techniques the developer wants to use, since the server processes the command regardless of the nature of the data. This will enable clever developers to quickly and easily build apps that can dependably utilize a neutral storage space for any encrypted or non-encrypted communication the app needs to use. Note that because this is a paid service, the server has a more inherent tendency to stability that other similar free services do not. With a sufficient community, it can be assumed that a fairly recent backup of the database will always exist somewhere. This means that even in the event of the NetVend server disappearing without a trace, another incarnation of it can easily be created and restored to a very recent state. In summary, the Data command stores a piece of data, publicly, for anyone to easily find, forever.
Current Beta fee: 30 mSat.
Tip:
response = netvend.commandTip(aFriendsAddress,5000000,0) #tip aFriendsAddress 5 satoshis' worth of uSats, referencing 0 as a data entry (interpreted as no data entry) success = response[0] if (success) tip_id = response[1]['command_response'] #the value of tip_id can now be used in a manner similar to data_id, seen above. 
Tip sends internal credit from one account to another, specified by that account's Bitcoin address. These are not native Bitcoin transactions, and therefore they require some degree of trust--but are still verifiable in their own way (see the technical writeup). However, because the blockchain isn't used, some limitations of traditional Bitcoin transactions are avoided. Tips are much cheaper than Bitcoin transactions (one Bitcoin transaction cost would pay for the cost of over 1 million NetVend tips), they're virtually instantaneous, and they have the precision of 1/1000000 of a Satoshi (1 uSat). Because NetVend accounts are based on a bitcoin address and the corresponding signatures, funds can be sent to any Bitcoin user regardless of whether they currently use the service. This is because the recipient can always claim or control those funds by sending commands signed with their private key.
Additionally, these tips can reference a data entry. When used in concert with the Data command, a tip can be sent with a sort of memo that describes some request or explains the tip in some way. These tips can be constructed by users directly or by the programs developers make. In both cases, these tips can be used as a paid request for any arbitrary service, automated or not.
These tips can be viewed and analyzed by Query in the same way that data entries can.
Current Beta Fee: 30 mSat.
Query:
query = "SELECT id,data FROM data WHERE id < 10" #SELECT id,data Get the data id and the data itself #FROM data from the "data" table #WHERE id < 10 for the first 10 data entries response = netvend.commandQuery(query,2000) #send the query with a max_fee of 2000 uSats (=0.002 Satoshis) success = response[0] if (success): rows = response[1]['command_response']['rows'] for row in rows: print "data entry number " + str(row[0]) + " says " + str(row[1]) #iterates through all returned rows, and prints out the data id and data of each entry 
Query accesses any of the public database tables (accounts, commands, data, tips) with any valid SQL SELECT query. All valid SQL SELECT queries are accepted and returned, excepting timeout issues. This allows anything (again, user or script) to comb through all public data (remember, however, that data can be encrypted) with that most perceptive tool--an SQL SELECT query, either simple or complex. This is how a client must gain any information about an account or anything else on the server directly, which means that a new account must receive either a direct Bitcoin deposit or a smaller tip from another NetVend account to access any information (Again, during the beta, we will be funding as much of this activity as we can).
(To those who haven't used SQL before, an SQL SELECT statement can be either very basic (for example, get the balance of every NetVend account) or extremely complex and perceptive)
Current Beta Fee: about 1.012 mSat, but varies based on complexity of query and size of returned data. See the netvend source code for details.
I've written an example service that facilitates user-vs-user rock-paper-scissors bets, which is currently operating on address 18UjjHg7PHg5YsCdhdmFSkQhfBbt3R2RpH (EDIT: it's only a script on my computer, so it isn't actually online--although it is tested, and you can try running it yourself). It accepts tips, charges a fee, and then sends the combined ante to the winner of the bet. The ante is whatever is left over after deducting the service fee.
If you'd like to experiment with the server, you can request funds from me directly, and I'll try to accommodate as many of you as I can. Alternatively, if you use netvend.setSeed('correct horse battery staple'), there is some credit sitting in that account that you can use. You can then tip this away into another account, but please try to be conservative so others can experiment as well. I've been using the python command prompt to send simple commands to the server, and it seems like a good way for anyone to get started.
If you guys have any questions at all, I'll be more than happy to answer them or help with any trouble you're having. bardiharborow has been helping a lot with all of this, and might be around to answer questions as well.
Thanks for reading!
submitted by syriven 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]

A few doubts regarding bitcoins.

I've been trying to understand how bitcoin works and I think I've got most of it, yet I have some doubts I couldn't solve in any other way.
1) I'm using an android wallet. I've gotten a private key that (as far as I understand) should be my address. My question is: by knowing my privkey, could anyone else access my bitcoins and steal them? If yes, how do I prevent it? If not, then how can export my key to another device?
2) I've seen the network analyzer part of the client, it shows some data I'm not sure I understand. Peers are other users on the network, bitcoin translations or what?
3) Free bitcoins. I keep seeing website that offer bitcoins for nothing or for ads/survey. Are they legit or a scam? If they're legit, what are the best ones I can use for some free bitcoin fractions? Apart from mining and buying, how can I obtain bitcoin in a safe way?
4) Security. It's supposed to be a legal and safe currency. Yet how can I protect my wallet? Can I encrypt a backup with truecrypt and then get it out and use it on another device?
Thanks to whoever will shed some light on my doubts. Sorry if asking questions is not allowed.
submitted by teamfoilhat to Bitcoin [link] [comments]

Mining, transaction relaying, privkey security, and spending are distinct tasks best served by distinct apps.

It was necessary but odd that once upon a time all Bitcoin functions were wrapped into one app. But those days are gone. Nowadays, each task is most effectively addressed by apps competing in open market.
Although I personally do not mine, I run a full node, I manage private keys to serious money, and I broadcast many transactions each day. I have switched node hardware and software more than once, I have tried many approaches to privkey security, and today I use any of several transaction-sending clients, depending on the source, destination, and size of each transaction. But I no longer use the Core app at all. I would dissuade anyone from using Core.
Core is function-bloated. This was initially necessary but is no longer the case. To expect every bitcoiner to run Core is as senseless as expecting every email user to run the same SMTP server, or worse, the same email client. Hundreds of email servers and clients compete for customers. Hence, they have evolved far beyond the original prototypes. Similarly, bitcoiners will benefit from picking and choosing among competing apps for each task.
Obviously, all SMTP servers and clients must follow the same protocol. Similarly, all Bitcoin apps, whether miners, nodes, privkey managers, or broadcasters must follow the same protocol. That changes to the former protocol are managed by committee while changes to the latter are decided by miners is irrelevant to my point: App development for each task will blossom in a free market but continue to be stifled if seen as the turf of a few.
submitted by coqui33 to Bitcoin [link] [comments]

XUEZ MASTERNODE TUTORIAL - YouTube VeriBlock Wallet & Import Guide. How to import a makeaddress .dat file How to Generate a Private Key from a Bitcoin watch only ... Crypto World Evolution/CWE - Basic Overview / Trade ... Best FREE Cryptocurrency Trade Bot for ANY Bitcoin ...

The craze for many forks from the Bitcoin blockchain has resulted in people trying to claim their free coins in various ways, the easiest one is to keep a local wallet and just export your private keys from the Bitcoin wallet and import them to the wallet of the fork. As a security measure it is always advised to first move your Bitcoin (or other coins) to a new address before trying to claim ... A Bitcoin address, or simply address, is an identifier of 27-34 alphanumeric characters, beginning with the number 1, 3 or bc1, that represents a possible destination for a bitcoin payment.Addresses can be generated at no cost by any user of Bitcoin. It is also possible to get a Bitcoin address using an account at an exchange or online wallet service. 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. It combines the latest Bitcoin crypto technology, including SegWit, Core 0.15 and Bloom, together with a 10 MB block size, fast 2.5 minutes block times, a new low sized blockchain (~1 GB) and completely new tech like the smooth Diff64_15 difficulty algorithm and the GPU-mining algorithm Timetravel10. Total coin supply, the halving schedule and the actual block reward are similar to Bitcoin. Privkey Bitcoin. Privkey Bitcoin . A private key in the context of Bitcoin is a secret number that allows bitcoins to be spent. Every Bitcoin wallet contains one or more private keys, which are saved in the wallet file. The private keys are mathematically related to all Bitcoin addresses generated for the wallet.. Python Bitcoin Tools. # Pybitcointools, Python library for Bitcoin signatures ...

[index] [17564] [6244] [41343] [19996] [42499] [37757] [28412] [44229] [22910] [32648]

XUEZ MASTERNODE TUTORIAL - YouTube

COMING SOON! Email Chad: craigs1669 @ gmail dot com / +1 773- 829 -0737 It is important to understand that in an affiliate plan that offers a crypto trading ... Skip navigation Sign in. Search Currently, Bitcoin Cash is estimated to have the support of just 0.26% of total Bitcoin mining hashrate and its price on the ViaBTC futures market is approximately 12% of Bitcoin’s. How these ... https://wallet-dat-lombard.com/koshelki-bitcoin-coree/181-bitcoin-core-wallet-dat-31btc Баланс: 31 BTC Адрес с балансом ... Xuez Masternode Tutorial is a guide to installing, setting up and configuring your Windows Controller wallet and Linux Masternode wallet. You will need to do...

#