Because I don't have the resources to populate a peer-to-peer network to test it privately myself, I couldn't actually predict whether it would work at all. I offered it up so that people could, if they wished, see if their balance showed up correctly.

It would be great to be able get palmd's input, we last interacted a few years ago at the start of Spreadcoin - which is handy because as several other altcoin communities have found, devs are fairly reluctant to take on the responsibility for someone else's hacky code (and the Navcoin code itself is somewhat hacky).

I'm still looking into the source of the issue, the port is pretty much done and mostly working. I think it's a matter of ensuring that the configuration is internally consistent and coherent after the adjustment of the parameters to reference billions of coins rather than millions. I recently switched over to Helium for a couple of weeks to thrash out the details of their public ledger transfer and in the process, deepened my model sufficiently to be able to return to the Navcoin->Bee port with a much better understanding of what I might have got wrong. It was/is the next thing I was/am planning to do after attending to bitcointalk responses. I'll report back later this evening.

Cheers

Graham

All commands are listed here: https://github.com/slimcoin-project/Slimcoin/blob/master/README.md#all-cmmand-line-options

To suppress staking, add reservebalance=1000000 to the config file.

(At some point, I'll understand Qt internal signalling sufficiently well to be able to hook up the GUI reservebalance setting to the innards of the engine.)

Cheers

Graham

See for yourself: https://github.com/primecoin-ng-group/primecoin-core/commit/5d41110c745c74e1eeb85f187f54777bf5e6407f

Cheers

Graham

I set 20000 blocks as a trial, staking tx have to mature which means blocks have to be initially mined until the staking weight starts to support the network. PoS didn't kick in as I expected so I guess there's something that I don't yet properly understand but then again the network consisted of just three of my machines and PoS alcoins can get really cranky with small numbers of nodes. I need to look again at the code.

Cheers

Graham

You only post baseless FUD, no need for him to defend himself and certainly not here - intemperate rants against Helium in this thread are clearly off-topic as would be any substantive response. I imagine georgem will round to clean up sooner or later.

On another topic - does anyone have any hard information (or even gossip) about an unadvertised SPR network of 100+ masternodes?

Cheers

Graham

I'll just chip in with a strong (experience-led) exhortation to consider including (at least optional) descriptive metadata.

Cheers

Graham

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/ .

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

Yes, of course. As I had to remind myself, they're probably listening but the router for the (home?) subnet they're connected to won't be forwarding on 31774 unless the user has either enabled NAT (against the advice of the DHS) or set up port forwarding.

Cheers,

Graham

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


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

I just filtered these (79 nodes) off've my client's getpeerinfo results ...


addnode=5.254.66.101:50298
addnode=5.68.54.99:31174
addnode=5.9.31.67:49126
addnode=12.13.193.227:60936
addnode=24.168.32.40:6193
addnode=24.9.70.204:54975
addnode=34.227.77.6:56497
addnode=37.189.255.136:65358
addnode=42.115.71.61:58955
addnode=45.28.140.116:62007
addnode=45.33.51.122:31174
addnode=46.105.98.179:31174
addnode=46.164.237.90:61138
addnode=46.242.35.119:51812
addnode=50.89.159.163:31174
addnode=50.89.159.163:49771
addnode=51.15.208.17:39942
addnode=54.83.128.67:45972
addnode=67.173.62.28:60524
addnode=67.190.62.252:31174
addnode=68.104.115.19:52912
addnode=68.195.28.248:31174
addnode=68.195.28.248:63957
addnode=68.96.96.143:59827
addnode=71.67.143.27:42425
addnode=73.196.204.117:31174
addnode=73.228.139.14:50420
addnode=73.95.169.154:62328
addnode=75.118.15.224:31174
addnode=76.103.125.46:44372
addnode=76.170.119.118:51353
addnode=77.190.169.17:65479
addnode=78.128.90.139:11140
addnode=78.66.36.36:49906
addnode=79.8.1.204:56356
addnode=81.61.92.19:57977
addnode=82.118.249.27:52464
addnode=83.84.173.136:23617
addnode=84.81.89.187:50032
addnode=86.148.246.170:61134
addnode=86.16.8.251:2580
addnode=86.21.88.174:31174
addnode=86.6.94.20:31174
addnode=88.17.148.10:55830
addnode=89.216.104.196:31174
addnode=92.210.93.81:54276
addnode=93.86.133.150:56786
addnode=94.242.254.66:40046
addnode=95.25.66.133:60923
addnode=99.189.170.199:50649
addnode=99.99.253.228:39920
addnode=104.239.139.17:33179
addnode=104.6.36.22:50761
addnode=108.31.223.236:31174
addnode=109.233.58.44:43200
addnode=109.252.60.102:13691
addnode=118.102.74.85:58544
addnode=118.102.74.85:59510
addnode=138.197.211.12:31174
addnode=138.201.35.158:31174
addnode=142.196.87.121:53317
addnode=145.239.28.208:46014
addnode=158.69.32.10:51376
addnode=163.172.138.202:53180
addnode=168.195.223.229:47284
addnode=170.130.28.170:51822
addnode=178.63.60.7:36500
addnode=179.113.194.75:49415
addnode=188.126.72.192:64616
addnode=188.40.131.43:41392
addnode=192.99.7.115:31174
addnode=193.23.157.12:55443
addnode=193.70.47.2:38163
addnode=213.60.163.199:48106
addnode=219.136.252.124:54817
addnode=219.136.252.124:55639
addnode=219.136.252.124:61613
addnode=219.136.252.124:63638
addnode=220.118.173.91:31174


Cheers

Graham

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

Cheers

Graham

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.

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  ...

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.


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

Cheers

Graham

Unfortunately, I'm not in a position to say - circumstances constrain my work to a laptop format.

Cheers

Graham

That's the understanding I'm arriving at, with a similar degree of caution.

There's a useful level of detail on consensus mechanisms in SoK: Consensus in the Age of Blockchains if you skip to p7, “1) Attacks and Mitigation”

(Sloppy on “Slimcode” tho' --- yes, they do mean us. It's a shame that their shallow approach to the domain beguiled them into making a completely unnecessary incorrect assertion. I mean, why did they even bother to make the statement? It speaks to me of research bias --- been there, got the T-shirt. And I find it useful to bear that in mind when reading, hence the pointer to that specific section - the rest of the paper is a mixed bag.)

Cheers

Graham

Especially in view of the fact that a Core client also offers an HTTP RPC: https://github.com/bitcoin/bitcoin/blob/master/src/httprpc.cpp#L229

Paul Frazee gets a quote in the IBT's: (Decentralisation experts unpack the problems of 'Web 3.0' Nick Szabo, Zooko Wilcox and Paul Frazee talk about the goals and challenges of the next generation of the internet) http://www.ibtimes.co.uk/decentralisation-experts-unpack-problems-web-3-0-1658382


However, just because the media are trialling a new narrative, it doesn't mean that there's any deep understanding there:


That would be a centralised decentralisation, wouldn't it? Splendidly absurdist nonsense.

Cheers

Graham

 Once again, heartfelt thanks for the feedback. What you describe is plausible. I'm in the process of updating the UTXO set, so your new addresses should show up in that.

It also occurs to me that the genesis block transactions which form the public ledger could be rephrased in a more accessible fashion by changing the transaction referents from pubkeys to addresses, i.e. change:

   txNew.vout[0].nValue = 10000000 * COIN;
    txNew.vout[0].scriptPubKey = CScript() << OP_DUP << OP_HASH160 << ParseHex("abee155f02a09bd70b498be5af25d7991703e404") << OP_EQUALVERIFY << OP_CHECKSIG;
    genesis.vtx.push_back(txNew);

to

   txNew.vout[0].nValue = 10000000 * COIN;
    txNew.vout[0].scriptPubKey = CScript() << OP_DUP << OP_HASH160 << ParseHex(DecodeBase58ToHex(std::string("3HN6ggDkexkUrHR7NNpgbhkBRY7eBckhMJ"))) << OP_EQUALVERIFY << OP_CHECKSIG;
    genesis.vtx.push_back(txNew);

Then people could just search the chainparams.cpp source for their address(es) and balance(s).

I'll make the switch when I re-generate the genesis block using the updated UTXO set. I'm just waiting for beecoinv2 to finish syncing before running the Python script that updates the UTXO database.

Cheers

Graham

No, not wrong at all (I come from a different part of the universe, one where users are not referred to as “lusers”). Thanks for trying this out, it is hugely important to get feedback on actual use in the field, so to speak.

Could you try importing the individual BEE2 privkeys?

It may be because Bee Core 0.13 has native support for HD wallets. I don't know if it can import non-HD wallets from dumped from previous versions.

(Still hoping Plan A will work).

Cheers

Graham

It's not my intention. I'm a cognitive psychologist by discipline and a cognitive scientist by profession, the latter mainly defined by its use of computational models as investigative tools (hence my broad but patchy knowledge of programming / software engineering --- it was acquired pragmatically and in a piecemeal fashion). Although local constraints circumscribe my involvement to that of a hobbyist, if I had a professional interest as such, it would be in what you might be forgiven for thinking is a bit far-fetched but is very real and also very pertinent to altcoin communities: aspects of Theory of Mind as they pertain to collective intelligence.
https://phys.org/news/2015-06-intelligence-online.html
https://gfbertini.wordpress.com/2016/04/25/theory-of-mind-predicts-collective-intelligence-equally-well-online-and-face-to-face/

For convenience:
I'm applying an altcoin context to the questions: “how can we measure the ability of others to communicate in a group, and how can we quantify the effectiveness of a group”.

Except that I'm changing the question away from measurement and quantification to: “how can we best support ...”

Basically, my interest is in understanding the user task information requirements - what information is required to perform a specific task and how it should be presented to best support the process (of creating and maintaining accurate mental models of others).

Unfortunately not. The Navcoin clone of Bitcoin Core 0.13 was an exercise in expediency, with parts of the code short-circuited in order to simplify the initial PoW phase - which I hadn't expected, so wasn't looking for.

It's because by the time Bitcoin Core 0.13 was released, the block generation part of the in-wallet miner had been completely obsoleted on mainnet by the shift to ASIC mining and the functionality/API had been adjusted to assume a testnet context with setgenerate (create blocks via continuous hashing) giving way to generate/generatetoaddress (create blocks on demand).

I tried the x11 miner without success and stopped at that point. So I'd had to use generatetoaddress to hand-crank the blockchain. What I hadn't spotted was that the API block generation code generated candidate blocks according to PoW diff rules, in an entirely different location in the codebase, the code had been adjusted so that (all) candidate blocks were checked against PoS diff rules, hence the failure to match. I guess the Navcoin devs chose a different route.

I was able to route the candidate PoW blocks to the appropriate checks and get generatetoaddress working, hand-cranking (via a scheduled task) the PoW block generation phase. I have left Navcoin's staking schedule in place (because it has a 2hr minimum staking time whereas Bee has 7 days and I'm not hanging around for a week).

Anyway, staking does seem to be working ...



(The 50 BEE amounts aren't actually stakes, they are mislabelled PoW blocks.)

No, I was merely explaining the presence of a test premine in the committed code as “Plan B”. But having already performed some limited tests of the ledger transfer mechanism, I do have some justification for expecting “Plan A” to execute flawlessly.

But you might want to try it out for yourself. ATM, a candidate pre-release version of the Bee Core 0.13 network using a throwaway UTXO set is (thus far) happily ticking away on minkiz.co (our rented Hetzner box) and on two Linux laptops running locally (my new XPS with Mint 18.2 and my old Acer running Ubuntu 17.10).

I imagine most subscribers to this thread use Windows and am happy to report that (bar a couple of small tweaks) MXE cross-compilation of Windows binaries works out of the box  (https://minkiz.co/noodlings/bee/bee-qt.exe.zip), although I've not had chance to check its functioning on a Windows VM as yet. Edit: Windows users will need to set port=19999 in the config file, at least until I refresh the binary

Linux source code is available pro tem from: https://github.com/gjhiggins/been

It should just sync straight up. If not, addnode=144.76.64.49:19999

You should be able to check whether your imported BEE2 privkeys show any balance at all and if they do, whether they stake (2hrs minimum wait, atm). It's an elderly UTXO, when we're ready actually do the hard fork, I'll update it to reflect the distribution at that point and re-do entire the genesis block creation / PoW mining phase.

Cheers

Graham

I was ignorant about Hubzilla previously; having skimmed the narrative description of the Zot protocol, fwiw I think you're spot on. They summarise it as “a JSON-based web framework for implementing secure decentralised communications and services.” and I would characterise the SOLID approach as “a JSONLD-based web framework for implementing secure decentralised communications and services.” Only two letters extra but it makes a big difference in terms of opening up access to already worked-out solutions.

My conceptualisation runs as follows:

I create a convention by using the in-browser bip39 HD keygen implementation to create a handful of notional "identity” addresses at sub-level m/44'/63'/0'/8/*, one for each identity that I wish to distinguish - as exemplified below (each one given a label for convenient reference):

m/44'/63'/0'/8/0	Sa3evx12ZgTDHqvuT5xpBaAYA5PQAmZFDM	gjhiggins
m/44'/63'/0'/8/1	SffwZ6jriJbnYtB27hbA9SzhpWYqf8WdoT	minki
m/44'/63'/0'/8/2	SYXxitjEU4KjVoXSrLLPwUhxEzpdjNr6Ud	gj

(I'm complicating matters slightly by using a bip39 wallet but the deterministic aspect means that re-entering the passphrase re-creates the privkeys for my identity addresses)

The convention continues ... in txouts spent by the “identity” addresses (e.g. Sa3evx12ZgTDHqvuT5xpBaAYA5PQAmZFDM), the OP_RETURN data is to be read as a ni-URI¹ formatted “Trusty URI”², e.g.

ni:///sha-256;5AbXdpz5DcaYXCh9l3eI9ruBosiL5XDU3rxBbBaUO70?module=RA

In the intended bog-standard modus operandi, the publisher will either self-host a SLM-ACME or will have a subscription to an SLM-ACME service hosted by a third-party and the  ni-URI value will resolve to a signed graph, retrieved by a SPARQL query posed of the graph:

SELECT ?g WHERE {
  ?g ccy:graphSignatureHash 5AbXdpz5DcaYXCh9l3eI9ruBosiL5XDU3rxBbBaUO70
}

The signed graph can contain whatever you like, as a file resource (module=FA) or an RDF document (module=RA). The latter makes more sense in a decentralised context where the need for apps to “discover” meta-data starts to become acute (happily, RDF documents are self-describing). Identity addresses would have to be published through sidechannels, such as this thread.

The minimum requirements of the SOLID WebId Profile would seem to be satisfiable, same goes for most of the SOLID-recommended vCard.

Very cool. Sorry for the non-reply to your earlier question, I completely lost track of time - I didn't have an answer anyway.

Nice work.

Another direction in which to pursue the notion of using OP_RETURN data to carry resolvable pointers to content/metadata - there's a very accessible HN discussion of IPFS basics which is very pertinent, especially the comparison of IPFS and torrenting practilcalities.

“One thing I've failed to find out about IPFS: who pays for hosting? The user? Or is it donated by some peers?” - https://news.ycombinator.com/item?id=16078975

I think I mentioned, I gave IPFS a spin. IPFS locators as OP_RETURN data would also work. There's a javascript implementation with some interesting in-browser examples: https://github.com/ipfs/js-ipfs/tree/master/examples and a ipfs-api https://github.com/ipfs/js-ipfs-api. It's on my stack to investigate, using the resurrected neocities.org - https://neocities.org/api and their support for ipfs DNS - https://blog.neocities.org/blog/2017/08/07/ipfs-dns-support.html

I still think RDF has an overwhelmingly significant advantage in that the torrent and ipfs protocols are incapable of carrying metadata which necessitates the use of separate sidechannels for the communication of associated user-vital info such as title, creator etc.

Cheers

Graham

¹ https://datatracker.ietf.org/doc/rfc6920/ Naming Things with Hashes - RFC 6920

² https://www.researchgate.net/publication/259845637_Trusty_URIs_Verifiable_Immutable_and_Permanent_Digital_Artifacts_for_Linked_Data

“Trusty URIs end with a hash value in Base64 notation(i.e. A–Z,a–z,0–9,-, and representing the numbers from 0 to 63) that is preceded by a module identifier. This is an example:

    http://example.org/r1.RA5AbXdpz5DcaYXCh9l3eI9ruBosiL5XDU3rxBbBaUO70”

For best results, conduct your Turing test off-line and face-to-face.

Cheers

Graham