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 - theoretical

Pages: 1 ... 4 5 6 7 8 9 10 [11] 12 13 14 15 16 17 18 ... 34
151
General Discussion / Re: Why UIAs use BTS as fees when they are transferred?
« on: January 12, 2015, 09:16:16 pm »

This could conceivably be implemented by a wallet that uses the UIA to buy BTS with market operations.

The problem is that I think market orders take 1-2 blocks to happen even if there is a matching order, thus a "self-funding UIA sell order" is not possible (where someone with a zero BTS balance and nonzero UIA balance creates a transaction to sell their UIA for BTS, paying the tx fee for the transaction with (part of) the proceeds).  And supporting it would require a ton of fundamental architecture changes and possibly open up new and interesting attack vectors.

It would be more feasible to have an "auto top-off" wallet function where if you have less than 10 tx fee worth of BTS, and you're transferring a UIA, the wallet will automatically "top you up" to 10 tx fees by withdrawing a little extra UIA and selling it for BTS at below-market rates (so the sale is basically guaranteed to match).  Of course it will have a confirmation prompt showing how much the top-up will cost and how many tx fees it will provide.

152
Stakeholder Proposals / Re: Developer delegate: dev.bitsharesblocks
« on: January 09, 2015, 11:27:29 pm »
Quote from: bytemaster on January 09, 2015, 05:42:47 pm
Can you add the ability to fetch the BTC address for the BTS Public Key under an accounts Active Key History and then provide a JSON RPC API that will allow people to lookup Bitcoin addresses for people that have registered accounts on BTS?   Perhaps have an option to return the address in several of the top crypto currencies. 

This way people can use our ID system for all crypto platforms and easily share it with people.

This is better accomplished by writing a standard spec for users to specify addresses for other cryptos in public data or object graph.

Importing the same private key into N different cryptocoin clients means that all of the different cryptos owned by that key will be lost if any of the clients that has that key is compromised.

My worry is that some of the more obscure altcoins may not have enough eyes on their source to avoid key stealing back doors.  And the more we encourage behaviors that require people to re-use the same keys in multiple clients, the more potentially lucrative the attack vector would become.

You might be able to use Diffie-Hellman to take a user's public key K and the name of the altcoin, say N = "DOGE", and determine some new pubkey K' = f(K, N), then K' is your Doge key.  Clearly you can get the private key for K' if you have the private key for K -- that's kind of the point of this whole construction.  But if you can "go backwards", i.e. get the private key for K from the private key for K', then it defeats the purpose (compromising your Doge private key gives the attacker enough to derive your BTS private key).  I'd have to study ECDH in detail for a while to figure out if "going backwards" is possible or not.

153
DevShares / Can't connect to DVS default peer, "Operation canceled"
« on: January 09, 2015, 08:48:19 pm »
I'm creating a brand new DVS directory, but I can't seem to connect to any peers.  I just have the one default peer.  Maybe the default peer is down, or its max connections are saturated?

Here is my p2p log:

Code: [Select]
2015-01-09T20:35:44        th_a:?unnamed?        open_database ] old database version, upgrade and re-sync                      chain_database.cpp:84
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_0 tid:140470143198976                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_1 tid:140469758711552                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_2 tid:140469750318848                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_3 tid:140469741926144                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_4 tid:140469733533440                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_5 tid:140469388441344                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_6 tid:140469380048640                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:wallet_scanner_7 tid:140469371655936                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:Mail client proof-of-work thread tid:140469363263232                      thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:Mail client indexing thread tid:140469354870528                   thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:p2p tid:140469346477824                   thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:stdin_reader tid:140469338085120                  thread.cpp:95
2015-01-09T20:35:55        th_a:?unnamed?               thread ] name:upnp tid:140468851570432                  thread.cpp:95
2015-01-09T20:36:08 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:36:14 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Forcibly disconnecting from handshaking peer 104.236.44.210:2009 due to inactivity of at least 5 seconds                     node.cpp:1235
2015-01-09T20:36:14 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Peer's negotiating status: connecting, bytes sent: 0, bytes received: 0                      node.cpp:1239
2015-01-09T20:36:14   p2p:connect_to_task           connect_to ] fatal: error connecting to peer 104.236.44.210:2009: 0 exception: unspecified
Operation canceled
    {"message":"Operation canceled"}
    asio  asio.cpp:59 error_handler                     peer_connection.cpp:206
