Bitcoin Forum
February 08, 2023, 09:50:59 AM *
News: Community Awards results
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 [29] 30 31 32 33 34 35 36 37 38 39 40 41 42 43 »
  Print  
Author Topic: [ANN] ParallelCoin - DUO - SHA256 + Scrypt | HardFork Soon!!! We are going Go!  (Read 61037 times)
trax0r
Full Member
***
Offline Offline

Activity: 372
Merit: 103

Coinz-Universe


View Profile
September 22, 2018, 08:42:57 AM
 #561

New wallet development is under way:




Also checkout the latest gitlab infos:
https://gitlab.com/parallelcoin/parallelcoin
1675849859
Hero Member
*
Offline Offline

Posts: 1675849859

View Profile Personal Message (Offline)

Ignore
1675849859
Reply with quote  #2

1675849859
Report to moderator
1675849859
Hero Member
*
Offline Offline

Posts: 1675849859

View Profile Personal Message (Offline)

Ignore
1675849859
Reply with quote  #2

1675849859
Report to moderator
"This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1675849859
Hero Member
*
Offline Offline

Posts: 1675849859

View Profile Personal Message (Offline)

Ignore
1675849859
Reply with quote  #2

1675849859
Report to moderator
1675849859
Hero Member
*
Offline Offline

Posts: 1675849859

View Profile Personal Message (Offline)

Ignore
1675849859
Reply with quote  #2

1675849859
Report to moderator
litecoinricky
Jr. Member
*
Offline Offline

Activity: 171
Merit: 3

I need a break!


View Profile
October 11, 2018, 12:39:45 AM
 #562

New wallet development is under way:




Also checkout the latest gitlab infos:
https://gitlab.com/parallelcoin/parallelcoin


Whats the ETA on the new wallet release, all is looking great so far Smiley

Also where is everyone hanging out, slack seems a little quiet lately, and there are just so many social hangouts I lose track lol Sad 
But what I do know is the team is still working hard on DUO, Ive been keeping a close eye on GITHUB and the regular updates are making me very excited for the coming months.

I'll take any freebies on offer Smiley
coolindark
Legendary
*
Offline Offline

Activity: 955
Merit: 1034



View Profile WWW
October 11, 2018, 10:13:02 PM
 #563

Cool Keep Calm and Always Use CoinMiners! ParallelCoin is active in our pool!  Cool
You can use market wallet address for mining!

CoinMiners.Net Pool

10% Fee
Register-free Mining & Auto Payments
Server located at USA
http://coinminers.net
CoinMiners Community Discord : https://discord.gg/VJ8nCmP

And CoinDL just compiled ParallelCoin Windows Wallet  Cool

Reach from here : CoinDL.net – Cryptocurrecy Coin Downloads Repository - ParallelCoin

ʕ•̫͡•ʕ*̫͡*ʕ•͓͡•ʔ-̫͡-ʕ•̫͡•ʔ*̫͡*ʔ-̫͡-ʔʕ•̫͡•ʕ*̫͡*ʕ•͓͡•ʔ-̫͡-ʕ•̫͡•ʔ*̫͡*ʔ-̫͡-ʔ
ʕ•̫͡•ʕ*̫͡*ʕ•͓͡•ʔ-̫͡-ʕ•̫͡•ʔ*̫͡*ʔ-̫͡-ʔʕ•̫͡•ʕ*̫͡*ʕ•͓͡•ʔ-̫͡-ʕ•̫͡•ʔ*̫͡*ʔ-̫͡-ʔ
trax0r
Full Member
***
Offline Offline

Activity: 372
Merit: 103

Coinz-Universe


View Profile
October 13, 2018, 08:01:48 AM
 #564

New wallet development is under way:




Also checkout the latest gitlab infos:
https://gitlab.com/parallelcoin/parallelcoin


Whats the ETA on the new wallet release, all is looking great so far Smiley

