ETFbitcoin's merit source application

[ABCbits]

Hi, i'm ETFbitcoin and i would like to apply to be a merit source, mainly because :
1. Not enough appreciation for newcomers who bring rough, but interesting/great idea for Bitcoin development
2. I'm out of sMerit, even if i only give 1-2 merit for a post/thread

Based on tool made by Piggy at https://bitcointalk.org/index.php?topic=4393868.0 & https://albertoit.github.io/Merit-Explorer-SQL/, i'm top 5 merit sender on "Development & Technical Discussion" boards, top 10 on "Bitcoin Technical Support" and top 50 overall¹ based on transaction count.
I'm from Indonesia, so i can participate in Bahasa Indonesia (Indonesian) boards and try to encourage more technical discussion in my board.

I'm not sure if i'm can categorized as somewhat established member, but i :
1. Sometimes help others with basic/common technical problem
2. I actively report spam on few board with stats 989 posts with 98% accuracy (936 good, 27 bad, 26 unhandled)

3. Starting try to make people aware with unpopular/upcoming Bitcoin technology such as Dandelion


Here are 10 posts/threads which i believe haven't received enough merit or/and could be implemented on Bitcoin development with further development. P.S. i'm fully aware some of the idea is controversial.

#1

Proof of Collaborative Work

A proposal for eliminating the necessity of pool mining in bitcoin and other PoW blockchains

Motivation
For bitcoin and the altcoins which are based on common PoW principles,  centralization of mining through using pools, is both inevitable and unfortunate and puts all the reasonings that support the security of PoW in a paradoxical, fragile situation.

A same problem does exist with PoS networks. Things can get even worse  there because of the fact that most PoS based systems enforce long run deposit strategies for miners that is highly discouraging for them to migrate from one pool to another because of the costs involved.

Satoshi Nakamoto's implementation of PoW that is the core of bitcoin client software is based on a winner-takes-all strategy which is the fundamental factor behind two critical flaws: mining variance and proximity premium which are the most important forces that participate in forming pooling pressure.

Until now, both mining variance and proximity premium are known to be unavoidable and hence pooling pressure is considered an inherent flaw for bitcoin and other PoW based currencies.

In this proposal, we are suggesting an alternative variant of PoW in which the traditional winner-takes-all is replaced with a collaborator-takes-share strategy.

The problem of solo mining becoming too risky and impractical for small mining facilities appeared in 2010, less than 2 years after bitcoin had been launched. It was the worst timing ever, although Satoshi Nakamoto made a comment on bitcointalk about first pool proposals,  it was among the latest posts Satoshi made and he just disappeared few days later from this forum, forever, without making a serious contribution to the subject.

This way, the confused community came out with an unbelievable solution for such a critical problem, a second layer centralized protocol, named pooling, boosted by greed and ignorance, supported by junior hackers who as usual missed the forest.

Bitcoin was just 2 years old when pooling age began and eventually dominated almost all the hashpower of the network.

A quick review of Slush thread in which Satoshi has made the above referenced reply, could reveal how immature and naive this solution was and has been discussed and how it has been adopted: In a rush with an obvious greed.
Nobody ever mentioned the possibility of an algorithm tweak to keep PoW decentralized. Instead everybody was talking about how practical was such a centralized service while the answer was more than obvious:
Yes! you can always do everything with a centralized service, don't bother investigating.  

Anyway, in the thread, one couldn't find any arguments about the centralization consequences or the possibility of alternative approaches including the core algorithm improvements

I think it is not fair. PoW is great and can easily be improved to eliminate such a paradoxically centralized second layer solution. This proposal, Proof of Collaborative Work (PoCW) is an example of inherent possibilities and capacities of PoW. I didn't find any similar proposal and it looks to be original but If there is a history, I'll be glad to be informed about.

The Idea is accepting and propagating works with hundreds of thousands times lower difficulties and accumulating them as a proof of work for a given transaction set, letting miners with a very low shares of hash power ( say of orders like 10^-6) to participate directly in the network and yet experience and monitor their performance on an hourly basis.



Imo, now, after almost a decade being passed, Moore law has done enough to make it feasible utilizing more bandwidth and storage resources and it seems to me kinda hypocritic to make arguments about 'poor miners' and pretending to be concerned about centralization threats and making excuses so for rejecting this very specific proposal that although increases the demand for such resources, can radically disrupt current situation with pools and centralized mining.

This proposal is mainly designed for bitcoin. For the sake of convenience and letting the readers to have a more specific perception of the idea, I have deliberately used constants instead of adjustable parameters.

Outlines

• An immediate but not practically feasible approach can be reducing blocktime (along with proportional reduction in block reward). Although this approach, as mentioned, can not be applied because of network propagation problems involved, but a very excellent consequence would be its immediate impact on the scalability problem if employed, we will use it partially (reducing blocktime to 1 minute compared to current 10 minutes period).
  
• As  mentioned earlier (and with all due respects to Core team), I don't take objections about the storage and network requirements implications and consequences of reducing blocktime as a serious criticism. We should not leave mining in hands of 5 mining pools to support a hypothetical poor miner/full node owner who can not afford installing a 1 terabyte HD in next 2 years!.
• Also note, blocktime reduction is not a necessary part of PoCW, the proposed algorithm, I'm just including it as one of my old ideas (adopted from another forum member who suggested it as an alternative to infamous block size debate and later has been developed a bit more by me) which I think deserves more investigation and discussion.
  
• PoCW uses a series of mining relevant data structures to be preserved on the blockchain or transmitted as network messages
  
  • Net Merkle Tree: It is an ordinary Merkle hash tree of transactions with the exception that its coinbase transaction shows no block reward (newly published coins) instead the miner charges all transaction fees to his account (supports SegWit)
  • Collaboration Share: it is  a completely new data structure composed of following fields:
    
    • 1- The root of a Net Merkle Tree
    • 2- Collaborating miner's wallet address
    • 3- A nonce
    • calculated difficulty using previous block hash padded with all previous fields, it is always assumed to be at least as hard as 0.0001 compared to current block difficulty
  • Coinbase Share: it is new too and is composed of
    
    • 1- A Collaborating miner's wallet address
    • 2- A nonce
    • 3- A computed difficulty score using the hash of
      • previous block's hash padded with
        
      • current block's merkle root, padded with
      • Collaborating miner's address padded with the nonce field
    • 4-  A reward amount field
  • Shared Coinbase Transaction: It is a list of Coinbase Shares  
    • First share's difficulty score field is fixed to be  2%
    • For each share difficulty score is at least as good as 0.0001
    • Sum of reward amount fields is equal to block reward and for each share is calculated proportional to its difficulty score
  • Prepared Block: It is an ordinary bitcoin block with some exceptions
    
    • 1- Its merkle root points to a  Net Merkle Tree
    • 2- It is fixed to yield a hash that is as difficult as target difficulty * 0.05
  • Finalization Block: It is an ordinary bitcoin block with some exceptions
    
    • 1- Its merkle root points to a  Net Merkle Tree
    • 2- It is fixed to yield a hash that is as difficult as target difficulty * 0.02
    • 3- It has a new field which is a pointer to (the hash of) a non empty Shared Coinbase Transaction
    • 4- The Shared CoinBase Transaction's sum of difficulty scores is greater than or equal to 0.95

• Mining process goes through 3 phases for each block:
  • Preparation Phase: It takes just few seconds for the miners to produce one or (barely) 2 or 3 Prepared Blocks typically. Note that the transaction fees are already transferred to miner's wallet through coinbase transaction committed to the Net Merkle Tree's root for each block.
  • Contribution Phase: Miners start picking one valid Prepared Block's Merkle root, according to their speculations (which become more accurate as new shares are submitted to the network) about it to get enough shares eventually, and producing/relaying valid Contribution Shares for it.
    As the sum of the difficulty scores for a given Prepared Block's Merkle root grows we expect an exponential convergence rate for the most popular Merkle root to be included in Contribution Shares.  
  • Finalization Phase: After the total scores approaches the 0.93 limit, rational Miners would begin to produce a Finalized block
• Verification process involves:
  • Checking both the hash of the finalized block and all of its Shared Coinbase Transaction items to satisfy network difficulty target cumulatively
  • Checking reward distribution in the shared coinbase transaction
  • Checking Merkle tree to be Net
• UTXO calculation is extended to include Shared Coinbase Transactions committed to finalized blocks on the blockchain as well
• Attacks/forks brief analysis:
  • Short range attacks/unintentional forks that try to change the Merkle root are as hard as they are in traditional PoW networks
  • Short range attacks/unintentional forks that preserve the Merkle root but try to change the Shared CoinBase Transaction has  zero side effects on the users (not the miners) and as of redistributing the shares in favor of the forking miner, they are poorly incentivized as gains won't go anything further than like %2-%10  redistribution ever.
    
  • Long Range attacks with a total rewrite agenda will fail just like Traditional PoW  
  • Long Range attacks with partial coinbase rewrite are again poorly incentivized and the costs won't be justified

Implementation

This is a radical improvement to classical PoW, I admit, but the costs involved are fair for the huge impacts and benefits. I have reviewed the bitcoin Core's code and found it totally feasible and practical form the sole programming perspective. Wallets could easily be upgraded to support the new algorithm as well,  but a series of more complicated issues, mostly political are extremely discouraging but it is just too soon to give up and go for a fresh start with a new coin, or just manage for an immature fork with little support, imo.

Before any further decisions, it would be of high value to have enough feedback from the community. Meanwhile I'll be busy coding canonical parts as a BIP for bitcoin blockchain, I think it takes like 2-3 weeks or even a bit more because I'm not part of the team and have to absorb a lot before producing anything useful, plus, I'm not full time, yet

I have examined the proposed algorithm's feasibility as much as I could, yet I can imagine there might be some flaws overlooked, and the readers are welcome to improve it. Philosophical comments questioning the whole idea of eliminating pools don't look to be constructive tho. Thank you.


Major Edits and Protocol Improvements:

• June 10, 2018 09:30 pm Inspired by a discussion with @ir.hn
  
  
  • A Prepared Block should be saved in the fullnodes for a long period of time enough to mitigate any cheating attempt to avoid Preparation Phase and using non-prepared, trivially generated Net Merkle Roots.  
    
    • Full nodes MAY respond to a query by peers asking for a block's respected Prepared Block if they have decided to save the required data long enough
      
    • For the latest 1000 blocks preserving such a data is mandatory.
    • For blocks with an accumulated difficulty harder than or equal to the respected network difficulty, it would be unnecessary to fulfil the above requirement.^*
    • Prepared Block and Preparation phase terms replaced the original Initiation Block and Initiation Phase terms respectively to avoid ambiguity
    Notes:
    ^* This is added to let miners with large enough hash powers choose not to participate in collaborative work.

• reserved for future upgrades
• July 3, 2018 02:20 pm inspired by discussions with @anunimint
  
  
  • A special  transaction was added to Shared CoinBase Transaction to guarantee/adjust proper reward for the finder of Prepared Block and some enhancements were made to include both block reward and transaction fees (partially) in the final calculations.
    
    • In Finalization Phase, miners should calculate a total reward for the miner of its respected Prepared Block as follows:  
      preparedBlockReward = blockReward *0.04 + totalTransactionFees *0.3
    • Shared Coin Base Transaction should include one input/output address-amount pair that adjusts the amount of reward assigned to the Prepared Block Miner in the ordinary coinbase transaction
    • All the calculations needed for calculating rewards assigned to the miners of finalized block and shares will be carried out on the sum of network block reward and 70% of transaction fees collected in transactions that are committed to Net Merkle Tree
    Note:
     This change is made to both guarantee a minimum reward for miners of Prepared Blocks and incentivize them for including more transactions with higher fees  

