Bitcoin Forum
March 26, 2017, 07:45:53 AM *
News: Latest stable version of Bitcoin Core: 0.14.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 [83] 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 ... 169 »
  Print  
Author Topic: [ANN][YAC] YACoin ongoing development  (Read 323110 times)
Balthazar
Legendary
*
Offline Offline

Activity: 2100


Post rank racist


View Profile
January 04, 2014, 12:39:22 PM
 #1641

2) Enforcing a hybrid chain (with alternating PoW/PoS blocks) is IMO a bad idea as the protocol is set to 1-minute PoW and 10-minute PoS target. With my rules hybrid chain is the optimal way when trying to do 51% attack (as you can reduce the "51%" PoW hashing power needed by at most 50% if you have 100% active weight). Still, it would not be expensive enough to attempt, anyway - that's my justification of lowering PoS trust to the level of PoW (I'd lower it even more if only it didn't cause another sort of problems, which it would). It's all about finding the right balance, anyway.
It's not a "good" or "bad" way. It's how the things should be. Preferred, but not enforced chain. For example, you can use own function of blocks share here, to maximize trust score for 10:1 chain and minimize it for another candidates.

Variable ROI isn't sufficient to prevent a malicious entity wanting to break the network entirely, anyway.
It's only a part of solution. It makes malicious activity to be a less danger for a network by increasing the share of coins participating in the network protection.

Anyway, I've got the code changes ready. You're all invited to review them. https://github.com/saironiq/yacoin-cc/commit/acf917a2c42cb947b08a9a7878ceafd6045ea24c
Good example of simpler != better statement. It will help you for one threat, but opens another hole. Actually, such fix is less secure than calculate block trust using an original algorithm. It can be forked without a significant part of stake or hashpower by running a parallel chain at lower PoS & PoW difficulties. Because it makes no difference between coindays consumed or hashpower wasted. One CPU is able to beat the entire network.

novaco.in | Etherium mining pool (20 GH/s)
฿: 1GV8D5SRkA3cPccpYhVc2wMkjwz3UREEpy: 4RgnHWtnJWEyMhqhDdazW3Hdr7cx5ybF6i ETH: 0x215c86bc952b0d98c4b2313a0a9ae56fa33c7f5d
1490514353
Hero Member
*
Offline Offline

Posts: 1490514353

View Profile Personal Message (Offline)

Ignore
1490514353
Reply with quote  #2

1490514353
Report to moderator
1490514353
Hero Member
*
Offline Offline

Posts: 1490514353

View Profile Personal Message (Offline)

Ignore
1490514353
Reply with quote  #2

1490514353
Report to moderator
1490514353
Hero Member
*
Offline Offline

Posts: 1490514353

View Profile Personal Message (Offline)

Ignore
1490514353
Reply with quote  #2

1490514353
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
sairon
Sr. Member
****
Offline Offline

Activity: 406


One does not simply mine Bitcoins


View Profile
January 04, 2014, 01:00:54 PM
 #1642

2) Enforcing a hybrid chain (with alternating PoW/PoS blocks) is IMO a bad idea as the protocol is set to 1-minute PoW and 10-minute PoS target. With my rules hybrid chain is the optimal way when trying to do 51% attack (as you can reduce the "51%" PoW hashing power needed by at most 50% if you have 100% active weight). Still, it would not be expensive enough to attempt, anyway - that's my justification of lowering PoS trust to the level of PoW (I'd lower it even more if only it didn't cause another sort of problems, which it would). It's all about finding the right balance, anyway.
It's not a "good" or "bad" way. It's how the things should be. Preferred, but not enforced chain. For example, you can use own function of blocks share here, to maximize trust score for 10:1 chain and minimize it for another candidates.

Maybe, but your solution actually forces the whole network into running their own modified client in order to maximize profits - which, honestly, sucks hard. The non-programmer folk have a huge disadvantage here.

