 Show Posts
|
|
Pages: [1]
|
|
Thanks for your replies, much appreciated. I'd imagine that recomputing a Merkle root would be quite fast so wouldn't interrupt the main business of grinding too much. Even though, I'd expect most software implementations to run this in a separate thread on the CPU, leaving the ASICs to get on with the grinding uninterrupted. If the algo decides its time to include a new TX it can prepare the root on the CPU, then pass it over to the ASICs seamlessly. Sound about right?
If so then sounds like it's fair to assume that a new TX with reasonable fee can expect to get into the current block in normal circumstances.
|
|
|
|
|
I know this is a well covered topic, so I'll keep my question precise.
I have three Z9 Minis and want to quieten them down as much as possible (I understand the effect will be limited).
I will build a single plywood box lined with a double layer of soundproof plasterboard.
I will make cut large rectangle vents in the ends of the box and form angled ducting using the same construction method (ply box section with double gypsum lining). The angle is an attempt to deaden the noise from the vent holes.
Q) How much improvement can I expect to achieve with an additional internal layer of mass loaded vinyl in the box and rigid ducting?
Thanks for any qualitative (or even quantitative) responses.
|
|
|
|
|
At what point in the mining cycle do new mempool transactions typically get added to the Merkle tree of a candidate block and what variables govern this?
Is a mempool snapshot taken once and then mined until a winner arrives or is found?
Or do miners continually add new transactions to the existing block opportunistically? If so is there any impact on the hashing speed due to the re-computation of the header? Maybe there isn't since the CPU can do that, while the ASIC does the mining? I suppose that would be an opportunity to reset the nonce too.
I'm sure algo's vary from miner to miner, I'm most interested in BitcoinCore's implementation and other popular systems including es cgminer and bfgminer.
Thanks for any insights, I am not a miner, but interested in the effect on the mempool and chances of a new TX getting into the next block.
|
|
|
|
|
At what point in the mining cycle do new mempool transactions typically get added to the Merkle tree of a candidate block and what variables govern this?
Is a mempool snapshot taken once and then mined until a winner arrives or is found?
Or does cgminer continually add new transactions to the existing block opportunistically? If so is there any impact on the hashing speed due to the re-computation of the header? Maybe there isn't since the CPU can do that, while the ASIC does the mining? I suppose that would be an opportunity to reset the Nonce too.
Thanks for any insights, I am not a miner, but interested in the effect on the mempool and chances of a new TX getting into the next block.
|
|
|
|
|
A couple of days (and restarts) later, it started working fine, fixed itself.
No idea what was going on there.
|
|
|
|
Hi All, I'm having trouble with Bitcoin Core crashing when I try to open its Preferences window from the menu bar. Bitcoin Client Software and Version Number: Bitcoin Core version v0.13.2 (64-bit) Operating System: Mac OS X 10.12.3 System Hardware Specs: Apple MacPro 5,1 Quad Xeon 32GB SSD Description of Problem: I have wiped the ~/Library/Application Support/Bitcoin folder and also the ~/Library/Preferences/org/bitcoin.Bitcoin-qt.plist file. I start up Bitcoin Core, tell it to use the default data directory and it loads fine an begins the syncing process. As soon as I select 'Preferences' from the Bitcoin Core menu the application crashes with the message "Bitcoin Core quit unexpectedly." Any Related Addresses: n/a Any Related Transaction IDs: n/a Screenshot of the problem: n/a Log Files from the Bitcoin Client: Here is the full debug.log file: 2017-02-01 18:59:48
2017-02-01 18:59:48 Bitcoin version v0.13.2
2017-02-01 18:59:48 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2017-02-01 18:59:48 Default data directory /Users/oscarp/Library/Application Support/Bitcoin
2017-02-01 18:59:48 Using data directory /Users/oscarp/Library/Application Support/Bitcoin
2017-02-01 18:59:48 Using config file /Users/oscarp/Library/Application Support/Bitcoin/bitcoin.conf
2017-02-01 18:59:48 Using at most 125 connections (2560 file descriptors available)
2017-02-01 18:59:48 Using 4 threads for script verification
2017-02-01 18:59:48 Using BerkeleyDB version Berkeley DB 4.8.30: (April 9, 2010)
2017-02-01 18:59:48 scheduler thread start
2017-02-01 18:59:48 Using wallet wallet.dat
2017-02-01 18:59:48 init message: Verifying wallet...
2017-02-01 18:59:48 CDBEnv::Open: LogDir=/Users/oscarp/Library/Application Support/Bitcoin/database ErrorFile=/Users/oscarp/Library/Application Support/Bitcoin/db.log
2017-02-01 18:59:48 Cache configuration:
2017-02-01 18:59:48 * Using 0.5MiB for block index database
2017-02-01 18:59:48 * Using 1.8MiB for chain state database
2017-02-01 18:59:48 * Using 1.8MiB for in-memory UTXO set
2017-02-01 18:59:48 init message: Loading block index...
2017-02-01 18:59:48 Opening LevelDB in /Users/oscarp/Library/Application Support/Bitcoin/blocks/index
2017-02-01 18:59:48 Opened LevelDB successfully
2017-02-01 18:59:48 Using obfuscation key for /Users/oscarp/Library/Application Support/Bitcoin/blocks/index: 0000000000000000
2017-02-01 18:59:48 Opening LevelDB in /Users/oscarp/Library/Application Support/Bitcoin/chainstate
2017-02-01 18:59:49 Opened LevelDB successfully
2017-02-01 18:59:49 Wrote new obfuscate key for /Users/oscarp/Library/Application Support/Bitcoin/chainstate: ff1e4604182219ca
2017-02-01 18:59:49 Using obfuscation key for /Users/oscarp/Library/Application Support/Bitcoin/chainstate: ff1e4604182219ca
2017-02-01 18:59:49 LoadBlockIndexDB: last block file = 0
2017-02-01 18:59:49 LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=0, size=0, heights=0...0, time=1970-01-01...1970-01-01)
2017-02-01 18:59:49 Checking all blk files are present...
2017-02-01 18:59:49 LoadBlockIndexDB: transaction index disabled
2017-02-01 18:59:49 Initializing databases...
2017-02-01 18:59:49 Pre-allocating up to position 0x1000000 in blk00000.dat
2017-02-01 18:59:49 init message: Verifying blocks...
2017-02-01 18:59:49 block index 112ms
2017-02-01 18:59:49 init message: Loading wallet...
2017-02-01 18:59:49 nFileVersion = 130200
2017-02-01 18:59:49 Keys: 0 plaintext, 0 encrypted, 0 w/ metadata, 0 total
2017-02-01 18:59:49 Performing wallet upgrade to 60000
2017-02-01 18:59:49 keypool added key 1, size=1
2017-02-01 18:59:49 keypool added key 2, size=2
2017-02-01 18:59:49 keypool added key 3, size=3
2017-02-01 18:59:49 keypool added key 4, size=4
2017-02-01 18:59:49 keypool added key 5, size=5
2017-02-01 18:59:49 keypool added key 6, size=6
2017-02-01 18:59:49 keypool added key 7, size=7
2017-02-01 18:59:49 keypool added key 8, size=8
2017-02-01 18:59:49 keypool added key 9, size=9
2017-02-01 18:59:49 keypool added key 10, size=10
2017-02-01 18:59:49 keypool added key 11, size=11
2017-02-01 18:59:49 keypool added key 12, size=12
2017-02-01 18:59:49 keypool added key 13, size=13
2017-02-01 18:59:49 keypool added key 14, size=14
2017-02-01 18:59:49 keypool added key 15, size=15
2017-02-01 18:59:49 keypool added key 16, size=16
2017-02-01 18:59:49 keypool added key 17, size=17
2017-02-01 18:59:49 keypool added key 18, size=18
2017-02-01 18:59:49 keypool added key 19, size=19
2017-02-01 18:59:49 keypool added key 20, size=20
2017-02-01 18:59:49 keypool added key 21, size=21
2017-02-01 18:59:49 keypool added key 22, size=22
2017-02-01 18:59:49 keypool added key 23, size=23
2017-02-01 18:59:49 keypool added key 24, size=24
2017-02-01 18:59:49 keypool added key 25, size=25
2017-02-01 18:59:49 keypool added key 26, size=26
2017-02-01 18:59:49 keypool added key 27, size=27
2017-02-01 18:59:49 keypool added key 28, size=28
2017-02-01 18:59:49 keypool added key 29, size=29
2017-02-01 18:59:49 keypool added key 30, size=30
2017-02-01 18:59:49 keypool added key 31, size=31
2017-02-01 18:59:49 keypool added key 32, size=32
2017-02-01 18:59:49 keypool added key 33, size=33
2017-02-01 18:59:49 keypool added key 34, size=34
2017-02-01 18:59:49 keypool added key 35, size=35
2017-02-01 18:59:49 keypool added key 36, size=36
2017-02-01 18:59:50 keypool added key 37, size=37
2017-02-01 18:59:50 keypool added key 38, size=38
2017-02-01 18:59:50 keypool added key 39, size=39
2017-02-01 18:59:50 keypool added key 40, size=40
2017-02-01 18:59:50 keypool added key 41, size=41
2017-02-01 18:59:50 keypool added key 42, size=42
2017-02-01 18:59:50 keypool added key 43, size=43
2017-02-01 18:59:50 keypool added key 44, size=44
2017-02-01 18:59:50 keypool added key 45, size=45
2017-02-01 18:59:50 keypool added key 46, size=46
2017-02-01 18:59:50 keypool added key 47, size=47
2017-02-01 18:59:50 keypool added key 48, size=48
2017-02-01 18:59:50 keypool added key 49, size=49
2017-02-01 18:59:50 keypool added key 50, size=50
2017-02-01 18:59:50 keypool added key 51, size=51
2017-02-01 18:59:50 keypool added key 52, size=52
2017-02-01 18:59:50 keypool added key 53, size=53
2017-02-01 18:59:50 keypool added key 54, size=54
2017-02-01 18:59:50 keypool added key 55, size=55
2017-02-01 18:59:50 keypool added key 56, size=56
2017-02-01 18:59:50 keypool added key 57, size=57
2017-02-01 18:59:50 keypool added key 58, size=58
2017-02-01 18:59:50 keypool added key 59, size=59
2017-02-01 18:59:50 keypool added key 60, size=60
2017-02-01 18:59:50 keypool added key 61, size=61
2017-02-01 18:59:50 keypool added key 62, size=62
2017-02-01 18:59:50 keypool added key 63, size=63
2017-02-01 18:59:50 keypool added key 64, size=64
2017-02-01 18:59:50 keypool added key 65, size=65
2017-02-01 18:59:50 keypool added key 66, size=66
2017-02-01 18:59:50 keypool added key 67, size=67
2017-02-01 18:59:50 keypool added key 68, size=68
2017-02-01 18:59:50 keypool added key 69, size=69
2017-02-01 18:59:50 keypool added key 70, size=70
2017-02-01 18:59:50 keypool added key 71, size=71
2017-02-01 18:59:50 keypool added key 72, size=72
2017-02-01 18:59:50 keypool added key 73, size=73
2017-02-01 18:59:50 keypool added key 74, size=74
2017-02-01 18:59:50 keypool added key 75, size=75
2017-02-01 18:59:50 keypool added key 76, size=76
2017-02-01 18:59:50 keypool added key 77, size=77
2017-02-01 18:59:50 keypool added key 78, size=78
2017-02-01 18:59:50 keypool added key 79, size=79
2017-02-01 18:59:50 keypool added key 80, size=80
2017-02-01 18:59:51 keypool added key 81, size=81
2017-02-01 18:59:51 keypool added key 82, size=82
2017-02-01 18:59:51 keypool added key 83, size=83
2017-02-01 18:59:51 keypool added key 84, size=84
2017-02-01 18:59:51 keypool added key 85, size=85
2017-02-01 18:59:51 keypool added key 86, size=86
2017-02-01 18:59:51 keypool added key 87, size=87
2017-02-01 18:59:51 keypool added key 88, size=88
2017-02-01 18:59:51 keypool added key 89, size=89
2017-02-01 18:59:51 keypool added key 90, size=90
2017-02-01 18:59:51 keypool added key 91, size=91
2017-02-01 18:59:51 keypool added key 92, size=92
2017-02-01 18:59:51 keypool added key 93, size=93
2017-02-01 18:59:51 keypool added key 94, size=94
2017-02-01 18:59:51 keypool added key 95, size=95
2017-02-01 18:59:51 keypool added key 96, size=96
2017-02-01 18:59:51 keypool added key 97, size=97
2017-02-01 18:59:51 keypool added key 98, size=98
2017-02-01 18:59:51 keypool added key 99, size=99
2017-02-01 18:59:51 keypool added key 100, size=100
2017-02-01 18:59:51 keypool added key 101, size=101
2017-02-01 18:59:51 keypool reserve 1
2017-02-01 18:59:51 keypool keep 1
2017-02-01 18:59:51 wallet 2432ms
2017-02-01 18:59:51 UpdateTip: new best=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 version=0x00000001 log2_work=32.000022 tx=1 date='2009-01-03 18:15:05' progress=0.000000 cache=0.0MiB(0tx)
2017-02-01 18:59:51 mapBlockIndex.size() = 1
2017-02-01 18:59:51 nBestHeight = 0
2017-02-01 18:59:51 setKeyPool.size() = 100
2017-02-01 18:59:51 mapWallet.size() = 0
2017-02-01 18:59:51 mapAddressBook.size() = 1
2017-02-01 18:59:51 init message: Loading addresses...
2017-02-01 18:59:51 torcontrol thread start
2017-02-01 18:59:51 ERROR: Read: Failed to open file /Users/oscarp/Library/Application Support/Bitcoin/peers.dat
2017-02-01 18:59:51 Invalid or missing peers.dat; recreating
2017-02-01 18:59:51 init message: Loading banlist...
2017-02-01 18:59:51 ERROR: Read: Failed to open file /Users/oscarp/Library/Application Support/Bitcoin/banlist.dat
2017-02-01 18:59:51 Invalid or missing banlist.dat; recreating
2017-02-01 18:59:51 init message: Starting network threads...
2017-02-01 18:59:51 dnsseed thread start
2017-02-01 18:59:51 net thread start
2017-02-01 18:59:51 addcon thread start
2017-02-01 18:59:51 Loading addresses from DNS seeds (could take a while)
2017-02-01 18:59:51 opencon thread start
2017-02-01 18:59:51 msghand thread start
2017-02-01 18:59:51 init message: Done loading
2017-02-01 18:59:51 GUI: Platform customization: "macosx"
2017-02-01 18:59:51 GUI: PaymentServer::LoadRootCAs: Loaded 168 root certificates
2017-02-01 18:59:51 GUI: QObject::connect: No such slot RPCConsole::test() in qt/rpcconsole.cpp:668
2017-02-01 18:59:51 GUI: QObject::connect: (receiver name: 'RPCConsole')
2017-02-01 18:59:52 127 addresses found from DNS seeds
2017-02-01 18:59:52 dnsseed thread exit
2017-02-01 18:59:53 GUI: ASSERT failure in QList<T>::at: "index out of range", file /home/ubuntu/build/bitcoin/depends/x86_64-apple-darwin11/share/../include/QtCore/qlist.h, line 531 And here is the OS X crash reporter output: Process: Bitcoin-Qt [6564]
Path: /Applications/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt
Identifier: org.bitcoinfoundation.Bitcoin-Qt
Version: 0.13.2 (0.13.2)
Code Type: X86-64 (Native)
Parent Process: ??? [1]
Responsible: Bitcoin-Qt [6564]
User ID: 501
Date/Time: 2017-02-01 18:59:53.657 +0000
OS Version: Mac OS X 10.12.3 (16D32)
Report Version: 12
Anonymous UUID: 2FF12520-5F58-DC11-326D-1E70F4224BF9
Time Awake Since Boot: 29000 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Application Specific Information:
abort() called
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fffbc756dd6 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fffbc842787 pthread_kill + 90
2 libsystem_c.dylib 0x00007fffbc6bc420 abort + 129
3 org.bitcoinfoundation.Bitcoin-Qt 0x000000010578df89 0x104bcb000 + 12332937
4 org.bitcoinfoundation.Bitcoin-Qt 0x000000010578e587 0x104bcb000 + 12334471
5 org.bitcoinfoundation.Bitcoin-Qt 0x000000010578b152 0x104bcb000 + 12321106
6 org.bitcoinfoundation.Bitcoin-Qt 0x0000000104c33c11 0x104bcb000 + 429073
7 org.bitcoinfoundation.Bitcoin-Qt 0x00000001053b0d6b 0x104bcb000 + 8281451
8 org.bitcoinfoundation.Bitcoin-Qt 0x00000001053c425d 0x104bcb000 + 8360541
9 org.bitcoinfoundation.Bitcoin-Qt 0x00000001053c42ec 0x104bcb000 + 8360684
10 org.bitcoinfoundation.Bitcoin-Qt 0x00000001053c4cf0 0x104bcb000 + 8363248 Any help offered would be much appreciated! |
|
|
|
I'm sure this question has been done to death but I haven't found an answer yet. Why do people talk so often about 2040 and 2140 as the estimated end date of the block subsidy? I had read 2140 in the early days and so took that number for granted. Andreas Antonopoulos uses 2140 in his book. Bank of England talk about 2040 in their papers as do many other people. I always assumed 2040 was typo. To settle it, I've made my own calcs. Assuming exactly 4 years between each 210,000 milestone then the year 2105 is when the last subsidy will be mined according to me. What am I missing? The formula used:  And the table it produces:  |
|
|
|
|
Is there any info on the london meetups I've been hearing about. Does anyone here go?
Please point me at any official threads there may be.
When can I post to the other non-newbie threads?
|
|
|
|
|
