#bitcoin freenode - IRC Chat - Bitcoin, Currencies

XMR Trader, the Official Monero Trading Subreddit

The official Monero trading subreddit. Discuss price movements, market dynamics, news, and trades involving Monero here.
[link]

Welcome to the world of Monero mining!

A subreddit for discussions about Monero (XMR) mining.
[link]

Monero Community Activists

A meeting place for Monero community activists. Put your talents to use by sharing the word of Monero!
[link]

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]

⚡ Lightning Network Megathread ⚡

Last updated 2018-01-29
This post is a collaboration with the Bitcoin community to create a one-stop source for Lightning Network information.
There are still questions in the FAQ that are unanswered, if you know the answer and can provide a source please do so!

⚡What is the Lightning Network? ⚡

Explanations:

Image Explanations:

Specifications / White Papers

Videos

Lightning Network Experts on Reddit

  • starkbot - (Elizabeth Stark - Lightning Labs)
  • roasbeef - (Olaoluwa Osuntokun - Lightning Labs)
  • stile65 - (Alex Akselrod - Lightning Labs)
  • cfromknecht - (Conner Fromknecht - Lightning Labs)
  • RustyReddit - (Rusty Russell - Blockstream)
  • cdecker - (Christian Decker - Blockstream)
  • Dryja - (Tadge Dryja - Digital Currency Initiative)
  • josephpoon - (Joseph Poon)
  • fdrn - (Fabrice Drouin - ACINQ )
  • pmpadiou - (Pierre-Marie Padiou - ACINQ)

Lightning Network Experts on Twitter

  • @starkness - (Elizabeth Stark - Lightning Labs)
  • @roasbeef - (Olaoluwa Osuntokun - Lightning Labs)
  • @stile65 - (Alex Akselrod - Lightning Labs)
  • @bitconner - (Conner Fromknecht - Lightning Labs)
  • @johanth - (Johan Halseth - Lightning Labs)
  • @bvu - (Bryan Vu - Lightning Labs)
  • @rusty_twit - (Rusty Russell - Blockstream)
  • @snyke - (Christian Decker - Blockstream)
  • @JackMallers - (Jack Mallers - Zap)
  • @tdryja - (Tadge Dryja - Digital Currency Initiative)
  • @jcp - (Joseph Poon)
  • @alexbosworth - (Alex Bosworth - yalls.org)

Medium Posts

Learning Resources

Books

Desktop Interfaces

Web Interfaces

Tutorials and resources

Lightning on Testnet

Lightning Wallets

Place a testnet transaction

Altcoin Trading using Lightning

  • ZigZag - Disclaimer You must trust ZigZag to send to Target Address

Lightning on Mainnet

Warning - Testing should be done on Testnet

Atomic Swaps

Developer Documentation and Resources

Lightning implementations

  • LND - Lightning Network Daemon (Golang)
  • eclair - A Scala implementation of the Lightning Network (Scala)
  • c-lightning - A Lightning Network implementation in C
  • lit - Lightning Network node software (Golang)
  • lightning-onion - Onion Routed Micropayments for the Lightning Network (Golang)
  • lightning-integration - Lightning Integration Testing Framework
  • ptarmigan - C++ BOLT-Compliant Lightning Network Implementation [Incomplete]

Libraries

Lightning Network Visualizers/Explorers

Testnet

Mainnet

Payment Processors

  • BTCPay - Next stable version will include Lightning Network

Community

Slack

IRC

Slack Channel

Discord Channel

Miscellaneous

⚡ Lightning FAQs ⚡

If you can answer please PM me and include source if possible. Feel free to help keep these answers up to date and as brief but correct as possible
Is Lightning Bitcoin?
Yes. You pick a peer and after some setup, create a bitcoin transaction to fund the lightning channel; it’ll then take another transaction to close it and release your funds. You and your peer always hold a bitcoin transaction to get your funds whenever you want: just broadcast to the blockchain like normal. In other words, you and your peer create a shared account, and then use Lightning to securely negotiate who gets how much from that shared account, without waiting for the bitcoin blockchain.
Is the Lightning Network open source?
Yes, Lightning is open source. Anyone can review the code (in the same way as the bitcoin code)
Who owns and controls the Lightning Network?
Similar to the bitcoin network, no one will ever own or control the Lightning Network. The code is open source and free for anyone to download and review. Anyone can run a node and be part of the network.
I’ve heard that Lightning transactions are happening “off-chain”…Does that mean that my bitcoin will be removed from the blockchain?
No, your bitcoin will never leave the blockchain. Instead your bitcoin will be held in a multi-signature address as long as your channel stays open. When the channel is closed; the final transaction will be added to the blockchain. “Off-chain” is not a perfect term, but it is used due to the fact that the transfer of ownership is no longer reflected on the blockchain until the channel is closed.
Do I need a constant connection to run a lightning node?
Not necessarily,
Example: A and B have a channel. 1 BTC each. A sends B 0.5 BTC. B sends back 0.25 BTC. Balance should be A = 0.75, B = 1.25. If A gets disconnected, B can publish the first Tx where the balance was A = 0.5 and B = 1.5. If the node B does in fact attempt to cheat by publishing an old state (such as the A=0.5 and B=1.5 state), this cheat can then be detected on-chain and used to steal the cheaters funds, i.e., A can see the closing transaction, notice it's an old one and grab all funds in the channel (A=2, B=0). The time that A has in order to react to the cheating counterparty is given by the CheckLockTimeVerify (CLTV) in the cheating transaction, which is adjustable. So if A foresees that it'll be able to check in about once every 24 hours it'll require that the CLTV is at least that large, if it's once a week then that's fine too. You definitely do not need to be online and watching the chain 24/7, just make sure to check in once in a while before the CLTV expires. Alternatively you can outsource the watch duties, in order to keep the CLTV timeouts low. This can be achieved both with trusted third parties or untrusted ones (watchtowers). In the case of a unilateral close, e.g., you just go offline and never come back, the other endpoint will have to wait for that timeout to expire to get its funds back. So peers might not accept channels with extremely high CLTV timeouts. -- Source
What Are Lightning’s Advantages?
Tiny payments are possible: since fees are proportional to the payment amount, you can pay a fraction of a cent; accounting is even done in thousandths of a satoshi. Payments are settled instantly: the money is sent in the time it takes to cross the network to your destination and back, typically a fraction of a second.
Does Lightning require Segregated Witness?
Yes, but not in theory. You could make a poorer lightning network without it, which has higher risks when establishing channels (you might have to wait a month if things go wrong!), has limited channel lifetime, longer minimum payment expiry times on each hop, is less efficient and has less robust outsourcing. The entire spec as written today assumes segregated witness, as it solves all these problems.
Can I Send Funds From Lightning to a Normal Bitcoin Address?
No, for now. For the first version of the protocol, if you wanted to send a normal bitcoin transaction using your channel, you have to close it, send the funds, then reopen the channel (3 transactions). In future versions, you and your peer would agree to spend out of your lightning channel funds just like a normal bitcoin payment, allowing you to use your lightning wallet like a normal bitcoin wallet.
Can I Make Money Running a Lightning Node?
Not really. Anyone can set up a node, and so it’s a race to the bottom on fees. In practice, we may see the network use a nominal fee and not change very much, which only provides an incremental incentive to route on a node you’re going to use yourself, and not enough to run one merely for fees. Having clients use criteria other than fees (e.g. randomness, diversity) in route selection will also help this.
What is the release date for Lightning on Mainnet?
Lightning is already being tested on the Mainnet Twitter Link but as for a specific date, Jameson Lopp says it best
Would there be any KYC/AML issues with certain nodes?
Nope, because there is no custody ever involved. It's just like forwarding packets. -- Source
What is the delay time for the recipient of a transaction receiving confirmation?
Furthermore, the Lightning Network scales not with the transaction throughput of the underlying blockchain, but with modern data processing and latency limits - payments can be made nearly as quickly as packets can be sent. -- Source
How does the lightning network prevent centralization?
Bitcoin Stack Exchange Answer
What are Channel Factories and how do they work?
Bitcoin Stack Exchange Answer
How does the Lightning network work in simple terms?
Bitcoin Stack Exchange Answer
How are paths found in Lightning Network?
Bitcoin Stack Exchange Answer
How would the lightning network work between exchanges?
Each exchange will get to decide and need to implement the software into their system, but some ideas have been outlined here: Google Doc - Lightning Exchanges
Note that by virtue of the usual benefits of cost-less, instantaneous transactions, lightning will make arbitrage between exchanges much more efficient and thus lead to consistent pricing across exchange that adopt it. -- Source
How do lightning nodes find other lightning nodes?
Stack Exchange Answer
Does every user need to store the state of the complete Lightning Network?
According to Rusty's calculations we should be able to store 1 million nodes in about 100 MB, so that should work even for mobile phones. Beyond that we have some proposals ready to lighten the load on endpoints, but we'll cross that bridge when we get there. -- Source
Would I need to download the complete state every time I open the App and make a payment?
No you'd remember the information from the last time you started the app and only sync the differences. This is not yet implemented, but it shouldn't be too hard to get a preliminary protocol working if that turns out to be a problem. -- Source
What needs to happen for the Lightning Network to be deployed and what can I do as a user to help?
Lightning is based on participants in the network running lightning node software that enables them to interact with other nodes. This does not require being a full bitcoin node, but you will have to run "lnd", "eclair", or one of the other node softwares listed above.
All lightning wallets have node software integrated into them, because that is necessary to create payment channels and conduct payments on the network, but you can also intentionally run lnd or similar for public benefit - e.g. you can hold open payment channels or channels with higher volume, than you need for your own transactions. You would be compensated in modest fees by those who transact across your node with multi-hop payments. -- Source
Is there anyway for someone who isn't a developer to meaningfully contribute?
Sure, you can help write up educational material. You can learn and read more about the tech at http://dev.lightning.community/resources. You can test the various desktop and mobile apps out there (Lightning Desktop, Zap, Eclair apps). -- Source
Do I need to be a miner to be a Lightning Network node?
No -- Source
Do I need to run a full Bitcoin node to run a lightning node?
lit doesn't depend on having your own full node -- it automatically connects to full nodes on the network. -- Source
LND uses a light client mode, so it doesn't require a full node. The name of the light client it uses is called neutrino
How does the lightning network stop "Cheating" (Someone broadcasting an old transaction)?
Upon opening a channel, the two endpoints first agree on a reserve value, below which the channel balance may not drop. This is to make sure that both endpoints always have some skin in the game as rustyreddit puts it :-)
For a cheat to become worth it, the opponent has to be absolutely sure that you cannot retaliate against him during the timeout. So he has to make sure you never ever get network connectivity during that time. Having someone else also watching for channel closures and notifying you, or releasing a canned retaliation, makes this even harder for the attacker. This is because if he misjudged you being truly offline you can retaliate by grabbing all of its funds. Spotty connections, DDoS, and similar will not provide the attacker the necessary guarantees to make cheating worthwhile. Any form of uncertainty about your online status acts as a deterrent to the other endpoint. -- Source
How many times would someone need to open and close their lightning channels?
You typically want to have more than one channel open at any given time for redundancy's sake. And we imagine open and close will probably be automated for the most part. In fact we already have a feature in LND called autopilot that can automatically open channels for a user.
Frequency will depend whether the funds are needed on-chain or more useful on LN. -- Source
Will the lightning network reduce BTC Liquidity due to "locking-up" funds in channels?
Stack Exchange Answer
Can the Lightning Network work on any other cryptocurrency? How?
Stack Exchange Answer
When setting up a Lightning Network Node are fees set for the entire node, or each channel when opened?
You don't really set up a "node" in the sense that anyone with more than one channel can automatically be a node and route payments. Fees on LN can be set by the node, and can change dynamically on the network. -- Source
Can Lightning routing fees be changed dynamically, without closing channels?
Yes but it has to be implemented in the Lightning software being used. -- Source
How can you make sure that there will be routes with large enough balances to handle transactions?
You won't have to do anything. With autopilot enabled, it'll automatically open and close channels based on the availability of the network. -- Source
How does the Lightning Network stop flooding nodes (DDoS) with micro transactions? Is this even an issue?
Stack Exchange Answer