EDIT: Assuming that you actually publicly release such modified client, it essentially becomes enforced (who would intentionally lower their profits?). Also, it definitely does not solve the orphaning issue we're facing now. As I stated before, PoS is useless without there actually being something in stake...

Variable ROI isn't sufficient to prevent a malicious entity wanting to break the network entirely, anyway.
It's only a part of solution. It makes malicious activity to be a less danger for a network by increasing the share of coins participating in the network protection.

59% yearly interest for early adopters, sure. Screw the later-coming big investors when the PoS difficulty gets higher and interest lowers significantly. Good way to discourage promotion of the coin and thus adoption.

Even Bitcoin isn't that harsh - and it was designed with huge early-adopter rewards to encourage fast adoption.

Don't get me wrong, I'm not calling Novacoin an outright scam. Just don't agree with the economic model behind it.

Anyway, I've got the code changes ready. You're all invited to review them. https://github.com/saironiq/yacoin-cc/commit/acf917a2c42cb947b08a9a7878ceafd6045ea24c
Good example of simple != better statement. It will help you for one threat, but opens another hole. Actually, such fix is less secure than calculate block trust using an original algorithm. It can be forked without a significant part of stake or hashpower by running a parallel chain at lower PoS & PoW difficulties. Because it makes no difference between coindays consumed or hashpower wasted. One CPU is able to beat the entire network.
The same is true for Bitcoin. That's what the hardcoded checkpoints are for.

GPG key ID: 5E4F108A || BTC: 1hoardyponb9AMWhyA28DZb5n5g2bRY8v
ilostcoins
Sr. Member
****
Offline Offline

Activity: 274



View Profile
January 04, 2014, 01:15:48 PM
 #1643

On a separate note, I have two small issues with the recent beta qt wallet running on a Windows XP, Core2Duo PC. The first is the GUI doesn't show up as quickly as when I first use it on the same PC. The first 2-3 times I ran it, the GUI appeared within a minute or so. Now, it's over 5 minutes. The good news is even though the GUI isn't loaded, at least the qt wallet icon quickly shows up in the notification bar (or whatever that part is called). Besides, looking at the block count that remains to be downloaded when the GUI first shows up after a few minutes, I think it's downloading and processing blocks before GUI is loaded.

Another issue is I have an orphan POS block back in September and this wallet keeps showing it as the most recent transaction entry on the "overview" page. The default sorting also have it floating at the top of the "transactions" page.

LTC: LSyqwk4YbhBRtkrUy8NRdKXFoUcgVpu8Qb   NVC: 4HtynfYVyRYo6yM8BTAqyNYwqiucfoPqFW   TAG id: 4313
CMC: CAHrzqveVm9UxGm7PZtT4uj6su4suxKzZv   YAC: Y9m5S7M24sdkjdwxnA9GZpPez6k6EqUjUt
bitdwarf
Sr. Member
****
Offline Offline

Activity: 378


The cryptocoin watcher


View Profile WWW
January 04, 2014, 01:16:56 PM
 #1644

2) Enforcing a hybrid chain (with alternating PoW/PoS blocks) is IMO a bad idea as the protocol is set to 1-minute PoW and 10-minute PoS target.

Other changes aside, would it be more desirable to have 1 minute PoW and 1 minute PoS so the chain gets more 'hybridized'?

https://twitter.com/bitdwarf · 𝖄𝖆𝖈: YF3feU4PNLHrjwa1zV63BcCdWVk5z6DAh5 · 𝕭𝖙𝖈: 12F78M4oaNmyGE5C25ZixarG2Nk6UBEqme
Ɏ: "the altcoin for the everyman, where the sweat on one's brow can be used to cool one's overheating CPU" -- theprofileth
Balthazar
Legendary
*
Offline Offline

Activity: 2100


Post rank racist


View Profile
January 04, 2014, 01:20:39 PM
 #1645

