One question I still have is : what is to prevent a user from forcing the generation of a POS block (which is just a flag when starting the wallet now, correct?), jumping offline before the generation is complete and coming back on 6 hours later. Does it attach to the end of the blockchain? or does it insert where the blockchain was when the block was generated (not submitted), potentially orphaning 360 blocks?
He can generate a PoS block wherever in the chain he likes, however with trust reduced to 1 it's useless to do so. And the "no consecutive PoS" rule prevents him from doing any damage even if he has millions of PoS-eligible inputs. So, it appears that the genesis for the hash on a POS block is based on the coin age of the input. If POS isn't successful (due to the most recent block being POS), then the coin age is not destroyed, and can be attempted later, which can be as soon as a minute (in an ideal model) as a miner finds a POW block to sit on top of the minter's POS block. I just wasn't certain if the whole orphaning was being caused by the POS blocks having to be inserted into the blockchain at the point it was generated as opposed to when the minter was connected to the network. Is cementing an option, or would that be really bad with our current distribution of hashpower (mostly centralized)? https://en.bitcoin.it/wiki/Proof_of_Stake#CementingIMO cementing is a bad idea as it requires us to trust PoS (which we don't as of now). Also there could be some race-conditions and other nasty issues that could easily result in network fragmentation. |
|
|
|
PoW miners will never be able to remove the whole PoS function and every block, but they could make the whole PoS system useless in order to maximize profits. I belive the rules you proposed are they only way besides CentralCheckpoints to solve the current doublespend problem.
PoW miners certainly won't maximize their profits by orphaning PoS. On the contrary - their mining revenue would be much lower if they decided to attempt orphaning PoS. |
|
|
|
One question I still have is : what is to prevent a user from forcing the generation of a POS block (which is just a flag when starting the wallet now, correct?), jumping offline before the generation is complete and coming back on 6 hours later. Does it attach to the end of the blockchain? or does it insert where the blockchain was when the block was generated (not submitted), potentially orphaning 360 blocks?
He can generate a PoS block wherever in the chain he likes, however with trust reduced to 1 it's useless to do so. And the "no consecutive PoS" rule prevents him from doing any damage even if he has millions of PoS-eligible inputs. |
|
|
|
The new rules make it possible to destroy PoS since they favour PoW so extreme over PoS.
No, it does not favor PoW over PoS - both have the exact same value. Orphaning a single PoS block with PoW is VERY HARD with the new rules (right now even more so). Orphaning a single PoW block with PoS is IMPOSSIBLE with the new rules (right now you can orphan a SHITLOAD of PoW blocks effortlessly). EDIT: to clarify - you can create an alternative fork with PoS block under the new rules (assuming that the second to last block was not PoS) - but that's not an issue. To actually orphan the legitimate block you'd have to also PoW mine at least one block after your PoS block. |
|
|
|
You just CAN'T spend freshly minted coins until there's 520 more blocks above the one you minted.
Yes. But exchanges and businesses could still wait until there's 1040, 2080 or 10400 before they take your fresh coins if they don't want the risk of transaction reversal. We could make the standard wallet freeze coins for that much longer, so they can't be put in outgoing transactions. If someone receives "fresh" coins, they know the other person is going all the way to use a hacked wallet which immediately flags it as fishy. Well, this hinders the usability of YAC, then... YAC would be absolutely unusable the way you propose. With the workaround I proposed, you can be certain that only someone with control of 51% or more of the network hashrate can orphan blocks - and that it actually costs him something to attempt that kind of thing. The way it is now even a McDonald's worker screaming for higher minimum wage can orphan as many YAC blocks as he likes. |
|
|
|
Would it be possible to implement automatic calculation of how many PoS blocks can be allowed one after another based on N factor? This is my idea and let's say for example that we get a new fork on February 1st. Column "Blockchain example" shows what could be allowed ( Nfactor-13 consecutive PoS blocks ) ▉ PoW ◔ PoS | Nfactor | Date time | Consecutive PoS blks allowed | Blockchain example | N | Memory | Timestamp | | 14 | We are here | | ◔◔◔◔◔◔◔◔◔◔◔ | 32768 | 4 MB | 1384768416 | | 14 | Sun 1 Feb 2014 00:00:00 | 1 | ▉◔▉▉▉◔ | | | | | 15 | Sat 31 May 2014 14:13:52 | 2 | ▉◔◔▉◔◔▉▉▉◔ | 65536 | 8 MB | 1401545632 | | 16 | Fri 05 Sep 2014 16:24:00 | 3 | ▉◔◔◔▉◔◔▉▉◔◔◔ | 131072 | 16 MB | 1409934240 | | 17 | Tue 23 Jun 2015 22:54:24 | 4 | ▉◔◔◔◔▉◔◔◔◔▉ | 262144 | 32 MB | 1435100064 | | 18 | Sat 16 Jul 2016 07:34:56 | 5 | ▉◔◔◔◔◔▉◔◔◔◔◔▉ | 524288 | 64 MB | 1468654496 | | 19 | Tue 08 Aug 2017 16:15:28 | 6 or perhaps release restrictions? | | 1048576 | 128 MB | 1502208928 | | 20 | Fri 16 Oct 2020 18:17:04 | ? | | 2097152 | 256 MB | 1602872224 |
By allowing N consecutive PoS blocks, you're essentially giving ANYONE with some YACs available the ability to orphan the latest N-1 blocks. With N == 1 you can't orphan anything. (All that assuming PoS block trust is equal to PoW block trust.) |
|
|
|
(eg. you deposit YAC to exchange, wait until the exchange credits you the deposited balance, block gets "magically" orphaned - and you now have both your YACs AND credit at an exchange - that's why Cryptsy has been disabling YAC trading lately).
Why would an exchange give you credit for freshly minted coins, unless they deliberatedly wanted the risk. NOT freshly minted... -.-" You just CAN'T spend freshly minted coins until there's 520 more blocks above the one you minted. I was referring to TRANSACTIONS. The block CONTAINING your transaction gets orphaned. It DOES NOT need to be YOUR block. And YAC had some chain reorgs deeper than 50 blocks (50 confirmations of transaction!) as the consequence of all this badly-designed PoS bullshit. Built-in POW-POS-POW-POS staggered blocks? What implications does it have other than fix the POW orphan problem (ie unintended consequences)?
It's not just pow-pos-pow-pos. It can just as well be pow-pos-pow-pow-pow-pow-pos. There's no limit on how much consecutive PoW blocks are there in the chain - just that 2 PoS blocks can't be directly linked. |
|
|
|
How come Peercoin doesn't have these problems? Or do they?
I have lost tons of YACoin from BTER-- they are scamming a lot of people. So I won't be in a position to offer bounties for a while. What would be the best type of bounty? More pools with different features? A javascript mining program/pool like bitminter? I cringe at the idea of centralized checkpointing or reduced POS awards.
Peercoin is using the centralized checkpointing approach as far as I can tell. |
|
|
|
Also, how long is long enough? It wouldn't be bulletproof...
Long enough to detect the situation maybe. New coins could take a month or a quarter to mature and it would still not be too outrageous for a mint and sell business -- resource miners everywhere have to deal with futures for such timespans. New coins need 520 confirmations already - which is almost 9 hours. But this is NOT the problem. The problem is that transactions from an orphaned block get REVERSED (eg. you deposit YAC to exchange, wait until the exchange credits you the deposited balance, block gets "magically" orphaned - and you now have both your YACs AND credit at an exchange - that's why Cryptsy has been disabling YAC trading lately). |
|
|
|
Is it possible to identify new PoW minted coins so exchanges/businesses/wallets reject them until they have definitely cooled down?
That's already done at the protocol level.  I understand if they don't move after minting until it's confirmed PoS won't orphan them, getting orphaned would be just an issue of PoW mining efficiency. Is that correct?
The problem is not block orphaning, but reversing of transactions (double-spending). We could then make the wallet hold longer on confirming transactions with new coins, unless the wallet owner likes to live dangerously and disables the safety delay. That's solution for the consequence, not the cause. Also, how long is long enough? It wouldn't be bulletproof... |
|
|
|
In the current scenario where one pool actually does have majority hashpower, this isn't quite true. Of course, the bigger problem isn't that issue, it's that there's one pool with majority hashpower at all.. Perhaps this should be a larger item of concern for the YACoin community at the moment.
The same goes for Bitcoin - just look at btcguild's recent luck. The cryptocurrency community contains a certain number of people who like to be a dick, and will do things solely for the purpose of being as much of a dick as possible. I think Luke-Jr possibly sets a good example of how best to be a dick to many altcoins.
LOL, what has Luke-Jr done? Haven't heard anything. |
|
|
|
Is it possible to identify new PoW minted coins so exchanges/businesses/wallets reject them until they have definitely cooled down?
That's already done at the protocol level. I understand if they don't move after minting until it's confirmed PoS won't orphan them, getting orphaned would be just an issue of PoW mining efficiency. Is that correct?
The problem is not block orphaning, but reversing of transactions (double-spending). |
|
|
|
Can't we just slow down PoW block target rate, so only a couple are mined between PoS blocks.
That wouldn't stop anyone from orphaning all the PoW blocks at the tip of the chain. Yeah, but orphaning a single PoS block with 2 PoW blocks actually costs you something (you have to be lucky or have majority of the network's hashrate).
It seems that there's currently a pool in a position to make it happen on a frequent ongoing basis. Orphaning a PoS block with 2 PoW blocks doesn't really cost you anything extra if you're already PoW mining anyway and happen to hit 2 consecutive PoW blocks. Nope, the rogue PoW miner has to decide in advance to invest his work in what will most probably be an invalid chain. So when he fails to execute his attack, he effectively lost his potential profit from playing nice. OTOH, with PoS you can safely and with absolutely no additional cost mine on all the forks. OTOH you can generate PoS blocks essentially for free.
Well, you do have to hold YAC, and hold it long enough, so I'm not sure it's correct to say minting PoS blocks is free. And what's gonna stop me from purchasing the minimum amount of YAC needed for some type of attack, assign them into multiple "packets" of coins that have different PoS maturity time so I get 1 PoS block every X hours/days/whatever?  (and trust me, the amount of YAC is small enough for anyone to buy) Also, the gain from orphaning PoS is ZERO.
The gain in the miner's held YAC from orphaning PoS blocks is zero, but there may be other motivations other than an immediate gain in YAC to orphan PoS blocks. I fail to see any possible motivation to do so whatsoever. |
|
|
|
I've got a "workaround" for this issue. Still, it requires a hard-fork.
It's quite simple, just disallow two consecutive PoS blocks and lower PoS trust to match PoW (1).
There's no way PoS-only miner can orphan a single block.
Matching PoS and POW trust has enourmous consequences so we have to be very carefull here. The biggest problem is that it'd be possible for PoW-miners to turn YAC into PoW-only! Once we are there we couldn't get back without a hardfork and it's unlikely we could possibly agree on such by then. PoW is far more important than just distributing initial coins.(I've written someting about that on yacointalk, that's also why YAC is special) I belive the current problem of one PoS-block overwriting more than 6blocks is far less than the problems we would get when we have no more or just a bit PoS. PoS as whole has to be much stronger than PoW so that all miners couldn't agree on "just ophraning all PoS" to make more profit. A PoW-block will always have more new coins than the average PoS block so most PoS would disapear and the rest 'd be centralized. PoS mining is truly decentralized so we should try to keep it as important as possible. I can't think of a technical way to prevent doublespends AND miners from fighting PoS. What we could do is increase PoW-rewards for miners that mine on top of a PoS block. It must be either chaintrust PoS>>>PoW or new coins generated in ...-PoW-PoW-PoS- PoW >...-PoW-PoW- PoW-PoW. We all know that PoS>PoW is problematic so we should go with the 2nd. I'm glad you've got something in mind, I've spent a couple hours trying to find out what the fix novacoin implemented was, even digging through the code, but I can't isolate a single POS fix - there have been quite a few tweaks to POS in Novacoin. I can see that they currently have adjacent POS blocks, so what did they do to address this issue?
AFAIK Novacoin "fixed" this by having a centralized checkpointing system in-place. Essentially one person controlling the whole network (deciding on the valid chain), which defeats the decentralized nature of cryptocoins. A centralized checkpoint for the next few months would be far better than loosing or having less PoS in the future than we have now. The only issue is deciding on the blockchain fork date. It should be fairly soon, but not too soon as we should give a majority of the network time to upgrade. How about 1 month?
I think that's reasonable. Yeah, but orphaning a single PoS block with 2 PoW blocks actually costs you something (you have to be lucky or have majority of the network's hashrate). OTOH you can generate PoS blocks essentially for free. Also, the gain from orphaning PoS is ZERO. |
|
|
|
I'm glad you've got something in mind, I've spent a couple hours trying to find out what the fix novacoin implemented was, even digging through the code, but I can't isolate a single POS fix - there have been quite a few tweaks to POS in Novacoin. I can see that they currently have adjacent POS blocks, so what did they do to address this issue?
AFAIK Novacoin "fixed" this by having a centralized checkpointing system in-place. Essentially one person controlling the whole network (deciding on the valid chain), which defeats the decentralized nature of cryptocoins. |
|
|
|
I was unable to come up with any suitable solution that also preserved PoS checkpointing functionality - IMO it just can't be done (the right way) with current hybrid PoW/PoS design. In PoS-only system - no problem. But with hybrid chain it's just one hell of a mess. This should be weighed carefully. PoW is a bit hard to rely on long term due to not knowing how technology is going to affect it, not knowing if someone will plug in massive hashpower out of the blue someday, not knowing how future energy costs will factor in, etc. It's not relying on PoW per se. In the future PoW can be disabled completely and the "no 2 consecutive PoS blocks" rule removed (block trust value would not matter then anyway, and the same goes for PoS checkpointing). However, this is a no-go short term, as we're still pretty much in the initial coin distribution stage and there's too few PoS blocks to be able to rely on it (and remember we need a huge amount of different people participating in PoS, not just 2-3 big hoarders). Also, remember the increasing computing and memory requirements of scrypt-chacha. If/when we see a massive break-through in hashing hardware, Bitcoin will be the first to go, not Yacoin. If we happen to see scrypt-chacha ASICs, the difficulty will adjust MUCH faster than in Bitcoin ('cause we do a retarget after each single block, compared to Bitcoin's 2016). In case of huge energy costs and the network hashrate experiencing a massive drop - YAC can also adjust fairly quickly (just look at the Nfactor change events). As far as quantum computing goes - we'll have much greater problems than cryptocurrencies going bust then. |
|
|
|
|
I've got a "workaround" for this issue. Still, it requires a hard-fork.
It's quite simple, just disallow two consecutive PoS blocks and lower PoS trust to match PoW (1).
There's no way PoS-only miner can orphan a single block.
PoW miner forking/orphaning still requires a substantial percentage of network hashing power.
However, this way we're essentially removing the intended purpose of PoS (checkpointing). I was unable to come up with any suitable solution that also preserved PoS checkpointing functionality - IMO it just can't be done (the right way) with current hybrid PoW/PoS design. In PoS-only system - no problem. But with hybrid chain it's just one hell of a mess.
I think I'll have the implementation ready soon (in 1 day methinks).
The only issue is deciding on the blockchain fork date. It should be fairly soon, but not too soon as we should give a majority of the network time to upgrade. How about 1 month?
|
|
|
|
Also, I am under the impression that even though PoS uses CPU, the ability to stake coins faster does not depend on CPU processor speed so increasing your CPU percentage used by the yacoin client won't benefit you.
Exactly. |
|
|
|
...
... NOTE: you NEED to move/rename (backup) everything except wallet.dat and peers.dat in the yacoin data directory and then run yacoin with -loadblock=C:\blk0001.dat (assuming you put the blk0001.dat file in C:\). This is needed because we had to change the way blocks are indexed and now the wallet starts in LESS THAN 30 SECONDS (down from more than 30 minutes). However, this initial load will take somewhere around 2 hours (still faster than downloading it through the p2p network). If you don't mind redownloading all the blocks, you can just remove the unneeded files and start yacoin normally (less hassle, but takes more time). Most of the time at startup is now spend verifying the last couple of blocks (which needs to to recompute their hashes to ensure integrity). I've lowered this number from the default 2500 to 666 (rather arbitrarily chosen, but should absolutely be set higher than 520). Hello sairon If I understand correctly, one moves one's blk0001.dat and blkindex.dat to a new location, but leaves one's wallet.dat and ... /database/log.00000000xx file(s) in place? Does the wallet info depend upon the old information, somehow? Also does the yacoin041 -loadblock="path to old blk0001.dat" invocation require an internet connection, or is a new blkindex.dat created from the old one? I would like to eliminate as many variables as possible, since I'm doing this in windows! Ron maybe just (re)moving blkindex.dat and running with just '-reindex' will work, too. haven't tried that, tho... |
|
|
|
|
Show Posts
