Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Troglodactyl

Pages: 1 ... 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 ... 64
166
General Discussion / Re: Test Net for Advanced Users
« on: August 21, 2015, 02:52:06 am »
And it keeps happening over and over again on that node.  Meanwhile my vps is chugging along.  Is there a way to turn on more logging options.  All I currently see is the p2p.log

Lots and lots of this from my most recent
...

Look in the config file, you should see:
Code: [Select]
# declare an appender named "stderr" that writes messages to the console
[log.console_appender.stderr]
stream=std_error

# declare an appender named "p2p" that writes messages to p2p.log
[log.file_appender.p2p]
filename=logs/p2p/p2p.log
# filename can be absolute or relative to this config file

# route any messages logged to the default logger to the "stderr" logger we
# declared above, if they are info level are higher
[logger.default]
level=info
appenders=stderr

# route messages sent to the "p2p" logger to the p2p appender declared above
[logger.p2p]
level=debug
appenders=p2p

At the end.  Try changing that to:

Code: [Select]
# declare an appender named "stderr" that writes messages to the console
[log.file_appender.stderr]
filename=logs/stderr/stderr.log

# declare an appender named "p2p" that writes messages to p2p.log
[log.file_appender.p2p]
filename=logs/p2p/p2p.log
# filename can be absolute or relative to this config file

# route any messages logged to the default logger to the "stderr" logger we
# declared above, if they are info level are higher
[logger.default]
level=info
appenders=stderr

# route messages sent to the "p2p" logger to the p2p appender declared above
[logger.p2p]
level=debug
appenders=p2p

But watch it, I haven't tried it and it's likely very verbose.  Keep an eye on how much space it's eating before you leave it running.

167
General Discussion / Re: Test Net for Advanced Users
« on: August 21, 2015, 02:34:35 am »
Code: [Select]
get_block 27868
{
  "previous": "00006cdb2f8937565fe6b272e3b43073be37a0de",
  "timestamp": "2015-08-21T01:57:24",
  "witness": "1.6.78",
  "next_secret_hash": "202f2a4a975f81e64b6caa1d46f9423ca1cbdde4",
  "previous_secret": "93d75a091fe435d5e92e66c29f2c55ae9449ea56",
  "transaction_merkle_root": "0000000000000000000000000000000000000000",
  "extensions": [],
  "witness_signature": "1f1b27b0e3b05b097eb773e11306513f46b90ca1f2f5c394a54836533d988887471813ddf0c4526687b13d2edbb43b2e2389b75245e4c48d4e3ab78f9015a1287a",
  "transactions": []
}

Getting the next block confirms that it's "previous block" id matches the one your node rejected, so now we just have to figure out why your node rejected that block.

168
General Discussion / Re: Test Net for Advanced Users
« on: August 21, 2015, 02:31:07 am »
My home node keeps losing sync. 
Code: [Select]
2015-08-21T01:57:22 p2p:message read_loop process_block_during ] Successfully pushed block 27866 (id:00006cda44c0d8b2e2566d15dfe7a2610430a774) node.cpp:3109
2015-08-21T01:57:22 p2p:message read_loop process_block_during ] client validated the block, advertising it to other peers node.cpp:3133
2015-08-21T01:57:22 p2p:message read_loop  clear_old_inventory ] Expiring old inventory for peer 176.221.43.130:33323: removing 1 items advertised to peer (114 left), and 0 advertised to us (0 left) peer_connection.cpp:479
2015-08-21T01:57:22 p2p:message read_loop  clear_old_inventory ] Expiring old inventory for peer 45.55.6.216:1776: removing 0 items advertised to peer (0 left), and 0 advertised to us (115 left) peer_connection.cpp:479
2015-08-21T01:57:22 p2p:advertise_inventory_loop advertise_inventory_ ] beginning an iteration of advertise inventory node.cpp:1175
2015-08-21T01:57:22 p2p:advertise_inventory_loop advertise_inventory_ ] peer->peer_needs_sync_items_from_us: false node.cpp:1188
2015-08-21T01:57:22 p2p:advertise_inventory_loop advertise_inventory_ ] inventory_to_advertise: [{"item_type":1001,"item_hash":"0a1c44a16235a09d4c84668842c85471b45e40e0"}] node.cpp:1196
2015-08-21T01:57:22 p2p:advertise_inventory_loop advertise_inventory_ ] *peer->inventory_advertised_to_peer.find(item_to_advertise): {"item":{"item_type":3624437200,"item_hash":"ff7f00002b00000000000000ffffffffff7f0000"},"timestamp":"2023-11-27T10:29:02"} node.cpp:1200
2015-08-21T01:57:22 p2p:advertise_inventory_loop advertise_inventory_ ] *peer->inventory_peer_advertised_to_us.find(item_to_advertise): {"item":{"item_type":3624438048,"item_hash":"ff7f00000000000000000000c8b007d8ff7f0000"},"timestamp":"1948-10-02T17:47:20"} node.cpp:1202
2015-08-21T01:57:22 p2p:advertise_inventory_loop advertise_inventory_ ] advertising item 0a1c44a16235a09d4c84668842c85471b45e40e0 to peer 176.221.43.130:33323 node.cpp:1212
2015-08-21T01:57:22 p2p:advertise_inventory_loop advertise_inventory_ ] advertising 1 new item(s) of 1 type(s) to peer 176.221.43.130:33323 node.cpp:1218
2015-08-21T01:57:22 p2p:advertise_inventory_loop  clear_old_inventory ] Expiring old inventory for peer 176.221.43.130:33323: removing 0 items advertised to peer (115 left), and 0 advertised to us (0 left) peer_connection.cpp:479
2015-08-21T01:57:22 p2p:advertise_inventory_loop advertise_inventory_ ] peer->peer_needs_sync_items_from_us: false node.cpp:1188
2015-08-21T01:57:22 p2p:advertise_inventory_loop advertise_inventory_ ] inventory_to_advertise: [{"item_type":1001,"item_hash":"0a1c44a16235a09d4c84668842c85471b45e40e0"}] node.cpp:1196
2015-08-21T01:57:22 p2p:advertise_inventory_loop advertise_inventory_ ] *peer->inventory_advertised_to_peer.find(item_to_advertise): {"item":{"item_type":3623881952,"item_hash":"ff7f0000000000000000000068a305d8ff7f0000"},"timestamp":"1948-09-25T19:23:04"} node.cpp:1200
2015-08-21T01:57:22 p2p:advertise_inventory_loop advertise_inventory_ ] advertising 0 new item(s) of 0 type(s) to peer 45.55.6.216:1776 node.cpp:1218
2015-08-21T01:57:22 p2p:advertise_inventory_loop  clear_old_inventory ] Expiring old inventory for peer 45.55.6.216:1776: removing 0 items advertised to peer (0 left), and 0 advertised to us (115 left) peer_connection.cpp:479
2015-08-21T01:57:22 p2p:advertise_inventory_loop         send_message ] peer_connection::send_message() enqueueing message of type 5001 for peer 176.221.43.130:33323 peer_connection.cpp:365
2015-08-21T01:57:22 p2p:advertise_inventory_loop send_queueable_messa ] peer_connection::send_message() is firing up send_queued_message_task peer_connection.cpp:354
2015-08-21T01:57:22  p2p:fetch_items_loop     fetch_items_loop ] beginning an iteration of fetch items (0 items to fetch) node.cpp:1104
2015-08-21T01:57:22 p2p:send_queued_messages_task              counter ] entering peer_connection::send_queued_messages_task() peer_connection.cpp:279
2015-08-21T01:57:22 p2p:send_queued_messages_task send_queued_messages ] peer_connection::send_queued_messages_task() calling message_oriented_connection::send_message() to send message of type 5001 for peer 176.221.43.130:33323 peer_connection.cpp:291
2015-08-21T01:57:22 p2p:send_queued_messages_task send_queued_messages ] peer_connection::send_queued_messages_task()'s call to message_oriented_connection::send_message() completed normally for peer 176.221.43.130:33323 peer_connection.cpp:294
2015-08-21T01:57:22 p2p:send_queued_messages_task send_queued_messages ] leaving peer_connection::send_queued_messages_task() due to queue exhaustion peer_connection.cpp:326
2015-08-21T01:57:22 p2p:send_queued_messages_task             ~counter ] leaving peer_connection::send_queued_messages_task() peer_connection.cpp:280
2015-08-21T01:57:22   p2p:connect_to_task           connect_to ] established outbound connection to 114.92.254.159:62015 peer_connection.cpp:251
2015-08-21T01:57:22   p2p:connect_to_task         send_message ] peer_connection::send_message() enqueueing message of type 5006 for peer 114.92.254.159:62015 peer_connection.cpp:365
2015-08-21T01:57:22   p2p:connect_to_task send_queueable_messa ] peer_connection::send_message() is firing up send_queued_message_task peer_connection.cpp:354
2015-08-21T01:57:22   p2p:connect_to_task      connect_to_task ] Sent "hello" to peer 114.92.254.159:62015 node.cpp:4093
2015-08-21T01:57:22 p2p:send_queued_messages_task              counter ] entering peer_connection::send_queued_messages_task() peer_connection.cpp:279
2015-08-21T01:57:22 p2p:send_queued_messages_task send_queued_messages ] peer_connection::send_queued_messages_task() calling message_oriented_connection::send_message() to send message of type 5006 for peer 114.92.254.159:62015 peer_connection.cpp:291
2015-08-21T01:57:22 p2p:send_queued_messages_task send_queued_messages ] peer_connection::send_queued_messages_task()'s call to message_oriented_connection::send_message() completed normally for peer 114.92.254.159:62015 peer_connection.cpp:294
2015-08-21T01:57:22 p2p:send_queued_messages_task send_queued_messages ] leaving peer_connection::send_queued_messages_task() due to queue exhaustion peer_connection.cpp:326
2015-08-21T01:57:22 p2p:send_queued_messages_task             ~counter ] leaving peer_connection::send_queued_messages_task() peer_connection.cpp:280
2015-08-21T01:57:23 p2p:message read_loop           on_message ] handling message hello_message_type 1ee7de2b2696aece8234a8c1198d21bbee1d4e29 size 528 from peer 114.92.254.159:62015 node.cpp:1651
2015-08-21T01:57:23 p2p:message read_loop         send_message ] peer_connection::send_message() enqueueing message of type 5007 for peer 114.92.254.159:62015 peer_connection.cpp:365
2015-08-21T01:57:23 p2p:message read_loop send_queueable_messa ] peer_connection::send_message() is firing up send_queued_message_task peer_connection.cpp:354
2015-08-21T01:57:23 p2p:message read_loop     on_hello_message ] Received a hello_message from peer 114.92.254.159:62015, sending reply to accept connection node.cpp:1967
2015-08-21T01:57:23 p2p:send_queued_messages_task              counter ] entering peer_connection::send_queued_messages_task() peer_connection.cpp:279
2015-08-21T01:57:23 p2p:send_queued_messages_task send_queued_messages ] peer_connection::send_queued_messages_task() calling message_oriented_connection::send_message() to send message of type 5007 for peer 114.92.254.159:62015 peer_connection.cpp:291
2015-08-21T01:57:23 p2p:send_queued_messages_task send_queued_messages ] peer_connection::send_queued_messages_task()'s call to message_oriented_connection::send_message() completed normally for peer 114.92.254.159:62015 peer_connection.cpp:294
2015-08-21T01:57:23 p2p:send_queued_messages_task send_queued_messages ] leaving peer_connection::send_queued_messages_task() due to queue exhaustion peer_connection.cpp:326
2015-08-21T01:57:23 p2p:send_queued_messages_task             ~counter ] leaving peer_connection::send_queued_messages_task() peer_connection.cpp:280
2015-08-21T01:57:23 p2p:message read_loop           on_message ] handling message item_ids_inventory_message_type 161f660391f8a231b70a77010704f124db1196af size 25 from peer 45.55.6.216:1776 node.cpp:1651
2015-08-21T01:57:23 p2p:message read_loop  clear_old_inventory ] Expiring old inventory for peer 45.55.6.216:1776: removing 0 items advertised to peer (0 left), and 1 advertised to us (114 left) peer_connection.cpp:479
2015-08-21T01:57:23 p2p:message read_loop on_item_ids_inventor ] received inventory of 1 items from peer 45.55.6.216:1776 node.cpp:2613
2015-08-21T01:57:23 p2p:message read_loop on_item_ids_inventor ] adding item 07eb3cbe0052b4a4ee0ed8dec43655b6965f0b1d from inventory message to our list of items to fetch node.cpp:2647
2015-08-21T01:57:23  p2p:fetch_items_loop     fetch_items_loop ] beginning an iteration of fetch items (1 items to fetch) node.cpp:1104
2015-08-21T01:57:23  p2p:fetch_items_loop     fetch_items_loop ] requesting item 07eb3cbe0052b4a4ee0ed8dec43655b6965f0b1d from peer 45.55.6.216:1776 node.cpp:1123
2015-08-21T01:57:23  p2p:fetch_items_loop         send_message ] peer_connection::send_message() enqueueing message of type 5004 for peer 45.55.6.216:1776 peer_connection.cpp:365
2015-08-21T01:57:23  p2p:fetch_items_loop send_queueable_messa ] peer_connection::send_message() is firing up send_queued_message_task peer_connection.cpp:354
2015-08-21T01:57:23 p2p:send_queued_messages_task              counter ] entering peer_connection::send_queued_messages_task() peer_connection.cpp:279
2015-08-21T01:57:23 p2p:send_queued_messages_task send_queued_messages ] peer_connection::send_queued_messages_task() calling message_oriented_connection::send_message() to send message of type 5004 for peer 45.55.6.216:1776 peer_connection.cpp:291
2015-08-21T01:57:23 p2p:send_queued_messages_task send_queued_messages ] peer_connection::send_queued_messages_task()'s call to message_oriented_connection::send_message() completed normally for peer 45.55.6.216:1776 peer_connection.cpp:294
2015-08-21T01:57:23 p2p:send_queued_messages_task send_queued_messages ] leaving peer_connection::send_queued_messages_task() due to queue exhaustion peer_connection.cpp:326
2015-08-21T01:57:23 p2p:send_queued_messages_task             ~counter ] leaving peer_connection::send_queued_messages_task() peer_connection.cpp:280
2015-08-21T01:57:23 p2p:message read_loop           on_message ] handling message block_message_type 07eb3cbe0052b4a4ee0ed8dec43655b6965f0b1d size 172 from peer 45.55.6.216:1776 node.cpp:1651
2015-08-21T01:57:23 p2p:message read_loop process_block_during ] received a block from peer 45.55.6.216:1776, passing it to client node.cpp:3087
2015-08-21T01:57:23 p2p:message read_loop process_block_during ] Failed to push block 27867 (id:00006cdb2f8937565fe6b272e3b43073be37a0de), client rejected block sent by peer node.cpp:3198
Code: [Select]
1671470ms th_a       application.cpp:348           handle_block         ] Got block #29623 from network
1672475ms th_a       application.cpp:348           handle_block         ] Got block #29624 from network
1675558ms th_a       application.cpp:348           handle_block         ] Got block #29627 from network
1675558ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link.
1675722ms th_a       application.cpp:348           handle_block         ] Got block #29626 from network
1675722ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link.
1676472ms th_a       application.cpp:348           handle_block         ] Got block #29628 from network
1676472ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link.
1677471ms th_a       application.cpp:348           handle_block         ] Got block #29629 from network
1677471ms th_a       fork_database.cpp:57          push_block           ] Pushing block to fork database that failed to link.
1678473ms th_a       application.cpp:348           handle_block         ] Got block #29630 from network

Code: [Select]
get_block 27867
{
  "previous": "00006cda44c0d8b2e2566d15dfe7a2610430a774",
  "timestamp": "2015-08-21T01:57:23",
  "witness": "1.6.71",
  "next_secret_hash": "74adc395b0e7aff2e854300a0d0e913fc83da333",
  "previous_secret": "2c2d4cb66202a45f75a7fd8876f4886694ee7bf5",
  "transaction_merkle_root": "0000000000000000000000000000000000000000",
  "extensions": [],
  "witness_signature": "1f14fa5a625f2e7f21a2fb80dff311f2da97da5834f7f21718dde7d904c848043e04fa596927d006090356854d0d19bd0e741b0f186c8c54f0070eddd2635e5608",
  "transactions": []
}

There's what I have for that block.

Code: [Select]
new >>> get_dynamic_global_properties
get_dynamic_global_properties
{
  "id": "2.1.0",
  "random": "b8c6bfb33a7c6806f4d1d02784f8020891935417",
  "head_block_number": 29773,
  "head_block_id": "0000744d5eb7d745a0de9541172ce4898de459c9",
  "time": "2015-08-21T02:30:29",
  "current_witness": "1.6.6",
  "next_maintenance_time": "2015-08-21T02:35:00",
  "witness_budget": 96821279,
  "accounts_registered_this_interval": 0,
  "recently_missed_count": 0,
  "dynamic_flags": 0
}

