text:
Detect when it is safe to 'stop' the Bitcoin Core Daemon, bitcoind
Previously, I kept the Bitcoin Core daemon running 24x7, however recently I've become less interested in keeping it running all the time, and would like instead to run it for as much time as it takes to ensure the blockchain is no more than a few hours behind.
I'm using a Powershell script to connect to the Bitcoin Core daemon running on Windows.  The script gathers the output from bitcoin-cli.exe getblockchaininfo into a json object to check blockchain verification progress.
I've scheduled a task to start the bitcoind process, and my Powershell script checks the output from bitcoin-cli every 30 seconds, waiting until verificationprogress is at least 0.999999 before shutting down the daemon.
Once verificationprogress is at 0.999999 or higher, the script shuts down the daemon, until the next time it runs about 4 hours later.  I've noticed that the next time bitcoind starts, it is re-downloading blocks it downloaded the last time it ran.   My script checks the number of blocks downloaded vs the number of block headers available, as well as looking at the initialblockdownload boolean indicator before exiting.
Is there something else I should check other than the verificationprogress output from bitcoin-cli.exe getblockchaininfo ?
This is the Powershell script, in case anyone is interested:
Param
(
    [System.Boolean]$debug_mode = $false,
    [System.Boolean]$display_blockchain_info = $false
);
Set-Location "E:\BitcoinCore\Bin";
### if Bitcoin Daemon isn't running, start it.
$Processes = (Get-Process -Name bitcoind -ErrorAction SilentlyContinue);
If ($Processes.Length -eq 0)
{
    $ServiceState = (Get-Service -Name BitcoinCoreDaemon -ErrorAction SilentlyContinue).Status;
    If ($ServiceState -ne "Running")
    {
        Write-Output "$((Get-Date).ToString('s')) - Starting the Bitcoin Core Daemon Service.";
        Start-Service -Name BitcoinCoreDaemon -ErrorAction SilentlyContinue;
    }
    Else
    {
        ### the service status is running, but something has killed the bitcoin daemon process, so we'll restart it.
        Write-Output "$((Get-Date).ToString('s')) - Starting the Bitcoin Core Daemon Process.";
        (Start-Process -FilePath ".\bitcoind.exe" -ArgumentList "--conf=E:\BitcoinCore\bitcoin.conf" -ErrorAction SilentlyContinue);
    };
}
Else
{
    If ($debug_mode -eq $true)
    {
        $Processes;
    };
    Start-Sleep -Seconds 3;
};
[System.Boolean]$is_complete = $false;
[System.Double]$progress = 0;
[System.Int32]$blocks_downloaded_at_start = 0;
[System.Int32]$blocks_downloaded = 0;
[System.Int32]$blocks_available = 0;
[System.DateTime]$start_time = (Get-Date);
While ($is_complete -eq $false)
{
    If ($Processes.Length -eq 0)
    {
        Write-Output "$((Get-Date).ToString('s')) - Sleeping for 30 seconds.";
        Start-Sleep -Seconds 30;
    }
    Else
    {
        $Processes = @();
    };
    [System.String]$block_chain_info = (.\bitcoin-cli.exe --datadir=E:\BitcoinCore\Data getblockchaininfo)
    If ($block_chain_info -ne $null)
    {
        $bci = (ConvertFrom-Json $block_chain_info -ErrorAction SilentlyContinue);
        If ($display_blockchain_info -eq $true)
        {
            Write-Output "$($block_chain_info)";
        };
        $is_complete = -Not ($bci.initialblockdownload -eq $true);
        $blocks_available = $bci.headers;
        $blocks_downloaded = $bci.blocks;
        If ($debug_mode -eq $true)
        {
            Write-Output "$($blocks_downloaded) of $($blocks_available) blocks downloaded.";
        };
        IF ($blocks_downloaded_at_start -eq 0)
        {
            $blocks_downloaded_at_start = $blocks_downloaded;
        };
        $progress = $bci.verificationprogress;
        If (($blocks_downloaded -lt $blocks_available) -or ($progress -lt 0.999999))
        {
            If ($debug_mode -eq $true)
            {
                Write-Output "Setting `$is_complete to `$false.  `$progress is $($progress).  `$start_time + 180 seconds is $(($start_time.AddSeconds(180)).ToString('s')).  `$progress is $($progress).";
            };
            $is_complete = $false;
        };
        If ($start_time.AddSeconds(180) -gt (Get-Date))
        {
            Write-Output "Waiting until at least $($start_time.AddSeconds(180).ToString('s')) before exiting.";
            $is_complete = $false;
        };
        If ($is_complete -eq $false)
        {
            Write-Output "Sync is $($progress) complete.  $($blocks_downloaded - $blocks_downloaded_at_start) blocks downloaded...";
        }
        Else
        {
            Write-Output "Sync complete (progess is $($progress)).  $($blocks_downloaded - $blocks_downloaded_at_start) blocks downloaded.";
        };
    };
};
### stop Bitcoin Core Daemon and then the Service
(.\bitcoin-cli.exe --datadir=E:\BitcoinCore\Data stop);
[System.DateTime]$start_of_shutdown = (Get-Date);
While (((Get-Process -Name bitcoind -ErrorAction SilentlyContinue).Length -gt 0) -and ($start_of_shutdown.AddSeconds(30) -lt (Get-Date)))
{
    Start-Sleep -Seconds 1;
};
Stop-Service -Name "BitcoinCoreDaemon" -ErrorAction SilentlyContinue;
Write-Output "$((Get-Date).ToString('s')) - Bitcoin Core Daemon and Service have been stopped.";

Here's the debug.log from the end of the prior session, and the start of the most recent session.  The previous session ended with an UpdateTip value of 810877, however the most recent session starts with UpdateTip 810207, 670 blocks earlier, and indeed the new log shows [Chainstate [ibd] @ height 810206.
2023-10-06T09:27:23Z UpdateTip: new best=000000000000000000026e31e1a0f6d0d65ac1ab7a765740eb0065176e38a209 height=810865 version=0x246fc000 log2_work=94.459262 tx=903462025 date='2023-10-06T08:01:13Z' progress=0.999979 cache=546.0MiB(3943178txo)
2023-10-06T09:27:25Z UpdateTip: new best=000000000000000000007e2d6aea7100d57133b5290eaba79891182a13f1a8f3 height=810866 version=0x2a4b4000 log2_work=94.459275 tx=903462385 date='2023-10-06T08:04:34Z' progress=0.999980 cache=546.5MiB(3947209txo)
2023-10-06T09:27:27Z UpdateTip: new best=00000000000000000004c7066de91e2532c5dbafd46a3f205da2d29e92511d30 height=810867 version=0x2000c000 log2_work=94.459288 tx=903463057 date='2023-10-06T08:17:29Z' progress=0.999983 cache=547.1MiB(3951752txo)
2023-10-06T09:27:28Z UpdateTip: new best=000000000000000000008b4aac5311e3ec65d3ed67a9f40b917a83a01aaca5f0 height=810868 version=0x2000e000 log2_work=94.459301 tx=903463474 date='2023-10-06T08:19:10Z' progress=0.999983 cache=547.7MiB(3956404txo)
2023-10-06T09:27:29Z UpdateTip: new best=0000000000000000000041af22296ba31c5a14bc35ea28e0f6de3d233b5596d9 height=810869 version=0x2109e004 log2_work=94.459314 tx=903464380 date='2023-10-06T08:37:32Z' progress=0.999988 cache=548.3MiB(3961301txo)
2023-10-06T09:27:31Z UpdateTip: new best=000000000000000000015d82f76da40ed61f772397e5bcc6a7486cf20312ef5f height=810870 version=0x31932000 log2_work=94.459327 tx=903464871 date='2023-10-06T08:43:04Z' progress=0.999989 cache=548.8MiB(3965122txo)
2023-10-06T09:27:32Z UpdateTip: new best=000000000000000000036fd5de966a90374af6793ef05a8cc38bc8b6573a03f8 height=810871 version=0x2fffe000 log2_work=94.459340 tx=903465378 date='2023-10-06T08:44:46Z' progress=0.999990 cache=549.2MiB(3969117txo)
2023-10-06T09:27:34Z UpdateTip: new best=00000000000000000004be6ac3f43df15ddcf1a7c62951e6e79eb5de57144edb height=810872 version=0x26000000 log2_work=94.459353 tx=903466243 date='2023-10-06T08:50:25Z' progress=0.999991 cache=549.7MiB(3972802txo)
2023-10-06T09:27:35Z UpdateTip: new best=000000000000000000044fa9f1776352615ac154b495874ce4e9a19e1afc5730 height=810873 version=0x20e00000 log2_work=94.459366 tx=903466739 date='2023-10-06T08:53:04Z' progress=0.999992 cache=550.2MiB(3976825txo)
2023-10-06T09:27:36Z UpdateTip: new best=000000000000000000035b75f248b8f6b910940c2c38a60bfe1814115f7737e0 height=810874 version=0x29960000 log2_work=94.459379 tx=903468832 date='2023-10-06T09:10:10Z' progress=0.999996 cache=550.8MiB(3981874txo)
2023-10-06T09:27:38Z UpdateTip: new best=000000000000000000009768742a1f0e94c67df18493ecab7aabe66499ae6936 height=810875 version=0x23572000 log2_work=94.459392 tx=903469658 date='2023-10-06T09:11:27Z' progress=0.999996 cache=551.3MiB(3985514txo)
2023-10-06T09:27:39Z UpdateTip: new best=000000000000000000002caf4e7450f713398fd4cf9a9cbf5a718ecf855f4c0c height=810876 version=0x2df92000 log2_work=94.459405 tx=903471258 date='2023-10-06T09:17:19Z' progress=0.999997 cache=551.9MiB(3990562txo)
2023-10-06T09:27:39Z Saw new header hash=000000000000000000024ff8dcb9fc8e05bd11652d93fa15ad8570a82c471e7c height=810877
2023-10-06T09:27:39Z New outbound peer connected: version: 70015, blocks=810876, peer=133 (block-relay-only)
2023-10-06T09:27:42Z UpdateTip: new best=000000000000000000024ff8dcb9fc8e05bd11652d93fa15ad8570a82c471e7c height=810877 version=0x22bc4000 log2_work=94.459418 tx=903473610 date='2023-10-06T09:28:09Z' progress=1.000000 cache=552.5MiB(3995018txo)
2023-10-06T09:28:09Z tor: Thread interrupt
2023-10-06T09:28:09Z addcon thread exit
2023-10-06T09:28:09Z opencon thread exit
2023-10-06T09:28:09Z Shutdown: In progress...
2023-10-06T09:28:09Z torcontrol thread exit
2023-10-06T09:28:09Z net thread exit

