Missing Characters From Private Key MyCrypto Knowledge Base

Technical: Taproot: Why Activate?

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

Taproot and Your /Coins

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

Taproot and Your Contracts

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

Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

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

Quantum Quibbles!

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

Summary

I Wanna Be The Taprooter!

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

But I Hate Taproot!!

That's fine!

Discussions About Taproot Activation

submitted by almkglor to Bitcoin [link] [comments]

[ Bitcoin ] Technical: Taproot: Why Activate?

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

Taproot and Your /Coins

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

Taproot and Your Contracts

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

Taproot and Your Contracts, Part 2: Cryptographic Boogaloo

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

Quantum Quibbles!

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

Summary

I Wanna Be The Taprooter!

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

But I Hate Taproot!!

That's fine!

Discussions About Taproot Activation

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

08-13 21:45 - 'Building the Infrastructure for the Future Decentralized Financial Market, Coinbase Included HBTC.Com Debut DeFi Project - Nest Protocol' (self.Bitcoin) by /u/Nest_Fan removed from /r/Bitcoin within 24-34min

'''
As the world’s leading regulatory compliant digital asset exchange, Coinbase sets one of the most stringent requirements for digital asset listing which includes technical evaluation of projects, legal and risk analysis, market supply and demand analysis, and crypto-economics. Coinbase holds a strong reputation in the digital asset industry, and thus the “Coinbase Standard” is considered as the industry benchmark for other digital asset projects, and the market has even seen the “Coinbase effect”.
On July 25 2020, Coinbase quietly launched the pricing chart of a decentralized oracle project, NEST Protocol (NEST), into its portal. Although Coinbase has yet to announce the inclusion of the project in its evaluation list, it represents a keen interest in the DeFi sector, and particularly in the DeFi price oracle projects.
NEST Protocol is the rising star in the decentralized price oracle sector
Decentralized financial services offered by the current mainstream DeFi platforms such as MakerDAO, Compound, dYdX, etc. rely heavily on the market data provided by the oracle projects. Oracle projects act as reliable information sources to feed these price data to other DeFi Projects, connecting the price data from the centralized world to the DeFi space. As such, the price oracle is an integral part of the decentralized financial services infrastructure.
Traditionally, the price oracle collects data from different platforms and feeds these data points to the DeFi space to create data reference points to enable them to function properly. However, many problems currently exist in the DeFi space, for example, blockchain network congestion, malicious attacks, wild market fluctuations, and other factors that may cause the data given by the price oracle to deviate from the true market data. These ultimately cause users to trade on wrong information in the DeFi space and increases such transaction costs.
Decentralized finance requires a fast, secure, and reliable price oracle. The birth of the decentralized price oracle is the embodiment of the blockchain industry’s thinking, and the current market projects offering decentralized price oracle services which includes NEST Protocol, Chainlink, Band Protocol, Tellor, Witness, Oraclize, and many others.
The innovation of NEST-Price is that every data point has been agreed upon by market validators, in line with the blockchain consensus mechanism. NEST-Price synchronizes the off-chain price in a highly decentralized manner, creating real and valid price data on-chain. This is the unique differentiator between NEST-Price and other price oracles.
Compared with other price oracle projects, NEST also has other features and advantages, such as the proposed peer-to-peer quotation matching as well as its unique verifier verification structure, making NEST more resilient to malicious attacks, resulting in a more decentralized network, and it’s on-chain prices closer to the fair market price. All of this has resulted in the NEST Protocol becoming a rising star in the DeFi price oracle sector. HBTC.com selects high-quality projects to list and partnering with NEST to promote the development of DeFi ecosystem
During the selection of quality assets, exchanges like [HBTC.com]1 and Coinbase adhere to the principle of a rigorous selection of assets from different projects to enable a proper range of digital assets. At the same time, in order to solve existing pain points in the digital asset industry, which currently lacks a market-making management solution, HBTC.com also has launched its own “coin listing crowdsourcing [liquidity initiative]2 “, redefining the exchange market making model.
HBTC.com, through its coin listing strategy, effectively reduces the problem of low liquidity in the early stages of high-quality projects, ensuring the smoothness of the user experience, and achieves a win-win situation for traders, the community, and the respective trading platform. These initiatives, coupled with reliable user protection and a responsible attitude, have earned a positive reputation among users.
Since its inception, the HBTC.com exchange has been committed to the discovery of both quality and promising digital asset projects. At a time when DeFi is growing rapidly, HBTC.com has a unique perspective for the decentralized price oracle sector and has prioritized NEST as a premium partner to debut the project alongside with its global branding upgrade. In addition, HBTC.com has [100% proof of reserves]3 for traders to validate the existence of assets via the Merkle tree, which brings transparency to the extreme.
In May 2020, NEST token delivered a 883.29% of return, at its peak, after its global debut on HBTC.com. At present, HBTC Exchange addresses holding NEST token accounts in a total of 141 million, ranked first in the overall network. At the same time, the HBTC Exchange network exclusively releases NEST staking mining and data show that NEST 24-hour turnover has reached $20.4 million.
Post-listing of the NEST token, HBTC.com has also listed DeFi projects such as DF, OKS, NEST, SWTH, JST, NVT, and other DeFi projects with market potential; some projects have achieved astonishing performance in the secondary market.
HBTC.com’s path to DeFi: developing public chains to prepare for the future ecosystem breakout.
In terms of the DeFi product and ecosystem infrastructure, HBTC has deployed HBTC Chain since launched in 2018, an infrastructure designed for decentralized finance and DeFi business with patented Bluehelix decentralized cross-chain clearing and custody technology.
The HBTC Chain is the DeFi ecosystem infrastructure that the team has spent a significant amount of effort to build. It is based on decentralization and community consensus and integrates cryptography and blockchain technologies to support decentralized association-based governance capabilities at the technical level. Based on decentralized key management, combining various cryptography tools including ECDSA, commitment, zero-knowledge proof, and multi-party computation, It implements the distributed private key generation and signature for cross-chain assets among all validators. On top of that, this technology can realize light-weight and non-intrusive cross-chain asset custody. On the clearing layer, HBTC Chain employs BHPOS consensus and horizontal sharding mechanisms to achieve high-performing transaction clearing, and implementation of OpenDex protocol to help the development of the DeFi ecosystem.
In addition, with the success experience of Bluehelix Cloud SaaS and white label solutions and the HBTC Brokerage system, HBTC’s public chain also innovatively supports CEX+DEX mixed matchmaking model and OpenDex protocol and proposes the three-tier node system which consists of standard node + consensus node + core node. This structure provides HBTC public chain certain advantages in terms of performance and cross-chain transactions. Users can easily establish a DEX with OpenDex protocol at nearly zero cost, and all DEX will share the liquidity and support customized user interface and trading parameters. The trading experience can be completely comparable to centralized spot exchanges.
With the launch of its test network, it is now possible to develop various DeFi applications on the HBTC public chain, such as decentralized swap, so that private keys are not controlled by any party; no KYC, which can prevent personal information leakage; and asset security through the setting of invalidation, cancellation of transactions and other functions, cross-chain asset mappings, such as the ability to issue cross-chain cBTC or other chain tokens, fully decentralized asset mapping contracts, and 100% reserves.
Conclusion
In the past few months, the DeFi market has been extremely active, the price of DeFi tokens has been rising, and a new round of competition with the centralized exchanges has started. HBTC Chain relies on the powerful technology of Bluehelix and [HBTC.com]1 , giving all public chains the ability to interconnect, and put into both DeFi and SaaS levels. Undoubtedly, as one of the first exchanges to build the DeFi ecosystem, HBTC is leading the breakout in the current DeFi craze and has now become the first choice of users to engage with quality DeFi projects.

From BITCOIN news([[link]6 )
'''
Building the Infrastructure for the Future Decentralized Financial Market, Coinbase Included HBTC.Com Debut DeFi Project - Nest Protocol
Go1dfish undelete link
unreddit undelete link
Author: Nest_Fan
1: *btc*com/ 2: m*diu**com/hbt***ficia*/hbt*-launches-ba**liquidi*y***owd*unding-li*ti*g-plan-redefine-t*e*exch*nge-*i*tin**m*d*l***6*58f*f1d* 3: hbtc.ze**e*k*co*/hc/*n-us/a**icles/3***46287754-HBT*-10*-*ro***of*Reserve 4: hb*c.co*/ 5: n*ws.bitcoin.c*m*bu*ld*ng-t**-infr***ructur*-f*r-the*fut*re*decen**ali**d-*inanc*a*-market-coi**as*-*ncluded-h*t*-*o*-*ebut-de**-p*oject-n*st-**otocol* 6: n**s.bit*oin*com/building-th*-infrast*u*ture*for-t*e-fut****decen**a**zed**inancia*-m*rket-coinbase-**c*uded-*b*c-c***deb***defi-**oject-*est**r**ocol/]^^5
Unknown links are censored to prevent spreading illicit content.
submitted by removalbot to removalbot [link] [comments]

What unites Bitcoin, gold, and Apple shares? — TkeyNet

What unites Bitcoin, gold, and Apple shares? — TkeyNet

https://preview.redd.it/ctpbqg8jbjg51.png?width=700&format=png&auto=webp&s=f7337e416de7124455dd5d072b5ee529067af6b3
Today we will briefly review the main points that will clarify the upcoming changes in the TKEY project.
If you missed previous publications about TkeyNet, be sure to read them:

Future changes to the TKEY project

TKEY Asset

Just like the first Protocol (Core 1.0), the TKEY asset used in the TkeyNet network — there are no changes in this plan. After launching TkeyNet, you can transfer TKEY to any user on the TKEY network without any restrictions.

Quick transactions

Transactions in TkeyNet will be much faster than it was before. You can check it in practice.

TkeyConnect Module

The Protocol has a built-in TkeyConnect module, which allows you to connect various blockchains to our network to conduct transactions directly in the TkeyNet blockchain. Besides, TkeyConnect meets the international ISO and ISIN standards, which also allows you to conduct transactions with Fiat currencies and shares in the TkeyNet blockchain.
TkeyConnect creates a flexible system, giving users the ability to store and conduct transactions in any assets, be it Bitcoin, Ethereum, Litecoin or dollars, euros, etc.
https://preview.redd.it/rkroh5ulbjg51.png?width=700&format=png&auto=webp&s=c47a094c9ae3d22131bebea80badafd0dd1f8dd6

New software

If the previous software based on the Core 1.0 Protocol, after switching to TkeyNet, wallets, a blockchain search engine, and other software related to the project will be adapted to the new Protocol.

Contact information and support service

Email addresses of the support service and other departments will be transferred to other service providers and will structure in the following areas: B2B and B2C. The list of email addresses will publish after updates are complete.
B2B (business-to-business) a term that means that a company or a division of a company sells its goods/services to corporate clients, that is, to other companies. B2C (business-to-consumer) is a term that refers to the commercial relationship between an organization (Business) and a private, so-called “end” consumer.

Websites

Information about the project, the company, and its products will subdivide into two websites: tkeycoin.com and tkey.org. The purpose of this division is to simplify product navigation, improve the appearance of pages for each product and solution, and update content.
The solution is modular. The information will be structured according to sections and sites, dividing the corporate and user segments. As the products develop, the information will be updated.
Technical specifications, documentation, and a description of the Protocol and its features will appear on the official website: tkey.org. Sections will fill in gradually.

Testing and launching TkeyNet

Between July 22 and July 24, Telnet was successfully launched in testnet mode. Our team is actively testing the entire TkeyNet network and its functions. The system is tested with different scenarios, its effectiveness is checked when working with high loads, and the security of the entire system is audited. Testing of TkeyNet is an important stage of production aimed at detailed research of the program code and identification of errors in the system operation. Comprehensive testing, which is carried out by our team, is necessary to determine the level of readiness of the system for subsequent operation. Testing is based on a set of test scenarios that cover the main business operations.
The testing process contains all the life cycle activities: dynamic and static indicators. The testing process involves planning, preparing, and evaluating a software product. The purpose of testing is to determine that all meet the requirements described, as well as to show that they are suitable for the stated purposes and for detecting errors.

The Digital Asset Exchange

After launching TkeyNet — we will publish the start date of trading on the exchange. Information is available in the official notification: https://tkeycoin.com/en/news/.
https://preview.redd.it/moap4drobjg51.png?width=700&format=png&auto=webp&s=3fbb1ac32741806c8c2c59081e5e14266ac9a2fe

FAQ

Buying and selling TKEY

You can buy or sell TKEY only on the exchange and not in any other source. Private transactions are subject to high risks. Once again, we remind you that at the time of updates, any transactions with TKEY will be invalid.

Safety of funds

If you use a local wallet on your computer, make a backup copy of the wallet.dat file. If you use a TkeySpace mobile wallet, make a backup copy of the private key (backup phrase).

Transactions before updates are completed

During updates-no transactions can be made on the network, which means that any private dealing made at the time of updates will be invalid. Additionally, we ask you to refrain from any actions related to TKEY until the end of updates protocol, including starting mining, local wallets, and reinstalling them.

Epilogue

Testing of the system and its functions takes place in a stable mode without days off. The test results that will receive at the end of this week will reflect the current state of Affairs. We will get up-to-date information about the end date of updates and the planned release date of TkeyNet.
An announcement of interim test results, as well as future updates, will be published at the end of this week or early next.
submitted by tkeycoin to Tkeycoin_Official [link] [comments]

My Trezor (MEW?) account got compremised, funds were stolen

Hello ladies and gentleman,
I hope you can help me out somehow. I put it in bitcoin as well despite its ethereum but its about trezor and the btc part is involved. In mid september all my ethereum and ethereum based stuff was cleared from my MEW accounts for roughly 38k USD. Trezor couldnt help me at all and we went through all the topics and questions they had which lead to nothing exept an basic answer “your seeds got compromised in the past“, which doesn’t make any sense and I will explain why.
Lets say, Im a person with some basic tech knowledge and worked as admin and I use common sense to handle my crypto stuff which is part of my business and daily task since 2 years.I check all things again before sending. Adress, amount etc and never had any problems before.I never was on a fake page where I had to give my seed or passphrases inI dont open spam mails nor use my new laptop for something else then work, like visiting porn sites or shady stuff or use cracks etc. I didnt even found a malitous cookie after checking everything. The laptop I used was 3 months old and set up on my own with windows, firwall, antivir and anti malware stuff. Things I am doing form me and my friends since year 2000. No cracks used for programms, everything legal. I use a trezor one since then which is updated accordingly when the tool or page prompts me. I used to use chrome as my default browser (which i learned, over the past months trying to figure out what might have happened, is one oft the worst browsers).
No one has my seedsno one knows my pin to entert the trezorI dont store any of this information onlineI dont know my private keys from trezor
So what happened was that september 9 in the evening, a few hours after I sent some usdt deposit to my adress, I want to check if everything is there, login to my MEW account (online, not offline and url was correct. no addon used, just the shortcut in my browser which i safed there and always used and later checked i fit was linked to something else which wasnt), and the account was empty. Three ethereum adresses where i stored some coins, eth and usdt.
I realised that every transaction below happened while i was standing infront of my laptop (checked time happening), trezor connected cause i did some btc transaction before and chatted to customers on different chat tools like telegram or skype. Obvsly without signing any transaction at all everything was sent to other adresses. It seemed someone got the keys to those adresses before. Now, I dont even know my private keys to those adresses which are stored in trezor right? I wasnt logged into MEW before this incident for about 1.5 days. The btc part on my trezor is MUCH more valuable, but still there. After trezor couldnt help me about what happened and MEW treated me like the standard idiot who gets highjacked and then wonders why his money is gone, I went trough so many possibilities. For the most time I thought some kind of KRACK attack happened.
The only problem is trezor says they dont extract the private keys. Some gurus in this topic ( i read on reddit here) say its possible to get them from the network. Even parts are enough to encrypt the whole key after a while which would underline the timeline that it took 6 days from working in this hotel and having the unusual situation with the sending (down explained) till the accs got cleared.
The hotel incident happened the week before my accounts got cleared. I was visitting friends and coworking agents in Vietnam and stayed in a red doorz hotel in Ho Chi Minh. Using the Hotel Wifi and a nvpn.net VPN I sent some usdt funds via MEW to a befriended customer and something very stranged happened, which I never had before.I sent 4k usdt to a customer and the transaction took 13 min working working working and then failed. I’ve never had something like that. We thought it might be because of eth network or so but we never had that before, me and him sending a lot transactions every day.
Then i copied all details in again and send another 4k and somehow he recieved both!
check the screen. The one transaction processed nearly 13 min then failed. 2min later i sent a new one and without any evidence in this screen he recieved both.
https://s19.directupload.net/images/200121/27e8uyd3.jpg
later
https://s19.directupload.net/images/200121/3todak3u.png
So he sent me back the additional 4k and I shut down everything not thinking about this much anymore. Only when the accounts got cleared I was searching for any unusual happenings which could have let to this because pretty much all other “typical“ mistakes people normally do we could exclude. If somehow my seeds got compromised why only the ETH stuff? The btc parts on the trezor had much much more value. I never searched for trezor page on the web and used a link to access my wallets or to do updates. I always used the trezor bridge and made a shortcut to my wallet in my browser. For MEW i always used the same shortcut in my browser which worked pretty fine for the past years an everytime when setting the browser or pc new i checked it all before.
Because of the unusual thing which happened in Vietnam I flew back there (from philippines) prepared with tools and checking because I couldnt let go and I didnt find any other plausible cause. I even got back my old room. In this hotel there are three hotel wifi network and I remeber 100% that I used the 2nd one before cause it had the strongest signal. Anyway. I switched on wireshark and later on Fiddler, repeated all steps I used to do before. Checking if some rerouting, dns poisening or readressing or so is happening. Nothing unusual happened in the first when entering MEW (I sent some bait funds there).
In the 2nd network I used in september the trezor basically totally freaked out. He didnt let me enter MEW, I had to reenter my pin up to 5 times sometimes, It gave me error messages in MEW or it took 30 fucking seconds to enter it. Trezor writes about this:
“When you enter an invalid PIN a few times, the Trezor adds a forced waiting time between attempts.You can see this feature on the photo where the Trezor is making you wait for 15 seconds before another attempt.This countdown is then multiplied by the factor of two until you reach the 16th invalid PIN entry. After that, the device automatically wipes its memory - deleting all data from it.
The behavior of your Trezor at MEW is undoubtedly not standard or in any form pleasantly functional. Nevertheless, it also isn't anything superbly unusual or unexpected, taking poor internet connection into account.“
The thing is, the pin is 6 digits but pretty basic and I never ever entered it wrong. And I used the strongest wifi and could open webpages very easily .
As well as: “Sadly, this does not tell us anything about how your funds could be compromised. None of this could have ever exposed your private keys or made your device vulnerable in any way.
The Reddit thread you linked discusses cracking BIP-39 passphrases, which is irrelevant to your case. Cracking such passphrases assumes the person trying to break the wallet already has full possession of the recovery seed (recovery words). See, a passphrase is not your recovery seed or some additional password on your device. It is an extension of the seed, and it is also 100% useless without controlling the full seed.
The only threat you are exposed to when using Chrome is using Google itself. When googling "trezor" or "trezor wallet", you might stumble upon a phishing site which will present itself as a genuine Trezor website and force you to go through a fake "recovery" process. There you'd give out your recovery seed, which subsequently grants full access to your wallet and funds.
It's reasonable to assume that malware could guide you to such a website. To this day, we are not aware of any such incident ever happening, and even then, there are protections in place to defend you against phishing attempts.“
Basically, something I never did and all funds would haven been gone then.
I checked the 3rd network as well, and like the 1st nothing special happened. Only in the 2nd.
These are the funds and how the got cleared off the wallets.
I always show last transaction from me to the adress as well on the screens. So adress:
0x253ABB6d747a9404A007f57AaDEc1cA2b80694a1
They withdrew this:
1k USDT and the small amount ETH to send stuff
https://s19.directupload.net/images/200121/sg2lumg8.png
adress:
0x01fd43a713D8F46FF9a7Ed108da2FF74884D8400
They withdrew this:Majority of USDT and small eth for sending stuff
https://s19.directupload.net/images/200121/arycubto.png
adress:
0xf73c8C30072488d932011696436B46005504A7aeThey withdrew this:
Majority of ETh, then all coins from valueable to worthless and then some rest eth
https://s19.directupload.net/images/200121/urbgm2y5.png
https://s19.directupload.net/images/200121/rdkod59h.jpg
So this is what happened at 12th september between 16:49 and 17:15. Sick to see that all happened between 16:49 and 17:00 and its like someone came back checking and saw the 0.014 eth and withdrew it 17:15. Around 10pm i discovered what happened.
So, do you have any ideas? Questions? Feel free to guess or ask Im glad for everything which might lead to what might have happened. I somehow can’t let go off the feeling something inbetween the network, MEW and trezor ist he cause, but what do I know.
submitted by The_Wave13 to Bitcoin [link] [comments]

