[white paper] Purely P2P Crypto-Currency With Finite Mini-Blockchain

[aaaxn]

I am very interested in this mini-blockchain idea, and the other ideas in the thread. This could be a very major step forward for crypto-currency.

What steps are being taken to put this into code? What help or resources are needed? Is there any other thread I should be following to keep abreast of this?

Project implementation thread can be found at link below. As of yet no developers have come forward to help so if you can help in any way or know anyone who can, that would be helpful.

https://bitcointalk.org/index.php?topic=215936.0

Post this link in this thread first post. I'd like to contribute but didn't even know new thread was started.

[1713972357]

1713972357

[1713972357]

1713972357

[1713972357]

1713972357

[1713972357]

1713972357

[bitfreak!]

I am very interested in this mini-blockchain idea, and the other ideas in the thread. This could be a very major step forward for crypto-currency.

What steps are being taken to put this into code? What help or resources are needed? Is there any other thread I should be following to keep abreast of this?

Project implementation thread can be found at link below. As of yet no developers have come forward to help so if you can help in any way or know anyone who can, that would be helpful.

https://bitcointalk.org/index.php?topic=215936.0

Post this link in this thread first post. I'd like to contribute but didn't even know new thread was started.

Good idea, I will do that now. I meant to send you a message with a link to that thread but I must have forgotten about it. At least you know now.

[stellarman]

I am very interested in this mini-blockchain idea, and the other ideas in the thread. This could be a very major step forward for crypto-currency.

What steps are being taken to put this into code? What help or resources are needed? Is there any other thread I should be following to keep abreast of this?

Project implementation thread can be found at link below. As of yet no developers have come forward to help so if you can help in any way or know anyone who can, that would be helpful.

https://bitcointalk.org/index.php?topic=215936.0

Thanks. I am now following that thread as well.

I am not a coder myself, but am the software Product Manager at the company where I work. So, I might be able to help coordinate. And I am willing to contribute at least some to the funding. But, that still leaves a pressing need for some strong coders to help move this forward. I will be talking to a couple of programmers I know, who may not be strong in crypto (yet), but who may be interested. That's the best I can do at the moment.

[Meni Rosenfeld]

The paper says each bitcoin is 10M satoshis, the correct number is 100M.

Let's consider some new awesome possibilities that arises when we get rid of bitcoin scripts and adopt account tree, so this thread won't die off.

Cryptocurrencies are almost useless without scripts.

This idea will obviously need to make use of P2SH; the account addresses will be hashes of scripts rather than public keys, and the defining script will be given in the spending transaction.

[aaaxn]

Cryptocurrencies are almost useless without scripts.

Any specifics? How many percent of current bitcoin transactions are something OTHER than simple pay to address? Is bitcoin useless because of it?

[Meni Rosenfeld]

Cryptocurrencies are almost useless without scripts.

Any specifics? How many percent of current bitcoin transactions are something OTHER than simple pay to address? Is bitcoin useless because of it?

Close to 0%, but currently securing bitcoins is very hard and the system isn't very scalable. You need multisig and more sophisticated scripts to keep bitcoins secure, you need payment channels to allow trustless off-chain payments, etc.

And, yes, I currently enjoy very little utility from Bitcoin in its intended purpose. It will be more useful when it is more widespread, but that will happen only if it's scalable and easy to secure.

[aaaxn]

Close to 0%, but currently securing bitcoins is very hard and the system isn't very scalable. You need multisig and more sophisticated scripts to keep bitcoins secure, you need payment channels to allow trustless off-chain payments, etc.

And, yes, I currently enjoy very little utility from Bitcoin in its intended purpose. It will be more useful when it is more widespread, but that will happen only if it's scalable and easy to secure.

You don't need scripts to do multi-sig accounts. You can just define such account type. And defining account types in code is more powerful than scripts because you have access to full blockchain state. You can example make accounts with withdraw limits per day. And please do not say anything about scripts flexibility because in reality every use case of script needs to be enabled by developers and accepted by miners. They could as well just write code handling new account type.

[Meni Rosenfeld]

Close to 0%, but currently securing bitcoins is very hard and the system isn't very scalable. You need multisig and more sophisticated scripts to keep bitcoins secure, you need payment channels to allow trustless off-chain payments, etc.