• reserved for future upgrades

Archive link : https://archive.fo/29FhF
Short comment/info : While there are many obstacle, removing pool from Bitcoin mining could prevent potential centralization/censorship by powerful multiple pools working together.


#2

Bitcoin wiki has a pretty good step-by-step explanation of how to go from a public key to a base58_encoded address which contains the values for each step of the way[1]. But unfortunately I could not find anything similar for Bech32_encoding. Additionally I found the reference implementations a bit confusing[2]! The information is out there[3] but I feel like having it step-by-step like "[1]" can make it a lot easier specially for developers. For example during unit testing I was getting a different address (bc1qp63uahgrxged4z5jswyt5dn5v3lzsem6c0qqhg8) for below public key and I wasn't sure where the bug was coming from, this visualization helped me [4] realize I was appending the version byte before converting the bits instead of after. So hopefully these steps can help someone like me looking for them.

How to create a Bech32 address from a public key:

1. Having a compressed[5] public key (0x02 or 0x03 followed by 32 byte X coordinate):

Code:

0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

2. Perform SHA-256 hashing on the public key:

Code:

0f715baf5d4c2ed329785cef29e562f73488c8a2bb9dbc5700b361d54b9b0554

3. Perform RIPEMD-160 hashing on the result of SHA-256:

Code:

751e76e8199196d454941c45d1b3a323f1433bd6

4. The result of step 3 is an array of 8-bit unsigned integers (base 2^8=256) and Bech32 encoding converts this to an array of 5-bit unsigned integers (base 2^5=32) so we "squash" the bytes to get:
in hex:

Code:

0e140f070d1a001912060b0d081504140311021d030c1d03040f1814060e1e16

in numbers:

Code:

14 20 15 07 13 26 00 25 18 06 11 13 08 21 04 20 03 17 02 29 03 12 29 03 04 15 24 20 06 14 30 22

5 bits binary:

Code:

01110 10100 01111 00111 01101 11010 00000 11001 10010 00110 01011 01101 01000 10101 00100 10100 00011 10001 00010 11101 00011 01100 11101 00011 00100 01111 11000 10100 00110 01110 11110 10110

5. Add the witness version byte in front of the step 4 result (current version is 0):

Code:

000e140f070d1a001912060b0d081504140311021d030c1d03040f1814060e1e16

6. Compute the checksum by using the data from step 5 and the H.R.P (bc for MainNet and tb for TestNet)

Code:

0c0709110b15

7. Append the checksum to result of step 5 (we now have an array of 5-bit integers):

Code:

000e140f070d1a001912060b0d081504140311021d030c1d03040f1814060e1e160c0709110b15

8. Map each value to its corresponding character in Bech32Chars (qpzry9x8gf2tvdw0s3jn54khce6mua7l) 00 -> q, 0e -> w,...

Code:

qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

9. A Bech32_encoded address consists of 3 parts: HRP + Separator + Data:

Code:

bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

The final result from step 9 is the same as example in BIP173[6]

References:
[1] https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses
[2] https://github.com/sipa/bech32
[3] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
[4] https://en.bitcoin.it/w/images/en/4/48/Address_map.jpg
[5] Only compressed public keys are allowed: https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#restrictions-on-public-key-type
[6] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#examples

Archive link : https://archive.fo/h1S2D
Short comment/info : While i haven't try make script based on this guide to test it, developer guide/wiki should able to use this guide


#3

Superspace: Scaling Bitcoin Beyond SegWit

Steve Kallisteiros
August 25, 2018

Abstract. SegWit, or Segregated Witness, a soft fork successfully activated mid-2017 on Bitcoin blockchain, provided among other benefits a backward-compatible increase to the block size limit, all while not introducing consensus breaking changes to Bitcoin protocol and not resulting in a hard fork network partitioning. The potential space increase is estimated at being close to 2 MB total for practical purposes. In this paper, the author argues that it is possible, using the same mechanism, increase the block size further up to any agreed-upon limit, while still providing the same security guarantees SegWit does.

Complete paper: https://files.zazzylabs.com/LNx2ud/superspace.pdf

===

Keep in mind, it's only the first draft. I would really appreciate your feedback.

Archive link : https://archive.fo/yZqOZ
Short comment/info : While it's over complicated and only increase maximum transaction in block, it could be used as last resort if hard-fork isn't option. Changing address prefixes from "bz" to "bc1p" (use next witness version)


#4

If you have ...
- The seed (set of words)
- The master private key (a long string starting with "xrpv")
Then you can get all the addresses that can ever exist with any path that you like as long as it comes after this extended key.

If you have ...
- Master public key (a long string starting with "xpub")
Then you can only get addresses that are not hardened

If you have ...
- Individual private key(s)
- Individual public key(s)
- Individual address(es)
Then you can't associate them together or find their master key.

If you have ...
- A master public key + a derived non-hardened private key
Then there may be a way for an attacker to find the master key.

Archive link : https://archive.fo/vfZEc
Short comment/info : A neat list to find all correlated address with/without private key from piece of information that you have.

#5

How far can possibly bitcoin blockchain height diverge from the ideal one- block-per-10-minutes measure?

Motivation
During a discussion with @gmaxwell about a hypothetical DoS vulnerability, in response to my suggestion for blacklisting peers that send block locators unreasonably large, he objected to my proposal by asserting that a loyal node may become maliciously bootstrapped and fooled to commit to a very long chain with trivial difficulty, so blocking it won't be helpful. I responded with a moderate version, ... but after further assessments, I realized that the whole situation is somewhat abnormal, the possibility of having honest nodes with an unreasonable perception of chain height.

