Topic: Slimcoin | First Proof of Burn currency | Decentralized Web - page 49. (Read 137085 times)

Very interesting. So at this moment, one has to wait more than a year to get at least the PoB "investment" back. That's truly a long-term reward  (That's one of the effects why I like Slimcoin and PoB so much).

I have not minted by PoB in the last months, but in 2016/17 the time until to get the investment back was much shorter (3-4 months). That is obviously a sign that the burn rate has increased, and we may be now again above the "equilibrium" PoB rate - so it's likely that in the coming months people will burn less, because the expected short- to medium term reward is negative.

I should retake this study where I followed the burn rate for the first million blocks. But first, I want to advance further with Slimweb.

PS: My peers are:

I currently have 291 decayed coins.
A basic calcualtion assuming a linear rate will would indicate 4x return (3x net) over about 8 years.

How many coins have decayed?

I had a week full of exams and projects to pass, so I forgot about addnodes update.

Give me a minute to update it.

Peers from getpeerinfo.

85.10.208.71:41682
185.68.67.37:41682
144.76.64.49:41682
5.9.39.9:41682
78.46.37.209:41682

For those interested in the return from burning coins, I have updated the spreadsheet I started:
https://drive.google.com/open?id=1b04jiUde-wWvyk7yXzWibVeYc03yz0MB

I published a draft for the "Slimweb" to be discussed and reviewed on the Wiki at Github. Please feel free to comment and edit - I don't know if I have described your (especially @gjhiggins' and @ksdme's) plans correctly, some ideas in the "tentative roadmap" are also mine.

My next step will be to write a publisher and a reader guide, based on the small guides I published here on the forum. Also, it was suggested to draw a table to compare it to other "decentralized web" implementations like Shift, Tron, Akasha, Steem or Substratum, but also non-blockchain projects like Beaker or ZeroNet (if there is a relevant project I forgot, please point me to it).

There are active connections, I'll update peers, when I'm home.

Seems good project, but I had to re-sync my wallet...everything was going fine but then last night the wallet stopped syncing, apparently there are no active connections...

How much normally you were making ?

PoW diff isn't so high (as well as PoB in this regard), but again PoS diff skyrocketed, making things a little uneasy.

I know that economic model could be flawed, if we would switch to PoS 3.0, but I'm still wondering, if it wouldn't help with such events...

I must see and try myself, with my friend spinning testnet, and trying and couple of different settings to see, which could be best.

Difficulty is sky high!!! With couple of hundred of thousands burnt SLM i am finding like 10-15 blocks per day only

We are still running voting for Slimcoin on next exch

Vote if you can

https://nextexchange.featureupvote.com/suggestions/3080/slimcoin-slm-the-original-proofofburn-cryptocurrency

I just yesterday got the time to re-read the Trusty URI paper (I had already looked at it, but very superficial). I just wanted to make sure I understand your idea to create "assets" based on signed RDF graphs. So here's my understanding of it:

1) Let's say Alice is wanting to issue an asset to crowdfund her startup. She creates the following RDF graph (in simplified Triples, as example, "ccy" for the Cryptocurrency Ontology and "sla" as a prefix for "SlimAssets"):


(For those that do not know RDF: Blank nodes often are used if you want to relate a subject-predicate combination - e.g. Alice's "issuing" of the asset - to several predicate-object combinations - N-ary relations - without "splitting" the triple. In this case, the ID and the quantity are related to the "issuing act".)


2) She signs the graph and then includes a self-reference for the trusty URI.
3) She inscribes the Trusty URI into the blockchain.

Now Bob wants to buy 100 of these assets. He comes to an agreement with Alice (the payment process from Bob to Alice here is not important, that would be a separate issue). When he pays to Alice, she creates the following graph:

again, signing it with SAlliceSAddressxxx and creating the trusty URI.

She can now inscribe the graph in the blockchain, and so the asset transfer would have taken place.

Is this approximately correct?

(It's possible that it's necessary to include the trusty URI to the issuance graph in the subsequent transactions, e.g. if Bob is selling his assets. Maybe the Trusty URI for the issuance could even be the asset ID?)

In this model, not all data is inscribed in the blockchain, only the trusty URI, while the graph itself is recorded off-chain. What are the security implications? In theory, Alice could try to hack Bob's computer, delete his record of the graph, and then say that she never transferred him the assets, and that her trusty URI is referring to another transaction. Now this reminds me a bit of the security model of the Lightning Network: in LN, also, if your node isn't aware of the state of your channels, then your counterparty can scam you.

An interesting issue is that with this model one could create enormous asset transactions, serving 1000s of people with assets (e.g. for an "airdrop") but the blockchain entry would continue to be small. It could be even possible to combine this model with Lightning-like HTLCs, what would create a kind of "sidechain" for each asset, so asset transfers wouldn't have to be recorded at the main chain at all.

