Now you just need to convince the miners that they are ok with 50% revenue cut, even as hashrate increases and no need to boost fees to 0.01 BTC per tx. As I saw in a movie once: "These are not the txfees you are looking for"

James

I have a use case of needing to have many weak chains all be able to do atomic swaps between each other and to be as secure as possible. The problem is that there probably will only be a dozen nodes per chain and PoS is the only practical way to secure these chains. While it would be great to have an unlimited electricity budget, these nodes wont, especially the ones running off of batteries.

So, while the ultimate super duper security is by doing a zillion hashes and PoW, I dont think anybody debates this. The issue is that not all networks can afford this, so the choice is not between PoW and PoS, the choice is between PoS and no network at all.

My idea is to infuse these weak chains with BTC's security. Not for every tx of course, but certainly a backstop from reorgs that go too deep is one protection. Just knowing that after X amount of time, it cant be changed, regardless of how smart/powerful an attacker comes around.

The other thing that BTC can provide via a few consensus rules is a common clock. By segmenting time periods to match the BTC blocktimes (probably grouped into batches of 10 or so), then all the different chains can have a verifiable common reference. The mere presence of a BTC blockhash proves an "after" time relationship.

To get the "before", the weak chains will need a consensus rule to either reject or add any later BTC blockhash that is available. Only "permanent" BTC blockhashes are used, ie 10+ blocks to avoid confusions from small reorgs. maybe it needs to be 30 blocks, but some amount where we can be pretty certain that it will never get reorged.

With a leeway of one to account for lag time that happens when a new block arrives, all chains can have at least a +/- 1 btc block resolution. The consensus rules still need to be completely worked out, but so far, nobody has found a fatal flaw. Which means even the weakest chain with enough confirmations will be able to trade with other weak chains and still with enough confirms (past the max reorg allowed), all can pretend they have BTC level security. Of course prior to reaching the permanent point, any weak chain is subject to all the usual suspects of attacks

including the fantasy one of buying old keys for $5 or $500 or whatever token amount is supposed to be possible. It just isnt so easy to buy something at significantly less than what they are worth from rich crypto traders. Arguably, anybody with a privkey that used to be a large enough stake you want to obtain it, is smart enough to ask for market value. So the cost of the private keys will trade at the expected value for them, with a bit of a discount. And it would not be a contingent payment as once the privkey is delivered there is no way to collect. So now we are looking at not $5 for "worthless" keys, but $X upfront, where X is some discount from the expected value, ie chance of success * size of successful attack. So this goes from a riskless attack to one that rapidly approaches some sort of breakeven level, but uncertain proposition.

The bigger attack that any coin PoW or PoS has is the hardfork attack. This attack is when the parties that control the hardfork version can transfer value from one part of the system to themselves. Their self interest assures they will do this if such a hardfork is available. What this means is that ALL derived cryptos are totally insecure from the hardfork attack.

James

it is not a technical issue. I dont even think any code would need to be changed, just some constants, but it would be a hardfork, so it is an economic/politics issue that is determined in BTC via hashrate (aka money)

With ~$2 billion in crypto (BTC) VC investments, it wouldnt surprise me if some of these startups are entering test or even rollout phases.

there are strong arguments on both sides of whether 10x higher txfees will help or hurt bitcoin. It seems to complicated to accurately understand.

I predict txfees will asymtotically approach sqrt(blockreward)

Nobody needs to protect the miners, since the control the blockchain. Since the miners determine which hardfork wins, to expect they will choose a version that gives them less money is not realistic.

what I suggest is a moving checkpoint, utilizing BTC blockhashes

block rewards are cutting in half. expenses going up
need to boost revenues
limit available tx
boost txfee revenues

in 2016, not any 2140

Yes, the problem is that the people with the power to decide are incentivized to create a smaller supply of available tx, and cutting the time in half only eliminates the "bandwidth is so bad here we use pigeons and 1 MB is all that fits in the tiny pouches" excuse. ipoac to the rescue

so it seems we are headed for significant txfee inflation

Imagine the difficulty of contacting enough such stakeholders. So with a very long term horizon and actively targeting a coin and aggressively buying keys (has anyone every actually done even a single sale) from ex-whales, then at some point you have enough keys, but you cant go back in time with a one day moving checkpoint. So now you need to setup a zillion nodes to sucker in newbies and exchanges?

also the lack of any large short selling market. My estimate is the manual labor cost to do this makes it have a negative expected return and as such is in the same category of economically nonviable endeavors.

Anyway, my interest on this topic is not about pure PoS, but a way to allow all of crypto to benefit from the electricity BTC is using.

I wrote up a little bit on how to use BTC as a unversal sequence server, like a clock for all of crypto.
https://bitcointalk.org/index.php?topic=1372879.msg14034846#msg14034846