In bitcoin, 10 minutes block time interval is not imposed synchronously nor integrally. Protocol adjusts the difficulty every 2016 blocks to keep the generation pace at 10 minutes target but a steady growth in network hash power makes it a possibility for chain height to exceed the ideal number based on 10 minutes generation rate. Actually maximum block height of the network as of this writing is #535461 while it is supposed to be ~504300 showing  a +6% divergence.

Not satisfied with the situation, I asked myself:
Why should we accept a proposed chain with an unreasonable longitude like 10 times or 1000 times longer than normal in the first place?
Why shouldn't we simply reject such proposals and shut down the peers who made them? Putting difficulty requirements aside, is it possible to have a chain orders of magnitude longer than normal?

In the malicious block locator scenario, a peer node, very commonly a spv, sends us a getheaders message with a payload of hundreds of thousands stupid hashes as block locator and instead of being rejected and banned we hopefully and exhaustively try to locate them one by one.

At first, @gmaxwell didn't believe it to be an attack vector because of the cpu bound nature of the processing involved but finally he made a pull request out of that discussion and it was committed to the source. Bitcoin core now puts a MAX_LOCATOR_SZ hardcoded to be equal to 101. So, we have block locator problem fixed now.

A block locator in bitcoin is a special data structure that spontaneously represents (partially) a node's interpretation of block headers in the chain. The spontaneous nature of block locator generation algorithm guarantees its length to be of O(log(n)) where n is the maximum block height in the chain, it is exactly 10+(log₂(n)) . For current block height of 535461 a legitimate block locator should carry a maximum of 29 hashes and a node sending 30 hashes is claiming a chain with 1,073,741,824 height which is almost twice longer and it would be 2 million times longer if block locator was holding 50 hashes. Yet we were worried about block locators holding thousands of hashes which represent chains with astronomical heights.

Although the issue is fixed now, the underlying theoretical base didn't get the attention it deserves: A boundary for the divergence of actual block chain's height  from what we could trivially calculate by dividing the minutes elapsed from an accepted checkpoint block's  timestamp by 10 (normal block interval).

At the time of this writing, the divergence is  6+% but we have no measure to consider 60%, 600% , 6,000,000,000% , ... divergence indexes infeasible, until now.

In  this article I'm trying to establish a mathematical framework for further research on this problem, by introducing a relation between hash power increase requirements for a specific divergence within a relatively large window of time.

I also found it useful to include a background section for interested readers, if you are familiar with the subjects, just skip this section.

Background

Difficulty adjustment: How bitcoin keeps the pace
Two rules are applied in bitcoin protocol for regulating the rate by which blocks are generated:
1- Increase/decrease difficulty every 2016 blocks by comparing the actual time elapsed with an expected 2 week period.
2- Don't Increase/decrease difficulty with a factor greater than 4.

The latter constraint is commonly overlooked because such a large retargeting is very unlikely to happen with the huge inertia of the currently installed hash power but as we are studying extreme conditions, the 4 times increase factor is of much importance.

Longest Chain Rule: How Bitcoin chooses between forks
In bitcoin and its clones, LRU is not interpreted naively as selecting the chain with biggest height as the main, instead it is defined as the chain with most work needed to generate it.
To calculate accumulative work done on each chain:
1-work for each block is calculated as:  floor(2^256 / (target + 1))
This is done in chain.cpp of bitcoin source code via GetBlockProof function:

Code:

arith_uint256 GetBlockProof(const CBlockIndex& block)
  122 {
  123     arith_uint256 bnTarget;
  124     bool fNegative;
  125     bool fOverflow;
  126     bnTarget.SetCompact(block.nBits, &fNegative, &fOverflow);
  127     if (fNegative || fOverflow || bnTarget == 0)
  128         return 0;
  129     // We need to compute 2**256 / (bnTarget+1), but we can't represent 2**256
  130     // as it's too large for an arith_uint256. However, as 2**256 is at least as large
  131     // as bnTarget+1, it is equal to ((2**256 - bnTarget - 1) / (bnTarget+1)) + 1,
  132     // or ~bnTarget / (bnTarget+1) + 1.
  133     return (~bnTarget / (bnTarget + 1)) + 1;
  134 }

2- During loading/adding a block to block index in memory, not only the block work is computed by calling the above function but also an accumulated chain work is aggregated in nChainWork with this ocde:

Code:

pindex->nChainWork = (pindex->pprev ? pindex->pprev->nChainWork : 0) + GetBlockProof(*pindex);

which is executed both in LoadBlockIndex and AddToBlockIndex.

The forks are compared based on nChainWork of BlockIndex item of their respective last block and once a chain is found heavier than current active chain a reorg will be performed mainly by updating UTXO and pointing to new chain as the active fork.

Between two difficulty adjustments, this the-most-difficult-chain-is-the-best-chain approach is identical to the-longest-chain-is-the-best-chain originally proposed by Satoshi but when we have to choose between two forks with at least one difficulty adjustment (typically in both forks) there is no guarantee for the results to be identical.

Block timestamp:How bitcoin keeps track of time
In bitcoin few rules apply to block time and current time. This is an important topic for the purpose of this article, defining an upper bound for the height of forks, because to impose such a boundary a node should eventually have a measure of  time and it is not simply its own system clock for obvious reasons.

1- Bitcoin defines a concept named network-adjusted time. It is defined to be the median of times reported by all the peers a node is connected to.

2- In any case network-adjusted time shouldn't offset node's local time more than 70 minutes.

3- Blocks should be marked with a timestamp greater than the median of previous 11  blocks and less than 2 hours after node's network-adjusted-time.

These constraints make it very hard for an adversary to manipulate block times and forging fake chains with fake difficulty and height which is our concern.


