text:
Receive at Watching Only Wallet
I am a little foggy about the Watching Wallet copy in Armory. I have received BTC in my Watching only wallet. Is there anything that I need to do now to get those to the Cold Storage Wallet or is the Cold storage Wallet only needed to sign Spending transactions.  If so then in that Case I assume that the accurate balance in the Cold Wallet does not need to be reflected as it is only used for spending?
Thanks

No, you don't need to do anything.

If so then in that Case I assume that the accurate balance in the Cold Wallet does not need to be reflected as it is only used for spending?

Correct. Without a means to gain knowledge about received money, the cold storage wallet can't update its balance. But it holds the private keys required to spend the money it received. The watch-only wallet can be used to check the balance without it having the ability to spend any money.

Thank you so much for answering. I was beginning to think that noone would after 11 views.


text:
Armory scan hangs each time on Ubuntu 16.04
I installed Armory 0.96 (armory_0.96-gcc5.4_amd64.deb) on Ubuntu 16.04. It worked for me a couple of times but now it seems to get stuck on the scan part.
After I close Armory I cannot start it again. The log shows something like
Log file opened at 1498017814: /home/ubuntu/.armory/armorycpplog.txt

==> .armory/armorylog.txt <==
2017-06-21 06:03 (ERROR) -- ArmoryQt.py:5906 - Socket already in use.  Sent CLI args to existing proc.
2017-06-21 06:03 (ERROR) -- ArmoryQt.py:5907 - Exiting...

Armory looks looks very good, looks like a lot of hard work went into creating it, so I am a bit surprised at this result. It looks like there are still major issues with it.
Should I switch to other OS? MS Windows? It does not look like this runs reliably on Ubuntu.
On first start - when scan seems to hang - logs are as follows
ubuntu:~] $ sudo tail -f .armory/armorylog.txt .armory/armorycpplog.txt .armory/dbLog.txt /var/log/syslog
[sudo] password for ubuntu:
==> .armory/armorylog.txt <==
2017-06-21 05:49 (INFO) -- ArmoryUtils.py:3590 - Using settings file: /home/ubuntu/.armory/ArmorySettings.txt
2017-06-21 05:49 (ERROR) -- ArmoryUtils.py:3747 - Unsupported language  specified. Defaulting to English (en)
2017-06-21 05:49 (INFO) -- ArmoryUtils.py:3750 - Using Language: en
2017-06-21 05:49 (INFO) -- BDM.py:368 - Using the asynchronous/multi-threaded BlockDataManager.
2017-06-21 05:49 (INFO) -- BDM.py:369 - Blockchain operations will happen in the background.
2017-06-21 05:49 (INFO) -- BDM.py:370 - Devs: check TheBDM.getState() before asking for data.
2017-06-21 05:49 (INFO) -- BDM.py:371 - Registering addresses during rescans will queue them for
2017-06-21 05:49 (INFO) -- BDM.py:372 - inclusion after the current scan is completed.
2017-06-21 05:49 (ERROR) -- ArmoryQt.py:5906 - Socket already in use.  Sent CLI args to existing proc.
2017-06-21 05:49 (ERROR) -- ArmoryQt.py:5907 - Exiting...

==> .armory/armorycpplog.txt <==

Log file opened at 1497968678: /home/ubuntu/.armory/armorycpplog.txt
-ERROR - 1497968679: (SwigClient.cpp:61) can't connect socket

Log file opened at 1498016894: /home/ubuntu/.armory/armorycpplog.txt

Log file opened at 1498016990: /home/ubuntu/.armory/armorycpplog.txt

==> .armory/dbLog.txt <==
-INFO  - 1498016004: (BlockchainScanner.cpp:650) scanned from height #472200 to #472200
-INFO  - 1498016353: (BlockchainScanner.cpp:650) scanned from height #472201 to #472201
-INFO  - 1498016685: (nodeRPC.cpp:368) Bitcoin server stopping
-INFO  - 1498016686: (SocketObject.cpp:350) POLLIN recv return 0
-ERROR - 1498016686: (BitcoinP2P.cpp:1037) caught StopBlockingLoop in processDataStackThread
-INFO  - 1498016686: (BitcoinP2P.cpp:969) Disconnected from Bitcoin node
-INFO  - 1498016704: (BitcoinP2P.cpp:947) Connected to Bitcoin node
-INFO  - 1498016727: (SocketObject.cpp:350) POLLIN recv return 0
-ERROR - 1498016727: (BitcoinP2P.cpp:1037) caught StopBlockingLoop in processDataStackThread
-INFO  - 1498016727: (BitcoinP2P.cpp:969) Disconnected from Bitcoin node

==> /var/log/syslog <==
Jun 21 05:54:15 io org.freedesktop.FileManager1[2363]: (nautilus:2789): GLib-GObject-WARNING **: invalid (NULL) pointer instance
Jun 21 05:54:15 io org.freedesktop.FileManager1[2363]: (nautilus:2789): GLib-GObject-CRITICAL **: g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
Jun 21 05:54:15 io nautilus: [N-A] Nautilus-Actions Tracker 3.2.3 initializing...
Jun 21 05:54:15 io org.freedesktop.fwupd[884]: (fwupd:2781): Fu-WARNING **: Failed to coldplug: UEFI firmware updating not supported
Jun 21 05:54:15 io dbus[884]: [system] Successfully activated service 'org.freedesktop.fwupd'
Jun 21 05:54:17 io thermald[960]: sysfs write failed trip_point_0_temp
Jun 21 05:54:21 io thermald[960]: sysfs write failed trip_point_0_temp
Jun 21 05:54:25 io systemd-timesyncd[734]: Synchronized to time server 91.189.89.198:123 (ntp.ubuntu.com).
Jun 21 05:54:33 io pulseaudio[2604]: [pulseaudio] bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.bluez': timed out
Jun 21 05:54:34 io org.gnome.zeitgeist.Engine[2363]: ** (zeitgeist-datahub:3133): WARNING **: zeitgeist-datahub.vala:229: Unable to get name "org.gnome.zeitgeist.datahub" on the bus!
Jun 21 05:54:52 io systemd[1]: Starting Stop ureadahead data collection...
Jun 21 05:54:52 io systemd[1]: Stopped Read required files in advance.
Jun 21 05:54:52 io systemd[1]: Started Stop ureadahead data collection.

==> .armory/armorylog.txt <==
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1138 - C++ block utilities loaded successfully
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:665 - Executing popen: free -m
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:665 - Executing popen: ['cat', '/proc/cpuinfo']
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1255 -
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1256 -
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1257 -
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1258 - ************************************************************
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1259 - Invoked: /usr/local/bin/../lib/armory/ArmoryQt.py
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1260 - ************************************************************
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1261 - Loading Armory Engine:
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1262 -    Armory Version        : 0.96
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1263 -    Armory Build:         : a3d01aa722
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1264 -    PyBtcWallet  Version  : 1.35
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1265 - Detected Operating system: Linux
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1266 -    OS Variant            : Ubuntu-16.04-xenial
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1267 -    User home-directory   : /home/ubuntu
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1268 -    Satoshi BTC directory : /home/ubuntu/.bitcoin/
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1269 -    Armory home dir       : /home/ubuntu/.armory/
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1270 - Detected System Specs    :
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1271 -    Total Available RAM   : 15.58 GB
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1272 -    CPU ID string         : Intel(R) Core(TM) i7-4810MQ CPU @ 2.80GHz
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1273 -    Number of CPU cores   : 8 cores
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1274 -    System is 64-bit      : True
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1275 -    Preferred Encoding    : UTF-8
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1276 -    Machine Arch          : x86_64
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1277 -    Available HDD (ARM)   : 25 GB
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1278 -    Available HDD (BTC)   : 25 GB
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1279 -
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1280 - Network Name: Main Network
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1281 - Satoshi Port: 8333
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1282 - Do wlt check: True
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1283 - Named options/arguments to armoryengine.py:
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     thread_count    : -1
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     rescan          : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     ignoreAllZC     : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     rescanBalance   : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     disableModules  : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     port            : None
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     interport       : 8223
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     coverageOutputDir: None
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     forceWalletCheck: False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     regtest         : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     rebuild         : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     nettimeout      : 2
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     datadir         : DEFAULT
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     clearMempool    : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     offline         : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     armoryDBDir     : DEFAULT
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     armorydb_port   : 9001
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     satoshiPort     : DEFAULT
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     useTorSettings  : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     netlog          : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     keypool         : 100
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     coverageInclude : None
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     forceOnline     : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     redownload      : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     rpcBindAddr     : 127.0.0.1
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     armorydb_ip     : 127.0.0.1
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     multisigFile    : DEFAULT
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     ram_usage       : -1
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     mtdebug         : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     logDisable      : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     settingsPath    : /home/ubuntu/.armory/ArmorySettings.txt
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     language        : en
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     db_type         : DB_FULL
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     doDebug         : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     enableDetSign   : True
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     disableConfPermis: False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     testnet         : False
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     rpcport         : DEFAULT
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     satoshiHome     : DEFAULT
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     satoshiRpcport  : DEFAULT
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     logFile         : /home/ubuntu/.armory/ArmoryQt.py.log.txt
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1285 -     verbosity       : None
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1286 - Other arguments:
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1289 - ************************************************************
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:1692 - C++ block utilities loaded successfully
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:3590 - Using settings file: /home/ubuntu/.armory/ArmorySettings.txt
2017-06-21 05:55 (ERROR) -- ArmoryUtils.py:3747 - Unsupported language  specified. Defaulting to English (en)
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:3750 - Using Language: en
2017-06-21 05:55 (INFO) -- BDM.py:368 - Using the asynchronous/multi-threaded BlockDataManager.
2017-06-21 05:55 (INFO) -- BDM.py:369 - Blockchain operations will happen in the background.
2017-06-21 05:55 (INFO) -- BDM.py:370 - Devs: check TheBDM.getState() before asking for data.
2017-06-21 05:55 (INFO) -- BDM.py:371 - Registering addresses during rescans will queue them for
2017-06-21 05:55 (INFO) -- BDM.py:372 - inclusion after the current scan is completed.

==> .armory/armorycpplog.txt <==

Log file opened at 1498017359: /home/ubuntu/.armory/armorycpplog.txt

