+1

It's not the bug in their exchange that pissed everyone off..

It's the way they dealt with it.. as always.

Did they have to release a statement to the masses saying 'Bitcoin has a BUG! RUN FOR YOUR LIVES!'..

Inflammatory bollox.

Same same from GOX.

Steer clear. Your choice. 

Well - this is to redistribute to fees. And it's not quite like the other Proof Of Stake systems out there, as they use your stake to allow you to mine, and find blocks. You would get your cut of these redistributed fees even in a paper wallet offline.

What if, like Proof of Burn, we just throw the fees away.. ? (I am assuming minting is finished..)

So that they are only used as a method to prioritise which txns to add to your block and to stop txn spam DOS attacks.

Can a system where the miners ARE NOT REWARDED work ?

Is the 'Tragedy of the Commons' the ONLY argument against letting people decide when to upgrade their kit ?

I can see that the network hash rate would be lower than it is now, but so would the incentive to acquire a high hash rate, as you don't make any money from it..

The only reason someone would try and garner 51% is to 'destroy' bitcoin, and maybe a different mechanism could be used in that case.

If there weren't 'dedicated' miners, you could maybe change the POW algorithm regularly to prevent ASICS coming in to play. CPU only, since users wouldn't really care.. as long as their computer can still compute it.

You could redistribute based on their BTC balance as a percent of the whole. No Sybil attack.

I'm also saying that this would be the absolute minimum fees possible to prevent spamming the network with txns. So maybe just chuck them away. Re-Mint if necessary.

Tragedy of the commons.. Yep.. it hangs over us all, but i'm not 100% that someone who had literally Thousands/Millions of btc would allow this to happen.

[BANG]! - That's the horse I was flogging earlier, being shot.. Cheers Tiers.

I was thinking - what if you didn't pay the miners at all.. ? What if the minimal fees, just to stop DDOS, were simply redistributed, in some way, to ALL the users. Can think of a couple of ways. Maybe just lose them completely. (Yes - there would need to be some other system to MINT the coins)

Would the whole network just collapse.. ?

What if you, the bitcoin user, ran the full node, and it was up to you to protect your investment, by making sure the hash rate of the network was high enough to prevent a trivial 51% attack ?

People could be compensated for allowing SPV clients to connect to them.  

If there was no money in it for the miners, would we still have the miner's issue..

Those with 10's of thousands of bitcoins, would simply choose to upgrade their equipment. To protect their stash. Kind of - Proof of Stake, but voluntary.. Those with more of a stake, would HAVE to invest in mining equipment, or risk losing it all.

Just a thought. (Down Dobbin!..)

Is it possible to get this hash value from bitcoind ?

Or - How do you get this Hash ?

Sorry to keep flogging this horse, just want to get it out of my system..  

What if you used some kind of logarithmic scale, with regard to your Hash Rate * BTC Balance. ?

So that the effect is much more for small miners.. and diminishes for the larger miners.

Somehow 'levelling the playing field', and make it so that a small miner benefits more than a large miner.

So, as a simple idea..

Total Hashrate = Computer Hashrate * SquareRoot(BTC Balance)

Then combining into your previous example.

1GH with 10 BTC = effective 1GH*SQRT(10) = 1GH * 3.16 = 3.16GH

Then x2

2GH with 20BTC = effective 2GH * SQRT(20) = 2GH * 4.47 = 8.9GH

8.9 / 3.16 = 2.8 times larger only..

Maybe the equation could be stepped so that

BTC balance < 10 you use the original.
BTC balance < 100 you use the squareroot. (of the difference over 10 + original for 10)
BTC balance < 1000 you use the cuberoot.  (of the difference over 100 + squareroot up to 1000 + original for 10) etc.. so that the curve is continuous, like taxes..

This way small miners would have the greater advantage for pooling together, but larger miners wouldn't ?

I suppose Pools would then break into smaller pieces to gain as much TOTAL HASH RATE as possible, some simple equation would determine that, BUT '..Pools would then break into smaller pieces', allowing more players onto the chain.

..TierNolan.. ATTACK!

Yes - i did think this.. the Product of HashPower and BTC balance has a few strange side properties..

BUT - it does mean trusting someone with your coins.

And, you can't sell your coins or spend them. A miner will have to pay out at some point ? A user will want to use his mined coins..

I know there are issues.. it just seemed like a very easy way of linking balances into the POW conundrum.

5/ STAKE YOUR WORK.. ?

Have been mulling this over and not sure if it can/can't work.

Basically it is a hybrid POW/POS system.

It is very simple.

You divide the current difficulty by the wallet balance of the miner. Minimum 1 btc balance used (even if you have less).

So - if you have less than 1 btc(or whatever alt-coin) you have to hit the current difficulty.

If you have 100 btc, it's 100 times easier for you..

Someone with twice as many coins, has twice as much POS power. POW still uses regular hashing.