Also where is everyone hanging out, slack seems a little quiet lately, and there are just so many social hangouts I lose track lol Sad 
But what I do know is the team is still working hard on DUO, Ive been keeping a close eye on GITHUB and the regular updates are making me very excited for the coming months.

Parellelcoin (DUO) dev and team is very active on Discord.
Please join there: https://discord.gg/uYm3sK
trax0r
Full Member
***
Offline Offline

Activity: 372
Merit: 103

Coinz-Universe


View Profile
October 13, 2018, 08:06:10 AM
 #565

Cool Keep Calm and Always Use CoinMiners! ParallelCoin is active in our pool!  Cool
You can use market wallet address for mining!

CoinMiners.Net Pool

10% Fee
Register-free Mining & Auto Payments
Server located at USA
http://coinminers.net
CoinMiners Community Discord : https://discord.gg/VJ8nCmP

And CoinDL just compiled ParallelCoin Windows Wallet  Cool

Reach from here : CoinDL.net – Cryptocurrecy Coin Downloads Repository - ParallelCoin
Thank you for adding Parallelcoin to your pool. Good to have more mining pools for DUO.
ligor
Full Member
***
Offline Offline

Activity: 1246
Merit: 138


Hodl DeepOnion


View Profile WWW
October 16, 2018, 05:38:35 PM
 #566

No fresh blocks  Huh


trax0r
Full Member
***
Offline Offline

Activity: 372
Merit: 103

Coinz-Universe


View Profile
October 17, 2018, 06:20:18 AM
 #567

No fresh blocks  Huh



Either noone is currently mining or the mining difficulty is again so high, that finding a new block is very hard.
But after checking the block explorer it seems that many new blocks have been found in the last hours.. so everything is fine.. Smiley
cslinz
Newbie
*
Offline Offline

Activity: 73
Merit: 0


View Profile WWW
October 24, 2018, 01:17:50 PM
Last edit: October 24, 2018, 01:28:10 PM by cslinz
 #568


Algo switched from sha256 to scrypt:


DUO mining with scrypt algo on http://cryptopool.at

1% fee, very fast payout every 30min after maturity

-o stratum+tcp://cryptopool.at:3433 -u <WALLET_ADDRESS> -p c=DUO,mc=DUO
sonja1
Newbie
*
Offline Offline

Activity: 80
Merit: 0


View Profile
November 03, 2018, 03:33:24 PM
 #569

I have many of the DUO-coins. When will it rise again?Huh
trax0r
Full Member
***
Offline Offline

Activity: 372
Merit: 103

Coinz-Universe


View Profile
November 05, 2018, 10:45:04 AM
 #570

I have many of the DUO-coins. When will it rise again?Huh

Nice to hear you are also a DUO holder.

Well, I cannot tell, when DUO will rise again (depends on what you define for a rise - in the last 2 days the coin did rise about 500-1000 satoshi).

But what I can tell is that the development of the new go-language DUO wallet (new Parallelcoin wallet) is ongoing since many months and on last weekend the dev managed to load the full blockchain (a full node) with the new developed wallet.

So there should be a first release of the wallet in the next weeks. The question is, which of the many new features that are planned, will be part/implemented and released in the first new go-language DUO wallet.

I advise you to join Discord, where on regular basis new steps of the development are posted and further news are available, too.

Follow this link: https://discord.gg/MjTxkk

trax0r
Full Member
***
Offline Offline

Activity: 372
Merit: 103

Coinz-Universe


View Profile
November 05, 2018, 01:56:58 PM
 #571

Shocked Shocked Shocked
First fully working full DUO node just got released (please note, it is still alpha)  Cheesy Wink

You can check it out here:
https://github.com/parallelcointeam/pod/releases/tag/v0.1.0alpha

There are binaries for all architectures (Windows and Linux). It should be possible to use this to run a node to solo mine to.

Anyone who wants to try it please let the dev (loki) know if you bump into any problems.

trax0r
Full Member
***
Offline Offline

