javascript - Error OPTIONS net::ERR_CONNECTION_REFUSED ...

Technical: The Path to Taproot Activation

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

The SegWit Wars

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

BIP9 Miner-Activated Soft Fork

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

The Great Battles of the SegWit Wars

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

BIP9 Feature Hostage

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

Covert ASICBoost

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

UASF: BIP148 and BIP8

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

BIP91, SegWit2X, and The Aftermath

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

Taproot Activation Proposals

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

Modern Softfork Activation

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

PSA: Being Resilient to Upgrades

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

Lightning node on Windows - testing, get not connected

Ok after testing BTCPay, C-Lightning, LND on Ubuntu I said ok let's try also the Windows implementation, is just few clicks and done (as it is promoted).
So I followed this github guide that actually send you to this one.
OK, started Bitcoin-core client on Windows 7 x64, with an already synced data folder. Empty bitcoin.conf (none of guides says how to configure the conf file). Wait until the client is full synced. And then launched the windows-node-launcher (from a subfolder inside Bitcoin folder). All good, started slowly and a small popup appeared in systray saying Bitcoin node is syncing. Reviewed the config of Bitcoin and LND through that little app in systray and saw that bitcoin.conf was already filled with some settings. Didn't change anything. After 1 day (with the bitcoin blockchain already synced), the systray popup still says that is syncing and have a red dot. In the tutorial says that we have to leave it to sync until is blue and then green.
I said, ok maybe it has more things to do. So I open that LND Output link, to see what is going on... And I see that LND is not well. Says: 2019-04-06 21:11:29.772 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc3, build=production, logging=default 2019-04-06 21:11:29.772 [INF] LTND: Active chain: Bitcoin (network=mainnet) 2019-04-06 21:11:29.774 [INF] CHDB: Checking for schema update: latest_version=8, db_version=8 2019-04-06 21:11:29.808 [INF] RPCS: password RPC server listening on 127.0.0.1:10009 2019-04-06 21:11:29.808 [INF] RPCS: password gRPC proxy started at 127.0.0.1:8080 2019-04-06 21:11:29.808 [INF] LTND: Waiting for wallet encryption password. Use lncli create to create a wallet, lncli unlock to unlock an existing wallet, or lncli changepassword to change the password of an existing wallet and unlock it. 2019-04-06 21:11:32.673 [INF] LNWL: Opened wallet 2019-04-06 21:11:33.183 [INF] LTND: Primary chain is set to: bitcoin unable to create chain control: unable to connect to bitcoind: unable to subscribe for zmq block events: dial tcp 127.0.0.1:18502: connectex: No connection could be made because the target machine actively refused it. 2019-04-06 21:11:36.087 [INF] LTND: Shutdown complete unable to connect to bitcoind: unable to subscribe for zmq block events: dial tcp 127.0.0.1:18502: connectex: No connection could be made because the target machine actively refused it. 2019-04-06 21:11:39.229 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc3, build=production, logging=default
Now the bitcoin.conf have this: printtoconsole=1 rpcallowip=::/0 whitelist=0.0.0.0/0 datadir=C:\Users\Admin\AppData\Roaming\Bitcoin prune=0 txindex=1 server=1 disablewallet=0 timeout=6000 rpcuser=user rpcpassword=defaultxzxxxxx zmqpubrawblock=tcp://127.0.0.1:18502 zmqpubrawtx=tcp://127.0.0.1:18503 dbcache=2408
And LND.conf have this: (#) Auto-Generated Configuration File (#) Node Launcher version 6.0.2 debuglevel=info restlisten=127.0.0.1:8080 rpclisten=127.0.0.1:10009 tlsextraip=127.0.0.1 listen=127.0.0.1:9735 alias=aliasme color=#00aa7f bitcoin.active=1 bitcoin.node=bitcoind bitcoind.rpchost=127.0.0.1:8332 bitcoind.rpcuser=user bitcoind.rpcpass=defaultxxxxx bitcoind.zmqpubrawblock=tcp://127.0.0.1:18502 bitcoind.zmqpubrawtx=tcp://127.0.0.1:18503
So what is going on here? I will have to wait indefinitely? Somebody can give some help or explanation? Is this LND node working on Windows Server 2008 or 2012?
submitted by Mr--Robot to Bitcoin [link] [comments]

Running Bitcoin Abe

I just created a bitcoin node on a digital ocean server and would like to set up bitcoin abe. However upon running

python -m Abe.abe --config abe.conf 

I get the following error:
RPC failed: [Errno socket error] [Errno 111] Connection refused Failed to catch up {'blkfile_offset': 0, 'blkfile_number': 1, 'chain_id': 1, 'loader': u'rpc', 'conf': None, 'dirname': u'/scratch/bitcoin/mainnet/bitcoind', 'id': 17} Traceback (most recent call last): File "Abe/DataStore.py", line 2561, in catch_up raise Exception("RPC load failed") Exception: RPC load failed Abe initialized. Listening on http://localhost:2750 

submitted by alpenmilch411 to Bitcoin [link] [comments]

04-07 09:48 - 'Lightning node on Windows - testing, get not connected' (self.Bitcoin) by /u/Mr--Robot removed from /r/Bitcoin within 845-855min

'''
Ok after testing BTCPay, C-Lightning, LND on Ubuntu I said ok let's try also the Windows implementation, is just few clicks and done (as it is promoted).
So I followed this [github guide]1 that actually send you to [this one]2 .
OK, started Bitcoin-core client on Windows 7 x64, with an already synced data folder. Empty bitcoin.conf (none of guides says how to configure the conf file). Wait until the client is full synced. And then launched the windows-node-launcher (from a subfolder inside Bitcoin folder). All good, started slowly and a small popup appeared in systray saying Bitcoin node is syncing. Reviewed the config of Bitcoin and LND through that little app in systray and saw that bitcoin.conf was already filled with some settings. Didn't change anything. After 1 day (with the bitcoin blockchain already synced), the systray popup still says that is syncing and have a red dot. In the tutorial says that we have to leave it to sync until is blue and then green.
I said, ok maybe it has more things to do. So I open that LND Output link, to see what is going on... And I see that LND is not well. Says: 2019-04-06 21:11:29.772 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc3, build=production, logging=default 2019-04-06 21:11:29.772 [INF] LTND: Active chain: Bitcoin (network=mainnet) 2019-04-06 21:11:29.774 [INF] CHDB: Checking for schema update: latest_version=8, db_version=8 2019-04-06 21:11:29.808 [INF] RPCS: password RPC server listening on 127.0.0.1:10009 2019-04-06 21:11:29.808 [INF] RPCS: password gRPC proxy started at 127.0.0.1:8080 2019-04-06 21:11:29.808 [INF] LTND: Waiting for wallet encryption password. Use lncli create to create a wallet, lncli unlock to unlock an existing wallet, or lncli changepassword to change the password of an existing wallet and unlock it. 2019-04-06 21:11:32.673 [INF] LNWL: Opened wallet 2019-04-06 21:11:33.183 [INF] LTND: Primary chain is set to: bitcoin unable to create chain control: unable to connect to bitcoind: unable to subscribe for zmq block events: dial tcp 127.0.0.1:18502: connectex: No connection could be made because the target machine actively refused it. 2019-04-06 21:11:36.087 [INF] LTND: Shutdown complete unable to connect to bitcoind: unable to subscribe for zmq block events: dial tcp 127.0.0.1:18502: connectex: No connection could be made because the target machine actively refused it. 2019-04-06 21:11:39.229 [INF] LTND: Version: 0.6.0-beta commit=v0.6-beta-rc3, build=production, logging=default
Now the bitcoin.conf have this: printtoconsole=1 rpcallowip=::/0 whitelist=0.0.0.0/0 datadir=C:\Users\Admin\AppData\Roaming\Bitcoin prune=0 txindex=1 server=1 disablewallet=0 timeout=6000 rpcuser=user rpcpassword=defaultxzxxxxx zmqpubrawblock=[link]3 zmqpubrawtx=[link]4 dbcache=2408
And LND.conf have this: (#) Auto-Generated Configuration File (#) Node Launcher version 6.0.2 debuglevel=info restlisten=127.0.0.1:8080 rpclisten=127.0.0.1:10009 tlsextraip=127.0.0.1 listen=127.0.0.1:9735 alias=aliasme color=#00aa7f bitcoin.active=1 bitcoin.node=bitcoind bitcoind.rpchost=127.0.0.1:8332 bitcoind.rpcuser=user bitcoind.rpcpass=defaultxxxxx bitcoind.zmqpubrawblock=[link]3 bitcoind.zmqpubrawtx=[link]4
So what is going on here? I will have to wait indefinitely? Somebody can give some help or explanation? Is this LND node working on Windows Server 2008 or 2012?
'''
Lightning node on Windows - testing, get not connected
Go1dfish undelete link
unreddit undelete link
Author: Mr--Robot
1: g*thub.c*m/light**ng**o*e*-users/no**-launc**r 2: me*ium.*o**lig*tn**g-p*wer-users/w*n**ws-m**os-l**ht*i*g-ne*work-2*4bd5034340 3: 127.0.0**:1*5*2 4: 127*0.0**:185*3 5: 1**.0.0*1:185*2 6: 12*.0**.1:*8503
Unknown links are censored to prevent spreading illicit content.
submitted by removalbot to removalbot [link] [comments]

01-31 23:15 - 'Running Bitcoin Abe' (self.Bitcoin) by /u/alpenmilch411 removed from /r/Bitcoin within 178-188min

'''
I just created a bitcoin node on a digital ocean server and would like to set up bitcoin abe. However upon running

python -m Abe.abe --config abe.conf 

I get the following error:
RPC failed: [Errno socket error] [Errno 111] Connection refused Failed to catch up {'blkfile_offset': 0, 'blkfile_number': 1, 'chain_id': 1, 'loader': u'rpc', 'conf': None, 'dirname': u'/scratch/bitcoin/mainnet/bitcoind', 'id': 17} Traceback (most recent call last): File "Abe/DataStore.py", line 2561, in catch_up raise Exception("RPC load failed") Exception: RPC load failed Abe initialized. Listening on [link]^^1 

'''
Running Bitcoin Abe
Go1dfish undelete link
unreddit undelete link
Author: alpenmilch411
1: *oca*ho*t*2750
Unknown links are censored to prevent spreading illicit content.
submitted by removalbot to removalbot [link] [comments]

Lnd with Bitcoind ZeroMQ Connection Refused

Hi All,
Trying to set this up and can't get it to work.
bitcoin.conf:
datadir=/Backup/Blockchain/Bitcoin server=1 rpcport=8332 rpcuser=bitcoinrpc rpcpassword={somepasswd} txindex=1 zmqpubrawblock=tcp://127.0.0.1:28332 zmqpubrawtx=tcp://127.0.0.1:28332
lnd.conf
[Bitcoin] bitcoin.active=1 bitcoin.node=bitcoind [Bitcoind] bitcoind.rpcuser=bitcoinrpc bitcoind.rpcpass={somepasswd} bitcoind.zmqpath=tcp://127.0.0.1:28332
I get the following:
[email protected]:~/.lnd$ lnd --bitcoin.mainnet 2018-03-18 16:16:51.743 [INF] LTND: Version 0.4.0-beta 2018-03-18 16:16:51.743 [INF] LTND: Active chain: Bitcoin (network=mainnet) 2018-03-18 16:16:51.752 [INF] CHDB: Checking for schema update: latest_version=0, db_version=0 2018-03-18 16:16:51.843 [INF] RPCS: password RPC server listening on 127.0.0.1:10009 2018-03-18 16:16:51.847 [INF] RPCS: password gRPC proxy started at 127.0.0.1:8080 2018-03-18 16:16:51.847 [INF] LTND: Waiting for wallet encryption password. Use lncli create to create wallet, or lncli unlock to unlock already created wallet. 2018-03-18 16:18:14.427 [INF] LNWL: Opened wallet 2018-03-18 16:18:14.557 [INF] LTND: Primary chain is set to: bitcoin 2018-03-18 16:18:14.557 [INF] LTND: Initializing bitcoind backed fee estimator 2018-03-18 16:18:15.925 [INF] LNWL: Opened wallet unable to start wallet: dial tcp 127.0.0.1:28332: connect: connection refused unable to create chain control: dial tcp 127.0.0.1:28332: connect: connection refused
submitted by anonCapitalist to BitcoinBeginners [link] [comments]

With all of the hullabaloo about a thin Dogecoin wallet, specifically naming Electrum, I went and analyzed both Electrum and the official P2P protocol's own thin-client support. I think I might have found a really big problem with them.

…and the thing that’s really got my jimmies rustled is how obvious the problem appears on the surface, and how I can’t find anyone else talking about it. So if you all don’t mind, I’ll go ahead and describe what I think could be the achilles heel of contemporary crypto currency thin clients. I'll be making some really strong assertions, but if anyone has any information that contradicts them, please share!
EDIT: By request from jdk, an abstract of sorts:
Light cryptocurrency wallets take absence of evidence as evidence of absence. Since they cannot verify that the nodes they are talking to have told them the full truth, it's possible that they will miss some incoming transactions.
I describe three attacks:
1. The simplest one don't tell the client about certain transactions. Because bitcoinj ignores block headers it has already seen, this attack is super effective! against it. Electrum, too, so long as all the nodes it's connected to all agree to not tell it. Once someone does tell it about a past transaction, it verifies it, and then adds it to your wallet. Unfortunately, this can be used to facilitate the third attack.
2. (This only applies to Electrum) A slightly more complicated attack has the attack nodes refuse to acknowledge a single outgoing transaction. Because Electrum always uses the oldest transactions to create new transactions, and because it takes absence of evidence as evidence of absence, you can freeze a user's wallet for as long as they are connected to you, or if they don't inspect older blocks. But, again, inspecting older blocks opens you up to the third attack.
3. A merchant and an attacker can conspire against you to trick you into sending your coins twice. They do this by running the second attack, then back-feeding older transactions so your client will attempt to spend those first. This will work as long as you, the user, try to re-initiate the transaction that supposedly failed.
If you haven’t already read the Bitcoin White Paper, I suggest you go ahead and read it, specifically Section 8 on Simplified Payment Verification. I found it to be fairly straightforward, and it should give you enough background to understand what’s going on. I'm also discussing Electrum and bitcoinj, the latter being a specific example of a client which, by default, relies on Simplified Payment Verification, henceforth known as SPV.
When people speak of "thin" clients, they are referring to clients that do not download all of the transactions in a block along with the block headers. Instead, they only download some of them. Because a block containing transactions links to its transactions by way of a Merkle tree, it is possible to omit a majority of transactions, yet still verify that the ones given were indeed present in the block. It is this property of Merkle trees that allows SPV to be possible.
Electrum came about just when the Bitcoin blockchain became too large for most people to stomach, a lot like what is happening with the Dogecoin blockchain now. The mechanics of SPV had been known in the community for as long as the white paper was released publicly, but the core protocol did not directly support it. Electrum was a series of cute, workable hacks that resulted in an SPV client, but also a client-server architecture and a completely different RPC protocol. At the time, it was necessary in order to receive the filtered transaction notifications necessary to efficiently implement SPV. However, the core Bitcoin Peer-to-Peer protocol now supports the capability of notifying peer nodes of what kinds of transactions of which you wish to be notified. The peers will always respond with blockchain headers, and in the event that any interesting transactions appear to be found, the Merkle branches of those transactions. The client then filters out the false positives (in order to efficiently implement this, the protocol uses a data structure called a Bloom Filter to encode the interesting wallets in a compact manner. It is susceptible to false positives, but that's OK, because you can safely ignore them) and verifies that the transactions sent were actually part of the block by rebuilding the Merkle root and comparing it to that of the block.
This is all well and good from an efficiency standpoint, but any sort of *coin being a type of currency, and thus demanding a high standard of security, I hold some gripes about both Electrum in particular and SPV in general that I feel make them unsuitable for the purposes for which they are currently being used.
The Electrum client begins its connection to the Bitcoin network through a series of hard-coded individual servers. There is a mechanism for describing more peers through IRC; the channels for which are provided by the servers contacted at start-up. I fear that this design empowers both the authors of the client and the owners of the seed servers far too much. In collusion, administrators of the seed servers could elect to not run IRC channels at all, or, alternatively, moderate out any servers from non-colluding parties. This could be used to facilitate something disastrous, particularly what I am about to describe.
In general, SPV provides excellent protection from false positives. Any transaction received with a Merkle branch must continue to hash to the proper child value until the Merkle root is reached. If the Merkle root is linked to a trusted block in the blockchain, its existence in the network is proved. But, it is computationally infeasible to protect from false negatives in a SPV scheme. All the peers need to do is refuse to pass on certain transactions. The client will be none the wiser for it, because the client never knew about them in the first place.
This can obviously be used to facilitate an “output garnishing” attack: simply ignore certain transactions outputting to a certain wallet when responding to the client. The client will not be able to see that there are more unspent outputs to its wallets, because he trusts and relies on his peers to do that instead.
"Output garnishing" can be reworked into a "wallet freezing" attack that completely locks the client out of the network. The attacking node may elect to pass an outgoing transaction to the network, but fail to relay the transaction’s status to the client. The client will believe that the transaction was unsuccessful, and because both Electrum and bitcoinjEDIT: bitcoinj marks outgoing transactions as "pending" and won't double-spend them deterministically attempts to spend the oldest transactions first, any further attempts to create transactions will be seen as a double-spend attempt by the network. As long as the client is only communicating with the attacking nodes, he is incapable of making any further purchases.
In Electrum, the solution may be trivial. Download the client source, modify the seed server list to be more trustworthy. Still, that there is now explicit trust in the network nodes is a far cry from the security of the original protocol design.
In bitcoinj, there is no solution. In fact, an attacker only needs to control one node; bitcoinj simply ignores all further communication about valid blocks it has seen only once before! The comments in the bitcoinj source code seem to suggest this was a performance optimization. However, not doing this would open bitcoinj up to another type of attack, to which Electrum is already vulnerable: a “double-purchasing” attack.
EDIT: The preceding paragraph doesn't completely apply as per the previous edit, but I'm leaving it in for consideration with regards to the first attack. Bitcoinj still ignores older blocks, even if they have new, relevant transactions in them.
Suppose a merchant M is in collusion with an attacker A who runs a series of nodes N0…Nn. Suppose also, that a client C, using a wallet Wc, wishes to purchase from M, using a wallet Wm, both of which are known to M and subsequently A.
A constructs N0…Nn such that certain transactions to Wc are silently ignored (call them Ti); valid in the network but never delivered to C. A waits until there are no more unspent transactions to Wc not in Ti older than some T in Ti. Upon an attempted transaction (Wc -> Wm)0, Nk with 0 <= k <= n sends the transaction to other peers but does not respond to C. Instead, Nk responds with some Ts0…Tsn in Ti such that the sum of outputs in Ts0…Tsn to Wc is greater than or equal to the outputs of (Wc -> Wm)0. C accepts these Ts0…Tsn. An unaware user may elect to begin a new transaction (Wc -> Wm)1 in lieu of a response regarding (Wc -> Wm)0. Because (Wc -> Wm)1 will use as inputs from unspent transaction outputs not used in (Wc -> Wm)0, indeed not yet used at all, the network will accept both transactions as valid! A may elect to continue this process for any (Wc -> Wm)n so long as the sum of all Tin in Ti is sufficient to cover the costs of all Tout in (Wc -> Wm)0…(Wc -> Wm)n. A has effectively coerced C into double-purchasing.
Even if Electrum and bitcoinj randomly chose unspent outputs as inputs for the new transaction, as does the reference Bitcoin client, the probability that such an attack could succeed at least once is directly proportional to the input activity of the target wallet, and the attacker would only need to withhold that particular outgoing transaction to succeed!
I’m looking for some peer review on this. If these scenarios are possible, the proliferation of SPV clients for Bitcoin (and perhaps in the future, Dogecoin) could make an adversary’s life very easy! Again, constructive hole-poking and educative discussion weakening this hypothesis are very, very welcome.
EDIT: And I'm all out of characters! More edits will end up in the comments.
submitted by chia_pet to dogecoin [link] [comments]

How do I setup my how pool?

Hello,
I've built a rig for mining recently and got hit by the Nicehash fraud like many. I'm trying to avoid this as the fraud seriously hindered how Christmas will be for the kids and don't want it to happen again. I don't want to rely on some local pool I found on http://scanner.vtconline.org/ as suggested in many guide... After about 10 hours mining @ roughly 380MH/s my balance still shows as 0 and have seen many disconnect of the pool.
So, my question is, how do I setup my own pool? I have many pc lying around which should more than do the trick. I'd also liek to have my brother living 50km away to mine with me on the pool.
I've currently 2 pc with the Vertcoin Core - wallet synced, that step should be done.
I've downloaded the p2pool-vtc from there, latest version from 4 days ago: https://github.com/vertcoin/p2pool-vtc/releases
I made a vertcoin.conf in the roaming directory of vertcoin as explained here: https://gist.github.com/veqtrus/e2b7c34d9c8b3ad285209ae1b13ca2b2
I've changed the rpc user and password but I have no idea if I should first create those somewhere ?
server=1 rpcuser=MyNewAndSecurePool rpcpassword=Thisisn'tsomethingI'llshowupinreddit
I've then opened a cmd and ran the run_p2pool.exe like in previous guide:
run_p2pool.exe --net vertcoin
But only am getting this :
Error while checking Bitcoin connection: Traceback (most recent call last): Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 10061: No connection could be made because the target machine actively refused it..
Anyone help me out a little ?
submitted by Laethageal to VertcoinHelp [link] [comments]

JSON-RPC connection failed when blockchain on USB – Please Help!

Hi,
Please be gentle.
2 weeks ago I had only ever used windows, the tor browser bundle and an electrum bitcoin wallet. Id heard of tails but never used it and knew nothing at all of coinjoin and joinmarket. I read a few things on reddit and thought id give it a try. After a lot more reading I decided on the following set up:
1.Tails with persistant on USB
2.Veracrypt install with hidden partition volume
3.bitcoin core over tor with blockchain stored on USB drive
4.joinmarket using the blockchain on my USB
5.joinmarket using the tor based irc channel
as you can imagine for a complete noob it has been a very steep learngin curve!
I was very pleased with myself today when I thought I had finnally managed to get it all set up without having to ask for help (I enjoy the intelectual challenge of working it ouy for myself) but when I tested it using python wallet-tool.py wallet.json
I get the following error:
2016-03-15 16:08:47,033 [MainThread ] [DEBUG] hello joinmarket
Traceback (most recent call last):
File "wallet-tool.py", line 89, in
load_program_config()
File "/home/amnesia/Persistent/joinmarket/joinmarket/configure.py", line 223, in load_program_config
global_singleton.config)
File "/home/amnesia/Persistent/joinmarket/joinmarket/configure.py", line 242, in get_blockchain_interface_instance
bc_interface = BitcoinCoreInterface(rpc, network)
File "/home/amnesia/Persistent/joinmarket/joinmarket/blockchaininterface.py", line 492, in init
blockchainInfo = self.jsonRpc.call("getblockchaininfo", [])
File "/home/amnesia/Persistent/joinmarket/joinmarket/jsonrpc.py", line 111, in call
response = self.queryHTTP(request)
File "/home/amnesia/Persistent/joinmarket/joinmarket/jsonrpc.py", line 100, in queryHTTP
repr(exc))
joinmarket.jsonrpc.JsonRpcConnectionError: JSON-RPC connection failed. Err:error(111, 'Connection refused')
so close yet still so far!!!!! I havent been able to find an answer to this anywhere and simply have no idea what it means or how to fix it. so am posting here in the hope someone can help or point me in the right direction. my bitcoin and joinmarket settings are as follows:
/home/amnesia/Persistent/bitcoin-0.11.2/bin/bitcoin.conf
rpcuser=bitcoin
rpcpassword=password
daemon=1
proxyrandomize=1
proxy=127.0.0.1:9050
listen=0
server=1
For JoinMarket
walletnotify=curl -sI --connect-timeout 1 http://localhost:62602/walletnotify?%s
alertnotify=curl -sI --connect-timeout 1 http://localhost:62602/alertnotify?%s
User must uncomment and input path to blockchain files
datadir=/media/amnesia/590C-2CF0/bitcoin
/home/amnesia/Persistent/joinmarket/joinmarket.cfg
[BLOCKCHAIN]
blockchain_source = bitcoin-rpc
network = mainnet
rpc_host = localhost
rpc_port = 8332
rpc_user = bitcoin
rpc_password = password
[MESSAGING]
host = 6dvj6v5imhny3anf.onion
channel = joinmarket-pit
port = 6698
usessl = true
socks5 = true
socks5_host = localhost
socks5_port = 9050
maker_timeout_sec = 30
and can anyone confirm I am right in thinking that to run bitcoin core over tor I just choose socks5 and port 9050 in the settings, there's nothing else I need to change? Told you I was a noob!
Thanks in advance for any help and please forgive me if I dont understand your answer at first.
i also have no idea how to sort out the formatting of that post, sorry!!!!
submitted by smokingskills1 to joinmarket [link] [comments]