2023-10-06T13:00:03Z Bitcoin Core version v25.0.0 (release build)
2023-10-06T13:00:03Z InitParameterInteraction: parameter interaction: -externalip set -> setting -discover=0
2023-10-06T13:00:03Z Using the 'sse4(1way),sse41(4way)' SHA256 implementation
2023-10-06T13:00:03Z Default data directory C:\WINDOWS\system32\config\systemprofile\AppData\Roaming\Bitcoin
2023-10-06T13:00:03Z Using data directory E:\BitcoinCore\Data
2023-10-06T13:00:03Z Config file: E:\BitcoinCore\bitcoin.conf
2023-10-06T13:00:03Z Config file arg: chain="main"
2023-10-06T13:00:03Z Config file arg: datadir="E:\\BitcoinCore\\Data"
2023-10-06T13:00:03Z Config file arg: externalip="x.x.x.x"
2023-10-06T13:00:03Z Config file arg: listen="1"
2023-10-06T13:00:03Z Config file arg: port="8333"
2023-10-06T13:00:03Z Config file arg: rpcallowip="192.168.0.0/24"
2023-10-06T13:00:03Z Config file arg: rpcbind="0.0.0.0"
2023-10-06T13:00:03Z Config file arg: rpcport="8332"
2023-10-06T13:00:03Z Config file arg: walletdir="E:\\BitcoinCore\\Wallets"
2023-10-06T13:00:03Z Setting file arg: dbcache = "900"
2023-10-06T13:00:03Z Setting file arg: par = "2"
2023-10-06T13:00:03Z Command-line arg: conf="E:\\BitcoinCore\\bitcoin.conf"
2023-10-06T13:00:03Z Command-line arg: datadir="E:\\BitcoinCore\\Data"
2023-10-06T13:00:03Z Using at most 125 automatic connections (2048 file descriptors available)
2023-10-06T13:00:03Z Using 16 MiB out of 16 MiB requested for signature cache, able to store 524288 elements
2023-10-06T13:00:03Z Using 16 MiB out of 16 MiB requested for script execution cache, able to store 524288 elements
2023-10-06T13:00:03Z Script verification uses 1 additional threads
2023-10-06T13:00:03Z scheduler thread start
2023-10-06T13:00:03Z Binding RPC on address 0.0.0.0 port 8332
2023-10-06T13:00:03Z WARNING: the RPC server is not safe to expose to untrusted networks such as the public internet
2023-10-06T13:00:03Z [http] creating work queue of depth 16
2023-10-06T13:00:03Z Using random cookie authentication.
2023-10-06T13:00:03Z Generated RPC authentication cookie E:\BitcoinCore\Data\.cookie
2023-10-06T13:00:03Z [http] starting 4 worker threads
2023-10-06T13:00:03Z Using wallet directory E:\BitcoinCore\Wallets
2023-10-06T13:00:03Z init message: Verifying wallet(s)…
2023-10-06T13:00:03Z Using /16 prefix for IP bucketing
2023-10-06T13:00:03Z init message: Loading P2P addresses…
2023-10-06T13:00:03Z Loaded 64337 addresses from peers.dat  406ms
2023-10-06T13:00:03Z init message: Loading banlist…
2023-10-06T13:00:03Z SetNetworkActive: true
2023-10-06T13:00:03Z AddLocal(x.x.x.x:8333,4)
2023-10-06T13:00:03Z Cache configuration:
2023-10-06T13:00:03Z * Using 2.0 MiB for block index database
2023-10-06T13:00:03Z * Using 8.0 MiB for chain state database
2023-10-06T13:00:03Z * Using 890.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2023-10-06T13:00:03Z init message: Loading block index…
2023-10-06T13:00:03Z Assuming ancestors of block 000000000000000000035c3f0d31e71a5ee24c5aaf3354689f65bd7b07dee632 have valid signatures.
2023-10-06T13:00:03Z Setting nMinimumChainWork=000000000000000000000000000000000000000044a50fe819c39ad624021859
2023-10-06T13:00:03Z Opening LevelDB in E:\BitcoinCore\Data\blocks\index
2023-10-06T13:00:03Z Opened LevelDB successfully
2023-10-06T13:00:03Z Using obfuscation key for E:\BitcoinCore\Data\blocks\index: 0000000000000000
2023-10-06T13:00:08Z LoadBlockIndexDB: last block file = 3864
2023-10-06T13:00:08Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=6, size=9751382, heights=810807...810812, time=2023-10-05...2023-10-06)
2023-10-06T13:00:08Z Checking all blk files are present...
2023-10-06T13:00:11Z Initializing chainstate Chainstate [ibd] @ height -1 (null)
2023-10-06T13:00:11Z Opening LevelDB in E:\BitcoinCore\Data\chainstate
2023-10-06T13:00:11Z Opened LevelDB successfully
2023-10-06T13:00:11Z Using obfuscation key for E:\BitcoinCore\Data\chainstate: 4358e8c41e43c894
2023-10-06T13:00:11Z Loaded best chain: hashBestChain=0000000000000000000328e424cd9ff6317a8f256f7bc2b5d3aa487e295eb27d height=810206 date=2023-10-01T22:03:16Z progress=0.998377
2023-10-06T13:00:11Z [snapshot] allocating all cache to the IBD chainstate
2023-10-06T13:00:11Z Opening LevelDB in E:\BitcoinCore\Data\chainstate
2023-10-06T13:00:11Z Opened LevelDB successfully
2023-10-06T13:00:11Z Using obfuscation key for E:\BitcoinCore\Data\chainstate: 4358e8c41e43c894
2023-10-06T13:00:11Z [Chainstate [ibd] @ height 810206 (0000000000000000000328e424cd9ff6317a8f256f7bc2b5d3aa487e295eb27d)] resized coinsdb cache to 8.0 MiB
2023-10-06T13:00:11Z [Chainstate [ibd] @ height 810206 (0000000000000000000328e424cd9ff6317a8f256f7bc2b5d3aa487e295eb27d)] resized coinstip cache to 890.0 MiB
2023-10-06T13:00:11Z init message: Verifying blocks…
2023-10-06T13:00:11Z Verifying last 6 blocks at level 3
2023-10-06T13:00:11Z Verification progress: 0%
2023-10-06T13:00:14Z Verification progress: 16%
2023-10-06T13:00:17Z Verification progress: 33%
2023-10-06T13:00:19Z Verification progress: 50%
2023-10-06T13:00:22Z Verification progress: 66%
2023-10-06T13:00:25Z Verification progress: 83%
2023-10-06T13:00:27Z Verification progress: 99%
2023-10-06T13:00:27Z Verification: No coin database inconsistencies in last 6 blocks (14504 transactions)
2023-10-06T13:00:27Z  block index           24335ms
2023-10-06T13:00:27Z Setting NODE_NETWORK on non-prune mode
2023-10-06T13:00:27Z block tree size = 810814
2023-10-06T13:00:27Z nBestHeight = 810206
2023-10-06T13:00:27Z loadblk thread start
2023-10-06T13:00:27Z Bound to 127.0.0.1:8334
2023-10-06T13:00:27Z torcontrol thread start
2023-10-06T13:00:27Z Bound to [::]:8333
2023-10-06T13:00:27Z Bound to 0.0.0.0:8333
2023-10-06T13:00:27Z 0 block-relay-only anchors will be tried for connections.
2023-10-06T13:00:27Z init message: Starting network threads…
2023-10-06T13:00:27Z net thread start
2023-10-06T13:00:27Z opencon thread start
2023-10-06T13:00:27Z dnsseed thread start
2023-10-06T13:00:27Z Waiting 300 seconds before querying DNS seeds.
2023-10-06T13:00:27Z addcon thread start
2023-10-06T13:00:27Z msghand thread start
2023-10-06T13:00:31Z UpdateTip: new best=000000000000000000005bf8f39f891a7ef192cd420aca62e6e4e712f9651345 height=810207 version=0x30b0c000 log2_work=94.450664 tx=902083876 date='2023-10-01T22:15:30Z' progress=0.998380 cache=1.9MiB(13862txo)
2023-10-06T13:00:38Z UpdateTip: new best=00000000000000000003d001eba5cebcc7f518100c565e9b81a8d43abe1a4647 height=810208 version=0x21b18000 log2_work=94.450677 tx=902085395 date='2023-10-01T22:16:33Z' progress=0.998380 cache=3.9MiB(27532txo)
2023-10-06T13:00:40Z UpdateTip: new best=000000000000000000023aa4cd17246fd163f70c76886d0a8a0c95de12064463 height=810209 version=0x31c16000 log2_work=94.450690 tx=902089477 date='2023-10-01T22:26:53Z' progress=0.998382 cache=5.5MiB(38614txo)
2023-10-06T13:00:44Z UpdateTip: new best=00000000000000000003bc9f4d0c3ee9506a98af5f998e76a26d0ce738857388 height=810210 version=0x20400000 log2_work=94.450703 tx=902091419 date='2023-10-01T22:34:18Z' progress=0.998384 cache=7.2MiB(49940txo)
2023-10-06T13:00:47Z UpdateTip: new best=000000000000000000015d7268a3392ee8a1d12df7487ab05a16850db6b55d27 height=810211 version=0x20000000 log2_work=94.450716 tx=902095202 date='2023-10-01T22:41:03Z' progress=0.998386 cache=8.5MiB(58801txo)
2023-10-06T13:00:49Z UpdateTip: new best=00000000000000000001e1f6c8ead46189e4be15a9d4ed23c9c3ab8173592fae height=810212 version=0x29274000 log2_work=94.450729 tx=902097477 date='2023-10-01T22:53:50Z' progress=0.998389 cache=9.8MiB(69269txo)
2023-10-06T13:00:49Z init message: Done loading
2023-10-06T13:00:50Z UpdateTip: new best=000000000000000000017157c555d2dbb157fab5fc745a16b08e6738e0c85936 height=810213 version=0x27e4e000 log2_work=94.450742 tx=902101740 date='2023-10-01T22:57:23Z' progress=0.998390 cache=11.0MiB(76813txo)
.
.
.
2023-10-06T13:25:12Z UpdateTip: new best=0000000000000000000079dafaab513cf75b6220c684509d181d5ec0a638679e height=810811 version=0x27306000 log2_work=94.458557 tx=903380823 date='2023-10-05T23:53:32Z' progress=0.999802 cache=513.6MiB(3686409txo)
2023-10-06T13:25:13Z UpdateTip: new best=000000000000000000033b8366f810946dbc4dcbb2554a0df47a065ace7f3276 height=810812 version=0x20400000 log2_work=94.458570 tx=903383323 date='2023-10-06T00:05:52Z' progress=0.999805 cache=514.2MiB(3690886txo)
2023-10-06T13:25:13Z Leaving InitialBlockDownload (latching to false)
2023-10-06T13:25:13Z Imported mempool transactions from disk: 2 succeeded, 32 failed, 0 expired, 0 already there, 0 waiting for initial broadcast
2023-10-06T13:25:13Z loadblk thread exit
2023-10-06T13:25:13Z Saw new header hash=0000000000000000000443ae77e6d49f6cfd76cac1eb641ac54b0c2ed014fa51 height=810813
2023-10-06T13:25:13Z Saw new header hash=0000000000000000000497d6381a7558a9d070a2941de4758bb1b69decf6ef5c height=810814
20
.
.
.
2023-10-06T13:28:24Z UpdateTip: new best=00000000000000000002d17d8f0633fcbfce76ba2a27a590d3330e7b6bb50a1f height=810905 version=0x22efc000 log2_work=94.459783 tx=903526119 date='2023-10-06T12:45:49Z' progress=0.999990 cache=564.7MiB(4092680txo)
2023-10-06T13:28:26Z UpdateTip: new best=00000000000000000004d144d05c5b9678748a76b21c50c55397c7db4e668376 height=810906 version=0x2000e000 log2_work=94.459796 tx=903528135 date='2023-10-06T12:50:15Z' progress=0.999991 cache=565.0MiB(4094669txo)
2023-10-06T13:29:36Z New outbound peer connected: version: 70015, blocks=810906, peer=162 (block-relay-only)
2023-10-06T13:31:54Z New outbound peer connected: version: 70016, blocks=810906, peer=173 (block-relay-only)
2023-10-06T13:35:13Z New outbound peer connected: version: 70016, blocks=810906, peer=184 (block-relay-only)
2023-10-06T13:37:13Z New outbound peer connected: version: 70016, blocks=810906, peer=189 (block-relay-only)
2023-10-06T13:37:21Z Saw new header hash=00000000000000000001fe1d6da07c23f61d49bd20e637f53a227f5b6cf428aa height=810907
2023-10-06T13:37:23Z UpdateTip: new best=00000000000000000001fe1d6da07c23f61d49bd20e637f53a227f5b6cf428aa height=810907 version=0x24e88000 log2_work=94.459809 tx=903531631 date='2023-10-06T13:37:00Z' progress=1.000000 cache=566.6MiB(4107740txo)
2023-10-06T13:37:23Z tor: Thread interrupt
2023-10-06T13:37:23Z opencon thread exit
2023-10-06T13:37:23Z addcon thread exit
2023-10-06T13:37:23Z Shutdown: In progress...
2023-10-06T13:37:23Z torcontrol thread exit
2023-10-06T13:37:23Z net thread exit
2023-10-06T13:37:23Z msghand thread exit