And my current blockchain state.

169
General Discussion / Re: Test Net for Advanced Users
« on: August 21, 2015, 12:33:59 am »
Code: [Select]
new >>> get_dynamic_global_properties
get_dynamic_global_properties
{
  "id": "2.1.0",
  "random": "42f2b51fa6a239642d8394d1806f9f8036b55f4b",
  "head_block_number": 22475,
  "head_block_id": "000057cbdb4a4e158cb39094bc7c078c86680be6",
  "time": "2015-08-21T00:23:49",
  "current_witness": "1.6.1",
  "next_maintenance_time": "2015-08-21T00:25:00",
  "witness_budget": 0,
  "accounts_registered_this_interval": 0,
  "recently_missed_count": 2,
  "dynamic_flags": 0
}

Try connecting to 176.221.43.130:33323, that's where all the blocks I get seem to be coming from, so I'm guessing that's my peer with lowest latency to the rest of the network.

170
General Discussion / Re: Test Net for Advanced Users
« on: August 21, 2015, 12:19:05 am »
Code: [Select]
info
{
  "head_block_num": 21949,
  "head_block_id": "000055bd60276952c37246d38eee3cf9780c71d6",
  "head_block_age": "0 second old",
  "next_maintenance_time": "18 seconds in the future",
  "chain_id": "d011922587473757011118587f93afcc314fbaea094fc1055574721b27975083",
  "active_witnesses": [
    "1.6.0",
    "1.6.1",
    "1.6.2",
    "1.6.3",
    "1.6.4",
    "1.6.5",
    "1.6.6",
    "1.6.7",
    "1.6.8",
    "1.6.9",
    "1.6.10",
    "1.6.11",
    "1.6.12",
    "1.6.13",
    "1.6.14",
    "1.6.15",
    "1.6.16",
    "1.6.17",
    "1.6.18",
    "1.6.19",
    "1.6.20",
    "1.6.21",
    "1.6.22",
    "1.6.23",
    "1.6.24",
    "1.6.25",
    "1.6.26",
    "1.6.27",
    "1.6.28",
    "1.6.29",
    "1.6.30",
    "1.6.31",
    "1.6.32",
    "1.6.33",
    "1.6.34",
    "1.6.35",
    "1.6.36",
    "1.6.37",
    "1.6.38",
    "1.6.39",
    "1.6.40",
    "1.6.41",
    "1.6.42",
    "1.6.43",
    "1.6.44",
    "1.6.45",
    "1.6.46",
    "1.6.47",
    "1.6.48",
    "1.6.49",
    "1.6.50",
    "1.6.51",
    "1.6.52",
    "1.6.53",
    "1.6.54",
    "1.6.55",
    "1.6.56",
    "1.6.57",
    "1.6.58",
    "1.6.59",
    "1.6.60",
    "1.6.61",
    "1.6.62",
    "1.6.63",
    "1.6.64",
    "1.6.65",
    "1.6.66",
    "1.6.67",
    "1.6.68",
    "1.6.69",
    "1.6.70",
    "1.6.71",
    "1.6.72",
    "1.6.73",
    "1.6.74",
    "1.6.75",
    "1.6.76",
    "1.6.77",
    "1.6.78",
    "1.6.79",
    "1.6.80",
    "1.6.81",
    "1.6.82",
    "1.6.83",
    "1.6.84",
    "1.6.85",
    "1.6.86",
    "1.6.87",
    "1.6.88",
    "1.6.89",
    "1.6.90",
    "1.6.91",
    "1.6.92",
    "1.6.93",
    "1.6.94",
    "1.6.95",
    "1.6.96",
    "1.6.1537",
    "1.6.5246",
    "1.6.5247",
    "1.6.5248"
  ],
  "active_committee_members": [
    "1.5.0",
    "1.5.1",
    "1.5.2",
    "1.5.3",
    "1.5.4",
    "1.5.5",
    "1.5.6",
    "1.5.7",
    "1.5.8",
    "1.5.9",
    "1.5.10"
  ],
  "entropy": "a04cd87714d3013b2ed9b14599ae2b2ad7b7e8e1"
}