==> .armory/armorylog.txt <==
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:3590 - Using settings file: /home/ubuntu/.armory/ArmorySettings.txt
2017-06-21 05:55 (INFO) -- ArmoryQt.py:2042 - loadWalletsAndSettings
2017-06-21 05:55 (INFO) -- ArmoryQt.py:2102 - Loading wallets...
2017-06-21 05:55 (INFO) -- ArmoryQt.py:2167 - Number of wallets read in: 1
2017-06-21 05:55 (INFO) -- ArmoryQt.py:2172 -    Wallet (SG4vvFdh):    "OU Sparen (Watch)               "   (No Encryption)
2017-06-21 05:55 (INFO) -- ArmoryQt.py:1747 - acquiring process mutex...
2017-06-21 05:55 (INFO) -- ArmoryQt.py:1385 - setupUriRegistration
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:665 - Executing popen: gconftool-2 --get /desktop/gnome/url-handlers/bitcoin/command
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:665 - Executing popen: xdg-mime query default x-scheme-handler/bitcoin
2017-06-21 05:55 (INFO) -- ArmoryQt.py:558 - Usermode: Advanced
2017-06-21 05:55 (INFO) -- ArmoryQt.py:1681 - Changing usermode:
2017-06-21 05:55 (INFO) -- ArmoryQt.py:1682 -    From: Advanced
2017-06-21 05:55 (INFO) -- ArmoryQt.py:1690 -      To: Advanced
2017-06-21 05:55 (INFO) -- ArmoryQt.py:1814 - startBitcoindIfNecessary
2017-06-21 05:55 (INFO) -- ArmoryQt.py:1850 - setSatoshiPaths
2017-06-21 05:55 (INFO) -- ArmoryQt.py:1868 - Setting satoshi datadir = /opt/blockchains/bitcoin
2017-06-21 05:55 (INFO) -- ArmoryUtils.py:665 - Executing popen: ['whereis', 'bitcoind']
2017-06-21 05:55 (INFO) -- SDM.py:289 - "whereis" returned: ['/usr/bin/bitcoind']
2017-06-21 05:55 (INFO) -- SDM.py:169 - Found bitcoind in the following places:
2017-06-21 05:55 (INFO) -- SDM.py:171 -    /usr/bin/bitcoind
2017-06-21 05:55 (INFO) -- SDM.py:171 -    /usr/bin/bitcoind
2017-06-21 05:55 (INFO) -- SDM.py:173 - Using: /usr/bin/bitcoind
2017-06-21 05:55 (INFO) -- SDM.py:337 - Called startBitcoind
2017-06-21 05:56 (INFO) -- ArmoryUtils.py:665 - Executing popen: ['/usr/bin/bitcoind', u'-datadir=/opt/blockchains/bitcoin']
2017-06-21 05:56 (INFO) -- SDM.py:443 - PID of bitcoind: 3379
2017-06-21 05:56 (INFO) -- SDM.py:444 - PID of armory:   3345
2017-06-21 05:56 (INFO) -- ArmoryUtils.py:665 - Executing popen: ['python', '/usr/local/lib/armory/guardian.py', '3345', '3379']
2017-06-21 05:56 (INFO) -- ArmoryQt.py:1850 - setSatoshiPaths
2017-06-21 05:56 (INFO) -- ArmoryQt.py:1868 - Setting satoshi datadir = /opt/blockchains/bitcoin
2017-06-21 05:56 (WARNING) -- SDM.py:396 - Spawning DB with command:ArmoryDB --db-type="DB_FULL" --cookie --satoshi-datadir="/opt/blockchains/bitcoin/blocks" --datadir="/home/ubuntu/.armory/" --dbdir="/home/ubuntu/.armory/databases"
2017-06-21 05:56 (INFO) -- ArmoryUtils.py:665 - Executing popen: ['ArmoryDB', '--db-type="DB_FULL"', '--cookie', u'--satoshi-datadir="/opt/blockchains/bitcoin/blocks"', '--datadir="/home/ubuntu/.armory/"', '--dbdir="/home/ubuntu/.armory/databases"']

==> .armory/dbLog.txt <==

Log file opened at 1498017360: /home/ubuntu/.armory/dbLog.txt
-INFO  - 1498017360: (main.cpp:23) Running on 8 threads
-INFO  - 1498017360: (main.cpp:24) Ram usage level: 4
-INFO  - 1498017360: (BlockUtils.cpp:907) blkfile dir: /opt/blockchains/bitcoin/blocks
-INFO  - 1498017360: (BlockUtils.cpp:908) lmdb dir: /home/ubuntu/.armory/databases
-INFO  - 1498017360: (lmdb_wrapper.cpp:388) Opening databases...

==> .armory/armorylog.txt <==
2017-06-21 05:56 (INFO) -- ArmoryQt.py:1900 - Setting netmode: 1

==> .armory/armorycpplog.txt <==
-ERROR - 1498017360: (SwigClient.cpp:61) can't connect socket

==> .armory/armorylog.txt <==
2017-06-21 05:56 (INFO) -- ArmoryQt.py:1900 - Setting netmode: 0
2017-06-21 05:56 (INFO) -- ArmoryQt.py:1882 - loadBlockchainIfNecessary
2017-06-21 05:56 (INFO) -- ArmoryQt.py:4619 - Dashboard switched to "Scanning" mode

==> .armory/dbLog.txt <==
-INFO  - 1498017360: (BlockUtils.cpp:1091) Executing: doInitialSyncOnLoad

==> .armory/armorylog.txt <==
2017-06-21 05:56 (INFO) -- ArmoryQt.py:4619 - Dashboard switched to "Scanning" mode

==> .armory/dbLog.txt <==
-INFO  - 1498017360: (DatabaseBuilder.cpp:169) Reading headers from db
-INFO  - 1498017363: (DatabaseBuilder.cpp:208) Found 472202 headers in db
-INFO  - 1498017364: (DatabaseBuilder.cpp:51) updating HEADERS db
-INFO  - 1498017365: (DatabaseBuilder.cpp:477) Found next block after skipping 356528bytes
-INFO  - 1498017365: (DatabaseBuilder.cpp:268) parsed block file #910
-DEBUG - 1498017365: (Blockchain.cpp:242) Organizing chain
-INFO  - 1498017365: (DatabaseBuilder.cpp:56) updated HEADERS db in 0.348001s
-INFO  - 1498017365: (DatabaseBuilder.cpp:106) scanning new blocks from #472202 to #472201
-INFO  - 1498017365: (BlockchainScanner.cpp:52) no history to scan
-INFO  - 1498017365: (BlockchainScanner.cpp:813) no SSH to scan
-INFO  - 1498017365: (DatabaseBuilder.cpp:156) scanned new blocks in 0.000506s
-INFO  - 1498017365: (DatabaseBuilder.cpp:160) init db in 3.77501s
-INFO  - 1498017365: (BlockUtils.cpp:1206) Enabling zero-conf tracking

==> /var/log/syslog <==
Jun 21 05:56:08 io systemd[1]: Stopping User Manager for UID 108...
Jun 21 05:56:08 io systemd[2017]: Reached target Shutdown.
Jun 21 05:56:08 io systemd[2017]: Stopped target Default.
Jun 21 05:56:08 io systemd[2017]: Starting Exit the Session...
Jun 21 05:56:08 io systemd[2017]: Stopped target Basic System.
Jun 21 05:56:08 io systemd[2017]: Stopped target Timers.
Jun 21 05:56:08 io systemd[2017]: Stopped target Paths.
Jun 21 05:56:08 io systemd[2017]: Stopped target Sockets.
Jun 21 05:56:08 io systemd[2017]: Received SIGRTMIN+24 from PID 3413 (kill).
Jun 21 05:56:08 io systemd[1]: Stopped User Manager for UID 108.
Jun 21 05:56:08 io systemd[1]: Removed slice User Slice of lightdm.

==> .armory/dbLog.txt <==
-INFO  - 1498017395: (BitcoinP2P.cpp:947) Connected to Bitcoin node
-INFO  - 1498017395: (nodeRPC.cpp:59) RPC connection established
-INFO  - 1498017431: (BlockchainScanner.cpp:650) scanned from height #472202 to #472204
-INFO  - 1498017443: (BlockchainScanner.cpp:650) scanned from height #472205 to #472205
-WARN  - 1498017443: (BDM_supportClasses.cpp:1891) running 10 zc parser threads
-WARN  - 1498017443: (BDM_supportClasses.cpp:1891) running 15 zc parser threads
-WARN  - 1498017443: (BDM_supportClasses.cpp:1891) running 20 zc parser threads
-WARN  - 1498017443: (BDM_supportClasses.cpp:1891) running 25 zc parser threads
-WARN  - 1498017443: (BDM_supportClasses.cpp:1891) running 30 zc parser threads
-WARN  - 1498017443: (BDM_supportClasses.cpp:1891) running 35 zc parser threads

==> /var/log/syslog <==
Jun 21 05:58:10 io thermald[960]: sysfs write failed trip_point_0_temp

The logged error Socket already in use seems to indicate that there is already an instance of Armory running - or another application is perhaps using port 8223?

Don't think that is it. It is just user interface stuff https://github.com/etotheipi/BitcoinArmory/blob/master/ArmoryQt.py#L5906

At the cmd line, try netstat -al | grep 8223. If anything shows up then there is an app using that port. Also: ps -ef | grep -i armor (or whatever the Armory process is called), and try to see if bitcoind is perhaps running in the background. Seems like when you previously exited Armory, its process was not killed...

I removed armory and .armory directory and installed again, now it is working again. I keep the blockchain in separate directory / NFS share so this was a good enough solution for now.

If you're using an NFS for blockchain storage this implies you're getting intermittent read/write locks that can cause Armory to hang and not properly terminate via user shutdown. Recommend you run bitcoind with local storage for datadir.

That fixes the problem. Using a NFS share does not seem to work.

This error means that the background database process, ArmoryDB, is still running. Just use sudo killall -9 ArmoryDB to kill all instances of this process and start Armory again. It's fine to use -9 as ArmoryDB is good enough to handle a SIGKILL signal; I have done this many times myself.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
How to setup, sync, backup en restore blockchain when using bitcoin-qt
I am trying to setup a Bitcoin client using Bitcoin Core and Armory.
Synchronization with the network seems troublesome. The blockchain is +120GB and corruptions can easily occur. I have tried twice already. Both attempts failed, first at 80%, the next at 28%.
The first became corrupted when I started Armory using the Bitcoin data directory.
On the second attempt there was some unknown error and the blockchain was again corrupted.
Such corruptions seem to require complete new download of the blockchain.
Of course, without a good and synchronized blockchain, Bitcoin Core and Armory will not work.
Is there a instruction somewhere that explains in detail how to setup, sync, backup, restore blockchain data properly?