Unanswered Questions

How do on-chain fees work when opening and closing channels? Who pays the fee?
How does the Lightning Network work for mobile users?
What are the best practices for securing a lightning node?
What is a lightning "hub"?
How does lightning handle cross chain (Atomic) swaps?

Special Thanks and Notes

  • Many links found from awesome-lightning-network github
  • Everyone who submitted a question or concern!
  • I'm continuing to format for an easier Mobile experience!
submitted by codedaway to Bitcoin [link] [comments]

Brief History Of Bitcoin

Brief History Of Bitcoin
Bitcoins have been classed as the world's originally decentralized cash, and for as far back as ten years, they have become all the more notable and keep on developing in notoriety.

The following is a concise history of how the Bitcoin began and what has occurred since.

2007 - It was in 2007 that the idea of the Bitcoin started. It is accepted that it was begun by Satoshi Nakamoto, in spite of the fact that very little is thought about him, other than the reality he is on record as living in Japan. Truth be told, many conjecture this may very well be a pen name more than one individual. Albeit soon, this character totally evaporated from the world.

August 2008 An application for an encryption patent application was recorded by three people who denied having any association with the supposed originator of the Bitcoin idea. They were Neal Kin, Vladimir Oksman and Charles Bry.

Around the same time, they namelessly purchased and enlisted the space bitcoin.org.

October 2008 In October of 2008, only two months after the space was enlisted, a paper titled, 'Bitcoin: A Peer-to-Peer Electronic Cash System', was distributed on a cryptography mailing list, apparently composed by Satoshi Nakamoto.

The paper laid out the establishment of how the Bitcoin would really work, and takes care of the issue of cash being duplicated, which permitted Bitcoin to develop genuinely.

November 2008 A month after the white paper was distributed, the Bitcoin venture is enlisted on a network joint effort site, SourceForge, which centers around the improvement and circulation of open source programming.

January 2009 In mid 2009, the principal square, which was nicknamed 'Beginning' is propelled, which permitted the primary adaptation of Bitcoin to be discharged.

There was further hypothesis that Bitcoins were created by more than one individual, as it had been accumulated with Microsoft Visual Studio for Windows, yet needed order line interface. It was anticipated as of now that a Bitcoin age framework would make a sum of 21 million Bitcoins during that time 2040.

Later on, right now, first exchange occurred among Satoshi and Hal Finney, a designer and cryptographic lobbyist.

October 2009 In October, New Liberty Standard distributes a Bitcoin swapping scale. The worth was built up and they distributed a pace of a Bitcoin at 1USD = 1,309.03 BTC. This was chosen utilizing a condition that incorporated the expense of the power to run the PC that produced Bitcoins.

Later on this month, the #bitcoin-dev channel is enrolled on freenode IRC, which was a conversation arrange intended for nothing and open source advancement networks.

December 2009 In late 2009, the second form of the Bitcoin was created and discharged; anyway later on in the month, they acquired their first trouble increment.

February 2010 In mid 2010, the Bitcoin money trade was conceived, and the Market was built up by the now ancient organization dollar. Later on in the month, and 18 months after the application was documented, the encryption patent was distributed and endorsed.

May 2010 This month would end up being an achievement for Bitcoins, because of the way that the primary genuine exchange occurred. A software engineer named Laszlo Hanyecz, who lived in Florida pays 10,000 Bitcoins on a pizza, that was initially purchased from Papa Johns by a volunteer in England. The conversion scale at the time put the price tag for the pizza at 25USD.

https://preview.redd.it/93tj7l1248g41.jpg?width=750&format=pjpg&auto=webp&s=ddd04f2fc86eaf33bc9894dd98f30781511c4f42
Given the present swapping scale, today the pizza is esteemed at 1,961,034GBP.

July 2010 The third form of Bitcoin is created and discharged. Later on that month, there were an enormous number of new Bitcoin clients, on account of a notice of the new form on Slashdot.

During a multi day time of this current month, the trade estimation of Bitcoin expanded multiple times, from 0.0008USD/BTC to 0.080USD/BTC which the prompted Jed McCaleb building up a Bitcoin money trade showcase named MtGox.

August 2010 August 2010 end up being a sad month for the Bitcoin, and the framework was hacked. A defenselessness in the framework caused Bitcoins to be inappropriately checked, and accordingly abused, which brought about the age of 184 million Bitcoins. The made the worth drop radically.

September 2010 This was a bustling month for Bitcoins, as they attempted to recoup from the hacking the earlier month. An offer was made by jgarzik as 10,000BTC, which was proportionate to 650USD at that point, to open source their Windows-based CUDA customer. Later on that month, they took this offer and discharged the source, under the MIT permit.

October 2010 Bitcoins confronted a ton of investigation this month, when a between administrative gathering named The Financial Action Task Force gave a report on tax evasion, notice about the utilization of computerized monetary standards to fund fear based oppressor gatherings.

In spite of this report, the Bitcoin swapping scale, which had slowed down, started to climb once more. This came after the principal open adaptation of an OpenCL digger is discharged.
submitted by Bitcoin12investment to u/Bitcoin12investment [link] [comments]

as p2pool reaches maturity, the hashing speed has breached 50GH/s.. are you Mining? jump in the only decentralized miners pool ^__^

as p2pool reaches maturity, the hashing speed has breached 50GH/s.. are you Mining? jump in the only decentralized miners pool ^__^ submitted by freeborn to Bitcoin [link] [comments]

Welcome! If you're new to Monero, please take a few minutes to learn WHY Monero is different :)

Hello new and old faces! I noticed that there are more new faces here than usual, and I hope this post can help those who are perhaps a little lost.
The vast majority of existing members are here since we feel Monero is revolutionary. Monero is a tool that people can actually use. It makes receiving payments hassle-free, since merchants and individuals no longer need to fear the source of funds they are accepting. With transparent systems like Bitcoin, Ethereum, Verge, or Dash, these people need to hope (or spend substantial resources verifying) the sender did not use the funds illicitly. Furthermore, merchants do not want all their vendors known, and individually do not want everyone to know how much they are spending. If I spend more than I should at Newegg, that's my own business.
Monero is different because every transaction is always private. There is no way for pools and exchanges to opt out of sending private transactions. Thus, Monero's anonymity set far exceeds any other coin's anonymity set. Over 86,000 transactions in the past month hid the sender and receiver, and about 99.95% of them also hid the amount (will increase to 100% of all new transactions in September)! There is no suspicion in using a private transaction, since all transactions are private. A single transaction does not stick out.*
This privacy is afforded with the best technology. I implore you to take a few minutes to learn about the four main technologies that Monero uses to provide privacy:
  1. Ring signatures hide where the money comes from. Spent inputs in a transaction are hidden among several others that also appear to be spent. Thus, no one knows which source of money is actually being spent. Think of inputs as individual dollars or euros. View a video about this topic here. Note: this is NOT the same as mixing.
  2. RingCT hides the amount. Instead of spending a known value of an input, you can cryptographically commit to a certain value without revealing what the value actually is. This is a very complicated topic, so please view this video for more information.
  3. Kovri is a work-in-progress tool to hide the transaction broadcast. Kovri will make it easy for users to hide their IP address when telling the network that they would like to make a transaction. Kovri will work with other cryptocurrencies and other projects through a common API, and Kovri can be used in a way to hide that you are using Monero at all. Kovri adds additional layers of network security for miners and pools, and it allows for the highest level of censorship resistance possible. A video for this project is not available yet, but you can check out the Kovri website. In the meantime, there are several guides to using Monero with Tor that work today, including an unofficial Tails build.
  4. Stealth addresses hide where the money goes to. Instead of sending money to a specific address directly, certain outputs are allocated for addresses, but outside observers do not know which addresses these belong to. Even if ring signatures were compromised for some reason, then people would still not know the sending address in a transaction thanks to stealth addresses. View a video about this topic here.