Activity: 372
Merit: 103

Coinz-Universe


View Profile
November 13, 2018, 02:05:29 PM
 #572

Again good news: Today an update of the suite of core apps was released.  Cool

It is the suite of core apps for Parallelcoin cryptocurrency network - parallelcointeam/pod

https://github.com/parallelcointeam/pod/releases/tag/v0.1.1-alpha

The full node and the CLI client are both fully functional and seemingly bug-free.  Wink
trax0r
Full Member
***
Offline Offline

Activity: 372
Merit: 103

Coinz-Universe


View Profile
November 14, 2018, 07:18:19 AM
 #573

DUO Market on Cryptopia has been paused today as on our (DUO team) request.

This was necessary as there are ongoing attacks on the DUO blockchain.

Our dev is looking into the issue and we will solve this problem within the next days.

Stay tuned for more infos.

You can also join DUO on discord for the latest news. Follow this link: https://discord.gg/eEunhn

openbit
Copper Member
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
November 14, 2018, 07:22:58 AM
 #574





Please let us know the projects that you want to be listed.

Fee


Sell: 0.5%
Buy:0.5%


https://bitcointalk.org/index.php?topic=5068678

Dev Team: info@openbit.online
Market : market@openbit.online
Discord:https://discord.gg/E3Fh9ZA
Add Coin:https://market.openbit.online/Article/detail/id/121

trax0r
Full Member
***
Offline Offline

Activity: 372
Merit: 103

Coinz-Universe


View Profile
November 22, 2018, 11:28:15 AM
 #575

Good news today Cheesy :

The Core blockchain client for the Parallelcoin network >>> Beta release <<< is now ready for testing:

https://github.com/parallelcointeam/pod/releases/tag/v0.1.2-beta

Please let loki know any bugs you might find.
lokiverloren
Newbie
*
Offline Offline

Activity: 85
Merit: 0


View Profile
November 24, 2018, 10:54:33 PM
 #576

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

As you can all see from @traxor's updates, I have been very very busy.

This morning I finished up with getting the wallet daemon (mod - because it's modular, and that's a nice short name). The new full node and wallet are based on btcsuite btcd and btcwallet, with all the necessary changes for it to conform to the existing consensus.

They can be found here: https://github.com/parallelcointeam/pod and https://github.com/parallelcointeam/mod I will be making a full release with installation packages for Windows, Mac, Debian/Ubuntu, Redhat/Suse and I have an account at the arch linux AUR and I will make a PKGBUILD for it also, and it will be available through the AUR (I'll make a binary, version pinned build and a rolling master branch build).

The new full node runs two separate RPCs for miners and pools to use, defaults to 11048 for sha256d and 11049 for scrypt. The full node, CLI controller and wallet daemon all autoconfigure for localhost access and integrates the full node and wallet automatically, both `podctl` and `mod` on first run with no configuration will copy the RPC credentials so you can get up and running quick and easy. The wallet daemon listens by default to port 11046

It got quite exciting a few weeks back as somebody with access to a lot of mining power started to put out blocks with different version numbers, which it turns out the old client treats as sha256d blocks. Then they started using 'Big S' signatures, which are part of the hypothetical signature malleability double spend attack - and then sure enough, logs started showing blocks coming in that were rejected because the outputs were already spent. The latest seems to be that they are trying to mine a side chain, but so far it looks like the rest of the miners have enough hash power to keep the head at the front.

Our secret shopper, whoever they are, or maybe they are just a legitimate Wink would-be-blockchain-robber, has ensured that it will be necessary to upgrade the protocol significantly. These are the changes I have in mind:

- - The new client will automatically set the equivalent of a checkpoint at about 288 (2 days) blocks, so that it will automatically block attempts to create side chains and push them ahead with a 51% attack.

