vikram help!

(wallet closed) >>>
Program received signal SIGSEGV, Segmentation fault.
fc::exception::code (this=0x0) at /root/bitsharesx/libraries/fc/src/exception.cpp:105
105        int64_t      exception::code()const throw() { return my->_code;         }
(gdb) bt
#0  fc::exception::code (this=0x0) at /root/bitsharesx/libraries/fc/src/exception.cpp:105
#1  0x0000000000847419 in operator() (e=..., __closure=0x4c6d268) at /root/bitsharesx/libraries/client/client.cpp:2766
#2  fc::detail::completion_handler_impl<bts::client::client::start_networking(std::function<void()>)::__lambda13, void>::on_complete(const void *, const fc::exception_ptr &) (this=0x4c6d260, v=<optimized out>, e=...) at /root/bitsharesx/libraries/fc/include/fc/thread/future.hpp:54
#3  0x00000000008e0516 in fc::promise_base::_set_value (this=0x4c6d9d8, s=s@entry=0x0) at /root/bitsharesx/libraries/fc/src/thread/future.cpp:122
#4  0x0000000000ccfc69 in set_value (this=0x4c6d940) at /root/bitsharesx/libraries/fc/include/fc/thread/future.hpp:158
#5  fc::detail::void_functor_run<bts::net::chain_downloader::get_all_blocks(std::function<void(const bts::blockchain::full_block&, unsigned int)>, uint32_t)::__lambda1>::run(void *, void *) (functor=0x4c6d948, prom=0x4c6d940) at /root/bitsharesx/libraries/fc/include/fc/thread/task.hpp:84
#6  0x00000000008e0fd3 in fc::task_base::run_impl (this=this@entry=0x4c6d978) at /root/bitsharesx/libraries/fc/src/thread/task.cpp:43
#7  0x00000000008e1685 in fc::task_base::run (this=this@entry=0x4c6d978) at /root/bitsharesx/libraries/fc/src/thread/task.cpp:32
#8  0x00000000008df52e in run_next_task (this=0x1a0de10) at /root/bitsharesx/libraries/fc/src/thread/thread_d.hpp:498
#9  fc::thread_d::process_tasks (this=this@entry=0x1a0de10) at /root/bitsharesx/libraries/fc/src/thread/thread_d.hpp:547
#10 0x00000000008df7b6 in fc::thread_d::start_process_tasks (my=27319824) at /root/bitsharesx/libraries/fc/src/thread/thread_d.hpp:475
#11 0x000000000120127e in make_fcontext ()
#12 0x0000000001a0de10 in ?? ()
#13 0x0000000004c8cf00 in ?? ()
#14 0x0000000000000000 in ?? ()

Prior to the allocation proposal BM and I had a discussion about relative valuations and despite agreeing about our personal valuations of the different networks (which was still higher than what DNS is worth now IIRC) we obviously did not properly discuss how the execution of this merger would actually play out. A better approach would have accounted for claimed vs unclaimed stake and would have coordinated snapshots with announcements. That is behind us though.

Despite the recent loss of value of DNS, I think it is ultimately in the best interest of DNS holders to accept the merger and end the current network sometime soon.