Socks5Error: 'Connection refused'

Error msg:
... Using socks5 proxy localhost:9150 AttributeError("'IRCMessageChannel' object has no attribute 'fd'",) CRASHING, DUMPING EVERYTHING ... Socks5Error: 'Connection refused' 
joinmarket.cfg
[BLOCKCHAIN] blockchain_source = json-rpc #options: blockr, json-rpc, regtest #before using json-rpc read https://github.com/chris-belchejoinmarket/wiki/Running-JoinMarket-with-Bitcoin-Core-full-node network = mainnet bitcoin_cli_cmd = bitcoin-cli -datadir=/media/shitman/here/Bitcoin [MESSAGING] #host = irc.cyberguerrilla.org channel = joinmarket-pit #port = 6697 #usessl = true #socks5 = false socks5_host = localhost socks5_port = 9150 #for tor host = 6dvj6v5imhny3anf.onion port = 6667 usessl = false socks5 = true 
Bitcoin core is using the same socks port and works fine. I'm running the latest Tor Browser Bundle on Ubuntu 14.04, and git cloned the latest master joinmarket branch from github. Also tried to install Tor, and use port 9050 but still get the same error.
submitted by throwerq to joinmarket [link] [comments]

tailsjoin full node connection failed

I've been trying to get joinmarket running with a full node working forever and I'm almost there but I keep getting this error.
2016-04-18 22:09:43,109 [MainThread ] [DEBUG] hello joinmarket Traceback (most recent call last):
File "wallet-tool.py", line 89, in
load_program_config() 
File "/home/amnesia/Persistent/joinmarket/joinmarket/configure.py", line 222, in \load_program_config
global_singleton.config)
File "/home/amnesia/Persistent/joinmarket/joinmarket/configure.py", line 241, in \get_blockchain_interface_instance
bc_interface = BitcoinCoreInterface(rpc, network) 
File "/home/amnesia/Persistent/joinmarket/joinmarket/blockchaininterface.py", line 492, in
init blockchainInfo = self.jsonRpc.call("getblockchaininfo", [])
File "/home/amnesia/Persistent/joinmarket/joinmarket/jsonrpc.py", line 111, in call
response = self.queryHTTP(request) 
File "/home/amnesia/Persistent/joinmarket/joinmarket/jsonrpc.py", line 100, in queryHTTP
repr(exc))
joinmarket.jsonrpc.JsonRpcConnectionError: JSON-RPC connection failed. Err:error(111, \'Connection refused')