Abstract
The short-range difficulty adjustment policy of bitcoin causes a divergence of expected chain height (expected from ideal 10 minutes block time) because of increased hashpower during each epoch, we show that this divergence is exponentially difficult by proving a functional dependency between the ratios by which hash power and the divergence increase: F = (n/N)^n

To prove this relation, we primarily show the maximum divergence caused by introducing any amount of new hashpower to the network in a specific period of time is achieved when its distribution in epochs, is representable by a geometric  progress.

The 4 times maximum threshold imposed by difficulty adjustment algorithm of network is deliberately ignored to to avoid complicating the discussion. It is a justifiable simplifying assumption in the context of this article because a 4+ times per epoch increase in hashpower is not feasible  anyway, as we shortly discuss at the end of the article.

After proving the exponential dependency, we briefly illustrate and discuss its relevance to block locator size problem and other interesting potentials for dealing with similar problems generally.

Lemma:
Suppose at the end of a difficulty adjusting epoch we have already chosen as  a check point and has started at time t₀ we have calculated an average hashpower C as current network hashpower and begun to introduce Q as a relatively large hashpower in a period of time t, greater than or equal to 1 ideal difficulty adjustment epoch time T₀. The number of epochs n that occur in period [t₀, t₀+t], is at its maximum when Q is distributed in a way that the network hashrate would go through a geometrical progression With:
 

C_i = C*qⁱ

and we have Sum(C_i-C_i-1)=Q the increased hash power:

proof:
For a network state at the end of a given epoch that is in equilibrium with hashpower C and an arbitrary distribution of new power Q in n epochs we have the sequence

C, C*k₁, (C*k₁)*k₂, ...,  (C*k_i-1)*k_i, ..., (C*k_n-1)*k_n

defined recursively as :

C_i=C_i-1*k_i , C₀ = C

Observing that for n+1>i>0:

C_i=C*K₁*k₂*...*k_i=C*K₁k₂...*k_i

and in the end of application of power Q, we have a total hashpower of C+Q that is equal to the last term of the sequence

We have to prove for n+1>i>0 we have k₁=k₂=...=k_n=q for the n epochs to occur in the least possible actual time. For this, we note that in the end of each epoch the difficulty adjustment algorithm of bitcoin  (4 times limit temporarily being ignored) resets block generation pace to T₀ for future epochs, so in each epoch we have:

t_i= C_i/C_i-1 = (C*K₁k₂...k_i-1)/ (C*K₁k₂...k_i) = 1/k_i

For total elapsed time t during n epochs, we have:

T = T₀+T₀*1/k₁+T₀*1/k₂+... +T₀*1/k_n

Then:
T/T₀ =1+1/k₁+1/k₂+...+ 1/k_n
                        = 1+ f(k)/(k₁k₂...k_n-1k_n
                         = 1+f(k)/ ((C+Q)/C) )
Where f(k) is the sum of the sequence:

a_i = k₁k₂...k_n/k_i

, now we need to have this sum in its minimum. We first calculate the product of the terms as prod(a_i) = (k₁k₂...k_n)^n-1 = ((C+Q)/C)^n-1

where ((C+Q)/C) and n-1 are constants and the sum is minimum when a₁=a₂=...=a_n hence:

k₁=k₂=...=k_n

Now we have proof because for the minimum time to be elapsed the power sequence definitively should be rewritten as:

C_i = C_i-1*q = C₀*qⁱ

where C₀ = C and n+1>i>1  which is a sequence with geometric progression.

Theorem
Minimum hashpower growth factor F = (Q+C)/C needed for bitcoin blockchain^* to grow by an abnormal ratio n/N is determined by F=(n/N)^n
 

where C is current  hashpower of the network and Q is the absolute increase during a period of N*T₀.

^*Note: Bitcoin difficulty adjustment algorithm applies 4 times maximum threshold that is ignored deliberately for practical purposes

Proof
For a given F = (Q+C)/C Using the geometric progress lemma above we have:
t=T₀*n/q    ==> t/T₀=N=n/q ==> n/N = q
and
Q=C*(qⁿ-1) ==> (Q+C)/C=F=qⁿ
eliminating q:

F=(n/N)ⁿ

Discussion
The exponential relationship with the ratio of power increase and the ratio by which blockchain height diverges from normal N=t/T₀ is an important key to understand how impractical would be for a network like bitcoin with tens of thousands penta hash inertia (C) to diverge from its normal behavior in terms of longitude (chain height).
Let's have a graphical illustration of this function. We replace n with N+d where d is the number of abnormally added epochs. So F=((N+d)/N)^(n+d)

This form of the equation illustrates how F (relative hashpower) should grow to have N+d epochs instead of N, normal epochs.

figure 1: F/d diagram with various N values for F up to 30 times hashpower increase

Figure 1 illustrates how hard is achieving to 2-3 epochs divergence in 3,6,12,24 standard epoch times (two weeks long each) e.g for reaching to 3 epochs divergence within 24 weeks (12 epochs) even 40 times increase in network hashpower doesn't suffice.

Figure 2 (below) illustrates the same function in larger scale (1000 times hashpower increase). To diverge 6 epochs within 48 weeks we need 800 times increase in network hash power and within 24 weeks even with 1000 times increase divergence can't approach 6.

figure 2: F/d diagram with various N values for F up to 1000 times hashpower increase

This exponential behavior is very interesting and  potentially can be used as a basis for confronting malicious bootstrap attacks and issues like what we mentioned in the beginning of this article: bogus block locator issue.

As of the 4 times maximum threshold bitcoin uses for difficulty adjustment, obviously having a 4 times or more increase in each epoch for the network is infeasible specially when it comes to large windows of time, like 1-2 years that cause exponential network hash power increase up to infeasible quantities. Hence, ignoring that threshold practically won't affect this analysis.