Technical: A Brief History of Payment Channels: from Satoshi to Lightning Network

Who cares about political tweets from some random country's president when payment channels are a much more interesting and are actually capable of carrying value?
So let's have a short history of various payment channel techs!

Generation 0: Satoshi's Broken nSequence Channels

Because Satoshi's Vision included payment channels, except his implementation sucked so hard we had to go fix it and added RBF as a by-product.
Originally, the plan for nSequence was that mempools would replace any transaction spending certain inputs with another transaction spending the same inputs, but only if the nSequence field of the replacement was larger.
Since 0xFFFFFFFF was the highest value that nSequence could get, this would mark a transaction as "final" and not replaceable on the mempool anymore.
In fact, this "nSequence channel" I will describe is the reason why we have this weird rule about nLockTime and nSequence. nLockTime actually only works if nSequence is not 0xFFFFFFFF i.e. final. If nSequence is 0xFFFFFFFF then nLockTime is ignored, because this if the "final" version of the transaction.
So what you'd do would be something like this:
  1. You go to a bar and promise the bartender to pay by the time the bar closes. Because this is the Bitcoin universe, time is measured in blockheight, so the closing time of the bar is indicated as some future blockheight.
  2. For your first drink, you'd make a transaction paying to the bartender for that drink, paying from some coins you have. The transaction has an nLockTime equal to the closing time of the bar, and a starting nSequence of 0. You hand over the transaction and the bartender hands you your drink.
  3. For your succeeding drink, you'd remake the same transaction, adding the payment for that drink to the transaction output that goes to the bartender (so that output keeps getting larger, by the amount of payment), and having an nSequence that is one higher than the previous one.
  4. Eventually you have to stop drinking. It comes down to one of two possibilities:
    • You drink until the bar closes. Since it is now the nLockTime indicated in the transaction, the bartender is able to broadcast the latest transaction and tells the bouncers to kick you out of the bar.
    • You wisely consider the state of your liver. So you re-sign the last transaction with a "final" nSequence of 0xFFFFFFFF i.e. the maximum possible value it can have. This allows the bartender to get his or her funds immediately (nLockTime is ignored if nSequence is 0xFFFFFFFF), so he or she tells the bouncers to let you out of the bar.
Now that of course is a payment channel. Individual payments (purchases of alcohol, so I guess buying coffee is not in scope for payment channels). Closing is done by creating a "final" transaction that is the sum of the individual payments. Sure there's no routing and channels are unidirectional and channels have a maximum lifetime but give Satoshi a break, he was also busy inventing Bitcoin at the time.
Now if you noticed I called this kind of payment channel "broken". This is because the mempool rules are not consensus rules, and cannot be validated (nothing about the mempool can be validated onchain: I sigh every time somebody proposes "let's make block size dependent on mempool size", mempool state cannot be validated by onchain data). Fullnodes can't see all of the transactions you signed, and then validate that the final one with the maximum nSequence is the one that actually is used onchain. So you can do the below:
  1. Become friends with Jihan Wu, because he owns >51% of the mining hashrate (he totally reorged Bitcoin to reverse the Binance hack right?).
  2. Slip Jihan Wu some of the more interesting drinks you're ordering as an incentive to cooperate with you. So say you end up ordering 100 drinks, you split it with Jihan Wu and give him 50 of the drinks.
  3. When the bar closes, Jihan Wu quickly calls his mining rig and tells them to mine the version of your transaction with nSequence 0. You know, that first one where you pay for only one drink.
  4. Because fullnodes cannot validate nSequence, they'll accept even the nSequence=0 version and confirm it, immutably adding you paying for a single alcoholic drink to the blockchain.
  5. The bartender, pissed at being cheated, takes out a shotgun from under the bar and shoots at you and Jihan Wu.
  6. Jihan Wu uses his mystical chi powers (actually the combined exhaust from all of his mining rigs) to slow down the shotgun pellets, making them hit you as softly as petals drifting in the wind.
  7. The bartender mutters some words, clothes ripping apart as he or she (hard to believe it could be a she but hey) turns into a bear, ready to maul you for cheating him or her of the payment for all the 100 drinks you ordered from him or her.
  8. Steely-eyed, you stand in front of the bartender-turned-bear, daring him to touch you. You've watched Revenant, you know Leonardo di Caprio could survive a bear mauling, and if some posh actor can survive that, you know you can too. You make a pose. "Drunken troll logic attack!"
  9. I think I got sidetracked here.
Lessons learned?

Spilman Channels

Incentive-compatible time-limited unidirectional channel; or, Satoshi's Vision, Fixed (if transaction malleability hadn't been a problem, that is).
Now, we know the bartender will turn into a bear and maul you if you try to cheat the payment channel, and now that we've revealed you're good friends with Jihan Wu, the bartender will no longer accept a payment channel scheme that lets one you cooperate with a miner to cheat the bartender.
Fortunately, Jeremy Spilman proposed a better way that would not let you cheat the bartender.
First, you and the bartender perform this ritual:
  1. You get some funds and create a transaction that pays to a 2-of-2 multisig between you and the bartender. You don't broadcast this yet: you just sign it and get its txid.
  2. You create another transaction that spends the above transaction. This transaction (the "backoff") has an nLockTime equal to the closing time of the bar, plus one block. You sign it and give this backoff transaction (but not the above transaction) to the bartender.
  3. The bartender signs the backoff and gives it back to you. It is now valid since it's spending a 2-of-2 of you and the bartender, and both of you have signed the backoff transaction.
  4. Now you broadcast the first transaction onchain. You and the bartender wait for it to be deeply confirmed, then you can start ordering.
The above is probably vaguely familiar to LN users. It's the funding process of payment channels! The first transaction, the one that pays to a 2-of-2 multisig, is the funding transaction that backs the payment channel funds.
So now you start ordering in this way:
  1. For your first drink, you create a transaction spending the funding transaction output and sending the price of the drink to the bartender, with the rest returning to you.
  2. You sign the transaction and pass it to the bartender, who serves your first drink.
  3. For your succeeding drinks, you recreate the same transaction, adding the price of the new drink to the sum that goes to the bartender and reducing the money returned to you. You sign the transaction and give it to the bartender, who serves you your next drink.
  4. At the end:
    • If the bar closing time is reached, the bartender signs the latest transaction, completing the needed 2-of-2 signatures and broadcasting this to the Bitcoin network. Since the backoff transaction is the closing time + 1, it can't get used at closing time.
    • If you decide you want to leave early because your liver is crying, you just tell the bartender to go ahead and close the channel (which the bartender can do at any time by just signing and broadcasting the latest transaction: the bartender won't do that because he or she is hoping you'll stay and drink more).
    • If you ended up just hanging around the bar and never ordering, then at closing time + 1 you broadcast the backoff transaction and get your funds back in full.