joinmarket.cfg:

[BLOCKCHAIN] blockchain_source = bitcoin-rpc #options: blockr, bitcoin-rpc, json-rpc, regtest # for instructions on bitcoin-rpc read # https://github.com/chris-belchejoinmarket/wiki/Running-JoinMarket-with-Bitcoin-Core-full-node network = mainnet rpc_host = 127.0.0.1 rpc_port = 8332 rpc_user = bitcoin rpc_password = password
[MESSAGING] #host = irc.cyberguerrilla.org channel = joinmarket-pit #port = 6697 #usessl = true #socks5 = false socks5_host = 127.0.0.1 socks5_port = 9050 #for tor host = 6dvj6v5imhny3anf.onion port = 6697 usessl = true socks5 = true maker_timeout_sec = 30

bitcoin.conf:

rpcuser=bitcoin rpcpassword=password daemon=1 proxyrandomize=1 proxy=127.0.0.1:9050 listen=0 server=1
# For JoinMarket
walletnotify=curl -sI --connect-timeout 1 http://127.0.0.1:62602/walletnotify?%s
alertnotify=curl -sI --connect-timeout 1 http://127.0.0.1:62602/alertnotify?%s
# User must uncomment and input path to blockchain files
datadir=/home/amnesia/Persistent/.bitcoin"
Can any please help?
submitted by frustratedtails to joinmarket [link] [comments]