2015-01-09T20:36:14 p2p:delayed_peer_deletion_task              destroy ] Unexpected exception from peer_connection's accept_or_connect_task : {"code":0,"name":"exception","message":"unspecified","stack":[{"context":{"level":"error","file":"asio.cpp","line":59,"method":"error_handler","hostname":"","thread_name":"asio","timestamp":"2015-01-09T20:36:14"},"format":"${message} ","data":{"message":"Operation canceled"}}]}                        peer_connection.cpp:109
2015-01-09T20:36:21 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:36:34 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:36:47 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:37:00 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:37:13 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:37:14 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Forcibly disconnecting from handshaking peer 104.236.44.210:2009 due to inactivity of at least 5 seconds                     node.cpp:1235
2015-01-09T20:37:14 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Peer's negotiating status: connecting, bytes sent: 0, bytes received: 0                      node.cpp:1239
2015-01-09T20:37:14   p2p:connect_to_task           connect_to ] fatal: error connecting to peer 104.236.44.210:2009: 0 exception: unspecified
Operation canceled
    {"message":"Operation canceled"}
    asio  asio.cpp:59 error_handler                     peer_connection.cpp:206
2015-01-09T20:37:14 p2p:delayed_peer_deletion_task              destroy ] Unexpected exception from peer_connection's accept_or_connect_task : {"code":0,"name":"exception","message":"unspecified","stack":[{"context":{"level":"error","file":"asio.cpp","line":59,"method":"error_handler","hostname":"","thread_name":"asio","timestamp":"2015-01-09T20:37:14"},"format":"${message} ","data":{"message":"Operation canceled"}}]}                        peer_connection.cpp:109
2015-01-09T20:37:26 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:37:39 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:37:52 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:38:05 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:38:18 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:38:31 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744

I restarted and got something similar:

Code: [Select]
2015-01-09T20:45:38 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Forcibly disconnecting from handshaking peer 104.236.44.210:2009 due to inactivity of at least 5 seconds                     node.cpp:1235
2015-01-09T20:45:38 p2p:terminate_inactive_connections_loop terminate_inactive_c ] Peer's negotiating status: connecting, bytes sent: 0, bytes received: 0                      node.cpp:1239
2015-01-09T20:45:38   p2p:connect_to_task           connect_to ] fatal: error connecting to peer 104.236.44.210:2009: 0 exception: unspecified
Operation canceled
    {"message":"Operation canceled"}
    asio  asio.cpp:59 error_handler                     peer_connection.cpp:206
2015-01-09T20:45:38 p2p:delayed_peer_deletion_task              destroy ] Unexpected exception from peer_connection's accept_or_connect_task : {"code":0,"name":"exception","message":"unspecified","stack":[{"context":{"level":"error","file":"asio.cpp","line":59,"method":"error_handler","hostname":"","thread_name":"asio","timestamp":"2015-01-09T20:45:38"},"format":"${message} ","data":{"message":"Operation canceled"}}]}                        peer_connection.cpp:109
2015-01-09T20:45:44 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:45:57 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744
2015-01-09T20:46:10 th_a:rebroadcast_pending rebroadcast_pending_ ] rebroadcasting 0                    client.cpp:744

154
General Discussion / Re: Reversible transactions - is there any sane way this could work?
« on: January 08, 2015, 09:50:37 pm »
Quote from: monsterer on January 08, 2015, 07:19:18 pm
If it were possible to design a transaction type which was reversible (and fair) it could solve a lot of problems.

In version 1.0, when creating a UIA you will be able to specify an optional flag, which will allow the issuer to freeze or revoke any balance in that asset [1].  This is primarily to help gateways [2] comply with regulatory requirements.  (Many governments want entities that hold user funds to be able to freeze / confiscate account balances.)

Quote from: monsterer on January 08, 2015, 07:19:18 pm
Crypto generally aims to let the end user own the value token

Which is why there's going to be inherent tension between reversible transactions and decentralized ownership schemes.  In other words, if someone else can reverse a transaction and take tokens out of my wallet, did I ever really own those tokens in the first place?

Our solution is to provide both "traditional" irreversible tokens and "reversible" UIA's (where the UIA or their designee has the power to revoke anyone's balance).  Since we also provide tools to allow people to trade them against each other, the relative market cap and value of the two different approaches will become clear.