Thank you for the clarification.

Some of the members of the Slimcoin Owners Club are exploring the notion of inscribing TrustyURIs in the slot offered by OP_RETURN data. There are similar associated issues to be addressed, such as limiting tx search to specific addresses, etc.

Cheers

Graham

Both. Preference as it's easier to query the API then else (explained bellow). It's important to have current set of UTXOs, can't do without.

So, P2TH (pay-to-tag hash)[https://peerassets.github.io/P2TH/) is why is using API easier for now.
P2TH is an address, which is like a directory from which tree structure can be derived. It's used to query for new decks (assets) and their card (token transfers).
So, flow when using a local node is a bit awkward. P2TH is imported into the node via `importprivkey` and then via `listtransactions` it's queried.
This can be resolved by using latest Bitcoin-core code which offers `txindex` and other marvels, which allows you to simply query a address without importing,
hopefully that will come later this year for us.

Another solution is using electrum-server.

Thanks for contributing to the discussion. My aim was to open up some of the practical implications that I thought might be in danger of being glossed over.

It's not so much that the presence of Iquidus in the mix is alarming, no more so than any nodejs app, it's just that the requirement (or otherwise) was unclear from the README and signalled that some more extensive due diligence was indicated.

If the app can talk to the client, then is the block explorer a matter of operational convenience? Or maybe is it that a current UTXO set is a vital part of the app's functioning?

Cheers

Graham

There're some hard-coded references to ppc/tppc remaining but perhaps of more concern to anyone proposing to implement PeerAssets are the dependencies. btcpy being one such example:

(original emphasis retained)


Not forgotten, merely thrashing out some details. Apart from the obvious practical issue of figuring out how to use message-queueing to enable the blocknotify script to run asych, I felt I needed to acquire more direct experience in hacking the codebase directly (elsewhere, I hasten to add) before proceeding and lately I've felt a need to consider the implications of GDPR and friends. I believe TrustyURIs in themselves are not PII (there has been some informative HN discussion about how the practicalities of observing "right to be forgotten"actually play out in the context of backups) but how it's going to work in practice for federated RDF graphs requires some extensive thought.

The fact that SPARQL searches can be made on federated graphs seems to satisfy the networks' requirement for an appropiately non-centralised solution but I believe anything other than a "click'n'deploy" approach to provding a [group|self]-publishing service will fall short of basic user requirements. This particular approach was never going to be as simple and easy as setting up an account on FB but I reckon it might be possible to achieve a suffciently gentle on-ramp slope to present at least a viable alternative.

Cheers

Graham

Hello guys,

you do not have to use iquidus backend, thought that is the simplest way trust me. It also enables light clients to exist.

Pypeerassets has concept of "provider", ie. a link with the network. It's used to fetch UTXOs, to query transactions, to send transaction.
A local node can be used via RPC: https://github.com/PeerAssets/pypeerassets/blob/master/pypeerassets/provider/rpcnode.py

Mh. I had also proposed to adopt PeerAssets some time ago because I liked the simplicity they claim (I had helped testing it in the Peercoin community, but very superficially, at this moment it seemed pretty buggy still).

But seeing that they're relying (if I understand it right) on a infrastructure of centralized block explorers doesn't really make this concept attractive for me. It could be adapted, in theory, to the SPARQL-based infrastructure (e.g. ACME) we have now, but then we would need to install a network (ideally, with nodes around the world) of very stable servers running these block explorers.

There are alternatives like OpenAssets, Omni and Counterparty that could be used instead. Counterparty for example seems a bit complex but at least it was already adapted to an altcoin blockchain (Doge).

But I remember also a RDF-based idea for these purposes ...

Immaterial.

The app needs infrastructure support in order to function, specifically it relies on the API provided by the Iquidus block and tx explorer - in this instance, adapted to work with Slimcoin. I'm not aware of such a beast.

Cheers

Graham

Hmm... Well @peerchemist have said, that adoption it to Slimcoin shouldn't take more than 1H.

Besides a lot of PoW blockchains have been recently attacked by 51% attack, double-spending them.

https://blog.zencash.com/zencash-statement-on-double-spend-attack/
https://www.trustnodes.com/2018/05/24/bitcoin-gold-51-attacked-18-million-stolen-double-spends
https://old.reddit.com/r/monacoin/comments/8k7640/51_attack_on_monacoin/

Developers as we can see, don't have real mitigation and solution to the problem, other than "patch" of increasing to enourmous amount of confirmations, until transactions is confirmed, which isn't really a viable solution.

As we can see such blockchains as Peercoin or Slimcoin, with even more security derived from PoW/PoB mining and PoS minting is a much more secure design.

And it's much harder to attack such blockchains.