There are several other things that make Monero great! It has a smooth tail emission, dynamic blocks and fees, and an accessible Proof of Work (mining) algorithm. Feel free to ask around to learn more about these features. Try asking questions on the Monero StackExchange, or hop on IRC! Explore the website and community resources.
Monero's community is large, and we have several other subreddits to help organize it! Please also subscribe to the following that interest you:
  1. /xmrtrader for price speculation and talk.
  2. /MoneroMining for, er, Monero mining.
  3. /MoneroCommunity for those who want to help grow the community.
  4. /moonero for shitposts and memes.
  5. /MoneroMarket for buying and selling wares for Monero.
  6. /MoneroSupport for, you guessed it, Monero support.
Finally, Monero has the best team. Over 270 contributors have brought Monero to where it is today. The vast majority of people donate their time to help Monero, but a few get paid through the Forum Funding System (FFS). This is how Monero can be a strong project despite not taking a portion of the block rewards or launching with a premine.
Anyway, we hope you stick around beyond the hype. Monero has a lot going for it, and we hope you agree! We really need your help, since this project is entirely driven by the community!
P.S. Want a quick-start, simple your-grandma-could-do-it guide? Here's a great one!.
*You can optionally choose a very large, unusual ringsize to make the transaction stick out. This is not recommended, and normal users who leave the ringsize at the default setting will not experience any issues. Also, it's possible for a user to manually add identifying information to the tx_extra field, which is something that a user must seriously go out of their way to do.
submitted by SamsungGalaxyPlayer to Monero [link] [comments]

[H] 0.25 BTC [W] Cash in Las Vegas or By Mail spot+5%

0.25 BTC available. (Around $2500 USD)
Cash in Person off 215, Sunset Durango exit.
Spot Price- bitcoinaverage+5%
Minimum $300
No PayPal, no Venmo, no zelle.
Comment and DM.
You go first. Cash by mail, price at time of cash counting. Check my bitrated links to paxful, localbitcoins, Mycelium, freenode bitcoin-otc (and this Reddit account)
submitted by opticbit to Cash4Cash [link] [comments]

BITCOIN DIVORCE – BITCOIN CORE VS BITCOIN CASH EXPLAINED