It seems to me you're not giving Bitcoin Core the time to shut down completely. There is (a) no log message in the first part about having flushed the database and (b) on restart, the tip has moved backwards. On normal shutdown, it should continue exactly where it left off.

This is pretty silly, but I wanted to document the issue for future visitors.  The problem was in the shutdown portion of my script where it waits 30 seconds for the bitcoind process to shutdown before stopping the custom service I created for the Bitcoin Daemon.
This code looks to see if 30 seconds has elapsed since the daemon was asked to shutdown, however it should be using -gt rather than -lt for the comparison against Get-Date.:
[System.DateTime]$start_of_shutdown = (Get-Date);
While (((Get-Process -Name bitcoind -ErrorAction SilentlyContinue).Length -gt 0) -and ($start_of_shutdown.AddSeconds(30) -lt (Get-Date)))
{
    Start-Sleep -Seconds 1;
};

It should be like this:
[System.DateTime]$start_of_shutdown = (Get-Date);
While (((Get-Process -Name bitcoind -ErrorAction SilentlyContinue).Length -gt 0) -and ($start_of_shutdown.AddSeconds(30) -gt (Get-Date)))
{
    Start-Sleep -Seconds 1;
};

The last section of the debug.log should be similar to this:
2023-10-06T16:35:57Z tor: Thread interrupt
2023-10-06T16:35:57Z Shutdown: In progress...
2023-10-06T16:35:57Z opencon thread exit
2023-10-06T16:35:57Z torcontrol thread exit
2023-10-06T16:35:57Z addcon thread exit
2023-10-06T16:35:57Z net thread exit
2023-10-06T16:35:57Z msghand thread exit
2023-10-06T16:35:57Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat started
2023-10-06T16:35:57Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat completed (0.00s)
2023-10-06T16:35:57Z scheduler thread exit
2023-10-06T16:35:57Z Writing 0 unbroadcast transactions to disk.
2023-10-06T16:35:57Z Dumped mempool: 0s to copy, 0s to dump
2023-10-06T16:35:58Z Shutdown: done

i.e. it should say that data was flushed to disk and that shutdown is "done" per that last line.

When bitcoind re-verifies blocks, it is not redownloading them. It is just loading them from disk and making sure that the databases are consistent. Bitcoind will always re-verify a small number of blocks on startup to make sure that its databases have not been corrupted.
You should use the initialblockdownload field instead of verificationprogress. It is just a boolean and it checks more heuristics to determine whether the node is still syncing.

Thanks for taking the time to answer.  My script checks the number of blocks downloaded vs the number of block headers available, as well as looking at the initialblockdownload indicator already, but the next startup results in many blocks being downloaded regardless.  I'll add details from the debug.log to my question.

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


text:
Can mediantime be used as a proxy for expected time of the most recently mined block?
I'm using Bitcoin Core CLI to get block info:
.\bitcoin-cli.exe getblockchaininfo

Among other things, this returns two items:
  "time": 1713464903,
  "mediantime": 1713461780,

I understand the mediantime is the median of the time value for the past 11 blocks, and is used as a check to ensure the miner used a valid timestamp value for the time of the block they just mined.
If I add 50 minutes to that mediantime value, is that a reasonably good proxy for when the most recently mined block would have been mined?  Intra block time is designed to be 10 minutes, but varies because of difficulty and the unpredictable nature of hashing, so of course it won't be exact.
I'm using the following in Powershell to display the most recently mined block number, along with the time it was mined, and when it was expected to be mined, just for my own edification:
[System.String]$block_chain_info = (.\bitcoin-cli.exe --datadir=E:\BitcoinCore\Data getblockchaininfo);
If ($block_chain_info -ne $null)
{
    [System.Object]$bci = (ConvertFrom-Json $block_chain_info -ErrorAction SilentlyContinue);
    $epoch = New-Object DateTimeOffset(1970,1,1,0,0,0,0);
    $block_time = $epoch.AddSeconds($bci.time);
    #mediantime is the median time of the past 11 blocks
    $block_expected_time = $epoch.AddSeconds($bci.mediantime + (50 * 60));
    Write-Output "Current Block Number is:    $($bci.blocks)";
    Write-Output "Block Time is:              $($block_time.LocalDateTime.ToString{s})";
    Write-Output "Block Expected Time is:     $($block_expected_time.LocalDateTime.ToString{s})";
}
Else
{
    "Could not obtain block chain info from the Bitcoin Core CLI";
};

I'm in the Central Standard Time timezone, so for the most recent block, it shows:
Current Block Number is:    839816
Block Time is:              2024-04-18T13:46:27
Block Expected Time is:     2024-04-18T13:33:41

In case it matters, my bitcoin-cli --version is:
Bitcoin Core RPC client version v27.0.0
Copyright (C) 2009-2024 The Bitcoin Core developers

source: Stack Exchange

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

sort: votes


text:
For a redeem script to satisfy the conditions of a script what must it leave on the stack post execution?
I was watching this Andreas Antonopoulos presentation on Advanced Bitcoin Scripting.
It appears from Andreas' examples that for a redeem script to satisfy the conditions of the script it needs to leave TRUE (and nothing else) on the stack after it has been executed. This was also enquired about here.
Therefore there is a VERIFY suffix such that some opcodes (e.g. EQUAL, CHECKSIG, CHECKMULTISIG) have competing opcodes (e.g. EQUALVERIFY, CHECKSIGVERIFY, CHECKMULTISIGVERIFY). Instead of leaving TRUE on the stack these VERIFY opcodes will "continue execution of the Script if the outcome of the conditional operator is TRUE" but "will not push that TRUE back to the stack, it will simply continue execution". These VERIFY opcodes can be used to ensure the execution of the redeem script leave TRUE (and nothing else) on the stack rather than say TRUE TRUE TRUE.
However, in this Bitcoin Core PR review club session Pieter Wuille stated (paraphrasing):

For CLEANSTACK you have to have a stack with a single element in it which has to be nonzero. Without CLEANSTACK a non-empty stack with multiple elements is ok as long as the top element is nonzero

I have two questions:

Presumably TRUE is equivalent to 1 and FALSE is equivalent to 0?

Any opcodes that evaluate to FALSE will result in immediate failure and termination of execution? So with non-CLEANSTACK you would never see a resulting stack of TRUE FALSE TRUE pass as FALSE would result in immediate failure and you wouldn't assess the final TRUE. However, you could see a stack of say TRUE 3 TRUE 5 and this would pass with non-CLEANSTACK. (It would fail with CLEANSTACK as CLEANSTACK must have a single element in the resulting stack).

Thanks to harding for answering this question on IRC and sanket1729 for edits.

Presumably TRUE is equivalent to 1 and FALSE is equivalent to 0?

TRUE is any non-zero value.  This is often used in scripts involving the former OP_NOPx opcodes that don't pop their values off the stack after verification, e.g. a script that can be spend by a miner after a certain height could use: <locktime> OP_CLTV ; if CLTV fails, the transaction is invalid; if it passes, then the non-zero  value left on the stack allows the script to pass.

Any opcodes that evaluate to FALSE will result in immediate failure and termination of execution? So with non-CLEANSTACK you would never see a resulting stack of TRUE FALSE TRUE pass as FALSE would result in immediate failure and you wouldn't assess the final TRUE. However, you could see a stack of say TRUE 3 TRUE 5 and this would pass with non-CLEANSTACK. (It would fail with CLEANSTACK as CLEANSTACK must have a single element in the resulting stack).

All that matters without CLEANSTACK is the top value on the stack at the end of execution.  Anything further down the stack doesn't matter.
CLEANSTACK is a standardness rule for P2SH but it is a consensus rule for Segwit v0 (BIP141 specification) and Tapscript, SegWit v1 (BIP342 specification, rule 4, ii)
The word "failure" is ambiguous here. There are different ways different opcodes can fail. For example, if OP_CHECKSIG fails it just pushes a 0 to the stack. But if OP_CHECKSIGVERIFY fails, the whole script fails. You can put TRUE FALSE FALSE on the stack using just OP_0 OP_0 OP_1.
Some of the VERIFY opcodes e.g. EQUALVERIFY, CHECKSIGVERIFY, CHECKMULTISIGVERIFY terminate immediately on failure but their non-VERIFY equivalents don't.
All that matters is the state of the stack at the end of script evaluation.  For example, you could do OP_CHECKSIG followed by OP_IF OP_PUSHNUM1 OP_ELSE OP_PUSHNUM2 OP_ENDIF, e.g. if the signature succeeds, take one branch; if it fails, take another branch (This isn't considered best practice though and shouldn't generally be done.)
CLEANSTACK is an attempt to prevent malleability by having people put a bunch of junk in your scriptSig or witness data. Because you can just push a bunch of data onto the stack that never gets used and doesn't prevent the script from evaluating correctly. (Pre-segwit, this affected txid malleability and was enforced as a standardness policy rule; with segwit, this is no longer possible as it is a consensus rule)