Archive link : https://archive.fo/wzCf9
Short comment/info : An interesting analysis which shows actual mean block time is only 9.4 minutes, not 10 minutes mainly due to difficulty adjustment every 2 weeks. Simply calculate (timestamp of current block height - timestamp of block #1) / current block height if you doubt it.


#6

Hi together,

I'm an IT-student and writing a thesis about atomic swaps on BTC and BTC-like blockchains. For the thesis I decided to use BTC, LTC, BCH and DCR. These chains have a somehow similar codebase and the same scripting language (I'm not a professional, so there might be differences, but they are not that serious). And they all have a high enough marketcap to be relevant for atomic swaps.
So the goal of the thesis is to find hashed timelock contracts (HTLCs) and connect matching HTLCs from different chains to get the atomic swap. Therefore I first searched the web for anything on atomic swaps [1] and analyzed the input script of this transaction [2] to get a basic understanding how atomic swaps work and what they look like.
Then I wrote a go program to search for any script longer than simple P2PKH scripts. This gave me a list of many different scripts which I analyzed by hand to only take the HTLC ones. (Besides many multisig scripts, there is not much to find on BTC^^)
At this point I found multiple different types of HTLCs as listed below. Afterwards I crawled* BTC again saving all transactions with HTLC scripts, storing the interesting data like tx-id, input value, pubKeyHashes, the secrets and their hashes. I found about one hundret HTLCs on BTC so far.
I did the same for LTC and found about 400 HTLCs.
As far as I understood, the secrets of HTLCs have to be the same on both chains. So I wrote another go program to match the found HTLCs from BTC and LTC and got around 30 matches. The next steps would then be to crawl BCH and DCR and also match the HTLCs found there.

* Crawling in this case means that I start to search the blockchain backwards (to get the newest first, the beginning years are not that interesting in this case^^) until the beginning of 2017. So about 18 months. As stated in [1] the first known atomic swap between BTC and LTC was made on 19th April 2017 (or April 19th 2017 or 19.4.2017 or whatever you like). So there is not much sense in crawling any further.

My questions now are the following:

• Why are there so many different types? Is it compatibility with other chains? Or what?
• What are the differences between these types (besides length and hashing algorithm)?
• What are the advantages and disadvantages of these types?
• Why are there so many HTLCs on LTC and so few on BTC?
• Do you know other such HTLC scripts?
• Can you provide interesting resources on this topic?

I'm open to any constructive input and hope you have a few answers for me. Thank you in advance.

Type 1: sha256 secret, length=97byte

Code:

63 if
82 size
01 data1
20
88 equalverify
a8 sha256
20 data32
<secret_hash 32byte>
88 equalverify
76 dup
a9 hash160
14 data20
<pubkey_hash1 20byte>
67 else
04 data4
<timelock 4byte>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
68 endif
88 equalverify
ac checksig

Type 2a: sha256 secret, length=94byte

Code:

63 if
a8 sha256
20 data32
<secret_hash 32byte>
76 dup
a9 hash160
14 data20
<pubkey_hash1 20byte>
88 equalverify
ac checksig
67 else
04 data4
<timelock 4byte>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
88 equalverify
ac checksig
68 endif

Type 2b: sha256 secret, length=93byte

Code:

63 if
a8 sha256
20 data32
<secret_hash 32byte>
88 equalverify
76 dup
a9 hash160
14 data20
<pubkey_hash1 20byte>
67 else
04 data4
<timelock 4byte>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
68 endif
88 equalverify
ac checksig

Type 3: ripemd160 secret, length=81byte

Code:

63 if
a6 ripemd160
14 data20
<secret_hash 20byte>
88 equalverify
76 dup
a9 hash160
14 data20
<pubkey_hash1 20byte>
67 else
04 data4
<timelock 4byte>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
68 endif
88 equalverify
ac checksig

Type 4a: hash160 secret, length=86byte

Code:

63 if
03 data3
<timelock 3byte>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
88 equalverify
ac checksig
67 else
76 dup
a9 hash160
14 data20
<secret_hash 20byte>
88 equalverify
ad checksigverify
82 size
01 data1
21 -> 33
88 equalverify
a9 hash160
14 data20
<pubkey_hash1 20byte>
87 equal
68 endif

Type 4b: hash160 secret, length=82byte

Code:

63 if
03 data3
<timelock 3byte>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
88 equalverify
ac checksig
67 else
76 dup
a9 hash160
14 data20
<secret_hash 20byte>
88 equalverify
ad checksigverify
a9 hash160
14 data20
<pubkey_hash1 20byte>
87 equal
68 endif

Type 5a: hash160 secret, length=81byte

Code:

63 if
a9 hash160
14 data20
<secret_hash 20byte>
88 equalverify
76 dup
a9 hash160
14 data20
<pubkey_hash1 20byte>
67 else
04 data4
<timelock 4byte>
b2 checksequenceverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
68 endif
88 equalverify
ac checksig

Type 5b: hash160 secret, length=78byte

Code:

63 if
a9 hash160
14 data20
<secret_hash 20byte>
88 equalverify
76 dup
a9 hash160
14 data20
<pubkey_hash1 20byte>
67 else
01 data1
<timelock 1byte>
b2 checksequenceverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
68 endif
88 equalverify
ac checksig

Type 6: hash160 secret, length=79byte

Code:

63 if
54 <timelock op>
b1 checklocktimeverify
75 drop
76 dup
a9 hash160
14 data20
<pubkey_hash2 20byte>
88 equalverify
ac checksig
67 else
76 dup
a9 hash160
14 data20
<secret_hash 20byte>
88 equalverify
ad checksigverify
a9 hash160
14 data20
<pubkey_hash1 20byte>
87 equal
68 endif

Type 7: multiple ripemd160 secrets, length=80 + n*23byte

Code:

63 if
a6 ripemd160
14 data20
<secret_hash1 20byte>
88 equalverify
a6 ripemd160
14 data20
<secret_hash2 20byte>
...
88 equalverify
a6 ripemd160
14 data20
<secret_hash_n 20byte>
88 equalverify
21 data33
<signature1 33byte>
ac checksig
67 else
04 data4
<timelock 4byte>
b1 checklocktimeverify
75 drop
21 data33
<signature2 33byte>
ac checksig
68 endif

Type 8: multiple ripemd160 secrets, length=81 + n*23byte

Code:

74 depth
60 16
87 equal
63 if
a6 ripemd160
14 data20
<secret_hash1 20byte>
88 equalverify
a6 ripemd160
14 data20
<secret_hash2 20byte>
...
88 equalverify
a6 ripemd160
14 data20
<secret_hash15 20byte>
88 equalverify
21 data33
<signature1>
67 else
03 data3
<timelock 3byte>
b1 checklocktimeverify
75 drop
21 data33
<signature2>
68 endif
ac checksig

[1] http://www.cryptovibes.com/crypto-news/charlie-lees-atomic-swap-between-litecoin-and-bitcoin-was-a-success/
[2] https://insight.bitpay.com/tx/0bb5a53a9c7e84e2c45d6a46a7b72afc2feffb8826b9aeb3848699c6fd856480