- - The difficulty adjustment needs to work from a longer timespan than 50 minutes. I will set it to 4032 blocks, approximately 2 weeks. This is to address the problem that short term bursts of greatly increased hash power is leading to miners printing 10 blocks within a minute and then nothing for hours, which is entirely unsuitable for a real world transactional currency. Extending the averaging window will mean that the difficulty adjusts more slowly and can't be pushed up artificially by timed bursts.

- - Block versions have been messed up by the secret shopper, but after the prescribed hardfork block height they will again be properly enforced and I will design an extensible protocol similar to the one in bitcoin, that allows us to in the future upgrade the protocol using BIP9 softforks.

- - The peer to peer and RPC protocols will be enhanced with a messsagepack binary format protocol and use the OTR/Diffie Hellman Perfect Forward Secrecy encryption protocol, as it is patently retarded to use OpenSSL/GNUTLS, which is based on a web of trust model - which means you have to faff about with certificate authorities to just get it connected. The mechanism will be extended to enable users to make black or whitelists. Web of trust protocols are not identity-secure, as you sign public keys that afterwards the signed keyholder will advertise therefore your approval of them. There might be some purpose to this but I can't think of it. This encryption protocol will also be added to the peer to peer protocol, because in my opinion, even though it's public information, the propagation pattern should be protected at least a little bit, as locations enable attacks.

- - I am planning an SPV wallet, which will have native compiled GUI interface available. The SPV wallet is the testbed and initial showcase/prototype for the peer to peer network extensions I have planned.

- - The first application of this will be in the implementation of a transaction proxy relaying, like the outbound connection component of the Tor network. The nodes will all have a unique identifying EC keypair (ed25519, natch) which will be constructing a wrapper around its transaction broadcast with three layers designating the 3 peers that will relay the message. Each node will only know where it came from and where it's going but not whether it is the first, second or last hop before the destination node.

- - From there on, there will be built wrappers and sockets and interfacing libraries that can be used by other applications to connect to the network and use it to find specific subprotocol peers to enable other types of distributed applications, both centralised/federated type applications (eg, diaspora, paxos/raft/sporedb and other federated WoT database protocols) and trust-computed (for example like the Steem reputation system) and trustless (yes, potentially allowing multiple cryptocurrencies to interface directly through the network) peer to peer protocols. In other words, I am aiming to make the parallelcoin network the wires to connect a whole ecosystem of applications.

When I have completed the releases, with all the installers made for all of the above mentioned platforms (and if anyone has specific requests) - and already you can see on the newest release that @trax0r posted, there is literally binaries for almost every platform in existence, I will make a new ANN thread for discussion and feedback.
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQThc/kXLToA5xCfIuOCA/USO9KcBAUCW/nWowAKCRCCA/USO9Kc
BJdXAQD/+BxK5stddGlA1InaDDrF6GI74Dfqz62E2Qu5E7mqCgEApeF9r1SRvS4c
rveVObyPNZ5DJNMIkMVlpsRT0rZIhA0=
=EmXt
-----END PGP SIGNATURE-----
lokiverloren
Newbie
*
Offline Offline

Activity: 85
Merit: 0


View Profile
November 29, 2018, 07:28:07 AM
 #577

Just a minor update regarding planned hardfork changes...

Parallelcoin suffers from a problem with its' difficulty adjustment because of how it is computer. It bases the difficulty adjustment of the measurement of the time between the latest and 9 previous blocks of the same algorithm. This is absurdly short, and typically ranges between 50 and 100 minutes. As such, it is highly vulnerable to what I call a 'rhythmic hashpower attack'. For this, I have two main strategies:

  • A long number of blocks, 4032, being approximately 2 weeks at 5 minute blocks, randomly 50% are selected, the top and bottom 12.5% are removed and the average is computed from this, eliminating sequence and outliers causing the mean to be inaccurately representative of block times. This is to ensure that no type of sequence or rhythm can control the adjustment, and it uses a much longer timescale so it also does not fluctuate wildly up and down chasing the impossible regularity of a poisson process, and so short periods of high hash power do not move the mean above the actual mean.
  • The weights of the 4032 past blocks are added and at the mean of the block weight, difficulty is further adjusted up or down based on a new block's proportion to this average. Below this value difficulty is nominal, above this, the nominal difficulty is multiplied by the factor above the average, and then squared. This does not affect the nominal difficulty, its purpose is to discourage processing all of the blocks when they bank up in one block, meaning more miners get a share of the block fees.