[1] Actually, currently the plan is for all UIA's created post-1.0 to have these capabilities enabled, but allow the UIA issuer to permanently, irrevocably turn off the capability.  This design is not final and may change before 1.0 is released!

[2] A "gateway" is a business that takes fiat currency deposits from the general public and issues a UIA; effectively shares of the UIA can be created or redeemed for an equal amount of fiat currency.

155
General Discussion / Re: What are Github commits?
« on: January 08, 2015, 04:44:23 pm »
Quote from: Gentso1 on January 05, 2015, 10:36:38 pm
I am trying to get a working understanding of what commits actually are and more importantly if we as users/shareholders can use them as some sort of metric.

Ultimately, really understanding what a commit represents entails understanding how Git works as a distributed version control system, and the different possible workflows enabled by Git.  Which you probably won't really understand until you've used Git for a while, including contributions to larger projects.  (At least I didn't really understand until I'd used Git for a while.)

We can help give you an idea in this thread, but the idea will necessarily be simpler than the reality of the different ways different people and projects use commits.

Quote from: bytemaster on January 05, 2015, 10:54:50 pm
No commits means they are not writing code.

Not necessarily.  You can have code that isn't ready to go into a commit, or you can have commits locally that you haven't published yet.

I like to clean up my commits before I publish them.  Nobody's interested in the 10 different one-line typo corrections and insertion / deletion of temporary debugging code I had to make to get my brand new code to compile and run as expected for the first time, so putting that kind of crap in the public commit record on Github as 10 different commits accomplishes nothing except wasting the time of everyone who views them and artificially inflating my "number of commits" metric.

So for this reason, my published commits aren't always an up-to-date record of the work I've been doing.

156
General Discussion / Re: Blockchain size
« on: January 05, 2015, 09:07:58 pm »

At one point, there were discussions of a penalty for those who do not move their balances at least once per year.  I believe the stated reasons were to encourage people to keep delegate votes up-to-date, encourage people to combine their balances, and provide a mechanism to permanently destroy "dust" balances.

However, AFAIK this scheme has never been implemented, and is currently no longer under consideration.

157
General Discussion / Re: How to make payroll without multiple delegates per developer
« on: January 02, 2015, 11:18:42 pm »
Quote from: sumantso on January 02, 2015, 10:24:41 pm
The centralization issue can be easily avoided if the block producers and employees are separated. I have given the proposals several times elsewhere.

I proposed a concept along these lines back when dilution was first being considered.

I think the main reason my proposal was not implemented was that it was considered desirable to make as little change as possible to the code.

As a secondary effect, it produces an incentive for delegates to have high uptime (downtime is a lot more expensive for 100% delegates than 3% delegates), and get some connections to the community.

I thought that having business people and block signers overlap would result in a lot of people like me spending a ton of time dealing with delegate IT issues, feeds, etc.  Which has certainly turned out to be the case.

158
General Discussion / Re: How to make payroll without multiple delegates per developer
« on: January 02, 2015, 09:47:05 pm »
Quote from: NewMine on January 02, 2015, 09:18:33 pm
It sounds like you got duped...I am quite surprised that in an industry where everyone exclaims to not invest more than you can lose, that you would be asked *or you would commit to flip upside down your life to work for a not guaranteed wage and with possible total loss of all earnings if BTS price dropped.

From what I understood, I was to be paid in US dollars, discounted by the USD value of my delegate income.  At the time, I believed I3 still had a ton of AGS funds and was only employing ~10 people.  It didn't seem risky because the plan seemed to be that I3 would use AGS funds to indemnify me against exchange rate risks, problems with the chain itself, or delegate IT screwups.

To be fair to bytemaster, it was suggested around this time that people begin to run inflationary delegates to preserve AGS funds (at first on DNS chain, after the merger on main chain), and that this would be the long-term vision:  People paid by inflation rather than AGS.

However, it was not at all clear -- or at any rate, it was not clear to me -- that compensation arrangements were going to change at the end of the year.

It's still been less than 24 hours since I first saw the post detailing the new compensation arrangements, and I am not going to make any big life decisions for at least a week while I consider the implications.

159
General Discussion / Re: How to make payroll without multiple delegates per developer
« on: January 02, 2015, 09:33:35 pm »
Quote from: NewMine on January 02, 2015, 09:18:33 pm
Multiple delegates held by one person taxing the blockchain will definitely kill this.