There aren't really such instructions because normally you don't have to do anything except start it up and wait.  Corruption isn't normal.  You may in some cases be able to use -reindex to reload what you've already downloaded and start from there, rather than starting completely over.  But you also might want to investigate why it failed the second time - is it possible you have a hardware fault?

I ran bitcoind on high-end server which performed the sync in less than 12 hours without problems. Subsequently I copied the data directory to network share accesible from my laptop. I have Armory running now without problems. I am keeping that server kopie as a backup copy in case I get a corruption again.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Can I have a bitcoin pool joining another bitcoin pool
I currently having some idea of starting up a bitcoin pool company with my unique strategy pattern. However, I wouldn't have enough hash power at the start.
Hence, it is possible for one mining pool to join another mining pool? Or is there any ways that I can go about doing this?
Thanks

Yes, a pool can mine through another pool. There are pools already doing this as you can see under the "proxy mining pools" heading of the mining pool list at https://bitcointalk.org/index.php?topic=104664.0
You won't control which transactions go into the blocks or be able to vote directly with the hashpower. You'll be providing hashpower to another pool that decides how to use it.
The technical part of proxying
If the upstream pool allows you to mine with a larger extranonce2 size than the regular 4 bytes, then you could use a single connection to the upstream pool and partition up the work you receive for your downstream miners with extranonce2 size of 4 bytes. If the upstream pool does not allow this then you'd need to create one connection to the upstream pool for each downstream miner and just pass the work data through like a plain proxy.
In either case you'll need to observe work submitted by your miners and whether it is accepted or rejected by the upstream pool.
Having one upstream connection per downstream miners means a lot of connections. But it simplifies counting accepted and rejected work for your miners, as upstream and downstream difficulty would be the same. You just pass everything through and watch to see what is accepted or rejected by the upstream pool. If you are mining on a single upstream connection then you'll be mining at a very high difficulty in the upstream pool. You can't have your miners all mining at that high a difficulty. So you'd need to process the lower difficulty work that does not meet upstream difficulty yourself instead of passing it upstream for acceptance/rejection. Whenever work from low difficulty miners do meet the upstream difficulty, then their work must of course be passed upstream.
You'll probably want to contact the upstream pool ahead of time. If you create 1000 connections to their pool from the same IP address there could be problems.
Reward system
If you use the PPS reward system things are pretty simple (but extremely risky). If you use something else then you'll need to think about whether it is safe from pool hopping or not. I'm not sure if anyone has ever analyzed whether you can pool hop a PPLNS pool that proxy mines another PPLNS pool, for example.


text:
When do scripts executed?
Can anyone explain when does a script executed exactly? There are several information about "how scripts are executed" but no information about "when".

The script is executed during the validation of a transaction by any full node which validates it. The script denotes the spending condition, so during the verification of a transaction the node will execute the script to ensure it passes successfully and does not violate any other rules (e.g. cleanstack)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How does a node forget about other nodes?
It is said that addr message: Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours.
I did not totally understood what does it mean forgetting a node? A node has a list of peers, and it is checking every 3 hours if these peer are active? Does it work like this? How does this forgetting mechanism work?

Where did you read this?

I read it here: https://en.bitcoin.it/wiki/Protocol_documentation#addr

Ignore that wiki, it was inaccurate when most of it was written years ago, and has been unmaintained since, mostly. I suggest using the bitcoin.org developer documentation instead.

OK. So does it mean that there is no neighbour forgetting if it does not respond in 3 hours or something like that? The answer to my question is still missing.

I'll write a full answer too when I have time; this is just a short comment to let you know the premise makes little sense.

OK. I am waiting for your answer.

There is no need for a node to "forget" a node. This is not something that is required nor necessary. What Bitcoin Core does in response to a getaddr message (so it sends an addr message) is that it checks its list of nodes. It filters through that list for the things that it recently had a connection to and that it didn't have multiple failed connections to before. There is no checking that a node is actually live and it doesn't do it on a set timer either.

But isn't there a number limit for the connections? Doesn't a node try to find another connection if one of its connection has failed?

Yes, so? That doesn't prevent a node from remembering that it recently connected to someone or that it recently tried to connect to a node and failed. And that only pertains to outgoing connections. If an incoming connection drops, Core doesn't care. It will only try to fill all of the 8 outbound connection slots.

So the limit for outbound connections is 8, right?

authors: Євгеній Ертман


text:
What happen to my bitcoin
I have payed last april 21 and april 25 should be my payment but it took days already here is my transaction id
b5a9cb6a67429ec60c51f3aa197bec67af0003c841890132051f9fea40f71f76
And the same as april 22 and i should get my bitcoin on april 26 transaction id
77fc2aa152a80e0abe382a53d5254f113460a6f17cff95852bd0827a572e01cb
I waited how many days just for bitcoin to go to my wallet but it say bitcoin network i dont why and what happen ?please i need help

Your transaction are NOT unconfirmed. As you can see here:
https://blockchain.info/tx/b5a9cb6a67429ec60c51f3aa197bec67af0003c841890132051f9fea40f71f76
https://blockchain.info/tx/77fc2aa152a80e0abe382a53d5254f113460a6f17cff95852bd0827a572e01cb
Both of them have over 700 confirmations. All, but one of your outputs are already spent.


text:
Can't remove unconfirmed transaction
Armory 0.95.1
Bitcoin core 0.14.1
I am stuck with a payment that has the state "not in the blockchain yet".
I already updated armory and bitcoin core, tried to rebuild the database and did the "clear all unconfirmed" command.
I added a fee of 0.0001 Bitcons to it, never had issues with this. The transaction was initiated several hours ago, it still has 0 confirmations.
According to blockchain.info the current confirmation time shouldn't be longer than 100mins...

0.0001 should be too little at current fee levels.

The best way is to select "remove all unconfirmed" and export the priv58 keys of your wallet.
The second step would be to import the priv58 keys into a working client, like bitcoin core.
The syntax is as follows:
importprivkey <key>

Armory 0.95.1 is incompatible with Bitcoin Core 0.14.1. Use Bitcoin Core 0.13.2 instead.

1) Clearing unconfirmed transactions is broken with 0.95.x
2) You can't RBF/CPFP with 0.95.x
3) 0.95 does not work with Core 0.14's refactored network layer
Your best path of action is to try out 0.96 and CPFP the unconfirmed transactions (using the Coin Control GUI in Expert mode):
https://bitcointalk.org/index.php?topic=1849994.0


text:
What is this 3d design of Bitcoin?
Lots of places online have a ray-traced, photorealistic image of an elaborate Bitcoin mint of the same design:
https://www.insiderfinancial.com/wp-content/uploads/2016/06/Two-Bitcoins.png
What is that design? where can i get a 3D model of it or a heightmap image of it?

I don't think that's a rendering. I think that's an actual copper coin with a bitcoin/circuitry theme.
Googling the text on the back, "AOCS APPROVED MJB 2013," finds this site, which gives the designer's name, Mick Bruce. Presumably "MJB" is his initials.
Googling that turns up this thread on BitcoinTalk, which is pretty similar to your coin.
I can't turn up a 3d model, but the designer, Mick Bruce, might have it. You might be able to contact him via the email in this thread, or by this onename.

There's now a free 3d version here https://www.thingiverse.com/thing:2724795

They sell the 3D models all over the internet. I have dozens of multiple designs, including MJB Copper and the one with the pick-axe on the back (my favorite).

Someone has copied a pretty good free version on thingiverse: https://www.thingiverse.com/thing:2724795


text:
My transaction was rejected
I don't know what to do about this transaction it have been send for days now and today i got message saying "Transaction rejected by our node. Reason: Transaction was previously accepted but has been pruned from our database"
tx hash:  414514d02b33b80fefce96669680d3e8e54d656d432958211dc632260b26f239
I don't know what do to about this

You should've used another blockexplorer instead of blockchain.info. The transaction didn't get confirmed due to low fees. I suggest trying to send it to ViaBTC transaction accelerator and see how things goes from there.

I discover i found the transaction back but it appear as uncomfirmed, what can i do to make it confirm and how can i add more fee to the transaction?

You can't add more fees at this point. use  ViaBTC Accelerator and send your TX HASH/ID there. It should get confirmed a few hours after doing so.


text:
I have waited for 2days now my transaction not confirmed yet
I have made 2 transaction but not confirmed yet
Blockchain: a68891b83177797c932873e3e5ff601bcea6e28b1cdbeb5a038dc0939c8371e0,
543c5f4612398c0b783fd3959a3390850a584c79a6c4fbe80bef88ebf455878f pls i need to be fix urgently

I can see that one of the transactions has been confirmed, so your problem is half solved. For the other transaction you just need to wait. If you're experienced enough you might as well want to rebroadcast the stuck transaction with a higher fee.
The problem
The transaction fee you have included in both transactions is way too low. At the current state of the bitcoin network, there is not enough room in blocks to fit all of the transactions, so the miners pick only the transactions with higher fees.
Prevent from happening again
If you require your transactions to be confirmed in a short period of time, then you need to include a much higher miner fee. You can use the following site as a guide as to what the fee should be:
https://bitcoinfees.21.co/


text:
permanent address
How can I set a permanent address wallets to send and receive?
How can I find out in advance which address the coins will be sent?
 We have a community in MLM that pays membership of the coins.
Upon registration, it is necessary to specify the address of BTC wallets. Payment system detects on the basis of registered wallet in the system. Now we have a problem because sending address changed every time..so that it shows in every transaction a different address.
You can help solve this problem?
Thank you in advance.
mark

It's confusing what you mean by "a permanent address wallets".  Can you clarify?  Also, it's good to use your question as the title, rather than a topic like "permanent address".  Being more clear will help you get better answers.

It seems to me that you're asking "How can I set my wallet to always reuse the same address?", but you're not telling us what wallet software you are using. Also, your explanation why you would want to do this seems very confused. It seems to me that there are better ways to do it, than address re-use.

If you are asking how to identify which payment came from who, then you want a new receiving address to be generated for each new member.
With an HD wallet you will have control of all address balances despite the address changes
https://bitcoin.org/en/glossary/hd-protocol