The second part is based on the method used by Freshcoin, which mines most of the supply early. This coin doesn't do that, but it instead has the problem that most blocks have no transactions put in them and they very often are spewed out at 10 at a time within a minute. By raising the difficulty required according to over-average numbers of transactions in a block, it ensures that these high powered pools are not able to deny the loyal, smaller mining pools and solo miners from getting blocks. Possibly I may also consider that below the mean block weight the difficulty scales downwards, meaning that even maybe solo miners have a decent chance of being able to clear one transaction.
lokiverloren
Newbie
*
Offline Offline

Activity: 85
Merit: 0


View Profile
December 07, 2018, 03:32:14 PM
 #578

Just a short little note to update on progress. For the last week, in between the many distractions that have come all at once, I have been developing an improved difficulty adjustment algorithm. The existing one is very prone to oscillation, a problem further compounded by the volatility of hashpower being pointed at the chain.

The new algorithm uses a fairly simple cubic curve that is more or less just, a cubic curve, calibrated to cross at 1,1. It uses the curve against the variance measured by a fixed number of past blocks. The old algorithm attempted to separate them and walks backwards through the chain to gather the last 10 per algorithm, and  then uses a flat linear adjustment, which is basically y=x, or  in other words, if the average time is under by 20%, it will reduce the target by 20%. This is a terrible way to do it, as it increasingly encounters aliasing distortion close to the target caused by the 1 second granularity of the block timestamps.

https://github.com/parallelcointeam/pod/blob/master/docs/parabolic_filter_difficulty_adjustment.md

Two main strategies are used as described in the document above, one is the cubic curve, and the other is that after the adjustment is made against the curve, the last two bits of the 'Bits' are flipped, which ensures that the target is unlikely to fall into a resonant cascade and getting stuck oscillating between long and short blocks over - in this case, typically 4-12 hour periods. This kind of extreme variance is very problematic for users because they literally cannot know when even the first confirmation will come in, better than 'about maybe half a day'. Intentionally adding noise to reduce these kinds of interference and distortion are well proven especially in radio and digital signalling technology in general, it is used by audio devices to reduce unintentional frequencies caused by the samplerate, it is used in most modern IPS and better LCD displays (they used to just do a checkerboard, the fuzz is much nicer on the eyes).

Oh, and one last thing, it does not filter out algorithms from the computation. The minimum target for scrypt blocks on the parallelcoin network is currently the smallest possible value, 7 at the front then lots of f's. Because there isn't many miners using this algorithm, at times the difficulty *will* drop to zero and *will* mean 5-10 blocks can be spewed forth suddenly. Being that mining is supposed to be about the transactions, and reward for doing that work, the incentives are all upside down. So the new algorithm only looks for the most recent one, and uses all of the previous blocks no matter which difficulty - the past difficulty adjustments are irrelevant, what is important is the timestamps. By not distinguishing between algorithms in this computation the block rhythm should be better regulated.

I am basically satisfied with the workings of the new adjustment now, and as you can probably imagine, it's more about staring and watching grass grow than actually coding, so I'm glad and just had to draw a line in the sand about how long I would fiddle with it. There is probably significant improvements possible, but they would be pushing the boundary of diminishing returns. As it stands, the variance from the target is typically held within 20%, and the dithering helps to ensure that strings of short blocks happen far less frequently, now it appears to be the case that more often they come in alternating or sometimes 2, and less frequently, 3 blocks at a time. Also, the very wide variance caused when pool miners dive bomb the chain will be greatly diminished, as such short blocks trigger very big difficulty adjustments, and instead of the current spates of 5-10 blocks under 10 seconds between, it is unlikely that more than 3 will usually happen so quickly, and hopefully they hang around long enough to get a few more at which point the timing will be more normal.

