Main Menu

Test Net for Advanced Users

Started by bytemaster, August 14, 2015, 10:39:33 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

puppies

Quote from: bulletproof on August 28, 2015, 08:56:59 PM
Thanks puppies, will see how far I can get with that & leave 'flood_network' & other network commands until there is one
the vps I'm using for testing graphene is just sitting around right now.  If you need peers to join you let me know. 
[url="https://metaexchange.info"]https://metaexchange.info[/url] | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

clayop

Quote from: bytemaster on August 28, 2015, 09:19:05 PM
The test network has been delayed because we have a random crash in block production that we just now identified the cause of.   

It took me 1M blocks to reproduce the issue on my local test net!

Somewhat disappointed but it's understandable. Can you tell ETA?
Bitshares Korea - [url="http://www.bitshares.kr"]http://www.bitshares.kr[/url]
Vote for me and see Korean Bitshares community grows
delegate-clayop

bytemaster

The test network has been delayed because we have a random crash in block production that we just now identified the cause of.   

It took me 1M blocks to reproduce the issue on my local test net! 
For the latest updates checkout my blog: [url="http://bytemaster.bitshares.org"]http://bytemaster.bitshares.org[/url]
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

bulletproof

Thanks puppies, will see how far I can get with that & leave 'flood_network' & other network commands until there is one
Everything is awesome, or if it isn't it ought to be.

puppies

Quote from: bulletproof on August 28, 2015, 08:16:27 PM
Just to follow up my ask in the Mumble - please consider getting this/a test net up again whilst one for the GUI is being worked on. I have been using it to test the cli_wallet API with the 2.0 version of my bitshares Ruby Gem & can't proceed until it is back up  :-\

Thx & have a good weekend all
is there a reason you need an actual network up?  Couldn't you just run a local instance on and test that way?
[url="https://metaexchange.info"]https://metaexchange.info[/url] | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

bulletproof

Just to follow up my ask in the Mumble - please consider getting this/a test net up again whilst one for the GUI is being worked on. I have been using it to test the cli_wallet API with the 2.0 version of my bitshares Ruby Gem & can't proceed until it is back up  :-\

Thx & have a good weekend all
Everything is awesome, or if it isn't it ought to be.

bytemaster

Quote from: xeroc on August 26, 2015, 02:07:43 PM
Quote from: bytemaster on August 26, 2015, 01:29:18 PM
I just killed the chain.        Will be back with a new test network later this week.
You certainly need to think about your wording .. unless you want people to believe you actually CAN kill the blockchain.

I assume you just switched of your initial witness nodes ..

LOL, yes.   
For the latest updates checkout my blog: [url="http://bytemaster.bitshares.org"]http://bytemaster.bitshares.org[/url]
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

abit

Quote from: bytemaster on August 26, 2015, 01:15:44 PM
Quote from: alt on August 26, 2015, 09:13:00 AM
several times, my witeness node blocked at some block
I watch the p2p log, it received block 419543, then 419544, then missed 419545, then received 419546, .......
and it will never receive block 419545, I have to  restart witness node, then it can request the block from other node.
I think we need a logic, when the witness node have missed a block more than 10 blocks, it should request from other node.

Eric checked in some fixes that may address this particular problem.    We do have logic to request from another node, but the timeouts were still tuned to BTS 1 timeframes so we reduced the timeout for BTS 2.
Can't wait. Where is the new code?
BitShares committee member: abit
BitShares witness: in.abit

bulletproof

#573
Quote from: puppies on August 22, 2015, 10:48:48 PM
Quote from: clout on August 22, 2015, 10:16:12 PM
Get this error:


10 assert_exception: Assert Exception
operations.size() > 0: A transaction must have at least one operation
    {"trx":{"ref_block_num":0,"ref_block_prefix":0,"expiration":"1970-01-01T00:00:00","operations":[],"extensions":[]}}
    th_a  transaction.cpp:51 validate

    {"name_or_id":"the-ae"}
    th_a  wallet.cpp:2762 import_balance


when I try to import balance...
pretty sure that means that key has no balance.

Getting this same error with test1 build while trying to import the 'nathan' account - am I doing something wrong? Witness node is running and currently at #260,000 (not producing blocks). Am I just not synced yet?

unlocked >>> import_balance nathan [5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3] true
import_balance nathan [5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3] true
1417187ms th_a       wallet.cpp:2721               import_balance       ] balances: []
10 assert_exception: Assert Exception
operations.size() > 0: A transaction must have at least one operation
    {"trx":{"ref_block_num":0,"ref_block_prefix":0,"expiration":"1970-01-01T00:00:00","operations":[],"extensions":[]}}
    th_a  transaction.cpp:51 validate

    {"name_or_id":"nathan"}
    th_a  wallet.cpp:2762 import_balance
unlocked >>>


Thx

EDIT: Just seen head block is at 427293 - will wait a while  :)
Everything is awesome, or if it isn't it ought to be.

xeroc

Quote from: bytemaster on August 26, 2015, 01:29:18 PM
I just killed the chain.        Will be back with a new test network later this week.
You certainly need to think about your wording .. unless you want people to believe you actually CAN kill the blockchain.

I assume you just switched of your initial witness nodes ..

bytemaster

I just killed the chain.        Will be back with a new test network later this week.

For the latest updates checkout my blog: [url="http://bytemaster.bitshares.org"]http://bytemaster.bitshares.org[/url]
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

bytemaster

Quote from: alt on August 26, 2015, 09:13:00 AM
several times, my witeness node blocked at some block
I watch the p2p log, it received block 419543, then 419544, then missed 419545, then received 419546, .......
and it will never receive block 419545, I have to  restart witness node, then it can request the block from other node.
I think we need a logic, when the witness node have missed a block more than 10 blocks, it should request from other node.

Eric checked in some fixes that may address this particular problem.    We do have logic to request from another node, but the timeouts were still tuned to BTS 1 timeframes so we reduced the timeout for BTS 2.
For the latest updates checkout my blog: [url="http://bytemaster.bitshares.org"]http://bytemaster.bitshares.org[/url]
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

lafona

Just got my seed node up and running, the address is 73.182.245.244:32015
If you have any issues, let me know, it is on a raspberry pi, so I am not sure how long it will last, but I will be checking up on it regularly.
BTS Witnesses: delegate-1.lafona     Witness Thread: [url="https://bitsharestalk.org/index.php/topic,21569.msg280911/topicseen.html#msg280911"]https://bitsharestalk.org/index.php/topic,21569.msg280911/topicseen.html#msg280911[/url]
MUSE Witness: lafona

alt

several times, my witeness node blocked at some block
I watch the p2p log, it received block 419543, then 419544, then missed 419545, then received 419546, .......
and it will never receive block 419545, I have to  restart witness node, then it can request the block from other node.
I think we need a logic, when the witness node have missed a block more than 10 blocks, it should request from other node.

lafona

Yeah it is still the Aug-20 genesis file and afaik the chain-id is d011922587473757011118587f93afcc314fbaea094fc1055574721b27975083 although I have been having some slight problems getting synced and staying on the chain. It was producing blocks earlier though.
BTS Witnesses: delegate-1.lafona     Witness Thread: [url="https://bitsharestalk.org/index.php/topic,21569.msg280911/topicseen.html#msg280911"]https://bitsharestalk.org/index.php/topic,21569.msg280911/topicseen.html#msg280911[/url]
MUSE Witness: lafona