I'm seeing a few brief pauses occasionally that are most likely missed blocks, but no sign of a serious failure yet.  I'll dig into the logs and see what I can find.  Is there a command I'm missing to get delegate participation, or recent missed blocks, or list forks?

171
General Discussion / Re: Test Net for Advanced Users
« on: August 20, 2015, 11:45:36 pm »
I'm not running a witness, but at first glance the network appears to be chugging along normally.

172
Technical Support / Re: Smart contracts side chain
« on: August 19, 2015, 10:36:03 pm »
If smart contracts are integrated into the block validation process, then they absolutely do impact performance.  It's possible we'll have enough spare resources to run them anyway, but once we start pushing the limits they will drive up transaction costs relative to what they'd be if smart contracts were handled otherwise.

I think smart contracts could be handled more efficiently outside chain validation by multisig.  You could create a smart contract with a distributed set of executors in a multisig account, and they all have to agree on how each action of the contract is executed.  The executors could be the dynamic set of witnesses if there's really that much demand for that.  Decoupling smart contracts from chain validation this way gives both the potential of higher performance, and provides greater flexibility to the smart contract security model.  Some people may be willing to pay for more redundancy/decentralization in their smart contract execution than others have any need for, and this model allows that.

 +5%  Excellent. Much better way of decoupling than a full side chain (it removes the complexity, but it achieves similar result). How do you envision the interaction between contracts and block chain, event triggering, etc?