Miniscript ##miniscript

I think the transaction will fail there is no matching OF_ENDIF for a OP_IF, but I am not 100% sure about it.

just checked this and suggested an edit

@sanket1729 Yes, if there are unbalanced IF and ENDIF then the script will fail. Similarly if you use ELSE outside of any IF statement. (Curiously, you can use multiple ELSE statements in a row, and the interpreter will just execute all the odd/even ones depending on the input to the IF.)


text:
Walking through a transaction script
As an example, I would like to consider this transaction: https://blockchain.info/tx/6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516
I have three questions:
1) The first two entries in the stack are <sig> and <pubKey> for each input. However, the inputs are just giant strings. For the first of the two inputs, it is
3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01

Where are the two separate items, the signature and the public key?
2) I understand that OP_DUP duplicates the top item on the stack i.e. the publick key and then OP_HASH160 computes the hash. Assuming I have the <pubKey>, I'd like to actually run OP_HASH160 and see that I get the result 12ab8dc588ca9d5787dde7eb29569da63c3a238c using a tool like this http://bitcoinvalued.com/tools.php. Where exactly is the <pubKey> that yields this hash?
3) Finally, there is the OP_CHECKSIG which should take ,  and  and return true or false. Where exactly are these items in this transaction?

This transaction is a Pay-to-pubkey transaction, so there is no OP_DUP and no OP_HASH160. When validating an input, you first need to find the scriptPubKey of the output that this input spends from. The first input of your transaction spends from the first output of https://blockchain.info/tx/ff3dc8b461305acc5900d31602f2dafebfc406e5b050b14a352294f0965e0bf6. The scriptPubKey of that output is
04c9560dc538db21476083a5c65a34c7cc219960b1e6f27a87571cd91edfd00dac16dca4b4a7c4ab536f85bc263b3035b762c5576dc6772492b8fb54af23abff6d OP_CHECKSIG

To evaluate the input script, we concatenate the input script with the output script, so our final script is
3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01 04c9560dc538db21476083a5c65a34c7cc219960b1e6f27a87571cd91edfd00dac16dca4b4a7c4ab536f85bc263b3035b762c5576dc6772492b8fb54af23abff6d OP_CHECKSIG

The first array of bytes (3046...5d01) is the signature. That is first pushed to the stack. Then the second array of bytes (04c9...ff6d) is pushed to the stack; that is the public key.
So the stack now looks like
04c9560dc538db21476083a5c65a34c7cc219960b1e6f27a87571cd91edfd00dac16dca4b4a7c4ab536f85bc263b3035b762c5576dc6772492b8fb54af23abff6d
3046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01

Lastly OP_CHECKSIG is performed. It pops the top two items on the stack. The first item popped is treated as the public key (and in this case it is the actual public key) and the second item popped is treated as a signature (and in this case it is the actual signatures). Then the signature is verified, and if it is, OP_TRUE is pushed to the stack.

For a P2PKH transaction, lets use the second input of https://blockchain.info/tx/12e753ef5cc30925a6eee2c457aa7f53022443ca013ea81882a6b59b69e342a6. This points us to the first output of https://blockchain.info/tx/6f7cf9580f1c2dfb3c4d5d043cdbb128c640e3f20161245aa7372e9666168516 which is a P2PKH output.
The output script is
OP_DUP OP_HASH160 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG

and the input script is
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601 044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c

Concatenating the two scripts gets us a final script of
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601 044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c OP_DUP OP_HASH160 12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG

So following the execution, the first two items (the signature and pubkey) are pushed to the stack, so our stack is
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

OP_DUP tells us to duplicate the top item (the pubkey), so our stack is now
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

OP_HASH160 pops the top stack item and pushes the RIPEMD160 of the SHA256 of that item, so our stack now looks like
12ab8dc588ca9d5787dde7eb29569da63c3a238c
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

The 20 byte hash is not pushed to the stack, so we get
that item, so our stack now looks like
12ab8dc588ca9d5787dde7eb29569da63c3a238c
12ab8dc588ca9d5787dde7eb29569da63c3a238c
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

OP_EQUALVERIFY pops the top 2 stack items and checks that they are equal. If they are not equal, the script execution bails out and fails. Otherwise nothing else happens. So now our stack is
044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687cf2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f26181398c
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955c867afac0ef78601

Lastly we do OP_CHECKSIG like we did with the P2PK output. The signature verifies, so we are left with
OP_TRUE

as our stack. And thus the script execution is successful.

Also, it is important to note that script execution is no longer actually concatenating the input and output scripts. Rather the input script is first verified, and then its resulting stack is examined for whether it is valid (i.e. there were no errors validating the input script) then that stack is passed as an initial stack to the output script verifier and the output script is run.

Hi, could you explain why the output script (if you scroll to the bottom of the page I linked in my question) has OP_HASH160 if this is a pay to public key transaction?

The output scripts of this transaction don't matter. What matters are the output scripts of the transactions that the inputs of this transaction spend from..

Great, thank you. Can I check how you found that the parent transaction was "ff3dc8b461305ac..."? I could not find that txid anywhere on the page I linked in my question. Also, if it's not too much trouble, can you add to your answer how this would be different if we were doing a P2PKH instead i.e. now in the output, instead of a pubKey and OP_CHECKSIG, I have OP_DUP OP_HASH160 a hash etc. so what exactly do I concatenate with the signature?

On blockchain.info, you can scroll down to the bottom and click the link to enable Advanced View. Advanced View will show you the input and output scripts, links to the output that an input spends from, and links to the transaction that spends an output.

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


text:
What and where are the current status of the BIP 125 replacement, the V3 Policy proposal, package RBF etc?
Whenever I try to review P2P and mempool (default) policy proposals I end up going round in circles around this maze of docs, mailing list posts and pull requests. Some of them are outdated, some present the latest state of proposal(s), sometimes two proposals are presented together, sometimes presented separately. Some docs I found really useful in the past I can't find anymore. Can you answer these questions and provide a link to the latest state of the proposal?
What is BIP 125? Which BIP 125 rules are still being enforced in default policy in Core today? Which aren't? Which BIP 125 rules have been replaced with alternative rules in Core today?
What (and where) is the proposed replacement for BIP 125?
What is V3 Policy? Is the proposed replacement for BIP 125 part of V3 Policy?
What is package RBF and is this part of V3 Policy or a separate proposal to V3 Policy? Is the intention that package RBF will (eventually) be enabled at the same time as V3 Policy or can they be enabled at different times?
I get the proposals are evolving over time (and so no criticism necessarily directed towards the authors) but this confusion makes it really hard for me to follow what is going on.

I do not think it’s useful to invent new monikers that nobody else uses to distinguish the different specifications and sets of rules we are talking about. How about these descriptions:

Bitcoin Core’s actual RBF behavior
is specified per the code of Bitcoin Core and has changed over the years. Notably, Bitcoin Core pull request #6871 introduced in November 2015 nSequence-based opt-in full-RBF behavior.
BIP 125
BIP 125 was an attempt in December 2015 to formally describe the RBF behavior implemented by Bitcoin Core. Even when published, the BIP had some subtle differences from the implemented behavior and therefore Bitcoin Core was never fully compliant with BIP 125.
Bitcoin Core’s documentation of the implemented behavior
In December 2021, a description of the behavior implemented in Bitcoin Core was added to the repository’s policy documentation which highlights the differences between the implementation and BIP 125 and includes a change log that summarizes how the implemented behavior was adapted over the years.
BIP 431 (TRUC transactions)
A related but distinct set of rules was specified in January 2024 with BIP 431: Topology Restrictions for Pinning. An implementation of BIP 431 was included in the Bitcoin Core v28.0 release.

BIP 125 specifies a set of rules under which a transaction may replace a prior transaction that signaled replaceability. Bitcoin Core implements similar but distinct rules, and notably since Bitcoin Core v24.0.1, node operators may accept replacements even in the case the original transaction did not explicitly signal replaceability by activating the mempoolfullrbf startup option. This option will be active by default starting with Bitcoin Core v28.0 due to being broadly adopted by a super majority of the hashrate.
BIP 431 proposes that senders set a transaction’s version field to version 3 to request that node operators enforce topological restrictions on that transaction while it is unconfirmed. We refer to these transactinos as  "topologically restricted until confirmed" or TRUC transactions. These topological restrictions apply independently of BIP 125 and the mempool behavior of Bitcoin Core applied to all transactions, and are only applied to transactions that set version 3. BIP 431 neither supersedes BIP 125, nor changes the behavior of Bitcoin Core in regard to transactions that do not use version 3. As these topological restrictions prevent TRUC transactions from forming packages larger than two transactions, some basic opportunistic package relay and package replacement can happen for TRUC transactions with the features shipped in Bitcoin Core v28.
The overall Package Relay Project is tracked in Bitcoin Core #28970.

This is a work in progress answer taken mostly from the notes of the Bitcoin Core PR review club on February 22nd 2023 on "nVersion=3 and Package RBF". As always alternative answers are welcome.

What is BIP 125? Which BIP 125 rules are still being enforced in default policy in Core today? Which aren't? Which BIP 125 rules have been replaced with alternative rules in Core today?

BIP 125 outlined how a transaction could signal that it was replaceable by a replace-by-fee (RBF) transaction. It was later discovered that the signaling rules as described in BIP 125 didn't match what was implemented in Bitcoin Core. Hence although a versioning system for BIP 125/RBF rules hasn't currently been introduced I'll use a RBF rule versioning system in this answer to be clear on exactly what rule I'm referring to.
Although the original Bitcoin Core implementation predated BIP 125 I will call the BIP "version 1" and the original Bitcoin Core implementation "version 2" because later changes and future versions ("version 3" and later) were made from the Bitcoin Core implementation and not from the BIP. This versioning system I am introducing is distinct to the "V3" transaction proposal which would set the nVersion field in the transaction to 3.
Issues with BIP 125: https://gist.github.com/instagibbs/b3095752d6289ab52166c04df55c1c19
Current RBF rules (BIP 125 v3) in Bitcoin Core: https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md#current-replace-by-fee-policy

What (and where) is the proposed replacement for BIP 125?

I'm not sure this exists yet. We'll call this BIP 125 v4 to differentiate from what is currently implemented in Core (BIP 125 v3) today.

What is V3 Policy? Is the proposed replacement for BIP 125 part of V3 Policy?