text:
How does the Segwit2x fork implement replay protection?
The creators of the Segwit2x fork claim that they are working on some sort of replay protection. What replay protection do they have and how does this replay protection work?

segwit2x temporarily had an opt-in replay protection, but chose to remove it.
it is intentional, as part of their strategy to make only one fork survive.

Interesting, do you have any thoughts on this: https://bitcoin.stackexchange.com/questions/61524/if-btc2x-doesnt-have-replay-protection-does-that-mean-all-btc-transactions-can

So does it mean they will NOT implement a reply protection at all?


text:
how to import private key without scaning QR code
I bought Bitcoins from the ATM and it gave me a receipt with a QR code.
and now after one year i wanted to scan it into my wallet, but ink on paper faded and it can`t be scaned.....
so im wondering if i can enter the private key manualy by keyboard?

What wallet do you use? Bitcoin-Core? importpivkey would work on Bitcoin-Core if your private key is WIF encoded.

Your QR code contains your private key, but yes you can recover with the private key directly if the QR code is now physically damaged.
I do not see that option for blockchain.info (which you stated you are trying to use in your comment):
https://blockchain.info/wallet/import-wallet supports QR codes Bitcoin-Qt (wallet.dat) and blockchain.info (wallet.aes.json) files.
Try one these methods instead (or choose another wallet which you prefer):
http://themerkle.com/how-to-recover-your-bitcoins-from-blockchain-info-using-electrum/
https://multibit.org/en/help/v0.5/help_importingPrivateKeys.html
https://en.bitcoin.it/wiki/Help:How_to_import_private_keys_in_Bitcoin_Core_0.7%2B

yes QR code is damaged, but private key that is  writen bellow QR code it`s still readable.
so where can i enter this key manually in my blockchain wallet

No need to re-invent the wheel for importing or sweeping paper wallets for mobile wallets such as airBitz, Blockchain, and Mycelium.  The Jaxx wallet also supports sweeping paper wallets under (Tools)->(Transfer Paper Wallet). These wallets should allow one to type a paper wallet's private keys if QR codes can't be scanned.

Actually the latest version of the Jaxx wallet says "coming soon" where this manual-key-entering functionality is supposed to be. So, no. Currently it is QR only.


text:
Bitcoin sending transaction error
I recently bought some Bitcoins(around 0.5) and sent some to a friend. He got them direct. Today I wanted to transfer some more but it didn't work. Every transaction was an error, besides one very small one(0.001 BTC).
All transactions are marked with a questionmark, so they are not confirmed for whatever reason.
After I restarted my bitcoin client, most of the transactions were marked with an exclamation mark.
I have no idea why I can not send money any more. Anyone having similiar problems and got a solution?
Thank you!
Here is a screenshot btw:

There could be many reasons for this. Provide us with the transaction numbers for better assistance. It could be related to transaction fees being too low, unconfirmed inputs or something else.

Alright here is the complete CFG:
https://drive.google.com/file/d/0B5hrAl7Okyv3bGRrV1RyYUVNMDQ/view?usp=sharing

BTW: The Transactions from Luca were chargedback aswell... : (


text:
Unconfirmed Bitcoin transaction
Please help me.  I have an unconfirmed Bitcoin transaction since three days. Below is the hash ID
a7f5f1989e0bbefeb012b22fbc8f011e5b6b0e66e802ea24242dc1d7878869bb

I would try an ATM if available in your area they seem to be alot faster, I've never waited more than 30 minutes and most of the time they are extremely fast.


text:
How does one node connect to other nodes
I am wondering how does one client connect to whole blockchain system if there is no centralized node which connecting other nodes together?
So for example if I want to create my own decentralized network how should my client now where to connect?

There is no centralised server required.
1.
If you start a node the first time, it will try to load a bunch of other nodes IPs via the build in list of available DNS seeds (there are ~5 seeds available).
2.
If those DNS seeds are not available, the Bitcoin-Core client uses its fallback IP list (a regularly updated list of IPs)
3.
Once a node could connect to one of those IPs (retrieved via DNS seeder or static list) it will ask for more IPs from known nodes (p2p address relay)


text:
Understanding Storing Bitcoin and wallets
I bought some bitcoin and have them saved on my PC on a MultiBit wallet.
I am a little confused as to how they are actually stored.
Are the bitcoins tied to my machine? So if I lose my PC the bitcoins are gone forever.
Or if I download the same multibit wallet on another computer can I enter my password and access my bitcoins from that machine?
Also what is a paper wallet?
And final question..... I have read Multibits policy on restoring wallet and the use of wallet words.  Are wallet words used by all types of wallets or is that just a Multibit specific security measure.
All simplified and intuitive answers will be of benefit as more people are starting to become aware of bitcoin and are probably thinking and asking the same things.
Thanks in advance

Welcome to the world of Bitcoin. One hint at the beginning: you raised too many questions at once, usually people here try to limit to one question, and answer it "accordingly". That makes it easier to follow up. Anyhow:
Bitcoins are not stored in a way you would have money in a wallet. The concept of Bitcoin circles around cryptographic keys (private and public keys). These keys are used to create and validate transactions, which transfer bitcoins from an address A to an address B, all noted down in the blockchain.
Your wallet is an abstraction layer, so that you don't have to work with these cryptographic keys. And every wallet has it's own idea on implementation, though there are some common rules. One of the major rules is: as long as you have the private key (on floppy, USB disk, or noted down on a paper), you are quite independant of any wallet.
Now on Multibit: if your PC crashes, your bitcoins must not be lost. You can make backups, and re-install on a new PC. Multibit has some info on the support pages on how to secure your wallet, by making backups and restores. Better read it carefully, and give it a try on a test machine  :-)
The more precise answer is: if you lose you private key (which is linked to the words of the multibit wallet), then and only then the bitcoins have very, very low probability to be somehow recoverd (all your bitcoins are lost).
On paper wallet: generally a paper wallet is a private key or words derived from the private key noted on a paper, so they can be used at a later stage to recreate a wallet (eventually with all its funds). There is a tag in stackexchange for paper wallet: https://bitcoin.stackexchange.com/questions/tagged/paper-wallet
you may find what it is, or do some web research. It has been answered before.
On Multibits use of words: it is not necessarily working in other wallets. It may work, or may not work. I haven't seen someone doing all the combinations - obviously already too many wallets out there!
My hints to all newcomers in rypto world: do some further research, e.g.:
1. the book „Mastering Bitcoin“, in many languages, by Andreas M. Antonopoulos.
2. „www.bitcoin.org“, with a description of the whole eco system, also in many languages.

Your wallet stores the secret (or private) key and your public address to interact with the money on blockchain securely. There are two kinds of wallets for storing keys:
Cold Wallet (wallet which is not connected to internet):
Cold wallet is an offline wallet provided for storing bitcoins. With cold storage, the digital wallet is stored on a platform that is not connected to the internet, thereby, protecting the wallet from unauthorized access, cyber hacks, and other vulnerabilities that a system connected to the internet is susceptible to.
The most basic form of cold storage is paper wallet. A paper wallet is simply a document that has the public and private keys written on it. The document is printed from the bitcoin paper wallet tool online with an offline printer. The paper wallet or document usually has a QR code embedded on it so that it can easily be scanned and signed to make a transaction. The drawback to this medium is that if the paper is lost or destroyed, the user will never be able to access his address where his funds are.
Another form of cold storage is a hardware wallet which uses an offline device or smartcard to generate private keys offline. The device looks and functions like a USB, and a computer and chrome-based app are required to store the private keys offline. Like a paper wallet, it is essential to store this USB device and smartcard in a safe place, as any damage or loss could terminate access to the user’s bitcoins. Two popular hardware wallets are TREZOR and KeepKey. These are expensive to buy.
Another form of cold storage is offline software wallets on desktop or mobile. They are mostly offline and pretty secure as long as your computer is not hacked. Electrum, Exodus and Armory are often quoted as the best offline software wallets in this category.
Hot Wallet(wallet that is connected to internet):
Private keys stored on a hot wallet are connected to the internet are vulnerable to network-based theft. These wallets are known as hot wallets. Here all the functions required to complete a transaction are made from online device. The wallet generates and stores private keys; digitally signs transactions using private keys; and broadcasts the signed transaction to the network.
It is considered "unsafe" because hackers have easier access to this than a cold wallet. So a minimal amount is stored on a hot wallet. The exchanges are the type of hot wallets. Examples: Coinbase and Blockchain.info
Generally as a rule of thumb you should only leave as much money on your hot wallet as you would with a leather wallet that you’d keep in your pocket. Think of it this way, if you were held at gunpoint while holding a leather wallet, then you’d only lose that money in your pocket, and not your entire bank account. If you keep all your money in Coinbase it’s as if you are walking around town with all your money in your pocket.

Bitcoins are not tied to your machine. They are linked to your private/public keys.
Basically, people send Bitcoins to a public address. Think of public address as a house address. Anybody can send a gift to a house address, which is publicly available. But only you, who have keys to your house, can stay in house and receive any gifts. These house keys are called Private Keys.
As long as your house keys(Private Keys) are safe with you, you alone can access your house.
For various security reasons, people transact using many public/private key-pairs. A wallet stores all these key-pairs mapped to one account.
This is good place to start: https://www.cryptocoinsnews.com/bitcoin-transaction-really-works/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Multibit showing account balance as zero
MultiBit showing my balance as zero.  Plus I have a transaction that has been unconfirmed for 18 days blockchain link to unconfirmed transaction
wtf... this is not cool... Need the money asap...  Bitcoin is not as cool as I thought...
Tried repairing wallets three times to no avail.
Is there anything I can do to get the money that is displayed in the image to be available to spend?
Thanks in advance

Repairing the wallet will not do anything, because the problem here is that the incoming payment is not confirmed.
You could either wait it out, or try to create a CPFP transaction, but I don't think that MultiBit has support for that. Anyway, the transaction appears to have confirmed by now.

As far as I know, it needs to be confirmed by at least 6 blocks before MultiBit 'allows' you to spend them (and the status changes from 'unconfirmed' to your actual balance). Did you include enough miner's fee?
In the "payments" tab, you can see the status of the transaction as well as a small green pie chart (1/6th = 1 block), reflecting the amount of blocks that have confirmed it.


