Topic: Proof of Activity Proposal (Read 34074 times)

I'm getting a PoS Token made, and since it is a Token and not a Blockchain Verifying Blocks, I am thinking of adding some kind of Proof of Activity to the PoS Mining.

Lol

I was Scouring the Internet looking for Minable ERC20 Token Information, and there came up a very informational Article, it might have been Documentation somewhere, I wasn't Paying Attention to the Page it was on, it could have looked like a Wiki, I don't Remember. But it had 3 Types of Mining Listed, and "Proof of Activity" was there with the Other 2, and they were all Hyperlinked. And it took me to this Thread. I was Surprised to find that it existed and that it got so into the Subject of such a General Proof of- that could be used for Minable Tokens.

I was around for Proof of Solar, and when Peercoin Started Proof of Stake, I remember all of that, there was supposed to be Proof of Identity Chains where You would get Paid for Logging in with Your Government ID, and it would be however many Times a Day or whatever like Mining Blocks to Keep the Blockchain Moving.

But Proof of Activity, that is a Great General New Concept, and it is 10 Years Old, but I would say it is still New. Just like I thought that Minable ERC20 Tokens I had heard of would still be around, they are all kind of defunct because they met that Pitfall that I Talked about in the Post that Revived this Thread.

I just see it as Worth Discussing Now. We could Call the HIVE-Engine Smart Media Tokens, "Proof of Activity". This is Definitely going to be where Currencies head. Because this also then Covers like Basic Attention Token (BAT), which I think was Part of the Brave Browser it was maybe Called. And People would get Paid for using that Internet Browser.

And just me knowing all of this, and being in the Middle of Creating a Minable Token that Works by being Burned and that Creates a Hashrate, I thought I would Add to the Concept and maybe we could get Everyone thinking. Because these are the Important Discussions. More Features IN WALLET, which is kind of Ruled by Token Wallets Right now, Creating Tokenomic Wallets are the kind of Cutting Edge Tech, that being CoinBase Wallet, Trust Wallet, MetaMask, KeyChain and TronLink. This is the most FUNCTIONAL WALLETS IN EXISTENCE. It used to either be like Bitcoin where there was just kind of a Send Function in the Wallet, to Proof of Stake where You could Mine Directly in the Wallet and at the same Time People Created Point and Click Mining in Different ways, that was also when Butterfly Labs was making the First ASICs for Bitcoin Mining and You could still Mine with a Laptop, I think each Bitcoin was $25 instead of $65,000. But the Wallet Functionality Discussion, and the "Proof of-" Discussions are the most important we can have.

Security is Probably Next, but it gets a big Chunk of the Conversation, so maybe some of the Security Features Community could even Benefit Financially from Thinking this way.

We used to Talk about Solar Mining and Living on Boats in the Ocean, and 3D Printing Things to Live on in the Ocean, being Platforms, and all kinds of Crazy Designs that now AI could be used to Generate. We used to Talk about Creating a Town Called Bitcoin Town, and it seems that somehow Cryptocurrency is becoming almost Childish, almost like it is Reverting Psychologically to a Childhood Tool, and Children should Learn to use it, but Everyone else needs to know how to use it to, or else they are going to be behind when all the Kids come and they are just waiting to Read my Words and that is all they need to get to the Next Solar System. Because we used to Talk about that too, Colonizing Space. In the like 50s they Started Calling it "The Last Fronteir" just imagine that (and they did) they had that kind of forethought, that it would be a Frontier.

You just dug up a 10 year old thread. 

I think Proof of Activity Sounds like a Good General New Protocol.

There is a Pitfall to be avoided, but we can get to that Now. There have been Tokens made on the Blockchain that made it where, I am not sure on the Math but to make it simple let's say the way it Worked (and this is how it Worked, I am just not sure on the Math) it Released 1 Token Every Time someone did some Specific Action. This seems Fair at First because anyone can come in and get one.

But they found that People could make Several Accounts and be Performing the Action Several Times, and this isn't much Different than ASICs Taking Over Blockchains, but it didn't Work for the Tokenomics. It Quickly became Unfair. Or a 51% Takeover.

51% Takeover used to be a Death Sentence, even if the Token or Coin Maker was the 51% Holder. That is, until Steemit, where they Promised to use the 51%+ that they Held to Fund New Accounts and Community Development. Since then there have been many Projects where the Creators Hold 51%+ and it has been more Accepted than it was before.

But the Point being, Increasing the Rewards Pool to meet Demand does not Work for Mining.

When Mining and doing Proof of Activity, it should be like Proof of Stake. Each Activity should count as like 1 Stake, they are called "Vests" in Steemit Language, and we could use that Word. Each Activity constitutes Vestment, Vests we could say, and the Rewards Pool does not become Larger. Instead, the Coins become more and more Rare.

This is what Bitcoin Mining Calls "Difficulty". As more and more People Mine, the Difficulty goes up, and where You used to be able to Mine with a Laptop, now the Difficulty has gone up, and You need a Mining Farm to do the same Thing a Laptop used to do. Just because there are so many more People with more "Vests", or "Hashrate" in Bitcoin Mining Language. The Vests and Hashrate are Similar.

In Proof of Stake, the Hashrate comes from the Vested/Staked Currency, so they are exactly Correlated. If we just use Proof of Stake as our Standard, then we can make this all Very Simple.

