Bitcoin Forum
September 22, 2021, 12:30:44 AM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 134 135 136 ... 179 »
  Print  
Author Topic: [ANN][YAC] YACoin ongoing development  (Read 378890 times)
Thirtybird
Hero Member
*****
Offline Offline

Activity: 693
Merit: 500



View Profile
January 09, 2014, 04:57:07 PM
 #1701

Yeah, but another flaw is that the protocol does not enforce alternation of PoW and PoS. Say an attacker somehow manages to make a chain that 100% alternates between PoW and PoS - it WILL have higher trust score and WILL overwrite the old chain. Also note that this type of attack will have lower energy cost than the network spent on its non-perfect chain. Perfect chain costs less (!!) than imperfect one.

However, if we were to actually enforce such alternation, pools will be starving when PoS block should be generated.

I didn't think forcing alternation was on the roadmap, just disallowing consecutive POS blocks.  If a chain that has both POW and POS blocks in it has a higher trust than a purely POW or a purely POS chain, doesn't that go a long way toward what we're trying to accomplish?

YACMiner: https://github.com/Thirtybird/YACMiner  N-Factor information : https://docs.google.com/spreadsheet/ccc?key=0Aj3vcsuY-JFNdC1ITWJrSG9VeWp6QXppbVgxcm0tbGc&usp=drive_web#gid=0
BTC: 183eSsaxG9y6m2ZhrDhHueoKnZWmbm6jfC  YAC: Y4FKiwKKYGQzcqn3M3u6mJoded6ri1UWHa
1632270644
Hero Member
*
Offline Offline

Posts: 1632270644

View Profile Personal Message (Offline)

Ignore
1632270644
Reply with quote  #2

1632270644
Report to moderator
1632270644
Hero Member
*
Offline Offline

Posts: 1632270644

View Profile Personal Message (Offline)

Ignore
1632270644
Reply with quote  #2

1632270644
Report to moderator
1632270644
Hero Member
*
Offline Offline

Posts: 1632270644

View Profile Personal Message (Offline)

Ignore
1632270644
Reply with quote  #2

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

Activity: 637
Merit: 500


View Profile
January 09, 2014, 05:30:42 PM
 #1702

Why not use centralized checkpointing ?? That's what PPC does because there is no solution to the problem (yet).
bitdwarf
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250


The cryptocoin watcher


View Profile
January 09, 2014, 07:35:03 PM
 #1703

However, if we were to actually enforce such alternation, pools will be starving when PoS block should be generated.

Considering pools are a source of risk in themselves for little advantage to the network, that's not a problem.

𝖄𝖆𝖈: 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: 3080
Merit: 1344


Worship the Eru


View Profile
January 09, 2014, 07:45:13 PM
 #1704

Why not use centralized checkpointing ?? That's what PPC does because there is no solution to the problem (yet).
There are enough possible solutions and BCP is not a one of these. It's just a workaround.

Darkness isn't born, you know. It's created.
cryptrol
Hero Member
*****
Offline Offline

Activity: 637
Merit: 500


View Profile
January 09, 2014, 11:08:19 PM
 #1705

Why not use centralized checkpointing ?? That's what PPC does because there is no solution to the problem (yet).
There are enough possible solutions and BCP is not a one of these. It's just a workaround.
And none works well AFAIK, that's one of the reasons PPC is centrally checkpointed ATM. Please, correct me if I am wrong.
ilostcoins
Sr. Member
****
Offline Offline

Activity: 274
Merit: 250



View Profile
January 10, 2014, 03:30:11 AM
 #1706

As far as I can see now, using difficulty as score for POW blocks, and let POS blocks inherit that score from the previous POW block is a good enough solution for the problem on hand. Whether one POS block following another POS block is explicitly ruled out or not, I think it should be ok either way.

The Novacoin solution of encouraging a hybrid chain only make sense because they have 1:1 POW:POS blocks ratio. YACoin is 10:1 with POW:POS. You'll need to check pretty deep into the past to encourage a 10:1 ratio. The score consistency problem I mentioned above could lurk in such schemes. Of course, we can also talk about the POW:POS ratio if people want to change it.

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

Activity: 406
Merit: 250


One does not simply mine Bitcoins


View Profile
January 11, 2014, 12:00:30 AM
 #1707

I would leave the target spacing for PoW and PoS as is. It really doesn't matter anyway with this scheme, so why bother.

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

Activity: 274
Merit: 250



View Profile
January 11, 2014, 01:30:33 AM
 #1708

If anyone can see some problems with the scheme, please post about it sooner rather than later.

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

Activity: 406
Merit: 250


The cryptocoin watcher


View Profile
January 11, 2014, 01:34:24 AM
 #1709