It came out of a post  made the other day, so I am sure it is not perfect, but I am pretty sure that weak PoS chains can be made a lot more secure by utilizing BTC. It would make BTC the heart of all these hybrid BTC/PoS and should appeal to the BTC maximalists.

As always, I am agnostic. I just seek the truth to find the best solution for each specific case

James

Where can I buy these keys? I am interested to buy up any PoS using this method and then short sell it

Theoretical vs Practical issues.

Also, what if the PoS chain utilized a PoW chain, like BTC? By effectively using BTC blockhashes directly in a PoS, you can get at least a backstop level of protection. By putting in a moving checkpoint onto the BTC blockchain, then you can create a decentralized and verifiable PoS chain.

Use BTC at the trusted party. Now maybe that changes it from a pure PoS, but maybe you can see a way to attack that too? The assumption is that all nodes are directly monitoring the BTC blockchain and the PoS staking node also puts data into the BTC blockchain, maybe once per hour or so.

James

The coming halving of the blockward, also has absolutely no effect on making the miners wanting to get more txfees.

After all, all businesses love it when their revenues just get cut in half, instantly. When all their costs stay the same, so why would miners do anything to boost their txfee side of the income? With a few thousand tx per block, if the market rate for txfee is pushed to 0.005, then all of a sudden, it isnt just a few satoshis anymore

Follow the money. Usually the answers are there

James

doubling tx capacity is pointless?
supposedly dealing with the massive 1MB blocks are the issue that creates resistance to increasing the blocksize. Establishing a txfee market has nothing to do with this resistance. The miners absolutely dont want to make more money by forcing txfees up.

5 minute blocks of 1MB doubles the tx capacity and delays the txfee market that the miners say they dont want, since the block reward is all they care about. Whats a few satoshis worth of txfees anyway?

When you can do a full blockchain sync in 30 minutes, there is no bloat problem.

I think a much bigger issue is the lack of standard for iporc. If pigeons are compared to rats with wings, then the rat lobby demands representation for ip packets encoded into bits of cheese. The technical challenges are immense, primarily due to consumption of the cheese prior to proper checksums are verified. However, I am assured that the rodents in general and rats in particular are confident that they will be able to create a more reliable packet routing than their flying counterparts

James

Actually the real reason is that there is an active behind the scenes campaign from the avian lobby:

https://en.wikipedia.org/wiki/IP_over_Avian_Carriers

They have spent a lot of money on higher reliability and faster packet times. At the 10 minute blocktime, they have a chance. Dont take that away from them

James

its a slippery slope.
first its 5 minutes
then 4, 3, 2, 1

and well before that a lot of hashrate is wasted on orphans and then instead of very rarely seen a block only to see it replaced, it will become much more frequent.

Also, it will bloat the blockhain by 0.01% due to extra overhead of blockheader's 81 bytes
i guess it is 0.008% at 1MB blocks.

James

double sha256 is used in quite a few places, the blockhash, the data that is signed, the address checksum and also for checksum of network messages.

While using different hash functions would require all of them to be solved to invert them, the danger of using any old hash function is that if any of them loses a lot of entropy, you could get a lot more collisions or just a clumping of outputs, which could cause bad behavior in other parts of the system that is expecting cryptographic strength hash

Hopefully, the resulting hashes are verified for collision resistance

James

on an unrelated issue, do you know what the likely range for the tx version field will be?

both version and locktime have very low entropy when viewed as an aggregate, but I dont want to encode it with too few bits if either of them will start being used actively. I think for locktime, encoding it as a relative to block or block timestamp for the cases it is nonzero could get both fields encoded into average of 8bits

I am using fixed space allocation though, so I need to make the worst case be as small as possible

James

all usage of ripemd-160 in the bitcoin protocol is to the result of the sha256's 256 bits, there is OP_RIPEMD160 that does just the RIPEMD, but there is also OP_SHA1. Unless you are using custom scripts on a core that supports those script opcodes, you are safe from the dangers of weak hash funcs.

Not sure if there is a way for any function to reduce the entropy of the sha256 output in a meaningful way, short of using an anti-sha256 after the sha256, it is probably harmless to use ripemd-160, and it could even make things that much harder to inverse.

If to just rely on lower bits of sha256, then once that is fully solved, well, I guess a lot in crypto will be an open book at that point. and if sha256 is cracked, then probably ripemd160 is also cracked.

James

P.S. For consistency, taking lower 160 bits of double sha256 would have removed the need for a ripemd160 hashing, but probably the thinking was that it was incrementally safer to use two different hash functions

Have to start with something. Seems much better than a solution to a tic-tac-toe problem.

Just keep in mind it is the "hello world" to show this concept actually works

I hope there will be reference verifies and easy to follow examples for more practical things, like privkey swap for BTC

hint, hint

James

P.S. before you start posting that to swap a privkey is silly, consider a 2of2 msig where you already have the other half