text:
No bitcoins in my multibit wallet, but I have some when I look in the blockchain
I got an old version of multibit (the one like in my picture)

It says I don't have any funds even when I reset my wallet (multiple times which takes about half an hour each time).
When I look at blockchain.info and search my wallet address it says I still have some bitcoin left.

I got a wallet.dat file somewhere but I don't know how to import it into the new multibit (multibit HD) since they require you to have some mnemonic or something. There is no simple open wallet button like in the old multibit.
What can I do?

I just deleted my original answer now because I realised it was wrong.
If you have a wallet.dat file, then multibit classic is not the Bitcoin wallet you would have used. Chances are, you used the original Bitcoin software.
First you will need Python 2.7:
64 bit version
https://www.python.org/ftp/python/2.7/python-2.7.amd64.msi
Download this private key extraction utility which will display the private keys for your wallet.dat
https://github.com/dlitz/pywallet
Download the zip and unzip.
Open the command line (windows key + r) type cmd then press enter. Change directory to the folder you downloaded ie:
cd c:\Downloads\pywallet-master
Or c:\users\mike\downloads\pywallet-master
then type:
python pywallet.py --dumpwallet
press enter and you should hopefully see a list of bitcoin addresses and private keys (which start with the number 5).
Once you have these private keys, open a wallet with blockchain.info
and once you're in, click on the Import/Export button and click 'Yes I know what I'm doing'.
Click on Import wallet in the left side column.
You can then add the private keys by copying and pasting the output from the command line.

authors: Сергей Прочуханов


text:
Bitcoin tx with electrum has been unconfirmed for more than 24 hours and cannot be found on blockchain
I tried to sell some BTC yesterday but the coins did not arrive and the tx remained unconfirmed and still is now. When I right click 'view on block explorer' it says 'Transaction not found'.
What can I do? I paid the recommended miner fee.
This is what it says when I click on view transaction:

You seem to have set a fee of 0.00000686 BTC (around 27 US cents) or 3 satoshi/vByte.
The average fee is currently about five times higher than your fee and you have three outputs. So the size in vBytes may be larger than average.
Various sites suggest 13 satoshi/vByte for a confirmation in an hour.
Since you have RBF enabled, maybe you should use that to set a higher fee.

Thank you, so that's probably the issue. What can I do now? Just wait for it to be confirmed? I've seen messages online of transactions taking weeks. Is there anything I can do to make it confirm faster?

You can use RBF to raise the fee. See Why is my transaction not getting confirmed and what can I do about it?


text:
Can you mine your own transactions yourself?
If no, why not? And is it you physically/theoretically or practically cannot?
If yes, is this ever practical and does anyone do it?
As I see it now, no matter what you are taking a fraction/subset of bitcoins entire hashing power so the difficulty of finding a nonce would take longer than 10 minutes to confirm.
As I see it, for this to be practical...
Block reward + saved fees > mining costs * time
Where saved fees are the result of not having to pay other miners fees since you are doing it yourself and time is the time it takes to find the nonce.
note: this miner wouldnt have to be running full time

It won't save you any fees really, as the space you'd use in your own blocks for your own transactions won't be available for storing other transactions - so you pay the opportunity cost equal to the fees those would pay.

Theoretically, if you can mine blocks then you can certainly include your own transactions in the block.
Practically, you are competing with every other miner on the planet to find the next block. If you "win", you get the block reward plus you get to choose which transactions are included in your block. If somebody else wins, you get no say in the matter. Unless you have a very large mining operation, the chance of you winning is so small that it's never going to happen.
Miners who do make new blocks today (somebody has to, after all) may choose to include their own transactions in their blocks.

dont you choose the transactions before performing the mining operation?  To clarify my question, can you avoid the competition and mine your own transaction into their own block separate from the rest of the network until you do find the mining nonce solution and then add that to the longest chain

You can keep your blocks secret but that means other can't build on top of them. Every block has 1 (and only 1) parent. If you have less than 50% of the hashing power of the entire network, you can't out-compete the others. They will make blocks faster. Because when a block will drop is random, you might be able to get a block before anyone else does, and you might even get another one on top of that one before the others get 2 blocks ahead of the starting position, but you can't defeat the law of big numbers and will lose the race in the long term.

@Studnt But that would take a long time. And by including your transaction in the block, you'd give up the space that you could use to include someone else's transaction and thus give up their fee. What would the benefit be?

I guess there is no reason to keep the block/txs secret because if you dont pay a fee, no one else will include it in a block...or if someone does even better! @DavidSchwartz I guess the benefit would be that you could maybe avoid orphan blocks by just mining your txs because then no one else would be creating blocks with those txs?

@Studnt that is not how it works. The bitcoin mining ecosystem produces one single chain of blocks that is shared across the whole world. There is on average one block per 10 minutes. The contents of blocks has nothing to do with that. You need to compete with everyone else who produces blocks regardless of what you put in them.

The fees people pay for transactions aren't destroyed. They are paid to the miner who mined the block. Each block typically contains about 2'500 transactions. For this to work, you have to make about as many blocks as transactions. Your transaction fee then is less than 0.1% of the fees you get from others. Plus, the block reward currently is way higher than the total transaction fees taken per block. You'd be at less than 0.01%. So if you can make a block, why not do it all the time and easily get 10'000 the money you save?

wrt the saved fees, what i was saying is that normally you have to include a fee to incentivize miners to include your tx into the block. Otherwise miners would just keep creating blocks out of other higher fee txs and your would be stowed away into a mempool i think is what its called??? If you were able to mine your transactions yourself, you wouldnt need to incentivize anyone with a fee because you are already incentivized to verify the block

Yes, that's correct.

@Studnt But then you'd just be cheating yourself. How would that help you? By including your own transaction, you'd forfeit the fee of someone else's transaction that you could have included instead.

@DavidSchwartz Im getting the impression that regardless of what is in the block, the difficulty of finding the nonce is the same. So mining your own txs is no easier than mining everyones or no ones...and that you dont avoid any mining competition by withholding your own txs and making a block out of them

@Studnt Either you are in a hurry to get your transaction confirmed or you're not. If you're in a hurry, you had better let other people mine it. If you aren't in a hurry, you're going to pay the minimum fee anyway, so what benefit do you get from mining your own transaction instead of someone else's?

@DavidSchwartz It would benefit you if the miner fees > cost of mining it yourself...but it sounds like mining it yourself is much more costly

@Studnt The cost of mining a block is currently about 14 BTC. And that's when you don't care when exactly you mine a block. A little less, of course, so miners make a profit. The cost of mining a block always is about as much as the miner gets for doing so because it's a self-regulatory system. But even that is assuming you have access to really cheap electricity. People mine where electricity is the cheapest.

@Studnt It still wouldn't benefit you. Because in order to mine your transaction, you'd have to forego the opportunity to mine someone else's. And since you weren't in a hurry, your transaction would be the cheapest.

If you can separate block-creation consensus from coin-creation work, a coin could use self-hashing transactions to prevent the need for pools. The transaction would include a destination address, a difficulty you set yourself, a block number in the near future that gives enough time for a block-creator to include it, and a nonce. You hash the txn until the nonce solves the difficulty that you chose.  https://zawy1.blogspot.com/2019/03/a-virtual-pow-to-prevent-51-attacks.html

i was looking at it from the purpose of trying to figure out how https://app.originstamp.org/home does free trusted timestamping based on sending bitcoins to i assume their own accounts, with a hash.
So the use case of being able to mine your own transactions is for an app that requires secured time stamping, like if users needed to timestamp legal documents.
1) no transaction fee
  2) you put your miner in your same network, so no network fee and lower latency
  3) You dont have to wait forever for the transaction to be processed if you are trying to reduce fees. I dont know anything about fees vs time for minimum sum BTC transfers to happen, and if running a small miner server to perform this within my network is what it takes to not have to worry about it... it's something to be explored

Both you and the OP seem to misunderstand something.  Namely, you seem to think that transactions are mined.  They are not.  Blocks of transactions are what actually get mined, and that makes a world of difference.  For more details, see my answer here:  https://bitcoin.stackexchange.com/questions/49569/why-does-the-blockchain-need-blocks/49570#49570

So after doing more research after the post, i found out that mining a 'standard' block would take a single small machine at least a day. Most of the content available on block size, seems to be talking about increasing a hardcoded 1mb limit. Is it possible on a server side, to process an extremely small block size (ie..only my own internal transactions)?

I don't know where you got your information, but mining a single block would take much longer than a day.  In fact, it would take much longer than a human lifespan.  You would be dead before you'd mine a block.  The size of a block is not a factor in how long it takes to mine a block.  Mining a block with just your transaction would take the same amount of time as mining a block with a million transactions.  Also, there is no such thing as "server side" in Bitcoin.  It is a peer to peer network.  I don't believe you have done enough research to understand what you are taking about.


text:
What is ASIC hardware good for besides mining?
Are there any other uses for ASIC hardware besides mining crypto?
Also what are the consequences of the hashing power race?

Space heating and noise emission.  :p

haha, I just can't believe Satoshi didn't have a good reason for implementing it this way. Gotta be some reason...

Satoshi probably did not envision ASICs at all.

ASIC stands for Application Specific Integrated Circuit.
This is hardware that is specifically designed for one use case.
Bitcoin mining ASICs are good at one thing: Bitcoin mining. If they were good at more things, they'd be less efficient and/or more costly than they need to be, and competition would replace them.

But can't you use it to brute force hashed passwords?

No. It can only hash data that is in the specific structure of Bitcoin block headers. And it's only efficient at searching through various nonces that are in the specific byte position in which they occur in Bitcoin.

@N0ir https://bitcoin.stackexchange.com/questions/16490/using-asic-for-password-cracking-mad-concept

@PieterWuille ok makes sense. How hard would it be to modify bitcoin ASICS to use them for password brute force? What I am trying to understand is what is the purpose of bitcoin mining race and where it leads (besides getting bitcoins)? I was thinking maybe the purpose is to bring the hashing power (technology) to the level where no hashed password will ever be safe to use? So that the only thing that is safe to use for financial purposes would be blockchains

The purpose of the Bitcoin mining race is Proof of Work, nothing else. It makes creation of a chain costly, and thus incentivizes miners to produce a valid chain - as an invalid chain would not pay them anything. The presence of Bitcoin mining ASICs does not in any way make password cracking easier, you need different hardware for that.