Bitcoin and Bitcoin Cash are confusing, especially to newbies. They are likely unaware of the history and reasoning for the existence of these two coins. This ignorance is likely persisted by the censorship practised at bitcoin and Bitcointalk.org for several years. (rbitcoinbanned includes examples of the censoring.)
Most of the following is an explanation of the history of Bitcoin, when there was only one Bitcoin. Then it explains the in-fighting and why it forked into two Bitcoins: 1) Bitcoin Legacy and 2) Bitcoin Cash, which happens in the last section (THE DIVORCE). Feel free to suggest edits or corrections. Later, I will publish this on Medium as well.
BITCOIN WAS AN INSTRUMENT OF WAR
For Satoshi Nakamoto, the creator, and the initial supporters, Bitcoin was more than just a new currency. It was an instrument of war.
Who are they fighting against?
The government and central banks.
There is an abundance of evidence of this, starting with Satoshi Nakamoto’s original software.
BATTLE FOR ONLINE GAMBLING
Governments around the world ban online gambling by banning their currency from being used as payment. The original Bitcoin software included code for Poker. Yes, Poker.
Here is the original code: https://github.com/trottieoriginal-bitcoin/blob/mastesrc/uibase.cpp
Search for “Poker”, “Deal Me Out”, “Deal Hand”, “Fold”, “Call”, “Raise”, “Leave Table”, “DitchPlayer”.
Bitcoin gave the middle finger to the government and found a way to get around their ban. In the initial years, it was mainly gambling operators that used Bitcoin, such as SatoshiDice. Was this a coincidence? Gambling is one of the best, if not, the best application for Bitcoin. It was no wonder that gambling operators embraced Bitcoin, including gambling mogul Calvin Ayre.
Bitcoin enabled people to rebel against the government in other ways as well, such as Silk Road, which enabled people to buy and sell drugs.
ANTI-GOVERNMENT LIBERTARIANS AND CYPHERPUNKS
Libertarians seek to maximize political freedom and autonomy. They are against authority and state power. Cypherpunks are activists advocating widespread use of cryptography as a route to social and political change. Their common thread is their dislike for the government.
Bitcoin was created by libertarians and cypherpunks.
Satoshi Nakamoto used cryptography mailing lists to communicate with other cypherpunks such as Wei Dai. Satoshi Nakamoto wrote:
“It’s very attractive to the libertarian viewpoint if we can explain it properly. I’m better with code than with words though.”
Satoshi Nakamoto was rebellious to government control. Someone argued with Satoshi by stating: “You will not find a solution to political problems in cryptography.” Satoshi replied:
"Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.
Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.”
Nakamoto was critical of the central bank. He wrote:
"The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts.”
It is no wonder that the first supporters of Bitcoin were libertarians as well, who agreed with Satoshi’s ideology and saw the potential of Bitcoin to fulfill their ideology.
One of the biggest benefits that Bitcoin supporters want, is “censorship resistance”. What does this mean? It means: to be able to spend your money any way you want. It means: how to get around government regulations and bans. It means: how to do something despite the government.
Roger Ver, an early Bitcoin supporter, heavily criticizes the government for engaging in wars around the world that kills civilians and children. When he ran as a Libertarian candidate in an election against the Republicans and Democrats, he criticized the ATF and FBI for murdering children in their raid in Waco, Texas. At the time, Ver and many other merchants were selling fireworks on eBay without a license. The ATF charged Ver and sent him to prison, but did not charge any of the other merchants. (https://youtu.be/N6NscwzbMvI?t=47m50s) This must have angered Ver a lot.
Since then, Ver has been on a mission to weaken and shrink the government. When he learned about Bitcoin in February 2011, he saw it as his weapon to accomplish his goal…his instrument of war.
Ver was already a multi-millionaire entrepreneur. He sold his company, bought Bitcoins and was the first to invest in Bitcoin startups, such as Bitpay, Blockchain.info, Kraken, Bitcoin.com, Bitcoinstore.com and others. Then he worked full-time to promote Bitcoin. Bitpay became the largest Bitcoin payment processor. Blockchain.info became the largest provider of Bitcoin wallets. Much of the growth of Bitcoin since 2011 can be attributed to Ver's companies.
More evidence of Ver’s anti-government sentiment emerged when he recently announced that he is working to create a society with no government at all (FreeSociety.com).
HOW TO WIN THE WAR
To win the war, Bitcoin must be adopted and widely used by the masses. When people use Bitcoin instead of their national fiat currency, the government becomes weaker. The government can no longer do the following:
It is not only important to get the masses to adopt Bitcoin, but it is also important to get them to adopt it quickly. If it takes a long time, governments will have more time to think twice about allowing Bitcoin to exist and will have more justifications to ban it. They can claim that Bitcoin is used for ransomware, terrorism, etc. If Bitcoin is adopted by the masses to buy everyday goods, such as food and clothing, then it will be harder for them to stop it.
IS BITCOIN WINNING?
Yes and no.
Bitcoin has definitely become more popular over the years. But, it is not achieving Satoshi Nakamoto’s goals.
Satoshi defined Bitcoin and his goal. The title of his white paper is:
“Bitcoin: A Peer-to-Peer Electronic Cash System”
Is Bitcoin being used as cash? Unfortunately, it is not. It is being used as a store of value. However, the title of Satoshi’s white paper was not:
“Bitcoin: A Store of Value”
There is utility in having a store of value, of course. People need it and Bitcoin has superior features to gold. Therefore, it is likely that Bitcoin can continue gaining in popularity and price as it continues to compete and take market share away from gold.
However, both gold and Bitcoin are not being used as currency.
If Bitcoin does not replace fiat currencies, will it weaken governments? No, because no matter how many people buy gold or Bitcoin (as a store of value), they do not weaken governments. To do so, Bitcoin must replace fiat currencies.
BITCOIN LOSING TO FIAT
In the initial years, Bitcoin was taking market share from fiat currencies. But, in the past year, it is losing market share. Dell, Wikipedia and airlines have stopped accepting bitcoin. SatoshiDice and Yours switched to Bitcoin Cash. According to Businessinsider:
"Out of the leading 500 internet sellers, just three accept bitcoin, down from five last year.”
Why is Bitcoin losing market share to fiat? According to Businessinsider:
“when they do try to spend it, it often comes with high fees, which eliminates the utility for small purchases, or it takes a long time to complete the transaction, which could be a turn-off.”
Why are there high fees and long completion times?
Because of small blocks.
SCALING DEBATE – THE BIG MARITAL FIGHT
Why isn't the block size increased?
Because Core/Blockstream believes that big blocks lead to centralization to fewer people who can run the nodes. They also believe that off-chain solutions will provide faster and cheaper transactions. There are advocates for bigger blocks, but because Core/Blockstream control the software, Bitcoin still has the original, one megabyte block since 8 years ago. (Core developers control Bitcoin’s software and several of the key Core developers are employed by Blockstream, a private, for-profit company.)
Businesses, users and miners have asked for four years for the block size to be increased. They point out that Satoshi has always planned to scale Bitcoin by increasing the block size. For four years, Core/Blockstream has refused.
The Bitcoin community split into two factions:
This scaling debate and in-fighting went on for several years. You can read more about it at: https://np.reddit.com/BitcoinMarkets/comments/6rxw7k/informative_btc_vs_bch_articles/dl8v4lp/?st=jaotbt8m&sh=222ce783
SMALL BLOCKERS VS BIG BLOCKERS
Why has Blockstream refused to increase block size? There are a few possible reasons:
  1. They truly believe that big blocks means that fewer people would be able to run full nodes, which would lead to centralization and that the best roadmap is with off-chain solutions. (However, since 2009, hard disk space has exploded. A 4TB disk costs $100 and can store 10 years of blocks. This price is the equivalent to a handful of Bitcoin transaction fees. Also, Satoshi never planned on having every user run full nodes. He envisioned server farms. Decentralization is needed to achieve censorship-resistance and to make the blockchain immutable. This is already accomplished with the thousands of nodes. Having millions or billions of nodes does not increase the censorship-resistance and does not make the blockchain more immutable.)
  2. Blockstream wants small blocks, high fees and slow confirmations to justify the need for their off-chain products, such as Liquid. Blockstream sells Liquid to exchanges to move Bitcoin quickly on a side-chain. Lightning Network will create liquidity hubs, such as exchanges, which will generate traffic and fees for exchanges. With this, exchanges will have a higher need for Liquid. This is the only way that Blockstream will be able to repay the $76 million to their investors.
  3. They propose moving the transactions off the blockchain onto the Lightning Network, an off-chain solution. By doing so, there is a possibility of being regulated by the government (see https://np.reddit.com/btc/comments/7gxkvj/lightning_hubs_will_need_to_report_to_irs/). One of Blockstream’s investors/owners is AXA. AXA’s CEO and Chairman until 2016 was also the Chairman of Bilderberg Group. The Bilderberg Group is run by politicians and bankers. According to GlobalResearch, Bilderberg Group wants “a One World Government (World Company) with a single, global marketplace…and financially regulated by one ‘World (Central) Bank’ using one global currency.” Does Bilderberg see Bitcoin as one component of their master plan?
  4. They do not like the fact that most of the miners are in China. In this power-struggle, they would like to take away control and future revenues from China, by scaling off-chain.
Richard Heart gives his reasons why block size should not be increased, in this video: https://www.youtube.com/watch?time_continue=2941&v=iFJ2MZ3KciQ
He cites latency as a limitation and the reason for doing off-chain scaling. However, latency has been dramatically reduced since 2009 when Bitcoin started with 1MB blocks. Back then, most residential users had 5-10 Mbps internet speed. Now, they have up to 400 Mbps up to 1 Gbps. That’s a 40 to 200X increase. Back in 2009, nobody would’ve thought that you can stream 4k videos.
He implies that 10 minute intervals between block creations are needed in order for the blocks to sync. If internet speed has increased by 40-200X, why can’t the block size be increased?
He claims that bigger blocks make it more difficult for miners to mine the blocks, which increases the chances of orphaned blocks. However, both speeds and the number of mining machines have increased dramatically, causing hashing power on the network to exponentially increase since 2009. This will likely continue increasing in the future.
Richard says that blocks will never be big enough to do 2,000 transactions per second (tps). He says that all of the forks in the world is only going to get 9 tps. Since his statement, Peter Rizun and Andrew Stone have shown that a 1 core CPU machine with 3 Mbps internet speed can do 100 tps. (https://youtu.be/5SJm2ep3X_M) Rizun thinks that visa level (2,000 tps) can be achieved with nodes running on 4-core/16GB machines, bigger blocks and parallel processing to take advantage of the multiple CPU cores.
Even though Rizun and Stone are showing signifiant increases in tps with bigger blocks, the big blockers have never been against a 2nd layer. They’ve always said that you can add a 2nd layer later.
CORE/BLOCKSTREAM VS MINERS
According to Satoshi, Bitcoin should be governed by those with the most hashing power. One hash, one vote. However, Core/Blockstream does not agree with this. Due to refusals for four years to increase block size, it would seem that Core/Blockstream has been able to wrestle control away from miners. Is this because they want control? Is this because they don’t want the Chinese to have so much, or any, control of Bitcoin? Is this because they prefer to eventually move the revenue to the West, by moving most of the transactions off chain?
DIFFERENT AGENDAS
It would seem that Businesses/Users and Core/Blockstream have very different agendas.
Businesses/Users want cheap and fast transactions and see this as an immediate need. Core/Blockstream do not. Here are some quotes from Core/Blockstream:
Greg Maxwell: "I don't think that transaction fees mattering is a failing-- it's success!”
Greg Maxwell: "fee pressure is an intentional part of the system design and to the best of the current understanding essential for the system's long term survial. So, uh, yes. It's good."
Greg Maxwell: "There is a consistent fee backlog, which is the required criteria for stability.”
Peter Wuille: "we - as a community - should indeed let a fee market develop, and rather sooner than later”
Luke-jr: "It is no longer possible to keep fees low.”
Luke-jr: "Just pay a $5 fee and it'll go through every time unless you're doing something stupid.”
Jorge Timón: "higher fees may be just what is needed”
Jorge Timón: "Confirmation times are fine for those who pay high fees.”
Jorge Timón: “I think Adam and I agree that hitting the limit wouldn't be bad, but actually good for an young and immature market like bitcoin fees.”
Mark Friedenbach: "Slow confirmation, high fees will be the norm in any safe outcome."
Wladimir J. van der Laan: “A mounting fee pressure, resulting in a true fee market where transactions compete to get into blocks, results in urgency to develop decentralized off-chain solutions.”
Greg Maxwell: “There is nothing wrong with full blocks, and blocks have been “full” relative to what miners would produce for years. Full blocks is the natural state of the system”
Wladimir J. van der Laan: “A mounting fee pressure, resulting in a true fee market where transactions compete to get into blocks, results in urgency to develop decentralized off-chain solutions. I'm afraid increasing the block size will kick this can down the road and let people (and the large Bitcoin companies) relax”
Why don’t Core/Blockstream care about cheap and fast transactions? One possible reason is that they do not use Bitcoin. They might own some, but they do not spend it to buy coffee and they do not use it to pay employees. They aren’t making hundreds of transactions per day. They do not feel the pain. As engineers, they want a technical utopia.
Businesses/Users on the other hand, feel the pain and want business solutions.
An analogy of this scaling debate is this:
You have a car that is going 50 kph. The passengers (Bitcoin users) want to go 100 kph today, but eventually in the future, they want to go 200 kph. The car is capable of going 100 kph but not 200 kph. Big blockers are saying: Step on the accelerator and go 100 kph. Small blockers are saying: Wait until we build a new car, which will go 200 kph. Meanwhile, the passengers are stuck at 50 kph.
Not only do Big blockers think that the car can simply go faster by stepping on the accelerator, they have already shown that the car can go even faster by adding a turbocharger (even bigger blocks) and making sure that every cylinder is firing (parallel process on multiple CPU cores). In addition, they are willing to use the new car if and when it gets built.
CORE/BLOCKSTREAM VS USERS
If you watch this debate from 2017-02-27 (https://youtu.be/JarEszFY1WY), an analogy can be made. Core/Blockstream is like the IT department and Bitcoin.com (Roger Ver and Jake Smith) is like the Sales/Marketing department (users). Core/Blockstream developers hold, but do not use Bitcoin. Blockstream does not own nor use Bitcoin.
Roger Ver's companies used to use or still use Bitcoin every day. Ver’s MemoryDealers was the first company to accept Bitcoin. Johnny seems to think that he knows what users want, but he rarely uses Bitcoin and he is debating one of the biggest users sitting across the table.
In all companies, Marketing (and all other departments) are IT’s customer. IT must do what Marketing wants, not the other way around. If Core/Blockstream and Roger Ver worked in the same company, the CEO would tell Core/Blockstream to give Roger what he wants or the CEO would fire Core/Blockstream.
But they don’t work for the same company. Roger and other businesses/users cannot fire Core/Blockstream.
Core/Blockstream wants to shoot for the best technology possible. They are not interested in solving short term problems, because they do not see high fees and long confirmation times as problems.
BLOCKSTREAM VS LIBERTARIANS
There are leaders in each camp. One can argue that Blockstream is the leader of the Small Blockers and Roger Ver (supported by Gavin Andresen, Calvin Ayre, businesses and some miners) is the leader of the Big Blockers.
Blockstream has openly called for full blocks and higher fees and they are preparing to scale with Lightning Network. As mentioned before, there is a possibility that Lightning hubs will be regulated by the government. Luke-jr tweeted “But State has authority from God” (https://twitter.com/LukeDashjstatus/934611236695789568?s=08)
Roger Ver wants Bitcoin to regulate the government, not the other way around. He wants to weaken and shrink the government. In addition to separation of church and state, he wants to see separation of money and state. He felt that Bitcoin can no longer do this. He pushed for solutions such as Bitcoin Unlimited.
THE DIVORCE
To prepare for off-chain scaling, Core/Blockstream forked Bitcoin by adding Segwit, which I will refer to as Bitcoin Legacy. This is still referred to by the mainstream as Bitcoin, and it has the symbol BTC.
After four years of refusal by Blockstream, the big blockers, out of frustration, restored Bitcoin through a fork, by removing Segwit from Bitcoin Legacy and increased the block size. This is currently called Bitcoin Cash and has the symbol BCH.
Bitcoin Legacy has transformed from cash to store-of-value. It had a 8 year head start in building brand awareness and infrastructure. It’s likely that it will continue growing in popularity and price for a while.
Bitcoin Cash most resembles Satoshi’s “peer-to-peer cash”. It will be interesting to see if it will pick up from where Bitcoin Legacy left off and take market share in the fiat currency space. Libertarians and cypherpunks will be able to resume their mission of weakening and shrinking the government by promoting Bitcoin Cash.
Currently, Bitcoin Cash can fulfill the role of money, which includes medium of exchange (cash) and store-of-value functions. It will be interesting to see if off-chain scaling (with lower fees and faster confirmations) will enable Bitcoin Legacy to be used as a currency as well and fulfill the role of money.
This is an example of the free market and open competition. New companies divest or get created all the time, to satisfy different needs. Bitcoin is no different.
Small blockers and big blockers no longer need to fight and bicker in the same house. They have gone their separate ways.
Both parties have want they want. Blockstream can store value and generate revenue from their off-chain products to repay their investors. Libertarians (and gambling operators) can rejoice and re-arm with Bitcoin Cash to take on the government. They can continue with their mission to get freedom and autonomy.
submitted by curt00 to btc [link] [comments]

[Very long, very serious] Development summary week ending 18th April 2014

When I got my first full time job, I used to try implementing requests from everyone as they came in, and for a while people really loved that I listened to their requests. Over time, however, things started to go wrong. I’d apply a change someone asked for, and in doing so would break something elsewhere in the code, in some subtle way that was missed in short-term testing. I’d fix that second bug and reveal a third. I’d fix that just in time for a new request to come in, and the process repeat. This led to the term “Bug whack-a-mole”, wherein I was spending time mostly fixing bugs introduced to live systems through rushing through earlier bug fixes.
So this week, we’ve had a lot of people asking about changes to proof-of-work, especially X11, or even moving to proof of stake, primarily in an attempt to address risk of a 51% attack. A 51% attack is where one actor (person, group, organisation, whatever) gains control of enough resources to be able to create their own blockchain, isolated from the main blockchain, at a rate at least as quickly as the main blockchain is being created. They can then spend Dogecoins on the main blockchain, before releasing their fake blockchain; if their fake blockchain is longer than the existing blockchain, nodes will switch to the new blockchain (as they would when repairing a fork), and essentially the spent Dogecoin on the main blockchain are reversed and can be spent again. This is mostly of consequence to exchanges and payment processors (such as Moolah), who are most likely to end up holding the loss from the double-spend.
The concern about a 51% attack stems from a couple of weeks ago now, when Wafflepool was around 50% of the network hashrate (mining power). It’s still high (at the time of wring about 32GH/s out of almost 74GH/s, or about 43%), but it is diminishing as a proportion.
Lets talk about proof of stake first, as this one’s simpler. Proof of stake has been suggested as a way of avoiding the risk of Wafflepool having control of too many mining resources by itself, by changing from securing the blockchain through computational resources (work), to using number of Dogecoin held. The theory is that those with most Dogecoins have most to lose, and will act in their own interests. Major examples of proof of stake coins include Peercoin, Mintcoin and more recently Blackcoin.
However, this essentially means we take control from Wafflepool, and hand it to Cryptsy (who are considered most likely to be the holder of some of the huge Dogecoin wallets out there). I by no means expect either organisation to attempt a 51% attack, but hopefully it’s clear that simply switching risks isn’t actually improving things. I’ve also had significant concerns raised from the merchant/payment processor community about potential impact of proof of stake, and that it may encourage hoarding (as coins are awarded for holding coins, rather than for mining). The price instability of Mintcoin and Blackcoin (and that Peercoin appears to only avoid this through very high transaction fees to keep the entire network inert) does not encourage confidence, either. For now, proof of stake remains something we’re keeping in mind, primarily in case price does not react as anticipated to mining reward decreases over time, but certainly we’re not eager to rush into such a change.
Before I get into a discussion on proof of work, let me summarise this quickly; right now, uncertainty about changes is holding back our community from adopting ASICs. It’s high risk to spend hundreds, thousands or in some cases significantly more on ASIC hardware which could be left useless if we move. Those who have already purchased ASICs to support the Dogecoin hashrate would most likely have to mine Litecoin to recover sunk costs, if we did move. ASICs are virtually inevitable, and in our assessment we are better off pushing for rapid adoption, rather than expending resources delaying a problem which will re-occur later.
At the time of writing the development team has no plans to change proof of work algorithm outside of the eventuality of a major security break to Scrypt. We are focusing on mitigation approaches in case of a 51% attack, and adoption of the coin as the most sustainable approaches to dealing with this risk.
The X11 algorithm has been proposed as an alternative proof of work algorithm. X11, for those unaware, was introduced with Darkcoin. It’s a combination of 11 different SHA-3 candidate algorithms, using multiple rounds of hashing. The main advantage championed for Darkcoin is that current implementations run cooler on GPU hardware. Beyond that, there’s a lot of confusion over what it does and does not do. As I’m neither an algorithms or electronics specialist, I recruited a colleague who previously worked on the CERN computing grid to assist, and the following is primarily his analysis. A full technical report is coming for anyone who really likes detail, this is just a summary:
A lot of people presume X11 is ASIC resistant; it’s not. Candidate algorithms for SHA-3 were assessed on a number of criteria, including simplicity to implement in hardware. All 11 algorithms have been implemented in FPGA hardware, and several in ASIC hardware already. The use of multiple algorithms does significantly complicate ASIC development, as it means the resulting chip would likely be extremely large. This has consequences for production, as the area of a chip is the main determining factor for likelihood of an error in the chip.
The short version being that while yes it would take significant resources to make an efficient ASIC for X11, for a long time Scrypt was considered infeasible to adapt to ASICs. As stated earlier, any move would most likely be nothing more than an extremely expensive and risky delaying manoeuvre. ASIC efficiency would also depend heavily on ability to optimise the combination of the algorithms; a naive implementation would run at around the rate of the slowest hashing algorithm, however if any common elements could be found amongst the algorithms, it may be that this could be improved upon significantly
There are also significant areas of concern with regards to X11. The “thermal efficiency” is most likely a result of the algorithm being a poor fit for GPU hardware. This means that GPU mining is closer to CPU mining (the X11 Wiki article suggests a ratio of 3:1 for GPU/CPU mining performance), however it also means that if a way of was found to improve performance there could be significantly faster software miners, leading to an ASIC-like edge without any of the hardware development costs. The component algorithms are all relatively new, and several were rejected during the SHA-3 competition for security concerns (see http://csrc.nist.gov/groups/ST/hash/sha-3/Round2/documents/Round2_Report_NISTIR_7764.pdf for full details). Security criteria for SHA-3 algorithms was also focused on ability to generate collisions, rather than on producing hashes with specific criteria (such as number of leading 0s, which is how proof of work is usually assessed).
X11 is a fascinating algorithm for new coins, however I would consider it exceptionally high risk for any existing coin to adopt.
Beyond algorithm analysis, this week has been mostly about testing 1.7. Last weekend Patrick raised the issue that we had been incorrectly running the automated tests, which had led to several automated test failures being missed earlier. This led to other tasks being dropped as we quickly reworked the tests to match Dogecoin parameters instead of Bitcoin. So far, all tests have passed successfully once updated to match Dogecoin, however this work continues. On the bright side, it turns out we have a lot more automated tests than we realised, which is very useful for later development.
The source code repository for Dogecoin now also uses Travis CI, which sanity-checks patches submitted to the project, to help us catch any potential problems earlier, thanks to Tazz for leading the charge on that. This is particularly important as of course we’re developing on different platforms (Windows, OS X, Linux) and what works on one, may not work on others. Over time, this should be a significant time saver for the developers. For anyone wanting to help push Dogecoin forward, right now the most productive thing to be doing is testing either Dogecoin, or helping Bitcoin Core test pull requests. Feel free to drop by our Freenode channel for guidance on getting started with either.
Right now, I’m working on the full technical report on X11, and will then be back working on the payment protocol for Dogecoin. I’ve approached a few virus scanning software companies about offering their products for Dogecoin, with so far no response, but will update you all if I hear more.
Lastly, the next halvening (mining reward halving) is currently expected late on the 27th or early on the 28th, both times GMT. Given that it was initially expected on the 25th, we’re obviously seeing some slippage in estimates, and a total off the top of my head guess would be that we’ll see it around 0500 GMT on the 28th at this rate. I have taken the 28th off from the day job, and will be around both before and after in case of any problems (love you guys, not getting up at 5am to check on the blockchain, though!)
submitted by rnicoll to dogecoin [link] [comments]

IRC Log from Ravencoin Open Developer Meeting - Aug 24, 2018

[14:05] <@wolfsokta> Hello Everybody, sorry we're a bit late getting started
[14:05] == block_338778 [[email protected]/web/freenode/ip.72.214.222.226] has joined #ravencoin-dev
[14:06] <@wolfsokta> Here are the topics we would like to cover today • 2.0.4 Need to upgrade - What we have done to communicate to the community • Unique Assets • iOS Wallet • General Q&A
[14:06] == Chatturga changed the topic of #ravencoin-dev to: 2.0.4 Need to upgrade - What we have done to communicate to the community • Unique Assets • iOS Wallet • General Q&A
[14:06] <@wolfsokta> Daben, could you mention what we have done to communicate the need for the 2.0.4 upgrade?
[14:07] == hwhwhsushwban [[email protected]/web/freenode/ip.172.58.37.35] has joined #ravencoin-dev
[14:07] <@wolfsokta> Others here are free to chime in where they saw the message first.
[14:07] == hwhwhsushwban [[email protected]/web/freenode/ip.172.58.37.35] has quit [Client Quit]
[14:08] Whats up bois
[14:08] hi everyone
[14:08] hi hi
[14:08] <@wolfsokta> Discussing the 2.0.4 update and the need to upgrade.
[14:08] <@Chatturga> Sure. As most of you are aware, the community has been expressing concerns with the difficulty oscillations, and were asking that something be done to the difficulty retargeting. Many people submitted suggestions, and the devs decided to implement DGW.
[14:09] <@Tron> I wrote up a short description of why we're moving to a new difficulty adjustment. https://medium.com/@tronblack/ravencoin-dark-gravity-wave-1da0a71657f7
[14:09] <@Chatturga> I have made posts on discord, telegram, bitcointalk, reddit, and ravencointalk.org from testnet stages through current.
[14:10] <@Chatturga> If there are any other channels that can reach a large number of community members, I would love to have more.
[14:10] <@wolfsokta> Thanks Tron, that hasn't been shared to the community at large yet, but folks feel free to share it.
[14:10] When was this decision made and by whom and how?
[14:10] <@Chatturga> I have also communicated with the pool operators and exchanges about the update. Of all of the current pools, only 2 have not yet updated versions.
[14:11] <@wolfsokta> The decision was made by the developers through ongoing requests for weeks made by the community.
[14:12] <@wolfsokta> Evidence was provided by the community of the damages that could be caused to projects when the wild swings continue.
[14:12] So was there a meeting or vote? How can people get invited
[14:12] <@Tron> It was also informed by my conversations with some miners that recommended that we make the change before the coin died. They witnessed similar oscillations from which other coins never recovered.
[14:13] only two pools left to upgrade is good, what about the exchanges? Any word on how many of those have/have not upgraded?
[14:13] <@wolfsokta> We talked about here in our last meeting Bruce_. All attendees were asked if they had any questions or concerns.
[14:13] == blondfrogs [[email protected]/web/freenode/ip.185.245.87.219] has joined #ravencoin-dev
[14:13] == roshii [[email protected]/web/freenode/ip.41.251.25.100] has joined #ravencoin-dev
[14:13] sup roshii long time no see
[14:14] <@Chatturga> Bittrex, Cryptopia, and IDCM have all either updated or have announced their intent to update.
[14:14] == wjcgiwgu283ik3cj [[email protected]/web/freenode/ip.172.58.37.35] has joined #ravencoin-dev
[14:15] sup russki
[14:15] what's the status here?
[14:15] I don’t think that was at all clear from the last dev meeting
[14:15] I can’t be the only person who didn’t understand it
[14:15] <@wolfsokta> Are there any suggestions on how to communicate the need to upgrade even further? I am concerned that others might also not understand.
[14:17] I’m not sold on the benefit and don’t understand the need for a hard fork — I think it’s a bad precedent to simply go rally exchanges to support a hard fork with little to no discussion
[14:17] so just to note, the exchanges not listed as being upgraded or have announced their intention to upgrade include: qbtc, upbit, and cryptobridge (all with over $40k usd volume past 24 hours according to coinmarketcap)
[14:18] <@wolfsokta> I don't agree that there was little or no discussion at all.
[14:19] <@wolfsokta> Looking back at our meeting notes from two weeks ago "fork" was specifically asked about by BrianMCT.
[14:19] If individual devs have the power to simple decide to do something as drastic as a hard fork and can get exchanges and miners to do it that’s got a lot of issues with centralization
[14:19] <@wolfsokta> It had been implemented on testnet by then and discussed in the community for several weeks before that.
[14:19] == under [[email protected]/web/freenode/ip.72.200.168.56] has joined #ravencoin-dev
[14:19] howdy
[14:19] Everything I’ve seen has been related to the asset layer
[14:19] I have to agree with Bruce_, though I wasn't able to join the last meeting here. That said I support the fork
[14:20] Which devs made this decision to do a fork and how was it communicated?
[14:20] well mostly the community made the decision
[14:20] Consensus on a change is the heart of bitcoin development and I believe the devs have done a great job building that consensus
[14:20] a lot of miners were in uproar about the situation
[14:20] <@wolfsokta> All of the devs were supporting the changes. It wasn't done in isolation at all.
[14:21] This topic has been a huge discussion point within the RVN mining community for quite some time
[14:21] the community and miners have been having issues with the way diff is adjusted for quite some time now
[14:21] Sure I’m well aware of that -
[14:21] Not sold on the benefits of having difficulty crippled by rented hashpower?
[14:21] The community saw a problem. The devs got together and talked about a solution and implemented a solution
[14:21] I’m active in the community
[14:22] So well aware of the discussions on DGW etc
[14:22] Hard fork as a solution to a problem community had with rented hashpower (nicehash!!) sounds like the perfect decentralized scenario!
[14:23] hard forks are very dangerous
[14:23] mining parties in difficulty drops are too
[14:23] <@wolfsokta> Agreed, we want to keep them to an absolute minimum.
[14:23] But miners motivation it’s the main vote
[14:24] What would it take to convince you that constantly going from 4 Th/s to 500 Gh/s every week is worse for the long term health of the coin than the risk of a hard fork to fix it?
[14:24] == Tron [[email protected]/web/freenode/ip.173.241.144.77] has quit [Ping timeout: 252 seconds]
[14:24] This hardfork does include the asset layer right? if so why is it being delayed in implementation?
[14:24] <@wolfsokta> Come back Tron!
[14:24] coudl it have been implement through bip9 voting?
[14:24] also hard fork is activated by the community! that's a vote thing!
[14:24] @mrsushi to give people time to upgrade their wallet
[14:25] @under, it would be much hard to keep consensus with a bip9 change
[14:25] <@wolfsokta> We investigated that closely Under.
[14:25] == Tron [[email protected]/web/freenode/ip.173.241.144.77] has joined #ravencoin-dev
[14:25] <@wolfsokta> See Tron's post for more details about that.
[14:25] <@spyder_> Hi Tron
[14:25] <@wolfsokta> https://medium.com/@tronblack/ravencoin-dark-gravity-wave-1da0a71657f7
[14:25] Sorry about that. Computer went to sleep.
[14:26] I'm wrong
[14:26] 2 cents. the release deadline of october 31st puts a bit of strain on getting code shipped. (duh). but fixing daa was important to the current health of the coin, and was widely suppported by current mining majority commuity. could it have been implemented in a different manner? yes . if we didnt have deadlines
[14:27] == wjcgiwgu283ik3cj [[email protected]/web/freenode/ip.172.58.37.35] has quit [Quit: Page closed]
[14:27] sushi this fork does not include assets. it's not being delayed though, we're making great progress for an Oct 31 target
[14:28] I don’t see the urgency but my vote doesn’t matter since my hash power is still CPUs
[14:28] <@wolfsokta> We're seeing the community get behind the change as well based on the amount of people jumping back in to mine through this last high difficulty phase.
[14:28] So that will be another hardfork?
[14:28] the fork does include the asset code though set to activate on oct 30th
[14:28] yes
[14:29] <@wolfsokta> Yes, it will based on the upgrade voting through the BIP9 process.
[14:29] I wanted to ask about burn rates from this group: and make a proposal.
[14:29] we're also trying hard to make it the last for awhile
[14:29] Can you clear up the above — there will be this one and another hard fork?
[14:29] <@wolfsokta> Okay, we could discuss that under towards the end of the meeting.
[14:30] If this one has the asset layer is there something different set for October
[14:30] <@wolfsokta> Yes, there will be another hard fork on October 31st once the voting process is successful.
[14:31] <@wolfsokta> The code is in 2.0.4 now and assets are active on testnet
[14:31] Bruce, the assets layer is still being worked on. Assets is active on mainnet. So in Oct 31 voting will start. and if it passes, the chain will fork.
[14:31] this one does NOT include assets for mainnet Bruce -- assets are targeted for Oct 31
[14:31] not***
[14:31] not active****
[14:31] correct me if I'm wrong here, but if everyone upgrades to 2.0.4 for this fork this week, the vote will automatically pass on oct 31st correct? nothing else needs to be done
[14:31] Will if need another download or does this software download cover both forks?
[14:31] <@wolfsokta> Correct Urgo
[14:32] thats how the testnet got activated and this one shows "asset activation status: waiting until 10/30/2018 20:00 (ET)"
[14:32] Will require another upgrade before Oct 31
[14:32] thank you for the clarification wolfsokta
[14:32] <@wolfsokta> It covers both forks, but we might have additional bug fixes in later releases.
[14:32] So users DL one version now and another one around October 30 which activates after that basically?
[14:33] I understand that, but I just wanted to make it clear that if people upgrade to this version for this fork and then don't do anything, they are also voting for the fork on oct 31st
[14:33] Oh okay — one DL?
[14:33] Bruce, Yes.
[14:33] Ty
[14:33] well there is the issue that there maybe some further consensus bugs dealing with the pruneability of asset transactions that needs to be corrected between 2.0.4 and mainnet. so i would imagine that there will be further revisions required to upgrade before now and october 31
[14:33] @under that is correct.
[14:34] I would highly recommend bumping the semver up to 3.0.0 for the final pre 31st release so that the public know to definitely upgrade
[14:34] @under +1
[14:35] out of curiosity, have there been many bugs found with the assets from the version released in july for testnet (2.0.3) until this version? or is it solely a change to DGW?
[14:35] <@wolfsokta> That's not a bad idea under.
[14:35] <@spyder_> @under good idea
[14:35] @urgo. Bugs are being found and fixed daily.
[14:35] Any time the protocol needs to change, there would need to be a hard fork (aka upgrade). It is our hope that we can activate feature forks through the BIP process (as we are doing for assets). Mining pools and exchanges will need to be on the newest software at the point of asset activation - should the mining hash power vote for assets.
[14:35] blondfrogs: gotcha
[14:35] There have been bugs found (and fixed). Testing continues. We appreciate all the bug reports you can give us.
[14:36] <@wolfsokta> Yes! Thank you all for your help in the community.
[14:37] (pull requests with fixes and test coverage would be even better!)
[14:37] asset creation collision is another major issue. current unfair advantage or nodes that fore connect to mining pools will have network topologies that guarantee acceptance. I had discussed the possibility of fee based asset creation selection and i feel that would be a more equal playing ground for all users
[14:38] *of nodes that force
[14:38] <@wolfsokta> What cfox said, we will always welcome development help.
[14:38] So just to make sure everyone know. When assets is ready to go live on oct 31st. Everyone that wants to be on the assets chain without any problems will have to download the new binary.
[14:39] <@wolfsokta> The latest binary.
[14:39] under: already in the works
[14:39] excellent to hear
[14:39] == UserJonPizza [[email protected]/web/freenode/ip.24.218.60.237] has joined #ravencoin-dev
[14:39] <@wolfsokta> Okay, we've spent a bunch of time on that topic and I think it was needed. Does anybody have any other suggestions on how to get the word out even more?
[14:40] maybe preface all 2.0.X releases as pre-releases... minimize the number of releases between now and 3.0 etc
[14:41] <@wolfsokta> Bruce_ let's discuss further offline.
[14:41] wolfsokta: which are the remaining two pools that need to be upgraded? I've identified qbtc, upbit, and cryptobridge as high volume exchanges that haven't said they were going to do it yet
[14:41] so people can help reach out to them
[14:41] f2pool is notoriously hard to contact
[14:41] are they on board?
[14:42] <@wolfsokta> We could use help reaching out to QBTC and Graviex
[14:42] I can try to contact CB if you want?
[14:42] <@Chatturga> The remaining pools are Ravenminer and PickAxePro.
[14:42] <@Chatturga> I have spoken with their operators, the update just hasnt been applied yet.
[14:42] ravenminer is one of the largest ones too. If they don't upgrade that will be a problem
[14:42] okay good news
[14:42] (PickAxePro sounds like a Ruby book)
[14:43] I strongly feel like getting the word out on ravencoin.org would be beneficial
[14:44] that site is sorely in need of active contribution
[14:44] Anyone can volunteer to contribute
[14:44] <@wolfsokta> Okay, cfox can you talk about the status of unique assets?
[14:44] sure
[14:45] <@wolfsokta> I'll add website to the end of our topics.
[14:45] code is in review and will be on the development branch shortly
[14:45] would it make sense to have a page on the wiki (or somewhere else) that lists the wallet versions run by pools & exchanges?
[14:45] will be in next release
[14:45] furthermore, many sites have friendly link to the standard installers for each platform, if the site linked to the primary installers for each platform to reduce github newb confusion that would be good as well
[14:46] likely to a testnetv5 although that isn't settled
[14:46] <@wolfsokta> Thanks cfox.
[14:46] <@wolfsokta> Are there any questions about unique assets, and how they work?
[14:47] after the # are there any charachters you cant use?
[14:47] will unique assets be constrained by the asset alphanumeric set?
[14:47] ^
[14:47] <@Chatturga> @Urgo there is a page that tracks and shows if they have updated, but it currently doesnt show the actual version that they are on.
[14:47] a-z A-Z 0-9
[14:47] <@Chatturga> https://raven.wiki/wiki/Exchange_notifications#Pools
[14:47] There are a few. Mostly ones that mess with command-line
[14:47] you'll be able to use rpc to do "issueunique MATRIX ['Neo','Tank','Tank Brother']" and it will create three assets for you (MATRIX#Neo, etc.)
[14:47] @cfox - No space
[14:48] @under the unique tags have an expanded set of characters allowed
[14:48] Chatturga: thank you
[14:48] @UJP yes there are some you can't use -- I'll try to post gimmie a sec..
[14:49] Ok. Thank you much!
[14:49] 36^36 assets possible and 62^62 uniques available per asset?
[14:49] <@spyder_> std::regex UNIQUE_TAG_CHARACTERS("^[[email protected]$%&*()[\\]{}<>_.;?\\\\:]+$");
[14:50] regex UNIQUE_TAG_CHARACTERS("^[[email protected]$%&*()[\\]{}<>_.;?\\\\:]+$")
[14:50] oh thanks Mark
[14:51] <@wolfsokta> Okay, next up. I want to thank everybody for helping test the iOS wallet release.
[14:51] <@wolfsokta> We are working with Apple to get the final approval to post it to the App Store
[14:51] @under max asset length is 30, including unique tag
[14:51] Does the RVN wallet have any other cryptos or just RVN?
[14:52] == BruceFenton [[email protected]/web/freenode/ip.67.189.233.170] has joined #ravencoin-dev
[14:52] will the android and ios source be migrated to the ravenproject github?
[14:52] I've been adding beta test users. I've added about 80 new users in the last few days.
[14:52] <@wolfsokta> Just RVN, and we want to focus on adding the asset support to the wallet.
[14:53] == Bruce_ [[email protected]/web/freenode/ip.67.189.233.170] has quit [Ping timeout: 252 seconds]
[14:53] <@wolfsokta> Yes, the code will also be freely available on GitHub for both iOS and Android. Thank you Roshii!
[14:53] Would you consider the iOS wallet to be a more secure place for one's holdings than say, a Mac connected to the internet?
[14:53] will there be a chance of a more user freindly wallet with better graphics like the iOS on PC?
[14:53] the android wallet is getting updated for DGW, correct?
[14:53] <@wolfsokta> That has come up in our discussion Pizza.
[14:54] QT framework is pretty well baked in and is cross platform. if we get some qt gurus possibly
[14:54] Phones are pretty good because the wallet we forked uses the TPM from modern phones.
[14:54] Most important is to write down and safely store your 12 word seed.
[14:54] TPM?
[14:54] <@wolfsokta> A user friendly wallet is one of our main goals.
[14:55] TPM == Trusted Platform Module
[14:55] Ahhh thanks
[14:55] just please no electron apps. they are full of security holes
[14:55] <@spyder_> It is whats makes your stuffs secure
[14:55] not fit for crypto
[14:55] under: depends on who makes it
[14:55] The interface screenshots I've seen look like Bread/Loaf wallet ... I assume that's what was forked from
[14:55] ;)
[14:56] <@wolfsokta> @roshii did you see the question about the Android wallet and DGW?
[14:56] Yes, it was a fork of breadwallet. We like their security.
[14:56] chromium 58 is the last bundled electron engine and has every vuln documented online by google. so unless you patch every vuln.... methinks not
[14:56] Agreed, great choice
[14:57] <@wolfsokta> @Under, what was your proposal?
[14:58] All asset creation Transactions have a mandatory OP_CHECKLOCKTIMEVERIFY of 1 year(or some agreed upon time interval), and the 500 RVN goes to a multisig devfund, run by a custodial group. We get: 1) an artificial temporary burn, 2) sustainable community and core development funding for the long term, after OSTK/Medici 3) and the reintroduction of RVN supply at a fixed schedule, enabling the removal of the 42k max cap of total As
[14:58] *im wrong on the 42k figure
[14:58] <@wolfsokta> Interesting...
[14:59] <@wolfsokta> Love to hear others thoughts.
[14:59] Update: I posted a message on the CryptoBridge discord and one of their support members @stepollo#6276 said he believes the coin team is already aware of the fork but he would forward the message about the fork over to them right now anyway
[14:59] Ifs 42 million assets
[14:59] yep.
[15:00] I have a different Idea. If the 500 RVN goes to a dev fund its more centralized. The 500 RVN should go back into the unmined coins so miners can stay for longer.
[15:01] *without a hardfork
[15:01] <@wolfsokta> lol
[15:01] that breaks halving schedule, since utxos cant return to an unmined state.
[15:01] @UJP back into coinbase is interesting. would have to think about how that effects distribution schedule, etc.
[15:01] only way to do that would be to dynamicaly grow max supply
[15:02] and i am concerned already about the max safe integer on various platforms at 21 billion
[15:02] js chokes on ravencoin already
[15:02] <@wolfsokta> Other thoughts on Under's proposal? JS isn't a real language. ;)
[15:02] Well Bitcoin has more than 21 bn Sats
[15:02] Is there somebody who wants to volunteer to fix js.
[15:02] hahaha
[15:03] I honestly would hate for the coins to go to a dev fund. It doesn't seem like Ravencoin to me.
[15:03] Yep, but we're 21 billion x 100,000,000 -- Fits fine in a 64-bit integer, but problematic for some languages.
[15:03] <@wolfsokta> Thanks UJP
[15:04] <@wolfsokta> We're past time but I would like to continue if you folks are up for it.
[15:04] Yeah no coins can go anywhere centrality contorted like a dev fund cause that would mean someone has to run it and the code can’t decide that so it’s destined to break
[15:05] currently and long term with out the financial backing of development then improvements and features will be difficult. we are certainly thankful for our current development model. but if a skunkworks project hits a particular baseline of profitability any reasonable company would terminate it
[15:05] Yes let’s contibue for sure
[15:05] the alternative to a dev fund in my mind would be timelocking those funds back to the issuers change address
[15:06] But we can’t have dev built in to the code — it has to be open source like Bitcoin and monero and Litecoin - it’s got drawbacks but way more advantages- it’s the best model
[15:06] Dev funding
[15:06] i highly reccommend not reducing the utility of raven by removing permanently the supply
[15:07] == BW_ [[email protected]/web/freenode/ip.138.68.243.202] has joined #ravencoin-dev
[15:07] timelocking those funds accompllishes the same sacrifice
[15:07] @under timelocking is interesting too
[15:07] How exactly does timelocking work?
[15:07] <@wolfsokta> ^
[15:07] I mean you could change the price of assets with the Block reward halfing.
[15:07] == Roshiix [[email protected]/web/freenode/ip.105.67.2.212] has joined #ravencoin-dev
[15:08] funds cant be spent from an address until a certain time passes
[15:08] but in a what magical fairy land do people continue to work for free forever. funding development is a real issue... as much as some might philosphically disagree. its a reality
[15:08] You’d still need a centralized party to decide how to distribute the funds
[15:08] even unofficially blockstream supports bitcoin devs
[15:08] on chain is more transparent imho
[15:09] == Tron_ [[email protected]/web/freenode/ip.173.241.144.77] has joined #ravencoin-dev
[15:09] @UJP yes there are unlimited strategies. one factor that I think is v important is giving application developers a way to easily budget for projects which leads to flat fees
[15:09] If the project is a success like many of believe it will be, I believe plenty of people will gladly done to a dev fund. I don't think the 500 should be burned.
[15:09] *donate
[15:09] centralized conservatorship, directed by community voting process
[15:10] == Tron [[email protected]/web/freenode/ip.173.241.144.77] has quit [Ping timeout: 252 seconds]
[15:10] <@wolfsokta> Thanks Under, that's an interesting idea that we should continue to discuss in the community. You also mentioned the existing website.
[15:10] It would need to be something where everyone with a QT has a vote
[15:10] think his computer went to sleep again :-/
[15:10] I agree UJP
[15:10] with the website
[15:10] No that’s ico jargon — any development fund tied to code would have to be centralized and would therefor fail
[15:11] ^
[15:11] ^
[15:11] ^
[15:11] dashes model for funding seems to be pretty decentralized
[15:11] community voting etc
[15:11] Once you have a dev fund tied to code then who gets to run it? Who mediates disputes?
[15:11] oh well another discussion
[15:11] Dash has a CEO
[15:12] <@wolfsokta> Yeah, let's keep discussing in the community spaces.
[15:12] Dash does have a good model. It's in my top ten.
[15:12] having the burn go to a dev fund is absolute garbage
[15:12] These dev chats should be more target than broad general discussions — changing the entire nature of the coin and it’s economics is best discussed in the RIPs or other means
[15:13] <@wolfsokta> Yup, let's move on.
[15:13] just becuase existing implementation are garbage doesnt mean that all possible future governance options are garbage
[15:13] <@wolfsokta> To discussing the website scenario mentioned by under.
[15:13] the website needs work. would be best if it could be migrated to github as well.
[15:13] What about this: Anyone can issue a vote once the voting feature has been added, for a cost. The vote would be what the coins could be used for.
[15:14] features for the site that need work are more user friendly links to binaries
[15:14] <@wolfsokta> We investigated how bitcoin has their website in Github to make it easy for contributors to jump in.
[15:14] that means active maintenance of the site instead of its current static nature
[15:15] <@wolfsokta> I really like how it's static html, which makes it super simple to host/make changes.
[15:15] the static nature isn’t due to interface it’s due to no contributors
[15:15] no contribution mechanism has been offered
[15:15] github hosted would allow that
[15:16] We used to run the Bitcoin website from the foundation & the GitHub integration seemed to cause some issues
[15:16] its doesnt necessarily have to be hosted by github but the page source should be on github and contributions could easily be managed and tracked
[15:17] for example when a new release is dropped, the ability for the downlaods section to have platform specific easy links to the general installers is far better for general adoption than pointing users to github releases
[15:18] <@wolfsokta> How do people currently contribute to the existing website?
[15:18] they dont?
[15:18] We did that and it was a complete pain to host and keep working — if someone wants to volunteer to do that work hey can surely make the website better and continually updated — but they could do that in Wordpress also
[15:19] I’d say keep an eye out for volunteers and maybe we can get a group together who can improve the site
[15:19] == digitalvap0r-xmr [[email protected]/web/cgi-irc/kiwiirc.com/ip.67.255.25.134] has joined #ravencoin-dev
[15:19] And they can decide best method
[15:20] I host the source for the explorer on github and anyone can spin it up instantly on a basic aws node. changes can be made to interface etc, and allow for multilingual translations which have been offered by some community members
[15:20] there are models that work. just saying it should be looked at
[15:20] i gotta run thank you all for your contributions
[15:20] <@wolfsokta> I feel we should explore the source for the website being hosted in GitHub and discuss in our next dev meeting.
[15:21] <@Chatturga> Thanks Under!
[15:21] == under [[email protected]/web/freenode/ip.72.200.168.56] has quit [Quit: Page closed]
[15:21] <@wolfsokta> Thanks, we also need to drop soon.
[15:21] There is no official site so why care. Someone will do better than the next if RVN is worth it anyway. That's already the case.
[15:21] <@wolfsokta> Let's do 10 mins of open Q&A
[15:22] <@wolfsokta> Go...
[15:23] <@Chatturga> Beuller?
[15:24] No questions ... just a comment that the devs and community are great and I'm happy to be a part of it
[15:24] I think everyone moved to discord. I'll throw this out there. How confident is the dev team that things will be ready for oct 31st?
[15:24] <@wolfsokta> Alright! Thanks everybody for joining us today. Let's plan to get back together as a dev group in a couple of weeks.
[15:25] thanks block!
[15:25] <@wolfsokta> Urgo, very confident
[15:25] Please exclude trolls from discord who havent read the whitepaper
[15:25] great :)
[15:25] "things" will be ready..
[15:25] Next time on discord right?
[15:25] woah why discord?
[15:25] some of the suggestions here are horrid
[15:25] this is better less point
[15:25] == blondfrogs [[email protected]/web/freenode/ip.185.245.87.219] has quit [Quit: Page closed]
[15:25] Assets are working well on testnet. Plan is to get as much as we can safely test by Sept 30 -- this includes dev contributions. Oct will be heavy testing and making sure it is safe.
[15:26] people
[15:26] <@wolfsokta> Planning on same time, same IRC channel.
[15:26] == BW_ [[email protected]/web/freenode/ip.138.68.243.202] has quit [Quit: Page closed]
[15:26] @xmr any in particular?
[15:27] (or is "here" discord?)
[15:27] Cheers - Tron
[15:27] "Cheers - Tron" - Tron
submitted by Chatturga to Ravencoin [link] [comments]