Now, even if you pass 50 drinks to Jihan Wu, you can't give him the first transaction (the one which pays for only one drink) and ask him to mine it: it's spending a 2-of-2 and the copy you have only contains your own signature. You need the bartender's signature to make it valid, but he or she sure as hell isn't going to cooperate in something that would lose him or her money, so a signature from the bartender validating old state where he or she gets paid less isn't going to happen.
So, problem solved, right? Right? Okay, let's try it. So you get your funds, put them in a funding tx, get the backoff tx, confirm the funding tx...
Once the funding transaction confirms deeply, the bartender laughs uproariously. He or she summons the bouncers, who surround you menacingly.
"I'm refusing service to you," the bartender says.
"Fine," you say. "I was leaving anyway;" You smirk. "I'll get back my money with the backoff transaction, and posting about your poor service on reddit so you get negative karma, so there!"
"Not so fast," the bartender says. His or her voice chills your bones. It looks like your exploitation of the Satoshi nSequence payment channel is still fresh in his or her mind. "Look at the txid of the funding transaction that got confirmed."
"What about it?" you ask nonchalantly, as you flip open your desktop computer and open a reputable blockchain explorer.
What you see shocks you.
"What the --- the txid is different! You--- you changed my signature?? But how? I put the only copy of my private key in a sealed envelope in a cast-iron box inside a safe buried in the Gobi desert protected by a clan of nomads who have dedicated their lives and their childrens' lives to keeping my private key safe in perpetuity!"
"Didn't you know?" the bartender asks. "The components of the signature are just very large numbers. The sign of one of the signature components can be changed, from positive to negative, or negative to positive, and the signature will remain valid. Anyone can do that, even if they don't know the private key. But because Bitcoin includes the signatures in the transaction when it's generating the txid, this little change also changes the txid." He or she chuckles. "They say they'll fix it by separating the signatures from the transaction body. They're saying that these kinds of signature malleability won't affect transaction ids anymore after they do this, but I bet I can get my good friend Jihan Wu to delay this 'SepSig' plan for a good while yet. Friendly guy, this Jihan Wu, it turns out all I had to do was slip him 51 drinks and he was willing to mine a tx with the signature signs flipped." His or her grin widens. "I'm afraid your backoff transaction won't work anymore, since it spends a txid that is not existent and will never be confirmed. So here's the deal. You pay me 99% of the funds in the funding transaction, in exchange for me signing the transaction that spends with the txid that you see onchain. Refuse, and you lose 100% of the funds and every other HODLer, including me, benefits from the reduction in coin supply. Accept, and you get to keep 1%. I lose nothing if you refuse, so I won't care if you do, but consider the difference of getting zilch vs. getting 1% of your funds." His or her eyes glow. "GENUFLECT RIGHT NOW."
Lesson learned?

CLTV-protected Spilman Channels

Using CLTV for the backoff branch.
This variation is simply Spilman channels, but with the backoff transaction replaced with a backoff branch in the SCRIPT you pay to. It only became possible after OP_CHECKLOCKTIMEVERIFY (CLTV) was enabled in 2015.
Now as we saw in the Spilman Channels discussion, transaction malleability means that any pre-signed offchain transaction can easily be invalidated by flipping the sign of the signature of the funding transaction while the funding transaction is not yet confirmed.
This can be avoided by simply putting any special requirements into an explicit branch of the Bitcoin SCRIPT. Now, the backoff branch is supposed to create a maximum lifetime for the payment channel, and prior to the introduction of OP_CHECKLOCKTIMEVERIFY this could only be done by having a pre-signed nLockTime transaction.
With CLTV, however, we can now make the branches explicit in the SCRIPT that the funding transaction pays to.
Instead of paying to a 2-of-2 in order to set up the funding transaction, you pay to a SCRIPT which is basically "2-of-2, OR this singlesig after a specified lock time".
With this, there is no backoff transaction that is pre-signed and which refers to a specific txid. Instead, you can create the backoff transaction later, using whatever txid the funding transaction ends up being confirmed under. Since the funding transaction is immutable once confirmed, it is no longer possible to change the txid afterwards.

Todd Micropayment Networks