Possibly to break cypher codes.. i often wonder if that's what really going on sopmewhere with the congregation of computing power to create what amounts to mega computers designed to bust thru huge blockchains of data


text:
I sent the BTC to a wrong address
I was trying to transact BTC and the end receiver gave me an address. I couldn't afford the amount due to spreads on transactions so we lowered the amount, made a new address and i sent it but I accidentally sent it to the first address and not the second. What can I do? The BTC already left my account and I'm sure it won't reach theirs because the transaction was declined.

What kind of wallet did you send it from? And what do you mean it was declined? What is the address you sent it too and can the receiver not access the BTC at the original address?

I sent it from my exodus wallet. I'm not sure how to get the money back, the address was cancelled before I sent my BTC then I sent my BTC to that address. It has been confirmed  6 times already.

Possible duplicate of Incorrect bitcoin address funded

The only thing you can do is ask the owner of the address you sent the bitcoin to to send the bitcoin back to you. There is no such thing as a "declined" transaction in bitcoin; transactions that get included in a block are final.

They sent me an address to send the BTC to. But the amount was too much, I couldn't cover fees so I cancelled the transaction. I then restarted again and they sent another address. I input the coin amount but I forgot to change the address. It sent the BTC to the first address and I don't know what happens to it on their end. I just got confirmation that my transaction was cancelled but my BTC hasn't been returned. I dont' know what to do.

@JonathanBenjamin Do you know who owns "the first address"? Ask its owner to refund you.


text:
Can rainbow tables be used to find private keys from public keys?
I understand that the public key is kept hidden until a bitcoin transaction is made, at which point the public key has to be revealed to prove that you created the transaction with your private key. Until then, only a hash of your public key is ever shared, know as your bitcoin address.
Once my public key is known, would it be possible for someone to lookup my private key in a rainbow table ?

Such a rainbow table already exists at directory.io. ;) However, you'll find that the site is a tongue-in-cheek joke explained by Pieter's answer below.

Technically, directory.io is not a rainbow table as it computes the keys on the fly. It's close to impossible to store all keys in a table.

No.
A rainbow table is simply a memory-cpu tradeoff that allows you to find preimages of a function faster by having a precomputed table with some of the entries.
In order to construct a rainbow table for bitcoin private/public keys, you still have to first iterate through all the keys at least once. It doesn't matter that only part of the keypairs will end up in your rainbow table - you still have to go through all them.
That is an impossible task. There are 115,792,089,237,316,195,423,570,985,008,687,907,852,837,564,279,074,904,382,605,163,141,518,161,494,336 valid private keys to go through. To put that in perspective: if you would put a computer on every square micrometer of earth (1/1600th of the cross section of a human hair) that can compute as many public keys per second as the entire Bitcoin mining network does hashes per second at the time of writing (4 exahash/s), it would take you 120000 times the age of the universe to go through all keys.
And, even if somehow you had an oracle that could give you the rainbow table, it would need to be impossibly large to make cracking private keys practical. If your table had a trillion entries, it would only make cracking a trillion times faster. That's still utterly impossible.

High up in the north, in the land called Svithjod, there stands a rock. It is a hundred miles high and a hundred miles wide. Once every thousand years a little bird comes to this rock to sharpen its beak.
When the rock has thus been worn away, then Pieter's computation will be complete.

Yeah, but what if Bitcoin is around in 120000 times the age of the universe? I'm worried because we might have a dip.

Thanks for the large bitcoin collider (LBC) link. Had a long look at it but it's way over my head. Seems they are finding private keys regularly that fit active accounts with some BTC on them. That's an an alarming sight. Especially since this is still running on a tiny scale.
Then I came across this excellent post:
https://www.reddit.com/r/btc/comments/65mjm3/bitcoin_wallets_under_siege_from_collider_attack/dgbudsk/
As to why the LBC seems to have already found private keys to active accounts, he answered:

The wallets they've attacked so far are not generic random-private-key
  bitcoin wallets as the usual ones, but they've been specifically
  crafted to be broken. They belong mostly to the puzzle transaction
  which contains many "easy" private keys.

What does that mean?
I'm not entirely sure these are all talking about the same approach/problem, but I think it's similar in the end: How hard is it to find a private key to a specific active bitcoin address or any of the active bitcoin addresses? I hope dyoniziz from reddit is correct.

LBC will only ever find keys that were generated with insecure random number generators. Anything else requires astronomical amounts of computation power which the technology is designed to withstand, so don't let it scare you.

Can you elaborate? I don't understand why keys generated with random number generators would be more likely to be found by the LBC? I thought LBC just goes through the possible keys methodically, from start to finish so to speak?

Things generated with insecure random number generators are easier to find by trying to mimick the algorithm they used. A good random number generator produces numbers that are indistinguishable from random, so every search pattern is as good as any other. And the key space is so massively large that it is impossible to ever hit one by chance again.

@PieterWuille "it will only ever" – when they calculate for long enough, the will find everything. we will see how fast computing can be in our livetime and if bitcoin breaks over it. I also feel quite comfortable right now, but that can change, we have to face that.

Good luck, then.

Lets say, I have 101 private keys generated by a pseudo-RNG, but I lost one.  Theoretically, I think its possible to use 100 private/public pairs to crack the missing one.  Because , while the actual number space is crazy large, the pseudo-RNG number space is limited by the floating point space of the hardware itself.  Also, I think it is possible to create a rainbow table from the 100 which makes it more accessible.  If I am wrong, someone please explain.

I downvoted. This answer is completely wrong. A properly designed PRNG does not let anyone derive information about the state or other outputs given a known outputs; it would be completely broken if that was the case. No floating point is used anywhere. Rainbow tables are completely useless as I explain in my own answer below.

I have a college textbook, "Making and Breaking Codes", written by Paul Garrett and it is 4th year text in mathematical encryption degree which says otherwise.
Some old ones are crackable. There's also PRNG cracking software such as Mandarino which has allowed some people to make money cheating online casinos.  The internal state of the PRNG supposedly can be discovered since it is actually a deterministic algolrithm.  So, being properly designed would include some random data such as CPU temp, fan speed, mouse movements etc.  But PRNG from the year 2000 might not have included that.

indeed that would theoretically be possible. such a table luckily is very large. for more read e.g. on the large bitcoin collider. if an active address means that is spends money, then the pubkey is revealed which makes it easier to attack. as long as an address only received money it is protected better by the 2nd hashing layer.
lbc can be ignored but they walk systematically through the keyspace from small difficulty to large by entropy. easy to find keys are just a bait to have more people involved. @Pieter: of course weak RNG is a problem, but that was not in question; we better get some open hardware standards for TRNG.
interestingly people vote this down. we have to face it: there are problems with the implementation of bitcoin apart from just scalability. the hashing was not well thought through and the ecc algo (Secp256k1: T=(p,a,b,G,n,h); a=0, b=7 … h=1. see slide by ruedi) got the parameter a nulled without any good reason (performace is not a good argument at all in means of crypto). cryptography does not honor weaknesses, small they may be.

No change to the hashing algorithm would make keys generated with an insecure RNG secure. I have no clue what ecc parameters you're talking about.

@PieterWuille 1st nobody claimed, if so point me there plz, and 2nd you hopefully know. math is not secret: ruedi on 31c3; Secp256k1: T=(p,a,b,G,n,h); a=0, b=7 … h=1.

Yes, a=0 is a conscious choice that makes certain operations faster. There are no known attacks against that choice.

I know, you know, but is no good argument still. Go ask the cryptographers around, they will tell you like that one did if they are sane. Altering crypto-implementation for performance is simply one of the things you should not do if you have the choice.

Nothing was altered. Secp256k1 was an elliptic curve standardized by the SECG before Bitcoin existed. Satoshi just picked one curve before EC was cool, and ended up picking a different standard than what the rest of world went with. It was an unusual choice at worst, but not a bad one

I've downvoted, because this answer doesn't provide useful information. "Theoretically possible" should be properly quantified and "problems with the implementation of bitcoin" should be substantiated with credible evidence, because as presented here the post completely overstates the actual possibility of such an attack and could alarm uninformed readers.

authors: Татьяна Дубисинюк


text:
What is the status of the "Hong Kong Agreement"
Are the bullet points below still valid?

We understand that SegWit continues to be developed actively as a soft-fork and is likely to proceed towards release over the next two months, as originally scheduled.
We will continue to work with the entire Bitcoin protocol development community to develop, in public, a safe hard-fork based on the improvements in SegWit. The Bitcoin Core contributors present at the Bitcoin Roundtable will have an implementation of such a hard-fork available as a recommendation to Bitcoin Core within three months after the release of SegWit.
This hard-fork is expected to include features which are currently being discussed within technical communities, including an increase in the non-witness data to be around 2 MB, with the total size no more than 4 MB, and will only be adopted with broad support across the entire Bitcoin community.
We will run a SegWit release in production by the time such a hard-fork is released in a version of Bitcoin Core.
We will only run Bitcoin Core-compatible consensus systems, eventually containing both SegWit and the hard-fork, in production, for the foreseeable future.
We are committed to scaling technologies which use block space more efficiently, such as Schnorr multisig.

https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff#.8vbwu3ft7

The full code for Segregated Witness was released on 19th of April, which to the letter fulfills the requirement. However, apparently some people had understood the first point to mean that it would be in production in April which was not the case.
Following the above, an implementation for a hard-fork would be expected to be delivered by 19th of July.
IIRC, Bitmain's Jihan Wu has recently stated that point 4 is to be interpreted as them requiring the code for a blocksize increase hardfork to have been merged into Bitcoin Core before they run Segregated Witness in production. This is of course a much stronger requirement than point 2 and point 4 which could be read as them starting to use SegWit at the latest when code for a hardfork is released.
The argument has also been made that by allowing voting for Classic, some pools have breached point five. The disagreement here is chiefly about whether Classic constitutes an incompatible version. Until a Classic node activates, it follows the same rules, so proponents argue it is compatible. Yet, since Classic breaks with the current rules as soon as it activates, others declare it to be not "Bitcoin Core-compatible".

Altogether, it seems to me that there are still a lot of misunderstandings and conflicts of interest to be ironed out. Vastly diverging priorities and language barriers add to the difficulties. There also seem to be very different assumptions about where the community support lies and how the power dynamics in Bitcoin will work out.
As far as I can tell, we can only wait and see how the situation develops. The next step appears to be the imminent inclusion of Segregated Witness into the next Bitcoin Core release candidate. Once some miners start signaling readiness for Segregated Witness, the situation will probably evolve quickly.