Since the executors would be defined through a multisig account, events could be triggered by anything upon which that group could be expected to reach consensus.  Obviously that includes any blockchain condition being met, but it's a lot more flexible than that.  When each executor detects a triggering condition being met, he either creates the appropriate multisig transaction or adds his signature if another executor has already created it on the blockchain.

Quote
...
This could work well in many instances I agree.... there are some instances however where if the smart-contract requires an audit of conditions that it would need to exist entirely within the blockchain.. in which case a sidechain might be appropriate.

However for most instances an external app interfacing with the bitshares network to execute on certain conditions might be just fine.

Man.. thinking about all the development possibilities just leaves me amazed!

Can you give an example of why a contract would have to exist within the blockchain?

173
Technical Support / Re: Smart contracts side chain
« on: August 19, 2015, 12:45:12 pm »
If smart contracts are integrated into the block validation process, then they absolutely do impact performance.  It's possible we'll have enough spare resources to run them anyway, but once we start pushing the limits they will drive up transaction costs relative to what they'd be if smart contracts were handled otherwise.

I think smart contracts could be handled more efficiently outside chain validation by multisig.  You could create a smart contract with a distributed set of executors in a multisig account, and they all have to agree on how each action of the contract is executed.  The executors could be the dynamic set of witnesses if there's really that much demand for that.  Decoupling smart contracts from chain validation this way gives both the potential of higher performance, and provides greater flexibility to the smart contract security model.  Some people may be willing to pay for more redundancy/decentralization in their smart contract execution than others have any need for, and this model allows that.

174
I don't think this is a problem that needs to be solved.  Prediction markets can have many use cases including as a crowd funding system, but that doesn't mean we need a system for censoring them.

175
As a neutral platform, BitShares will enable people to network and collaborate with others more effectively.  I don't think there's a need to cripple it just because some people may use it for things of which we disapprove in the future.

Keep in mind that even the most dreaded "assassination market" application of prediction markets is just as much an opportunity to crowd fund the defense of the person as it is an opportunity to crowd fund the assassination.  At its core, this is a fundamental question about the aggregate nature of humanity.  If you think new technologies that increase human productivity are a net negative because they enable people to produce more misery and suffering, this may not be the community for you.  If you think that technology and increased productivity is generally an improvement and leaves people better off, then check your paranoia and have some appreciation for what this community is building for human empowerment.

176
General Discussion / Re: Potential flaw in referral fee system
« on: August 11, 2015, 12:54:51 pm »
Ultimately there's no "forcing" people to create new accounts.  If a business tries to do that, they'll either lose customers who think it's irritating, or they'll successfully convince people to create new accounts, and their previous referrers will lose some potential income.  I don't see either of these options causing major problems, but I think the former is more likely.  I know personally I'd be irritated about a company trying to get me to create more redundant accounts.  BitShares login has great value as a unified account system, and I don't think people will want to give that up.

177
General Discussion / Re: Economic Arguments against POS/DPOS
« on: August 06, 2015, 09:28:42 pm »
The byline: 'So-called “alternatives” to Proof-of-Work “waste” just as much “work”.'