Link: https://github.com/bitcoin-core-review-club/bitcoin/blob/7198dac47279967be1a5d97c5423df60ff3b7df5/doc/policy/version3_transactions.md

What is package RBF and is this part of V3 Policy or a separate proposal to V3 Policy? Is the intention that package RBF will (eventually) be enabled at the same time as V3 Policy or can they be enabled at different times.

There is no versioning of BIP125. BIP125 describes a set of rules and it has not changed.
V3 refers to a completely separate set of policies to apply to transactions with nVersion set to 3.

@glozow: There isn't. It does make it hard to follow without them. Whenever I see say "Rule 3" I have no idea whether it is referring to Rule 3 in BIP 125, Rule 3 as originally implemented in Core, today's Rule 3 in Core, a proposed future change to Rule 3 in Core etc. I get "V3" is not referring to BIP 125 version 3 (which as you say hasn't been versioned)


text:
Is there an open source clone of SatoshiDice that works on altcoins?
There are many clones of SatoshiDice.
SatoshDice is very primitive game in a technical sense. However, it's very popular among Bitcoin users. It seems like the same thing would be true of altcoins, but there are only 10-20 alt-coin dices versus 200-300 alt-coins.
It seems like the engine of satoshi-dice might be easy to implementat. Probably, without a server-side database. One page-php + bitcoind + little log + small cron's script.
That is why I'm looking for turnkey solution.

Interesting post, but I have problems at finding the question. What exactly are you asking?

I'm looking for "OpenSource Alt-coins Dice engine"

Beware, there are lots of problems with dice, especially when there is a relatively low hash rate (e.g. most altcoins). An attacker with enough hashpower to solomine could steal fairly easily. I can't find the article detailing how a miner could defraud you but it goes something like this:

Attacker has 250 BTC
Attacker makes 2 transactions from one input, but doesn't publish them

betting 250 BTC on Satoshi Dice 50% 1.98x
sending 250 BTC to another address owned by attacker

Attacker solo mines bitcoin at 0.1% of network (reasonable expectation to block: 1 week) with transaction b included
Attacker finds a block and holds it while sending 250 BTC bet to satoshi dice
Within seconds, attacker knows if they've won 245 BTC or if they've lost

If attacker loses bet: they publish the block, effectively unspending the transaction sent to satoshidice
If attacker wins bet: they discard the block, since 245 BTC is greater than the 25 expected from the block
Also, it's possible for people to game these 0 confirmation games by not paying a fee to the game and sending a double spend with a fee. See: https://bitcointalk.org/index.php?topic=130764.0
Any dice game you use should be deposit based, like just-dice.com

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


text:
buying bitcoin with Amazon gift card
why all the sellers whom selling bitcoin with Amazon gift card are asking for physical cards with a receipt for it.
Thanks

There's no current way to check the Amazon gift card balance without actually depositing the gift card into your account.
See this post from purse.io for more details.

well because there are a lot of scams out there especially on amazon. Most sellers requires that the amazon gift card is purchased with cash and they need receipt because a lot of scammers and hackers are stealing peoples credit card information and buying these gift cards online and using those gift cards to buy bitcoins, now once the credit card holder notice the charge on their cards they dispute it and if the seller of the bitcoin haven't use the card balance than it will be removed from the card. The sellers are being careful because it would be their lost. I have a $25 amazon gift card that I bought from walgreens to buy bitcoins and because I misplaced the receipt I can't buy the bitcoin.


text:
What options does one have to manage Bitcoins?
I started trading and buying Bitcoins for a while now, and realised: I have multiple wallets and multiple websites where I have bitcoins/litecoins.
I think most of the people, including me, want use Bitcoin in there day to day life, and also invest in Bitcoin and Litecoin.
For this, which setup is recommended?

Is it safe yet to store, lets say, 50 to 100 Bitcoins at some online service, or should I, after purchasing, transferring it to a
  hardware wallet?
Are there any sites which are buying Bitcoins or is it always from person to person (therefore, Volume might be a problem when investing)
All recommended services and wallets also have as many open "recently got hacked" reddit threads. Which ones have to be in a basic
  setup?

In my perfect world, I have

A hardware wallet with my Bitcoin investment
A hardware wallet with Litecoin
A mobile app for day-to-day bitcoins
A trusted online service where I go to buy Litecoin/Bitcoin and also
sell it

Is my perfect world correct, are the big tradings time over or yet to come? From a tech perspective, Bitcoin is quite old, but there are still just low-quality apps out there.
Any guidance?

Hey gruberb, welcome to Bitcoin.SE. I feel that your question is a bit hard to answer, as you don't provide guidance as to what factors you would like to consider in the evaluation of "better". To mind come for example safety, convenience, or cost. Generally, recommendation requests tend to being closed as "primarily opinion based", so perhaps an edit towards "What options does one have to manage Bitcoins?" or "What should I consider when setting up my Bitcoin storage?" would be best.

Thanks a lot @Murch, I updated my answer and hope to fulfill the quality guidelines.

I am not a trader, so I don't have much advice to offer in terms of which services are best.  However, I do have some thoughts and experience with storing bitcoins.
From a technology standpoint, bitcoins are secured by the private keys held by the owner of the coins.  Private keys are cryptographically amazing, but terrible in terms of user experience.  If the management of private keys was easy to create an interface for, the internet would be a much more secure place.  Unfortunately, humans have proven really bad and managing private keys.  This is the problem every bitcoin wallet attempts to solve.
To understand your options for managing private keys (wallets), you have to understand how the security model works.  As the name suggests, private keys are meant to remain private.  Anyone who has knowledge of them has access to your bitcoins.  Meanwhile, you also never want to lose your own access to the private keys.  If you do, you lose your bitcoins.  This creates a problem with solutions that have an indirect relationship between the two issues.  If your private keys are well protected, you increase the chance that you will lose your access as well.  If your private keys are easily accessible, you are unlikely to lose them, but far more likely to be robbed.  There are some elegant technical solutions for this paradox, but no user-friendly solutions that come to mind.
Let's explore some of the options.
Web Wallets
This is the case where some online service manages your private keys for you, but gives you access to control how the bitcoins they store are used.  Personally, I would define the owner of the bitcoins to be whomever has access to the private keys.  With this viewpoint, you are not the owner of the bitcoins held in an online wallet.  You are the owner of an account with an organization who owns the bitcoins on your behalf.  The question of whether it is "safe" to store 50 to 100 bitcoins in an online wallet can only be answered by answering one or both of these questions:

Do I trust this 3rd party with 50 to 100 bitcoins (both with honesty and security)?
Can I afford to lose 50 to 100 bitcoins?

If your answer to either question is "no", then you may want to consider reducing the amount you store in the online wallet to an acceptable amount.
Hardware Wallets
These are single-purpose computers that manage your private keys for you.  Because they are usually offline devices, they go a long way towards being hacker-proof, but remember that there really is no such thing.  These sound great, and many people have started using them, but I'm personally skeptical.  These products were created from a growing demand, and rushed to market to beat out competitors.  Even if the security is perfect (which it never is), you are now trusting your wealth to the reliability of these machines.  I would recommend letting the market settle down for a couple of years, and let a few more generations come out, before trusting too much of your wealth to these devices.  You don't want the scenario where the thing won't power on, but you have your life savings stored on it.
Mobile App Wallets
These wallets are by far the most convenient for day to day use, perhaps even more so than online wallets.  You can scan QR codes to pay people, generate QR codes to be paid, and have your funds at your fingertips as you go about your day.  The drawbacks are also pretty steep.  Your funds are now only as secure as your phone.  If you get malware, you could lose your money.  If your phone gets lost or stolen, you lose your money.  If your device breaks (ex. dropped in the toilet), you may lose your money.  I view a mobile app wallet as I view a physical wallet.  You don't go about your day to day business hauling around your retirement savings.  You only leave the house with as much cash as you plan on spending that day, and try to keep it to what you can afford to lose.
Desktop Wallets
This is the case of running Bitcoin Core, or Electrum, or some other desktop-based wallet.  In principal, these are about the same as a mobile app wallet, with the advantage that you may be participating as a full-node in the Bitcoin network.  This allows you to trust transactions and blocks more than with an SPV Wallet, but doesn't really offer anything better in terms of the management of private keys.  Desktop wallets can be run on your day to day desktop, or perhaps a desktop that is usually kept offline and used only for bitcoin transactions.  Like with mobile app wallets, the security of this wallet is only as secure as the computer it runs on.  Also remember that software wallets (both mobile and desktop) have the ability to backup the wallet files, which can add to their reliability, but increase the number of ways your bitcoins can be compromised.  Again, there's always a trade off.
Paper Wallets
A paper wallet is a physical, paper document that contains a QR code of the the private key to a Bitcoin address.  You can store money in the wallet by sending bitcoins to the address, and then redeem them later by importing the private key into some other type of wallet.  This document can then be stored in a safe, a safety deposit box, buried in the woods, or anywhere else that you feel is safe from burglary and fire.  Think of this as a stack of fiat currency being held in a safe.  This is one of the safest ways to store your bitcoins, but is terribly inconvenient.  There is also the question about how the address was generated in the first place.  If you don't trust the software/organization that generated the paper wallet, then you can't trust the wallet.
Brain Wallets
A brain wallet is a way of generating a private key from a passphrase that is not stored anywhere, but rather remembered by the owner of the wallet.  It is much like a paper wallet, except that the private key is never written down.  Again, you must trust the software used to generate this address from your passphrase.  You will also most likely want to generate a passphrase, rather than use a passage from literature or a song lyric.  With computer speed and storage increasing along an exponential curve, and all the worlds books being digitized, it is not unthinkable that someone will attempt to steal bitcoins by brute forcing every known phrase from every book and song.  With cryptography, randomness is extremely important.
To conclude, diversification is always a good strategy for wealth management, and bitcoins are no different.  If you spread out your bitcoins between different types of wallets on different storage mediums, then you are less likely to lose everything, but more likely to lose something.  If you limit exposure to the wallets you use for long-term holding, you increase your security.  Just don't forget your password, passphrase, safe combination, place you buried it, or whatever.
I hope that helps.


text:
New altcoin. Cpuminer gives me "booo"
I made a new altcoin based on "INSaNe" https://github.com/CryptoCoderz/INSN
I changed genesis hashes using this code:
    if (true  && (genesis.GetHash() != hashGenesisBlock)) {
                     //This will figure out a valid hash and Nonce if you're
                    // creating a different genesis block:
                        uint256 hashTarget = CBigNum().SetCompact(genesis.nBits).getuint256();
                        while (genesis.GetHash() > hashTarget)
                           {
                               ++genesis.nNonce;
                               if (genesis.nNonce == 0)
                               {
                                   printf("NONCE WRAPPED, incrementing time");
                                   ++genesis.nTime;
                               }
                           }
                    }
            printf("block.GetHash() == %s\n0x", genesis.GetHash().ToString().c_str());
            printf("block.hashMerkleRoot == %s\n", genesis.hashMerkleRoot.ToString().c_str());
            printf("block.nTime = %u \n", genesis.nTime);
            printf("block.nNonce = %u \n", genesis.nNonce);

So i started coin with two clients on localhost and tried to mine it with cpuminer-multi by tpruvot https://github.com/tpruvot/cpuminer-multi, but miner always gives me booo, please help me...
My OS: Kubuntu 16.04
There is no setgenerate or generate function in this cryptocurrency
00:15:45 setgenerate
00:15:45 Method not found (code -32601)
00:16:03 generate
00:16:03 Method not found (code -32601)

Cpuminer output:
Current block is 1
[2017-07-19 00:16:32] Switching to getwork, gbt version 7
[2017-07-19 00:16:36] CPU #2: 26.28 kH/s
[2017-07-19 00:16:38] accepted: 0/1 (diff 0.000), 26.28 kH/s booooo

Here is difficulty for mainnet:
bnProofOfWorkLimit = CBigNum(~uint256(0) >> 18);

Here is block time:
static const int64_t BLOCK_SPACING = 5 * 60;
/** Block spacing minimum */
static const int64_t BLOCK_SPACING_MIN = 3.5 * 60;
/** Block spacing maximum */
static const int64_t BLOCK_SPACING_MAX = 7.5 * 60;

Here is block version:
static const int CURRENT_VERSION=1;

Can you show how you us how/where you changed the time in the code.

How did you actually solve this problem?
Could you please share it? Many thanks,
BRs,
Joe

fixed! The main trouble is time. I set my time in genesis hash +3hrs, i changed my pc time +3hrs and voila! Mining works!


text:
What is the correct term for bitcoin market cap?
Market capitalization is a term that is usually used to refer to the total value of the shares of a company. Given that bitcoin is not a company, is there a better term than market cap that we should be using to describe the total value of all bitcoins?

The value of a commodity expressed by its exchange rate in dollars is sometimes referred to as "Total Dollar Value" (example).  That's probably the most commonly used term for referring to the value of all assets at the current valuation.
Incidentally, money stock refers to the amount of bitcoins themselves.  So currently (Feb 2013) there is about 10.8 million BTC.
There is another concept called purchasing power which might be used as well.  Because the value fluctuates, prefixing that definition and referring to it as "current purchasing power" might be an even better term.  Discussion on this was initiated in a forum thread.


text:
How to send transaction in Bitcoin-Qt without transaction fee

Possible Duplicate:
Is there a way to not pay the transaction fees when using the standard Bitcoin client?

How do I override the transaction fee in bitcoin-qt?

No it is not possible, not with the standard bitcoin client. See this http://bitcoin.stackexchange.com/questions/7161/is-there-a-way-to-not-pay-the-transaction-fees-when-using-the-standard-bitcoin-c/7170#7170

Um, yes it is possible - its really easy. There is an option in the settings you can change. See my answer in the question Gopoi referenced.


text:
What is the difference between accounts and adresses?
What is the difference between accounts and adresses? As discussed in this question accounts are a component of bitcoin wallets, different from addresses. What are they? How do they work?

A Wallet is a collection of Accounts and Addresses.
An Account is an arbitrary basket of Addresses. Transactions originating from and going into one Account will be kept separate from other Accounts (unless you use a move command, which moves the balances around without creating new transactions).
Address is the only part of this that is visible in the Block Chain.

Doesn't the move command move assets between accounts without creating a transaction that is sent out to the network? That would mean that there is no assignement of addresses to accounts, as in your scenario only the whole balance of an address could be moved from account A to account B.

@cdecker Edited accordingly.

So if addresses are contained within accounts, how then can you move bitcoin from one account to another without moving them from one address to another?

@KinnardHockenhull You bend the rule and allow the transactions to be spent with a different account until the balances are right.

@ThePiachu Huh?

Addresses are intrinsic to Bitcoin. Amounts of bitcoins are moved from an address to an address (most of the time that is, there are other mechanisms). A transaction that transfers bitcoins from address A to address B is sent to the network and will then be applied by all the nodes to their local replica of the ledger.
Accounts on the other side are a further abstraction that Bitcoin-QT (the mainline client) provides. It is purely for internal accounting and information about the accounts is not spread to the network.
Accounts simply have a balance, the sum of all account balances is the sum of all the addresses balance, but I don't think that addresses are actually associated with an account. The API supports this as if an address were associated with an account it would only be possible to move the entire balance of an address to a new account, while as it is implemented suggests that you can move any amount between the accounts.

What are the other mechanisms besides the coinbase transaction? and then, as above, you can't move balances between accounts without moving them between addresses, correct?

Your wallet is your account (or, accounts) and it holds all your public - private key pairs (mostly encrypted), all the transactions that corresponds to your addresses, and other details.
you can also add watch-only addresses for fun, just like a shares watchlist. If you write down all your private keys somewhere then your wallet could only contain all watch-only addresses.
Wallet is in fact more than an account, and it is your private ledger. Other wallet providers could store your backup options, escrow / mixing preferences, etc. into your wallet.


text:
Accesing bitcoind through terminal on mac
How do I use bitcoind through Terminal on Mac OSX? I think this is not adressed by these questions, but honestly, I'm not sure:
Bitcoin-Qt command line control on Mac
What are the steps in building bitcoind on Mac OS X 10.6?

Per Gavin Andresen's answer on the first post to which you linked, Bitcoin-Qt for Mac does not ship with bitcoind. However, you can still access it with curl or wget, or using the provided Python wrapper. See the post for more.
If you are adamant about using bitcoind itself, your best bet is to compile your own bitcoind using my instructions or using the instructions provided in the source distribution of bitcoin.

The OSX build instructions mentioned above may be one in the same come 0.8.0, when issue #2026 is complete.


text:
trouble with bitcoin cli regtest
These are the commands I'm running after building a clean ubuntu docker image with all the dependencies:
./src/bitcoin-cli -regtest &

It yields the error:
error: too few parameters (need at least command)

Next I ran:
./src/bitcoin-cli -regtest -daemon

which resulted in:
error: too few parameters (need at least command)

finally:
./src/bitcoin-cli -regtest 101 &

yields:
error: Could not locate RPC credentials. No authentication cookie could be found, and no rpcpassword is set in the configuration file (/root/.bitcoin/bitcoin.conf)

These commands have been taken from the following resource:
https://bitcoin.org/en/developer-examples#regtest-mode
There's a question here, and a corresponding answer that provides a script to start regtest, is that a good solution?
To stop the daemon use the interface or run bitcoin-cli stop.

Next step
so I ran first:
bitcoind -regtest -daemon

and I got the output:
Bitcoin server starting

then I tried:
bitcoin-cli -regtest getinfo

which resulted in:
error: Could not locate RPC credentials. No authentication cookie could be found, and no rpcpassword is set in the configuration file (/root/.bitcoin/bitcoin.conf)

these commands also generated the same output as above:
./src/bitcoin-cli -regtest help
./src/bitcoin-cli -regtest 101

so I've created the following file:
vim /root/.bitcoin/bitcoin.conf

it's literally just this:
rpcpassword=123

*also tried with this:
server=1
rpcuser=root
rpcpassword=password
rpcconnect=127.0.0.1
rpcport=8332

and now issued the command:
bitcoin-cli -regtest getinfo

which resulted in the following:
error: couldn't connect to server: unknown (code -1)
(make sure server is running and you are connecting to the correct RPC port)

It seems you're mixing up bitcoind and bitcoin-cli.
bitcoind is the Bitcoin Core daemon. It must be running first before you can do anything. bitcoin-cli is a tool to send RPC commands to a running bitcoind instance.
From the linked documentation page:

bitcoind -regtest -daemon

No need to put a & after the command if you run with -daemon.
Once bitcoind is running, you can for example send the getinfo command using bitcoin-cli:

bitcoin-cli -regtest getinfo

Or send generate 101 to generate 101 blocks:

bitcoin-cli -regtest generate 101

To learn about other commands you can send:

bitcoin-cli -regtest help

That way you could for example learn about the ping command. To learn more about that, you can send:

bitcoin-cli -regtest help ping

You need to specify -regtest for every command, as you can have a daemon running for each network (one for mainnet, one for testnet, one for regtest), or more if you configure each to run in separate directories and network ports.
Note that bitcoin-cli is just a program that speaks JSON-RPC (which is a standardized protocol), albeit somewhat specialized for use with bitcoind. You can connect to bitcoind using any JSON-RPC client (for which libraries exist in all popular languages). To do so, you'll need to configure a username/password for connecting to bitcoind.
To explain what you are seeing:

./src/bitcoin-cli -regtest & won't work as bitcoind is not yet running, and you aren't specifying a command to send.
./src/bitcoin-cli -regtest -daemon likewise.
./src/bitcoin-cli -regtest 101 & looks almost right, except you missed the generate, so you're trying to send the non-existing command 101 to a daemon that is not yet running.

you're exactly right that I was confused about id and cli, In Next step in the OP I tried to follow your guidance but also I seem to have messed it up, or it otherwise didn't work, I tried to write exactly what I've done, do you see what I've done wrong?

You can't change bitcoin.conf while bitcoind is running. Either no rpcuser/rpcpassport is set when bitcoind starts, and it'll use cookie authentication, or it is set, and both bitcoind and bitcoin-rpc will use it.

aha- ok. also I started the network like this: https://bitcoin.stackexchange.com/questions/45881/how-to-setup-bitcoin-network-using-regtest which seemed to be better- but now it crashes because the size of my docker container is too small :/ need to figure out how to resize it


text:
What is the magic number used in the block structure?
What is the Magic no used in the block structure, why is the value always 0xD9B4BEF9 and what is it used for ?
Thanks

http://bitcoin.stackexchange.com/questions/2337/how-was-the-magic-network-id-value-chosen

Also http://bitcoin.stackexchange.com/questions/41495/what-block-version-is-this-d9b4bef9-decimal-3652501241

The magic number is not something specific to bitcoin.
Magic numbers are used in computer science for both files and protocols. They identify the type of the file/data structure. A program receiving such a file/data structure can check the magic number and immediately know the supposed type of that file/data structure.
This is what the Unix/Linux command file uses to quickly identify the type of file. It only requires to check only the first bytes of a file to determine its (supposed) type. A list of files and their magic numbers can be found here.
Protocols like bitcoin use data structures to talk to each other (e.g. propagating blocks through the network). Nodes check the first bytes to identify the type of data structure.
Another use of magic numbers is that you can check the type of the file or data structure on a text editor. E.g. while a png image is binary if you open it with a text editor you will notice that it starts with .PNG..... Another example, the SMB protocol replies start with FFSMB. Note, however, that this is not always the case.
Other files/structures have magic numbers that do not make much sense; they may be some geeky code or inside joke of the developers that chose it.
So that is what it is used for. As far as I can tell 0xD9B4BEF9 is quite arbitrary... but maybe there is some meaning for its creator.

The way it was chosen is documented here.

Thanks @NickODell. Interesting. Actually, unless you stream the blocks I find that the probability of these bytes occurring in normal data is irrelevant.

I also commented in the answer you linked in case someone can clarify.


text:
Can I reload my node's config from the command line without restarting the node?
I needed to make some config changes to my node and I'd like to reload the config without stopping the node and then restarting it. Is that possible? I don't see any related RPC commands on the wiki.

I don't think so. There's a feature request about this, but I don't think a feature like that has been added.


text:
What libraries should I use for E-Commerce
We are developing some automated payment functions for Bitcoin. We want to automate transactions via a backend server setup; what libraries would be best suited?
I've found two libraries so far:

Java has BitcoinJ
C++ has bitcoin-qt

Would a thin or selfish client suffice ?
Do they support QR codes ?
P.S. I would prefer a Java over C++ coming from a C# background.

BitcoinJ is fully featured and recently updated.
There is also BitcoinSharp if you are from a c# background. This is a direct port of BitcoinJ (it   may be slightly out of date as a new BitcoinJ has been released recently).
As far as im aware it does not support native QR codes but https://btc.to/ has a http request which can generate QR codes (https://btc.to/1PeizMg76Cf96nUQrYg8xuoZWLQozU5zGW/qr) if you dont want to use your own.
A thin or selfish client may be suitable it really depends on what your application is, your confidence in the network and risk involved with your application in general.

I developed a solution using bitcoind (bitcoin-qt).
It was very easy with PHP + RPC Class, but bitcoind has some limitations which make it not very suited as a backend/library.

I was looking for java or C# as PHP ..thanks


text:
Can you Send Coins back from a Receive Address?
We are setting up some merchant functions
If a customer sends too many coins in a transfer for an order
Can you send the change back to address you received the coins from .
i.e
1) Order 1234 12.5 BTC Merchant Recieve Address (1234abc)
2) Customer Sends 12.6 BTC to Merchant Address (1234abc) from his Address (4567def)
3) Merchant detects overpayment And sends the 0.1 btc back to customers (4567def) Address as change
Will this work in that the customer will get his change ??