I'd think you'd want the good chain to maximize as much as possible its score. So either 1:1 ratio, or the max score should be when ratio is 10:1. E.g. PoS score increases the more PoW ancestors it has, maxxing at 9, then PoW score decreases the further away it is from a PoS, up until 9.

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

Activity: 115
Merit: 10


View Profile
January 12, 2014, 02:46:07 AM
 #1710

As far as I can see now, using difficulty as score for POW blocks, and let POS blocks inherit that score from the previous POW block is a good enough solution for the problem on hand. Whether one POS block following another POS block is explicitly ruled out or not, I think it should be ok either way.

The Novacoin solution of encouraging a hybrid chain only make sense because they have 1:1 POW:POS blocks ratio. YACoin is 10:1 with POW:POS. You'll need to check pretty deep into the past to encourage a 10:1 ratio. The score consistency problem I mentioned above could lurk in such schemes. Of course, we can also talk about the POW:POS ratio if people want to change it.

I absolutely agree with the ratio of 10:1 and when you think about it, it's more like 20:1 at least. We do not have many POS in YAC now at all, I do not understand why the sudden rush and madness to "fix" POS when there is hardly any POS at all. Has anyone looked at the blockchains that we are comparing YAC to, meaning PPC and NovaCoin, they are 90% POS or more.

Is there are alternate motive behind all this?

Ɏ : YEojPD2QxFVaSUypTLYhwJgmVekqoAtdE3
฿ : 1946hwLbBdLNSA1FFUY3ZvRx6j6dqvbzcE
Ł : LczTrStBZ8b1Y4DJU59CjtYRtjKufbTXPE
Ғ : 6i4S4BfHfC9LLmTBhjYDVKe7g8XfPz9uj8
Ψ : AGpoWwc6N59PPqKbzRTAiFG5WmDEQU7Ydp
ζ : ZLYFK2KNrFDDGVbEJPKnTdWuGk3iA3CNY2
G : GQbjHcGPgUwRBKZcdoMCpuf24QSXY5t5bf
St.Bit
Sr. Member
****
Offline Offline

Activity: 280
Merit: 250


View Profile
January 12, 2014, 05:00:07 PM
 #1711

We do not have many POS in YAC now at all, I do not understand why the sudden rush and madness to "fix" POS when there is hardly any POS at all. Has anyone looked at the blockchains that we are comparing YAC to, meaning PPC and NovaCoin, they are 90% POS or more.

Is there are alternate motive behind all this?
Well, the current system isn't safe from doublespends so that's the main motivation behind this.
Question will be how to fix this mess here, or if there's even an acceptable fix for it.

PS: A big part of the problem is that "there is hardly any POS at all"


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

Activity: 118
Merit: 10


View Profile
January 12, 2014, 05:09:55 PM
Last edit: January 12, 2014, 09:06:10 PM by senj
 #1712

Here are my refined strategy concepts now partly borrowed from Satoshi:)


When PoW block arrives modulo operation is executed on last 4 bytes of the hash. If remainder equals zero, PoS window opens. Divisor would determine chance of that happening and it could be:

a) static (with optional hardcoded decrements on Nfactor change)

Miner gone bad would need to hash like crazy (even many times the same block EDIT: after one hash is found) in order to meet conditions that would allow him to pack more PoS blocks in the chain.

b) dynamic, derived from PoW block difficulty

Difficulty extracted from last PoW block combined with N factor,  both input into modulo operation would influence chance of PoS block window. Normally high difficulty and considering N would be set to produce a chain with more PoS blocks. This way the chain would balance itself through time ( more widespread yacoin usage -> high hashrate -> high difficulty -> higher chance of success for PoS blocks windows ). Determining N factor change implications would be challenging at least, since that lowers difficulty at first in spite of  more miners.

If longer chain fork is announced and it's blocks do not connect anywhere in the recent past chain is rejected. If it connects, the pattern of PoS windows is inspected and PoW blocks difficulty of both forks is compared.



I have another dynamic solution in mind, where delayed difficulty cumulative moving average (DCMA) would be used in PoS window calculation.

Record of delayed running DCMA would be calculated and kept up-to-date until the time of approx. now-2000 blocks. That number would be transformed and merged with last 4 bytes of PoW hash before modulo operation is executed. Effectively we would be "encoding" average PoW block difficulty from the past into the criteria for PoS block window.

It would be nearly impossible for the rogue miner to hash on low difficulty far in the future and then switch to high difficulty - he would need to guess DCMA at the publish time of his chain (minus 2000 blocks) in advance, because that is how chains would be compared if his fork signals to be longer. If new blocks start orphaning many of our blocks, "headers" call is invoked and latest 2000 headers are fetched, their start time determined, corresponding DCMA for that start time acquired from our records (or even calculated from history data if operation is not too expensive) and then PoS windows pattern checked if it fits the formula. To accomplish that we would also need to keep a small rolling window of delayed DCMAs.