And, yes, I currently enjoy very little utility from Bitcoin in its intended purpose. It will be more useful when it is more widespread, but that will happen only if it's scalable and easy to secure.

You don't need scripts to do multi-sig accounts. You can just define such account type. And defining account types in code is more powerful than scripts because you have access to current network state. You can example make accounts with withdraw limits per day. And please do not say anything about scripts flexibility because in reality every use case of script needs to be enabled by developers and accepted by miners. They could as well just write code handling new account type.

Ok, I have a better idea now of what it is you are suggesting, you could hard-code the more commonly needed functionality. However, I will say that scripts are more flexible, and furthermore that we should move away from having to approve each script individually.

[aaaxn]

Ok, I have a better idea now of what it is you are suggesting, you could hard-code the more commonly needed functionality. However, I will say that scripts are more flexible, and furthermore that we should move away from having to approve each script individually.

I don't think scripting will be enabled ever. It is too risky and would probably bloat blockchain too much. If however it can be done and will prove to be useful nothing stops us from creating new account type with spending script attached (or its hash). It's a win-win.

[AnonyMint]

Now attack scenario. Suppose there is attacker with more than 50% of hashing power. He takes hash of current best block N and tries generating a next one but instead of using real account database he just create new one in which he holds all coins. If he is able to keep this chain in front of original one for as long as original network looses block N contents he can reveal his chain and it would look perfectly valid for all nodes because they lost track of how account database looked on block N.

It looks like algorithm presented in this paper is only as secure as mini blockchain is secure and if attacker could sustain 51% hashing power for as long as mini blockchain cycle completes it could cause much more severe problems than in bitcoin, because attacker could rewrite entire account balances database and not just make some double spends.

Essentially Bitcoin has the same risk for clients that don't download the entire transaction history, and the solution is the same which is to ask the peers that have the relevant transaction history to prove which chain is not valid.

[AnonyMint]

The following is helpful discussion, but appears to me to be somewhat wrong:

http://bitfreak.info/mbc-wiki/index.php?title=Secure_0-confirmation_transactions

Here is what I have written thus far on this:

1-Confirmation Transactions

To successful double-spend or unspend, the theft transaction needs to be placed in a block that will become orphaned and the winning chain must be obscured from the merchant accepting the 1-confirmation transaction. There is no reliable way to accomplish this attack on every attempt without 50+% of the PoW resources. So for small ticket items where rare theft is tolerable, the merchant can accept 1-confirmation transactions. An improvement would be to punish any transaction which overdraws the sender's balance, by charging a percentage fine of the balance that is not given to anyone (don't want to reward miners for this beyond the transaction fee which must be less than the fine, since the attacker may be the miner). When the attack succeeds, there won't be any balance to punish. However, since the attack doesn't succeed every time, then the punishment would further discourage the attack.

[AnonyMint]

Note there is some new discussion in the implementation thread for this proposed coin:

https://bitcointalk.org/index.php?topic=286536.msg3342106#msg3342106

Bitfreak!, aaaxn, bytemaster et. al have convinced me that the community can design better than I can alone. Although I independently realized most of the things they also realized, there are nuances and details which the group has hashed out better than one person could alone. Thus I would like to open the design to the community of my altcoin, if we can agree.

There is another thread:

https://bitcointalk.org/index.php?topic=215936.0

I would like to see if we can discuss now which additional features are desirable and the design of such features we agree on beyond what has already been agreed upon and designed for this proposed altcoin.

I do agree that we should not overly complicate the initial design. Yet I disagree that we should only do a proof-of-concept of only one feature improvement over Bitcoin, because the effort required really demands going all the way to marketing a new coin and hard forks are very difficult so we only get one chance to put the features that we want into the coin. We should choose very judiciously the features which are extremely important.

We will need to nail down whether the ideas presented by aaaxn on how to do scripting-like features (multisig, etc) have to be incorporated from launch or if they can be added later without requiring a hard fork.

I did two polls which you can find from the following post:

https://bitcointalk.org/index.php?topic=279340.msg3346774#msg3346774

Block chain scaling is the #2 most requested feature, yet anonymity is #1 by far.

So let me start by jumping into my current thoughts on anonymity.

First of all, I have just recently abandoned mixers entirely as an anonymity solution (which was a shocking, unexpected realization for me too):