Did you mean "back to customer's (4567def) address"?

Yes back to the customers 4567def address

This is not recommended.
If the customer uses a fully controlled wallet he will get the coins, but will be confused about their source because the address would carry the label of some other provider.
If the customer is using a shared eWallet, he might not get the coins at all because the address isn't his.

On the shared wallet is it likely that the app is using an address not related to the user etc ?

How would you deal with this situation ??? Prompt the user for a change address ??

@BitCoinNewGuy Indeed - If you need to do a refund, ask for a refund address.


text:
What files do I need for backing up my wallet?
Is %APPDATA%\Roaming\Bitcoin\wallet.dat the only file I need to backup my wallet?
I've heard about backing up every ~50-100 transactions is this correct? I thought that with the wallet.dat file, I have my private key, which is all that I need to restore my bitcoins.

Yes.  The wallet.dat file is all you need to be able to keep your coins backed up.  You'll also obviously need your password if you've encrypted your wallet.
However, backing up the entire folder may be advisable if you're on a slow internet connection.  The blockchain is getting rather sizable and can take a significant amount of time to redownload from scratch.  I recently needed to do that and it took almost 2 full days.

Note: Unless you spend all "input", you will get some bitcoins 'back'. Bitcoin-qt will automatic assign a new bitcoin address to the "charge" (for security and privacy reasons). Your wallet.dat will contain a "key pool" of 100 new bitcoin addresses, but when theses are spend, then bitcoin-qt will generate a new addresses. So backup every 100 transfers, or change the default key pool size by running bitcoin-qt once with the parameter:
-keypool n