Live Update On Bitcoin Price Action  Charts Review How to parse Bitcoin price from Coinbase API - iOS tutorial. free software bitcoin generator 2020 Bitcoin NodeJS Part 1 - Hello World Stock Market CRASH Cancelled (Best Bet for Bitcoin Price ...

freenode Channels. IRC network freenode was registered on netsplit.de in August 1998.Since that time our data collector regularly connects IRC network freenode to determine its key performance indicators, such as its number of users and its number of chat rooms (IRC channels). On this occasion a list of visible (not private) chat rooms is requested too. Most Bitcoin Core related discussion happens in the #bitcoin-core-dev IRC channel on irc.freenode.net or bitcoin-core-dev mailing list. There is also a mailing list for Bitcoin protocol discussion bitcoin-dev and a general Bitcoin discussion bitcoin-discuss. Contribute to this website. You can also translate or contribute to this website. Appchat: bitcoin freenode Chat Room - 565 users - 32 minutes ago - known since 2011-04-18 - current topic: Bitcoin 0.20.1 bitcoinwiki dot org is a PHISHING SCAM Price chat > #bitcoin-pricetalk Trade #bitcoin-otc Rules https://goo.gl/SJMlSL Most wallets sell your info and lie Web wallets steal! You have stumbled upon the Kiwi Webchat for the freenode project. To learn more about the freenode IRC network, the freenode #live conference and other freenode projects head over to our website.our website. Most of the following Bitcoin-related IRC channels are available on Freenode: Please read: Bitcoin IRC Channel Guidelines before joining. Contents. 1 Bitcoin Project. 1.1 Local communities; 2 Mining Related Communities; 3 Communities for Exchanges and Trading; 4 Related Communities; 5 See Also; Bitcoin Project. Channel Description IRC Web #bitcoin : General Bitcoin-related discussion and ...

[index] [25530] [16949] [3135] [958] [574] [37007] [26953] [51374] [8450] [8539]

Live Update On Bitcoin Price Action Charts Review

As Bitcoin's price climbs higher, I asked YOU to choose the top altcoins that have massive potential in 2020. You chose the coins. I gave you my thoughts! To... The markets have been choppy over the past few days but I'm seeing some potential double bottoms and may be getting ready for some upside testing. Several alts have setting up and looking strong ... Hey Altcoin Daily Team! Masternodes offer you a passive income. Masternodes might be a great investment for your crypto future. Watch the video. Check out th... Join Coinbase - Make a $100 Transaction and get $10 FREE! Follow this link: https://www.coinbase.com/join/52b1cf4d296f3250b4000066 Parse JSON data from Coinb... Muita gente pergunta se é realmente necessário rodar um full node de Bitcoin. Neste vídeo o Dov explica quais são alguns dos maiores benefícios e motivações para você rodar seu próprio node.

#