text:
Verify value of input address
Think about a bitcoin transaction:
Inputs: Address1: 2 BTC, Address2: 1 BTC
Output: Address3: 3 BTC
So the value of Address1 is because of two previous transactions where every one of those 2 transactions sent 1 BTC to Address1. How is a full node now be able to verify that the amount of "2" is correct for the transaction?

Transactions don't work like that, so this issue does not arise.
Inputs of a transaction don't specify addresses, they specify previous transactions; more precisely, a particular output from a previous transaction.  The data included in an input is a transaction ID and an output index.
So in the example you cite, the transaction would have to have three inputs: one for each of the two Address1 transctions, and a third for the Address2 transaction.

Ok, so we can get a step forward. Think about the transaction X with value 2. The input references a transaction and we actually do not know in which block the referenced transaction is. How to prove that value of "2"?

Edleredge: I know how transactions work, but you did not get my question. Some guys only want to get attention with the minimum amount of time spending in the answer.

@ErhardDinhobl: Sorry I missed your previous comment.  We have to actually find the referenced transaction in a block (or in the memory pool).  This can be done very efficiently by a standard full node because it creates an index of all validated transactions, mapping a txid hash to the block, and offset within the block, where the transaction itself can be found.


text:
Question on interpreter.cpp in Bitcoin core - set_success method
https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp
Line 22 => Where is declare "ScriptError" ? What does the "*" mean ?
           "inline bool set_success(ScriptError* ret)"

The enum ScriptError is defined in https://github.com/bitcoin/bitcoin/blob/master/src/script/script_error.h, and the * means that set_success requires you to pass a pointer to an enum value rather than the enum value itself.
I have to tell you, however, that if you are asking questions like "What does the "*" mean?", then you are going to have a hard time understanding C++ code.  I highly recommend doing some tutorials on C++ programming before going any further.

I  know about pointers I was just disturbed by the fact that it is wrote "ScriptError*" and not "*ScriptError"

*ScriptError would mean dereferencing a variable named "ScriptError".  For example, see line 25 interpreter.cpp, where ret is dereferenced in order to assign a new value.  I think you are thinking of writing set_success(ScriptError* ret) like set_success(ScriptError *ret), instead.  In C++, both mean the same thing.

Do you understand what is happening line 167 ?

std::vector vchSigCopy(vchSig.begin(), vchSig.begin() + vchSig.size() - 1);

It's creating a copy of vchSig called vchSigCopy.  However, it's neither possible nor appropriate for me to teach you C++ in the comments.  Some of these questions you've been asking are very fundamental concepts in C++.  You really need to take some time to learn the language if you want to understand Bitcoin's code.


text:
Projections for reductions in price of hardware wallets
The components of hardware wallets are not very expensive (at least when purchased as scale). I understand the need to recover R&D costs and that higher sales volume will increase negotiating power with component and manufacturing providers.
Are there projections for the future prices of existing hardware wallets (such as KeepKey, Trezor and Ledger) over the next 12-24 months based on projected sales data?
When hardware wallet costs near the cost of flash drives, then usage and security for new bitcoin users (and minimal funds) should increase dramatically.

This data on Ledger production costs seems relevant:
https://forum.daohub.org/t/ledger-proposal-for-the-dao-1-ethereum-hardware-wallet/1750

Significant price savings exist with orders as small as 6,000 units
Q: "Why 6,000 units?"
A: "This is our estimate of the best compromise of minimum order needed to get good prices, without having too much stock on hands if the market is going bearish"
120,000EUR/6,000 units = 20 Euro per unit compared to a retail selling price of 59 EUR (without tax). Based on this data, significant scaling has already occurred. Higher prices (compared to production costs) reflect revenue sharing agreements with partners (in this proposal the DAO would have been paid 25 EURper unit) and profits for the wallet makers themselves.
"When hardware wallet costs near the cost of flash drives, then usage and security for new bitcoin users (and minimal funds) should increase dramatically." Depending on what type of flash drive and hardware wallet you are referring to this has occurred already. The Ledger HW.1 retails for 18EUR:
https://www.ledgerwallet.com/products/3-ledger-hw-1


text:
C++ and secp256k1
I am working on a tiny C++ bitcoin application for a university project. I'm using Blockcypher API to create transactions, but I faced a problem with signing transaction's hash that returns one of the methods. Are there any simple C++ libraries that will allow me to sign this hash with secp256k1 ECDSA? Also, library must work for Android NDK development.
Maybe I have found one, but I have a problem with installation, and I don't exactly know if I can use it with Android NDK.
Thanks for all answers!

