Bitcoin Forum
December 01, 2020, 06:35:44 AM *
News: Bitcointalk Community Awards
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 107 »
1  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Slimcoin | First Proof of Burn currency | Decentralized Web on: November 29, 2020, 11:44:19 AM
why dont u start paying gjhiggins guy for his work? This walton goggins fellow, or call him walton higgins, he is here to donate his life to u.
Had you more respect/regard, you might have questioned the reliability of your assumptions. I'm not for hire.

Cheers

Graham
2  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Slimcoin | First Proof of Burn currency | Decentralized Web on: November 29, 2020, 11:41:31 AM
... begin to speak without having technical knowledge ... what each quick suggestion they have would imply to you in terms of time and effort

So I apologise for all the times I've spoken like that.
Thank you for appreciating that, creating detailed esponses to unconsidered "why don't we ...?" suggestions is getting more tedious to me as time goes on. Without at least a basic technical grounding it's all too easy to indulge in flights of fancy.

Quote
I think when we speak about your personal interest there are two kind of personal interest, and I'm not sure which one you are referring to: the financial and the ideal one.
Neither, it's far more prosaic than that. As I've mentioned previously, I'll be 70 next year and I literally don't have time to waste pursuing other people's fantasies.

Quote
I believe the PoD token will become the game changer in the cryptoworld. Maybe it won't shine in the context of SLM, because we may not be able to convince people that the PoD token can function in this context, but I hope it will influence people to do great things that will help the mankind:
Many people apparently hold similar personal beliefs and some have used them as justification for the launch of a crytpocurrency. One thing that has become evident is that belief isn't enough on its own. If your notion is to have even a chance of success then it needs to be grounded with solid market research, else you're basically dealing in the realm of fantasy.

Quote
I think that the time of the coins that are just clones, a mix of existing technologies and even of existing ideas is over.
Only the coins that have something really new will get the necessary attention. People are literally fed up with all this mixing and relaunching of the old stuff without sense.
Again, solid market research would give you the facts and figures on which base reliable inferences and conclusions. It will also inform your marketing tactics and strategy.

As regards the Slimcoin community, I'll leave you to reflect on what the occasional staker's experience might be if the listening nodes all switched over to using an 0.16 client which ignored connections from old clients.
 
Cheers

Graham

3  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Slimcoin | First Proof of Burn currency | Decentralized Web on: November 27, 2020, 02:24:01 PM
I understand your point
I don't believe you did. I wasn't referring to ROI for others but personal ROI for me. I'm never sure who these "we could" suggestions are aimed at. As far as I know, I'm the only member of the community with the requisite skillset and without any kind of disambiguating "this is how we'd do it" context, they come across as implying that I should undertake the work and if that's the case, I'm the one you need to convince that the time and effort would be worthwhile.

Creating new coins isn't all that demanding, technically speaking. For several years now, I've kept Minkiz' Foundry up to date with the latest Bitcoin version (now working on the 0.20 template).




Minkiz' Foundry started off as a non-functional ironic comment on all the algo-variant altcoins released a few years ago which were basically the same Bitcoin codebase except they used a different PoW algo. As this was a relatively trivial change to the codebase which could be easily automated via a template-based solution, it amused me to make the tongue-in-cheek offering secretly real. (You'll notice that the Dcrypt algo is one of the offerings.)