59% yearly interest for early adopters, sure. Screw the later-coming big investors when the PoS difficulty gets higher and interest lowers significantly. Good way to discourage promotion of the coin and thus adoption.
1) You have to maximize an active weight. It doesn't matter how you do so, but you have to do it for any price (even for constant trolling from ignorant kids), because that's necessary to survive.
You can freely choose another thresholds or function, but the reward shouldn't be fixed. Actually, you have a choice between red and blue pills right now... Logic vs. Emotions/Sanity vs. Morality/Practice vs. Worthless ideology. Worthless because the fixed RoI means no self-regulation, thats why it opens a security hole. Absense of self-regulation is just another type of centralization.

Anyway, I've got the code changes ready. You're all invited to review them. https://github.com/saironiq/yacoin-cc/commit/acf917a2c42cb947b08a9a7878ceafd6045ea24c
Good example of simple != better statement. It will help you for one threat, but opens another hole. Actually, such fix is less secure than calculate block trust using an original algorithm. It can be forked without a significant part of stake or hashpower by running a parallel chain at lower PoS & PoW difficulties. Because it makes no difference between coindays consumed or hashpower wasted. One CPU is able to beat the entire network.
The same is true for Bitcoin. That's what the hardcoded checkpoints are for.
That's not true, it seems that you don't understand Bitcoin quite well.

1. Bitcoin is able to make a difference between diff1 or diff2 blocks, one diff2 block can't be beaten with one diff1 block.
2. Hardened checkpoints only purpose is to be a trigger for signature checking optimization and protection against compromised ISPs. And you can disable hardened checkpoints verification in bitcoin.


novaco.in | Etherium mining pool (20 GH/s)
฿: 1GV8D5SRkA3cPccpYhVc2wMkjwz3UREEpy: 4RgnHWtnJWEyMhqhDdazW3Hdr7cx5ybF6i ETH: 0x215c86bc952b0d98c4b2313a0a9ae56fa33c7f5d
sairon
Sr. Member
****
Offline Offline

Activity: 406


One does not simply mine Bitcoins


View Profile
January 04, 2014, 01:23:26 PM
 #1646

Anyway, I've got the code changes ready. You're all invited to review them. https://github.com/saironiq/yacoin-cc/commit/acf917a2c42cb947b08a9a7878ceafd6045ea24c
Good example of simple != better statement. It will help you for one threat, but opens another hole. Actually, such fix is less secure than calculate block trust using an original algorithm. It can be forked without a significant part of stake or hashpower by running a parallel chain at lower PoS & PoW difficulties. Because it makes no difference between coindays consumed or hashpower wasted. One CPU is able to beat the entire network.
The same is true for Bitcoin. That's what the hardcoded checkpoints are for.
That's not true, it seems that you don't understand Bitcoin quite well.

1. Bitcoin is able to make a difference between diff1 or diff2 blocks, one diff2 block can't be beaten with one diff1 block.
2. Hardened checkpoints only purpose is to be a trigger for signature checking optimization and protection against compromised ISPs. And you can disable hardened checkpoints verification in bitcoin.
Fair enough. This will need to be changed, thanks.

GPG key ID: 5E4F108A || BTC: 1hoardyponb9AMWhyA28DZb5n5g2bRY8v
St.Bit
Sr. Member
****
Offline Offline

Activity: 280


View Profile
January 04, 2014, 04:02:19 PM
 #1647

No need to add another signing as PoS works in a similar way, anyway. PoS was supposed to be a distributed check-pointing and look where it got us. Wink

...

Anyway, I've got the code changes ready. You're all invited to review them. https://github.com/saironiq/yacoin-cc/commit/acf917a2c42cb947b08a9a7878ceafd6045ea24c

I hope that not the reason why you think this way about my idea with decentralized centralized Checkpointing, but I think you don't dislike it just because of that. Anyways:


I know how PoS was "supposed" to work, but basically it's crap now without some mayor changes (even with your new rules additionally). PoS is allowed with wallets that have just 2YAC balance so just having such small PoS block doesn't add any security. On the other hand miners could do the following profitable:

Generate a bunch of small adresses and wait for them to be ready to POS. Once a pool found a PoS they keep it secret and mine a PoW on top of it. Most of the time they will fail to mine a block but they have more time to mine than the rest of the network since they can ophran 1 block. This gives them an advantage over mining without such and would result in loosing a lot of hashpower.

It also destroys the puropse of PoS adding any form of additional security. Where is the security benefit from having PoS-blocks with such little weight. PoS are sacre and unless they become meaningless for security (small PoS witout PoS-rewards). Mining pools wouldn't even have to own these small adresses, they could rent them or buy unpublished blocks. If they pay more than 5% per year even I'd consider splitting up but giving them a unpublished PoS-block is cost free.
A collaterall would prevent any fraud from the owners and would only be paid if miners actually lost some work.

This adjustment would also reduce the security benefits from having PoS at all so we could rather automatically increase every wallet with 5% per year and stop all that madness.

Sign a message and get some YAC: https://bitcointalk.org/index.php?topic=300152.0
St.Bit
Sr. Member
****
Offline Offline

Activity: 280


View Profile
January 04, 2014, 04:29:46 PM
 #1648

Anyway, I've got the code changes ready. You're all invited to review them. https://github.com/saironiq/yacoin-cc/commit/acf917a2c42cb947b08a9a7878ceafd6045ea24c
Good example of simpler != better statement. It will help you for one threat, but opens another hole. Actually, such fix is less secure than calculate block trust using an original algorithm. It can be forked without a significant part of stake or hashpower by running a parallel chain at lower PoS & PoW difficulties. Because it makes no difference between coindays consumed or hashpower wasted. One CPU is able to beat the entire network.
Oh, haven't seen that.

I agree that these changes wouldn't keepit safer for long. Problem with fixing PoS on it's own (Sairon's,NVC's and f.e. PPCs)has usually major negative sideeffects. NVC's solution gives huge inflation and I think this would hurt YAC significantly more that it hurts NVC so be shouldn't go there.


On the other hand am I not able to find any loopholes in my Decentralized Centralized Checkpointing-idea and it's simple.
It doesn't change anyting for 99% of the people owning YAC and only a few rich guys get higher rewards for their effords.

Decentralized Centralized Checkpointing idea:
Was in this thread a few posts bevor, klick the link to read it. Would still require no 2 PoS blocks touching.

Sign a message and get some YAC: https://bitcointalk.org/index.php?topic=300152.0
alenevaa
Sr. Member
****
Offline Offline

Activity: 287



View Profile WWW
January 04, 2014, 04:40:17 PM
 #1649

Can somebody explain me why there's so many orphaned PoW-blocks in plain English please?
Why this wasn't happened before (in first 6 month)?
Why it happening now!?

Thank you in advance!!

PS: I've read all the posts above  Tongue

██████████████████████
████████████████████████
████████████████████████
████████████████████████
███████████████████████
█████████████████████
████████████████████████
████████████████████████
██████████████████████
██████████████████████
███████████████████████
████████████████████████
████████████████████████
████████████████████████
███████████████████████
██████████████████████
|
WINGS           
Where DAO Unicorns are born
|
.
1st Bitcoin & Ethereum DAO for DAOs
1st Decentralized Chatbot to Smart Contracts Interaction System

|
.
Wings Bounties Earn Eggs
X-Blockchain DAO

St.Bit
Sr. Member
****
Offline Offline

Activity: 280


View Profile
January 04, 2014, 05:18:10 PM
 #1650

Can somebody explain me why there's so many orphaned PoW-blocks in plain English please?
Why this wasn't happened before (in first 6 month)?
Why it happening now!?

Thank you in advance!!

PS: I've read all the posts above  Tongue
I belive most of those PoW were unintentionally orphraned, but it could also be abused.

Sometimes your client wasn't able to get a freshly generated PoS into the blockchain. If you have other adresses that can PoS you are the only one that sees your longer chain and begins to PoS on top of your not acepted PoS block.