https://bitcointalk.org/index.php?topic=279249.msg3343568#msg3343568

I quote below what I have written down thus far in a whitepaper I was composing.

Anonymity

All known existing solutions for anonymizing the IP address, e.g. Tor, I2P darknet, anoncoin, etc., are not secure against timing attacks.[13] Assuming that problem is solved, then a remaining problem is how to delink spends from other spends. Paradigms which mix coins from numerous identities only provide plausible deniability since the hashes of the addresses of all the input coins are in the public record, and the probability of deniability is reduced by the percentage of inputs provided by an attacker or participants who leak their identity to their outputs. Decentralized mixers are difficult to design to be resistant to DoS attackers, although Zerocoin might be a solution.[14] It is possible that some vendors might not accept coins that originated from mixers due to "know your customer" anti-money laundering concerns.[15] Thus the most robust solution is to obtain coins anonymously with small values. This can be done by mining coins, or anonymously receiving payment in coins. Unless the attacker has a list of all the customers, by giving a unique destination address to each customer then it is impossible to correlate that these coins belong to the same vendor. If coins can be anonymously converted into cash or mining hardware, they can be anonymized.

[13] https://bitcointalk.org/index.php?topic=279249.msg3109291#msg3109291
[14] https://bitcointalk.org/index.php?topic=279249.0
[15] https://bitcointalk.org/index.php?topic=175156.msg2318052#msg2318052

So it appears to me that in order to have anonymity of IP addresses, every peer on the network has to be forced to communicate via a mix-net otherwise those miners who anonymize their IP are at a disadvantage timing-wise and all peers who anonymize their IP are tainted by those who don't. And that mix-net can't be low-latency so that timing attacks can be prevented. And unlike Tor and more like I2P darknet, the number of hops must be more than 3 and all nodes must participate in the routing (not just dedicated nodes). Preventing DoS is an open issue.

Timing attacks are possible when nodes route anonymized (i.e. encrypted) onion layers in the order and near-time they receive them, thus making it possible to detect the flow not based on content, but based on the relative timing that packets are routed.

It seems to me that we will need to build this into the coin if we want any hope of strong (trustable) anonymity.

Note privacy and anonymity are not always inseparable. For example, if Satoshi spent all his coins today, we would know with high probability it is him (i.e. he lost his privacy), but we wouldn't necessarily know who he is (he didn't lose his anonymity). Yet spending that many coins without revealing identity is nearly impossible, thus often the two concepts are inseparable.

Society demands privacy, but it often frowns on anonymity, i.e. our bank doesn't tell the world our purchases of pornography (privacy), but the authorities have access to this data via warrant (not perfect anonymity).

Perhaps we can construct a sound argument that we don't have privacy at all without the anonymity of IP address. Can anyone help me with that logic?

P.S. note that mining on PCs could become realistic again with the mini-blockchain and a high DRAM requirement for the PoW which can't be defeated by GPUs (I have a rough sketch already).

[AnonyMint]

Let's talk about debasement. It ends in Bitcoin 2033 and my deep understanding of money indicates that will doom Bitcoin long-term.

I want to try to educate and convince you that perpetual debasement is good and we really need it. This is a difficult shift in mindset for many people, because they've adopted some concepts which are not correct. I explained this more exhaustively but spread out across dozens of  past posts and will have to go dig up all my prior points and condense at some point. I have studied this issue for several years, and I am somewhat mathematical. If you spend enough time on it and are rational, you will come to the same conclusion; it is not a subjective conclusion.

Let me take a stab now at summarizing although I am likely to miss some key points without a more exhaustive review of all my past posts on this issue.

1. The debasement of mined (above ground) gold never stops, i.e. it is roughly 1 - 3% per year throughout history.

2. Debasement funds mining, and mining is essential to a coin's PoW security. Transaction fees can also fund, but debasement consistently funds on every block.

3. The most reliable way to obtain coins anonymously is mining. Debasement provides it in small chunks and my realization on anonymity (see my prior post) is we need small chunks to delink spends. Transactions fees destroy the small chunks if they are too large, thus I would prefer they are scaled and set by the protocol.