Archive link : https://archive.fo/TXnno
Short comment/info : Interesting research since few people thought atomic-swaps could bring better privacy while atomic-swaps transaction on both coins have same secret which could lead to de-anonymization. He also release his thesis and script on below posts (https://bitcointalk.org/index.php?topic=4686439.msg45980025#msg45980025), even though the paper is in German and the script only works with their own daemon.

[1713426109]

1713426109

[1713426109]

1713426109

[1713426109]

1713426109

[1713426109]

1713426109

[Jrashid]

Thread link : https://bitcointalk.org/index.php?topic=4975639.msg44869693#msg44869693 (thread is locked, so i can't quote the post)

You can, you have to do it manually. There are several ways to quote a locked topic. You can find some here- https://bitcointalk.org/index.php?topic=4144474.0

Anyway, I support your application and wish theymos make you merit source. I like the posts you have quoted. Most of the application only quote some from meta (Quoting threads only from meta doesn't evaluate a person's ability, IMO.)

[suchmoon]

ETFbitcoin - do you speak Indonesian? I think you should mention that in your application. Being able to merit posts in more than one language is an advantage.

[TheBeardedBaby]

What I love from all those merit source application is reading the selected posts.
The best way to learn things, and here's quite a lot to read.

@OP, really like your application as you are more technically oriented. Crossing fingers for the best outcome in a short time.

[Husna QA]

#7
Thread link : https://bitcointalk.org/index.php?topic=4975639.msg44869693#msg44869693 (thread is locked, so i can't quote the post)
Archive link : https://archive.fo/1wX3v
Short comment/info : Sharing about Bitcoin's consensus from book by Jameson Lopp and compare it with fiat money

<snip>

Quote the post for reference

Our education system (or at least in the country where I'm from) is such that students learn very little about the principles and foundation of money. For example, nobody is teaching about the history of money, how it is created, how it works, why it works etc.

Maybe the principles of money are known to economics students, but it is easy to check that the general population knows very little about the concept of money. Given how important money is in everyone's life, this lack of knowledge is really symptomatic. So much so that one has to ask oneself if this is done deliberately to keep the masses ignorant of one of the most important aspects in their lives.

In the following, I want to share a couple of interesting points about how crypto compares to fiat money and where is the important difference. It is about 3 types of consensus inherent to Bitcoin that I learned from the book:

Bitcoin and Cryptocurrency Technologies, Chapter 7. Community, Politics, and Regulation

As the authors state, there are basically

3 types of consensus that any cryptocurrency functioning as money has to have:

• consensus about rules
• consensus about history
• consensus about value

1. The consensus about rules is basically a set of rules the majority agrees to follow.

Fiat money doesn't have this kind of consensus, because the government declares the rules by fiat. It may even change the rules along the way as it sees fit. Great example is the current hyperinflation disaster in Venezuela.

Cryptocurrencies do have this kind of consensus. In Bitcoin, we have a consensus about what makes a transaction valid, what makes a block valid, how new bitcoins are minted, what the total supply is, etc.

2. The consensus about history is actually about record keeping.

Like in the previous point, fiat money doesn't need this kind of consensus. It is enough to physically own money, or the banks can take care of your money and keep a record for you, so there is no need for this consensus.

Cryptocurrencies do need this kind of consensus. In Bitcoin, there has to be a consensus about the history of all valid transactions as well as about the current state of the public record.

3. The consensus about value is a mutual agreement about the value of money.

This consensus is the only consensus both fiat and crypto require in order to function properly. It is about people agreeing that the value of the money they are using will be there in the future.

This consensus equally applies to dollars, euros, and bitcoin. You have to believe that the money you hold will retain its value tomorrow. If many people believe in the same outcome, there is a consensus about value.

Interdependence of the 3 Types of Consensus

Bitcoin (and other cryptocurrencies) have to have all three types of consensus to work as they are supposed to. Moreover, these 3 types support one another. If everyone agrees about valid blocks and transactions, everyone agrees about the state of the public record. As a result, everyone agrees that the currency is not double spent and everyone agrees that the currency will be valuable in the future.

And the other way around: If everyone agrees that the currency will have value in the future, everyone will make sure the consensus rules are followed and the miners have incentive to obey the rules. Then, automatically there is a consensus about the state of the public record.

The ingenuity of Satoshi Nakamoto can be seen, among other things, in connecting these 3 consensus mechanisms and making them work so well in practice to support each other.

[mu_enrico]

Tech person want to be a merit source? You got my vote master!

[The Cryptovator]

weekly bump

Wondering how have I missed to reply and support your application . As far as I know theymos removed 1 merit source lately, current merit source is 119. Although I have applied for merit source but you are the best from me and you deserve it. I believe theymos will reconsider to assign more few merit source since he removed 1 from total. I know you have distributed your smerit fairly, so you deserve it.

Strongly support..

[The Cryptovator]

So how you put other topic like images on your thread like that i tried to do that but no way it is look like a link on my preview

This is off topic, your reply isn't appropriate with thread.
Try to use search button before you ask anything on forum. Once I have searched there is lot of post how to add image on post. This is the good explaination; https://bitcointalk.org/index.php?topic=4542012.0
Read it and try yourself.

You have made post with image previously; https://bitcointalk.org/index.php?topic=5057411.msg47270815#msg47270815

If I am not wrong then you are asking about how to quote others post. It's very simple. Just click on quote from uper left which post you want to add quote on your post. Then copy all and paste on your thread. If you don't need copy all then delete  which part you don't need.

[AleScamHole]

hey ETF,  you and the other paid shills should realize something.
ill tell you as the sources here seem to not want to ...

Theymos picked legendaries for sources recently with one major requirement: YOU CANT be bought, A.K.A, your NOT in a paid sig campaign

YOU, and many of you shills that want to be sources , ARE all in paid sig campaigns

you cant really be trusted to not sell merit, as you have PROVEN you can be bought, and will say w.e for a few pennies

sorry but thats just the truth

good luck!

[khaled0111]

ARE all in paid sig campaigns

You may be right about that.

you cant really be trusted to not sell merit, as you have PROVEN you can be bought, and will say w.e for a few pennies

There is nothing wrong in participating in sig campaigns (it is a legit way to earn some money), but you make it sound like he sold his soul to the devil.
OP is very active especially on the Development & Technical Discussion board, that's why I support his application.

[Coyster]

The requirements for applying to be a merit source happens to be that such individual must at least be somewhat of a reputable member on the forum,with at least some positive trusts and no negative trust(it will help increase ones chances),and also to garner from around the forum 10 posts that haven't been merited,or haven't gotten the real number of merits it actually deserves...

There is no tag as to a paid signature campaign,as it's absolutely acceptable on the forum,and being on one doesn't make one dishonest,or less trustworthy...
It's a honest way to earn from the forum, just that most noobs abuse it by spamming the forum with tons of alt accounts,and definitely the OP isn't one of them...

Good luck mate!!!

[elastiman]

I support him to be a merit source we do not have enough merit sources only 119? and how many members are in bitcointalk like 3 millions maybe?

[JusticeForYou]

@ETFbitcoin your example posts show that you really have technical views and also tend to roll over in the Technical sections of the forum which truly lacks merit interactions.

Just a Bump from my side.

[Onuohakk]

I might not be a technical person myself but I must say I was interested in you wanting to encourage your local board that is quite selfless of you I think some local board are lacking behind in terms of merit allocation as to compare with the English board.
I hope your application is well looked into in as much as you do not have a positive trust I am glad you don't have a negative trust either.
Well wish you luck

[The Sceptical Chymist]

@ETFbitcoin your example posts show that you really have technical views and also tend to roll over in the Technical sections of the forum which truly lacks merit interactions.

I don't know for certain if that's true, but I suspect it is.  I do think that there ought to be broad merit source coverage of as many sections of the forum as possible, and I'm pretty sure there are sections where good posts are being made and going un-merited. 

I support ETFbitcoin's application anyway, since he's been a solid member of the forum.  If he can cover an underrepresented area of bitcointalk (as far as merit sources go), then all the better.  As I've said in other recent application threads, however, I'm not sure if Theymos is actively looking for new merit sources after adding the 36 new ones back in September.  Hopefully he is, because I do think we need more.

and how many members are in bitcointalk like 3 millions maybe?

Yeah, but there aren't that many who are actually active posters.  Many are inactive accounts and a lot of them are brand new ones that have never made posts.  I don't know how many actual members post day-to-day, though I'm sure that figure is available.  Whatever it is, I think the number of merit sources ought to be closer to 200-250 than however many we have now. 

On the other hand, there are so many shitposts being made that I swear it's getting even harder to find posts worthy of merit.  It's not supposed to be easy for newbies to rank up anymore, but I think it might be taking the decent posters a bit too long to rank up.  In any case, good luck to ETFbitcoin.  Hope Theymos sees this and makes you a merit source.

[mikeywith]

I see ETFbitcoin being active and giving some merits on the mining board, also looked at a few random merits sent and I think he deserves to be a merit source, mainly due to his participation on the tech side of the forum. good luck

[bones261]

Congratulations. You deserve it.

[The Sceptical Chymist]

Now i'm merit source, thank you everyone for the support

Props to you.  You were the other one along with o_e_l_e_o that I was wondering about.  You two seemed to have the strongest applications as of late. 

Didn't think Theymos was going to tweak anything so soon, or add any more merit sources this soon but he's surprised me yet again.  Pleasantly.  Good luck, bro.

[manfredmann]

Tech person want to be a merit source? You got my vote master!

The guy really deserve it if he was approved. I have been also following this guys post and relatively mosy of them where good and you can learn from it. Just wishing he gets what he want and share some love with his smerits to other good guys also. BTW, the post he presented for proof or pre requisites in applying a source merit was totally a very good find.

[S_Therapist]

The guy really deserve it if he was approved. I have been also following this guys post and relatively mosy of them where good and you can learn from it. Just wishing he gets what he want and share some love with his smerits to other good guys also. BTW, the post he presented for proof or pre requisites in applying a source merit was totally a very good find.

If you read couple of posts from this post, you would know that ETFbitcoin is now officially a merit source. Joining in a discussion from only OP isn't good at all. You should check what other people are saying. You should read all the replies and only then you will be able to create a merit worthy post.

Here-

Now i'm merit source, thank you everyone for the support