(where n = how many keys to pre-generate, eg 1000).


text:
Could the Lightning Network encounter any problems as a result of Taproot activating?
I was reading this excellent write up from Laolu Osuntokun on how the light client protocol Neutrino encountered a Taproot related issue on testnet. (Taproot is already active on testnet.)
Could the Lightning Network encounter any problems as a result of Taproot activating? I'm leaning strongly towards no as unlike Neutrino no Lightning implementations as far as I know have been set up to deal with SegWit version 1 (Taproot) transactions (channel opens or channel closes spending to or from a Taproot multisig). And so the Lightning Network should not even notice that Taproot has activated?
I guess a large re-org due to miners initially mining an invalid Taproot spend could disrupt the Lightning Network but that would be blockchain related rather than related to a specific Lightning transaction(s).

I am a bit uncertain thus the comment: A chain split / fork might lead to strange situations as you would not be sure which asset you actually route. Initially both but newer channels would be anchored in either one of the chains. In particular channels opened before the split would have to be closed in both networks.


text:
How do eltoo channel constructions using ANYPREVOUT compare to those using CTV and CSFS?
SIGHASH_ANYPREVOUT has been designed as I understand primarily for the eltoo channel construction use case although it has many other potential use cases too.
BIP 119 states:

Were both OP_CHECKTEMPLATEVERIFY and OP_CHECKSIGFROMSTACKVERIFY to be
added to Bitcoin, it would be possible to implement a variant of
Eltoo's floating transactions using the following script:

witness(S+n): <sig> <H(tx with nLockTime S+n paying to program(S+n))>
    program(S): OP_CHECKTEMPLATEVERIFY <musig_key(pk_update_a, pk_update_b)> OP_CHECKSIGFROMSTACKVERIFY <S+1> OP_CHECKLOCKTIMEVERIFY

How do these two eltoo channel constructions compare e.g. upsides and downsides? They clearly aren't equivalent. The BIP states:

Compared to SIGHASH_ANYPREVOUTANYSCRIPT, because
OP_CHECKTEMPLATEVERIFY does not allow something similar to
SIGHASH_ANYONECANPAY or SIGHASH_SINGLE, protocol implementers might
elect to sign multiple versions of transactions with CPFP Anchor
Outputs or Inputs for paying fees or an alternative such as
transaction sponsors might be considered.

The main answer is that we don't really have a fully spec'd Eltoo design for  Anyprevout (or CTV+CSFS), and that's something that requires more thorough investigation to make the correct primitives for Eltoo, including things like SIGHASH_BUNDLE.
The main issue that arises with (any) eltoo proposal is that you have to pay fees, somehow, and there is a Dust limit.
With APO Eltoo there is an issue that because the different sighash modes let you only sign one or all of the outputs, it's difficult to add fees to the transactions in it if they have >1 output. Thus (how I've seen eltoo described, I could be off) is such that one root transaction with 1 output drives state forward where outputs can be dynamically added, and the second layer of transaction expands to HTLCs but is not time sensitive to resolve, but I'm not sure how it's proposed fees are added to that. One option is to allow adding inputs (but not outputs) and you have to craft perfectly sized fee paying outputs, another option is CPFP on each HTLC. This is an option at this phase since every party should have some output (remember, eltoo is N party). This doesn't work at the state update level of eltoo since we don't want to have to create N outputs for CPFP-ing.
In CTV world you can have the option of adding an input, but you can't dynamically add change. So if you have N parties, you might sign N transactions to allow up to N parties to add an (perfectly sized) input to add fees. These input slots can accomodate any UTXO (without a relative timelock set). The state updates can also have a CPFP anchor output, that could be anyone can spend, it could also have a CTV congestion control tree of anchor outputs to allow any party to pay fee with only log4(N) cost to get a single CPFP hook, and constant overhead to get N hooks out.
One of the benefits of a CPFP approach over a RBF with new inputs approach is that it is slightly simpler to deal with various types of pinning attack when your transactions can't be dynamically changed by a third party.
Alternatively, my Transaction Sponsors proposal would benefit both APO and CTV based fee paying by moving the payment of fees to out of band.
Overall, short of a fee paying solution, the protocols are pretty much the same.
Lastly, as the question asker has insinuated on other platforms, he wishes to oppose CTV unless we prove that CTV+CSFS works for Eltoo, I'd advise against that. The point is that the main state update mechanisms described by Eltoo as implementable via APO can be achieved with CTV + another possible proposal (CSFS) that is a little simpler than APO, but does not currently have a BIP. In either case, the main thing that should happen is more research into Eltoo to fully prove out the requirements for the system and then we can adopt the set of upgrades required to give us the best version of that. I suspect that means something like transaction sponsors or sighash bundles, but it's not my prime area of research. CTV has enough 'other stuff' going on that witholding it's release pending ongoing research on the lightning network seems like an unforced error.

"Lastly, as the question asker has insinuated on other platforms, he wishes to oppose CTV unless we prove that CTV+CSFS works for Eltoo, I'd advise against that. " Nope, merely to hammer out details before attempting activation. Answering questions before activation rather than afterwards. Does CTV work for eltoo is only one of those questions. If the answer is no I'd focus more on the other use cases of CTV.

I wish to support CTV if it is optimal for a single or multiple use cases that the community is demanding. I wish to oppose CTV if it is not optimal for any of the use cases the community is demanding. Today I haven't worked out whether it is optimal or isn't for these use cases hence the question.

To add to Jeremy's answer I'll summarize some thoughts from Christian Decker (co-author of BIP 118 for ANYPREVOUT) on the bitcoin-dev mailing list.
As Jeremy points out SIGHASH_ANYPREVOUT (APO) has been refined and optimized for the eltoo channel construction use case to a much greater extent than OP_CHECKTEMPLATEVERIFY (CTV). There is still a lot more work to do to build out and test the eltoo construction using ANYPREVOUT but none of this work has been done using the CTV and CHECKSIGFROMSTACK construction at the time of writing (January 2022).
While it may be possible to emulate APO using CTV, APO does not have any overhead in the transaction size which is not the case for CTV. Hence eltoo transactions using APO are more efficient in terms of vbytes.
In addition (and arguably least importantly) it has been highlighted on a number of occasions that CTV only represents ~200 lines of code change. APO is even simpler in terms of lines of code than this. The original SIGHASH_NOINPUT (since updated for Taproot and renamed to SIGHASH_ANYPREVOUT) contained as little as 3-5 lines of code in Bitcoin Core.


