Writcoin[™] corrects the dates of its genesis blocks to the start of its current Gregorian calendar month…
Since it has unique transaction blockchains for each month, the network cited above features genuine "full blockchain pruning" (kodtycoon).
Topic: have any coins actually developed blockchain pruning yet? (Read 1290 times)
Since it has unique transaction blockchains for each month, the network cited above features genuine "full blockchain pruning" (kodtycoon).
If so, please prove me and the scientific community wrong, and I'll eat every hat you give me.
And after that you want us to believe you are not BCNext?
PS:
I'll eat my hat if in half a year they won't be worth a couple of millions.
Lol if I was BCNext, why would I challenge myself in all those posts?? I'm a bit eccentric, but dual personality disorder???
"Actions contain metadata which nominate 3rd party actors as trustworthy at that time. 3rd party actors prove their trustworthiness via Proof of Work challenges. Trustworthy actors can then have influence on conflicts and arrive at a majority solution."
That was such ambiguous, long winded terminology, it was almost an exact recreation of the Conan O'Brien Bitcoin clip:
https://www.youtube.com/watch?v=Vd19SboRhVY
I would just call it an automated reputation protocol then go on to explain details from there.
How is it ambiguous? It provides a complete, clear explanation of what it does and how.
Can you explain POW or POS in as many words?
"Bitcoin is secured by a Proof of Work algorithm whereby actors attempt to solve a cryptographic puzzle. The POW challenges are of varying difficulty depending on actor participation to ensure that challenges are not solved too quickly and that conflicting solutions are rare. The first solver of the puzzle has the right to modify the state of the ledger. The process repeats."
Thats about the best I can do.
I don't think I'm really nitpicking here, but trustworthiness is an extremely ambiguous term that I would probably avoid using. It's usually not used in relation to any data that can be quantified, while words like reputation are in systems like Ebay. The word trust usually implies what one party thinks of one other party, while the word reputation usually implies what many parties think of one party. This is why I said I would call your system an automated reputation protocol and abolish the use of the word trust or trustworthiness in any of it.
Ok fair enough, I thought you were referring to the statement as a whole. Now you've explained I see where you are coming from.
"Actions contain metadata which nominate 3rd party actors as trustworthy at that time. 3rd party actors prove their trustworthiness via Proof of Work challenges. Trustworthy actors can then have influence on conflicts and arrive at a majority solution."
That was such ambiguous, long winded terminology, it was almost an exact recreation of the Conan O'Brien Bitcoin clip:
https://www.youtube.com/watch?v=Vd19SboRhVY
I would just call it an automated reputation protocol then go on to explain details from there.
How is it ambiguous? It provides a complete, clear explanation of what it does and how.
Can you explain POW or POS in as many words?
"Bitcoin is secured by a Proof of Work algorithm whereby actors attempt to solve a cryptographic puzzle. The POW challenges are of varying difficulty depending on actor participation to ensure that challenges are not solved too quickly and that conflicting solutions are rare. The first solver of the puzzle has the right to modify the state of the ledger. The process repeats."
Thats about the best I can do.
I don't think I'm really nitpicking here, but trustworthiness is an extremely ambiguous term that I would probably avoid using. It's usually not used in relation to any data that can be quantified, while words like reputation are in systems like Ebay. The word trust usually implies what one party thinks of one other party, while the word reputation usually implies what many parties think of one party. This is why I said I would call your system an automated reputation protocol and abolish the use of the word trust or trustworthiness in any of it.
If so, please prove me and the scientific community wrong, and I'll eat every hat you give me.
And after that you want us to believe you are not BCNext?
PS:
I'll eat my hat if in half a year they won't be worth a couple of millions.
There is always an attack vector
Soon you will learn that is not true.
So you are saying that your solution is Byzantine tolerant to greater than (n-1)/3? If so, please prove me and the scientific community wrong, and I'll eat every hat you give me.
There is always an attack vector
Soon you will learn that is not true.
"When you point one finger, there are three fingers pointing back to you."
Still waiting for the details of your solution as I've found it to be sorely lacking.
Still waiting for the details of your solution as I've found it to be sorely lacking.
Furthermore, I don't believe the eMunie trust consensus is any more complicated than POW or POS, it is in fact quite simple, and simple enough to describe in 3 short sentences.
But you'll always have an attack vector whether is be 25% or 51% of the nodes.
Mine has no such vulnerability and is perfectly Byzantine fault tolerant.
And it is much simpler. And it is based on proof-of-work, but removes all the things people complain about w.r.t. to proof-of-work, including the excess security that is wasted on electricity. I do not feel good about causing someone to waste 2 - 3 years of effort. Hey if you are a good Java programmer and want to work for coins, again I suggest maybe you should be talking to me. I not only have the holy grail of consensus designs, but I also obliterate all the other anonymity designs as well including Blockstream, Cryptonote, and Zerocash.
Please I don't wish any harm on you or your community. You've been very reasonable. I hope you see I am being reasonable. As for unreasonable dickheads, they have coming what they deserve.
There is always an attack vector, you can not guard against Byzantine faults if more than (n-1)/3 of them are occurring, not matter what algorithm you chose, this is proven. Yours also then has attack vectors too, and it is simply that (n-1)/3 nodes lie, so you need to have some Sybil protection to make achieving (n-1)/3 node difficult (you can never prevent them completely). If your solution is 100% guarded against these scenarios, then well, I will take my hat off to you and propose you for every CS prize going.
Bitcoin is not Byzantine tolerant IMO because the historical state of the ledger can be changed by someone with a majority of hash-power. In a true Byzantine tolerant protocol, the ledger (or log) is append only, and this is not the case for Bitcoin.
"Actions contain metadata which nominate 3rd party actors as trustworthy at that time. 3rd party actors prove their trustworthiness via Proof of Work challenges. Trustworthy actors can then have influence on conflicts and arrive at a majority solution."
That was such ambiguous, long winded terminology, it was almost an exact recreation of the Conan O'Brien Bitcoin clip:
https://www.youtube.com/watch?v=Vd19SboRhVY
I would just call it an automated reputation protocol then go on to explain details from there.
How is it ambiguous? It provides a complete, clear explanation of what it does and how.
Can you explain POW or POS in as many words?
"Bitcoin is secured by a Proof of Work algorithm whereby actors attempt to solve a cryptographic puzzle. The POW challenges are of varying difficulty depending on actor participation to ensure that challenges are not solved too quickly and that conflicting solutions are rare. The first solver of the puzzle has the right to modify the state of the ledger. The process repeats."
Thats about the best I can do.
"When you point one finger, there are three fingers pointing back to you."
Still waiting for the details of your solution as I've found it to be sorely lacking.
Still waiting for the details of your solution as I've found it to be sorely lacking.
Furthermore, I don't believe the eMunie trust consensus is any more complicated than POW or POS, it is in fact quite simple, and simple enough to describe in 3 short sentences.
But you'll always have an attack vector whether it be 25% or 51% of the nodes (no matter how much you and Bitcoin people argue that isn't the case and unlikely, which is not!).
Mine has no such vulnerability and is perfectly Byzantine fault tolerant.
And it is much simpler and easy to describe and comprehend. And it is based on proof-of-work, but removes all the things people complain about w.r.t. to proof-of-work, including the excess security that is wasted on electricity. I do not feel good about causing someone to waste 2 - 3 years of effort. Hey if you are a good Java programmer and want to work for coins, again I suggest maybe you should be talking to me. I not only have the holy grail of consensus designs, but I also obliterate all the other anonymity designs as well including Blockstream, Cryptonote, and Zerocash.
Please I don't wish any harm on you or your community. You've been very reasonable. I hope you see I am being reasonable. As for unreasonable dickheads, they have coming what they deserve.
it is in fact quite simple, and simple enough to describe in 3 short sentences.
"Actions contain metadata which nominate 3rd party actors as trustworthy at that time. 3rd party actors prove their trustworthiness via Proof of Work challenges. Trustworthy actors can then have influence on conflicts and arrive at a majority solution."
"Actions contain metadata which nominate 3rd party actors as trustworthy at that time. 3rd party actors prove their trustworthiness via Proof of Work challenges. Trustworthy actors can then have influence on conflicts and arrive at a majority solution."
That was such ambiguous, long winded terminology, it was almost an exact recreation of the Conan O'Brien Bitcoin clip:
https://www.youtube.com/watch?v=Vd19SboRhVY
I would just call it an automated reputation protocol then go on to explain intricacies from there.
He's right though, even people well versed in the technical aspects of Bitcoin have a hard time predicting all the various scenarios that can go wrong with proof of stake, let alone a full blown eMunie phonebook of variables. You then have people like Kushti and Buterin trying to mathematically prove that proof of stake can rival or beat proof of work's security model in post's like this:
http://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
Since they have such a hard time quantifying the security model of simpler concepts like PoW vs PoS, how many decades will it take to quantify the security model of emunie?
http://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
Since they have such a hard time quantifying the security model of simpler concepts like PoW vs PoS, how many decades will it take to quantify the security model of emunie?
POW and POS are not true Byzantine solutions though, where I believe that eMunie is. So it should be easy to quantify its security, when proof of tolerance is apparent.
I'm currently communicating with some respected academics that have no association with Bitcoin, block chains, or crypto-currencies in general. This is so as to prevent reviewers making assumptions about the technology by aligning it with current block chain technologies, and to safeguard against any bias, motives to discredit the algorithm other than for good reason.
I'm sure most of these individuals wouldn't risk their reputation by publishing falsehoods in a peer review, only to be subsequently exposed when peers of their own review the algorithm for themselves...but you never know.
Furthermore, I don't believe the eMunie trust consensus is any more complicated than POW or POS, it is in fact quite simple, and simple enough to describe in 3 short sentences.
"Actions contain metadata which nominate 3rd party actors as trustworthy at that time. 3rd party actors prove their trustworthiness via Proof of Work challenges. Trustworthy actors can then have influence on conflicts and arrive at a majority solution."
He's right though, even people well versed in the technical aspects of Bitcoin have a hard time predicting all the various scenarios that can go wrong with proof of stake, let alone a full blown eMunie phonebook of variables. You then have people like Kushti and Buterin trying to mathematically prove that proof of stake can rival or beat proof of work's security model in post's like this:
http://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
Since they have such a hard time quantifying the security model of simpler concepts like PoW vs PoS, how many decades will it take to quantify the security model of emunie? Even if you release the perfect system, it might sit on the shelf for several years before anyone will touch it.
http://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
Since they have such a hard time quantifying the security model of simpler concepts like PoW vs PoS, how many decades will it take to quantify the security model of emunie? Even if you release the perfect system, it might sit on the shelf for several years before anyone will touch it.
Another benefit of having partitions, and channels within those partitions, it allows client-only nodes to not have to rely on 3rd parties for the storage of their wallets. These devices (such as mobile phones) can just store the channel their transactions are in, maintain their own micro ledger with regard to their transactions and not have the worry of xyz.com running off with funds.
You are on the right track. But the devil is in the details.
K.I.S.S. if you expect anyone to comprehend and trust the design."When you point one finger, there are three fingers pointing back to you."
Still waiting for the details of your solution as I've found it to be sorely lacking.
Another benefit of having partitions, and channels within those partitions, it allows client-only nodes to not have to rely on 3rd parties for the storage of their wallets. These devices (such as mobile phones) can just store the channel their transactions are in, maintain their own micro ledger with regard to their transactions and not have the worry of xyz.com running off with funds.
You are on the right track. But the devil is in the details.
K.I.S.S. if you expect anyone to comprehend and trust the design.You keep telling me things I already know :p
Another benefit of having partitions, and channels within those partitions, it allows client-only nodes to not have to rely on 3rd parties for the storage of their wallets. These devices (such as mobile phones) can just store the channel their transactions are in, maintain their own micro ledger with regard to their transactions and not have the worry of xyz.com running off with funds.
You are on the right track. But the devil is in the details.
K.I.S.S. if you expect anyone to comprehend and trust the design. eMunie supports it, and has been a requirement from day 1 of the project.
Our ledger also supports partitioning, where nodes can elect to store only a part of the entire ledger. This is to allow storage limited nodes to still provide value in regard to securing the network.
With this ability, even if the network is seeing loads 100s or 1000s of times greater than what BTC is currently, low resources devices such as Pis can participate without needing terabytes of storage available to them.
Our ledger also supports partitioning, where nodes can elect to store only a part of the entire ledger. This is to allow storage limited nodes to still provide value in regard to securing the network.
With this ability, even if the network is seeing loads 100s or 1000s of times greater than what BTC is currently, low resources devices such as Pis can participate without needing terabytes of storage available to them.
The hyperbole is strong with this one. We've been running alts on Pis for years, btw..
Supporting a network with a Pi that is processing 1-2 tx/s a sec (BTC average) is childs play.
Throw a Pi on a network that is processing 100+ tx/s with current block chain tech and lets see how far you get then. At 4GB a day of transactions at 100 tx/s (1.5TB over a year) good luck with that. Even if you had the storage, and let alone keeping up with the chain, you'd need GB upon GB of RAM just for the UTXO.
Infact Id like to see any currency support that on current block chain tech and not become centralized to a few farms of full nodes controlled by a handful of people.
Another benefit of having partitions, and channels within those partitions, it allows client-only nodes to not have to rely on 3rd parties for the storage of their wallets. These devices (such as mobile phones) can just store the channel their transactions are in, maintain their own micro ledger with regard to their transactions and not have the worry of xyz.com running off with funds.
eMunie supports it, and has been a requirement from day 1 of the project.
Our ledger also supports partitioning, where nodes can elect to store only a part of the entire ledger. This is to allow storage limited nodes to still provide value in regard to securing the network.
With this ability, even if the network is seeing loads 100s or 1000s of times greater than what BTC is currently, low resources devices such as Pis can participate without needing terabytes of storage available to them.
Our ledger also supports partitioning, where nodes can elect to store only a part of the entire ledger. This is to allow storage limited nodes to still provide value in regard to securing the network.
With this ability, even if the network is seeing loads 100s or 1000s of times greater than what BTC is currently, low resources devices such as Pis can participate without needing terabytes of storage available to them.
The hyperbole is strong with this one. We've been running alts on Pis for years, btw..
eMunie supports it, and has been a requirement from day 1 of the project.
Our ledger also supports partitioning, where nodes can elect to store only a part of the entire ledger. This is to allow storage limited nodes to still provide value in regard to securing the network.
With this ability, even if the network is seeing loads 100s or 1000s of times greater than what BTC is currently, low resources devices such as Pis can participate without needing terabytes of storage available to them.
Our ledger also supports partitioning, where nodes can elect to store only a part of the entire ledger. This is to allow storage limited nodes to still provide value in regard to securing the network.
With this ability, even if the network is seeing loads 100s or 1000s of times greater than what BTC is currently, low resources devices such as Pis can participate without needing terabytes of storage available to them.
i dont mean pruning of some bits out of the chain like messages, or reductions here or there. i mean full blockchain pruning where i could run a node and only store a partial chain that consists of say, the last 50/100/500 etc blocks. whats the closest anyone has gotten to this and are any coins currently developing this?
Yeah, it's in Bitcoin Core 0.11, and by extension Dogecoin Core 1.10 beta has it too.
Jump to: