Topic: [ANN] Datacoin - Censorship-Free Data Storage - page 41. (Read 66848 times)

Hi,

I received the same error cross compiling compiling the client using;

Ubuntu 14.04  x64
16 CPU's
65536MB Memory

Tnx,

H

Compile issue:

  CXX      wallet/libbitcoin_wallet_a-wallet.o
wallet/wallet.cpp: In member function ‘std::__cxx11::string CWallet::SendData(CWalletTx&, bool, const string&)’:
wallet/wallet.cpp:4337:95: error: no matching function for call to ‘CWallet::CreateTransaction(CScript&, int, CWalletTx&, CReserveKey&, int64_t&, std::__cxx11::string&, const string&)’
 ansaction(scriptPubKey, 0, wtxNew, reservekey, nFeeRequired, strError, txData))
                                                                              ^
wallet/wallet.cpp:2700:6: note: candidate: bool CWallet::CreateTransaction(const std::vector&, CWalletTx&, CReserveKey&, CAmount&, int&, std::__cxx11::string&, const CCoinControl&, bool, const string&)
 bool CWallet::CreateTransaction(const std::vector& vecSend, CWalletTx& wtxNew, CReserveKey& reservekey, CAmount& nFeeRet,
      ^~~~~~~
wallet/wallet.cpp:2700:6: note:   no known conversion for argument 1 from ‘CScript’ to ‘const std::vector&’
wallet/wallet.cpp:4345:61: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 2 has type ‘int64_t {aka long int}’ [-Wformat=]
     printf("SendData(): nFeeRequired = %lld\n", nFeeRequired);
                                                             ^
wallet/wallet.cpp:4347:33: error: ‘class CClientUIInterface’ has no member named ‘ThreadSafeAskFee’; did you mean ‘ThreadSafeQuestion’?
     if (fAskFee && !uiInterface.ThreadSafeAskFee(nFeeRequired))
                                 ^~~~~~~~~~~~~~~~
                                 ThreadSafeQuestion
wallet/wallet.cpp:4350:46: error: no matching function for call to ‘CWallet::CommitTransaction(CWalletTx&, CReserveKey&)’
     if (!CommitTransaction(wtxNew, reservekey))
                                              ^
wallet/wallet.cpp:3080:6: note: candidate: bool CWallet::CommitTransaction(CWalletTx&, CReserveKey&, CConnman*, CValidationState&)
 bool CWallet::CommitTransaction(CWalletTx& wtxNew, CReserveKey& reservekey, CConnman* connman, CValidationState& state)
      ^~~~~~~
wallet/wallet.cpp:3080:6: note:   candidate expects 4 arguments, 2 provided
Makefile:6415: recipe for target 'wallet/libbitcoin_wallet_a-wallet.o' failed
make[2]: *** [wallet/libbitcoin_wallet_a-wallet.o] Error 1
make[2]: Leaving directory '/home/miles/datacoin-core/src'
Makefile:9515: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/miles/datacoin-core/src'
Makefile:748: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

Not quite. This is work in progress that I published, an adaptation of Ahmad Kazi's work (Primecoin intermediary and Primecoin Core). The (Datacoin adaptation of the Primecoin) intermediary client ("intermediary" branch) functions as expected. The Primecoin Core 0.16 adaptation (master branch) is not as straightforward.

Thus far, I've managed to get it to sync up to block 4000-odd before it chokes, probably on an improper diff calculation or retargeting mismatch or some such gotcha. Running it under the debugger should throw a bit more light on the issue.

However, the challenging task is to migrate the RPC getdata and senddata commands. 0.16 is a very different environment from 0.8, the architecture is quite different, much more complex and forces the simplistic senddata interface to make some heroic assumptions - about which wallet to use, about which account to use - about which txin to use to pay the fee. The API call itself basically fails to provide basic information for the construction of a transaction to store the data.

I mean, I don't know whether it will fit ...


The reason I published the work in progress is so that anyone who wants to pick it up and run with it isn't waiting on me unnecessarily.

But it's work in progress. I don't even know if it works yet, I've only just now got it to compile successfully with the refactored API calls, now to find out whether it'll work okay without a receiver (new Bitcoin code can be much more strict about such things).

Cheers

Graham

Is this real life?

Will begin testing the new Datacoin client immediately.

Great work Graham! Do you have a development fund? I will contribute.

Also, about the our Datacoin testnet IP address, it's not consistent, i need to create something static.

Exciting times for Datacoin!

Regards,
DataSea

Thank you Graham!  OFC!

-extro

And, ofc, it only connects to the Datacoin intemediary client: https://github.com/gjhiggins/datacoin/tree/intermediary

Cheers

Graham

Datacoin Core 0.16

Graham Higgins has released an early version of Datacoin Core 0.16:  https://github.com/gjhiggins/datacoin-core

At this stage the client is obviously released for testing.  Use with caution.

Thank you Graham!  It has been a long, long road for this coin.

-extro

That's welcome news for the group, I reckon.


144.76.64.49:4776 is minkiz.co, which is currently hard-coded into the client as a dnsseed: https://github.com/datacoinproject/datacoin/blob/master/src/net.cpp#L1195 - (the Minkiz site is a long-term art project of ours, so I can be relatively confident that the service will persist for a few years more at least).

Which of the above IP addresses are referencing your nodes?

Cheers

Graham

Hi Team,

We've dedicated two rigs to keeping the Datacoin testnet going.
As part of their duties, each rig now has a single dedicated CPU churning to lay blocks and keep the chain alive at all times.

We do this as a service to Datacoin development.

As always, we offer free testnet coin and mainnet coin for experimentation.
Test away.

Kind Regards,
The HugPuddle Team

P.S.
The following nodes have been seen active on the Datacoin Testnet in the last 14 dayz:
144.76.64.49:4776
64.130.139.90:4776
192.175.69.10:4776
119.9.108.125:4776
[2a01:4f8:13b:30a2::2]:4776

P.P.S.
Testnet swarm:
"version" : "v0.8.6.0",
"protocolversion" : 70001,
"walletversion" : 60000,
"blocks" : 228076,
"moneysupply" : 7990047.57000000

Hi mohsenp,

Hmmm, interesting.
Is there any other error occurring?
How long does that hang like that?
What system are you trying to load Datacoin on?
What Datacoin-QT wallet are you using?
Where did you get it?
What is your favorite color?
Any other insights you have on the matter will assist troubleshooting.

May the Data be with you.

Regards,
The DataSea

My datacoin-qt wallet is not opened.why?
please help
http://i.imgur.com/yjaqY07.png

Well, then it's good

IMO, Linked Data. It's where I'm headed, anyways.

Cheers

Graham

We should talk to these folks at the Online Computer Library Center.
There has to be some possible convergence between the Dewey Decimal Classification and block chain technology which facilitates the advancement and diffusion of knowledge.

I'm not sure what it is - but they've been doing what we aim to do for a very very long time.

----------

    So in that spirit - here is my suggestion.


    A Killer Application is designed for the submission and review of erratum such that rather than going to the publisher to find corrections in a book you have just bought - you can feed the Datacoin Browser an ISBN number and it will render a few pages for you to print.

    Inputs would work like this: a reader finds an error and submits the correction to the Killer Application.
    The Killer Application manages consensus for the correction by crowd sourcing yay or nay votes and by allowing the author and publisher to bless a correction through the Killer Application.
    Both the correction and the ongoing vote tally are inscribed into the chain.
    The Killer Application uses its own schema and metadata to curate the collection so that the most valuable data rises to the top and we have full CRUD functionality.

    DTC is used to inscribe the data and to potentially compensate a contributor who will be given or provide a Datacoin address upon submission.

    In the future, a publisher would obtain a GUID for each edition, directly from the Killer Application.
    A reader could scan a QR code of the GUID which then takes them directly to the Killer Application's collection of errors and corrections for the edition.

    Possibly, we could even make the GUID compatible with public-key cryptography so that it is actually the public key to a new edition submission.
    This would enable the mechanics of having a publisher or author bless a correction.

You tell me.
What would be a killer app for Datacoin?

 killer-app？any details？

Go increase demand...
... it is a data blockchain after all -- develop a killer-app that requires Datacoin

Therefore, the mining of this coin will not be profitable

Well, divided by 10 :-D

how did you calculate?