4. I found data since the 1800s for the USA that showed that wages and money supply both increased nominally roughly 5.6% per year compounded. The point is that monetary inflation is not bad because it feeds back to workers. What is bad is when a central authority controls the timing and amount of debasement, because they can structure so that certain opaque (hidden) entities gain more. With a transparent (open and known a priori) protocol based schedule for debasement, no one can benefit in an opaque manner by manipulating the timing and rate.

5. Perpetual debasement continually diminishes the premine, and realistically you don't get dedicated serious developers without a premine. I know bytemaster's organization is attempting to profit without a premine, but before we can cite that as an exception they must prove it, and Litecoin isn't a significant deviation from Bitcoin.

6. Without debasement, capital has less incentive to invest, as it can gain value via deflation by being held unproductively. Note if everyone holds their capital unproductive, then deflation spirals into a dark age which is very difficult (as in an average of 600 years with several historic cases) to get out of, because those with capital invest in armies to protect their capital not in production, e.g. feudalism. This is why gold is never a sustainable money throughout history, because society fights against capitalists who want to hoard capital instead of risk investment in production. Without debasement, the value of your house can't go up, if wages don't go up, and the investor can't get return on his investment, nor can the interest rate for loans be paid. How can you pay an increase if there is not an increase in the money supply. I realize that capital from losers can end up with the winners, yet one issue is consistent winners aggregate too much capital and can't maintain growth without doing Olsen capture[2]  of the system (because smaller things grow faster, e.g. saplings grow to mature trees, but not to the moon or the guy selling cold mineral water on a hot day can double or triple his investment in a day, but Warren Buffett could never do that with his $billions in a day). And then note that it is impossible to eliminate the desire of humans to use debt, yet debt can't be serviced without debasement since the losers are always backstopped by insurance and thus society as a whole. So the huge-scale capitalists always move into usury finance to maintain portfolio value growth. If instead we take away that option with deflation, then they either defeat us or turn to protecting their capital into a dark age, because their size is too large to always win with investment. So we've got to issue money that is compatible with human nature, and thus there must be perpetual debasement. There is no panacea that can come from ending debasement.

[2] Eric S. Raymond, "Some Iron Laws of Political Economics", Armed and Dangerous blog

So pleeeeassssseeee throw away that "goldbug" nonsense. The economy can't be a constant. It has to have a business cycle wave function of expansion and contraction, because of the fact that nothing in this world is perfectly frictionless and inertia is required else we wouldn't exist. I suggest reading my blog to gain some insights on this on a more abstract level especially The Universe:

http://unheresy.com/

7. Absence of debasement steals from those who produce and gives to those who sit on their capital unproductively. The increased production along with deflation rewards the miser with increased goods and services for hoarding and not investing. Yet we shouldn't entirely diminish idle savings overnight, because of the lesson of saving during the 7 productive years to sustain during the 7 lean years (Biblical story that reflects the reality of the wave function of The Universe). So we need a balance between no debasement and infinite debasement. Gold appears to be a bit too low, as even the natural human population growth rate is probably more than 2% (at the peak of the western debt bubble birth rates have collapsed with 40 million abortions per year and contraception from age 15, but historically the long skirts come back, marriage comes back, and reproduction returns when the debt bubbles collapse):

http://armstrongeconomics.com/2013/10/01/what-socialism-destroyed-govt-shutdown/

What must be stated openly is that the “New Deal” of Roosevelt has actually destroyed the very fabric that formed society that nobody wants to look at no less discuss.

For centuries, people had children to provide for their own retirement. Family units were the social structure. The sad part of socialism is how this family unit was fundamentally destroyed by socialism. Once social security was created, children were relieved of the burden of taking care of their parents – that became government’s job. People were told to save conservatively. They salted away money often in government bonds. Now government has been so fiscally irresponsible, they have to keep interest rates low not to stimulate the economy, but to control their own perpetual deficits.

The retired can no longer live off of their savings. Their home has proven to be anything other than the savings for retirement as annual property taxes alone approach the cost of the house in the 1950s. Pensions are insolvent and taxes only rise perpetually. It now takes two incomes for a family to survive. The New Deal has failed on every level.