If you then resend your block(s) you orphran all other PoS-blocks if your chain has higher trust.
The more txt you have in your wallet it lags more and more and it becomes more likely that you block doesn't get transmitted on the first try and some people resend then manually.

Sign a message and get some YAC: https://bitcointalk.org/index.php?topic=300152.0
bitdwarf
Sr. Member
****
Offline Offline

Activity: 378


The cryptocoin watcher


View Profile WWW
January 04, 2014, 08:10:22 PM
 #1651

PoS is allowed with wallets that have just 2YAC balance

Maybe PoS minimum stake should depend on PoS difficulty, so small amounts are never staked if there's no need to.

https://twitter.com/bitdwarf · 𝖄𝖆𝖈: YF3feU4PNLHrjwa1zV63BcCdWVk5z6DAh5 · 𝕭𝖙𝖈: 12F78M4oaNmyGE5C25ZixarG2Nk6UBEqme
Ɏ: "the altcoin for the everyman, where the sweat on one's brow can be used to cool one's overheating CPU" -- theprofileth
Joe_Bauers
Hero Member
*****
Offline Offline

Activity: 782


GCVMMWH


View Profile
January 05, 2014, 03:14:04 AM
 #1652

Balthazar, thanks very much for your input! Cool

So, what does everyone thing we should do?  I think if something isn't agreed upon soon, it may be a good idea to just rebase YAC to the latest NVC source. 
Balthazar
Legendary
*
Offline Offline

Activity: 2100


Post rank racist


View Profile
January 05, 2014, 04:00:40 AM
 #1653

I know how PoS was "supposed" to work
There are serious reasons to doubt this. Roll Eyes

but basically it's crap now without some mayor changes
It works as it was designed, and there is no crap except constant values which were chosen by hand of original developer. PoW blocks target spacing must be higher or at least equal to PoS blocks target spacing, because this system is originally designed for "slow" PoW blocks and "fast" PoS blocks. It doesn't work in the perverted version and there is nothing strange here. Orphans is just another part of self-regulation in this complex system. If developer tries to set PoW spacing lower than PoS spacing then network just forces him to get acceptable PoS/PoW ratio.

If you wish to have a "fast" PoW blocks then you need another system, because this system won't allow you so. You need cunicula's concept or something like that. I.e. no PoW and PoS blocks, but a homogenious chain with a new block type. It's even possible to reuse the current code by removing PoW blocks support and forcing PoS blocks to have a suitable header hash.

PoS is allowed with wallets that have just 2YAC balance
Such threshold looks like allowing the PoW generation only for miners with 8 or 10+ MH/s. I mean it's pretty senseless and won't change anything. This measure is only able to increase an extent of the problem by decreasing active inputs amount.

Maybe PoS minimum stake should depend on PoS difficulty, so small amounts are never staked if there's no need to.
Recursion here, you can't define an argument of difficulty function as a function of difficulty. Smiley

novaco.in | Etherium mining pool (20 GH/s)
฿: 1GV8D5SRkA3cPccpYhVc2wMkjwz3UREEpy: 4RgnHWtnJWEyMhqhDdazW3Hdr7cx5ybF6i ETH: 0x215c86bc952b0d98c4b2313a0a9ae56fa33c7f5d
aso118
Legendary
*
Offline Offline

Activity: 1372



View Profile
January 05, 2014, 10:44:20 AM
 #1654

I've read all of the recent posts (twice actually) and gave this a lot of thought...

Anyway, I've got the code changes ready. You're all invited to review them. https://github.com/saironiq/yacoin-cc/commit/acf917a2c42cb947b08a9a7878ceafd6045ea24c

I think Sairon's fix is the best solution at the moment.  It seems to be easy to implement and it will solve the immediate issue.  While there may need to be other 'tweeks' down the road, we need to get YAC back up and running.  The inconstancy on Cryptsy and other market charts / exchanges aren't helping improve YAC's reputation and community.  Without either of these, I don't think we will have a chance to face some of these other issues...

