[ANN][ARG] Argentum || Secure. Rare. Fast. || Randomized reward system commodity

[ahmed_bodi]

Update:

In the Argentum Data Dir:

Create a file called "DB_CONFIG"
In this file place the following:

Code:

set_lk_max_locks 537000
set_lk_max_objects  537000

Once saved, Delete and resync the arg blockchain after backup the wallet.dat
You should now be good to go

[1714599444]

1714599444

[1714599444]

1714599444

[1714599444]

1714599444

[1714599444]

1714599444

[baritus]

Update:

In the Argentum Data Dir:

Create a file called "DB_CONFIG"
In this file place the following:

Code:

set_lk_max_locks 537000
set_lk_max_objects  537000

Once saved, Delete and resync the arg blockchain after backup the wallet.dat
You should now be good to go

Thanks for posting back. Looks like it's because 4.8 version libs were used.

[xredirector]

this fixed worked. thank you

arg.coinminerpool.com is on the latest updated blockchain if you are looking to mine the coin

[flound1129]

Update:

In the Argentum Data Dir:

Create a file called "DB_CONFIG"
In this file place the following:

Code:

set_lk_max_locks 537000
set_lk_max_objects  537000

Once saved, Delete and resync the arg blockchain after backup the wallet.dat
You should now be good to go

Thanks for posting back. Looks like it's because 4.8 version libs were used.

Nope, 5.3.

[dimonarka]

ARG is dead?
We invested more 10k$ in ARG!  

[ahmed_bodi]

Update:

In the Argentum Data Dir:

Create a file called "DB_CONFIG"
In this file place the following:

Code:

set_lk_max_locks 537000
set_lk_max_objects  537000

Once saved, Delete and resync the arg blockchain after backup the wallet.dat
You should now be good to go

Thanks for posting back. Looks like it's because 4.8 version libs were used.

Nope, 5.3.

The error is due to berkerly db being used which has a restriction called "locks". The block where clients forked meant that there wernt enough locks for the block to be processed therefore leading to the fork. By switching to leveldb this scenario could be avoided in the future.

PS. for anyone doubting me. Look into the bitcoin fork between v0.7 bdb clients and v0.8 level db clients.

[flound1129]

ARG is dead?
We invested more 10k$ in ARG!  

You chose..  poorly

[flound1129]

Update:

In the Argentum Data Dir:

Create a file called "DB_CONFIG"
In this file place the following:

Code:

set_lk_max_locks 537000
set_lk_max_objects  537000

Once saved, Delete and resync the arg blockchain after backup the wallet.dat
You should now be good to go

Thanks for posting back. Looks like it's because 4.8 version libs were used.

Nope, 5.3.

The error is due to berkerly db being used which has a restriction called "locks". The block where clients forked meant that there wernt enough locks for the block to be processed therefore leading to the fork. By switching to leveldb this scenario could be avoided in the future.

PS. for anyone doubting me. Look into the bitcoin fork between v0.7 bdb clients and v0.8 level db clients.

So to be clear, EVERYONE running an Argentum client is going to experience this issue, unless they explicitly configure the DB_CONFIG parameters that Ahmed was kind enough to post.  This means the wallet will be unusable for anyone who simply downloads the client from the website and has never heard of Bitcointalk.

Baritus, fix this, kill ARG, or hand it over to someone else.

[ahmed_bodi]

Update:

In the Argentum Data Dir:

Create a file called "DB_CONFIG"
In this file place the following:

Code:

set_lk_max_locks 537000
set_lk_max_objects  537000

Once saved, Delete and resync the arg blockchain after backup the wallet.dat
You should now be good to go

Thanks for posting back. Looks like it's because 4.8 version libs were used.

Nope, 5.3.

The error is due to berkerly db being used which has a restriction called "locks". The block where clients forked meant that there wernt enough locks for the block to be processed therefore leading to the fork. By switching to leveldb this scenario could be avoided in the future.

PS. for anyone doubting me. Look into the bitcoin fork between v0.7 bdb clients and v0.8 level db clients.

So to be clear, EVERYONE running an Argentum client is going to experience this issue, unless they explicitly configure the DB_CONFIG parameters that Ahmed was kind enough to post.  This means the wallet will be unusable for anyone who simply downloads the client from the website and has never heard of Bitcointalk.

Baritus, fix this, kill ARG, or hand it over to someone else.

Maybe not at this block but some time in the future surely. 1 Big Block and boom it will stick again. As you said some people may not even be able to sync up.

Ahmed

[baritus]

Update:

In the Argentum Data Dir:

Create a file called "DB_CONFIG"
In this file place the following:

Code:

set_lk_max_locks 537000
set_lk_max_objects  537000

Once saved, Delete and resync the arg blockchain after backup the wallet.dat
You should now be good to go

Thanks for posting back. Looks like it's because 4.8 version libs were used.

Nope, 5.3.

The error is due to berkerly db being used which has a restriction called "locks". The block where clients forked meant that there wernt enough locks for the block to be processed therefore leading to the fork. By switching to leveldb this scenario could be avoided in the future.

PS. for anyone doubting me. Look into the bitcoin fork between v0.7 bdb clients and v0.8 level db clients.

So to be clear, EVERYONE running an Argentum client is going to experience this issue, unless they explicitly configure the DB_CONFIG parameters that Ahmed was kind enough to post.  This means the wallet will be unusable for anyone who simply downloads the client from the website and has never heard of Bitcointalk.

Baritus, fix this, kill ARG, or hand it over to someone else.

I'm already looking for a solution.

[ahmed_bodi]

i handed the solution to you on a golden platter. Upgrade arg to a newer version of the btc/ltc codebase supporting leveldb and then the issue will be fixed

Ahmed

[flound1129]

Since both block explorers are down can ppl please post what block you're at, I want to know if it's safe to reenable this..

[everybodyclapyohands]

Since both block explorers are down can ppl please post what block you're at, I want to know if it's safe to reenable this..

MyWl.lt never had the database problem, but I implemented the fix and re-synchronized the block chain. Here's the current status (01:17 PST):

"blocks" : 433542,
"connections" : 16,
"difficulty" : 0.06581028

[Jacobinge]

This is a reasonable plan, to maximize the convenience
 

[hsz]

well done!

[baritus]

i handed the solution to you on a golden platter. Upgrade arg to a newer version of the btc/ltc codebase supporting leveldb and then the issue will be fixed

Ahmed

ARG's code has many major differences. It would take much longer than I have available to do the port. That's why I am looking for a solution. I contacted Alpha, Argentum's dev, and asked him to take a look.

[xredirector]

Hey guys,

I have the same blockchain that is passed block 426490, but I think whatever coins generated after block 426490 are not accepted by exchanges like cryptsy. They are probably "stuck" on blockchain with block "426490".

The "working" blockchain I could find is here: https://altexplorer.net/chain/Argentum and it is also on a latest block of 426490.

Now, I wounder if blockchain passed 426490 is legit.

There are more peers with this block vs. newer. what do we do?

[my@srv /d2/altcoins]$ argentumd -conf=argentumd.conf getpeerinfo
[
    {
        "addr" : "162.243.226.39",
        "services" : "00000001",
        "lastsend" : 1401150639,
        "lastrecv" : 1401148940,
        "conntime" : 1401102131,
        "version" : 1030000,
        "subver" : "/ARG V1.2:1.0.3/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 426490,
        "banscore" : 0
    },
    {
        "addr" : "46.119.36.123",
        "services" : "00000001",
        "lastsend" : 1401150639,
        "lastrecv" : 1401149327,
        "conntime" : 1401102131,
        "version" : 1030000,
        "subver" : "/ARG V1.2:1.0.3/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 426490,
        "banscore" : 0
    },
    {
        "addr" : "54.201.183.106",
        "services" : "00000001",
        "lastsend" : 1401150639,
        "lastrecv" : 1401149025,
        "conntime" : 1401102131,
        "version" : 1030000,
        "subver" : "/ARG V1.2:1.0.3/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 426490,
        "banscore" : 0
    },
    {
        "addr" : "192.99.44.51",
        "services" : "00000001",
        "lastsend" : 1401150639,
        "lastrecv" : 1401149191,
        "conntime" : 1401102131,
        "version" : 1030000,
        "subver" : "/ARG V1.2:1.0.3/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 426490,
        "banscore" : 0
    },
    {
        "addr" : "72.78.100.9",
        "services" : "00000001",
        "lastsend" : 1401150639,
        "lastrecv" : 1401149548,
        "conntime" : 1401102210,
        "version" : 1030000,
        "subver" : "/ARG V1.2:1.0.3/",
        "inbound" : false,
        "releasetime" : 0,
        "startingheight" : 426490,
        "banscore" : 0
    },
    {
        "addr" : "89.29.69.214:3326",
        "services" : "00000001",
        "lastsend" : 1401150639,
        "lastrecv" : 1401150640,
        "conntime" : 1401110806,
        "version" : 1030000,
        "subver" : "/ARG V1.2:1.0.3/",
        "inbound" : true,
        "releasetime" : 0,
        "startingheight" : 434143,
        "banscore" : 0
    },
    {
        "addr" : "86.30.167.243:36203",
        "services" : "00000001",
        "lastsend" : 1401150639,
        "lastrecv" : 1401150581,
        "conntime" : 1401124171,
        "version" : 1030000,
        "subver" : "/ARG V1.2:1.0.3/",
        "inbound" : true,
        "releasetime" : 0,
        "startingheight" : 426490,
        "banscore" : 0
    },
    {
        "addr" : "192.99.135.85:49393",
        "services" : "00000001",
        "lastsend" : 1401150639,
        "lastrecv" : 1401150639,
        "conntime" : 1401125395,
        "version" : 1030000,
        "subver" : "/ARG V1.2:1.0.3/",
        "inbound" : true,
        "releasetime" : 0,
        "startingheight" : 434569,
        "banscore" : 0
    },
    {
        "addr" : "176.9.63.136:16543",
        "services" : "00000001",
        "lastsend" : 1401150604,
        "lastrecv" : 1401150639,
        "conntime" : 1401126166,
        "version" : 1030000,
        "subver" : "/ARG V1.2:1.0.3/",
        "inbound" : true,
        "releasetime" : 0,
        "startingheight" : 434589,
        "banscore" : 0
    },
    {
        "addr" : "81.99.241.164:34902",
        "services" : "00000001",
        "lastsend" : 1401150639,
        "lastrecv" : 1401145298,
        "conntime" : 1401144684,
        "version" : 1030000,
        "subver" : "/ARG V1.2:1.0.3/",
        "inbound" : true,
        "releasetime" : 0,
        "startingheight" : 426490,
        "banscore" : 0
    }
]
[my@srv /d2/altcoins]$

[my@srv /d2/altcoins]$ argentumd -conf=argentumd.conf getinfo
{
    "version" : 1000300,
    "protocolversion" : 1030000,
    "walletversion" : 60000,
    "blocks" : 435360,
    "connections" : 9,
    "proxy" : "",
    "difficulty" : 0.06793071,
    "testnet" : false,
    "keypoololdest" : 1392347456,
    "keypoolsize" : 103,
    "paytxfee" : 0.00000000,
    "mininput" : 0.00010000,
    "errors" : ""
}
[my@srv /d2/altcoins]$

how do I force my daemon not to drift away from "main" chain that currently stuck on block "426490"?
Am I lost?

[OLX]

what happened to Argentum? difficulty 0.01, pools do not work

[flound1129]

Hey guys,

I have the same blockchain that is passed block 426490, but I think whatever coins generated after block 426490 are not accepted by exchanges like cryptsy. They are probably "stuck" on blockchain with block "426490".

The "working" blockchain I could find is here: https://altexplorer.net/chain/Argentum and it is also on a latest block of 426490.

Now, I wounder if blockchain passed 426490 is legit.

Cryptsy probably hasn't patched their wallet yet, so they can't get the new blocks.  Once they patch they should sync to the current longest chain and the new transactions should come in.

[cryptmebro]

Which block is everybody on?