P.S. The following is wild conjecture (not scientific enough) and shouldn't be taken very seriously. 2033 is the target year for the current global financial crisis to bottom and a renewal to begin, i.e. it would correlate with roughly the 1950s and the end of the world wars (on the 78 year repeating crisis cycle that can be traced back throughout all of history, i.e. 3 x 26 reproductive maturity generations). Is it just a coincidence that Satoshi chose that year to end debasement. We will probably never know. I am not encouraging extended discussion on this speculative conjecture (the P.S.). I just wanted to note the (somewhat unscientific) correlation. Correlation is not always meaningful.

Here is a link to some conjecture about what may happen between now and 2033:

https://bitcointalk.org/index.php?topic=279771.msg3340053#msg3340053

[AnonyMint]

Incomplete, rough draft of whitepaper I was composing...

Bitcoin Proof-of-work and Block Chain

In the seminal Bitcoin whitepaper[1] Satoshi somewhat obscured the essential weakness of financial institutions that they are captured by the asymmetrical vested interests of society described by Olsen[2] which is to the detriment of individual empowerment. Ultimately it is the lack of anonymity of the institutions and transactions which allows society to identify them and thus the asymmetrical vested interests to capture them. Instead Satoshi emphasized transaction reversibility as the problem, but which is rather a sometimes desireable feature that is not necessarily incompatible with anonymity in all cases.

Financial transactions must be recorded in a public or private ledger trusted by both the spender and the recipient, otherwise funds could be unspent or double-spent to a plurality of recipients. To provide a ledger that can't be captured, Satoshi described a proof-of-work (PoW) scheme where transaction peers communicating over the network compete to be the first to solve a computational puzzle which is unique for each block of transactions added to a public ledger. The security of this ledger against double-spends has three (3) essential requirements.

1. The computational puzzle can't be preimaged, i.e. nothing can be known about solving the puzzle until the prior block's puzzle is solved.

2. Without at least 50% of the aggregate computational power of all transaction peers, it is not possible to create a modified chain of blocks starting from any present or past block, which would contain more blocks than the block chain controlled by the remaining cooperating peers. Thus the longer chain is trusted.

3. The block chain is cryptographically linked in forward order, such that the historical proof-of-work and transactions can be independently verified at any time in the future. Thus the transaction peers may leave and rejoin the network at will without need for a trusted centralized storage.

Note security point #1 eliminates from consideration PoW schemes in which the puzzle is some real-world computational work because the puzzles are known a priori and are thus pre-imageable. Non-PoW voting and membership schemes disqualify because the ordering of designation of authority (to decide which transactions are in each block) to transaction peers is pre-imageable, or requires peers trusted by reputation which is centralizing on a slippery slope towards Olsen capture.

Bitcoin's blockchain stores sender(s) signed hashes of the transaction data, which includes the nonce transaction id and hash(es) of the destination public key(s). The monetary value of each hash of the public key is computed from the transactions history. Satoshi suggested pruning historical transactions from the blockchain which are no longer relevant to computation and security of the set of unspent coins (a.k.a. Unspent Transaction Output Set or UTXO).[3] Note hashes of destination public keys[4] obscure the asymmetric public key cryptography from attempted attacks until a spend transaction is sent from the public key. However, this is not sufficient to assure with the same confidence as for symmetric key cryptography that an attack can't occur once the spend transaction is sent.[5]

Mini-Block Chain

The pruned Merkel transaction tree is not the most compact data structure possible, because an additional hash must be stored for each branch of the tree to each unpruned transaction[3], sender signature(s) are stored for each unspent coin, and transactions can't be pruned until all outputs are spent.[6] Note these transaction peers resource requirements only apply to startup download bandwidth, startup verification DRAM, and ongoing disk space, because the UXTO balances and hashes of each unspent coin address can be kept ongoing in DRAM without the signatures.

However if the public key account balances are separately stored, then the signatures only need to be kept for N blocks, where N is high enough to guarantee with sufficient probability that the peer's current chain won't be orphaned by a competing fork that gains more than N blocks x difficulty to become the accepted chain. For example in Bitcoin miner coinbase transactions can't be spent for 100 blocks[7].

