And then later how to extract that data for use?

and how to increase that 80 bytes size?

and up to what size increasing possible?

Play Services framework is almost certainly a privacy hole in Android. And probably a security hole too.

I say "almost certainly" and "probably" because it's closed source; only Google know what Play Services is actually doing, as only they have the source. I do not recommend Android if you want privacy or security.

om perbedaannya apa antara Protocol DD dengan Mixer misal Bitcoin Mixer. Bukan kah prinsip kerja nya sama antara "Mixer" dan DD (Hidden).

tambahan om, berarti kl diterapkan apakah butuh Sync terlebih dahulu/gmna Om?.

Gan, sepertinya untuk bagian ini ada yang kurang. Kalau mengacu ke thread agan yang berbahasa Inggris seharusnya tertulis (kurang lebih):

CMIIW.

Apa manfaat Dandelion Secara Real bagi saya sebagai nubie di dunia crypto? Tentu selain manfaat bertambahnya wawasan.
Andai saja IP/nodes yang saya gunakan dilacak itu bukan masalah bagi saya.
Karena :

• Saya bukan seorang kriminal  
• Saya tidak memiliki aset yang cukup besar

Saya pikir, Dandelion dapat disalah-gunakan oleh para cyber crimes untuk mencegah segala tindak-tanduknya diketahui oleh pihak berwajib dan pemerintahan. Mohon dikoreksi jika saya salah.

Can you please elaborate on these "low cost manipulations" and how they are different from manipulating any low hashrate altcoin?
Clearly when the altcoin is young, the hashrate is presumably low and anyone can cheaply attack it. In the above setup you don't need to buy mining equipment to perform the attack, you spend bitcoins doing it.

Regarding the blockchain bloat argument, I tend to think that this type of questions are best left for the market to decide. "Bloat" is a moral objection saying "useless tx", but I think all tx are equally useful as long as the sender is willing to pay the fee and miner is willing to mine. Plus, "buying altcoin security" sounds like a legitimate use case to me. Also there is a flip side that by paying miners (instead of burning electricity) we are increasing Bitcoin miners' reward thus contributing to Bitcoin security.

To strengthen the MAD and prepare, I encourage people to be as ready and threatening as possible in case an immediate PoW change becomes necessary: for example, I've said several times (and I mean it) that if the Bitcoin Core devs fail to respond adequately to a miner attack, I'll propagate the necessary hardfork myself. But I oppose a preemptive PoW change unless there's some sort of new long-term solution.

This runs both ways though. With the majority hashrate presumably being located in China it may very well be that using increased block weight as a weapon would merely lead to an increased orphan rate in Europe and the Americas, further strengthening China's position.

I have this idea for a long time, a 2-way concurrent PoW algorithm with a 2-3 years smooth migration from ASICs to the alternate cpu/gpu PoW method e.g. ProgPoW. I'm thinking of starting with a 10:1 ratio in favor of sha2 ASICs and a gradual transition to 1:10 ratio against them.

Terkait yang nomor 2 dan 3, ane beranggapan bahwa privkey yang berada di komputer linux offline ane akan tetap aman meskipun dompet watch-only ane berada pada lingkungan yang sangat tidak aman, misalnya sering nonton b*kep, install software bajakan + crack, windows bajakan, virus, dll., karena yang berisiko dicuri hanya xpub. Meskipun xpub bisa dicuri oleh hacker, hacker tersebut hanya bisa melihat saldo ane saja kan?

Apakah ane harus khawatir akan privkey ane di komputer linux yang offline tersebut gan?

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

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):

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

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

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:
in numbers:
5 bits binary:

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

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

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

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

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

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

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.

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.

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:

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:
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:
 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
defined recursively as :
Observing that for n+1>i>0: 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:
For total elapsed time t during n epochs, we have:
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:
, 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:
Now we have proof because for the minimum time to be elapsed the power sequence definitively should be rewritten as:
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:

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 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.

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.

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

Type 2a: sha256 secret, length=94byte

Type 2b: sha256 secret, length=93byte

Type 3: ripemd160 secret, length=81byte

Type 4a: hash160 secret, length=86byte

Type 4b: hash160 secret, length=82byte

Type 5a: hash160 secret, length=81byte

Type 5b: hash160 secret, length=78byte

Type 6: hash160 secret, length=79byte

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

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

[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

Om yang dimaksud dengan ukuran transaksi lebih kecil apakah yang berhubungan dengan Weight Units (https://en.bitcoin.it/wiki/Weight_units)

Dimana pada legacy transaction, Weight = Ukuran transaksi (witness + non witness) x 4
Sedangkan pada segwit transaction, Weight = (witness size x 1) + (non witness size x 4)

Contoh : 1 segwit address dan 1 legacy address, masing-masing melakukan sebuah transaksi yang identik sehingga mempunyai ukuran transaksi (size) yang sama , yakni 250 bytes (130 bytes witness + 120 bytes non-witness). Maka pada saat Weight unit dihitung berdasarkan jenis address yang digunakan akan menghasilkan nilai yang tidak sama.

Weight pada Legacy Transaction = 250 bytes x 4 = 1000 bytes
Weight pada Segwit Transaction = (130 x 1) + ( 120 x 4) = 610 bytes


Mohon dikoreksi jika salah  

om, Newbie mau request heehe:
Lebih banyak bikin Tutorial Seputar Bitcoin(Technical) di Local dong om. Saya lebih senang dan cepat ngerti kalau belajar langsung dari org yg berpengalaman.

Well the funds went from coinbase to electrum to a gaming website.. I did some research and it told me that my transaction is signed and confirmed but not broadcasted...so i went to my wallet and pushed the broadcast button and still nothing is moving it seems...but whats strange is that i sent the coin in the same fashion as i allways do but now for some reason my status is local