Which is why I proposed the system in OP where bytemaster decides who deserves what, issues IOU's, then the shareholders vote in delegates held by multiple different owners to redeem the IOU's by buying and burning them.

The real solution would be to have the blockchain scale delegate income within the supply envelope, i.e. if max inflation is 5050 BTS / round, and you have 11 delegates at 100% and 90 delegates at 3%, then you just figure 11 * 100 + 90 * 3 = 1100 + 270 = 1370, make each percentage point worth 5050 / 1370 so the 100% delegates get 368.61 BTS and the 3% delegates get 11.05 BTS, the total is 11 * 368.61 + 90 * 11.05 = 5049.21.  Now the "%" has become kind of a misnomer and we just have arbitrary weights.

You should be able to have the delegate specify maximum as well as a weight, then you pour the round's supply allocation into each delegate proportional to their weight, removing a delegate whenever its max pay is reached.  You should be able to specify the maximum as a BitAsset, so you can specify e.g. "I want $200 / round" and the blockchain will give you $200 worth of BTS when your slot comes up (or even better, front-run the market and buy you BitUSD automatically).

All of these features would be hardforks and need lots of testing, the main selling point of OP is it captures 80% of the value and can be implemented by a simple script on today's blockchain, no complicated, potentially exploitable exchange rate discovery / market maker bot logic or hardfork required.

160
General Discussion / Re: How to make payroll without multiple delegates per developer
« on: January 02, 2015, 09:07:05 pm »
Quote from: NewMine on January 02, 2015, 07:31:49 pm
Wait. You just got $17K bonus and you have a 100% delegate raking around $2k per month? Plus, I assume you got $100K/yr prorated for however many months you were on I3/AGS payroll and you are publicly complaining that you think you won't be able to eat in a fewmonths?

I don't know what you do for a living, but if you moved to a different state for a new job (including paying relocation expenses out of your own pocket), and then within less than three months of hiring you they gave you a big bonus equivalent to a couple months' income, but told you they'd be cutting your pay to 1/3 going forward, wouldn't you try to negotiate a deal somewhat equivalent to what you originally agreed to -- and if you couldn't, wouldn't you at least seriously consider walking away?

Quote from: NewMine on January 02, 2015, 07:31:49 pm
be able to eat

This is a metaphor.  As others have noted, the relevant metric is opportunity cost -- how much I could be earning elsewhere, but am not.

Quote from: NewMine on January 02, 2015, 07:31:49 pm
publicly complaining

I think it's clear that I3 has little interest or ability to continue to directly pay developers.  Therefore, if I want to raise concerns about how much I am paid, I must talk to shareholders and present my case for new 100% delegate(s).  Which means making my case publicly, since there is no effective way to contact the BTS holders privately.

161
General Discussion / Re: How to make payroll without multiple delegates per developer
« on: January 02, 2015, 08:44:39 pm »
Quote from: delulo on January 02, 2015, 07:16:01 pm
Can you say how much you received in total as pay (BTS, BTC, USD) and how long you have been working full time so things can be put into perspective?

How much I make is a very personal question.  I don't usually like to answer it.  But I think I must be transparent about this if I want shareholders to vote for additional delegates, so I will go ahead and say.

EDIT:  Redacted, apparently being transparent is causing PR problems.  I don't really understand the issue, but for now I'm going to remove the exact accounting until I can discuss with bytemaster and others exactly what the issue is.

This exact analysis took me quite a while to prepare, which I could have spent writing code.  Which is a prime example of

Quote from: bytemaster on January 02, 2015, 05:58:34 pm
demanding excessive accountability to the point of hindering productivity.

especially given that the exact answer came out pretty much the same as my back-of-the-envelope estimate of

Quote from: theoretical on January 02, 2015, 07:17:40 pm
I plan to start a campaign for 1-2 additional 100% delegate(s) sometime in February or early March.

162
General Discussion / Re: How to make payroll without multiple delegates per developer
« on: January 02, 2015, 07:17:40 pm »
Quote from: bytemaster on January 02, 2015, 05:58:34 pm
I think you are misunderstanding my intentions.  My intentions are for developers to be well compensated and error on the side of over compensation.  The penny pinchers I was referring to are those who are trying to nickel and dime developers and demanding excessive accountability to the point of hindering productivity.

I have provided complete transparency on the bonus each developer received so that people would not overcompensate developers with a large bonus + paid position. 

