thank you for correction. I directly jumped in timeline section, and unfortunately there was no information about bug release date - so it looked like the bug was in a release that published the same day.. however, I am still happy with the response time, but why such important information doesn't exist in timeline!?

 

bugs always exist in cyber world. the important part is the way you perform a debugging procedure. if I was an investor, I would find and invest on a coin that has the most quick reaction to a bug from identifying to patching it. so look at the analysis bellow:


which means within 3 hours the bug identifies and patches in less than 10 hours.. this is a great benchmark. so a bug that only lived in 10 hours is really like it never exists. its an honor, not hilarious.

Thank you for spending time on this study, Magic Byte. Your kind reply provides great energy that we all need to continue such researches.


Actually, this is the most important part of the PoCo, where we force (holder)nodes to shape a Ring for syncing the pre-mined transactions during new block creation. because Ring is very sensitive due to faults and fails, this could quickly expose any possible forks during block creation. with PoCo, holdernodes could simply bypass the faulty node and continue - however they also attempt to reconnect to the faulty node. in other words, such disadvantage in Ring Network could become an advantage in PoCo consensus model.


well, this research project contains several sub-systems like flash-back-pinning (https://bitcointalk.org/index.php?topic=5089384.0) that could get used immediately in bitcoin core. but as you have mentioned above the whole bitcoin may not convert into such consensus model. I personally like bitcoin remains in PoW area forever. someday a team may come up with the idea of forking to have "Bitcoin PoCo" in the market.

if we do not give super power to masternodes, then they never could turn the consensus into PoS. for example, those full nodes that get committed to provide 99.9% up-timing (ping/pong) with good bandwidth, static IP and disk space (and urgent power supply, etc) for their full nodes without any restriction in responding other nodes (blooming filters, etc) could receive some rewards from the network. just look at this as an improvement for the gossip protocol. this would be a good field for research.


the ppt version also added to the topic. the ppt version helps you read it quickly:
https://bitcointalk.org/index.php?topic=5066624.0

True. this was just for better expressing the idea. in implementation, I have this format:

which could shrink into your suggested version too:



sorry for delay. I was busy with preparing the ppt file. please find it at:
https://bitcointalk.org/index.php?topic=5066624.0 (updated)

I have also changed the subject of topic for better results in search.


don't consider the bitcoin. unfortunately the PoW is fragile too when your crypto is not established yet.

a presentation file for PoCo Workshop is available now at:
http://www.mixoftix.net/knowledge_base/blockchain/shahin_go-round_v_1_2.ppt

/*
UPDATE: Note: page 15 of the ppt file talks about cluster mechanism and expresses the ability of masternodes to reject a cluster when a conflict with protocol happens. in fact, there are several steps before creating a cluster that reject such conflicts with protocol and giving this power to masternodes obviously could bring damage to the crypto. so this (the only) ability of masternodes to reject blocks will remove from the PoCo in next update unless a comment changes the situation.
*/

it contains the latest feedbacks from discussions here, in bitcointalk. and now we have master nodes in protocol, which have no super power, but some responsibilities. these slides could better show how PoCo will work so could expose any possible hidden flaws in workflows. related discussion are listed bellow:


- Is it possible to generate a consensus algorithm using machine learning?
https://bitcointalk.org/index.php?topic=5079827.0

- Proof of Thought (PoT): The Holy Grail has arrived! Only Humans can mine
https://bitcointalk.org/index.php?topic=4459113.0

- A Possible Solution To Re-Org Attacks That Isn't Inculudes Checkpoints
https://bitcointalk.org/index.php?topic=5077722.0

- A new idea for node reward
https://bitcointalk.org/index.php?topic=5085744.0

- The necessity of "flash-back-pinning" in structure of transactions..
https://bitcointalk.org/index.php?topic=5089384.0

The flash-back-pinning is about a rule in PoCo [R1] that enforces the end user to include & sign the block number and its hash value of her last known chain (e.g. with 10 confirmation distance) in the structure of raw transactions. For flash-back-pinning we need to add two new fields “flash-back-block” and “flash-back-hash” after “timelock” field. So as timelock field provides a condition about after which block the transaction could be processed, the “flash-back-block” and “flash-back-hash” also provide us a condition about which chain this transaction belongs to [R2]:


With this potential improvement, 51% attacker can't use others' legitimate transactions of mempool for block fabrication in the hidden fork (so needs to generate many valid transactions for his hidden fork too). therefore, when an invalid fork involves, based on situation, with this rule:

1- Nodes could early stop a transaction in mempool (and the user understands that she has wrong chain info)
2- Miners also could exclude a payment on wrong chain from their candidate blocks
3- Receiver of payment also could ignore it, when she can't approve the Flash_back_hash in her chain

As an additional layer of protection, when a 51% attacker tries to broadcast a longer fork, the protocol checks the sum of coins-in-circulation among two/more forks. With same difficulty, the fake fork still needs to have the more coin-in-circulation to finalize the over-write process.

1- Is there any BIP/method similar to flash-back-pinning improvement proposal?
2- What is your assessment about flash-back-pinning in mitigating attacks?


[R1] https://bitcointalk.org/index.php?topic=5077722.0
[R2] https://medium.com/coinmonks/how-to-create-a-raw-bitcoin-transaction-step-by-step-239b888e87f2

from the introduction section of url above:
"If the elements are large, it may be preferable to compute the sketches over hashes of the set elements."

and I think this method will fit in cryptos. if so, then this would be a good idea to relay the FEE parameter with these hash values too. then you could add a HAND-SHAKING stage at the beginning of these back and forts:


therefore, (refer to RAM capacity and node minimal fee threshold) Alice and Bob (within hand-shaking stage) could express their minimal-fee-threshold to the other side and save even more bandwidth from the beginning. not sure, but this may also help in mitigating a sibyl attack..


and I have a question here. if I understand it right, the BCH here needs a rearrangement of data in mempool - so in continue, we should know does this rearrangement need more space too? and the encoding/decoding processes engage the processor of a node. may it put an end on nodes that have miniature hardware like raspberry family?

Lets elaborate the control of price and oxidation fee.. in fact oxidation fee in not a mechanism for control the prices, this is addressing one major flaw in cryptocurrency ecosystem that some economists and financial managers say that "business model in these coins are like ponzi /pyramid schemes". but I need to go even further more..

in cryptocurrencies, we have Alice that initiates a transaction to Bob by assistance of entities that we call them miners. in fact miners here act like a bank / payment provider company but we never proceed to model the role of central bank and the economy that it drives. however we simply use rewarding system instead of central bank's monetary policy, but there also need to be a taxing system to manage the incentives. this is important to build a healthy economy around cryptos ( https://www.abc.net.au/news/2017-03-07/what-happens-to-the-economy-when-we-stop-spending-money/8297724 ):

"if everyone put money into a bank, the economy would grind to a halt."

"Deposits act as a nice bit of insulation for the economy. While they do facilitate lending, economists view savings as a 'leakage' of money out of the economy."

"Starting early, and saving a consistent amount over a long period, can produce big returns. On the other hand … if everyone tries to increase their saving all at once, the result will be bad for almost everyone."

and oxidation fee (in my white) exactly targets this flaw in business model of the cryptocurrencies, which means when your coins are all in circulation, you automatically have a good economy around it and this defines the worth of the coins. a taxing system may need a centralized organization that dosen't fit in crypto environment, but a decentralized fee mechanism that wipes out the coins in the protocol level, could simply establish. BTW, the oxidation fee defines by Fibonacci Sequence (1,1,2,3,5,8,13,..). for example after 5 years destroys 1+1+2+3+5 = 12% of the frozen savings in an address.

P.S.:

and refer to this thread ( https://bitcointalk.org/index.php?topic=178140.msg1857705#msg1857705 ) the idea of panic tax doesn't make sense, because you need to robust your business model to PREVENT any future panic from the beginning. when panic begin, you only could innovate and pray.. any intervention in users savings during panic just doubles the problem..

UPDATE:

for more information and background of oxidation fee please read about:

https://en.wikipedia.org/wiki/Invisible_hand
https://courses.byui.edu/econ_150/econ_150_old_site/lesson_11.htm

so it was all about disabling ASIC devices in a PoW..


and disabling ASICs dosen't necessarily prevent pools from acting centralized.. and signing messages also can't stop this. one pool still can gather processing power in other ways and become the majority. hope I didn't miss something important in your proposal.

UPDATE:

solo miners still could join a pool and each of them check a defined range of values for mining. look at p2pool.

I still need to read more about it.
refer to the paths that nodes may connect to each other among dishonest nodes, huge amount of nodes could be vulnerable.


True. I have also read this page (https://docs.dash.org/en/stable/masternodes/understanding.html) :


however block rewarding will end in bitcoin and miners should be ready for these changes, but I agree that people are not ready for such changes in current bitcoin ecosystem. a masternode model could help a new proof model which tries to dedicate block rewarding for nodes.. for example, in PoCo I have a very special kind of nodes that I name them HolderNodes and with studying masternodes, I could better reward them after block creation..

once again you are going to convince me to make another change in PoCo, ETFBitcoin - Thank you..


my question was about what is the optimized amount of full nodes in a crypto network like bitcoin? however I remember from bitcoin's arrangement against sibyl attack [1]:


but after reading your reply, I start thinking and have googled about it and it seems we already have "115,000" running full nodes [2]!! and refer to the theory of six degrees of separation [3], the longest distance in a crypto network from any of these nodes to another is 6. I could conclude from these all that having lower counts of full nodes is good enough. so getting back to the topic, I think if we need to have a rewarding policy for nodes, it should follow the masternode model, which the masternode has to deposit some coins, and in continue receive some responsibilities and jobs then benefit from the fixed /random rewards (like DASH).

for example, we could include this policy in the protocol that one node could become a masternode by freezing a predefined amount of coins in the network and declaring its IP and PORT in the message of the transaction.


just like masternodes, I could accept hash values of entities that already have at least 1 coin in their addresses - this prevents people of making unnecessary addresses just for joining the rewarding process. you know, in PoCo gathering several information from involved entities about the consistency of the network is an important rule, but after discussing masternodes above, now I could provide some changes in the rewarding model and focus on masternodes only.

[1] https://en.bitcoin.it/wiki/Weaknesses#Sybil_attack
[2] https://hackernoon.com/bitcoin-miners-beware-invalid-blocks-need-not-apply-51c293ee278b
[3] https://en.wikipedia.org/wiki/Six_degrees_of_separation#cite_ref-22

this is very important. would you please explain it more?
you know, just because we assume that more full nodes means more backup (and more protection) for blockchain history, everybody tries to achieve the higher full node counts.. is there any of best practice / your personal experience about limitation for running full nodes? if so, are we facing an approach like masternodes among regular full nodes for better performance of the network?


P.S.:

in proof-of-consistency, I really don't care the one who submits her check up session hash value is really running a full node. I just need an entity check the consistency of new blocks with older blocks in the blockchain history. if the result is true and majority of the network approves it, then the value will register for rewarding process. in fact, if you can process the consistency of the network, then at least you have a valid copy of the blockchain.

I'm really getting surprised to see new demands are coming about rewarding / fee models and the way they try to bring solutions that suit upcoming willing from a sustainable crypto-currency.. you may find it useful to read my whitepaper:

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

as a brief, this may be meaningless if you just provide a lottery mechanism for nodes. with proof-of-consistency (PoCo), I regularly ask the whole network to check the consistency of the blockchain data and this operation generates a unique hash value per block creation. nodes get rewarded randomly and miners collect the transfer fee - both based on that randomness (noise).. this noise could apply the Dither Effect to a crypto-currency and make it work properly.. the PoCo is totally based on Dither. so, the randomness that you feel could make nodes work better, is a fact in engineering:

"when you tap a mechanical meter/engine to increase its accuracy, you are applying dither."

well, when you decide to model all kinds of metals by crypto-coins, you may find the need for different policies. for example, who uses steel as a medium for storing value? defiantly no one. but at the same time, let focus on modeling gold - as all crypto-coins do and imagine you buy a piece of golden jewelry today with 30 Grams (1.06 Ounces). for the security reason, you may also buy a home safe box and regularly spend time to check the content of the box and be worried during each travel out of city (oxidation fee). with golds around 1 kilograms (35.274 Ounces) and above, now you start thinking about renting a safe deposit box and pay for it every year (oxidation fee).

each entity that involves in the process of block making has to somehow benefit form protecting the whole network. why people should work all the time to persevere something precious for me, for free?

P.S.:

there is another report here about loss of 36% of all bitcoins in circulation. this report may be wrong, but people could either simply forget their private keys or send their coins to an invalid address, and the whole network will suffer from the loss too. this is another problem that I try to address by oxidation fee:

https://news.bitcoin.com/btc-36-in-circulation-lost-23-held-by-speculators-us-tax-authority-monitoring/

sorry, sorry. I have lost the mean of word infinite. you are right.

now, what you suggest in your paper is same as what I do. my coin supply is "infinite" too. I have a transfer fee that divides into:
1- transaction fee
2- network fee (this wipes out in the system)

destroying all/part of transfer fee prevents the unnecessary transactions in the system and I really like this. I also have the 3rd fee:
3- oxidation fee (this wipes out in the system too)

and this one is for the unspent coins with more than 1 year old (more older, more oxidation fee). you know, bitcoin and other similar coins have finite coin supply to create something like GOLD in virtual world - but with adding this wiping/destroying policy now we are at the age of modeling COPPER (or other metals) in virtual world.

Gold wasn't the only metal that brought us civilization, others were important too.

thank you for the post. refer to the PDF version in page 5:


while you have infinite coin supply, how you can remove the transaction fees? this means after years, finally all coins will get mined and after that miners will find no incentives to mine new blocks.. even in continue the paragraph - that tries to describe the consequences - doesn't provide a solution. you you please clarify this paradox?

there is a rule in my proof protocol that enforces the end user to include & sign the hash value of her/his last known block number - with one zero in its right digit (with some add/subtract) - in the payment order. now, 51% attacker can't use others' legitimate transactions in mempool for block fabrication in his hidden fork, and needs user's private key too (that is impossible, so needs to generate too many valid transactions for himself). therefore, when an invalid fork involves, based on situation, with this rule:

1- BEGIN: nodes could early stop a wrong payment in mempool / and a user understands that she has a wrong chain info
2- WITHIN: miners also could exclude a wrong payment from the process
3- END: receiver of payment also could ignore it, when she can't approve the hash value in her chain

and when a 51% attacker tries to broadcast a longer fork, the protocol checks the sum of coins-in-circulation among two/more forks. with same difficulty, the fake fork still needs to have the more coin-in-circulation to finalize the over-write process.

[this may sound funny, but rich users with just periodic circulating their coins in the blockchain could preserve their assets!! and an attacker with 51% of the hash power and huge amount of coin supply, better to hijack that broken crypto ]

avoiding hard coding of a checkpoint in the application, this would be a kind of decentralized-dynamic checkpoint system that I name it flash-back-field..

is there something wrong with this procedure?

Dummy Data?! when someone asks for elaborating the subject, you have to provide more info - and that is called responsibility.


if you don't RUSH into reply   and read the info carefully, you could see that step by step based on what attack that a bet/gambling provider need to prevent, he could do something special about it. each data source has its own characteristics and mixing them takes you to a better level of trust/security. for example, when you only have static password and decide to add one time password for a login process, we could say you have 2-factor authentication. and we can't say it (a login) 2-factor authentication, when it has 2 step of one time passwords, because they both work the same and are vulnerable to the same attack model.

therefore, when a blockchain is your only source of randomization, by mixing several blocks (header & content) you only could increase the difficulty, nothing more. if you mix data from two different blockchains, this is also trivial (refer to the 2-factor authentication sample above). now, by having the blockchain info (each of block header & block content has their own characteristics in defending the process) as the main source of randomization project, just aim at preventing any kinds of colluding among house and miners, you just add news/stock/weather/etc values to the process. their duty in the process is different here.

eventually, what we write here is about what-to-do, not how-to-do.. this is the project manager's call to pick (a) proper source(s) of data for randomization.

that is one of the symptoms of buffer over flow in client side  server side is working properly 


the hash matters, but the hash of rounds that creates based on the principles of bet/gambling provider. in this scenario anything that happen among a miner and the house (colluding, etc), will be useless when your ROUND-HASH should wait till finally identifies by some news feed or economical values in the future.. in this method, hash values of a blockchain are part of input parameters to the ROUND-HASH - not all of them.