diff --git a/doc/concepts/Temporal Level Blockchain.MD b/doc/concepts/Temporal Level Blockchain.MD
new file mode 100644
index 00000000..070b03a1
--- /dev/null
+++ b/doc/concepts/Temporal Level Blockchain.MD	
@@ -0,0 +1,148 @@
+A blockchain concept based on temporally leveled chain levels and correlations between time-to-mine and difficulty could be an interesting approach to improve the efficiency and scalability of blockchain networks. Let's call this concept the Temporal Level Blockchain (TLB). Here's an outline of how such a system could work:
+
+Temporal Levels:
+
+In the TLB, blocks are organized into distinct temporal levels based on their time-to-mine. The levels are pre-defined, with each level representing a specific time range. For example:
+
+Level 1: 0-10 minutes
+
+Level 2: 10-20 minutes
+
+Level 3: 20-30 minutes
+
+... and so on.
+
+Mining Process:
+
+Miners compete to solve cryptographic puzzles to create a new block. The difficulty of the puzzle is adjusted dynamically based on the current level's target time-to-mine range. As the mining time progresses, the difficulty of the puzzle adjusts to maintain the desired temporal level. For example, if a block is mined within 5 minutes, the difficulty could be increased, whereas if it takes 15 minutes, the difficulty could be decreased.
+
+Block Validation:
+
+When a block is mined, it is added to the appropriate temporal level. Other nodes in the network validate the block by verifying its difficulty and the temporal level it belongs to.
+
+Chain Selection:
+
+The longest chain is still considered the valid chain, but the cumulative difficulty across all temporal levels is also taken into account. This way, shorter chains with higher overall difficulty can be considered valid if they are more computationally intensive.
+
+Incentives:
+
+The block reward for mining a block can be adjusted based on the temporal level it belongs to. Blocks in higher levels could offer greater rewards, incentivizing miners to focus on solving more difficult puzzles.
+
+This Temporal Level Blockchain (TLB) concept could have several potential benefits:
+
+Scalability: By organizing blocks into temporal levels, the TLB could allow for more efficient parallel processing of transactions, reducing congestion on the network and improving scalability.
+
+Energy Efficiency: Miners could target specific temporal levels based on their computational capabilities, leading to a more energy-efficient mining process.
+
+Security: The correlation between time-to-mine and difficulty could increase the overall security of the network, as it would be more challenging for attackers to manipulate the chain.
+
+Flexibility: The TLB concept could be adapted to different use cases by adjusting the temporal levels and their respective target time-to-mine ranges.
+
+However, there may also be potential challenges with the TLB concept, such as:
+
+Implementation Complexity: Introducing temporal levels and dynamic difficulty adjustments could add complexity to the blockchain's implementation and maintenance.
+
+Network Effects: The TLB concept may require a critical mass of miners and nodes supporting the system for it to function effectively.
+
+Incentive Balancing: Ensuring the right balance of incentives for miners across different temporal levels could be challenging and may require ongoing adjustments.
+
+Overall, the Temporal Level Blockchain (TLB) concept presents an interesting approach to improving the efficiency and scalability of blockchain networks, but further research and development would be needed to address potential challenges and fully realize its potential.
+
+Converting the existing Bitcoin blockchain into the Temporal Level Blockchain (TLB) concept would be a complex process, and it may not be practical without significant changes to the current infrastructure and consensus mechanisms. However, it could potentially be implemented in a few ways:
+
+Hard Fork:
+
+A hard fork could be introduced to implement the TLB concept in the Bitcoin network. A hard fork is a change in the blockchain protocol that is not backward-compatible. This would mean that all nodes and miners would need to update their software to support the new protocol, resulting in a split of the original blockchain into two separate chains: one following the original protocol, and the other following the new TLB protocol. This approach would require strong community support and consensus, as it could lead to potential disruptions and risks, including reduced network security and loss of value.
+
+Sidechain:
+
+Another approach could be to implement the TLB concept as a sidechain to the existing Bitcoin blockchain. A sidechain is a separate blockchain that runs parallel to the main chain and allows for the transfer of assets between the two chains. This would enable the TLB sidechain to take advantage of the proposed benefits, such as increased scalability and energy efficiency, without directly affecting the main Bitcoin blockchain. Users could choose to move their assets to the TLB sidechain if they find its features more attractive. This approach would be less disruptive but may face challenges in gaining widespread adoption.
+
+Layer 2 Solutions:
+
+The TLB concept could also be adapted as a Layer 2 solution built on top of the existing Bitcoin blockchain. Layer 2 solutions aim to improve the scalability and efficiency of the main chain without modifying the underlying protocol directly. This could involve creating a separate network that utilizes the TLB concept for processing transactions, and periodically settling these transactions on the main Bitcoin blockchain. This approach may provide some of the benefits of the TLB concept while minimizing the impact on the existing Bitcoin infrastructure.
+
+While it may be technically possible to convert the existing Bitcoin blockchain into the TLB concept using one of these approaches, it would likely face significant challenges related to community support, consensus, and adoption. Additionally, it's worth noting that other blockchain projects and Layer 2 solutions are already exploring similar ideas for improving scalability and efficiency, such as Ethereum's move to Ethereum 2.0, which shifts from a Proof of Work (PoW) to a Proof of Stake (PoS) consensus mechanism, or the Bitcoin Lightning Network, which enables off-chain transactions to reduce congestion on the main chain.
+
+If compression is implemented without data loss (lossless compression), the Temporal Level Blockchain (TLB) could still benefit from reduced storage requirements and improved efficiency, while maintaining the complete transaction history for auditing and trust purposes.
+
+Lossless compression algorithms, such as LZ77, Lempel-Ziv-Welch (LZW), or Huffman coding, could be used to compress block data as it moves up to higher temporal levels. These algorithms would allow for the data to be decompressed later without losing any information, ensuring the integrity of the blockchain history.
+
+Using lossless compression in the TLB would have some advantages:
+
+Reduced Storage Requirements: Lossless compression would still reduce the overall storage requirements for nodes, making it easier to run a node and participate in the network.
+
+Improved Efficiency: Compressed data would require less processing power and bandwidth to transmit and verify, leading to improved efficiency and scalability.
+
+Accessibility: Reducing the storage and computational requirements would make it more feasible for smaller devices or devices with limited resources to participate in the network, contributing to the decentralization of the system.
+
+Complete Transaction History: Maintaining the full transaction history through lossless compression would allow for better auditing, trust, and verification of the blockchain's integrity, addressing one of the concerns raised with data pruning.
+
+However, there are still potential challenges to consider:
+
+Complexity: Implementing lossless compression at different temporal levels could add complexity to the blockchain's implementation and maintenance, increasing the risk of bugs or vulnerabilities.
+
+Compression Efficiency: Lossless compression algorithms may not achieve the same level of compression as lossy algorithms (which allow for data loss), potentially limiting the storage space savings. The actual compression ratio would depend on the redundancy and structure of the data being compressed.
+
+Computational Overhead: Compression and decompression processes introduce additional computational overhead for nodes. The trade-off between storage savings and computational requirements would need to be carefully considered.
+
+In summary, implementing lossless compression in the Temporal Level Blockchain (TLB) could help improve storage efficiency and network accessibility, while maintaining the complete transaction history for auditing and trust purposes. However, the potential trade-offs between storage savings, computational overhead, and implementation complexity would need to be carefully evaluated to determine the feasibility and effectiveness of this approach.
+
+It's difficult to provide an exact compression ratio for the Bitcoin blockchain using lossless compression, as it depends on the specific compression algorithm used and the structure and redundancy of the data being compressed. However, we can provide a rough estimate based on some assumptions and previous research.
+
+In the case of the Bitcoin blockchain, the primary data types that can be compressed are transaction data and block headers. Some parts of the transaction data, such as public keys and signatures, are already compressed or have low redundancy, which makes them harder to compress further. Other parts, such as transaction inputs and outputs, could have higher redundancy and may be more suitable for compression.
+
+One study that analyzed blockchain data compression using a combination of lossless compression algorithms like Huffman coding, LZ77, and LZW reported compression ratios of around 1.45 to 1.60 for transaction data (source: https://arxiv.org/pdf/1902.06967.pdf). This means that the compressed data would be about 1.45 to 1.60 times smaller than the original data.
+
+However, this compression ratio is specific to the dataset used in the study and may not be directly applicable to the entire Bitcoin blockchain. Also, keep in mind that the compression ratio will vary depending on the data's redundancy and the efficiency of the compression algorithm used.
+
+Moreover, it's important to note that the Bitcoin blockchain is continually growing, and the compression ratio could change over time as the nature of the data and the number of transactions evolve.
+
+In conclusion, while it's challenging to provide a precise compression ratio for the Bitcoin blockchain using lossless compression, previous research suggests that a compression ratio of around 1.45 to 1.60 might be achievable for transaction data. However, this estimate may vary depending on the specific data being compressed and the efficiency of the compression algorithm used.
+
+There is some overhead and redundant data stored in the Bitcoin blockchain. The blockchain is designed to be a decentralized, transparent, and secure ledger, but this design comes with some inherent storage overhead and redundancy. Some examples of overhead and redundancy in the Bitcoin blockchain include:
+
+Transaction Data Redundancy:
+
+In Bitcoin, transaction inputs reference the outputs of previous transactions (UTXOs) by including the transaction ID and the index of the output. The transaction inputs also contain the unlocking script (scriptSig), which includes the signature and public key. Since multiple inputs can reference the same transaction ID or public key, there is some redundancy in the transaction data.
+
+Block Headers:
+
+Each block in the Bitcoin blockchain contains a block header, which includes metadata such as the previous block's hash, the Merkle tree root, a timestamp, the difficulty target, and a nonce. While this information is essential for maintaining the blockchain's integrity and security, it contributes to the storage overhead.
+
+Script Data:
+Bitcoin transactions use a scripting system that allows for a variety of conditions to be set for spending transaction outputs. Although the scripting system enables flexibility and programmability, it also increases the storage overhead.
+
+Unspent Transaction Outputs (UTXOs):
+
+UTXOs are the outputs of transactions that have not yet been spent. The entire UTXO set must be stored by full nodes to validate new transactions. While not technically redundant, the UTXO set contributes to the storage overhead of the Bitcoin blockchain.
+
+Witness Data (SegWit):
+
+With the introduction of Segregated Witness (SegWit), the witness data (i.e., transaction signatures) has been separated from the main transaction data. Although SegWit has improved transaction capacity and scalability, it still adds some storage overhead.
+
+These examples highlight some of the overhead and redundant data in the Bitcoin blockchain. However, it's important to note that many of these redundancies and overheads are necessary for maintaining the blockchain's security, decentralization, and transparency. Some optimizations and improvements have been proposed and implemented over time, such as data compression and pruning, to reduce storage requirements while preserving the essential features of the blockchain.
+
+The concept you've proposed is an interesting take on blockchain technology, addressing various challenges like the long transaction times, storage efficiency, and the lost private key problem. I'll provide an overview of the concept and suggest some possible improvements:
+
+Multi-temporal level blockchain: The blockchain operates on multiple temporal levels, with each level representing a different transaction speed and mining difficulty. The higher the temporal level, the slower the transaction speed and the higher the mining difficulty.
+
+Correlation between time-to-mine/difficulty and lossless compression: The information in higher temporal levels is compressed using lossless compression techniques, and this compressed data is correlated with mining difficulty and time-to-mine. As a result, data storage requirements are reduced without compromising the integrity of the information.
+
+Pruning of lower level chain parts: When a block is found in a higher temporal level, the corresponding lower level chain part is pruned, further optimizing storage requirements.
+
+Level 0 for fast transactions: A 0-level chain is used for lightning-like fast transactions, offering improved transaction speeds.
+
+Temporal address persistence: Address persistence is also temporal, and users must refresh their addresses with any transaction, or the funds associated with the address will be transferred to a mineable coin pool.
+
+Solving the lost private key problem: The requirement to refresh addresses through transactions helps address the lost private key problem by reallocating funds from inactive addresses to a mineable coin pool.
+
+Possible improvements:
+
+Adaptive temporal level management: Introduce adaptive mechanisms that automatically adjust the number of temporal levels and their associated parameters (transaction speed, mining difficulty) based on network conditions, ensuring optimal performance and resource usage.
+
+Enhanced security and privacy features: Implement advanced cryptographic techniques, such as zero-knowledge proofs, to enhance the security and privacy of transactions, especially in the fast 0-level chain.
+
+Incentives for address refreshing: Provide incentives for users to frequently refresh their addresses, ensuring that funds are more effectively redistributed to the mineable coin pool when private keys are lost.
+
+Flexible pruning strategies: Implement flexible pruning strategies that allow nodes to choose their desired level of data storage and participation in the network, balancing between full nodes and light nodes.
diff --git a/doc/concepts/proportional_address.txt b/doc/concepts/proportional_address.txt
new file mode 100644
index 00000000..5696fc16
--- /dev/null
+++ b/doc/concepts/proportional_address.txt
@@ -0,0 +1,114 @@
+mining hardware may have limitations on the maximum size of the coinbase, which can result in fewer addresses can be rewarded - is it possible to solve it using taproot addresses in the coinbase?
+
+Yes, it may be possible to address the issue of fewer addresses being rewarded due to limitations on the maximum size of the coinbase by using Taproot addresses in the coinbase.
+
+Taproot is a proposed Bitcoin soft fork that is expected to improve privacy, security, and efficiency by introducing a new signature scheme called Schnorr signatures. Taproot also includes a feature called "Pay to Taproot" (P2TR), which allows for more efficient and flexible use of Bitcoin addresses.
+
+By using Taproot addresses in the coinbase, miners can potentially reduce the amount of space required for the address data, as Taproot addresses are smaller than traditional Bitcoin addresses. This can free up more space in the coinbase for additional addresses, which can help to address the issue of fewer addresses being rewarded.
+
+It's worth noting, however, that Taproot is not yet fully implemented on the Bitcoin network, and its adoption is still subject to community consensus and activation. Additionally, not all mining software or hardware may be compatible with Taproot, so it may not be a viable solution for all miners.
+
+is it possible to determine proportion amount of funds to be distributed when creating taproot address?
+
+The Pay-to-Taproot (P2TR) address format does not by itself allow for a proportion amount of funds to be distributed between multiple parties. However, it is possible to use various transaction scripting techniques in combination with the P2TR address format to enable more complex spending conditions, such as distributing funds to multiple parties in different proportions.
+
+One such technique is known as a "multi-party taproot spend," which involves creating a Taproot output script that allows for multiple public keys to sign off on the spending of funds. Each public key can be associated with a specific proportion of the funds to be distributed, such that the final spending transaction will distribute the funds in the desired proportions.
+
+Another technique is known as a "Taproot covenant," which is a type of smart contract that allows for more complex spending conditions, such as time-based or event-based triggers, or the ability to change spending conditions after the fact.
+
+Both of these techniques involve creating more complex spending conditions that go beyond the basic P2TR address format, and typically require the use of specialized wallet software or programming skills to implement. As with any advanced Bitcoin transaction scripting technique, it is important to thoroughly test and verify the spending conditions before committing any funds to a P2TR address with more complex spending conditions.
+
+example of technique known as a "multi-party taproot spend," which involves creating a Taproot output script that allows for multiple public keys to sign off on the spending of funds. Each public key should be associated with a specific proportion of the funds to be distributed, such that the final spending transaction will distribute the funds in the desired proportions.
+
+Here is an example of how a multi-party taproot spend could be used to distribute funds between multiple parties in different proportions:
+
+Suppose that Alice, Bob, and Charlie want to create a Taproot address that will hold 10 BTC, and they want to distribute the funds in the following proportions:
+
+Alice: 40%
+Bob: 30%
+Charlie: 30%
+To achieve this, they can create a Taproot output script that requires signatures from all three parties in order to spend the funds, and which assigns specific weightings to each signature.
+
+The Taproot output script might look something like this:
+
+<2-of-3 multisig> OP_CHECKSIGVERIFY
+<0.4: Alice's public key> OP_CHECKSIGVERIFY
+<0.3: Bob's public key> OP_CHECKSIGVERIFY
+<0.3: Charlie's public key> OP_CHECKSIG
+
+
+In this script, the first line specifies a standard 2-of-3 multisignature requirement, which means that any two of the three parties can sign off on the spending of funds. This ensures that the funds can only be spent if all parties agree.
+
+The next three lines specify the public keys of each party, along with a weighting factor that represents the proportion of the funds that each party is entitled to. The weightings are expressed as a fraction of 1 BTC, so in this case Alice's public key has a weighting of 0.4 BTC, Bob's public key has a weighting of 0.3 BTC, and Charlie's public key has a weighting of 0.3 BTC. When the funds are spent, the output values for each public key are adjusted accordingly to reflect the desired proportions.
+
+To spend the funds from this address, all three parties must agree on the spending transaction and sign off with their respective public keys. The signature weightings ensure that the funds are distributed in the desired proportions.
+
+signature weightings explanations with examples
+
+In a Taproot output script that allows multiple parties to sign off on a spending transaction, signature weightings can be used to specify how much weight each signature contributes to the overall decision to spend the funds.
+
+Each signature is associated with a public key, and the signature weighting represents the proportion of the funds that the associated public key is entitled to. Signature weightings are expressed as a fraction of 1 BTC, and must add up to 1.0 BTC in total.
+
+For example, suppose that a Taproot output script requires two signatures to spend the funds, and the public keys associated with the signatures are:
+
+Public key A: 0.6 BTC
+Public key B: 0.4 BTC
+In this case, the signature weightings would be set as follows:
+
+<2-of-2 multisig> OP_CHECKSIGVERIFY
+<0.6: Public key A> OP_CHECKSIGVERIFY
+<0.4: Public key B> OP_CHECKSIG
+
+
+This script specifies a standard 2-of-2 multisignature requirement, which means that both Public key A and Public key B must sign off on the spending transaction. However, the signature weightings ensure that Public key A is entitled to 60% of the funds, while Public key B is entitled to 40% of the funds.
+
+When the funds are spent, the output values for each public key are adjusted accordingly to reflect the desired proportions. For example, if the total output value is 10 BTC, Public key A would receive 6 BTC, while Public key B would receive 4 BTC.
+
+Signature weightings can be used in more complex Taproot output scripts that involve multiple parties and/or more complex spending conditions. For example, signature weightings could be used to distribute funds between multiple parties in different proportions, or to create time-based spending conditions that change over time. However, it's important to thoroughly test and verify the spending conditions before committing any funds to a Taproot address with more complex spending conditions.
+
+malicious behaviour possibilities in the case above?
+
+The use of signature weightings to specify how much weight each signature contributes to the overall decision to spend the funds in a multi-party Taproot spend can introduce some potential malicious behavior possibilities. Here are a few examples:
+
+A party fails to sign off on the spending transaction: If one of the parties fails to sign off on the spending transaction, the funds may be locked up and unable to be spent. This could occur if one of the parties decides to act maliciously and refuses to sign the transaction, which could potentially harm the other parties.
+
+A party tries to manipulate the signature weightings: Since the signature weightings represent the proportion of the funds that each public key is entitled to, it is possible for one of the parties to try and manipulate the weightings in their favor. For example, they could try to increase their weighting or decrease the weighting of the other parties, which could potentially result in them receiving a larger share of the funds than they are entitled to.
+
+A party tries to steal funds from the other parties: Since the funds are distributed based on the signature weightings, it is possible for one of the parties to try and steal funds from the other parties. For example, they could try to sign the transaction multiple times with different public keys or try to modify the transaction in a way that benefits them.
+
+To mitigate these risks, it's important to carefully choose the parties involved in the multi-party Taproot spend and to ensure that all parties have a vested interest in ensuring that the funds are spent fairly and securely. It's also important to thoroughly test and verify the spending conditions before committing any funds to the multi-party Taproot address, and to ensure that all parties agree to the terms of the spending conditions in advance.
+
+generate taproot address step by step 1 of 5 multisig with random weighted funds distribution
+
+Here are the steps to generate a Taproot address for a 1-of-5 multisig with random weighted funds distribution:
+
+Choose five public keys: For a 1-of-5 multisig, you will need to choose five different public keys. These public keys can be generated using a Bitcoin wallet or other key generation tool.
+
+Determine the weightings: Assign a random weighting to each public key to determine the proportion of the funds each key will be entitled to when spending from the multisig address. The weightings should be expressed as a fraction of 1 BTC and should add up to 1.0 BTC in total. For example, you could randomly assign weightings of 0.2 BTC, 0.3 BTC, 0.1 BTC, 0.25 BTC, and 0.15 BTC to each public key.
+
+Create the Taproot output script: The Taproot output script will specify the conditions required to spend funds from the multisig address. In this case, you will need to create a script that requires only one of the five public keys to sign off on the spending transaction. The script should also include the weightings for each public key. Here is an example of what the script might look like:
+
+<1-of-5 multisig> OP_CHECKSIGVERIFY
+<0.2: Public key 1> OP_CHECKSIGVERIFY
+<0.3: Public key 2> OP_CHECKSIGVERIFY
+<0.1: Public key 3> OP_CHECKSIGVERIFY
+<0.25: Public key 4> OP_CHECKSIGVERIFY
+<0.15: Public key 5> OP_CHECKSIG
+
+
+Compute the Taproot address: Once you have the Taproot output script, you can compute the Taproot address by encoding the script using the Bech32 encoding scheme. This will result in an address that starts with "bc1p". You can use a tool such as Bitcoin Core or Electrum to compute the Taproot address.
+
+Share the address with the other parties: Once you have computed the Taproot address, you can share it with the other parties involved in the multisig. They can use this address to send funds to the multisig, and to sign off on spending transactions when needed. It's important to ensure that all parties agree to the terms of the multisig in advance, and that they are aware of the signature weightings and other spending conditions specified in the Taproot output script.
+
+in case one party initiates tx in 1 of n multisig taproot address - do other parties receive the funds or do they need to initiate tx by themselves?
+
+In a 1-of-n multisig Taproot address, only one of the n parties is required to sign off on a spending transaction to initiate the transaction. However, the funds will be distributed according to the signature weightings specified in the Taproot output script, regardless of which party initiates the transaction.
+
+For example, suppose that a 1-of-3 multisig Taproot address is created with the following public keys and signature weightings:
+
+Public key A: 0.4 BTC
+Public key B: 0.3 BTC
+Public key C: 0.3 BTC
+In this case, any one of the three parties can initiate a spending transaction by signing with their respective public key. However, the funds will be distributed according to the signature weightings, regardless of which party initiates the transaction. This means that if Party A initiates the transaction, they will receive 40% of the funds, while Party B and Party C will receive 30% each, as per the signature weightings specified in the Taproot output script.
+
+It's worth noting that in a multisig Taproot address, it's important for all parties to be aware of the spending conditions and signature weightings specified in the Taproot output script. This can help to ensure that all parties agree to the terms of the multisig and can participate in spending transactions as needed. If any party is not aware of the spending conditions, they may not be able to access the funds as intended.