Bitcoin Forum
October 27, 2020, 04:07:22 PM *
News: Latest Bitcoin Core release: 0.20.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 [103] 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 »
  Print  
Author Topic: Slimcoin | First Proof of Burn currency | Decentralized Web  (Read 132784 times)
d5000
Legendary
*
Offline Offline

Activity: 2618
Merit: 2056


Decentralization Maximalist


View Profile
February 12, 2018, 07:51:45 PM
 #2041

If i am not wrong, these 3 proofs system represents a way to prevent attacks on the blockchain.
The PoS does represent more than 50% of the blocks, what if someone posses more than 50%... ?
The high proportion of PoS blocks is indeed "not ideal".
But it isn't possible to create a long fork only based on PoS blocks, because the "chain trust" value of the chain decreases when there are no PoW blocks [with reasonable difficulty] in the last couple of blocks. (For a 51%/double spend attack you must create a fork in secret and then try that others accept the fork as the longest chain. If you don't own significant hashrate that would be very difficult).
Obviously, a miner that is also a "staker" can game the system, but he must be a large whale and a decent miner to achieve a successful attack. Now if he's successful - what would he win? Very likely the value of the currency would tank, and I guess it's impossible that he sells his entire stake (again, he must own a lot to be successful) before the price drop. So the profit from the double spend would have to be bigger than the exchange rate loss he will get for his stake!



I want to retake one of the crucial questions for every "decentralized web" incarnation, as mentioned by Graham in one of his last posts (related to IPFS):

Who pays for the hosting of the content?

Decentralized web technologies based on Torrent or IPFS technology provide (or should provide) mechanisms for content to be shared easily by many peers. But for a web page being available "all the time" there must be someone (an individual or a group/swarm) who hosts the content "permanently", so it doesn't get lost.

To my knowledge, there are the following possibilities:

1. The most simple one: The publisher hosts the content on a machine that is online 24/7. This machine could be an average PC or notebook, but as these devices are often turned off because they're relatively expensive to run (electricity), most likely will be something like a home server, a Raspberry Pi or a modified router (depending on the technical knowledge) or even an old smartphone or tablet.
2. A variant of 1: The publisher hosts the content on a server in a datacenter. This could be
- a web space / web server (s)he purchases (can be very cheap or even free)
- a free or low-cost cloud storage service like Dropbox with the ability to share links publicly (Dropbox itself doesn't allow public folders anymore)
- a web-based service giving the possibility to host files, like Github/Github Pages.
- an IPFS pinning service (mostly paid, but relatively cheap)

3. A blockchain. There are special "data blockchains" like Steem or Datacoin.
4. A blockchain-based storage service like Sia or Storj.
5. An "altruists' P2P network" that is able to incentive many people to contribute space, like Freenet or ZeroNet.

Every one of these technologies has advantages and disadvantages.

Option 5 (an "altruist network") looks like something like the "holy grail" for P2P anarchists, but is a bit difficult to achieve if we want to preserve the nice Web2Web feature that readers don't need additional software to access the content. It may be possible using technologies like JavaScript "service workers" that operate in the background of a Web2Web reading app. And one would have to think about long-term scalability.

Regarding option 1 (content on a publisher-controlled computer), Slimweb would solve the problem that home PCs very unlikely have a static IP. It could succeed where Opera Unite failed because it's browser-agnostic. A Raspberry Pi distribution of the Slimcoin client and the Slimweb tools could help to increase the number of "hosts" that seed interesting Slimweb content.

For option 2 (content on a server) you could say - why not use traditional web technologies? Slimweb, however, here could achieve a better distribution of the content on the planet if the content is shared by other peers, and potentially more bandwidth. It would be like a "poor man's CDN". It also provides independence from static IPs.

To be able to "focus" on some of these technologies, the crucial question remains: What do we want to achieve with the decentralized web? What is the main goal?

Possible goals are: control over your own data, censorship-resistance, and an easy-and-cheap publishing tool. For some of these goals, some of the options detailed above are better suited than others.

An attractive vision for the "Slimweb" would be to stay an "technology-agnostic hub" and work with all those existing technologies. For example, the current web2web approach together with Sia and Namecoin would provide a service very similar to what MaidSafe and Substratum are trying to achieve on one single blockchain (and they've still not released anything). To use several blockchains does also carry scalability advantages.

"There should not be any signed int. If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1603814842
Hero Member
*
Offline Offline

Posts: 1603814842

View Profile Personal Message (Offline)

Ignore
1603814842
Reply with quote  #2

1603814842
Report to moderator
1603814842
Hero Member
*
Offline Offline

Posts: 1603814842

View Profile Personal Message (Offline)

Ignore
1603814842
Reply with quote  #2

1603814842
Report to moderator
1603814842
Hero Member
*
Offline Offline

Posts: 1603814842

View Profile Personal Message (Offline)

Ignore
1603814842
Reply with quote  #2

1603814842
Report to moderator
keliokan
Jr. Member
*
Offline Offline

Activity: 76
Merit: 1


View Profile
February 13, 2018, 02:15:56 PM
 #2042

Thanks all for the clarification.

K.
ZuSinus
Sr. Member
****
Offline Offline

Activity: 518
Merit: 261



View Profile
February 13, 2018, 02:19:07 PM
 #2043

Hello
Do I need to keep my wallet open for Proof of Burn?
muf18
Sr. Member
****
Offline Offline

Activity: 854
Merit: 310


View Profile
February 13, 2018, 02:25:52 PM
 #2044

Hello
Do I need to keep my wallet open for Proof of Burn?

Yes, and unlocked wallet.
gjhiggins
Legendary
*
Offline Offline

Activity: 1974
Merit: 1138



View Profile WWW
February 15, 2018, 08:40:39 PM
Merited by muf18 (2)
 #2045

I want to retake one of the crucial questions ...
fwiw, that pretty much accords with what I've found thus far. From my perspective, the key practical advantage of ni-URIs is that they resolve directly to metadata which describes the content and so informs the user's decision as whether to retrieve and render/execute the content.

Option 5 (an "altruist network") looks like something like the "holy grail" for P2P anarchists, but is a bit difficult to achieve if we want to preserve the nice Web2Web feature that readers don't need additional software to access the content. It may be possible using technologies like JavaScript "service workers" that operate in the background of a Web2Web reading app. And one would have to think about long-term scalability.
I was pointed to this: https://github.com/OleEichhorn/bitcoin-msvc - it's the last piece of the jigsaw I need to complete the implementation of web2web in the GUI wallet.

Elsewhere, I already have it working with Linux and OS X binaries. Slimcoin's “Inscription” list is a further adaptation of (Torrencoin's) torrent list tab which I nicked and adapted:



The qtwebengine examples offer a straightforward approach to rendering web content: https://doc.qt.io/qt-5/qtwebengine-webenginewidgets-minimal-example.html - the new v8 engine allows one to render self-contained web apps and distribute the html, css and javascript files in a reliable fashion via the Qt resource bundle.

The markup for including javascript source files becomes <script src="qrc:///pbt/webtorrent.js"></script> where the qrc protocol maps to the Qt resource specification, following the pattern in slimcoin/src/qt/bitcoin.qrc  ...
Code:
    <qresource prefix="/pbt">
        <file alias="index.html">res/pbt/index.html</file>
        <file alias="semantic.min.css">res/pbt/semantic.min.css</file>
        <file alias="style.css">res/pbt/style.css</file>
        <file alias="jquery.js">res/pbt/jquery.js</file>
        <file alias="webtorrent.js">res/pbt/webtorrent.js</file>
        <file alias="semantic.min.js">res/pbt/semantic.min.js</file>
        <file alias="jquery-migrate-3.0.0.js">res/pbt/jquery-migrate-3.0.0.js</file>
    </qresource>

I first got it working with the published web2web example, using their torrenthash, then switched it over to use the torrenthash generated for my post. Unfortunately, I wasn't able to get it seeded externally and seeding it locally was pushing the laptop a bit too far. Although the feature does function, I wasn't able to check that it functions with a torrenthash to content that I have published.



The blocker thus far has been that the MXE cross-compilation environment doesn't support qtwebengine - and in all likelihood, never will. Unfortunately, I haven't been able to find the time to familiarise myself with MSVC to compile up a Windows binary. The github repos I mentioned earlier looks like it could save me some time --- or someone else, if they fancied the challenge.

Quote
To use several blockchains does also carry scalability advantages.

And would form a robust network. Generally, I'm anticipating that an ecosystem will gradually cohere.

Cheers

Graham
gjhiggins
Legendary
*
Offline Offline

Activity: 1974
Merit: 1138



View Profile WWW
February 16, 2018, 01:02:43 PM
 #2046

Dunno what's going on here, my last post was interrupted by this request every time I previewed the page and any subsequent edits reliably result in the presented CAPTCHA page. I'm not getting the same result previewing this post (atm), I presume it's being triggered by a “suspicious content” algo but if the issue persists, the frequency of my technical postings will be accordingly reduced ¹ ...



¹ Traditionally you're limited to three cheers Smiley

Cheers

Graham
gjhiggins
Legendary
*
Offline Offline

Activity: 1974
Merit: 1138



View Profile WWW
February 16, 2018, 03:08:46 PM
 #2047

DYOR Dept ...

The promo article “How a New Blockchain-Based Project is Trying to Build the New Internet” ... (note the words “Skycoin team consisting of original Bitcoin and Ethereum developers”)
https://cointelegraph.com/news/how-a-new-blockchain-based-project-is-trying-to-build-the-new-internet

The takedown “Fifteen Minutes with a Scam Coin: A Hands on Approach”
https://medium.com/@somearenumbers/fifteen-minutes-with-a-scam-coin-a-hands-on-approach-4bd187206701

The “white” paper (referenced in the above takedown)
https://downloads.skycoin.net/whitepapers/a-distributed-consensus-algorithm-for-cryptocurrency-networks.pdf

Quote
Another class of algorithms, that we also rejected, involve electing a leader node. Agreeing to elect
one’s leader (or a temporary ruler), we contend, is not a very intelligent behavior either. Here is why.
Leader election is a natural adaptation in situations when group’s survival requires high intelligence, while
the average intelligence of group members is low. Hence the group, in order to to survive, has to find a
member who can make intelligent decisions for the group. Such behavior is modeled after sheeple, or after
species that have a predilection for being led, which does not seem to be congruent with cryptocurrency
community. Additionally, a leader is potentially a single point of failure, as she can be coerced by a
malicious entity to act against the interests of the society she was elected to represent. Therefore we
decided to drop leader-based models from consideration as well.

Vacuous conjecture resulting in utter psychobabble. This comprehensive and profound failure of ToM entertainingly reveals the depth of the developers' intellectual immaturity. They are so blissfully unaware of the depth of their ignorance, not only do they produce psychobabble (that they must know is psychobabble because they are speculating so wildly), they descend into farce by presenting it as though it were serious work ...

“We are curious if anthropologists or ethnographers could confirm this proposition, perhaps using their yet-unpublished research.”

Cue gales of laughter from any passing academic.

Cheers

Graham
d5000
Legendary
*
Offline Offline

Activity: 2618
Merit: 2056


Decentralization Maximalist


View Profile
February 18, 2018, 01:00:59 AM
 #2048

@gjhiggins: If I understand it the right way, your plan is to integrate a Web2Web viewer in the Slimcoin client (or at least a variation of it) and that the ni-URIs would be shared by the publishers, instead of the Torrent hash, and point to the metadata.

For me, the ideal situation would be to have two basic options for viewing the "Slimweb":
- a Slimcoin client with viewer (and possibly editor) for those that want to see Web2Web pages without having to rely on a third party. It would ideally be also an automatic Torrent sharing program.
- a JavaScript gateway app (like the minimal gateway I'm testing, but with possibly new functions like a "sharing button") to be able to present the contents to non-technical people. I consider that important because this is the point where most "decentralized Web" apps like ZeroNet and IPFS-based solutions are currently failing. This would have to rely on third parties - but this third parties could be everybody who runs ACME or provides a RDF dataset with blockchain data that follows the CCY ontology, so ideally there would be multiple places to get the URIs from the blockchain data.

There could be even more of these "apps", like a browser extension or a combined WebTorrent/Web2Web client that would work like a Zeronet app sharing everything you read, but without having to download the whole blockchain.

@Skycoin: Was on my sh!tcoin list from long ago - I simply didn't believe its "proposal" to be really factible. At least not in the short term most ICO roadmaps are promising.

gjhiggins
Legendary
*
Offline Offline

Activity: 1974
Merit: 1138



View Profile WWW
February 18, 2018, 02:33:13 PM
 #2049

@gjhiggins: If I understand it the right way, your plan is to integrate a Web2Web viewer in the Slimcoin client (or at least a variation of it) and that the ni-URIs would be shared by the publishers, instead of the Torrent hash, and point to the metadata.
Indeed. It's rather a fanciful notion of mine, I need to give a lot of thought to the security implications of enabling javascription execution in a running wallet, even with Qt/V8 sandboxing. That's why I initially kicked off with ACME as a web app.

HN has an interesting general illumination of a few of the archival storage issues .... https://news.ycombinator.com/item?id=16402803 I found it worth reading through the tarsnap FAQ https://www.tarsnap.com/faq.html (esp. “What happens if I run out of money?”) and the Amazon Glacier pricing schedule https://aws.amazon.com/glacier/pricing/ .

Quote
There could be even more of these "apps"...
Absolutely so. I'm currently looking at Fresnel, an RDF display vocab: https://www.w3.org/2005/04/fresnel-info/manual/ which will allow me to associate an RDF type (e.g. “WebProfile” or “FOAFpage”) with a chunk of HTML/CSS/JS that renders it. There  is a javascript implementation that I haven't actually tried yet and I also have a Python implementation for RDFLib, transcribed from some previous academic work: tobacconist which is nearly complete and which I plan to add to the Python implementation of ACME.

Cheers

Graham
muf18
Sr. Member
****
Offline Offline

Activity: 854
Merit: 310


View Profile
February 25, 2018, 10:22:38 PM
 #2050

I'm discussing with coinhouse, about wallet maintance stance, to help them get it out of it.
Coinsmarkets are returning it seems
bobitza202
Sr. Member
****
Offline Offline

Activity: 507
Merit: 253



View Profile
February 26, 2018, 07:16:38 PM
 #2051

I'm discussing with coinhouse, about wallet maintance stance, to help them get it out of it.
Coinsmarkets are returning it seems

Interested to see when novaexchange will come back  Grin
avariahb
Full Member
***
Offline Offline

Activity: 174
Merit: 100



View Profile WWW
February 27, 2018, 05:42:31 PM
 #2052

Of the 350,400 annual blocks, how many are
POB?
POS?
POW?

d5000
Legendary
*
Offline Offline

Activity: 2618
Merit: 2056


Decentralization Maximalist


View Profile
February 28, 2018, 09:29:33 PM
 #2053

I've published the modified blocknotify scripts here: https://github.com/d5000/acme-minitools . The scripts allow to run a basic node with a RDF graph to serve as infrastructure for Web2Web ("Slimweb").

Fuseki2 is required to handle the graph. I wrote a basic Readme file with some explanations.

Basically, I modified:
blocknotifybase.py adding some methods to run SPARQL queries and to provide a basic way to record "partial blockchains" (e.g. all blocks that contain OP_RETURN transactions) to the RDF graph.
- the various blocknotify.py ... scripts were "unified" into a single script called block2rdf-cli.py. This script can be run from the command line or as a "blocknotify script", and (afaik) it can handle mainnet and testnet. However, you shouldn't include it directly in the slimcoin.conf file as a blocknotify script but use the provided blocknotify.sh shell script, it provides a basic lock mechanism to avoid that multiple versions of the script run in parallel.
- I still didn't modify the other shell scripts, but I left them in the repo because they could be useful.

My modifications are very likely ugly and amateurish, but I tried to "embellish" the worst hacks a little bit Wink. I'm open to design improvements.

muf18
Sr. Member
****
Offline Offline

Activity: 854
Merit: 310


View Profile
March 01, 2018, 08:50:17 AM
 #2054

It's a great info.
I have already forwarded it to our group on telegram.
muf18
Sr. Member
****
Offline Offline

Activity: 854
Merit: 310


View Profile
March 01, 2018, 10:48:03 PM
 #2055

Please vote on us.
https://nextexchange.featureupvote.com/suggestions/3080/slimcoin-slm-the-original-proofofburn-cryptocurrency
muf18
Sr. Member
****
Offline Offline

Activity: 854
Merit: 310


View Profile
March 02, 2018, 08:16:33 PM
 #2056

Quote
Thanks Piotr,
I've received your coin listing submission and our devs will work on auditing and onboarding your coin.

They will get in touch if they have any questions, otherwise I'll be in touch in the next few weeks with your official coin listing date.

Thanks,
Emma
d5000
Legendary
*
Offline Offline

Activity: 2618
Merit: 2056


Decentralization Maximalist


View Profile
March 02, 2018, 09:43:41 PM
Last edit: March 02, 2018, 11:43:19 PM by d5000
Merited by psycodad (1), muf18 (1)
 #2057

A little tutorial for those who want to try to run a "Slimweb" node (for Linux/Unix) with the "acme-minitools".

You can read what the tool does in the README file.

Requirements:

- a server or virtual server (a cheap one will be enough, 1 GB virtual RAM or more recommended) or alternatively a PC which is connected permanently to the Internet with a static IP.
- Slimcoin full node (0.5 client or higher)
- Apache Jena (for database tools)
- Apache Jena Fuseki 2 (the server that provides the data to the clients, like gateways etc.)
- Python 3.5+ with the following libraries: requests and rdflib (install them via pip)
- Git (recommended, as it's alpha software and you may want to update it frequently)

Disk space:
- ~300 MB for Jena and Fuseki
- ~2 GB for Slimcoin blockchain
- ~1 GB for a partial blockchain with OP_RETURN transactions (enough to be part of the "Slimweb")
- additionally, ~7 GB for a full blockchain installation (not covered in this guide, it is not necessary for Slimweb but useful if you want to process various queries about the blockchain)

Jena + Fuseki Installation

Download Fuseki and Jena from the following source: https://jena.apache.org/download/
The current version is 3.6, you will be fine with the binary distributions.

Unpack them and install them in two folders of your choice.

In your .bashrc, you need to add the following lines (replace <jenadirectory> with the directory where you installed Jena):

Code:
export JENAROOT=${HOME}/<jenadirectory>
PATH=${JENAROOT}/bin:${PATH}

Installation of ACME-minitools
Select a directory where you want to install the node. In this example, you install it in an "opt" folder in your home directory.

Code:
cd $HOME/opt
git clone https://github.com/d5000/acme-minitools.git
cd acme-minitools

Configuration

Open the file coin.ini.sample in the acme-minitools directory in a text editor.

- Insert the rpcuser and rpcpassword values from your Slimcoin configuration file (slimcoin.conf in your .slimcoin directory).
- Insert the folder where you installed Fuseki in the line "fusekidir="
- Create a data directory and insert it in the "datadir=" line.

Save the file to coin.ini.

Create databases / Run Fuseki

It is recommended to run Fuseki in  Publication mode: In this case, the software will only save blocks in your database that contain OP_RETURN transactions (for example, Slimweb torrent hashes).

1. Create a folder for your databases.
2. Create a sub-folder there called pub_slmchain.
3. Go to the directory where you installed Fuseki.
4. Type in the following line (replace <databasedir> with the folder where you installed the databases) to run Fuseki in "publication mode":

Code:
./fuseki-server --loc=<databasedir>/pub_slmchain /pub_slmchain

It is recommendable that you use screen for that step as the server will run permanently.

Initial catchup

Start the Slimcoin daemon (slimcoind) and wait until it gets loaded. Go to the acme-minitools folder.

Start the command line utility:

Code:
python3 block2rdf-cli.py -P -l 15000

This will save all blocks that contain OP_RETURN transactions into your database. The "15000" is the number of loops the utility will run; one loop processes 100 blocks, so these numbers are enough for the current blockchain height (a mode that simply processes all blocks will be added soon). You can adjust these parameters, look at the --help option.

The script will run:
- until the number of loops is processed
- until you stop it - you can stop block2rdf.py at any time with CTRL-C, it will exit gracefully and save its progress.
- until the blockchain is complete.

As the first OP_RETURN transaction resides on block 966397, you can stop the utility with CTRL-C once it processes the genesis block; then run it with the following additional parameter:

Code:
python3 block2rdf-cli.py -P -l 5000 -o 966397

Let it catch up until the blockchain is complete and the script stops. This will take some hours.

Final configuration step
Insert the following line in your slimcoin.conf:

Code:
blocknotify=/<installation directory>/acme-minitools/blocknotify.sh %s

This step ensures that the script is run every time the client detects a new block, so the blockchain is updated in real-time.

Start the Slimcoin daemon again and ... everything should work now.

How to test if your node works properly

Open a browser on your personal computer (not on the server!). Type in the following:

Code:
http://<your-server-IP>:3030/

A control panel for Fuseki will open. Select pub_slmchain as dataset and insert http://<your-server-IP>:3030/pub_slmchain/query in the "SPARQL endpoint" form field. You can insert SPARQL queries in the big text data field. The following should provide you the last block height saved by the tool:

Code:
PREFIX ccy: <http://purl.org/net/bel-epa/ccy#>

SELECT ?block ?height
WHERE {
?block ccy:height ?height
}
ORDER BY DESC(?height) LIMIT 1

For advanced users: You can use the Slimweb Gateway and change the server IP in the source code to the IP of your server. So you can try your node "live".

I will try to modify the Slimweb gateway soon so you can use it without having to include the IP manually.

muf18
Sr. Member
****
Offline Offline

Activity: 854
Merit: 310


View Profile
March 08, 2018, 07:20:35 PM
 #2058

Gopax exchange will list us for 0.4BTC
I'm giving 0.1BTC , will anybody would be willing to give rest ? 0.3BTC? Help community Cheesy
gavrilo77
Hero Member
*****
Offline Offline

Activity: 804
Merit: 501



View Profile
March 09, 2018, 03:39:10 AM
 #2059

Gopax exchange will list us for 0.4BTC
I'm giving 0.1BTC , will anybody would be willing to give rest ? 0.3BTC? Help community Cheesy

What i have seen. GOPAX is better than Cryptopia and Yobit in volume and it is Korean market with volume ~4000 BTC. Not bad.
Count on my 0.1 BTC
Is there Gopax in English?
muf18
Sr. Member
****
Offline Offline

Activity: 854
Merit: 310


View Profile
March 09, 2018, 09:41:29 AM
 #2060

Yeah there is scroll below.
Ok, so 0.2BTC.
I'm just making sure he is real guy, not some imposter, but this would make us more visible I think, without it, it's hard really hard.
BTW. we can try another time on bittrex, they updated their website to add coins.
https://support.bittrex.com/hc/en-us/requests/new?ticket_form_id=114093958872

I don't have enhanced veryfied accountt, maybe someone will try to fill it in?
Pages: « 1 ... 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 [103] 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 »
  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!