* BTS+BitUSD is where the money is. The marginal benefit of each extra % likelihood that it takes off is huge compared to what DNS could return in the medium term.
* I3 can poach any talent I bring on as long as I’m working nearby (vikram, drltc)
* DNS blockchain functionality is trivial (it's already done!) and the hard work comes in the infrastructure development and navigating the politics of the existing DNS system. Once one person figures this out it opens the gates for any other system to come in and take advantage of it, and BTS now has all the resources that DNS had.
* DNS price has adjusted to BM’s proposal which means any change now will just hurt more people.


Right now the best way to actually get DNS on a blockchain to be successful would be for me to work with Agent and a private investor and do things quietly as a completely independent effort without any BTS baggage. The right thing to do for that project would be to honor DNS holders at a point just prior to the proposed allocation post. The second best way would be to do this under the new BTS umbrella. I do not have plans to do either at this time. I will probably be spending my time developing KeyID (key graph / rep system etc) as an app within BTS, but who knows - if I get my way I’ll be managing development of BTS Platform with Vikram.


I’m very sorry to everyone who got burned by the proposal. The people this hurt the most are those who specifically believed in me and this project. I was blindsided by this also - I’ve never sold DNS except the private deal prior to network launch which helped pay for key development by dbrock, greg, derrick, etc. Perhaps I will use what’s left of that fund (not much) to buy back DNS at just above it’s “true” price and put it into the non-honored dev fund.


Assuming the proposal cannot be changed (can it? would do more harm than good I think) you should now value DNS as about 4.5% of BTSX by market cap (because (~5/4.1 dev fund adjustment)*(.03/.8 percent of BTS)).

Right now we all need to focus on BTS+BitUSD to solidify a network effect advantage. Let’s get this over with as fast as possible.

It's annoying, why are we doing it? Is it just to not give seo juice to spam links?

Please pm me on skype (nikolaimushegian) if you are an active DNS full node - delegates, faucets, seed nodes, chain servers, etc

I screwed up... the code to check that capital letters aren't allowed in names was hidden in the "subname" functionality and so I accidentally disabled it.

Thanks greg wexler for finding it. Will do damage control in the morning, meanwhile all the init delegates have been swapped back in.

Right now:

1) Each block has a maximum possible subsidy which is a fixed % of the difference between current_shares and max_shares
2) Your pay_rate determines what % of normal transaction fees *and* what % of the subsidy you want.

This leads to us burning through the delegate subsidy very fast as nobody is taking a high pay rate.

I propose:

1) pay_rate only determines how much of "normal" transaction fees you take (the rest are burned).
2) subsidy_rate determines what % of the max possible subsidy you take.
3) subsidy_burn_rate determines what % of max possible subsidy you burn.
   so subsidy_rate + subsidy_burn_rate <= 100   


Thoughts? The idea is to allow us to "save up" the delegate subsidy while still giving the stakeholders the option to burn through the subsidy if they want to.

https://github.com/keyid/keyid

branch "public_testnet".  DON'T USE MASTER, THAT'S THE REAL NETWORK! Make sure you are transferring "DNST" and not "DNS"!

Try:

keyid_set_edge from_acct to_acct edge_name edge_value
keyid_get_edges from_acct [to_acct] [edge_name]

Here is how the dev fund was "spent" when I offered DNS backpay to early supporters / investors:

https://docs.google.com/spreadsheet/ccc?key=0AjWEvwFB1BZ7dHlRMFFlRHVvM21XU3pqS2NoSUFqWWc&usp=drive_web#gid=0

In addition, 5% (1% of initial allocation / 0.5% of max allocation) of the dev fund was sold for $20k (the dollars have not all been spent and will be used for anything that does not accept DNS). Those 50m DNS will be held for 6 months and then sent to Bo Shen who will split this stake among the early investors who pooled the $20k. These investors are mostly influential BTS community members from the Eastern side.

AGS that was for Keyhotee was claimed for the dev fund - sorry founders, AGS wasn't part of the promise until after keyhotee drive ended, and the AGS day 0 keyhotee thing is a completely broken model.

This leaves us at 958,016,700 DNS in the dev fund.

I'm first to acknowledge that "toast secretly decides" is not the best way to spend these dev funds and that so far I have been "overspending" relative to the DAC's optimistic projection of its own shares. So here are some steps towards better process:

* Inflation will be favored for anything that is not a large infusion of capital or a "strategic partnership".
* Dev funds will not be sold without public notice.
* In the next release I will put source locks on each of the remaining 4 dev keys (200m a piece) - this is an additional check on spending power which requires delegates to approve a hard fork which unlocks these.

Glad to hear concerns and suggestions.