What I was thinking is that it would be like buying ASIC equipment, so that everyone could just buy coins and increase their hash power.

Unlike current systems, it doesn't run out after you spend it. You don't have to have TXN outs that you haven't spent. It's always there.

Basically your hash power is now your 'Computer's Hash Rate * Your BTC Balance.'

A one man band with one computer hashing away at 1KHash, who had 1000btc, would have the 'effective' hash rate of 1MH.

I also thought this would affect the current Mining Pools.. as their hash rate would not be the sum of all the accounts that mined. It would be just the central miner's balance..

(I also thought that maybe you could have a separate coin exchanged on chain p2p, and that was your MiningPower, so that a market price would emerge.. The Total MP coins would equal hash rate.. or something.. but that's for another day..   )

I was wondering if this idea could be generalised..

What I mean is, if you had blocks coming in.. continuously..with uneven gaps between them, and all you know is when you received the block & the block hash, and other details pertaining to the contents of the block, could you work out a deterministic way of ordering them.. ? Which would be the same for users across the network who may have received the blocks in a slightly different order to each other ? 

Maybe a block could tell you where it 'thinks' it should be in the order, by using it's timestamp, but that would only be valid if you received it within a certain time range from that point.. A window of validity.

Is there a way to do this.. ?

Assume non-malicious users to start with, then we can try and break the system later..   

Just to clarify..

p2pool ROCKS. No question.

BUT - p2pool is not the BE ALL AND END ALL ANSWER.. I wish it was.

All p2pool does, from a technical perspective, is make bitcoin run on a much faster chain. Originally it was 10 seconds, but now has moved to 30 seconds, funnily enough to let the ASIC machines work on it... So it's chain is just, with 30 secs, 20 times easier to mine on. And yes, it is decentralised, just like btc. But that's all.

Once A LOT of hashing power moves to p2pool, EXACTLY the same thing will happen and only pools will be able to mine it.

You will not be able to mine solo on p2pool. You'll have to join a pool that mines p2pool.

And then the whole circus will start again.

A technical solution has yet to be found for this issue.

That doesn't mean it won't, but just saying 'EVERYONE JUMP ONTO P2POOL', is a temporary solution at best..

Now.. Let's think of a proper technical solution, as the OP suggests..

{..sits on chair and starts thinking..HARD..}.. 
 

Modular Exponentiation!  Thought it might play a part.. 

'Time-Lock Puzzles' is a new term for me.. It's always in the name. Then you know what to look for on Google.

The idea seems that you can lock data up in such a way that it can be decrypted ONLY after a certain amount of sequential tasks are performed. And this task CANNOT be run in  parallel. Like it.. Seems the inverse of what i was looking for, but definitely in the same ball park.. Thanks

Could it be used as some form of Hash Function ? Or as a sort of POW system..

I am searching for more info now.. {..starts sucking the interweb..}

In the current POW system, you have the blockheader and a nonce you can change. Then you SHA256 the lot.

This is obviously a task that can be run in parallel.

This way an ASIC can crunch through a 'Gazillion' different nonce values simultaneously. Using pipelines etc..

And, once a nonce that satisfies certain criteria is found, maybe more than one actually, the proof-of-work is still just a simple hash away.

Is there a construction that only works 'Sequentially', so that the task cannot be run in parallel, and yet STILL only a hash away from the proof ?

I know that Scrypt uses a memory hard function, so you would need a different block of memory per attempt, but you could still do this in parallel. As the GPU implementations do.

You could say that the hash is the Hash(prevHash + Blockheader), but this is then not provable in a single hash check as you would need to do all the work again running back through the previous hash values..

Is there a construction that does this ?  

Question..

If you were running a 10 second share chain, like p2pool, is it even possible to run a pool on that ?

The chain would be too fast to have another pool trying to find smaller shares, say every 1 second ?

The messages just wouldn't have time to propagate across the network.

Is that correct?

You would need a different mechanism. Maybe one based on sending different miners a range of nonce values they should try, so that no 2 miners search the same space, and then when someone finds a valid block just publish it with payouts made to all.. Seems like 'trust' would need to be involved for that to work though.

Litecoin changing it's POW - Hmm.. Not sure, you'll only have to do it agin and again..

YaCoin does a nice job as a variable scrypt coin.

If you want a coin to be truly ASIC resistant you may need to come up with a completely new algorithm paradigm.

Serendipitously enough - I have just had an idea that may/may not work..

https://bitcointalk.org/index.php?topic=322581.msg4450472#msg4450472

Please check that out.. Curious to hear if you think it might/won't work..

At first, this seemed an impossible dream, but I've had a rather devious idea.. 

It is obvious, to me at least, that any piece of code that can be WRITTEN DOWN, can ALWAYS be converted to some form of ASIC.

So - let's assume that to be the case. That if you write a complicated algorithm that re-jigs the hash algorithm used in a POW system, you can ALWAYS write that as some form of ASIC.

Now let's attack this problem from a different angle.

Let's say - We want the ASIC implementation to be ONLY AS FAST as the CPU implementation.. rendering the ASIC implementation useless. Can that be done ?

I can think of something that does that. A Full Blown Computer..

You write an algorithm that writes TOTALLY NEW CODE. And not code that uses a couple of mixer functions like XOR or modular exponentiation.

I mean a complete working program that can ONLY BE RUN on a full blown CPU chip. You could make the algorithm use a minimum amount of differing logic, so that ONLY a cpu could run the whole brand new piece of code. 

 

This sort of thing could be used to ensure that whatever the new piece of code the computer came up with was still a valid hash. You may have to use concatenation or nesting instead of a straight XOR depending on the use of the Hash. Concatenation preserves collision resistance, nesting preserves first pre-image resistance and XOR preserves pseudo-randomness.. Or maybe the newly-written code could be used for some other function, like determining which hash algo to use in the first place. Not the HASH algo itself. 

Thus - You would be writing a computer program that writes computer programs, and the programs that the computer writes can only be run on a full blown cpu.

Therefore, when someone does create the ASIC version, which they always can, it's fine. It still needs to run the code on a cpu. So they would need to put a full CPU on the ASIC chip board.

Which i think is just another name for, a computer..

This way the ASIC version is, just another computer. And no faster than the fastest computers.

As for the implementation of a program that writes working programs complicated enough for this scheme to work.. that would need to be something, a little bit special.. 

Actually, thinking about it..

How does a p2pool sub pool get paid by the p2pool main chain 1 level up ?

There could be, let's say 1000 outputs on the coinbase txn of the sub pool, and then in the p2pool main chain there could be 1000 shares from the various subpools.

This would mean having literally a million payouts in the coinbase txn..

err.. not sure now..

You can have the top level p2pool, but then you need the regular centralised pools as the sub pools, otherwise as I said, the coinbase becomes toooo large..

 

+1

How about..

Main p2pool share-chain. (Or a blockchain that ran on a 1024 PPLNS system by default)

Then 1024 sub-p2pools, each mining the main p2pool chain.

When you connect to the network you always connect to one of the sub-pools. Basically the weakest one in terms of hashrate.

You reconnect/re-organise your miner every 24hrs/Some amount of blocks. To keep the sub pool hash rates even.

Repeat.

The goal would be 1024 p2pools with ~0.1% total hashrate each. Not that it would matter that much if one pool was a few percent more powerful than another. Your payouts would be of the same amount, just different variance.

All done automagically.. No need for user to worry about it. Just connect and go!
  

Thinking out loud..

If a coin has an 'expiration date', then the older it is, the closer it is to expiration, so the LESS it is worth. This sounds very similar to demurrage ? I can see why Impaler invited you
 
Trying to keep track of how old coins are, whilst keeping the same value, seems quite complicated. I think that the demurrage principal used by freicoin, where the coin is worth :

(It's value) * (-5% per annum), is simpler for people to understand.

Your idea of buying newer coins with older ones seems THE SAME as simply applying demurrage to all coins ?

The newly minted coins will be worth more since the demurrage has not had a chance to affect them as much.

What I do see as different is that if you had an exchange for older to newer coins, the AMOUNT of demurrage would effectively be set by the market, and would not be set in stone.

This could be a useful metric in deciding the state of the economy, and whether money needs to be injected or not. Hmm..

So, what if the coin amount inflated by 2% per annum, or some amount. BUT the amount of demurrage that was applied to each coin was decided by a some kind of on chain exchange. Similar to exchanging old coins for new.

If the demurrage was set to more than 2% you would have monetary deflation, otherwise inflation ?

I'm not sure if the money injection would be done per coin, or just given straight to the miners.

thaaanos! ('Thanos Rising' by Jason Aaron was almost my favourite comic of last year..)

Thanks for your input.

I'm not quite sure I get your idea.. let me try..

There are old coins and new coins.

Old coins stop working after a while. new coins take their place.

If you have old coins does that mean they become useless after their expiration date ?

Then you can trade these coins on an exchange. Old for New. And the price on the exchange determines whether we print more or less money ?

Can you explain it in a little more detail ?

Thinking about it, if you did have a 1024 PPLNS system by default, so that the last 1024 shares were paid, and miners could increase their difficulty and get paid etc etc.., would it not be the case that all the miners would lower themselves down to the smallest miner able to get on the chain ? So that, in the ideal case, each miner still only got 1 share per 1024.

This way you would at least have 1024 miners/mining pools visible on the chain ? Rather than the 10 or so currently available on Bitcoin.

Not sure how important decreasing the difficulty of the individual shares actually is.

The weakest miner able to get on the chain would set the hashrate that the others would have to emulate by increasing their difficulty.

Having 1024 mining pools able to get on the chain is better than less than 1024. No ?