The old hub-spoke model (that isn't how LN today actually works).
One of the more direct predecessors of the Lightning Network was the hub-spoke model discussed by Peter Todd. In this model, instead of payers directly having channels to payees, payers and payees connect to a central hub server. This allows any payer to pay any payee, using the same channel for every payee on the hub. Similarly, this allows any payee to receive from any payer, using the same channel.
Remember from the above Spilman example? When you open a channel to the bartender, you have to wait around for the funding tx to confirm. This will take an hour at best. Now consider that you have to make channels for everyone you want to pay to. That's not very scalable.
So the Todd hub-spoke model has a central "clearing house" that transport money from payers to payees. The "Moonbeam" project takes this model. Of course, this reveals to the hub who the payer and payee are, and thus the hub can potentially censor transactions. Generally, though, it was considered that a hub would more efficiently censor by just not maintaining a channel with the payer or payee that it wants to censor (since the money it owned in the channel would just be locked uselessly if the hub won't process payments to/from the censored user).
In any case, the ability of the central hub to monitor payments means that it can surveill the payer and payee, and then sell this private transactional data to third parties. This loss of privacy would be intolerable today.
Peter Todd also proposed that there might be multiple hubs that could transport funds to each other on behalf of their users, providing somewhat better privacy.
Another point of note is that at the time such networks were proposed, only unidirectional (Spilman) channels were available. Thus, while one could be a payer, or payee, you would have to use separate channels for your income versus for your spending. Worse, if you wanted to transfer money from your income channel to your spending channel, you had to close both and reshuffle the money between them, both onchain activities.

Poon-Dryja Lightning Network

Bidirectional two-participant channels.
The Poon-Dryja channel mechanism has two important properties:
Both the original Satoshi and the two Spilman variants are unidirectional: there is a payer and a payee, and if the payee wants to do a refund, or wants to pay for a different service or product the payer is providing, then they can't use the same unidirectional channel.
The Poon-Dryjam mechanism allows channels, however, to be bidirectional instead: you are not a payer or a payee on the channel, you can receive or send at any time as long as both you and the channel counterparty are online.
Further, unlike either of the Spilman variants, there is no time limit for the lifetime of a channel. Instead, you can keep the channel open for as long as you want.
Both properties, together, form a very powerful scaling property that I believe most people have not appreciated. With unidirectional channels, as mentioned before, if you both earn and spend over the same network of payment channels, you would have separate channels for earning and spending. You would then need to perform onchain operations to "reverse" the directions of your channels periodically. Secondly, since Spilman channels have a fixed lifetime, even if you never used either channel, you would have to periodically "refresh" it by closing it and reopening.
With bidirectional, indefinite-lifetime channels, you may instead open some channels when you first begin managing your own money, then close them only after your lawyers have executed your last will and testament on how the money in your channels get divided up to your heirs: that's just two onchain transactions in your entire lifetime. That is the potentially very powerful scaling property that bidirectional, indefinite-lifetime channels allow.
I won't discuss the transaction structure needed for Poon-Dryja bidirectional channels --- it's complicated and you can easily get explanations with cute graphics elsewhere.
There is a weakness of Poon-Dryja that people tend to gloss over (because it was fixed very well by RustyReddit):
Another thing I want to emphasize is that while the Lightning Network paper and many of the earlier presentations developed from the old Peter Todd hub-and-spoke model, the modern Lightning Network takes the logical conclusion of removing a strict separation between "hubs" and "spokes". Any node on the Lightning Network can very well work as a hub for any other node. Thus, while you might operate as "mostly a payer", "mostly a forwarding node", "mostly a payee", you still end up being at least partially a forwarding node ("hub") on the network, at least part of the time. This greatly reduces the problems of privacy inherent in having only a few hub nodes: forwarding nodes cannot get significantly useful data from the payments passing through them, because the distance between the payer and the payee can be so large that it would be likely that the ultimate payer and the ultimate payee could be anyone on the Lightning Network.
Lessons learned?

Future

After LN, there's also the Decker-Wattenhofer Duplex Micropayment Channels (DMC). This post is long enough as-is, LOL. But for now, it uses a novel "decrementing nSequence channel", using the new relative-timelock semantics of nSequence (not the broken one originally by Satoshi). It actually uses multiple such "decrementing nSequence" constructs, terminating in a pair of Spilman channels, one in both directions (thus "duplex"). Maybe I'll discuss it some other time.
The realization that channel constructions could actually hold more channel constructions inside them (the way the Decker-Wattenhofer puts a pair of Spilman channels inside a series of "decrementing nSequence channels") lead to the further thought behind Burchert-Decker-Wattenhofer channel factories. Basically, you could host multiple two-participant channel constructs inside a larger multiparticipant "channel" construct (i.e. host multiple channels inside a factory).
Further, we have the Decker-Russell-Osuntokun or "eltoo" construction. I'd argue that this is "nSequence done right". I'll write more about this later, because this post is long enough.
Lessons learned?
submitted by almkglor to Bitcoin [link] [comments]

NOOBS GUIDE - How not to get your bitcoin stolen on Empire Market and verify any empire site

Hi guys and gals,
I have made this guide because as some of you have probably experienced before there are tons of phishing sites that are mimicking empire market. Lots of them are very credible but steal your bitcoins. The most convincing phishing sites use a 'man in the middle' attack where it directs traffic to the original empire market site, but changes the bitcoin deposit address. People fall for this because the nature of the attack means that the users individual personal phrase is displayed correctly and everything seems to be normal but when you deposit, the coins disappear. This has led many users to falsely blame empire market and assume they are conducting an exit scam which is not true.

Firstly I would like to say to avoid this you must have a critical mindset of every empire market onion url you visit. Even if it has worked several times before. I will detail in this guide how to stop getting your money stolen and this is for educational purposes only. I do not take responsibility for anything you buy on the site. Please let me know if there is anything you would like added to the guide and I will aim to do so. I would also appreciate if everyone could upvote this and if the mods could sticky this so we can get maximum views to stop people getting scammed.

With that out of the way, I am assuming you know how to use PGP. if you don't please research how to do this before you continue, the following links may help you (if there is enough demand I will eventually make a separate tutorial on this):

http://www.bitcoinnotbombs.com/beginners-guide-to-pgp/
https://www.reddit.com/SilkRoad/comments/1qh266/guide_pgp_4_n00bz/

The critical requirements you must have before continuing:

The reason why most people get scammed is because they don't verify their links, and when they have, they use the wrong empire market public PGP key located on the phishing sites. The attackers have set this up to work with their own phishing empire market site. The real empire market PGP key has always been located on dreadditevelidot.onion:

  1. Copy dreadditevelidot.onion into Tor
  2. on the right hand side of the page you will see a link saying '/d/EmpireMarket' click on it
  3. towards the top of the page underneath where it says 'Dread' you should see a button called 'PGP' click on it.
  4. Copy the PGP public key into notepad and save it as a .txt or .asc file and import it into your chosen PGP program (i tend to use GPA as part of the GPG4WIN toolkit but others prefer to use kleopatra, each to their own it does the same job)

Once you have this key imported name it something like empire market or whatever you wish, this will be the real key that will tell you if any site you are on is genuine or not. It is published only by the creator of empire market. NEVER and I repeat NEVER use the empire market PGP public key located on any empire market url as this can be faked. Only use the one on dreadditevelidot.onion, I hope that is crystal clear.

Now in general, what you want to do next is:

  1. take a link from dark.fail e.g. dkndfkn9gfnf.onion(not real) and add '/safe' to the end of it, or alternatively click on 'verify mirror' once you land on the site.
  2. follow the prompts until you see a PGP message displayed for you, copy this into GPA or other program and click 'verify', if all is good you should see a popup saying 'valid signature' and maybe some text highlighted in green. It looks like this:
https://pasteboard.co/IkNVbsC.png
  1. If you see anything saying 'bad signature' then under no circumstances login or use the site as it is a phishing site.
https://pasteboard.co/IkNVP1l.png
  1. if the signature is good proceed to login

Now, once you are certain the site is real, you still don't want to trust it 100%. What you want to do is go to the bitcoin deposit page and click 'generate a bitcoin deposit address'. Once that is done, underneath you will see a link saying 'Get PGP signed proof of ownership', click that and go through the prompts (as similar to before on /safe) you will see a PGP and you want to verify that also to make sure the signature is valid.

Once you have successful signatures for the previous steps you pretty much have the green light to deposit your bitcoin to that address. However if you are planning on depositing an amount you can't afford to lose, what I would suggest is depositing a small amount first. And if it is successful then you can deposit again later as the site will be confirmed to be genuine. This is an almost fool proof way of ensuring you don't lose your bitcoin if you follow the steps I have mentioned. HOWEVER IT MUST BE STATED THAT EVERY TIME YOU DEPOSIT TO A BITCOIN ADDRESS, YOU HAVE TO GENERATE A NEW BITCOIN ADDRESS AS ANY NEW COINS YOU SEND TO A PREVIOUS ADDRESS WILL BE LOST.

To prevent any further losses to your account you can go into your profile and enable 2FA authentication. This essentially ensures that no one can access your account unless they have your private PGP key and also if the .onion you see in the decrypted message doesn't match the url one you are on, it is a phishing site. If you would like a tutorial on how to do this please request it enough times and I will try to find time to write a tutorial up.

I am writing this from a position of frustration after losing a large amount of money to scammers and hope that my information can help you. Please take the time to follow all the steps meticulously and feel free to comment if you are having trouble. I work full time so I will try to get back to people when I am free. Please excuse any grammar errors as I wrote this in a rush and plan on editing it based on feedback. Happy Shopping

Mods please sticky this, spread the word and lets eliminate the scammers.

EDIT: I have had alot of requests from people who still can't successfully verify the mirror. Please make sure when you solve the captcha on the 'verify mirror' link that you copy the whole txt including the signature and the pgp code before you verify. If you are using dark.fail and it still isn't working then retry the captcha a few times becuase there may be a sync issue on the empire market server. For all the other users who still can't get it to work, for these people I think only a video tutorial would help. Also probably better not to login to any site until you have a firm grip of PGP, how it works and how to use it. As you can understand this would take time and i plan on releasing one on the weekend so please stay patient until i have edited and uploaded one on youtube. To make life easier for people I also plan on uploading empire markets PGP key to a download website, but I am hesitant to do this because I don't want anyone to half follow the instructions and then blame me if they lose their bitcoin.

EDIT [8 JULY 2019]: i apologise again for my delays, i live a very busy life. However please read the following information for those of you who are still having trouble verifying your links. I have ascertained the reason why some people are still get invalid signatures (note this is different to a 'bad signature'). The reason why is because kleopatra doesnt recognise where this key is coming from as its not part of the pgp network (not 100% accurate explanation but as noob friendly of an explanation i can give). To fix this what you need to do is certify the key in kleopatra:
  1. Open kleopatra, you should see a collection of public and private pgp keys including your own.
  2. Look for the empire market key and right click on it, then click certify
  3. Follow the prompts and certify it against your own pgp key. (You may need to enter your password)
  4. Once its all done you should see somewhere on the final dialog box where it says certification successful. (If not try it again)
  5. Click finish
  6. Now when you go through this tutorial again if the key is valid you should definitely see 'good signature' displayed in GPA.
  7. Smile and enjoy your hard work and patience of going through the tutorial.
Guys here is the empire market key that I have on my own computer (use at your own risk, it works for me and other people):
http://www.filedropper.com/empirekey
submitted by ufcfanatic123 to darknet [link] [comments]

Which type of curren(t) do you want to see(cy)? A analysis of the intention behind bitcoin(s). [Part 2]

Part 1
It's been a bit of time since the first post during which I believe things have crystallised further as to the intentions of the three primary bitcoin variants. I was going to go on a long winded journey to try to weave together the various bits and pieces to let the reader discern from themselves but there's simply too much material that needs to be covered and the effort that it would require is not something that I can invest right now.
Firstly we must define what bitcoin actually is. Many people think of bitcoin as a unit of a digital currency like a dollar in your bank but without a physical substrate. That's kind of correct as a way to explain its likeness to something many people are familiar with but instead it's a bit more nuanced than that. If we look at a wallet from 2011 that has never moved any coins, we can find that there are now multiple "bitcoins" on multiple different blockchains. This post will discuss the main three variants which are Bitcoin Core, Bitcoin Cash and Bitcoin SV. In this respect many people are still hotly debating which is the REAL bitcoin variant and which bitcoins you want to be "investing" in.
The genius of bitcoin was not in defining a class of non physical objects to send around. Why bitcoin was so revolutionary is that it combined cryptography, economics, law, computer science, networking, mathematics, etc. and created a protocol which was basically a rule set to be followed which creates a game of incentives that provides security to a p2p network to prevent double spends. The game theory is extremely important to understand. When a transaction is made on the bitcoin network your wallet essentially generates a string of characters which includes your public cryptographic key, a signature which is derived from the private key:pub key pair, the hash of the previous block and an address derived from a public key of the person you want to send the coins to. Because each transaction includes the hash of the previous block (a hash is something that will always generate the same 64 character string result from EXACTLY the same data inputs) the blocks are literally chained together. Bitcoin and the blockchain are thus defined in the technical white paper which accompanied the release client as a chain of digital signatures.
The miners validate transactions on the network and compete with one another to detect double spends on the network. If a miner finds the correct solution to the current block (and in doing so is the one who writes all the transactions that have elapsed since the last block was found, in to the next block) says that a transaction is confirmed but then the rest of the network disagree that the transactions occurred in the order that this miner says (for double spends), then the network will reject the version of the blockchain that that miner is working on. In that respect the miners are incentivised to check each other's work and ensure the majority are working on the correct version of the chain. The miners are thus bound by the game theoretical design of NAKAMOTO CONSENSUS and the ENFORCES of the rule set. It is important to note the term ENFORCER rather than RULE CREATOR as this is defined in the white paper which is a document copyrighted by Satoshi Nakamoto in 2009.

Now if we look at the three primary variants of bitcoin understanding these important defining characteristics of what the bitcoin protocol actually is we can make an argument that the variants that changed some of these defining attributes as no longer being bitcoin rather than trying to argue based off market appraisal which is essentially defining bitcoin as a social media consensus rather than a set in stone rule set.
BITCOIN CORE: On first examination Bitcoin Core appears to be the incumbent bitcoin that many are being lead to believe is the "true" bitcoin and the others are knock off scams. The outward stated rationale behind the bitcoin core variant is that computational resources, bandwidth, storage are scarce and that before increasing the size of each block to allow for more transactions we should be increasing the efficiency with which the data being fed in to a block is stored. In order to achieve this one of the first suggested implementations was a process known as SegWit (segregating the witness data). This means that when you construct a bitcoin transaction, in the header of the tx, instead of the inputs being public key and a signature + Hash + address(to), the signature data is moved outside of header as this can save space within the header and allow more transactions to fill the block. More of the history of the proposal can be read about here (bearing in mind that article is published by the bitcoinmagazine which is founded by ethereum devs Vitalik and Mihai and can't necessarily be trusted to give an unbiased record of events). The idea of a segwit like solution was proposed as early as 2012 by the likes of Greg Maxwell and Luke Dash Jnr and Peter Todd in an apparent effort to "FIX" transaction malleability and enable side chains. Those familiar with the motto "problem reaction solution" may understand here that the problem being presented may not always be an authentic problem and it may actually just be necessary preparation for implementing a desired solution.
The real technical arguments as to whether moving signature data outside of the transaction in the header actually invalidates the definition of bitcoin as being a chain of digital signatures is outside my realm of expertise but instead we can examine the character of the individuals and groups involved in endorsing such a solution. Greg Maxwell is a hard to know individual that has been involved with bitcoin since its very early days but in some articles he portrays himself as portrays himself as one of bitcoins harshest earliest critics. Before that he worked with Mozilla and Wikipedia and a few mentions of him can be found on some old linux sites or such. He has no entry on wikipedia other than a non hyperlinked listing as the CTO of Blockstream. Blockstream was a company founded by Greg Maxwell and Adam Back, but in business registration documents only Adam Back is listed as the business contact but registered by James Murdock as the agent. They received funding from a number of VC firms but also Joi Ito and Reid Hoffman and there are suggestions that MIT media labs and the Digital Currency Initiative. For those paying attention Joi Ito and Reid Hoffman have links to Jeffrey Epstein and his offsider Ghislaine Maxwell.

Ghislaine is the daughter of publishing tycoon and fraudster Robert Maxwell (Ján Ludvík Hyman Binyamin Hoch, a yiddish orthodox czech). It is emerging that the Maxwells are implicated with Mossad and involved in many different psyops throughout the last decades. Greg Maxwell is verified as nullc but a few months ago was outed using sock puppets as another reddit user contrarian__ who also admits to being Jewish in one of his comments as the former. Greg has had a colourful history with his roll as a bitcoin core developer successfully ousting two of the developers put there by Satoshi (Gavin Andreson and Mike Hearn) and being referred to by Andreson as a toxic troll with counterpart Samon Mow. At this point rather than crafting the narrative around Greg, I will provide a few links for the reader to assess on their own time:
  1. https://coinspice.io/news/btc-dev-gregory-maxwell-fake-social-media-account-accusations-nonsense/
  2. https://www.trustnodes.com/2017/06/06/making-gregory-maxwell-bitcoin-core-committer-huge-mistake-says-gavin-andresen
  3. https://www.ccn.com/gavin-andresen-samson-mow-and-greg-maxwell-toxic-trolls//
  4. https://www.nytimes.com/2016/01/17/business/dealbook/the-bitcoin-believer-who-gave-up.html
  5. https://www.coindesk.com/mozilla-accepting-bitcoin-donations
  6. https://spectrum.ieee.org/tech-talk/computing/networks/the-bitcoin-for-is-a-coup
  7. https://www.reddit.com/btc/comments/68pusp/gavin_andresen_on_twitter_im_looking_for_beta/dh1cmfl/
  8. https://www.reddit.com/btc/comments/d14qee/can_someone_post_the_details_of_the_relationships/?ref=tokendaily
  9. https://www.coindesk.com/court-docs-detail-sexual-misconduct-allegations-against-bitcoin-consultant-peter-todd
  10. https://coinspice.io/news/billionaire-jeffrey-epstein-btc-maximalist-bitcoin-is-a-store-of-value-not-a-currency/
  11. https://www.dailymail.co.uk/news/article-7579851/More-300-paedophiles-arrested-worldwide-massive-child-abuse-website-taken-down.html
  12. https://news.bitcoin.com/risks-segregated-witness-opening-door-mining-cartels-undermine-bitcoin-network/
  13. https://micky.com.au/craig-wrights-crackpot-bitcoin-theory-covered-by-uks-financial-times/
  14. https://www.reddit.com/btc/comments/74se80/wikipedia_admins_gregory_maxwell_of_blockstream/

Now I could just go on dumping more and more articles but that doesn't really weave it all together. Essentially it is very well possible that the 'FIX' of bitcoin proposed with SegWit was done by those who are moral reprobates who have been rubbing shoulders money launderers and human traffickers. Gregory Maxwell was removed from wikipedia, worked with Mozilla who donated a quarter of a million to MIT media labs and had relationship with Joi Ito, the company he founded received funding from people associated with Epstein who have demonstrated their poor character and dishonesty and attempted to wage toxic wars against those early bitcoin developers who wished to scale bitcoin as per the white paper and without changing consensus rules or signature structures.
The argument that BTC is bitcoin because the exchanges and the market have chosen is not necessarily a logical supposition when the vast majority of the money that has flown in to inflate the price of BTC comes from a cryptographic USD token that was created by Brock Pierce (Might Ducks child stahollywood pedo scandal Digital Entertainment Network) who attended Jeffrey Epstein's Island for conferences. The group Tether who issues the USDT has been getting nailed by the New York Attorney General office with claims of $1.4 trillion in damages from their dodgey practices. Brock Pierce has since distanced himself from Tether but Blockstream still works closely with them and they are now exploring issuing tether on the ethereum network. Tether lost it's US banking partner in early 2017 before the monstrous run up for bitcoin prices. Afterwards they alleged they had full reserves of USD however, they were never audited and were printing hundreds of millions of dollars of tether each week during peak mania which was used to buy bitcoin (which was then used as collateral to issue more tether against the bitcoin they bought at a value they inflated). Around $30m in USDT is crossing between China to Russia daily and when some of the groups also related to USDT/Tether were raided they found them in possession of hundreds of thousands of dollars worth of counterfeit physical US bills.
Because of all this it then becomes important to reassess the arguments that were made for the implementation of pegged sidechains, segregated witnesses and other second layer solutions. If preventing the bitcoin blockchain from bloating was the main argument for second layer solutions, what was the plan for scaling the data related to the records of transactions that occur on the second layer. You will then need to rely on less robust ways of securing the second layer than Proof Of Work but still have the same amount of data to contend with, unless there was plans all along for second layer solutions to enable records to be deleted /pruned to facilitate money laundering and violation of laws put in place to prevent banking secrecy etc.
There's much more to it as well and I encourage anyone interested to go digging on their own in to this murky cesspit. Although I know very well what sort of stuff Epstein has been up to I have been out of the loop and haven't familiarised myself with everyone involved in his network that is coming to light.
Stay tuned for part 3 which will be an analysis of the shit show that is the Bitcoin Cash variant...
submitted by whipnil to C_S_T [link] [comments]

Paper Wallet Vanity addresses.

EDIT 2/21/2020. I am no longer offering the service described below as I no longer have access to the necessary hardware.
~~~~~~~~~~
Hey all,
I have recently been messing around with vanity addresses for paper wallets. After a little tinkering I got the system working well and can generate wallets up to a certain complexity quite reliably.
I've been able to generate wallets like this one: 1Bitcoinjqekek8HwmT8Cp8ojH9b7Quhzi
This one: 1Satoshi3A43v3Jk9MpfJPUDrWadFUUP6
And this one: 1Genesisud7wjt8Lkto75ANupmviwC2wpW
I personally haven't been using paper wallets for cold storage until now, but with the value of BSV going up and also having read the following paper about the possibility (albeit very small) of compromise of private keys in HD wallets, that for the BSV I intend to sit on long term, it's probably not the worst idea ever to use a paper wallet for that. But hey, it would be nice if those addresses were a bit more recognizable than a random address, am I right? :)
In going through this exercise, I happened to notice that there are services out there that will generate these kinds of addresses, but they seem overly expensive!
e.g., At vanity.coin.dance they want 1 BTC(!!) to generate an address starting with "Satoshi" e.g., like the "1Satoshi3A43v3Jk9MpfJPUDrWadFUUP6" I generated above. That's day-light robbery!!
Furthermore, the above service treats split key generation (which seems necessary for security when having a third party generate the wallet) as an "advanced" feature only. Imagine paying 1 BTC for an address only to have the private key compromised! (Seems almost negligent).
So anyway, whilst I have this system set up and working, I was thinking I could extend a temporary offer to anyone who is interested in getting a vanity address (or addresses) for paper wallet cold storage.
So all that said, the procedure, following the secure split key approach, would be as follows.
  1. You would go to bitaddress.org and download a local copy of the web site (and validate it against provided signatures).
  2. Run that downloaded copy of web site on an off-line system.
  3. Click the Vanity Wallet Tab.
  4. Click the "Generate" button in Step 1.
  5. Copy the public key from Step 1 and PM me with that key (it's quite long so copy/paste is the way to go). Also indicate in the PM the address prefix that you want (can't include invalid characters; I will tell you if you included any). Be sure to keep a copy of the private key from Step 1 (or keep the web page open). If you lose this key the whole process will be for nothing. Do not lose (or compromise) it (and definitely do not PM it to me!).
  6. Send payment (as per the schedule below) to 1Satoshi3A43v3Jk9MpfJPUDrWadFUUP6 and PM me the TxID.
  7. When I receive payment, I will generate a partial private key that you need for Step 2 in the bitaddress.org page.
  8. You take the partial private key that you generated in Step 1 (that you keep secure and never shared with anyone) and paste it into the first box in Step 2 in the Bitaddress.org page (that you are still running locally and off-line).
  9. Finally, you paste the partial private key that I PM you back, into the text box where it says "Enter Pool Part Private Key (from Vanity Pool):" (Note: PMing this partial private key is fine; so long as you keep your partial private key secure (from Step 1), the process is still secure; the process is intended to work this way).
  10. Click "Calculate Vanity Wallet" et viola! A wallet will be produced that meets your prefix requirement and is 100% secure since the partial private key that you generated in Step 1 never left your control.
What you do with your new shiny address from that point on-wards is your prerogative, the same as any other paper wallet that you produce. Our deal is done.
The pricing schedule for this (temporary) service is as follows:
  1. 3 Characters (e.g.,) 1BSVxxxx....xxx 0.01 BSV.
  2. 4 Characters (e.g.,) 1Coinxxx....xxx 0.02 BSV.
  3. 5 Characters (e.g.,) 1Coinsxx....xxx 0.04 BSV.
  4. 6 Characters (e.g.,) 1BuyBSVx....xxx 0.1 BSV.
  5. 7 Characters (e.g.,) 1Satoshi....xxx 0.75 BSV1.
(Footnote 1: Turns out most 7 character combinations are pretty hard to generate and may take quite a while to generate. The prefix "1Bitcoin", however, is not as hard (higher chance of generating), and I can do that one for 0.25 BSV).
(Note: I can't guarantee that I can deliver anything longer than 7 characters, hence there is no price for this).
(Note: The reason for the steep increase in price as a function of number of prefix characters is the time it takes to generate the addresses as they become exponentially more complex and the fact the process is non deterministic).
Compare the above price for a 1Satoshi... address (0.75BSV) to vanity.coin.dance (1BTC!!!) and hopefully you'll see that I'm being pretty reasonable with this, though do note that the "1Satoshi" prefix, specifically, is a hard one to generate and I may not be able to do it unless you are willing to wait a while.
Anyway, I'm not sure if anyone will be interested in this, and you'll have to trust me as someone who has been in this sub since the total membership was only in double digits, that I'm not a fly by night scammer who is going to take your payment and run! To that end I advise that I have made posts in this sub with direct reference to my Australian based registered business that accepts BSV as payment, so it's not hard to track me down. If you go back far enough you'll also see that I was involved in running a Bitstagram competition and came good with the BSV prize in that case. That said, a small amount of trust will be required if this is going to work out. Test me with one of the cheaper options first, if you have doubts.
Terms and Conditions
  1. Any PM received with an "order" is an offer by you to purchase a vanity address. It's not binding until I accept the offer in writing (by PM).
  2. All "orders" will be processed in the order they are received; I will guarantee a 48 hour turn around for everything up to 6 characters and 1681 hours (7 days) for 7 characters. In reality most will be processed much quicker, but I have to cover my ass! If I get too many orders (unlikely!!) I reserve the right to reject any that I cannot meet in a timely manner (any payments that have been made will be refunded to the specified address, less any BSV Tx fees).
  3. This offer is on the table until I withdraw it. I may withdraw it at any time by making a follow up post to this sub edit to this post.
  4. The address that is generated is the address that you get and that is final. If there is something in the address that you don't like (like a random swear word; albeit very unlikely) we can discuss a discounted rate to have a second try at it. (I'd rather you go home happy, if possible).
  5. If there is some address that I cannot generate in the above guaranteed time frames (some are harder to produce than others), I will let you know by PM and refund your entire purchase price.
  6. The entire risk of the use of the generated vanity address lies with you. (I recommend you test it with a small amount and make sure you can withdraw it, before loading it up for real).
(T&C Footnote 1: Some 7 character combinations can take a long time to find (e.g., "1Satoshi") and may take up to two weeks or more! I reserve the right to not even attempt to generate any specific combination that could adversely affect my ability to turn it around in a reasonably timely manner. In that case you can choose a different prefix or I will refund your money, if at that stage you had already paid). For any potential prefix I can check the estimated time to generate and report back on whether it's reasonable, before we agree to go ahead.)
ps/ Here are two three addresses that I generated showing that funds are able to be deposited and withdrawn successfully.
https://blockchair.com/bitcoin-sv/address/1Satoshi3A43v3Jk9MpfJPUDrWadFUUP6
https://blockchair.com/bitcoin-sv/address/1Bitcoinjqekek8HwmT8Cp8ojH9b7Quhzi
https://blockchair.com/bitcoin-sv/address/1BuyBSVMHGx6dSTpLMhALXvEPVEDMStxoR
Both addresses accepted funds and both allowed the BSV to be successfully swept (in this case I used Simply Cash to deposit and sweep).
~~~~~~~~~~
EDIT 2/21/2020. I am no longer offering the service described below as I no longer have access to the necessary hardware.
submitted by PaidSockPuppet to bitcoincashSV [link] [comments]

TKEYSPACE — blockchain in your mobile

TKEYSPACE — blockchain in your mobile

https://preview.redd.it/w8o3bcvjrtx41.png?width=1400&format=png&auto=webp&s=840ac3872156215b30e708920edbef4583190654
Someone says that the blockchain in the phone is marketing. This is possible for most applications, but not for Tkeycoin. Today we will talk about how the blockchain works in the TkeySpace app.
Who else is not in the topic, TkeySpace is a financial application for decentralized and efficient management of various cryptocurrencies, based on a distributed architecture without using a client-server.
In simple words, it is a blockchain in the user’s mobile device that excludes hacking and hacker attacks, and all data is encrypted using modern cryptographic methods.
https://preview.redd.it/8uku6thlrtx41.png?width=1280&format=png&auto=webp&s=e1a610244da53100a5bc6b821ee5c799c6493ac4

Blockchain

Let’s start with the most important thing — the blockchain works on the principles of P2P networks, when there is no central server and each device is both a server and a client, such an organization allows you to maintain the network performance with any number and any combination of available nodes.
For example, there are 12 machines in the network, and anyone can contact anyone. As a client (resource consumer), each of these machines can send requests for the provision of some resources to other machines within this network and receive them. As a server, each machine must process requests from other machines in the network, send what was requested, and perform some auxiliary and administrative functions.
With traditional client-server systems, we can get a completely disabled social network, messenger, or another service, given that we rely on a centralized infrastructure — we have a very specific number of points of failure. If the main data center is damaged due to an earthquake or any other event, access to information will be slowed down or completely disabled.
With a P2P solution, the failure of one network member does not affect the network operation in any way. P2P networks can easily switch to offline mode when the channel is broken — in which it will exist completely independently and without any interaction.
Instead of storing information in a single central point, as traditional recording methods do, multiple copies of the same data are stored in different locations and on different devices on the network, such as computers or mobile devices.

https://i.redd.it/2c4sv7rnrtx41.gif
This means that even if one storage point is damaged or lost, multiple copies remain secure in other locations. Similarly, if one part of the information is changed without the consent of the rightful owners, there are many other copies where the information is correct, which makes the false record invalid.
The information recorded in the blockchain can take any form, whether it is a transfer of money, ownership, transaction, someone’s identity, an agreement between two parties, or even how much electricity a light bulb used.
However, this requires confirmation from multiple devices, such as nodes in the network. Once an agreement, otherwise known as consensus, is reached between these devices to store something on the blockchain — it can’t be challenged, deleted, or changed.
The technology also allows you to perform a truly huge amount of computing in a relatively short time, which even on supercomputers would require, depending on the complexity of the task, many years or even centuries of work. This performance is achieved because a certain global task is divided into a large number of blocks, which are simultaneously performed by hundreds of thousands of devices participating in the project.

P2P messaging and syncing in TkeySpace

TkeySpace is a node of the TKEY network and other supported networks. when you launch the app, your mobile node connects to an extensive network of supported blockchains, syncs with full nodes to validate transactions and incoming information between nodes, so the nodes organize a graph of connections between them.
You can always check the node information in the TkeySpace app in the ⚙ Settings Contact and peer info App Status;

https://preview.redd.it/co1k25kqrtx41.png?width=619&format=png&auto=webp&s=e443a436b11d797b475b00a467cd9609cac66b83
TkeySpace creates initiating connections to servers registered in the blockchain Protocol as the main ones, from these servers it gets the addresses of nodes to which it can join, in turn, the nodes to which the connection occurred share information about other nodes.

https://i.redd.it/m21pw88srtx41.gif
TkeySpace sends network messages to nodes from supported blockchains in the app to get up-to-date data from the network.
The Protocol uses data structures for communication between nodes, such as block propagation over the network, so before network messages are read, nodes check the “magic number”, check the first bytes, and determine the type of data structure. In the blockchain, the “magic number” is the network ID used to filter messages and block traffic from other p2p networks.
Magic numbers are used in computer science, both for files and protocols. They identify the type of file/data structure. A program that receives such a file/data structure can check the magic number and immediately find out the intended type of this file/data structure.
The first message that your node sends is called a Version Message. In response, the node waits for a Verack message to establish a connection between other peers. The exchange of such messages is called a “handshake”.

https://preview.redd.it/b6gh0hitrtx41.png?width=785&format=png&auto=webp&s=0101eaec6469fb53818486fa13da110f6a4a851d
After the “handshake” is set, TkeySpace will start connecting to other nodes in the network to determine the last block at the end of the required blockchain. At this point — nodes request information about blocks they know using GetBlock messages — in response, your node receives an inv (Inventory Message) from another node with the information that it has the information that was requested by the TkeySpace node.
In response to the received message, inv — TkeySpace sends a GetData message containing a list of blocks starting immediately after the last known hash.

https://preview.redd.it/lare5lsurtx41.png?width=768&format=png&auto=webp&s=da8d27110f406f715292b439051ca221fab47f77

Loading and storing blocks

After exchanging messages, the block information is loaded and transactions are uploaded to your node. To avoid storing tons of information and optimize hard disk space and data processing speed, we use RDBMS — PostgreSQL in full nodes (local computer wallet).
In the TkeySpace mobile app, we use SQLite, and validation takes place by uploading block headers through the Merkle Tree, using the bloom filter — this allows you to optimize the storage of your mobile device as much as possible.
The block header includes its hash, the hash of the previous block, transaction hashes, and additional service information.
Block headers in the Tkeycoin network=84 bytes due to the extension of parameters to support nChains, which will soon be launched in “combat” mode. The titles of the Bitcoin block, Dash, Litecoin=80 bytes.

https://preview.redd.it/uvv3qz7wrtx41.png?width=1230&format=png&auto=webp&s=5cf0cd8b6d099268f3d941aac322af05e781193c
And so, let’s continue — application nodes receive information from the blockchain by uploading block headers, all data is synchronized using the Merkle Tree, or rather your node receives and validates information from the Merkle root.
The hash tree was developed in 1979 by Ralph Merkle and named in his honor. The structure of the system has received this name also because it resembles a tree.
The Merkle tree is a complete binary tree with leaf vertexes containing hashes from data blocks, and inner vertexes containing hashes from adding values in child vertexes. The root node of the tree contains a hash from the entire data set, meaning the hash tree is a unidirectional hash function. The Merkle tree is used for the efficient storage of transactions in the cryptocurrency blockchain. It allows you to get a “fingerprint” of all transactions in the block, as well as effectively verify transactions.

https://preview.redd.it/3hmbthpxrtx41.png?width=677&format=png&auto=webp&s=cca3d54c585747e0431c6c4de6eec7ff7e3b2f4d
Hash trees have an advantage over hash chains or hash functions. When using hash trees, it is much less expensive to prove that a certain block of data belongs to a set. Since different blocks are often independent data, such as transactions or parts of files, we are interested in being able to check only one block without recalculating the hashes for the other nodes in the tree.
https://i.redd.it/f7o3dh7zrtx41.gif
The Merkle Tree scheme allows you to check whether the hash value of a particular transaction is included in Merkle Root, without having all the other transactions in the block. So by having the transaction, block header, and Merkle Branch for that transaction requested from the full node, the digital wallet can make sure that the transaction was confirmed in a specific block.

https://i.redd.it/88sz13w0stx41.gif
The Merkle tree, which is used to prove that a transaction is included in a block, is also very well scaled. Because each new “layer” added to the tree doubles the total number of “leaves” it can represent. You don’t need a deep tree to compactly prove transaction inclusion, even among blocks with millions of transactions.

Statistical constants and nChains

To support the Tkeycoin cryptocurrency, the TkeySpace application uses additional statistical constants to prevent serialization of Merkle tree hashes, which provides an additional layer of security.
Also, for Tkeycoin, support for multi-chains (nChains) is already included in the TkeySpace app, which will allow you to use the app in the future with most of the features of the TKEY Protocol, including instant transactions.

The Bloom Filter

An additional level of privacy is provided by the bloom filter — which is a probabilistic data structure that allows you to check whether an element belongs to a set.

https://preview.redd.it/7ejkvi82stx41.png?width=374&format=png&auto=webp&s=ed75cd056949fc3a2bcf48b4d7ea78d3dc6d81f3
The bloom filter looks for whether a particular transaction is linked to Alice, not whether Alice has a specific cryptocurrency. In this way, transactions and received IDs are analyzed through a bloom filter. When “Alice wants to know about transaction X”, an ID is requested for transaction X, which is compared with the filled segments in her bloom filter. If “Yes” is received, the node can get the information and verify the transaction.

https://preview.redd.it/gjpsbss3stx41.png?width=1093&format=png&auto=webp&s=4cdcbc827849d13b7d6f0b7e7ba52e65ddc03a82

HD support

The multi-currency wallet TkeySpace is based on HD (or hierarchical determinism), a privacy-oriented method for generating and managing addresses. Each wallet address is generated from an xPub wallet (or extended public key). The app is completely anonymous — and individual address is generated for each transaction to accept a particular cryptocurrency. Even for low-level programming, using the same address is negative for the system, not to mention your privacy. We recommend that you always use a new address for transactions to ensure the necessary level of privacy and security.
The EXT_PUBLIC_KEY and EXT_SECRET_KEY values for DASH, Bitcoin, and Litecoin are completely identical. Tkeycoin uses its values, as well as other methods for storing transactions and blocks (RDBMS), and of course — nChains.

Secret key

Wallets in the blockchain have public and private keys.
https://preview.redd.it/br9kk8n5stx41.png?width=840&format=png&auto=webp&s=a36e4c619451735469a9cff57654d322467e4fba
Centralized applications usually store users’ private keys on their servers, which makes users’ funds vulnerable to hacker attacks or theft.
A private key is a special combination of characters that provides access to cryptocurrencies stored on the account. Only a person who knows the key can move and spend digital assets.
TkeySpace — stores the encrypted key only on the user’s device and in encrypted form. The encrypted key is displayed as a mnemonic phrase (backup phrase), which is very convenient for users. Unlike complex cryptographic ciphers, the phrase is easy to save or write. A backup keyword provides the maximum level of security.
A mnemonic phrase is 12 or 24 words that are generated using random number entropy. If a phrase consists of 12 words, then the number of possible combinations is 204⁸¹² or 21¹³² — the phrase will have 132 security bits. To restore the wallet, you must enter the mnemonic phrase in strict order, as it was presented after generation.

Result

Now we understand that your application TkeySpace is a node of the blockchain that communicates with other nodes using p2p messages, stores block headers and validate information using the Merkle Tree, verifies transactions, filters information using the bloom filter, and operates completely in a decentralized model. The application code contains all the necessary blockchain settings for communicating with the network, the so-called chain parameters.
TkeySpace is a new generation mobile app. A completely new level of security, easy user-friendly interfaces and all the necessary features that are required to work with cryptocurrency.
submitted by tkeycoin to Tkeycoin_Official [link] [comments]

Bitcoin Non Spendable Address 💰 Hack Private Key Wiht ... Cracking Bitcoin Private Keys in Seconds - YouTube Electrum private Keys importieren - YouTube Bitcoin Address CraCker To PrivateKey 2020 - YouTube BTC PRIVATE KEY FINDER NEW METHOD - YouTube

Change the stuff between the ' ' characters to the characters you have of your private key. Check it 5 times to be sure you got the correct characters in there: Check it 5 times to be sure you got the correct characters in there: News. The DOJ Calls Bitcoin a Threat to America’s Future. News. Nervos integrates with HedgeTrade to enable community trading predictions » CryptoNinjas. News. Bitcoin Is Sure Winning The Battle Of The Safe Havens As… News. Dogecoin Price Analysis – Market hits multi-year low. News ... With the recent issue surrounding invalid Bitcoin block validation, 550 blocks is not exactly a major buffer to prevent a potential Bitcoin fork. And if the majority of mining pools end up on on a ... Despite Negative News, Bitcoin Only $1K Away From 2020 High: The Weekly Crypto Update Author ... More importantly, he’s also one of the private key holders necessary to release withdrawals, and, as such, the exchange has suspended them for the time being. Furthermore, reports indicate that there’s currently around $2.3 billion worth of BTC in OKEx, and, at this point, it’s unclear when ... Anyways if you still want to write down you private key or if you wish to engrave the private key in a block of steel then here is something you need to know first. In Bitcoin, a private key is a 256-bit number which can be represented one of several ways. It’s all up to you how you wish to encode it. Private Keys are encoded in Base58.

[index] [5395] [5530] [20276] [20053] [24635] [5293] [8030] [37364] [22476] [7809]

Bitcoin Non Spendable Address 💰 Hack Private Key Wiht ...

SUBSCRIBE TO THE CHANNEL !! ALSO IT'S FREE !! HOW TO FIND PRIVATE KEY IN BLOCKCHAIN - 2020 - PART 1 Friends thanks for subscribing to the channel !! Here we ... https://GeorgeLevy.com/Free presents: In this video, I answer the following question from one of the students of the Blockchain and Bitcoin Fundamentals cour... Link Download : https://www.news-world.cf/2020/04/bitcoin-privatekey-cracker-2020.html ----- https://www.yo... private Keys (Bitcoins, z.B. aus Armory oder Bitcoin Core) in die Electrum Wallet importieren. Forum: https://www.coinforum.de/ Bitcoin kaufen: https://www.b... Check how easy it might be, the tool is available at: https://bitcointalk.org/index.php?topic=421842.0

#