Bitcoin miner 10061 error FIX Dev++ 01-08-EN  Remote Procedure Calls (RPC) - Anditto Heristyo Connect to Bitcoin & Ethereum networks - Dilum Navanjana- FOSSASIA 2018 A breif introduction to the Chain Query Bitcoin RPC API Bitcoin JSON-RPC Tutorial 6 - JSON Parameters and Errors

If it is, please include the bitcoin.conf file (and other information that might be helpful) in the question. – greybeard Dec 11 '16 at 14:58 haha sorry I didn't pay attention. – superNovice92 Dec 11 '16 at 15:38 I'm running bitcoind on one machine and would like to control it from another (using python and the JSON RPC interface). ~/.bitcoin/bitcoin.config on the bitcoind host (192.168.2.4): rpcuser=xxx connection refused when downloading file on a local area pc using proxy to backend. Related. 1105 . How do you remove all the options of a select box and then add one option and select it with jQuery? 1404. What is the best way to add options to a select from a JavaScript object with jQuery? 1245. jQuery get specific option tag text. 777. Adding options to a <select> using jQuery? 302. Why is ... All the results are 'Connection refused' Can anyone advise me how to resolve the problem? Thanks Regards, Max. bitcoind json-rpc. share improve this question follow edited Nov 14 '18 at 20:09. max. asked Nov 6 '18 at 2:28. max max. 21 3 3 bronze badges. add a comment 2 Answers Active Oldest Votes. 4. Since Bitcoin Core 0.17 certain config file options are net-specific. In particular ... When running bitcoin-qt.exe -server -rpcuser=u -rpcpassword=p the server binds to 127.0.0.1, though, and not to all interfaces. This causes the server to be unreachable from another machine. Looks like a bug.

[index] [45297] [32260] [31751] [23544] [43864] [8330] [3961] [51177] [1303] [19442]

Bitcoin miner 10061 error FIX

Bitcoin JSON-RPC tutorial. Handling JSON, entering parameters and receiving error messages. BTC: 1NPrfWgJfkANmd1jt88A141PjhiarT8d9U. You can do what ever the blockchain work you want with those APIs. So in my talk I will talk about how to use those APIs to connect to most famous Bitcoin & Ethereum networks. So you can ... #bitcoin rpc #bitcoin difficulty #bitcoin to usd #problems communicating with bitcoin rpc #bitcoin watch #bitcoin trade #earn bitcoins #bitcoin server #bitcoin cuda #sell bitcoins #bitcoin price # ... In this video I revisit an old topic where several things have changed since 2015 in regards to using the JSON-RPC to communicate with your node with an apache server with PHP. https://www.amazon ... Bitcoin JSON-RPC Tutorial 3 - bitcoin.conf - Duration: 8:10. ... Step 7.3 Connecting your Wallet to BTCPay Server with xpub Ledger Nano S or other like Electrum - Duration: 5:00. BitcoinShirt ...

#