That link is an older fork of libsecp256k1 with MSVC support added (see Jannes' answer)

Maybe libsecp256k1, which is what Bitcoin Core itself uses. Not sure about Android usability, but it compiles on many architectures.

Libsecp256k1 is pure C89, with optional assembly optimizations (including ARM, since very recently). It may need some tweaks to work on Android NDK, but should otherwise work fine. Feel free to report any issues around that on the issue tracker: https://github.com/bitcoin-core/secp256k1

You may want to check out Spongy Castle, which is the Android-specific port of Bouncy Castle.  I've used Bouncy Castle in C# to secpk2561 functions, so I assume Spongy Castle will have what you need, although it will be Java and not C++.
Also check out this question on SO:  https://stackoverflow.com/questions/29778852/how-to-create-ecdsa-keypair-256bit-for-bitcoin-curve-secp256k1-using-spongy


text:
Is there a way to estimate the price based on the blockchain?
Suppose I need a rough estimate of the current value of BTC in USD, is there anything in the blockchain that could be used for that? For example, is there some kind of correlation between block difficulty vs price, number of transaction vs price, etc?

Not currently. There is a rough correlation between difficulty and price, but it tends to be the latter affecting the former (so a delay is involved), and you certainly couldn't use it to predict with any usable degree of accuracy. Theoretically, when (if) Bitcoin stabilizes significantly, you could use the current difficulty to predict the price with reasonable accuracy, as mining profit margins would approach zero, but the markets are too volatile and entry barriers to mining too high at the moment for that measure to work accurately.
If you're trying to implement the current exchange rate in a program, see this question.

I wrote a bitcoin price theory is about a correlation of number of bitcoin addresses
(from blockchain) and the bitcoin price, with a law of networking use like the metcalfe law.
here I posted my study about your question
https://bitcointalk.org/index.php?topic=441336.0

Interesting post, but doesn't Bitcoin price lead amount of Bitcoin addresses?

Not really, you could kind of guess that as difficulty rises the previous price should technically go up to make sure the miners receive an equal reward, but this is not a rule its just speculation. so yea there is no hard data in the block chain that would actually determine price. You have to assume any expected changes to the chain are also usually pre-priced into the market price


text:
Is there a reason why MtGox is based in Japan?
I was wondering why MtGox is a Japanese company. The founder was American, and the current owner is French, so is there a special reason why Japan was attractive for them?

Mtgox owner was already in japan and already had his company there when he decided to buy mtgox from historical owner Jed in 2011.

mtgox owner s blog : http://blog.magicaltux.net/
hosting company that existed years before he decided to buy mtgox : http://legal.tibanne.com/ , services on https://www.kalyhost.com/


text:
Is there a database of all transactions?
The blockchain is a database of all valid transactions, but is there a company/project that also logs all transactions which were broadcasted, but didn't made it to the chain? Blockchain.info for example, keeps a history of all double-spends, so I assume they keep such a log, but its not publicly available.
I could very easily calculate how much was lost by transaction maleability if something like that was publicly available.

Blockchain info does not keep for a long time double spend transactions. They keep them about several days.

@Zergatul That their interface doesnt show any older than a few days, doesnt necessarly mean they are not stored in their database. I would be surprised if they took the effort to actually delete them, since they require virtually no space compared to the valid tx's.

If this is true, someone can easily spam their database.

@Zergatul Good point!

I haven't seen anything that is tracking all transaction including failed ones, etc although  this project looks like it has promise:
http://codesuppository.blogspot.co.uk/2013/07/work-in-progress-on-bitcoin-blockchain.html
That said I'm not even certain what your suggesting would be possible.  Consider the following scenario.
If a person / organisation were monitoring and recording all transactions and I were to submit a transaction that then where then to be marked invalid and discarded, the nature of bitcoin is that you send your transaction to peer nodes who in turn will broadcast those out if they verify the transaction.  Now If someone can explain to me otherwise than fine but surely this transaction would only have a limited number of broadcasts before a different chain showing it to be be invalid was received and the erroneous block discarded.  Now unless the 'monitoring party' where within the peers that received the broadcast there would be no way for them to track it?

Muis, a friend and I are working on that exact project. We want to track which transactions get mined and how long it takes different types of to get mined.
Its kind of a large ugly monster right now but we are actively working on it. The database of transactions is stored in a postgresdb.
Check it out: https://github.com/NSkelsey/TxWaitTime


text:
How to use downloaded blockchain on ubuntu?
I am using a fresh install of Bitcoin and have no wallet with coins at this time, and want to use the Bitcoind service in short time (loading blockchain using bitcoind will take days because of slow pc, can not wait for that also because PC can't run all day). So I decided to download the blockchain from http://eu1.bitcoincharts.com/blockchain/.
But how do you use it? I am using Ubuntu 10.4 and Bitcoin 0.7.0. I already placed the downloaded files in .bitcoin directory and then run bitcoind but then it just started downloading the blockchain from the network, ignoring my downloaded files.
Thank you in advance.

That set of the blockchain data files doesn't contain the required index.


text:
One node accessible under several ip-addresses?
Is it possible to make one core-node accessible under several ip-addresses? (with the result that other nodes can not recognize that it is the same node under two different ip-addresses)
If this is not possible: Why?

Yes, it is possible.
You simply need to listen on the different IP addresses. What is necessary to do that and the steps required depend on your network configuration and hardware capabilities.
The trick is then to get your node to advertise all of the different IP's, which on some node software I think (from practical experience but, without going back actually to confirm) that you can just specify multiple external IP's.
I am not sure that this accomplishes much, however. If you have the bandwidth you can just modify the node to allow a high number of incoming connections and use a single IP.
Also, I suspect, others may confirm, that the default connection rules have subnet spacing integrated so that the same node will not connect outgoing to all connections in the one subnet.
If you control traffic and DNS on your network it is trivial to ruin Bitcoin via a number of methods as you could the operation of any application.

you are talking tcp/ip network stack and name resolution here. It can be done, you can change your IP as often as you want on your system. For a core node this doesn't make sense, so this looks like someone wants to find a way to destabilize the network. Or where you tricked by someone?
On DNS and tcp/ip stack, this is the wrong area here - this is not a network stackexchange...

The question of whether it is undetectable as the same node is very on topic, however.


text:
Make a spendable Bitcoin transaction with a message
I am trying to send a bitcoin transaction which encodes a message. I know about OP_RETURN however this makes the transaction un-spendable. I want to make a spendable transaction that contains a message.
This transaction's message needs to be publicly on the blockchain as well.
How can I do this? Any supporting code would also be much appreciated.


text:
Can SegWit block weight be increased without a hard fork?
I know segwit's block weight is 4MB. Can it be increased without a hard fork? If no, was that option even considered, and is it even possible?

The explicit block weight limit cannot be changed without a hard fork.


text:
Sent wallet to desktop
I had bitcoin core and dummy me deleted it but I sent my wallet to desktop and now I have a new wallet, are there any way to get the wallet that is on my desktop back into bitcoin core? I tried to copy and paste but that does not work. I went to %APPDATA%\roaming\bitcoin but could not do a copy and paste into it. Any way to get my wallet back into it.
Thanks for your time.
RoberT

What problem do you have when you copy and paste?  Does the file not copy, or does the wallet file not load when you restart Bitcoin Core?

The file does not copy,I am reindexing now for a new wallet.

Make sure that Bitcoin Core is not running when you attempt to copy, otherwise it may have a hold on the file.  Also make sure you are running as a user with sufficient permissions to copy over the other wallet file.  It sounds like it's your operating system that is not allowing you to copy...not Bitcoin.


text:
Can there be a blockchain without mining?
This is a question about Blockchain in general, not about Bitcoin as a currency on top of Blockchain technology.
Let's say I want to issue a vote on top of, lets say, multichain. I would issue an asset called "voting_right". Let's say I have 1000 participants, so I create 1000 voting rights and send each participant address one voting right. Everyone can either transfer their vote to somebody else or directly to a vote option.
I don't have given anyone mining permissions, because I don't want anyone to "illegally" earn voting rights. On the other side, I require miners to collect the votes into blocks and prevent double-voting.

Can there be a Blockchain without miners?
If no, what I am assuming, is there any danger if I, let's say create two mining-enabled multichain nodes (with 0 reward), 100% controlled by me? How can others trust me?

To answer the other part of your question, can you please clarify what you mean by "mining"? Is it proof-of-work mining? Or are you just referring to nodes doing the needed verification and gossiping to achieve consensus?

Just to note that the scenario you described can be implemented easily using, say Counterparty, without any risk of miners illegally getting any of the voting tokens. The miners' rewards are different from the asset/token you want to create.

related: http://bitcoin.stackexchange.com/q/44409/5406

I don't know anything about Multichain so I'm not sure if this is the answer you're looking for, but here's one answer that might help you.
The interesting thing about proof-of-work (Nakamoto) blockchains is that they enable a constantly-changing set of unknown nodes on the internet to achieve consensus under certain assumptions about the adversary (i.e., the good guys are more "powerful" than the bad guys).
Before Bitcoin, no one knew how to do this (AFAIK) and all consensus algorithms required that the participants were known and that 2/3 of them were honest. Typically, an admission control process was used to decide who could participate and who couldn't. This was, for the most part, a human process.
Now, blockchains solve this very hard problem of permissionless consensus: How can you agree on a log of operations among N participants as they leave and join the system, without an admission control process? The answer: Use a little bit of economics to incentivize participants to behave correctly, no matter who they are (i.e., Bitcoin).
Now, with this understanding of the hard problem Nakamoto blockchains solve, you can image that a system such as the one you propose (if I understand it correctly), where users have to trust you to correctly dictate consensus, is not that interesting nor useful. It is well known how to achieve consensus with trust: just use any Byzantine agreement protocol and keep 2/3 of your nodes honest.
I am not sure if I properly understood your question and your system, so I hope this answer is not completely useless to you.

The other answers explain the problem that mining solves -- of the many possible valid blockchains, which is the one that everyone can agree on? Proof of work solves this -- the valid chain that took the most work to produce is the one that everyone agrees on.
There are other solutions. Note that some of these may not be sufficiently secure for some use cases, and it's very easy to implement these things incorrectly and not get the security you require.
For private or permissioned blockchains, PBFT can be used. With this scheme, "miners" are chosen when the system is set up. "Miners" can be added or removed by agreement of the existing "miners". Rather than using proof of work, the "miners" in this scheme agree on the valid blockchain. In one scheme, those "miners" who are currently operating rotate in getting a turn to create a block. The other "miners" sign that block so that everyone knows its valid. This kind of system cannot make forward progress unless a majority of miners are operating and will not function reliably unless at least 2/3 of miners aren't malicious.
For public blockchains that have a native cryptographic asset, proof of stake can be used. This is much like the scheme above except that those who hold the native asset are allowed to "mine". Bond schemes can be used such that proof of incorrect operation by a "miner" forfeits their bond.
Schemes such as Ripple's consensus algorithm can be used. This works much like the PBFT scheme except that it doesn't require strict agreement on the "miners". This makes it suitable for use on public/permissionless systems.

I'd like to add my own answer and remark that Alin Tomescu's answer does a good job of explaining the problem proof of work solves, so I won't go into those details.
The concept you describe could work. The problem is it makes no sense to use a blockchain to do this. Since your concept requires trust in the original issuer there's no reason for a blockchain to exist. The point of a blockchain is to provide a trustless, publicly verifiable and distributed ledger of transactions. As each block is added to the blockchain without a consensus algorithm such as proof of work mining where miners have incentive to not rewrite transactions, how does the network decide which blockchains are correct? For instance if I connect to one of the nodes in your network what's to stop that node from feeding me an incorrect version of your blockchain (on in which it didn't spend it's vote)? The only way I think this can work is if the original issuer signs each block with their private key that the public can then verify as being correct.
The concept you describe could easily and much more simply be implemented using a central database (you can make it publicly accessible as well) where you record the signed votes of your members in one table and in another table members can transfer votes to other members by using their vote to sign the transaction. In this scenario you are the certificate authority who issues the voting certificates to your members. You and the public can verify the votes in the database with a certificate chain that you make publicly available. This allows the individual voters to remain anonymous in their voting decisions, but still verifiable that their votes were made with a certificate signed by the central authority (the one person we are required to trust). Using a central database also prevents the problem of not knowing which chain is correct.
Basically, making use of a blockchain and removing the trustless factor can easily work, but it's slower and completely overkill for the job. If you don't need a trustless system, then simply use the efficient tools we have already built for trusted networks.
I really hope I've understood your question correctly and have provided a helpful answer.

Mining is still a murky concept to me. Mining, as I understand it, is used to verify and secure unconfirmed transactions. Based on what I've read, for Bitcoin it seems to mean that when a transaction occurs it is unconfirmed until a new block is verified. My assumption has always been that the block is not "written" until both unconfirmed transactions are in the queue AND a block has been "mined" with a bundle of unconfirmed transactions.
If “mining” sounds like a process which extracts value from Bitcoin, nothing could be further from the truth!
Miners are the backbone of the Bitcoin network:
Without miners, the network would collapse and lose all value.
The role of miners is to secure the network and to process every Bitcoin transaction.
Miners achieve this by solving a computational problem which allows them to chain together blocks of transactions (hence Bitcoin’s famous “blockchain”).


text:
Attach and persist identity to address
With Bitcoin, you can sign messages to prove that you are in possession of a private key associated to a public key. Correct me if I'm wrong, but from my understanding this only works with a separate communication channel, such as email or a central system where you request the other system participant to sign the message for you.
I think this works great if you want to confirm a shipping address in order to make sure the person who paid is aware of where the shipment goes (if you want to accept the fact that everyone in the network can see your shipping address).
But does that work for a notary use case, for example? How can you know, using Bitcoin message signing, that the company "AMCE Ltd." is actually behind the address "XYZ"? Is this only possible if you actually call AMCE Ltd. or email them for them to sign a message for you? What if you can not trust the communication channel (e.g. message gets intercepted by a potential attacker).
The only thing I can think of that can solve the problem is introduce a middlemen you are required to trust (from what I understand, Onename.com is such a middleman) and who does the background check for you. But from my understanding, this would eliminate a significant part of the value of Blockchain. Why would you need a distributed ledger anyways if you already trust the middleman?

I think this works great if you want to confirm a shipping address in order to make sure the person who paid is aware of where the shipment goes (if you want to accept the fact that everyone in the network can see your shipping address).

You can embed an shipping address into the blockchain using OP_RETURN or something similar, but a much simpler way is to sign your shipping address using your bitcoin address, and send that via a private channel.

But does that work for a notary use case, for example? How can you know, using Bitcoin message signing, that the company "AMCE Ltd." is actually behind the address "XYZ"? Is this only possible if you actually call AMCE Ltd. or email them for them to sign a message for you? What if you can not trust the communication channel (e.g. message gets intercepted by a potential attacker).

You need some sort of trusted communication channel to send an address. If you do not have one, most methods of starting one (like SSL) involve some kind of trusted third party.
But that's not unique to Bitcoin, of course. There's a huge problem with fake, nonexistant businesses on Google Maps. In order to create a naming system that resists tampering and fraud, you must have 1) some system to detect and remove fakes, and that system must work consistently and 2) some way of punishing people who create fakes.

Why would you need a distributed ledger anyways if you already trust the middleman?

One reason is that there are different kinds of trust in play. For example, I trust Comodo to verify SSL certificates before signing them, but I don't trust them to hold any of my personal data. I trust my bank to route payments to the correct recipient, but I don't trust them to not charge me an inactivity fee.

One idea that I came up with is to have every node in the network expose a "sign" endpoint. Something like:
Request:
GET https://acme.com/sign?message=randomText&address=Ajd45...

Response:
{
    "address": "Ajd45...",
    "message": "randomText",
    "signature": "..."
}

Using this data, one can verify that the owner of the DNS acme.com has the possession of the private key. The only thing you need to make sure that the server behind acme.com is actually owned by Acme.