Bitcoin Finance Core FIP-04 Updates(v17.0):

17.0 Bitcoin Finance Pre Build Notes:

The Foundation is about to release the 17th series of nodes, which is prepared for the flash loan protocol and multi-signature addresses.

Features of the new BTF node:
1. Fix the node synchronization failure caused by Seed DNS pollution.
2. Provide a basis for the release of the flash loan protocol.
3. Fix the transaction index of the full node.
If you have any questions about the above update preview, please contact us.
[email protected]

Flash Loans protocol on Bitcoin finance:

Our team is developing a flash loan protocol based on BITCOIN. It is currently in the experimental stage. The protocol is similar to AAVE, but the loanable time of a single block is much longer than AAVE.

v17.0 Upgrade Guide

Download & Update BitcoinFinance Core Windows

Download & Update BitcoinFinance Core Linux

Release Notes:

Change Log:
Bitcoin Finance Network - Satoshi-BTF(BitcoinFinance)-Main-vSeventeen:0.17.1
******************************************************************************************
+ Feature - *ckpIndex - Transactions index
******************************************************************************************
Description:
When called with a blockhash argument, getrawtransaction will return the transaction
if the specified block is available and the transaction is found in that block.
When called without a blockhash argument, getrawtransaction will return the transaction
if it is in the mempool, or if -txindex is enabled and the transaction is in a block in the blockchain.

Usage:
./bitcoind -txindex=1000000 -reindex

Code:
pow.cpp L104

Function:
static bool ckpIndex(const CBlockIndex* pindexLast)



Txindexing Guide:
Download Latest synced block data from:
https://www.btf.finance/opensource.html
and unzip the *.zip file to the Bitcoin Finance Core block directory and replace the [blocks] and [chainstate] folders.
Please carefully check the directory where the actual application is located.
There are differences between bat startup and conf startup.

Txindex Command :
./bitcoind -txindex=1000000 -reindex (indexing 100,000 Transactions recently)



******************************************************************************************
+ Feature - *vSeventeen - vSeventeen Upgrade
******************************************************************************************
Description:
Bitcoin Finance Network - V17 network upgrade ckpt
V16 Final Block:
block - 341733 hash - 000000000000253889cf85b1ee03f8d158b737ac7e0b54b0ad6ad41b7cff6eb6
https://explorer.btf.finance/block-height/341733
V17 upgrade : block>=341734


Code:
pow.cpp L93

Function:
static bool vSeventeen(const CBlockIndex* pindexPrev)


******************************************************************************************
+ Feature - *V17 Checkpoint - Transactions index
******************************************************************************************
Description:
Checkpoint for Bitcoin Finance Network V17.1
{300001, uint256S("0x00000000000039557e9234c4f4de4f915f985be797e2705a0f8b65e486c7c31a")},
{341734, uint256S("0x00000000000009b116f0785c4783a18a170dc442f677c2f4876c0b9bdd446b28")},
//V17 upgrade Checkpoint

Implementation

It should be noted that the states are maintained along block chain branches, but may need recomputation when a reorganization happens.

Given that the state for a specific block/deployment combination is completely determined by its ancestry before the current retarget period (i.e. up to and including its ancestor with height block.height - 1 - (block.height % 2016)), it is possible to implement the mechanism above efficiently and safely by caching the resulting state of every multiple-of-2016 block, indexed by its parent. Warning mechanism

To support upgrade warnings, an extra "unknown upgrade" is tracked, using the "implicit bit" mask = (block.nVersion & ~expectedVersion) != 0. Mask will be non-zero whenever an unexpected bit is set in nVersion. Whenever LOCKED_IN for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period (when the unknown upgrade is in the ACTIVE state).