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

Pages: 1 ... 62 63 64 65 66 67 68 [69] 70 71 72 73 74 75
1021
General Discussion / Re: DACs vs. Firms (Are DACs useless?)
« on: June 10, 2014, 12:01:17 pm »
Let me clear something up as well - I am looking at how I would do things differently, had I been starting BitShares from the beginning.
It is clear that Invictus is doing exactly what they promised to do, and they have not set the expectations this high.

So here is how I would do it:

1. I would make the funding only a % pledge amount. Say 5%. I.e. you pledge 5% of your donation, but only buy the full amount once the system is up and running (within 3 months of the start). Yes, this would require actually building a DAC that allows cross chain decentralized exchange. Yes, it is possible. However I wouldn't even expect donations, I'd probably do a proof of burn instead. This also gives better incentive on making my own asset worth something.

2. Then I would create projects and proposals for bettering the system, which would be funded by the owners. I would NOT accept "donations" in PTS or BTC. (let's face it, that's just a term masking the fact that they are doing an IPO). It would be all through assurance contracts, and the funds would not only be available to spend as I see fit. Yes, Invictus has stated that they will spend the funds AS THEY SEE FIT. My opinion is that this is still old school mentality.

3. I would also build restrictions in the system, such that any funded project has limits on spend. i.e. it has predefined milestones, and limits on how much you can spend per day, unless voting approves it (sometimes there is a need)

In any case, I might just have to get these prototypes to a more complete stage and present them for peer reviews. Because until people see what my vision is and how it works, I'm just my own echo chamber and come off as FUD, when really I'm just looking at how I would improve things. I see so many possible improvements, but it is clear that Invictus is not willing to make drastic changes, and perhaps that is a good thing, as it is risky, and also clear that the investors in Invictus don't want them to make changes. So, Invictus will deliver on what they set out to do. And I should shut up and go back to the drawing board. :)

1022
General Discussion / Re: DACs vs. Firms (Are DACs useless?)
« on: June 10, 2014, 11:34:23 am »
I think DACs are superior for virtual entities which have to operate across multiple jurisdiction. The law just cannot keep up with technology. So why would you want to artificially slow the rate of innovation by going with a firm when you can build a DAC without permission and apologize later on?
That was my point - even Invictus the "champions" of DAC, had to create entities, and then deal with complications. I'm not judging, just pointing out that a true DAC was not their first choice for their operation.

Innovate and then apologize rather than fear to innovate and have the species go possibly extinct as a result. No one needs permission to make a DAC and it can run independent of human operators someday while a firm will never be able to do that.
Correct. However Stan recently made a post stating the opposite, saying that "better to ask for forgiveness, than permission" was a bad idea.
Again - not judging, just showing that they are not truly embracing and eating their own dog food. However I'm hoping that will soon change.

DPoS isn't the only possible design for a DAC. I also don't think every DAC has to have a blockchain. MaidSafe may actually be a DAC too if they can get it running properly and it doesn't have a blockchain.

Like I said, there are many ways to innovate in the area. Block-chain is probably going to be viewed as an outdated technology not long from now.

It all depends on if you take the strict definition of a DAC or a loose definition. In the strictest definition MaidSafe lacks transparency because we cannot see all the transactions but it fits everything else.

Why do you need to see all the transactions? In fact that's why it's the perfect solution - it solves privacy concerns as well. So long as you have proof that you own your amounts, why do you care to see other transactions?

1023
General Discussion / Re: SMS Wallets
« on: June 10, 2014, 11:12:19 am »
The best way to implement this is to just request a signature over SMS, and charg a miniscule fee for processing the transaction.