Now it will get a *little* more interesting for me. I have to get the scrypt CPU mining working properly again, I think the two RPC ports properly produce block templates, but this will be checked and fixed if it is not. Then I will be adding more proof of work algorithms. The main thing that will determine what makes the cut for the first hard fork will be that the hash functions are in a Go package. Most of them are covered. I am unsure which, at this point, and I recall looking at Ethash and thinking it would be a huge pain, but Equihash, Cryptonote 7, possibly Cuckoo, x11, and maybe some others like Myriad, Keccac, Skunk and similar. I will aim to ensure that miners with idle GPU capacity can help secure the network against hashpower attacks. Adding merged mining is a considerable undertaking, and if it is going to be done it will be in the second hard fork, if it seems necessary to do this.
litecoinricky
Jr. Member
*
Offline Offline

Activity: 171
Merit: 3

I need a break!


View Profile
December 08, 2018, 07:23:59 PM
 #579

Thanks for the update lokiverloren, very informative as usual Smiley
I hope others appreciate this great work as much as me Smiley
Im a long time DUO holder, and can see a very good future Smiley

I'll take any freebies on offer Smiley
lokiverloren
Newbie
*
Offline Offline

Activity: 85
Merit: 0


View Profile
December 08, 2018, 09:39:05 PM
 #580

It's nice to know I'm not talking to myself  Grin

So, more news, and general commentary. I got through a lot of tasks today and I need to debrief a bit.

There is 7 new algorithms being added: blake14lr (as used in decred), blake2b (sia), Lyra2REv2 (vertcoin), skein (one of myriad's 5), x13 and x11. These were selected because all of the coins that they are associated with have the standart bitcoin mining RPC API, and none of these require any changes to the block header structure (equihash requires an additional 1134 bytes, monero's difficulty adjustment is double the length at 64 bits) and basically most of it is tedious administrative work going through all the places where I already added the support for Scrypt to the btcd base, now there will be 9 in total. I am most of the way through the initial implementation.

The difficulty adjustment deserves a little more discussion. KGW and Dark Gravity Wave are more well known continuous difficulty adjustment algorithms, and as people would know, the Verge attack was due to flaws in the DGW. I spent a lot of the last week staring at logs of the new node mining, well, only one algorithm, but this doesn't substantially matter because all of them are poisson point processes anyway, so if designed right it should behave not too differently with more. It might be a day or two before I have them fully working, and then I can see how my algorithm copes with the multiple algorithms.

So, the existing difficulty adjustment is terrible, I don't know how long the original authors spent testing but I suspect not very long. It bases its calculations on the time between a block of an algorithm and the previous block of the algorithm, with a mere 10 sampled to generate the average upon which it adjusts linearly.

Firstly, yes, of course this new algorithm uses exponents, not squares, as in many of the others, but rather, a cubic curve, which is shifted with adding one to the result and taking one from the divergence ratio (target:actual) then cubing it. This is a slightly rough description:

https://github.com/parallelcointeam/pod/blob/master/docs/parabolic_filter_difficulty_adjustment.md

One subject I didn't fully address because it wasn't on my mind so much as I was simply testing to see how it works, was the matter of how the different algorithms cooperate with each other. The many schemes I see, monero's and others, do a LOT of processing and slicing and weighting and such, and I think if this can be avoided, it is better, as this is a process that takes place during replay, and nothing is more irritating than waiting for sync, because of bandwidth or disk access problems. It can be worse sometimes also depending on the database, leveldb is not bad but I would prefer, down the track, to switch it all to the Badger database, which separates the key and value fields, and keeps (optionally) all of the keys in memory.