I used a Foundry 0.16.3 template as the base for an upgrade of Gapcoin from 0.9 to 0.16.3 (https://github.com/gjhiggins/gapcoin-core) and similarly for Datacoin, upgrading Crossverse's 0.15.99 upgrade of the 0.8.6 client to something more maintainable (https://github.com/gjhiggins/datacoin). Unfortunately, neither community is what you might call enthused.

It's easy to launch coins but these days it's far more difficult to attract the interest and engagement of a new community (one recent example here https://bitcointalk.org/index.php?topic=5293602.0)

Cheers

Graham
4  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Slimcoin | First Proof of Burn currency | Decentralized Web on: November 27, 2020, 01:31:47 PM
Just to throw in an idea: Could it be possible to require UTXOs to be "whitelisted" for them to be enabled to stake?

This would change the standard mode of "stake with all UTXOs you find in the wallet" to "only stake with UTXOs that are specifically enabled to participate in the minting process". So if new staking/mining/burn rewards come in, they would not be used for staking, giving the owner time to consolidate the wallet.

If this was possible, and along with iguanadon's optimizations (which obviously are another "item" that would have to be ported to the new wallet), this could result in less computational load.
Reasonable at first glance but I'd prefer to find out first how an 0.16.3 Slimcoin reference client performs with a lavishly-funded wallet before adding more potential for bugs. There's also the possibility of riffing off've (or ripping off) John Doering's dual-thread staking solution for Orbitcoin https://github.com/ghostlander/Orbitcoin/commit/a846b5d8b55bc09cc0fb20f86cc1ef4426b450f9 - a rather well-executed  Peercoin clone that still has a respectable profile on freiexchange (https://freiexchange.com/market/ORB/BTC).

Cheers,

Graham
5  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Slimcoin | First Proof of Burn currency | Decentralized Web on: November 27, 2020, 01:18:44 PM
But in the same moment we'll have another coin, (like people that have BTC and BCH in the same time) that carries on the original idea of PoB and develops it into direction that can help it recover the community and the market price.

I'll emphasise this point until its significance is acknowledged and the issue addressed ...
I find it difficult to see any significant demand for a new Slimcoin chain, which makes the personal ROI very doubtful.

Cheers

Graham
6  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Slimcoin | First Proof of Burn currency | Decentralized Web on: November 27, 2020, 12:50:50 PM
I think switching to this model would make more sense. Maybe we can create SLM+ based on blackcoin?
To launch a new coin we don't need to ask the Community if someone wants to switch he'll be able to using swap.
No, for a PoB coin it would make no sense at all as Blackcoin derivatives are pure PoS. Only Peercoin derivatives are hybrid PoW/PoS and they necessarily inherit Peercoin's PoSv1 staking kernel. You can dismiss all thoughts of a PoB/PoSv2 chain.

(I didn't realise that by mentioning blackcoin, I'd be creating quite so much confusion, sorry)

Cheers

Graham
7  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Slimcoin | First Proof of Burn currency | Decentralized Web on: November 27, 2020, 12:41:28 PM
... generally speaking I was thinking whether it can make sense to launch a new coin, let's call it Slimcoin-Plus, with the same idea of PoB and with a swap premine for all the willing Slimcoin owners
Given the number of Slimcoin addresses in the top 100 that have been active in the last couple of years (https://chainz.cryptoid.info/slm/#!rich), it would appear that the majority of Slimcoin owners are fairly comfortable with the approach of occasionally firing up the wallet in order to collect their accrued stake. I have contemplated your suggested approach but, given the apparent fact that the majority of the community seem to be uncomplaining hodlers, I find it difficult to see any significant demand for a new Slimcoin chain, which makes the personal ROI very doubtful.

Cheers

Graham
8  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Slimcoin | First Proof of Burn currency | Decentralized Web on: November 27, 2020, 12:28:59 PM
i started it because wallet began to freeze very often for a long time and I decided to reduce the size of wallet.dat (4 mb now)
with Linux, I started experimenting because subjectively it seems to me that synchronization there is much faster
Yes, that's my experience too. Immediately after startup and at arbitrary times the GUI is so sluggish that it appears to freeze (even with iguanadon1's PoS optimisation). I haven't found it to be unreliable, just very, very slow for a while after initial startup but if I let it run for a while, the response improves after it's finished its initial staking frenzy. The latter is an unfortunate but obvious side-effect of running a PoS v1 coin where staking isn't tied to the time online but to having UTXOs. The Slimcoin community (as with the Peercoin community) has shown no interest in moving to a PoS v2 staking kernel (a la blackcoin) where the node has to be permanently online in order to accrue opportunities to stake.

Cheers

Graham
9  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Datacoin - Censorship-Free Data Storage on: November 27, 2020, 02:45:15 AM
Quote
But from what I understand, the 0.15 version is the unique that can broadcast txs  to both 0.8 and 0.16 nodes (and 0.15, of course).
I don't think that's the case but I will check.
I checked with my own version of the 0.16.3 client (available here) and it does successfully broadcast senddata txs: https://www2.bytestamp.net/blocks/qtx/en/c58ecabe71ffa403b9c962a509ff3ffda3659b895ffbca23db714c06c4a4d51f

I've cut an alpha release of this reference client if people want to d/l it and play with it on testnet https://github.com/gjhiggins/datacoin/releases/tag/alpha (I've made Windows and OS X binaries available) and I have a node running the Datacoin testnet chain on 144.76.118.44, generating blocks for 2mins out of every 10, just to keep the tip from getting stale. Feel free to have a play, difficulty is low. Unless configured otherwise, the client will sync to the Datacoin mainnet chain (although harmless, it's not what you want atm), so an appropriate conf file would be:

Code:
rpcuser=<rpcuser>
rpcpassword=<rpcpassword>
testnet=1
server=1
listen=0
txindex=1
gen=0
genproclimit=1
listenonion=no
addnode=144.76.118.44
(edit to suit your preferences), or just use -testnet on the command line if you prefer.

Cheers

Graham
10  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Slimcoin | First Proof of Burn currency | Decentralized Web on: November 27, 2020, 02:04:34 AM
If I understand correctly you were trying all these years to mitigate the consequences of the decisions of the other people, that have left this project years ago.
Not mitigate, no. My skillset doesn't extend that far. Apart from adding a few GUI/RPC-API enhancements, the majority of the changes I made were basically to bring the Slimcoin codebase up to date with Peercoin development - as far as I could. That activity came to an end when Peercoin hard-forked its protocol and I couldn't see any support for that in the Slimcoin community. iguanadon1's PoS optimisation does mitigate the computational effort via caching of the computational results, thus reducing the load and enabling the client to be responsive to user commands.

Quote
Maybe it may make sense to change the architecture that is creating all this resources usage, since we are probably in the middle of the upgrade to latest Peercoin's code?
If you've any concrete suggestions to make on how this might be achieved, this'd be a good place to air them.

Cheers

Graham
11  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Slimcoin | First Proof of Burn currency | Decentralized Web on: November 26, 2020, 03:40:54 PM
Are you testing Graham's instructions above?
yes, it works with v6 only, compiling v5 still breaks with error
now i started sync from zero then i will try again import my privkeys
if all ok, i will forget for v5
I'm not at all clear what you're trying to do here. Reverting to earlier, unsupported versions of the Slimcoin codebase isn't going to clarify matters, rather the reverse.

very problematic coin   Shocked
It's a very old codebase which is being severely taxed by the consequences of choosing a 90s block time, calculating a UTXO set is requiring more and more computation as the blockchain continues to grow.

Quote
version 5 has subversions
for Graham's instruction here is v5-268
i have v5-232 on windows and seems like my wallet.dat and blockchain are compatible with 232 only
how to compile 232 ?
The instructions are for 0.6.0 (https://github.com/slimcoin-project/Slimcoin/releases/tag/SLMv0.6.0). Any later version of bdb will load a wallet.dat file created with an earlier version but an earlier version of bdb cannot load a wallet created with a later version of bdb. The cross-compiled WIndows binaries used to use the recommended bdb-4.8 but as this just creates yet another factor potentially slowing the wallet's processing, I subsequently enabled the use of whichever version of bdb is provided by MXE. I'm not sure why older Windows versions of the wallet are being referenced, it's not as though they're any more reliable or faster or anything other than potentially problematic.

Only the latest release of Slimcoin is supported --- the current practical meaning of this is: "successfully compiles on Graham's laptop running Mint Ulyana (Ubuntu 0.20), on a VirtualBox VM of Ubuntu 18.04 and cross-compiles to Windows64/32 bit on VirtualBox VM of Ubuntu 18.04 using MXE". Unfortunately, I can no longer successfully cross-compile OS X binaries, so Mac users will have to make do with older (but nevertheless adequately functional) versions of the wallet.

If you're trying to compile code from older releases (which I don't recommend) then you're unlikely to be successful unless you're using a Linux version contemporary with that release.

Quote
i wouldn't ask so many questions if I didn't have so many burnt coins that I don't want to lose
which, apparently, are not supported even in different versions of the 5 release, especially in the 6
You haven't lost any burned coins, it's just that the GUI wallet overview page is erratic in its display of the totals, sometimes showing wildly incorrect values. Again, the likely root cause of this is the  consequence of a slow, elderly codebase (lacking the efficiency gains from the generic optimisations of later improvements to the Bitcoin codebase architecture/implementation), exacerbated by the high processing demand imposed by continuously calculating UTXO sets for a blockchain of 2.2 million blocks and an even larger number of transactions. However, if your experience is anything like mine, you'll find that if you just leave it to crunch its numbers, it'll eventually show you the correct totals - once it's synced, leave it overnight and check in the morning.

It's worth reflecting on the fact that Slimcoin is a clone of Peercoin and the Peercoin blockchain is currently just over 500k blocks.

There is an unfortunate consequence of the design of the Slimcoin burn approach - coins are burned in a transaction and any unspent burn rewards will qualify as staking coins and if allowed to stake, those stake rewards themselves will qualify as staking coins, which if allowed to stake ... and so on, and so on. Setting a reservebalance merely limits the amount of stake processing, it doesn't stop it entirely. The computational demand of stake processing (effectively, continuously calculating the UTXO set) isn't such a significant factor with Peercoin with its shorter blockchain but with Slimcoin the (not entirely unpredictable) computational consequences of a 90s block time on the PoS staking calculations are starting to kick in quite sharply for those with well-funded wallets. It's not even clear whether an update to a later clone of Bitcoin would provide any actual solution - Bitcoin, being pure PoW, has no specific UTXO calculation optimisations that the PoS staking calculations could benefit from.

Cheers

Graham


12  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][FC] Fuguecoin - Fugue256 hash, Launched! NO PRE-M! CPU/GPU minable! on: November 25, 2020, 05:17:16 PM
In support of this small revival in interest, I've reactivated the node on my remote server:

144.76.118.44

And I've also refreshed the codebase: https://github.com/gjhiggins/fuguecoin/releases/tag/v0.8.6, it now compiles out-of-the-box (qmake, make) on Ubuntu Bionic (18.04) and Mint Ulyana (20.04). I also cross-compiled a Windows binary, available from the above URL.

I've extended the GUI a bit with a diff/hashrate plot, a in-wallet block explorer, a Mining tab and a Messaging tab (the latter uses ECIES, courtesy of ghostlander and Orbitcoin):





Also, I've uploaded a blockchain snapshot to Mega.nz: https://mega.nz/file/ecdH3Irb#mzvyuzbWnuqsC0IBsO2b698qoFTyzt41TyH6UVMwou8

Have fun Smiley

Cheers

Graham
13  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Slimcoin | First Proof of Burn currency | Decentralized Web on: November 25, 2020, 04:45:47 PM
If trying command "addnode", I get the answer "Method not found (code -32601)". command "help" does not list a command "addnode".
...
My wallet has no coin control, it's important to me. As I remind, wallet version 0.6.0, that I tried before, had coin control.
That's because Slimcoin 0.5.0 is (via Peercoin) a clone of Bitcoin 0.6.3 beta - yes it really is that old - see the Slimcoin README where it discusses 0.6.3 BETA.

The coincontrol facility and addnode RPC-API command were added much later to Bitcoin. Fortunately I was able to copy the former from a later version of Peercoin and back-port the latter from Bitcoin. That's why they're in Slimcoin v0.6 and not in (the original) Slimcoin v0.5

Cheers

Graham
14  Alternate cryptocurrencies / Announcements (Altcoins) / Re: Slimcoin | First Proof of Burn currency | Decentralized Web on: November 25, 2020, 04:34:22 PM
If you need slimcoin-qt instructions please let me know I'll need some time to gather the instructions together.
yes please
See the section Slimcoin-qt: Qt5 GUI for Slimcoin Build instructions, in the file "readme-qt.rst" in the Slimcoin repos doc directory.

In summary: (for Ubuntu Bionic):
Quote
sudo apt-get install git build-essential qttools5-dev-tools qt5-default libboost-dev libboost-system-dev \
    libboost-filesystem-dev libboost-program-options-dev libboost-thread-dev \
    libssl-dev libdb5.3++-dev libminiupnpc-dev qrencode

git clone https://github.com/slimcoin-project/Slimcoin.git
cd Slimcoin
git checkout master
qmake
make
I've just confirmed (for myself) that the above (verbatim, copy'n'pasta) results in a successful compilation on Ubuntu 18.04.
 
Cheers

Graham
15  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Datacoin - Censorship-Free Data Storage on: November 20, 2020, 03:50:25 PM
This is the second part of the response

What I was trying to do with

Code:
addresstype=legacy

instead, was the opposite thing, i.e. sending a not-segwit tx from 0.16 client.

But your suggestion could work. I don't thing broadcasting segwit-enabled txs to a mixed network will cause a fork across versions.

In fact old clients see segwit txs as normal tx.

So the blockchain should not fork and maybe segwit txs could also be mined from old client.

BTW, it is a dangerous thing to do. We all don't want to risk a fork of Datacoin.
Thank you, the pointer to "old clients see segwit txs as normal tx" was most useful. The key fact is contained in the post following the one you linked to:

Quote
old clients will not receive transactions in the segwit transaction format. Segwit transactions will only be sent in response to a getdata for inv type MSG_WITNESS_TX. However old nodes will not have that inv type in their getdata messages, only MSG_TX, which indicates to segwit capable nodes to send the transaction in the legacy format.

That clears things up a lot and bodes well for the future.

Quote
I already set up a mixed environment  of 0.8 and 0.16 clients, because I had to solve an issue about not confirmed transactions.

The conclusion of this study was that clients version  0.16.3 ban clients 0.8.3 for Misbehaving.

When I sent a tx from my 0.8 client it does not appear in the getrawmempool command of my 0.16 client that is in the same LAN.
I'll have a look at this. I do know (from working on a Gapcoin 0.16.3 reference client) that this isn't the case for a mixed network of 0.9/0.16.3 nodes but I haven't checked with a mixed network of 0.8/0.16 nodes, the situation may differ.

Quote
So I have this situation:

1) If I broadcast a tx from 0.8 client  it is not propagated across 0.16 nodes in the network and so the transaction don't get confirmed for days

2) If I broadcast a tx from 0.16 client the tx is never broadcasted nor confirmed because it causes the error

Code:
CommitTransaction(): Transaction cannot be broadcast immediately, no-witness-yet

and the wallet loses all its datacoins because it never receives from the network the tx of the unspent ones

Long story short, I ended with installing a 0.15 version and I deactivated all my 0.8 an 0.16 clients.
Given that experience, I can understand why. Smiley But there may be some other factor causing the problem - I've just successfully received some DTC from freiexchange with my 0.16.3 client (assuming that freiexchange are using an 0.8 client which may not be the case). After some "fettling", I now have a compiled 0.15.99 Crossverse reference client and am working to get the (rather elderly) 0.8 client to compile on my Mint/Ubuntu 0.20 laptop. Then I can replicate your experiment and maybe have a chance to see where things go astray.

Quote
I also suspect that running different node versions from the same public IP will cause network issues, you could confirm this.
No, that should work without problems, they'd each have a different port/rpcport assignment.

Quote
But from what I understand, the 0.15 version is the unique that can broadcast txs  to both 0.8 and 0.16 nodes (and 0.15, of course).
I don't think that's the case but I will check.

Quote
Each day between 6:00 UTC and 7:00 UTC the blockchain slows down.

You can see this  on the Datacoin block explorer selecting 3710777 as starting block.

This is happening every day.

Any idea?
No at the moment, there's nothing in the code (that I know of) which could cause that. It'll be worth looking at the hash rate and the tx record for that time of day.

Cheers

Graham
16  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Datacoin - Censorship-Free Data Storage on: November 20, 2020, 12:34:33 PM
Thank You for your reply.
...
Now I am facing another issue. Each day between 6:00 UTC and 7:00 UTC the blockchain slows down.

This is part one of a two-part response.

Providing even limited support via bitcointalk is both time-consuming and awkward, so I've set up a Datacoin Discord server for this express purpose, here's the invitation https://discord.gg/evxVsb5FXB. I'm usually online mid-morning to late at night GMT if anyone wants specific help or advice.

fwiw, I'm working on the Datacoin 0.16.3 reference client at the moment so I'm interested in how these issues may be resolved.

Cheers

Graham
17  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Datacoin - Censorship-Free Data Storage on: November 19, 2020, 04:05:43 PM
I think there is an issue with 0.16.3 client.
Just to be clear, you reference the "0.16.3 client". Do you actually mean the 0.16.3 client (the one listed as "datacoin" in the Github list of repos, not the one listed as "datacoin-core") - I ask because as far as I can ascertain, everyone that's using the not-0.8 client is apparently using Verionum/Crossverse's version --- according to my server's response to getpeerinfo | grep subver

Code:
    "subver": "/Datacoin:0.8.6/Datacoin:0.1.2(v0.8.6.0-dirty)/",
    "subver": "/Satoshi:0.8.5/",
    "subver": "/Satoshi:0.8.5/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/Satoshi:0.8.3/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/Satoshi:0.8.3/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",

The Veronium/Crossverse client version string is:
Code:
const std::string CLIENT_NAME("DatacoinCore.Veter");

The 0.16.3 client version string is:
Code:
const std::string CLIENT_NAME("Datoshi");

And the addresstype option was added to upstream Bitcoin after Veronium cloned the codebase (he cloned it when it was 0.15.99, well before the 0.16 version was released). It is present in the 0.16.3 version but as far as I'm aware, no-one's using that implementation.

I'm afraid that one does need to be precise in distinguishing which codebase is giving problems because the solutions will differ.

Cheers

Graham
18  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Datacoin - Censorship-Free Data Storage on: November 19, 2020, 03:37:14 PM
I think there is an issue with 0.16.3 client.

Just to be clear, you reference the "0.16.3 client". As far as I can ascertain, everyone that's using the not-0.8 client is apparently using Verionum/Crossverse's version, according to my server's response to getpeerinfo | grep subver

Code:
    "subver": "/Datacoin:0.8.6/Datacoin:0.1.2(v0.8.6.0-dirty)/",
    "subver": "/Satoshi:0.8.5/",
    "subver": "/Satoshi:0.8.5/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/Satoshi:0.8.3/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
    "subver": "/Satoshi:0.8.3/",
    "subver": "/DatacoinCore.Veter:0.15.99.8/",
19  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][GAP] Gapcoin - Prime Gap Search - New Math Algo - CPU / GPU - Zero Premine on: November 18, 2020, 10:44:36 AM
i am sorry for my young padawan  Grin
you have some snapshot as download available ?

Not as a matter of course atm, tends to be on request. Here's the latest, as of a couple of minutes ago: https://minkiz.co/noodlings/gap/gapchain-snapshot.zip.

Cheers

Graham.

Edit: Well, I don't know how I managed to get the zip file up to 4.2Gb but after reading BitcoinFX’ post below, I remilled it and apparently fixed whatever I'd done - the zip file is down to a more tolerable 642Mb.
20  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Datacoin - Censorship-Free Data Storage on: November 18, 2020, 05:04:06 AM
Code:
CommitTransaction(): Transaction cannot be broadcast immediately, no-witness-yet

Line #468 (AcceptToMemoryPoolWorker) in validation.cpp refers and offers a solution:
Code:
   // Reject transactions with witness before segregated witness activates (override with -prematurewitness)

Which temptingly suggests that if you include prematurewitness=1 in your conf file, or add -prematurewitness to the command line as indicated, senddata txs might well get broadcast. I don't know the effect of broadcasting segwit-enabled txs to a mixed network of 0.16 and 0.8 clients, it's possible that segwit txs will fail to validate on the 0.8 clients causing a fork across versions. You could set up a small local testnet of mixed-version clients and see what happens.

And I think Datacoin blockchain hasn't activated segwit yet.
Indeed it hasn't.

Line #106 of chainparams.cpp refers:
Code:
consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nStartTime = 999999999999ULL; //DATACOIN SEGWIT oтключaeм SEGWIT = 1479168000; // November 15th, 2016.

where "nStartTime = 999999999999ULL" means "sometime in the distant future" (and oтключaeм apparently translates to "turn off")

HTH

Cheers

Graham
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 107 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!