I think if something isn't agreed upon soon, it may be a good idea to just rebase YAC to the latest NVC source. 

I am (personally) not in favor of this.  Nothing against Novacoin but; YAC was branched from PPC/NVC and there has been a lot of development work to make it a unique (and useful) coin.  And by copying NVC's PoS modifications, we begin to lose some of our uniqueness.  And YAC isn't another 'clone' coin.  If it was; it would have been named CAC - Clone Another Coin....

If we do decide to move forward with Sarion's hard-fork, I am in favor of doing it by Feb 1st.  This gives 4 weeks for all pools and miners to update their software.  I believe this is more than enough time to properly communicate to everyone.  Also, a few thoughts / questions about how POS after this hard-fork.

Our block target for YAC is one minute.  This would imply that there would be a maximum of 720 POS blocks per day.  As YAC continues to grow, this may not offer many opportunities for people to mint their transactions.  Therefore, is it possible to....

1) Mint more than one transaction at once/per block? (i.e. Five transactions of 10 YAC w/ one coin-year each, in an unlocked wallet would mint in the same block, and be returned a single transaction (50.50 YAC)
2) Increase/remove the 'coin-age' cap? (I believe transactions stop gaining 'coin-age' after 90 days) 

IMO - These adjustments will allow people to continue to fairly PoS mine YAC, with out compromising any of the security or fundamental features of YAC.

 

██████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████
 
Get Free Bitcoin Now!
¦¯¦¦¯¦    ¦¯¦¦¯¦    ¦¯¦¦¯¦    ¦¯¦¦¯¦
0.8%-1% House Edge
sairon
Sr. Member
****
Offline Offline

Activity: 406


One does not simply mine Bitcoins


View Profile
January 05, 2014, 11:22:39 AM
 #1655

I've added a small fix that preserves the old block trust model for blocks <400k (oops). https://github.com/saironiq/yacoin-cc/commit/2a394a39c2133aa600b81580f587733b2498a01d

I've also been thinking abount the issue Balthazar found (generating lower-difficulty fork from last checkpoint). The only way it can be achieved (the lower diff) is by faking the timestamps in the blocks (to keep diff low) and generating a longer chain than the current main chain. By faking the timestamps to be more distant from each other the difficulty is kept low. This, however, results in the attacker's fake longer chain to have a timestamp from the future - possibly more than the allowed clock-drift (depends on the length of the faked chain. If the timestamp is higher than "now + allowed drift", then such block is rejected by the client - thus fixing this issue.

The only open question is how long can the fake chain be to fit into the allowed clock-drift window.

One solution is reducing the nMaxClockDrift parameter in the code from the current 2 hours (!!!). I'd personally go for something like 15 minutes or so, as your system time needs to be faily accurate to even use HTTPS sites. Hell, even time-based one-time pads (TOTP) need clock accuracy to be within 1 minute (this is the thing you use for two-factor auth, eg. with Google's Authenticator)! And most operating systems keep the time updated for you automatically, anyway.

It's just a simple change, see:
https://github.com/saironiq/yacoin-cc/commit/ad5533d015ea910f4ebfb569f3065186b8923ae6

GPG key ID: 5E4F108A || BTC: 1hoardyponb9AMWhyA28DZb5n5g2bRY8v
sairon
Sr. Member
****
Offline Offline

Activity: 406


One does not simply mine Bitcoins


View Profile
January 05, 2014, 12:19:58 PM
 #1656

Err, WTF?
https://en.wikipedia.org/wiki/Yacoin
(page deleted)

https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Yacoin

GPG key ID: 5E4F108A || BTC: 1hoardyponb9AMWhyA28DZb5n5g2bRY8v
Balthazar
Legendary
*
Offline Offline

Activity: 2100


Post rank racist


View Profile
January 05, 2014, 03:18:24 PM
 #1657

