Weren't there problems with the miner itself? If not then I should be paying Wolf the bounty, but my recollection was that it only worked for a little while and then would crash. Please let me know if incorrect.
|
|
|
I am torn on the transparent vs non transparent blockchain.
I'm nearly 100% certain that a transparent blockchain for currency would not exist if non-transparent blockchains were developed first. (Possibly, blockchains for things like land title records might be made transparent, if those things make sense at all.) First mover advantage does exist though.
|
|
|
The 2.5ms on an i7-2700K came from NoodleDoodle's commit notes I think. It was obviously intended as a CPU-only number that was not realistic for the full system at all. I'm pretty sure even today with a multi-processor server using newer CPUs you could do many times better (if you wanted all full nodes to be on big servers in data centers). But that's still not a realistic end-to-end number at all.
|
|
|
A crowdfund can be configured to allow every potentially interested buyer to remove his offer to buy at any time. Okay that is a somewhat unconventional definition. If no one commits to anything then I agree you are likely outside the definition. But this is getting quite contrived in my view: 1. No commitment for funding. 2. No efforts post-sale by the developer to fix the damn thing if it breaks 3. No efforts by the developer to refine post sale (at least none that are important to success) Maybe you can avoid problems with securities law, but in practical terms the project seems like a mess of other problems.
|
|
|
Your crowdfunding argument does not work because a commitment to pay by sponsors is itself valuable consideration. It is used by the developer to backstop development and reduce risk (and can be used in other ways, such as to support raising capital from others). https://en.wikipedia.org/wiki/Consideration#Option_contracts_and_conditional_considerationI'm also not sure that the definition of crowdfunding necessarily means the developer doesn't get the money until the project is complete. If that's what you mean you should be clear on that, but from an investment contract point of view, it probably doesn't matter. You are correctly pointing out that making a coin that is not yet mostly finished I guess this is yet another gray area but I'm not really sure what "mostly finished" means here. If it has all features appears to be "done" but it turns out to crash such that no one other than the original developer can or will fix it then everyone is going to lose all their money. So the developer's efforts or lack thereof may still be critical. I guess that is a market value question too. If the developer says "I won't fix it if it breaks" then what will the ICO price be vs. the case where the developer will fix it? I think very, very different, which argues for the importance of the developer's efforts even after launch, but who knows I might be wrong. remove things from the protocol that force users to rely on the managerial control of the core devs, such as that forced hard fork every 6 months There is nothing in the protocol for that. If no further updates are released (or if users don't install the updates), nothing will happen after six months. It will just keep going forever (assuming people continue to use it and it doesn't crash). The idea of the six month window is to continue to add them on a rolling basis with updates, so no one is surprised. (Off topic for this thread though, if you want to discuss it you know where the Monero thread is.)
|
|
|
If say someone who sent me a bitcoin years ago decides to do a double spend, he can create a transaction and that transaction will be ignored because bitcoin has blocks. It seems to me, dagcoin would be vulnerable to double spends this way.
In dagcoin as I understand it the second spend would be ignored because the first one would have much more work endorsing it.
|
|
|
It appears that whether the users think it is an investment or not, has nothing to do with the classification as a security. No. One and only one link on this thread. I'm getting back to work now. "According to the Howey test, an instrument is only a security if it involves an investment of money or other tangible or definable consideration used in a common enterprise with a reasonable expectation of profits to be derived primarily from the entrepreneurial or managerial efforts of others." http://www.legalandcompliance.com/securities-resources/securities-glossary/howey-test-to-determine-if-an-investment-is-a-security/That is why crowdfunding a movie does not violate securities law, or even a toy, watch, etc. where you get the item as a reward. Coins not so much. The red bolded phrases are the salient part of the test I am referring to. To be an investment security requires an ongoing " common enterprise" where the buyer "r easonably expects profits" due to the ongoing " entrepreneurial or managerial efforts of others" in that enterprise. When the developer sells some software and tokens encoded in a genesis block of the protocol of that software, there is no enterprise. The users take that and decide whether to make it an enterprise. For example, they could throw away the genesis block if they wanted to and were able to organize themselves to do so. "Ongoing enterprise" or "ongoing efforts" is not part of the definition. Selling interest in a time- or scope-iimited project still counts. That's still a common enterprise with profits potentially derived "primarily" from the efforts of others. If someone privately finances development and then sells it when compete, with no further efforts, then that could possibly work. But realistically what buyers are going to buy that? At best, they will do so only at a very discounted price. As far as users voting to tell the developer what to do (during ongoing maintenance), seems like a very gray area to me. Giving general guidance is probably not good enough as success may still depend "primarily" on the decisions made by developer. As a practical matter, making all the important design, development, and delivery decisions by voting of generally unskilled users seems unworkable (and possibly even voting by skilled experts). You may comply with securities law but you will violate the laws of successful software development. EDIT: Also, purely mined coins don't obviously fall within this definition because no money or other consideration is ever given to be used by the developer. (An alternative argument would be that the entire network, as opposed to development, is the enterprise, but then in that case one may question whether the developer has a "primary" role in its success; certainly users, investors, merchants, etc. have a huge role in the success of a currency network.) If the developer premines or instamines and the sells those coins, that begins to move closer.
|
|
|
It appears that whether the users think it is an investment or not, has nothing to do with the classification as a security. No. One and only one link on this thread. I'm getting back to work now. "According to the Howey test, an instrument is only a security if it involves an investment of money or other tangible or definable consideration used in a common enterprise with a reasonable expectation of profits to be derived primarily from the entrepreneurial or managerial efforts of others." http://www.legalandcompliance.com/securities-resources/securities-glossary/howey-test-to-determine-if-an-investment-is-a-security/That is why crowdfunding a movie does not violate securities law, or even a toy, watch, etc. where you get the item as a reward. Coins not so much.
|
|
|
The case law says that as long as the user has managerial control then whether you sold a product enabling the user to take control, then as long as the developer has had no control, then the user entirely culpable thus the shares in the product that was sold at ICO are not a security, because there is nothing backing it. It appears you are wrong in the case that the developer steers far from any managerial control throughout the entire process. You are, I think, attempting to thread a needle here where the "developer" is an employee or contractor for another entity where the other entry has all the control. The could certainly happen in some cases, but remember economic reality has a lot of weight, and can trump organization paperwork.
|
|
|
smooth your opinion is appreciated, but I would like to point it seems to be entirely based on opinion; whereas, I cited the law (in the USA and in the EU).
It is labeled as opinion and I wouldn't portray it otherwise. It is based on having digested reasonably credible analysis though. I don't feel like digging up actual links. You have a lot more patience for that than I do. Thus, it can certainly be reasonably disregarded for failure to provide supporting background material. However, if something about what I wrote seems totally unsupported (as opposed to being one of several differing views), you're probably missing something.
|
|
|
Too many options in the poll. I can't even figure out how to vote.
My opinion is that no one really knows since these laws are incredibly unclear, basically written to give maximum power and abusable discretion to regulators and prosecutors. ICOs seem like the most obvious and highest risk (the securities law issues arise before the coin launches at all). Trying to call it a crowdfunded product seems quite weak when there is obvious intent and expectations by nearly all participants to treat it as an investment (i.e. economic reality trumps fine print). I'm looking at you Ethereum.
Other cases become less clear. Plausible arguments could be made either way.
If you want zero risk, don't play. I'm pretty sure that is somewhat by design. The investments industry doesn't like disruption or competition from technological change, upstarts or scrappy independents.
In general I don't think stepping aside helps much. Whatever you did before you stepped aside is probably enough for culpability if money changed hands.
|
|
|
I am syncing Aeon 0.9.5.0 from scratch and keep getting stuck on block 64,952
Any clues why? I know there is a bootstrap I could use but I want to figure out why the daemon is getting stuck.
I've never seen that. If you or anyone are able to produce it please try with --log-level=2 and upload your aeond.log somewhere (suggest compressed) Just did a resync from scratch. It isn't done yet but it blew past 64,952 without any problem. Has already reported passing the 175500 checkpoint. 2015-Oct-23 18:16:59.643001 [P2P2]CHECKPOINT PASSED FOR HEIGHT 175500 <3f7dd748b3b863b04654d87a387f2b65a365f467188971f3192eab2368e64a35>
|
|
|
30.Nb2 Nxa1
Typo I believe
|
|
|
no MAID
MAID trades, right? I'm not familiar with it through, is that just some placeholder token with no features?
|
|
|
I just saw a quote by a user that Monero has an "opaque blockchain" which I don't think is correct. Monero has a private blockchain, in the the sender and receiver are always protected from knowing each other, but (correct me if I'm wrong here) the amount of money moving across the blockchain is still visible in some respects. If someone sent 300,000 Monero across the blockchain, then observers would be able to see that a large amount of money moved today but not be able to pin it down to a particular user or transaction time (with proper mixin settings)
I thought that with the new CT ring developments coming out, people wouldn't be able to tell what amount of monero is being transacted unless you have the right key which shows you the amount for that particular transaction? Wouldn't this be a non issue with the upcoming developments? In theory yes. It has not been implemented yet into monero so testing needs to happen over months to come. For now AP is right you can see how much is moved and when. But not who sent to who specifically. Also you can't really tell it moved between two people. Much of it could be change going back to the sender and it could be someone moving from one wallet to another. Above comments about CT are correct. However, even with CT, using math an observer can still verify that the coins spent are equal to the coins received. You just can't tell the number. This is assuming you have the "Amount Key"? No. The equality sum(in)-sum(out)-fee=0 is independently verified by every node or any observer without any key. To explain in simplified terms how this works, there is a random blinding term x, which is secret. Ignoring fee here for simplicity: hidden_in = real_in + x hidden_out = real_out + x Of course real_in - real_out = 0 But hidden_in - hidden_out = 0 i.e. (real_in + x) - (real_out + x) = 0 also hidden_in and hidden_out are visible on the blockchain. (Magic crypto math means that you can't do something silly to break this like solve for x.) Okay so because you know the outcome of the equation you can just verify the result and check to see if it lines up with what is expected without knowing the actual amounts transferred. Exactly! hidden_in and hidden_out are visible on the blockchain. To verify the transaction you subtract them and see the result is 0, which proves that real_in - real_out is also zero without revealing their actual value. That is oversimplified, but you get the basic idea.
|
|
|
dumps will still happen and be plenty if AEON makes bull runs.
Yes I'm sure this is true. It is a bit like CLAMs (you get get free CLAMs if you had DOGE, LTC, or BTC but you have to do some extra effort to get them) where higher prices motivate effort and coins will come out from hiding as the price goes up. This is okay it will help stabilize the value while gradually removing resistance as new highs are reached.
|
|
|
I just saw a quote by a user that Monero has an "opaque blockchain" which I don't think is correct. Monero has a private blockchain, in the the sender and receiver are always protected from knowing each other, but (correct me if I'm wrong here) the amount of money moving across the blockchain is still visible in some respects. If someone sent 300,000 Monero across the blockchain, then observers would be able to see that a large amount of money moved today but not be able to pin it down to a particular user or transaction time (with proper mixin settings)
I thought that with the new CT ring developments coming out, people wouldn't be able to tell what amount of monero is being transacted unless you have the right key which shows you the amount for that particular transaction? Wouldn't this be a non issue with the upcoming developments? In theory yes. It has not been implemented yet into monero so testing needs to happen over months to come. For now AP is right you can see how much is moved and when. But not who sent to who specifically. Also you can't really tell it moved between two people. Much of it could be change going back to the sender and it could be someone moving from one wallet to another. Above comments about CT are correct. However, even with CT, using math an observer can still verify that the coins spent are equal to the coins received. You just can't tell the number. This is assuming you have the "Amount Key"? No. The equality sum(in)-sum(out)-fee=0 is independently verified by every node or any observer without any key. To explain in simplified terms how this works, there is a random blinding term x, which is secret. Ignoring fee here for simplicity: hidden_in = real_in + x hidden_out = real_out + x Of course real_in - real_out = 0 But hidden_in - hidden_out = 0 i.e. (real_in + x) - (real_out + x) = 0 also hidden_in and hidden_out are visible on the blockchain. (Magic crypto math means that you can't do something silly to break this like solve for x.)
|
|
|
I am syncing Aeon 0.9.5.0 from scratch and keep getting stuck on block 64,952
Any clues why? I know there is a bootstrap I could use but I want to figure out why the daemon is getting stuck.
I've never seen that. If you or anyone are able to produce it please try with --log-level=2 and upload your aeond.log somewhere (suggest compressed)
|
|
|
(Even as it still remains a commodity in the US)
It is a currency, a commodity, or property depending on who is defining it. Each agency defines it to maximize its own jurisdiction.
|
|
|
Greece won't be allowed to default; it would've happened a dozen of times within the last 6 years of recession. Not on purpose no. Sometime accidents happen though. In 07 it was expected that a buyer could be found for Lehman, as is usually the case for large failing banks, but it didn't happen during that weekend and Monday TSHTF. That's how these crises occur usually, not by design. If something happens in Greece the details will be different but the outline will be the same.
|
|
|
|