A separate "proof chain"[8] linked since the genesis block is necessary, otherwise an attacker could utilize unlimited time to construct a fake chain with more than N blocks x difficulty. Note each PoW puzzle solution difficulty (i.e. the number of zero bits in the block's hash) is independent of the transaction data in the block, thus constructing a fake proof chain requires the same historical resources as the legitimate proof chain. Including a hash of the account balances in the corresponding block links their veracity to the longest chain. If an attacker creates fake account balances that have a hash that agrees with some block, and is able to outpace the difficulty of the rest of the legitimate peers, it could erase preexisting and create new account balances.[9] Thus the 50+% attack would be more dangerous. However this can be mitigated to the same extent that Bitcoin does with community resources to store the entire block chain transaction history linked from the genesis block. These super peers with sufficient resources would be entrusted to detect and show the proof of a 50+% attack.

To help insure that transaction signatures are not replayed, transaction inputs could be entirely spent to outputs which include a new address for the change. Signing a hash of the transaction which included a nonce (e.g. the transaction id in Bitcoin) would not be secure for the transaction peers which don't download the entire community transaction block chain history. Note the replay could still occur if the fully spent input address was ever sent a sufficient balance again. Signing a hash of the transaction which included the block id and allowed the transaction to appear once in any one of the M (where M <= N) blocks that followed, is probably a superior solution.

The transactions would not need to be stored in a Merkel tree since the only reason for doing so is to be able to verify remaining transactions against the block header after pruning and to support simplified payment verification[10] which is unnecessary because fully verifying peers would have optimized resource requirements. The data structure for the account balances has to meet certain requirements.[11]

The DRAM and download footprint would be dominated by the account balances data structure.[12] To eliminate the useless proliferation of public keys, the block chain would not accept transactions that create non-zero balances less than some quantity of coin (e.g. 0.01 BTC).

Since transaction sender signature size becomes an insignificant factor (except for the super peers), the relatively insecure ECDSA of Bitcoin can be replaced with Lamport signatures with extraordinary long key lengths, e.g. 4096 bit.[5]

Anonymity

All known existing solutions for anonymizing the IP address, e.g. Tor, I2P darknet, anoncoin, etc., are not secure against timing attacks.[13] Assuming that problem is solved, then a remaining problem is how to delink spends from other spends. Paradigms which mix coins from numerous identities only provide plausible deniability since the hashes of the addresses of all the input coins are in the public record, and the probability of deniability is reduced by the percentage of inputs provided by an attacker or participants who leak their identity to their outputs. Decentralized mixers are difficult to design to be resistant to DoS attackers, although Zerocoin might be a solution.[14] It is possible that some vendors might not accept coins that originated from mixers due to "know your customer" anti-money laundering concerns.[15] Thus the most robust solution is to obtain coins anonymously with small values. This can be done by mining coins, or anonymously receiving payment in coins. Unless the attacker has a list of all the customers, by giving a unique destination address to each customer then it is impossible to correlate that these coins belong to the same vendor. If coins can be anonymously converted into cash or mining hardware, they can be anonymized.

1-Confirmation Transactions

To successful double-spend or unspend, the theft transaction needs to be placed in a block that will become orphaned and the winning chain must be obscured from the merchant accepting the 1-confirmation transaction. There is no reliable way to accomplish this attack on every attempt without 50+% of the PoW resources. So for small ticket items where rare theft is tolerable, the merchant can accept 1-confirmation transactions. An improvement would be to punish any transaction which overdraws the sender's balance, by charging a percentage fine of the balance that is not given to anyone (don't want to reward miners for this beyond the transaction fee which must be less than the fine, since the attacker may be the miner). When the attack succeeds, there won't be any balance to punish. However, since the attack doesn't succeed every time, then the punishment would further discourage the attack.

[1] Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", 1. Introduction
[2] Eric S. Raymond, "Some Iron Laws of Political Economics", Armed and Dangerous blog
[3] Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", 7. Reclaiming Disk Space
[4] https://en.bitcoin.it/wiki/Protocol_specification#Addresses
[5] AnonyMint, "How is same signed transaction not reusable, also quantum security of ECDSA?", https://bitcointalk.org/index.php?topic=309594.0
[6] https://bitcointalk.org/index.php?topic=215936.msg2268831#msg2268831
[7] https://bitcointalk.org/index.php?topic=145666.msg1546809#msg1546809
[8] J.D. Bruce, "Mini-Blockchain Project wiki, Proof Chain", http://bitfreak.info/mbc-wiki/index.php?title=Proof_chain
[9] http://bitfreak.info/mbc-wiki/index.php?title=Weaknesses_and_attack_vectors#The_Secret_Chain_Attack
[10] Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", 8. Simplified Payment Verification
[11] J.D. Bruce, "Mini-Blockchain Project wiki, Account Tree Structure", http://bitfreak.info/mbc-wiki/index.php?title=Account_tree#Requirements_of_Account_Tree_Structure
[12] https://bitcointalk.org/index.php?topic=215936.msg2556839#msg2556839
[13] https://bitcointalk.org/index.php?topic=279249.msg3109291#msg3109291
[14] https://bitcointalk.org/index.php?topic=279249.0
[15] https://bitcointalk.org/index.php?topic=175156.msg2318052#msg2318052