text:
Transaction using too many pieces
Transactions been formed with too many pieces of different ages, causing the transaction to have a huge size and therefore require very high fees.
Question
Is there a way to reduce the size of the transaction?
Story
I have a payment system that accepts bitcoins.
Therefore my client (the store owner) receives many transactions of relatively small amounts ($30 - $400 amounts).
And every now and then he tries to move what he has on his address to exchange that to dollars.
We use Blockcypher's API.
The problem is that when we construct the transaction, the script gets formed with all the sum of the different pieces, indicating which pieces will form the payment, as I see it, this is done using the age.
An example of how these pieces are in the input list is here:
"inputs": [
  {
    "prev_hash": "094be5d93ec5a5299fc8f64501855010649e3bb15d56f41ac9b5291d0XXXXX",
    "output_index": 0,
    "script": "483045022100d73dd1a8499caac0d237f5f2df17786722b4e50120756bc63c4f5f513b4f4244022019d20416762f21870e63fe035e2a0599217bc62323430ca428c2d1c8930b67270121035a3ce00ccf0701a28f124e634f4243ef2b40650aad5b0433eba4feXXXXXXX",
    "output_value": 1883692,
    "sequence": 4294967295,
    "addresses": [
      "1Lpua75bYTfeVUaEYDEkzY1vxwaVFvUNNr"
    ],
    "script_type": "pay-to-pubkey-hash",
    "age": 498654
  },
  {
    "prev_hash": "1917bb8a51642541f9d4b20beeec02a57193d5ede91e7fc79a6b7aXXXXXXX",
    "output_index": 0,
    "script": "483045022100d5f54e8b89fe080b16236a742bce0d4512f83d382a683bee96a25d5c1ff41a0802206844d81b0c2d909e4d893733a7f317caaa49a408f69c0414cee0685ac96883850121035a3ce00ccf0701a28f124e634f4243ef2b40650aad5b0433ebaXXXXXXXX",
    "output_value": 2470000,
    "sequence": 4294967295,
    "addresses": [
      "1Lpua75bYTfeVUaEYDEkzY1vxwaVFvUNNr"
    ],
    "script_type": "pay-to-pubkey-hash",
    "age": 498665
  },

Is it really necessary to indicate the age of the pieces used?
Is there a way to reduce the size of the transaction script?
This is costing too much in fees to my client. We are talking transactions that costs hundreds or more dollars.
Thanks in advance.

Is it really necessary to indicate the age of the pieces used?

The "age" is shown only in Blockcypher's API. Transaction itself does not have such field

Is there a way to reduce the size of the transaction script?

Yes. Use segwit

Is there a documentation on how to create SegWit transactions?


text:
Getting error while accessing bitcoin client from ruby using Rpc
I am getting the following error while trying RPC call from ruby. bitcoind server is running. I am using bitcoin-ruby library .
Code Tried in irb to test:
require 'bitcoin'
=> true
irb(main):002:0> txid= "611b40973fe68cc42b70ae5af365a449af458d76086415c6fa6c45364c36278e"
=> "611b40973fe68cc42b70ae5af365a449af458d76086415c6fa6c45364c36278e"
irb(main):003:0> rtx= bitcoinRPC('getrawtransaction',[txid])

Error :
NoMethodError: undefined method `bitcoinRPC' for main:Object
    from (irb):3
    from /usr/bin/irb:11:in `<main>'

Any suggetion will be highly appreciated.
Thanks in advance,
R

Use the following method to call BitcoinRPC using Ruby:
Create ruby file test.rb as
require 'net/http'
require 'uri'
require 'json'

class BitcoinRPC
  def initialize(service_url)
    @uri = URI.parse(service_url)
  end

  def method_missing(name, *args)
    post_body = { 'method' => name, 'params' => args, 'id' => 'jsonrpc' }.to_json
    resp = JSON.parse( http_post_request(post_body) )
    raise JSONRPCError, resp['error'] if resp['error']
    resp['result']
  end

  def http_post_request(post_body)
    http    = Net::HTTP.new(@uri.host, @uri.port)
    request = Net::HTTP::Post.new(@uri.request_uri)
    request.basic_auth @uri.user, @uri.password
    request.content_type = 'application/json'
    request.body = post_body
    http.request(request).body
  end

  class JSONRPCError < RuntimeError; end
end

if $0 == __FILE__
  h = BitcoinRPC.new('http://username:password@127.0.0.1:8332')
  txid= "611b40973fe68cc42b70ae5af365a449af458d76086415c6fa6c45364c36278e"
  p h.getrawtransaction(txid)
end

NOTE:
username and password are from your bitcoin.conf file.

mark this as answer if you run successful.


text:
What happens to bitcoin transactions that are unconfirmed during the hard fork?
So I've just moved my bitcoins out of Coinbase into my own wallet in anticipation of the hard fork as they will only support BTC (and not BCC) afterwards.
It's been about 6-7 hours and it still is in Pending. On their help site(https://support.coinbase.com/customer/en/portal/articles/593836), there is a message saying "Partially Degraded Service: In advance of the upcoming potential hard fork, we are processing a large volume of outgoing Bitcoin transactions. Recent or new outgoing BTC transactions may be delayed by up to 12+ hours as we process this backlog."
So I'm hoping that 3 days is enough to get my transaction but I'm wondering, at the time of the hard fork, what will happen to the transactions that are midway though? Would it be different if the transaction has had no confirmations vs if it already has a few confirmations but just not the 6 for it to be fully confirmed?
Will they end up in the new wallet address for both the BCC and BTC network? Will they end up in the new wallet address for only BTC and BCC will still be in the old address?

If the transactions are still unconfirmed after the hard fork has occurred, you will only receive the coins on your Bitcoin wallet, not the Bitcoin Cash wallet. In that case, Coinbase still holds all of your Bitcoin Cash coins.

So if we keep both source and destination private keys of an unconfirmed transaction, no risk to lose fork tokens, right?

If you have the private keys, you cannot lose any coins at all.


text:
What is the cheapest Bitcoin -> prepaid VISA/Mastercard service?
I am looking for the cheapest Bitcoin to prepaid VISA/Mastercard service for the amount of $5000. I have noticed some with a maximum of $100, and inquired whether it would be possible to increase this cap. It is really not interesting to have to buy 50 cards, and ensure that one empties each of them. $1000 on each card is acceptable though.
The card needs to work for purchases in any country.

That's quite a lot of money to try to load onto a prepaid card and likely not something you'll find easily done.
Some options are:

http://www.okpay.com/en/services/debit-card/index.html
https://www.aurumxchange.com/cards Expect to get their cards program back soon.

With OKPay, you can reload using bitcoins, which OKPay will exchange into USDs for you (the cost of this was just reduced from 5% to 2.5% of transfered amount).
With AurumXChange, you can reload using USDs from Mt. Gox codes.
For that amount though you'll probably be best arranging trades with some buyers willing to exchange Moneypak to you.  For instance, on the #bitcoin-otc there often times are traders looking for BTC and for larger amounts will go out and buy a MoneyPak to do the trade.
You can load a number of different prepaid cards with MoneyPak, up to $1,000 each.  See the Prepaid Cards section for the list: https://www.moneypak.com/WhoAccepts.aspx
Along the same lines, you might find a trader that would deposit cash at Western Union to reload a Western Union prepaid card.

Aurum Exchange has a different domain ("exchange", vs. "xchange") and doesn't seem to handle Bitcoin.

Since May 2013, OKPay no longer accepts Bitcoin

Paxum doesn't seem to accept Bitcoin either. This answer needs a big update.

I would recommend http://www.xmlgold.net. They offer a pretty good system which allows you to buy a prepaid mastercard with bitcoins and load the card with bitcoins. They have low fees.

The Mastercard itself is expensive to use, and they do not make it easy to see how much they take for converting from Bitcoins to Eur.

xmlgold.net is dead, and the .eu site refuses connections from the US.

http://bitcashretail.com/ (service is now dead)
Quote from site:

We will provovide you a digital Visa card for the spot price of Mtgox for a Bitcoin equivalent of a $7usd service charge. Available to registed users only!

Welcome to the site. One upvote to get you started. I could only see that they have visa cards for 25$, which is too low.

Are there any people describing their experience with this service (BitCashLotto.com , IIUC)?

BitcashRetail is dead

Visit en.bitcointalk.org - Their you will find awesome services!

Seems like the price is 27€ for a 25€ virtual card when I also count in the poor exchange rate they offer. This is the cheapest I have seen so far.

I have tested this now, and it works perfectly!

@David: what service have you tested that you have found on the Bitcoin forums? This answer would be more useful if it mentioned some services.

@cryptal The original answer mentioned CryptCard.org, but that service has been closed down.

Why not using Bitcurex card?
It's the cheapest and most anonymous way. For 5000 USD you would need 2 cards only, and you don't have to sign for the shipping for two cards.
With a bit of searching you can even load it through an IBAN account from different exchanges, not just Bitcurex. (a bit of searching required)
I'm using them all the time and I'm very happy with them.

You can also try CentreGold for this service but you will have to transfer them Liberty Reserve (USD) from your Gox account.
https://centregold.com/public/debitcard.php

I have got an XMLGold Prepaid MasterCard from PFS and it can be loaded instantly with bitcoins during a daytime, the card cost just 2 Bitcoins and delivery was included. You can get the card here: instant bitcoin mastercard

Check out Ecardone.com
more info here. They offer a prepaid MasterCard debit card that can be loaded with Bitcoin for $3 plus 2%. You also need to buy Bitcoins through their exchange, which costs you an additional 3% or so.

Right now they have a fee of 3% for depositing BTC because of them offering lower exchange rates. This is so sneaky that I will be reluctant to use them as I will always have to do the manual work of comparing their exchange rates to those on MtGox.com


text:
What stops someone from faking a rating on OTC web of trust?
What mechanisms does OTC web of trust have against someone creating several accounts and trading between with themselves over a period of time, giving each other perfect ratings.

The global ratings are fairly easy to manipulate as you describe, and it has been done before. There is some minor protection provided by the requirement that you need a positive OTC rating to rate anyone else.
#bitcoin-otc also supports "trust rating" (example) which can't be easily manipulated.


text:
How does blockchain.info access my wallet in MyWallet
I made a wallet at blockchain.info and enabled two-step authentication using Google Authenticator.
As I understand it, the operator of blockchain.info cannot access your wallet (unlike e.g. MtGox). Yet somehow blockchain.info can deposit coins in my wallet.
Also, I assume the two-step does not work for the offline backup files, but the password does?

You can print on a piece of paper a wallet and obviously you can't connect it to the web. To deposit money to any wallet you need a valid address tied to a private key. The address is unknown to the network until someone attempts to send money to it, then it is within the blockchain forever. You use the private key to sign the bitcoins tied to that address to another wallet.
To give you a visual representation:

The address you send money to is on the left and the key you need to access the bitcoins tied to the piece of paper is on the right. Blockchain's double factor authentication first encrypts your wallet and then also has an encryption for the private keys tied to the addresses within the wallet. You cannot sign for the funds in the wallet until you enter the second password thus preventing a hacked wallet from being useful.
Blockchain cannot decrypt the wallet nor the keys and thus the only possible failure event would be for their servers to crash and you losing access to your wallet. Thus you should backup your wallet often using their backup service.

I love how this community never upvotes me. This is a solid answer

Your wallet is only used to send coins. To receive coins you don't need access to the wallet.