Part of his criticism of DPOS is voting in general. He also says the amount of resources "wasted" to political campaigning (among other voting inefficiencies) will equal the resources wasted to mining. Even if it was true, wouldn't such campaigns be more beneficial/productive for their blockchains than mining? He compares it to the "democracies" of today and assumes anyone can get voted in based on how much they spend. I don't think it's a fair comparison.

Parts of his criticism are parenthetical:
"Is vote-buying a bad thing? Who really knows (considering the long-run coordination problems facing this species…)? For today’s post, who cares?"

The article is long-winded and I admittedly skimmed a lot.

Also, I don't believe he addressed the centralization of POW, which would make the rest moot.

"Rational ignorance occurs when the cost of educating oneself on an issue exceeds the potential benefit that the knowledge would provide."

This thread is a highly interesting convo that will take me more time to fully digest in order to offer substantive comments on the merits. However, I do feel compelled to comment, more from an abstract philosophical perspective on the basis of voting vs. mining.

It was easy for me to see the benefits of DPoS over PoS based solely on a DAC / balance sheet perspective. My view in that regard has not changed. However, I now have doubts concerning the political influences of both systems which I cannot easily evaluate as to which influences the free market nature of a crypto-currency the least.

There is no disputing that both systems are influenced by politics. PoW by the ever increasing costs of the mechanics of mining drive increasing centralization to save costs, which increase the chances that mining will be influenced more and more by those wealthy enough to buy a bigger share of mining hardware or control over it. Even the cost of power generation is an influential factor.

I don't see any magic bullet to eliminate similar issues in DPoS either. Look at the power of so called "whales" in our ecosystem over who gets elected to produce blocks. It's not currently decentralized and whether it will become sufficiently decentralized such that healthy competition can emerge and the free market qualities of the ecosystem can be maintained remains to be seen. Then there is the issue of voter apathy, and how that tends to put more influence in the hands of "whales who care" to vote.

I'm not convinced it's fair to extrapolate our current experience with DPoS with what it will look like with orders of magnitude greater adoption we all hope will happen. Who knew that mining would lead to centralization? How can we rely on "game theory" and presume to know how people will be swayed to elect (or not elect through apathy or personal preferences) quality "overseers" in the form of workers and delegates? I left out witnesses b/c they are more or less a binary check & balance mechanism, tho if push came to shove and a code controversy splits witnesses into factions that support various versions they too will be influenced by politics.

My doubts about any crypto-currency will always be focused on the philosophical basis and people politics involved. I can't imagine how that perspective could be changed.

I think a key advantage here is that DPoS is a consensus bootstrapping system that allows people to organize based on a shared value system.  Any DPoS network can be forked if it no longer reflects the value system of some of its users, and a new networks rules and distribution system can be altered to reflect the moral ideas of its users.  Networks will grow as more people identify with the networks distribution and rules, and find their functionality useful.  DPoS networks are ruled by the dynamic community of token holders, but PoW networks are less flexible, since all of them are ultimately controlled by the dominant holders of hardware for the given hashing algorithm.  PoW networks are still dependent on community acceptance for value, so nothing is really lost here.

178
General Discussion / Re: Economic Arguments against POS/DPOS
« on: August 06, 2015, 05:21:00 am »
This article abstracts most of the relevant issues into "externalities" and then ignores them.

179
General Discussion / Re: Lets here who the bank is already
« on: July 29, 2015, 01:21:08 pm »
just another hotair from dev.dont take it seriously.

Deals like that are often started in an NDA and nothing is said till the ink is dry and thing are 'official'.

I think there's validity in both of these.  BM is much better at research and development and inspirational vision than he is at public relations and leadership.  I think most of us here have enough firsthand knowledge to be pretty optimistic about BitShares, but I'd be careful how much weight you give to BM's expectations.  Conveniently we're quickly building to the point where such leadership will be less necessary.

180
Muse/SoundDAC / Re: Bitshares music blockchain
« on: July 25, 2015, 04:46:41 pm »
I'm still curious what other projects people think  that could be built on top of the MUSE blockchain. Beyond PeerTracks what do you guys envision coming from this new blockchain? I'm seeing a lot of great ideas tossed around for what Peertracks could accomplish but I'm wondering what people see this turning into if this project is as successful as it could potentially be.

At this point no one but PeerTracks knows enough about the MUSE chain to start basing any sort of business on it.

Pages: 1 ... 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 ... 64