[Etlase2]

Any scheme providing a private and public key is asymmetric cryptography. Note the use of two keys.

Signing a hash of the transaction which included a nonce (e.g. the transaction id in Bitcoin)

You still misunderstand bitcoin transactions.

The transactions would not need to be stored in a Merkel tree since the only reason for doing so is to be able to verify remaining transactions against the block header after pruning and to support simplified payment verification[10] which is unnecessary because fully verifying peers would have optimized resource requirements.

Your argument assumes that all peers will be fully verifying just because it is easier than bitcoin. It is still not easy.

Since transaction sender signature size becomes an insignificant factor (except for the super peers), the relatively insecure ECDSA of Bitcoin can be replaced with Lamport signatures with extraordinary long key lengths, e.g. 4096 bit.

And bandwidth constraints are completely disacknowledged for the cherry on top. Replace storage unscalability with bandwidth unscalability and pretend no one notices? Right.

[bitfreak!]

1. The debasement of mined (above ground) gold never stops, i.e. it is roughly 1 - 3% per year throughout history.

It will eventually stop though, there is only so much gold in the Earth. Personally I don't think perpetual debasement is a desirable thing but this is really a debate for another thread. Like I've said many times, I want to avoid any controversial changes, and perpetual debasement is certainly one of the most controversial changes possible.

[AnonyMint]

Any scheme providing a private and public key is asymmetric cryptography. Note the use of two keys.

Yes. What are you replying to? Are you thinking of where I wrote in another thread that Bruce Schneier recommends using symmetric key when ever possible, and I am mentioning Lamport signatures in that context because even though they are asymmetric, my understanding is they avoid the factoring math that drives Bruce's concern about public-key cryptography.

Signing a hash of the transaction which included a nonce (e.g. the transaction id in Bitcoin)

You still misunderstand bitcoin transactions.

I am simplifying the generative essence for the conceptual purpose of the context, not describing exactly the Bitcoin protocol in great detail (as that would obfuscate the point I am making for the new protocol).

The transactions would not need to be stored in a Merkel tree since the only reason for doing so is to be able to verify remaining transactions against the block header after pruning and to support simplified payment verification[10] which is unnecessary because fully verifying peers would have optimized resource requirements.

Your argument assumes that all peers will be fully verifying just because it is easier than bitcoin. It is still not easy.

Let's talk specifics.

Since transaction sender signature size becomes an insignificant factor (except for the super peers), the relatively insecure ECDSA of Bitcoin can be replaced with Lamport signatures with extraordinary long key lengths, e.g. 4096 bit.

And bandwidth constraints are completely disacknowledged for the cherry on top. Replace storage unscalability with bandwidth unscalability and pretend no one notices? Right.

We only keep N blocks of signatures so what is your point? The super peers (which keep all history) are super

[Etlase2]

We only keep N blocks of signatures so what is your point? The super peers (which keep all history) are super

Sounds like centralization to me.

[AnonyMint]

We only keep N blocks of signatures so what is your point? The super peers (which keep all history) are super

Sounds like centralization to me.

Then you are arguing against the Mini-blockchain design, and also against Bitcoin's design. And we know you hate PoW and the Bitcoin blockchain. But that is what we are implementing.

Yes it is centralization but it enables decentralization of most of the peers and we only need to trust the super peers when there is a 50+% attack. And we assume they will be watched by the community. We don't trust them on real-time matters where they can sneak it past us.

If PoS is better at reducing risks from centralization, then one can argue that. I think the designers of this have stated they want to go with PoW for now. The PoS version would be another thread I assume?

[Etlase2]

Powerful argumentation, as always.