i.e. have software on the phone generate the digital signature (I'm assuming most of these phones can still run some form of custom softwar, even if they have no Internet)

steps:

1. RECEIVE INVOICE TRANSACTION IN SMS TXT (INCLUDES TINY FEE FOR PROCESSOR)
2. COPY + PASTE INTO SOFTWARE
3. GENERATE SIGNATURE
4. COPY + PASTE BACK INTO SMS
5. PROCESSOR SUBMITS TO BITCOIN NETWORK

1024
General Discussion / Re: DACs vs. Firms (Are DACs useless?)
« on: June 10, 2014, 10:57:01 am »
To me a true DAC is not controlled or owned by any legal entity. It is owned and controlled by voted delegates. Delegates in turn are incentivized to do what is expected of them, and even punished if they do what isn't expected.

If I am correct (and obviously I think I am :P), Invictus is a Central entity that formed to create the DAC toolkits and develop their own DACs to start and compete in the market.  I do not recall them ever saying anything about being a DAC themselves, though.
+Invictus/Bytemaster/Stan stated several times that invictus is a part of the bitshares ecosystem
+AGS/PTS is just their way of distributing initial shares, legal issues have nothing to do with DACs in general but with invictus holding the keys for the Angel addresses!

I'd like to see a system in which the keys of a DAC don't need to be held by a centralized entity. That's all.

What Invictus is doing is good, but not great. Things can be improved 10x. But anytime I raise the questions I'm tagged as a "non-believer" and a FUD spreader. I'm just looking at the natural progression of the space. Nothing wrong with expecting more, especially, when I see it is possible.

I'm not in a position to go work on these ideas full time at the moment. But may be I should. So far every experiment I did for fun is showing promising progress. I even have a prototype for a quantum computing resistant coin.

1025
General Discussion / Re: DACs vs. Firms (Are DACs useless?)
« on: June 10, 2014, 10:41:25 am »
Yum! Kool Aid!

1026
General Discussion / Re: DACs vs. Firms (Are DACs useless?)
« on: June 10, 2014, 09:44:04 am »
That said, I am very interested in brainstorming around methods that make the block-chain obsolete.

I have come up with couple solutions, some close to what MaidSafe does, but there are few places that would need a different form of decentralized consensus, perhaps something like DPOS.

1027
General Discussion / Re: DACs vs. Firms (Are DACs useless?)
« on: June 10, 2014, 09:41:17 am »
Good write up! I believe that DACs have not evolved yet. Tools will become better, new systems will be tested/proven. It will take a much longer time than people expected.

I found it quite bizarre that Invictus would preach DACs, yet they have 2 legal entities and complain about "regulatory issues around making AGS liquid".

To me a true DAC is not controlled or owned by any legal entity. It is owned and controlled by voted delegates. Delegates in turn are incentivized to do what is expected of them, and even punished if they do what isn't expected.

1028
Stakeholder Proposals / Re: Qualification to remain a delegate
« on: June 08, 2014, 08:28:01 pm »
I'm assuming delegates up-time is critical for the ecosystem. For that will there be a way to gather stats for delegates, as to how quickly they process transactions, or how often they are up and running?

Also how would the system handle internet split? Say there was a technical difficulty and the Internet on one continent was isolated for a few hours. I.e. the Internet gets split in 2 separate clouds, unable to reach each other.

I understand the second question is more technical and this may not be the place to discuss it, but I'm curious as to how much the system can handle automagically. i.e. stats/bad behavior/etc. if these get reported then voting someone out becomes an easier case.

1029
LottoShares / Re: Check your expected LottoShares balance for AGS
« on: June 05, 2014, 07:56:26 pm »
Would be nice if AGS explorer shows it too :)

1030
Technical Support / Re: AGS potential security issue
« on: June 04, 2014, 04:03:03 am »
So help me understand - PTS doesn't have regulatory issues because it was mined, not issued? And in retrospect - AGS might have regulatory issues, because it was directly funded?

I'm asking because from a technical perspective I don't see any issues implementing this. It seems that you guys are avoiding it like a hot potato, but if that's what your lawyers said then I guess it explains the resistance on your part.

1031
Technical Support / Re: AGS potential security issue
« on: June 03, 2014, 09:15:00 pm »


That is how I interpreted CrazyBit's suggestion.

You seem to be suggesting that AGS will be liquid but I still haven't heard anything that suggests that from anyone within Invictus.

Yes, my proposal makes it liquid and is extremely easy to implement. Had I seen some support from Invictus I would even volunteer to implement it. But no dice. So we wait. Seems like we are close for the BTS X though.

I think it's a pretty good idea, and anyone is free to implement it. Likewise anyone is free to just go ahead and implement a liquid version of AGS once the donation period ends.

I just don't think anyone here wants to change the officially endorsed definition of AGS, don't want to make the "changing the deal" reputation worse.

Right, but we wouldn't be changing the distribution amounts, just allowing ownership to be transferred, prior to launch. Anyways. We live and learn. I would do this if I know Invictus would honor it for BTSX otherwise I have no incentive at the moment.
And again, it seems they are much closer to release so defeats the purpose a bit. But had the idea met less criticism I could've had it up and running back in March.

Thanks for the positive feedback, toast!

1032
Technical Support / Re: AGS potential security issue
« on: June 03, 2014, 07:06:16 pm »

As I understood the suggestion, the signed message was to be used to collect the shares of the new DAC instead of the private key.  But if the private key has already been exposed anyone who has it can create that signed message.

As far as private key already exposed there is no good way to solve that with the current system. I did like the idea of using derived individual private key per DAC so that if one DAC software steals it, it doesn't compromise the rest of your apps.

1033
Technical Support / Re: AGS potential security issue
« on: June 03, 2014, 06:56:40 pm »

That is how I interpreted CrazyBit's suggestion.

You seem to be suggesting that AGS will be liquid but I still haven't heard anything that suggests that from anyone within Invictus.

Yes, my proposal makes it liquid and is extremely easy to implement. Had I seen some support from Invictus I would even volunteer to implement it. But no dice. So we wait. Seems like we are close for the BTS X though.


1034
Technical Support / Re: AGS potential security issue
« on: June 03, 2014, 05:25:41 pm »
I disagree. Signing a message transfers over the responsibility to a new unexposed private key. How does that not solve the problem?

1035

are you going to argue me that if you giving away 1 million to hire someone to finish a single bitshare wallet in one month, that won't happen?

Precisely! (except for the "single wallet" part... we're not just building a wallet for an existing system).
Find me a credible software project manager who would say otherwise.

"You can't get 9 women together and tell them to make a baby in 1 month."

(if anyone is wondering, I'm only posting during compiles - if anything would speed us up it's a faster c++ compiler)

Try bundling the C++ compiles of the many individual CPP files into a larger single one, which invokes the compiler once instead of parsing the same includes every single time.


Pages: 1 ... 62 63 64 65 66 67 68 [69] 70 71 72 73 74 75