That video is wicked cool! Wow. Had to share it on Facebook.
The vid is also good in showing to others that monero development is ongoing, its far from dead, many ppl help, and is constantly evolving. The Monero bears and shorts will get to play until 0,9 is out. After that all bets are off. Wht do you mean. Beta of 0.9 for windows is available for a while. What would change for bears and shorts if 0.9 becomes stable? I mean tagged and official for download from https://getmonero.org/downloads/. What changes for the bears and shorts is that the development work that has been going on for well over 9 months is released officially. It also means that the process for the necessary hard fork is started. I'd add that many people are routinely confused about the state of the code. It is easy for us who are basically all insiders here to say that we know all about 0.9, we've tried the Windows beta and github source, etc. But with some frequency people download the 10-month old binaries, and report various problems with them only to be told to try one of the newer ones. It can't be known how many people evaluating it never ask for help and just give up after seeing the state of that old release (or do ask, are given that advice, but decide it is too much trouble and give up), but it is logical to assume that a large fraction do. So smooth, what's holding up releasing new binaries? Is there some crucial feature that remains to be implemented? Who makes the call as to when the code is ready? |
|
|
|
its all a bit pie in the sky but I can see this kind of price action giving people a real hard time!
How do you respond to Burt W's objections regarding the implausibility that so large a fraction of the world's electricity supply would be diverted to mining? Bitcoin to the moon means electricity price to the moon. efficiency of mining keeps increasing, however, difficulty is increasing as well. In March 2014 antminer S1 was producing 0.08BTC/day while hashing at 178GH/s In October 2015 antminer S7 is producing 0.04BTC/day while hashing at 4860Gh/s So, in mere 19 mo, hashing speed of the consumer machine increased ~27-fold. Efficiency per watt went from 2 to 0.25-an eightfold increase in efficiency. However, difficulty increased ~54-fold, making the best (so far) machine to produce just half of what it's predecessor did 19 mo ago. This is the Burt W post I was thinking of: https://bitcointalk.org/index.php?topic=720179.msg8135635#msg8135635We cannot/do not want to get to $500,000 per BTC any time soon. Here is the math behind it: https://bitcointalk.org/index.php?topic=694401.0If BTC were to go to $500,000 in this era it would cause a catastrophic mining bubble: $500,000 x 25 = $12,500,000 per block = $75,000,000 per hour $75 million per hour would drive the mining to attempt to use 675 GW. This is about 30% of all the power generated on the planet. So, in order to keep our power consumption under about 2% of world wide power production, we cannot/do not want the price to get to $500,000 before era 6, which is about 2033 or so. Using my previously derived formula for the power consumption: P = (6(50/2 e) + f)(x)(1 - g)/c [kW] where: x = exchange rate [USD/BTC] e = era [0..32] (we are currently in era 1) f = average fees per hour [BTC/hour] c = cost of energy [USD/kWh] g = average gross profit margin [unitless ratio] we can look at the power consumption in each era assuming a price of $500,000 per BTC. In order to make it simple I will make the following assumptions: x = $500,000 per BTC f = fees per hour will keep the coinbase above 6 BTC/hour (1 BTC/block) in all eras c = $0.10 per kWh g = 0.1 miner gross profit margin Original target Subsidy Est Fees Power % of total world
Era starting year BTC/block BTC/hour GW power production
--- --------------- ----------- ---------- ----- ----------------
0 2009 50.00000000 0.00000000 1,350 58.41%
1 2013 25.00000000 0.00000000 675 29.20%
2 2017 12.50000000 0.00000000 337 14.60%
3 2021 6.25000000 0.00000000 169 7.30%
4 2025 3.12500000 0.00000000 84 3.65%
5 2029 1.56250000 0.00000000 42 1.83%
6 2033 0.78125000 1.31250000 27 1.17%
7 2037 0.39062500 3.65625000 27 1.17%
8 2041 0.19531250 4.82812500 27 1.17%
9 2045 0.09765625 5.41406250 27 1.17%
|
|
|
|
its all a bit pie in the sky but I can see this kind of price action giving people a real hard time!
How do you respond to Burt W's objections regarding the implausibility that so large a fraction of the world's electricity supply would be diverted to mining? Bitcoin to the moon means electricity price to the moon. |
|
|
|
to me personally there is also the fact that some comments from fluffy are disturbing(at least to me, maybe its also the language), like the quote about zerocash. to me sometimes it seems like he allready made up his mind about how "a lot of people are going to lose a lot of money".
I think fluffypony is referring to early adopters of Zerocash, who would be risking the loss of their funds should flaws be found. He's not talking about Monero holders losing money. |
|
|
|
|
Is Monero compatible with Zerocash? Would Monero + Zerocash have advantages over Bitcoin + Zerocash?
|
|
|
|
|
We've seen recently how discord between developers and also between factions in the larger community has slowed Bitcoin's development (and perhaps depressed its price), affecting the entire cryptocurrency sector. Monero's politics is more opaque. Here are some questions:
1. Do the XMR devs get along?
2. Do they share a vision for Monero's future?
3. Are there significant points of technical disagreement?
4. Does everyone agree on the development path (for example, that code review and optimization should precede "official" GUI development).
5. Does everyone agree on Monero's "governance model"?
The answers will influence Monero's probability of success and its price.
|
|
|
|
That is all they got in the 0.022 years since the 8 MB XT code was released. They have only 316'000 minutes left before the end of the year. What a flop. That's if we're to assume all these nodes are in actual XT-nodes  notbitcoinXT doesn't make any sense. if blocks are stamped with bitcoinXT, they contribute toward the 75% supermajority, correct? why would anyone opposing XT want that supermajority activation triggered? I lack the programming skills to see how this would slow XT adoption. It would reduce the confidence miners considering adopting XT have that they will end up on the supermajority side of the fork. The fork may be triggered prematurely when only a minority of miners are really interested in XT. |
|
|
|
Thanks dEBRUYNE and double-thanks fluffypony.
Trying out the beta now, will report back any issues I might have (or on IRC if it looks lengthy for whatever reason).
Whats this i here about a new beta? Is there an OS X beta? |
|
|
|
ummm, merely an attempted coup at this stage ... and pretty pathetically transparent power grab dressed up as "helping all the things". It's the latest "color revolution." |
|
|
|
|
Just recompiled the latest version of bitmonerod; it's running very smoothly on OS X, without the libunbound errors on startup from a week ago. Great work, devs!
|
|
|
|
I cloned and compiled the latest code from github and sync'd the daemon overnight on a new VM. I ended up with an 11G data.mdb file.
My data.mdb is 13GB (on OS X). |
|
|
|
When the market is ready--that is when enough strong hands hold most of the bitcoins, small amounts of demand buying into very little selling can push the price by large amounts. That means a strong surge up but not necessarily parabolic. The market has more price discovery mechanisms now (futures, margin trading, etc) than in 2013 so the rise may not get past $1000 until next year. I'm anticipating a move to $400-$500 in the coming months though--the price has bottomed and wound itself up for at least that much Another thing that has changed since 2013 is the proliferation of altcoins, some of which are compelling enough to steal mindshare and capital from Bitcoin. |
|
|
|
Not sure if this is the right place to report this, but have compiled the new version of bitmonerod on a mac and converted the blockchain using blockchain_converter. The problem is I have to run bitmonerod twice (exiting the first run with ^C ^C) in order for it to work. The first run after opening a new Terminal window always hangs, displaying two libunbound error messages during startup: http://pastebin.com/WPQqaRG6. Oddly, the second run sometimes has one libunbound error message and sometimes none, but it works (as long as there are not two). Hm, I seem to remember having some hiccups like that too but I forgot about them because they eventually just disappeared without me doing anything (knowingly) to correct the issue. What version of OSX? Yosemite (10.10.4). Another tiny bug is that typing help in bitmonerod sometimes causes it to hang. (Help works fine in simplewallet, though). Overall very impressed with the improvements. |
|
|
|
When was the last time tacotime did anything remotely related to monero? Serious question. EDIT: Why not call the smallest Monero denomination... a Nero. I would appreciate an answer to this as well. At 2am today (my time) -
[01:53:09] <tacotime> https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-03#section-5.6
[01:53:36] <tacotime> there's a step where you get r from SHA-512(prefix || M)
[01:54:10] <tacotime> where prefix is SHA-512(secret)[32:64]
[01:57:48] <tacotime> (the first half of the prefix is used to generate the scalar to use as a private key)
[01:58:08] <tacotime> my question is, can't prefix be anything and the won't the signature still be valid if it is?
[01:58:21] <tacotime> and is there any reason that doing this would be dangerous?
[01:59:27] <tacotime> i realize that if you use a bad value it might be like choosing a bad K in general
[01:59:38] <tacotime> but if your value is securely chosen, is it safe?
[02:34:26] <tacotime> and also
[02:34:26] <tacotime> is it possible to construct hd keychains from ed25519 private scalars? i don't really thing it is because there are four required bits that need to be set for an ed25519 scalar to be valid in terms of generating a signature
[02:34:26] <tacotime> i kinda wonder if there's a way around that though
[02:34:29] <tacotime> normally for an hd keychain you += hash(pubkey || index) to both the private scalar and public point
[02:35:38] <tacotime> so to get priv_i and pub_i
[02:36:06] <tacotime> priv_i = (priv + hash) mod N
[02:37:17] <tacotime> pub_i = (pub + scalarbasemult(hash))
[02:38:16] <tacotime> and how come monero doesn't run into this issue when it generates private keys through ecdh? does monero allow these scalars to be legal with the bits set anyway?
[02:38:37] <tacotime> because you'd expect 1 in every 2^4 scalars for any given derived keypair to be invalid
[02:38:42] <tacotime> but i'm probably missing something
[02:59:03] <tacotime> okay i figured out the zeroing out of the 3 lsbs
[02:59:12] <tacotime> that's just *= the cofactor
[02:59:29] <tacotime> but you do need one bit to be set in the private key for it to be useable, right??
[03:00:22] <tacotime> so when you ecdh a corresponding secret to the recipient, how can you tell with 100% certainty that the private key they will derive has a single set bit in the 254th position??
So 2am is taco time? |
|
|
|
Not sure if this is the right place to report this, but have compiled the new version of bitmonerod on a mac and converted the blockchain using blockchain_converter. The problem is I have to run bitmonerod twice (exiting the first run with ^C ^C) in order for it to work. The first run after opening a new Terminal window always hangs, displaying two libunbound error messages during startup: http://pastebin.com/WPQqaRG6. Oddly, the second run sometimes has one libunbound error message and sometimes none, but it works (as long as there are not two). |
|
|
|
|
Thanks Saddam, very helpful.
|
|
|
|
|
Show Posts