I want to make my own intentions clear as well.  It's not my intention to soak the community for the year-end bonus from AGS funds and additional 100% delegate(s).  Rather, my problem is that the AGS bonus will only last a couple months at the current exchange rate, and I want to be reasonably sure that I'll still be able to eat when it runs out, even if BTS hasn't gone to the moon by then.

Despite the tax accounting of the bonus, I think the community will be unlikely to support any future delegate proposal which does not treat the bonus as an advance payment of my 2015 funding.  Thus, even though I am not contractually obligated to do so, I currently plan on sticking around for at least 2-3 months with a single delegate regardless of the outcome of this discussion.

Then I plan to start a campaign for 1-2 additional 100% delegate(s) sometime in February or early March.  At that time I will provide a detailed accounting to the community, showing that my bonus has run out and I do in fact need the additional delegate(s) to continue to receive a competitive salary, and also including a detailed list of my recent contributions.

Edit:  This plan is on hold until I can discuss things with bytemaster in person and decide what I should do.

Note that most other developers received a much larger bonus, and will not be in that situation at the same time.

163
General Discussion / Re: How to make payroll without multiple delegates per developer
« on: January 02, 2015, 07:07:20 pm »
Quote from: bytemaster on January 02, 2015, 05:58:34 pm
I have no problem with developers asking for additional delegate slots if one slot doesn't pay enough.

This is the main issue.  Some discussion in the other thread led me to believe that multiple 100% delegate registration for developers was being discouraged due to increased centralization.  This thread started out as a technical proposal for mechanics that would achieve the same economic outcome for developers as multiple delegate registration, without the drawback of increased centralization.

Quote from: bytemaster on January 02, 2015, 05:58:34 pm
I have provided complete transparency on the bonus each developer received so that people would not overcompensate developers with a large bonus + paid position. 

Transparency in AGS usage is good, especially as regards the bonus.

Quote from: bytemaster on January 02, 2015, 05:58:34 pm
I had no problem advancing you the funds to register your paid delegate nor trusting you with a no-strings-attached bonus

I was more using this as an example to illustrate how meager my BTS holdings actually are.

Quote from: bytemaster on January 02, 2015, 05:58:34 pm
I think everyone values you and you will have no problem maintaining a good income while you have support of the community.

I hope that's the case, I've been active on this forum and trying to be sure my contributions are public.

Quote from: bytemaster on January 02, 2015, 05:58:34 pm
I am against any kind of commitment to vote for you.  People have a right to vote how they think is best when they think it.

Understandable.  It sets a bad precedent if delegates aren't continuously held accountable.

164
General Discussion / Re: How to make payroll without multiple delegates per developer
« on: January 02, 2015, 06:56:26 pm »
Quote from: Carpet Ride on January 02, 2015, 06:00:28 pm
Just trying to understand the dev mindset more.  At the moment, what factors motivate you to work full time on the project and can you quantify how much each factor matters to you?

What matters most to me is how interesting the problems we have are, how understanding and improving the code requires knowledge of a lot of diverse stuff from low-level computer hackery (one intermittent crash I successfully debugged involved tracing through the Bitshares client one assembly language instruction at a time), cryptographic mathematics, economic theory.  When I took an introductory macroeconomics course (in college years ago), I never imagined a career in software development would one day lead to effectively being an influential advisor to a central bank!

But the problem is that my personal financial situation isn't the greatest, and I feel some pressure to be sure I'm getting paid a fair market salary.

So I guess I would say that being paid is more important, since I'll probably eventually leave if I'm not getting paid enough, even though I love the work.  Does that make sense?

165
General Discussion / Re: How to make payroll without multiple delegates per developer
« on: January 02, 2015, 05:55:55 pm »
Quote from: bytemaster on January 02, 2015, 05:22:34 pm
Core developers have a large enough stake that they now get "automatic bonuses"  if the value of that stake goes up as a result of their efforts.   The incentives are aligned. 

Assume for the moment I did have a large stake.  Then I have two choices:

(a) Leave and watch my stake grow x% based on the efforts of other developers
(b) Stay and watch my stake grow y% based on the efforts of myself and other developers combined

My effective salary is then (y-x)% times my stake, plus income from any delegate(s) I operate.

I am not sure that (y-x)% is large enough even if my stake is large.

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

Page created in 0.194 seconds with 23 queries.