So, I basically (lazily) implemented it, without too much thinking beforehand, such that for each algorithm, it always steps back to the previous block of that algorithm, and then walks backwards some amount of blocks (probably 288 blocks, but I'm not completely sure yet), and simply uses these two times, subtracts the older time from the newer, and adjusts from that.

What I did not realise immediately was how this would work with especially this many algorithms. As I have discussed in that document above, the difficulty is dithered by a tiny amount, just the last two bits, after getting that average block time, and then feeding it into that curve filter. This is a unique feature for difficulty adjustments, I thought about more 'random' ways of doing it but the fact is when you are dithering, you should not shuffle things too much. The bit-flipping may not be sufficient to smooth out the bumpy, pointy timestamp resolution, but it probably is a long way towards eliminating resonances caused by common factors between numbers.

So, in every case, the difficulty adjustment is computed based on, what will often be, some time in the past, maybe 1 block, maybe hundreds. The adjustment based on this will influence only the one algorithm's blocks, but it also combines with the other blocks mingled together. But the most important effect, which was just a side effect, in my mind, that I didn't model yet, is that no matter how long the gap is while an algorithm isn't being used, it is as though no time has passed, so each of the different algorithms will bring new, complex 'echoes' into the feedback loop that computes difficulty, which I figure will probably somewhat resemble reverb or radiosity in sound and light respectively. Or in other words, the possibly different inherent distributions of solutions, which are already independent from each other, will combine a lot of different numbers together.

Pure gaussian noise is by its nature soft and fluffy, the sound is like the whooshing of breath, and visually it is blurring, density of dots, for example, is used for most forms of print matter, and the best looking images are ones that have the natural chaotic patterning as you see in film. Even many new developments in camera technology, and displays, are increasingly using multiple exposures, and highly pattern-free algorithms like Floyd-Steinberg and later, more fluffy types of ditherers.

So, in a simple way of explaining it, the only thing that really differentiates how I am implementing this, is I am making maximum use of the benefits of poisson point processes and gaussian distribution with intentional noise. Too much will overwhelm it, but I think between the bit flips and the time-traveling block difficulty that always ignores the immediate previous block, maybe many more, since the previous time the algorithm was used for a block, these blocks will appear randomly, and the echos will be sometimes short, nearly not an echo at all, and sometimes quite a ways back. These will definitely add more randomness to the edges of the adjustments, and this is very important, in my opinion, as the reality is, difficulty adjustment regimes really are not up to date compared to other fields of science where control systems are implemented.

You may have heard of Fuzzy Logic, and probably don't realise that almost all cars, washing machines, and many many devices now use fuzzy logic systems to progressively adapt via feedback loops to keep a random or undesirably shaped response pattern from appearing in the behaviour of the device. These unwanted patterns tend to also cause inefficiency and catastrophic changes if they are not mitigated.

The new stochastic parabolic filter difficulty adjustment scheme should hopefully fix almost all of the issues relating to blockchain difficulty attacks, most of them, the most devastatingly efficient, as was the first live instance of a time warp attack, on Verge, earlier this year, and the attacker succeeded in freezing the clock and issuing arbitrary tokens (of course limited by block height/reward size, but not in sheer number).

The only remaining vector of attack is the pure and simple 51%, just simply overwhelming the chain for long enough to be able to rewrite it.

Just some brief comments about the timing behaviour that I observed so far in tests, with the dithering added, particularly, the block times started to nicely swing quite a ways back and forth, in an almost alternating pattern. It's probably actually a 4-part pattern, because 4 different ways 2 bits can be  set. Firstly, it does not react strongly to blocks when they fall within the inner 20% of divergence, between 80% and 125%, and as such, even with quite dramatic changes in hashpower, it stays pretty close, because basically once block time falls, as it is prone to, randomly, at the further out edges, from 50% to 200% (smaller and bigger) the algorithm kicks them hard, so in the events of a sharp rise in hashpower, what happens is the difficulty rapidly increases, *but* it does not do so in a linear fashion. It is dithered in the smaller harmonics, as well as being a smooth surface like a mirror (and made smoother by dithering), so it homes in on the correct adjustment quite quickly.

From what I saw so far, a sharp rise sees the difficulty accelerates upwards, but not smoothly, and because it isn't smooth, though when a big miner stops mining, yes there may be longer gaps between, but as I mentioned, the block times seem to pretty well oscillate in a 1:4 and 1:2 ratio, usually within 3 blocks it will, as it did going up, go back down.

Most algorithms don't try to address the issue of aliasing distortion in the signal, and it is this that makes difficulty adjustment algorithms get stuck or oscillate excessively.

Anyway, I will have all of the bits changed to fit the 7 new algorithms in the next days, and then we will be able to see more concrete data about what additional effect the 9 different algorithms will have, as well as the pattern that it ignores the newest block if it is the same algorithm, meaning that due to the random distribution of the algorithms, the time will also be dithered as a product of the poisson process of finding solutions.

Blockchains basically take a random source, and attempt to modulate the process with difficulty to make it more regular. Regular blocks is very important because of the width of the amount of time between blocks being somewhat long, and in fact blockchains can't really do much better than 2.5 minutes, at best, and in my opinion, 5 minutes is a good amount of time, and long enough. Between 10 minute blocks, there is 600 seconds. You would not be happy if there was only 600 pixels across your screen (these days), and I think it helps people understand what is going on when an analogous phenomena is compared.

Blockchains are highly dependent on clocks, and it is because of the many random factors between them, that it is also the most difficult thing to really get right. Many of the older coins have terrible difficulty adjustments, bitcoin only adjusts every 2 weeks, and the only reason it can get away with it is because of so much loyal hashpower, the volatility is small. But the more ASICs that are available, the more GPUs, the more variance there can be between hashpower and profitability on various chains, the more of a problem it gets to be for more chains.

I have thought about other strategies, and maybe they will be added later, but I am not sure yet if it is even necessary. The most challenging thing with difficulty adjustment and the main type of attack carried out on pretty much a daily basis, even, mostly unintentional, is that blockchains can be caused to pause for indeterminate amounts of time when difficulty adjusts up due to high hashpower, and then when it goes away, it cannot go back down until a new block hits the old target. Min diff blocks, as used in test networks, do not work in the real world, because it is not possible to come to a clear consensus about time, and the network can be highly divided about whether the necessary amount of time elapsed or not, and thtis gets even worse when you add in that people alter their nodes to feed fake times or divergent times as part of attempts to game the system.

I think the solution is just noise, basically, in case you hadn't figured it's all about that, and using noise to eliminate distortion. Even if the chain has dramatic, like maybe even as high as 20x jumps in difficulty, that with added wiggle, when difficulty ramps up, it does not get caught, either slowed or sped up, in moving up, it wiggles all the way to the top, and at the top, though there will be a time of gap between, the 'time travelling' averaging I have devised, likely will further counter this.

There will naturally be clumpiness in the distribution, even given a continuous, long time of all algorithms at a stable hashrate, and, especially with so many algorithms, now there is 9, this means that when difficulty goes up a lot, an algorithm that has gone through a long dry patch will have a potentially lower (and also higher) target already, and thus where the blocks with algos with not many recent solutions find a solution, or another giant pool shows up, it gives far more opportunities for a block to come in on target, sooner than it would have otherwise.

The real results of course will be seen with more testing and when the hardfork activates. I hold to Proof of Work as the currently and still and will probably be best strategy for protecting the security of the blockchains, as I saw first hand how easily it is for proof of stake blockchains to get extremely badly distributed. Proof of Stake also, in the beginning, is very cheap to acquire, and after a short time, only the early people or someone with a lot of money can have any influence. This is not conducive to adoption, nor is it conducive to security.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 [29] 30 31 32 33 34 35 36 37 38 39 40 41 42 43 »
  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!