This, however, results in the attacker's fake longer chain to have a timestamp from the future - possibly more than the allowed clock-drift (depends on the length of the faked chain. If the timestamp is higher than "now + allowed drift", then such block is rejected by the client - thus fixing this issue.
Nope, this maxClockDrift condition is just a sanity checking threshold against the node with invalid time settings. It's not necessary to publish a chain immediately, real attacker will be able to publish his chain in any moment of the future. And clockdrift condition won't be able to prevent this.

I can generate chain and publish it a month or even year later... And it will overwrite the main chain if there are no checkpoints added. Just because there is no way to make a difference between valid or invalid timestamps if these timestamps are in the past.

novaco.in | Etherium mining pool (20 GH/s)
฿: 1GV8D5SRkA3cPccpYhVc2wMkjwz3UREEpy: 4RgnHWtnJWEyMhqhDdazW3Hdr7cx5ybF6i ETH: 0x215c86bc952b0d98c4b2313a0a9ae56fa33c7f5d
sairon
Sr. Member
****
Offline Offline

Activity: 406


One does not simply mine Bitcoins


View Profile
January 05, 2014, 04:01:24 PM
 #1658

This, however, results in the attacker's fake longer chain to have a timestamp from the future - possibly more than the allowed clock-drift (depends on the length of the faked chain. If the timestamp is higher than "now + allowed drift", then such block is rejected by the client - thus fixing this issue.
Nope, this maxClockDrift condition is just a sanity checking threshold against the node with invalid time settings. It's not necessary to publish a chain immediately, real attacker will be able to publish his chain in any moment of the future. And clockdrift condition won't be able to prevent this.

It's just an additional measure to prevent (well, lower the risk) the live nodes from being fooled, so they can continue building on top of the valid chain.

I can generate chain and publish it a month or even year later... And it will overwrite the main chain if there are no checkpoints added. Just because there is no way to make a difference between valid or invalid timestamps if these timestamps are in the past.

Yeah, but exactly HOW can you make a valid chain that's LONGER than the previous valid chain in SHORTER time while spending considerably LESS energy to do it?

And now the same with hard checkpoints enabled.

GPG key ID: 5E4F108A || BTC: 1hoardyponb9AMWhyA28DZb5n5g2bRY8v
Balthazar
Legendary
*
Offline Offline

Activity: 2100


Post rank racist


View Profile
January 05, 2014, 04:28:53 PM
 #1659

Yeah, but exactly HOW can you make a valid chain that's LONGER than the previous valid chain in SHORTER time while spending considerably LESS energy to do it?
1. I need some time to recalculate a difficulty, but once difficulty is recalculated I can generate as many blocks as I need. 100, 1000 or even 10000 blocks could be generated without any problem. The only thing I need is a modified software.

2. Actually I don't need do it in shorter time. I can use my wallet for payments as usual while alternate chain is generated. A week/month/year later I'm publishing a fake chain which removes all of my transactions during this period from the main chain.

Such attack is impossible in Bitcoin or Novacoin, because those networks are able to see the difference between diff1 and diff2 blocks. But your version of YACoin makes no difference between such blocks.

And now the same with hard checkpoints enabled.
The purpose of checkpoints is not a chain consistency control, chain should be able to control itself. Those checkpoints are able to prevent such type of attack, but it's not a solution. It's just another workaround.

novaco.in | Etherium mining pool (20 GH/s)
฿: 1GV8D5SRkA3cPccpYhVc2wMkjwz3UREEpy: 4RgnHWtnJWEyMhqhDdazW3Hdr7cx5ybF6i ETH: 0x215c86bc952b0d98c4b2313a0a9ae56fa33c7f5d
Joe_Bauers
Hero Member
*****
Offline Offline

Activity: 782


GCVMMWH


View Profile
January 05, 2014, 07:38:47 PM
 #1660


Good thing I copied it all and added to yacoin.org before it was deleted  Wink I also setup a redirect to your explorer page (explorer.yacoin.org) as was done on yacointalk.
Pages: « 1 ... 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 [83] 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 ... 169 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!