I am making a Proof of Burn Token. So the Burn will be a kind of Vest, or a Share, a Hashrate, once Burned the Hashrate will go to the Wallet that Burned the Token. And the Rewards Pool will not Grow. But instead, that Person gets a Hashrate, and it makes it Harder for Everyone else. The Difficulty goes up.

It's possible more than 1 miner would solve the block at 1 time. So if the block is prevented from being signed as you mentioned above, another miner might get lucky.

The block that gets signed is the one that enters the blockchain.

If the node which may sign the next block is determined by the network before it's signed, how to handle the cases where

* node with signing privilege refuses to sign, or

* signing node is attacked in order to prevent signing?

I think it can be compatible with existing mining hardware. Whether it adds security or not depends on distribution of 'stake' and how much active stake there will be.

I'm interested to see where this leads. Although it would have to be a very compelling and obvious win in order to risk changing Litecoin's PoW at this late stage of the game.

Not exactly, because the transaction fees policy can be such that if you wish to send a near-zero amount then you have to pay a large fee.

I attempted to give a more complete answer in the previous reply, regarding "third tragedy" paragraph in the paper. The data size cap should be aligned with the amount of compensation that the nodes who secure the network get, otherwise it would be unprofitable for them to provide this security.

There won't be only a value cap. There are several costs for transactions, and the caps / hardcoded fees need to account for all of them. A value cap helps sponsor hashing, you'd also need a cap on size, and maybe also on computation.

I meant to ask: If there's only a value cap, that'd mean a miner could trivially blow up the blockchain in size by adding a bunch of near-zero transactions and everyone would accept it as valid.  

I'm sure it can be worked around, but would involve some sort of upper-bound cap.
 
As far as rolling out the ideas, it's hard. Something like Litecoin is perfect because it has actual value, which is the only real test of the hybrid systems, to be honest.

Litecoin would come to mind, but they said no.

I hope this is something everyone agrees with. People who deny this are no better than AIDS denialists.


I do not like shitcoins either, but we need some chain to test this on (preferably with valuable coins, in order to observe real-world behaviours and give people incentive to try to hack it).

to argue it makes no economic sense to do a 50+ percent attack is BS. if this concentration exist there is a chance for an abuse by a third party (e.g. a hack).

(maybe the PRoC will hack into GHash.IO and destroy Bitcoin)

EDIT: do not want to have an another shitcoin, want to have this issues fixed in Bitcoin.

Litecoin developers aren't the ones who have written the paper. It was coblee's idea (although the current version is very different from his), but it was just an idea, they weren't committed to implementing it.


Litecoin's bread and butter is copying Bitcoin is some minor tweaks. They (neither developers nor users) aren't interested implementing new, experimental features. So this is understandable.

But "can be abused by centralization" is a bullshit excuse. It doesn't make sense.

PoA still can be implemented as an alt-coin. And perhaps after some testing more established alts will consider adopting it.

"Among the Litecoin devs we have come to agreement that PoA was a bad idea as it can be abused by centralization.  It will absolutely not happen with Litecoin."

https://litecointalk.org/index.php?topic=576.0

So the concept was a joke or how should this to be understandable??

what is the reason for the stop? please explain: "can be abused by centralization"

I read in an independent news outlet that GHash is close to be hitting the 51%.

the most important part of the paper is this:


to the core devs: you have an issue with the amount of full nodes and you have an issue with the centralization of hash power by pool mining. the network is one of the most essential part of Bitcoin like a payment backbone of other instituations.

this proposal could be a solution for the issues. act now!

Yes, by readjusting the PoW difficulty according to how many blocks were created in a retarget window, we can achieve a predictable gap between blocks, where the new difficulty is derived both from the stakeholders' participation level and the PoW participation level.


Stakeholders shouldn't want to mine empty blocks in a malicious attack to destroy the system, as this would diminish the value of their stake. The bigger concern is closely related to the centralization/monopoly risks, i.e. miners cartel that obtains dominance and could then impose their policies (exclude transactions that don't conform with the fees that they impose, etc.). If PoW mining hardware is completely unusable for anything besides the particular cryptocurrency, then stake and PoW hardware would indeed be very similar in this regard. But ASIC/GPU can be repurposed for other uses, in particular to mine other cryptocurrencies, even as part of auto-switching centralized pool.


Since the objective is to discourage stakeholders (or miners) from accepting low-fee transactions, I don't see any problem with value cap rule that lets the last transaction overflow. It doesn't have to be a block that includes only a single transaction, for example if the limit is 100 BTC and there are transactions of 70 BTC and 60 BTC (with high proportional fees), then you can include the 70 BTC, then also include the 60 BTC, but then you must finalize the block because 70+60=130 BTC is over the limit.


It's "in addition", see the paragraph that starts with "There is also a third tragedy of the commons problem" in section 2.1 in the paper. The point is that if there's only data size cap and let's say Alice wishes to send a low-value transaction and Bob wishes to send a high-value transaction, then Alice and Bob will compete for space and whoever of the two who offers the higher fee gets included. With the value cap, users who transact with higher values will pay higher fees (same proportional amount but higher in absolute terms), which is more fair. The data size cap is more controversial because it should accommodate the economy and reflect the wishes of the users. This is easier to see when you consider an extreme example, e.g. if Bitcoin allowed only 5 transactions per block now, then obviously everyone will revolt, hence similarly if the transactions volume increases substantially in the future (due to popularity) then the users will revolt if the 1MB cap remains.



I failed to understand, what is a size propagation penalty? Why split up into smaller values?

can it be combined with a distributed mixer? PoA nodes should be mixer nodes too?