This last method would sure need more analyzing, planning and discussion. It would be hardest to implement, but from my understanding would offer trustworthy chain compare method.


Independently from the chain trust concept just mentioned above I have been also considering higher number of PoS windows than average (or needed at specific time), but not making them all mandatory - some window criteria matches would just "award" incoming PoS blocks with desired trust score. This way it would be possible to impose minimum PoS block occurrence threshold while at the same time making possible for more PoS blocks to be accepted in the chain (when window opens). But that would at least to some degree mess with the concept explained above.


I hope my explanation is understandable -  I have looked at source code and tried to grasp the functioning but it's not that trivial for a rookie. Except for DCMA method, not a lot of code would need to be written but that wouldn't bring solution for chain trust either.
Balthazar
Legendary
*
Offline Offline

Activity: 3080
Merit: 1344


Worship the Eru


View Profile
January 13, 2014, 01:32:28 AM
Last edit: January 13, 2014, 02:36:41 AM by Balthazar
 #1713

2 all

Guys, I suppose that you need block hashes caching , this approach would allow you to reduce startup time significantly (30x-100x times at least). This could be done through merging with NVC blockindex code and addition of your network rules.

I think this will resolve all your performance issues.

Darkness isn't born, you know. It's created.
sairon
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250


One does not simply mine Bitcoins


View Profile
January 13, 2014, 08:37:20 AM
 #1714

2 all

Guys, I suppose that you need block hashes caching , this approach would allow you to reduce startup time significantly (30x-100x times at least). This could be done through merging with NVC blockindex code and addition of your network rules.

I think this will resolve all your performance issues.

Already done.
Didn't know it was in NVC, though. Would have been easier to pull the changes rather than write it from scratch. Tongue

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

Activity: 3080
Merit: 1344


Worship the Eru


View Profile
January 13, 2014, 09:48:27 AM
 #1715

Hm... Just checked your sourcecode. It seems too overcomplicated for me, actually. This issue could be resolved with less than 10 additional lines of code. Maybe even 4-6 lines...

Darkness isn't born, you know. It's created.
sairon
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250


One does not simply mine Bitcoins


View Profile
January 13, 2014, 09:54:15 AM
 #1716

Hm... Just checked your sourcecode. It seems too overcomplicated for me, actually. This issue could be resolved with less than 10 additional lines of code. Maybe even 4-6 lines...
Whatever. The whole Bitcoin codebase is crap anyway.

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

Activity: 3080
Merit: 1344


Worship the Eru


View Profile
January 13, 2014, 09:58:49 AM
 #1717

Maybe Satoshi need to learn some features from C99/C++0x/boost to write a readable code without portability issues. But it's definately not a crap.

Anyway, I have no problem with understanding a Bitcoin code.

Darkness isn't born, you know. It's created.
sairon
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250


One does not simply mine Bitcoins


View Profile
January 13, 2014, 10:04:26 AM
 #1718

Maybe Satoshi need to learn some features from C++0x and boost to write readable code without portability issues. But it's definately not a crap.
It's C++11 already.
Oh well, at least it works, somehow...

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

Activity: 3080
Merit: 1344


Worship the Eru


View Profile
January 13, 2014, 10:10:07 AM
 #1719

It's C++11 already.
Bitcoin was written during 2008-2009.

Oh well, at least it works, somehow...
C++11 doesn't work sometimes. Just because there are only a few compilers supports it and this support is still under active development. It's easy to write C++11 code for g++-4.8, which will be impossible to compile with 4.6, for example.

Darkness isn't born, you know. It's created.
sairon
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250


One does not simply mine Bitcoins


View Profile
January 13, 2014, 10:20:20 AM
 #1720

It's C++11 already.
Bitcoin was written during 2008-2009.
Sure it was. Maybe even earlier.
Just saying that C++0x was already standardized (and renamed) as C++11.

Oh well, at least it works, somehow...
C++11 doesn't work sometimes. Just because there are only a few compilers supports it and this support is still under active development. It's easy to write C++11 code for g++-4.8, which will be impossible to compile with 4.6, for example.
I don't see the problem here. g++ 4.8 is already available even for that windoze crap.
BTW, libbitcoin has a much nicer/cleaner codebase. I'd like to see new alts based on that.

GPG key ID: 5E4F108A || BTC: 1hoardyponb9AMWhyA28DZb5n5g2bRY8v
Pages: « 1 ... 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 134 135 136 ... 179 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!