Quote from: gamey on June 11, 2014, 09:39:53 pm

Slightly off topic but I never understood how it prevents domain squatting.  If there is an auction and only the squatter is there, then they receive the domain, no ?  Are people able to outbid for the domain later on ?

We should say "mitigate" instead of "prevent."

If you try to buy a domain that is clearly worth a lot for cheap, someone will call you on it because they have a profit motive to do so. Of course *someone* will end up with the domain, but they are forced to pay full price and so 1) they are more likely to sell it because of high opportunity cost and 2) they cannot buy thousands of high-value domains.

The end result is that you still have "squatters" except they look more like registrars that resell well-priced domains.

There's also a fee built into the system right?  So someone speculating on a domain name would need to be able to move it quickly.

I also agree that the video should have a little bit more information on domain name squatting.  Perhaps point out the percentage of .bit registered names vs operation websites.

Quote from: puppies on June 10, 2014, 06:14:32 pm

Looks like my delegate node forked last night too.  I was able to get it back to what I believe is the correct chain by clearing the data directory.  Are the logs from my forked delegate worth anything?

Eric is actively working on setting up intentional fork generating tests.  We will be able to handle this better soon.

One odd thing I noticed in the node that forked is that the logs show its own IP address as a peer.  I haven't seen that in any of the logs of my other nodes.  Anyways, I'm off to work.  I'll keep as close of an eye on my nodes as I can.

Is anyone running their delegate on Digital Ocean servers?

I am

wallet (unlocked) >>> enable_raw wallet get_receive_accounts
returns
wallet (unlocked) >>>
With no info. 
To find my delegate numbers I started with
wallet (unlocked) >>> blockchain_get_account_record init-delegate-1
and increased the integer at the end by one.  When you get to an return that does not list
 "next_secret_hash": "0000000000000000000000000000000000000000",
but instead has a hex key inside the final " " you should have the value of your delegate. 

Its possible that I am just stupid, and did not understand the instructions. (the brain power does fade this late at night)

**so.  I have just tested this and have gotten next_secret_hash from keys I probably shouldn't have.  Chances are I am the dumz.  I will retry in the morning with the firepower of this fully ARMED and OPERATIONAL battle station!**

Thanks.  It seemed like my delegates were signing way to many blocks.   Should I just wait for instructions for the new testnet, or would my clearing data directory and attempting to rejoin the main chain do any good?

Sent from my SCH-I535 using Tapatalk

Got the following error:

established outbound connection to 107.170.30.182:8764                      node.cpp:488
Sent "hello" to peer 107.170.30.182:8764                    node.cpp:2042
The hello message I just sent contains connection information: my_ip: XXXXXXXXXXX, my_outbound_port: 5678, my_inbound_port: 5678

Received a rejection from 107.170.30.182:8764 in response to my "hello", reason: "You're on a different chain than I am.  I'm on 3b7df0e87c4f3b1ff36f48f4f374ea6c52355626c31962e50c73552390704e67 and you're on 5b4b4e70614f80b5b88392ff33ebf194e53e4ed9bf2fd43c233c1f7e470a2981"

What can I do about this?

I've updated and rebuilt according to instructions.

I've also tried titan branch:

1618537ms       th_a on_connection_reject ] Received a rejection in response to my "hello"                      node.cpp:1257
1618537ms       th_a            read_loop ] disconnected eof
End of file
    {"message":"End of file"}
    asio  asio.cpp:22 read_write_handler

    {"len":16}
    th_a  stcp_socket.cpp:73 readsome                   message_oriented_connection.cpp:130
1618537ms       th_a on_connection_closed ] Remote peer 107.170.30.182:8764 closed their connection to us                       node.cpp:1608

I am totally confused.  We are going to have to wait for the people that actually understand all this stuff to wake up.  My bitshares_client doesn't throw any errors, and network_get_connection_count shows 1.  Network_get_peer_info shows

[{
    "addr": "107.170.30.182:8764",
    "addrlocal": "107.170.170.214:34021",
    "services": "00000001",
    "lastsend": 1402212502,
    "lastrecv": 1402212502,
    "bytessent": 9520,
    "bytesrecv": 46800,
    "conntime": "",
    "pingtime": "",
    "pingwait": "",
    "version": "",
    "subver": "bts::net::node",
    "inbound": false,
    "firewall_status": "unknown",
    "startingheight": "",
    "banscore": "",
    "syncnode": "",
    "bitshares_git_revision_sha": "34f677e17217a1a1f0eb17f6aaa9296bf259b217 (different from ours)",
    "bitshares_git_revision_unix_timestamp": "20140608T020517",
    "bitshares_git_revision_age": "5 hours ago (older than ours)",
    "fc_git_revision_sha": "ac6505f196c9a360957af2f9fa4814a814261bbf (different from ours)",
    "fc_git_revision_unix_timestamp": "20140608T010812",
    "fc_git_revision_age": "6 hours ago (older than ours)",
    "platform": "linux"
  }

and blockchain_get_config shows

{
  "blockchain_id": "3b7df0e87c4f3b1ff36f48f4f374ea6c52355626c31962e50c73552390704e67",
  "block_interval": 15,
  "max_block_size": 104857,
  "target_block_size": 52428,
  "max_blockchain_size": 107374182400,
  "symbol": "XTS",
  "version": 101,
  "min_block_fee": 1,
  "delegate_num": 97,
  "delegate_reg_fee": 1000000,
  "delegate_reward_min": 10000,
  "name_size_max": 63,
  "data_size_max": 4096,
  "asset_reg_fee": 1000000,
  "asset_shares_max": 1000000000000000
}

I'm not sure I'm connected to the main chain at all anymore.  My delegates are still producing blocks, but I don't know of a real time way of seeing if blocks are being generated by other delegates.  I do show blocks generated by the always present delegate91.

Either way I am going to sleep.

Another test net is up right now - just a test test network, we will do the real dry-run when we have more delegates

puppies, emski, your 10 keys are registered as initial delegates.
sfinder, for some reason Dan didn't see your post. Whoops. You'll get into the real dry run with everyone else.

puppies and emski should:

1) Pull latest (+ git submodule update) and build
2) Wipe data dir
3) "wallet_create" / "wallet_unlock 9999999"
4) "wallet_import_private_key <WIF_PRIVATE_KEY>" on each key (other readers: you must "wallet_account_create" first if you are not hard-coded delegate)
5) "rescan"

Leave it running for a while (50 minutes worst case)

6) "blockchain_get_delegates"  -> see the names of all your delegats
7) "blockchain_get_account_record <delegate_name>"

"blocks_produced" should be more than 0.
"blocks_missed" will be big but should stop increasing after you import your keys

Thanks Toast.

Up, running, and producing blocks.

this would be a good airdrop candidate if nothing else.