1) To further clarify, the transaction does NOT instantly appear on the blockchain. If you're watching something like blockchain.info, they are running a NODE that picks up the transaction almost immediately. It doesn't get stored on the blockchain until "2)".
2) The block finder indeed confirms it is valid before adding it to its newly minted block, but every other NODE also confirms the transaction(s) is/are valid before accepting the newly minted block in its own local blockchain. Indeed, 100% of the nodes confirm the transaction (otherwise they would reject the block and get left behind), however, the network will continue to function properly as long as a majority of the hashing power has consensus. Other nodes can go their own way and reject the TX/block (creating their own fork), but no one will care; the "mishaving" node(s) will be left behind.
3) +1 to previous reply. Additionally, the "recommended" amount of confirms is 6 (5 blocks minted after your TX was included). However, the receiver is free to do whatever they want. Bitpay for example requires 0 confirms (pay for something at Newegg for example, and you'll see it say that your payment is accepted, usually within 1-5 seconds of you hitting "Send").
1) Great! You are right, my observation was based on blockchain.info that immediately picked up my transactions, the delay was literally less than a second. Does this mean that blockchain.info is running their own miner that picks up the transactions or is the NODE just a running wallet? 2) Makes sense, thanks! 3) Thx for the example, looks like Bitpay made an educated guess that the customer convenience economically outweighs the possible risk 1) It could be a miner or just a regular node. It matters not. All nodes process transactions and blocks, regardless of if they are mining, to verify that they are valid before including them in their local version of "the blockchain". Could this yield the last word on this? https://bitcoin.org/bitcoin.pdf   Such hard to understand. Wow. |
|
|
|
1) To further clarify, the transaction does NOT instantly appear on the blockchain. If you're watching something like blockchain.info, they are running a NODE that picks up the transaction almost immediately. It doesn't get stored on the blockchain until "2)".
2) The block finder indeed confirms it is valid before adding it to its newly minted block, but every other NODE also confirms the transaction(s) is/are valid before accepting the newly minted block in its own local blockchain. Indeed, 100% of the nodes confirm the transaction (otherwise they would reject the block and get left behind), however, the network will continue to function properly as long as a majority of the hashing power has consensus. Other nodes can go their own way and reject the TX/block (creating their own fork), but no one will care; the "mishaving" node(s) will be left behind.
3) +1 to previous reply. Additionally, the "recommended" amount of confirms is 6 (5 blocks minted after your TX was included). However, the receiver is free to do whatever they want. Bitpay for example requires 0 confirms (pay for something at Newegg for example, and you'll see it say that your payment is accepted, usually within 1-5 seconds of you hitting "Send").
1) Great! You are right, my observation was based on blockchain.info that immediately picked up my transactions, the delay was literally less than a second. Does this mean that blockchain.info is running their own miner that picks up the transactions or is the NODE just a running wallet? 2) Makes sense, thanks! 3) Thx for the example, looks like Bitpay made an educated guess that the customer convenience economically outweighs the possible risk 1) It could be a miner or just a regular node. It matters not. All nodes process transactions and blocks, regardless of if they are mining, to verify that they are valid before including them in their local version of "the blockchain". |
|
|
|
Bitcoin 101 question here on how exactly are crypto transaction confirmed - I know the basics - that miners confirm the transactions but I am still not clear on what exactly happens:
1) Let's say I pay my chocolate milkshake using BTC. The transaction instantly appears on the blockchain (X)- is this based on information from payer, recipient or from some independent miner processing the transaction? Are the miners processing the transactions before the block is finalised?
2) After about 10 minutes the transaction is confirmed along with all transactions in the same block. Now - who exactly confirms it - is it > 50% of the network? A randomly chosen miner? A miner based on certain criteria?
3) Since blocks are 10 minutes apart... is it possible to be lucky and have the transactions confirmed in just a few seconds if it occurs at the end of the block?
Wrong thread perhaps? 1) The payer broadcasts it to the network, which picks it up. 2) The miner mining the block confirms it 3) Yes, 10 minutes is just the average time. It can be confirmed in 1 second or 60 minutes. 1) To further clarify, the transaction does NOT instantly appear on the blockchain. If you're watching something like blockchain.info, they are running a NODE that picks up the transaction almost immediately. It doesn't get stored on the blockchain until "2)". 2) The block finder indeed confirms it is valid before adding it to its newly minted block, but every other NODE also confirms the transaction(s) is/are valid before accepting the newly minted block in its own local blockchain. Indeed, 100% of the nodes confirm the transaction (otherwise they would reject the block and get left behind), however, the network will continue to function properly as long as a majority of the hashing power has consensus. Other nodes can go their own way and reject the TX/block (creating their own fork), but no one will care; the "mishaving" node(s) will be left behind. 3) +1 to previous reply. Additionally, the "recommended" amount of confirms is 6 (5 blocks minted after your TX was included). However, the receiver is free to do whatever they want. Bitpay for example requires 0 confirms (pay for something at Newegg for example, and you'll see it say that your payment is accepted, usually within 1-5 seconds of you hitting "Send"). |
|
|
|
Well, many things happen, first your balance will be broken into denominations, like 1DRK, 10DRK, 100DRK, etc, this creates uniformity so that when you send a random amount, this amount is really the sum of many denominated inputs ok, my coins are now anonymised (just used the "Basic" setting for speed). If I call "listaddressgroupings" from the command line, I can see all the new anonymised addresses. Block explorer confirms the situation whereby my original address is empty and the "fragmented" addresses contain the anonymised coins. What I can't seem to find in block explorer is any link between the "anonymised fragmented" addresses and my original deposit address. Is that where the masternodes come in ? ... breaking that link and obfuscating it ? EDIT: Hey - I need to go and get some tapas and wine for half an hour. Will be back to this asap - looks like fantastic stuff so far. Thanks for all the help in the meantime. When your denominated funds are mixed by the masternodes, it grabs your and other's funds together and makes it into one big transaction that all of you group sign. This makes it equally likely that any of outputs could belong to any of the signers, thus the hard blockchain link is broken, and you're left with probabilities. |
|
|
|
Hey all! +1
Monero is an entirely new type of coin and needs it's [sic] community to be organized.
Perhaps we could contact Obama. |
|
|
|
Good news!
We have a new build v0.3.0.38(109f49c), where we finally started to prune ring signatures.
What is going on ?
New build prune ring signatures in all transactions that lay under height 70000 (new checkpoint).
When you launch new version, you could see that message(numbers would be little different):
How does it work:
1. When new version (v0.3.x, build 38 and older ) load blockchain from drive, it prune signatures from transactions under chekpoints after storage loaded from drive and before core start work.
2. When new version (v0.3.x, build 38 and older ) download blockchain via network from older clients (v0.2.x, build 37 and younger) it downloads full blockchain and prune transactions locally before put it into the storage.
3. When new version (v0.3.x, build 38 and older ) download blockchain via network from the clients with version v0.3.x it downloads blockchain with pruned ring signatures.
4. When old version (v0.2.x, build 37 and younger) will try to sync with client (v0.3.x) starting from height higher then 70000 (less than ~17 days ago) it will successfully synchronized
5. When old version (v0.2.x, build 37 and younger) will try to fully download blockchain from scratch from new clients (v0.3.x) they fail to do it, so you need to use new client. Or manually download scratchpad from website.
6. On handshake both peers figure out what checkoint height has other party, and consider it to figure out if synchronization is possible. If you see such messages in logs that also means that you have old version and should update your client. But it still work's properly.
Now, when new clients download blockchain via network from versions v0.3.x it looks like this:
Important: If you have version v0.2.x and by some reasons can't/don't want to update it to v0.3.x, and have to synchronize your client from height under 70000, you better to pre-download blockchain from website:
Windows blockchain: http://boolberry.com/downloads/windows/blockchain.bin
Linux blockchain: http://boolberry.com/downloads/linux/blockchain.bin
Well, we tested it, but it's still possible to have bugs, so i won't push update alerts for next few hours to collect feedback.
Let me know is something is going wrong.
Good luck!
Now we really live in the future Ty Zoidberg! Nice, should probably spell "signatues" correctly.  |
|
|
|
I'd like to get a feel from the darkcoin community about including you in the SuperNET coin group I'm creating. I anticipate it will bring in about 10,000 bitcoins to invest in select altcoins. Please post on this thread why you think DRK would be a good candidate. 1 post = 1 vote https://bitcointalk.org/index.php?topic=762346.0lol, why wouldn't the "real" jl777 post this question? |
|
|
|
I realize that the system has similarities. What I believe is novel is the (snipped) "nomination" system based on the hash of the block, the need for the nominated MNs to respond with blockchain-writable transactions within 2 blocks of being nominated, and the deterministic picking of a "winner" based on the responding MNs. This negates the need to maintain an off-blockchain "list" of active MNs, which I believe is what caused the forking problems in previous releases, where some nodes were rejecting blocks off of a belief that the MN receiving payment was not a valid MN, for whatever reason. You can see this in all the questions about "is my MN appearing ok?" It should not be possible for one person's list of active MNs to be different than another person's, yet I believe that this is what we still have today. "I'm seeing 850 active MNs but Joe sees 842" is a very difficult problem to solve, so my proposal moves all MN "activeness" into the blockchain where it becomes indisputable.
When MN payments were first introduced, forking occurred as the network propagation process could take longer than the blocktime. Since then the inter-MN comms are *much* faster. If I see 850 active MNs, you and Joe also see 850, any change is propagated within seconds at most. There will always be fringe cases, but that's what the voting system across multiple blocks is is for. It's critical for future services that MN's maintain comms discrete from the slow blocktime. I agree, but I don't think it's critical that they do so for payment (at least % of block reward payment) reasons. Agreed with luigi. The MNs can maintain their high-speed network, but the rest of the network (including miners) will always have propagation delays. Unless you do something like require all mining to be funneled through the MNs.... which wouldn't be a bad idea IMO. There can also be malevolent MNs, or incompetently-managed MNs, or MNs that are facing DOS attacks, or having other network or server issues. Counting on the MNs to be fast all the time will lead to failure, guaranteed. I think you/we should present this to the right people and figure out what, if anything, would prevent this from being the MN payment solution. |
|
|
|
|
3K. 3,000. Three thousand.
|
|
|
|
Attempted clarification in red. Hope it helps. Long underlying is always higher than any form of theta negative strategy.
could you please elaborate and clarify what you mean here ? thx! The underlying's chances of going up or down are wrapped around 50/50.
Let's consider directly at the money options for simplicity. Since all non-expired ATM options have extrinsic premium, the underlying's price must rise above (or below for puts) the B/E value given by that extrinsic premium in order to profit. Since there must be some nonzero chance that the underlying finishes between the strike and B/E, the option's probability of profit must be less than 50%.
Theta is just the measure of expected extrinsic (time) premium decay per day, having negative theta just means your position is net long extrinsic premium.I think you've really nailed it with the second bolded quote. Other people might not see it that way, particularly OTM call buyers. In the (unlikely) case of underlying --> moon, the long call always outperforms everything else.
same question here could you please clarify ? what is your metric to say that something out(under) performs ? The long call provides the highest expected return.Does underlying + Put k normally have the same risk profile as call k? Yes!
Is one of them therefore mispriced? Yes! (only time will tell; both could certainly be mispriced as well)
the mispricing here is clear because you can replicate the exact same risk profile for cheaper using the decorated put. If you could borrow BTC to build a position you could even reproduce the outright call to achieve the exact same leverage. But this is the essence of the matter. People don't loan you BTC for free.It should not go unnoticed that general sentiment in the XMR community is very bullish. Given normal put/call parity, long call is a superior position to married put.
same question as before, what is your criteria to say something is higher/lower, just leverage ? Yes. Also, in regular trading, it costs less in fees (by extension, selling a put is superior to a covered call).Risto is making people pay, which is his prerogative. With how bullish (some) people are, I'd even go as far to argue that it's more about long leverage than anything else. From that perspective, the XMR + Put position is actually the worst of them all.
for leverage metric yes, but again if you could borrow BTC the same leverage could be achieved. Same as above. I think you're underestimating the value of leverage.Contrarily, if you're just expecting lots of volatility (relative to IV of the put you'd be buying), then XMR + Put is the best position available (long straddle/strangle could be argued as well depending on your upside bias/vol expectation).
(I think you probably understand these things already, but others may not.)
not sure i understand this last statement, could you please elaborate a bit ? thx! If you think the IV (implied volatility) of the puts is lower than realized volatility will be (but that the calls' IV is on the mark or too high), you should go long XMR + Put. Note you must still have a bullish bias as you won't make any money on the downside. You could overhedge with puts and create some position you're comfortable with.
If you're confused as to strangles and/or straddles, a straddle is the purchase or sale of a call and a put at the same strike, while a strangle is the purchase or sale of a call and a put at different (usually both out of the money) strike. If you felt that call IV was way too low, you should just buy straddles/strangles.
|
|
|
|
Poloniex is registered with USA FINCen nationally as an MSB in the state of Montana.
If they stay in compliance, and don't get in hot water with the SEC, they should be OK unless the legal landscape changes.
True. But I think the "ICO" is very clearly in violation of the law. This creates a liability when they are sued by investors who lose money as a result. Well, it's almost certainly not "clearly" in violation of the law considering it's uncharted territory in general. I'm not qualified to argue the point, so I won't. But I think you would probably agree that it's a complex subject that would end up resulting in at a minimum serious debate between pro-freedom legal minds and those of the government(who might not even consider such offerings an issue). The closest thing that we've seen thus far is Erik Voorhees settling his case with the SEC after he sold his fully functioning company via shares on MPEX. The SEC very likely wasn't 100% sure they would be able to win in court considering he sold SatoshiDICE for something like 13 million dollars at the time, yet settled with the SEC for $50,000 if I remember correctly. And the only similarity here is that the shares were bought with cryptocurrency. The offering itself wasn't a cryptocurrency, unlike Qibucks which is. I don't think you can really compare decentralised cryptocurrency offering to securities, but I might be wrong about that and perhaps the SEC does see it that way. My gut feeling is that they don't, but Poloniex's lawyers will be the final word on this, and I hope things will continue as usual in our community without the ever present gaze of the SEC or any other governmental agency disrupting what's being built. There have been several IPO/ICOs already. QBK is just a recent one. There was LCL (Limecoin Lite), XBC (Bitcoin Plus), MIL (Millennium coin now), as well as those mining shares if they count. People definitely lost money on them (the IPO/ICOs) as well. |
|
|
|
Of course XMR + Put is superior from a probability of profit standpoint (as shown by your lengthy explanation of put/call parity), but naked XMR is better still. People aren't (as far as I can tell) buying calls based on POP, they are buying them for the leverage. In this case, it's quite costly.
XMR + Put is equivalent payoff to Call + BTC as i have argued. Naked XMR is neither better nor worse from profitability perspective, it's just a different risk profile. XMR has downside risk that the Call payoff does not have. My point was just to say that the *optionality* of the call option is much cheaper if you buy it through Put + XMR instead of buying the outright calls. With regard to leverage it is true that a *naked Call* is higher leverage than *XMR + Put* however the premium you pay on the optionality does not justify it in my eyes. For the same reason, the break-even level for XMR + Put is lower than the naked Call. Therefore, if someone is a bit short on capital AND really want to play options AND wants to target maximum leverage they should probably buy a combination of Call, Put and XMR to optimize their break-even/leverage metrics. [bolded quotes] I understand. I was not talking about things from a profitability perspective, only probability of profit. Long underlying is always higher than any form of theta negative strategy. I think you've really nailed it with the second bolded quote. Other people might not see it that way, particularly OTM call buyers. In the (unlikely) case of underlying --> moon, the long call always outperforms everything else. Does underlying + Put k normally have the same risk profile as call k? Yes! Is one of them therefore mispriced? Yes! (only time will tell; both could certainly be mispriced as well) It should not go unnoticed that general sentiment in the XMR community is very bullish. Given normal put/call parity, long call is a superior position to married put. Risto is making people pay, which is his prerogative. With how bullish (some) people are, I'd even go as far to argue that it's more about long leverage than anything else. From that perspective, the XMR + Put position is actually the worst of them all. Contrarily, if you're just expecting lots of volatility (relative to IV of the put you'd be buying), then XMR + Put is the best position available (long straddle/strangle could be argued as well depending on your upside bias/vol expectation). (I think you probably understand these things already, but others may not.) |
|
|
|
Found this article, is this all true? 1. DarkCoin claims to be an anonymous cryptocurrency Let’s get one thing straight from the very beginning – DarkCoin is NOT an anonymous digital currency. It uses a special feature known as “darksend”, which is basically a protocol that labels transactions in a way that the destination and the source of the coins are vague. Darksend doesn’t provide complete anonymity, though. At best, it offers pseudonimity. DarkCoin use unscrupulous methods to promote its coin, and it won’t hesitate to promote it by using deceptive buzzwords; they labeled the coin as groundbreaking and completely unique, which is not. Apparently, at this point DarkCoin is as anonymous as Bitcoin. Old and also wrong. 1/5
2. DarkCoin uses Darksend, a closed source, totally unoriginal Darksend claims to be a unique DarkCoin feature, but it’s not. It was not developed by Evan Duffield, the lead developer for DarkCoin. It is solely an implementation of a CoinJoin specification created by one of the most important developers for Bitcoin, Greg Maxwell. To make things worse, Darksend is not an open-source because it’s not completed yet. This goes against the basic principles of the digital currency movement. What did they think, that the users will not notice? Correct in being closed source. Old and incorrect in reference to gmaxwell being the sole creator. 2/5
3. DarkCoin can’t ensure payment anonymization DarkCoin has a lot of limitations, and that can only mean it can’t be trusted. While we can agree that it created a hype and made a lot of people curious, it’s definitely “dark” in nature. It uses “masternodes” that support darksend transactions. Recently, a bug implemented in the code stirred things up in the network, triggering continuous fork and making the coin nonfunctional. To fix this issue, a hardfork was required. Evan Duffield is well aware Darkcoin has limitations; however, he’s not concerned at all because the coin is extremely good at creating hype. Hype triggers price appreciation and thus, coin holders are the main beneficiaries. Are they creating a cryptocurrency or specialized PR? First part is old and very poorly written regarding what actually happened. The part about hype/hyping is silly. 1.5/5
4. Subsidy reduction and tremendous instamine DarkCoin has tremendous instamine linked to it. In the initial 15 hours, between block 1 and block 4000, there were created nearly 1.75m darkcoins. When the IekNpA1 period ended, Duffield claimed that the block reward calculations had a “bug”; to address it, he issued a hardfork, which led to a decrease in the block reward. The result: 80,000 blocks yet there’s only 4.3 DRK out in the open. 5 months later, 1.75m produced during the first 4,200 blocks still accounts for 40% of all existing DRK. Sorry for the ones mining after first 15 hours. Old news, but still a relevant part of the history of the coin. Last sentence is garbage though. 4/5
5. Shady beginnings DarkCoin started as XCoin, and for many it looked like a scam. It was launched without having a working windows client and mining the coin was really difficult. The ideal candidates to mine the first 4,200 blocks were, of course, Duffield and his associates. It looked like that “bug” we just mentioned was intentional. It allowed the developer to mine a huge number of coins for his own personal use, in a desperate attempt to shun the negative stigma linked to obvious premining/instamining. The users from outside of Duffield circle might have the feeling they are on the party they were not invited to. Perception/opinion/hearsay. 1/5
6. Inexplicable problems Darkcoin experienced a lot of problems since its creation, and many users didn’t like this aspect. The “masternodes” were just implemented and used to “mix” the darkcoins, thus making transactions totally anonymous. Those who owned 1 masternode received 10% of the block reward, each time their masternode was selected. This could have been extremely profitable, if the user didn’t have to pay 1,000 darkcoins [LOL?] ($10,000) to set up their own masternode. DarkCoin was forced to change its code to use masternodes, and they performed a controlled fork of the block chain to attain their goal. Everything went smoothly for a couple of hours, after the masternodes started working; however, the Darkcoin blockchain fissured into many forks due to some “bad” masternodes. Another “helpful” solution to make the coin even less convenient. Old, garbage, wrong, disingenuous, and other things. 0.5/5
eI9t28P7. Blockchain forks are bad for digital currency Are you ready to lose your darkcoins for good? Because with DarkCoin, that may happen. Sending DarkCoins during the fork can be extremely risky. Users may lose their darkcoins forever if they send them on the wrong fork. In the end, 1 blockchain will receive recognition, and if your coins wind up on a different blockchain, they will vanish. There are many reports with darkcoins fading from mining pools, considering that the pools were mining on a wrong fork. The exchanges took a hit as well, considering that DarkCoin deposited from wrong forks were confirmed initially and vanished afterwards. At least they are helping the users to practice their accuracy, thoroughness and conscientiousness. Utter garbage. Senders don't lose coins in forks. Receivers (aka exchanges) could, but it would be unusual and typically the result of a deliberate attack. It certainly didn't happen during the mini forks that occurred back when mainnet enforcement was switched on. 0/5
8. The Darksend issue Darksend is a DarkCoin technology employed to surpass a deficiency which is not a main concern for 99% of users, and apparently it can be fixed with an easy proxy protocol analysis, since the root of the problem is IP tracking. However, Darksend is limited to 10 DRK. It needs 3 parties to mix up the coins, and since it is in beta stage, it is limited to 10 DRK. It is like using a Kalashnikov to kill a fly. The "root of the problem" is not IP tracking. A portion of the problem is IP tracking. The rest is outdated or wrong. 1/5
9. Unexpected price drops For connoisseurs, these drops were expected, especially since it was obvious from the very beginning, that DarkCoin was unreliable. DarkCoin prices dropped when information about the fork was revealed. It went from 0.025 BTC per DarkCoin ($14.50) to 0.016 BTC per DarkCoin ($9.35). This 36% reduction was drastic, and it led to frozen markets for withdrawals and deposits. Is the tendency completely random or just decreasing? Irrelevant. 0/5
10. Disappointing statistical reviews – things are not looking great for DarkCoin. Here’s why:
Energy Efficiency — Partial
51% protection — Partial
Stability in prices — Partial
Compress protocol — No
Fast confirmation times — No
Prevent instamine — No
Expansion Scope — No
Transaction comments — No
No or less transaction fee — No
Anonymous Payment – No
Point 10 is just gibberish. Who can make sense of it? 1/5
This piece deserves a solid F-. |
|
|
|
now bare with me for a minute [...]
*Raises hands* Whoa, whoa! Ok there! Let's start again. ("bare" vs "bear" for those who don't get it) |
|
|
|
dear all, for those considering buying call options be aware of the following fact from options. in the case of european options (which are options that can only be exercised AT maturity and not before) there is something called the "put/call parity" which states that for a call Ce and put Pe striking at K and if the forward is called F (with the same maturity as the one of options) one has (in absence of discounting which is ok assumption given that we are talking about 1 month options and interest rates are so low) Ce - Pe = F - K now since we are talking about american options it's true that the previous relation does not hold however the following can be said. As mentioned above the early exercise opportunity for the american call is worthless in the absence of dividend yield, so the calls ARE european options. For the puts, given that interest rate are so low there's hardly any chance to be willing to early exercise, but let's not even say that and assume that the american put Pa has a higher value than the european put. So Pa > Pe then one has Pa > Ce - F + K which is equivalent to saying that Pa + F > Ce + K in the absence of dividend yield or interest rate the forward value XMR/BTC should not be different than spot which is about 0.0043 when i am writing this (for those unaware, the forward value of XMR/BTC has nothing to do with the "most likely value" of XMR/BTC in one month time! so it makes perfect sense that the fair forward rate XMR/BTC in 1 month is the spot value today even if your are super bullish on XMR  ). why did i say all of this ? just to make you aware that if you buy a Put and buy XMR/BTC spot you will effectively construct for yourself a position that is even more valuable than a synthetic position K + Call. why is it interesting ? because if you look at the current market prices displayed you will see that for the Sept maturity call with strike K=0.004 you can easily see that you could save close to 0.001 compared to buying the outright call that is sold for 0.00210 It is not possible to arbitrage rpietila because he is not providing a 2 way market however you see that you can still easily save you substantial money by buying puts + spot instead of calls sorry for the long post, happy to elaborate if you have more questions about options!! DISCLAIMER: i have no xmr holding and do not intend to build one in the next 72hours  i am just interested in seeing how this experimental option market will turn out! Of course XMR + Put is superior from a probability of profit standpoint (as shown by your lengthy explanation of put/call parity), but naked XMR is better still. People aren't (as far as I can tell) buying calls based on POP, they are buying them for the leverage. In this case, it's quite costly. |
|
|
|
XMR > BTC in 2015 !!! Not possible  It's possible, but I am much more conservative in my speculation: XMR > BTC in 2015 2017!!! If we make it XMR > [BTC today ~$500], then 2017 sounds nice. If we're talking about XMR/BTC rate, I doubt that'll be happening that soon. |
|
|
|
Is simple as this, if 50% of XMR would be minted in first month, few people would buy them and hold and price would go x10 or x100 in few months and not many people would got into coin at all, community would be weak. And some other coin would take XMR spot. As it is is perfect since will keep coin at low price for longer period of time + noone got coins super cheap. What you think is better is at quite some other coins, so i think is better you chose those.
This is kinda nonsense, as you are pretty apparently comparing to DRK (at 50% of current supply, which isn't even true anymore), but their community (of which I am a part as well) is quite big and active. They have the longest thread in the entire altcoin section. The other part of it is, absolutely some people got XMR at super cheap prices. I was one of them. You are spot on about fast emission keeping price relatively low for early adopters/accumulators. I did not meant any particular coin. You said that emission curve of Monero is bad and would be better if would be more mined at early start. I told you there are 100 of such coins already. And i told you that is really bad for the coin. Emission curve of Moreno is perfect. Today 4 months after start, daily gets mined almost same amount of coins as on first day. Is perfect as it is. Super cheap Moneros would be bought at 0.00001BTC or mined at that cost. Or even cheaper. Coins with emission curve as you said you want to have for Moreno have such cases. Not many Moneros were traded under 0.001 BTC. Compared to whole trade volume of past 4 months are not worth of mentioning. And About DRK and its community. I dont know really DRK emission curve, I dont know how strong community is. I dont know when was coin launched. But if emission curve is as you wanted for Monero, then at time when Monero will be as old as is DRK right now, Monero community will be way stronger and compact then DRK community is now. I don't think I said that at all. I said it rewards early adopters, but it then becomes opinion on what's good/bad. I didn't give one. |
|
|
|
I realize that the system has similarities. What I believe is novel is the (snipped) "nomination" system based on the hash of the block, the need for the nominated MNs to respond with blockchain-writable transactions within 2 blocks of being nominated, and the deterministic picking of a "winner" based on the responding MNs. This negates the need to maintain an off-blockchain "list" of active MNs, which I believe is what caused the forking problems in previous releases, where some nodes were rejecting blocks off of a belief that the MN receiving payment was not a valid MN, for whatever reason. You can see this in all the questions about "is my MN appearing ok?" It should not be possible for one person's list of active MNs to be different than another person's, yet I believe that this is what we still have today. "I'm seeing 850 active MNs but Joe sees 842" is a very difficult problem to solve, so my proposal moves all MN "activeness" into the blockchain where it becomes indisputable.
When MN payments were first introduced, forking occurred as the network propagation process could take longer than the blocktime. Since then the inter-MN comms are *much* faster. If I see 850 active MNs, you and Joe also see 850, any change is propagated within seconds at most. There will always be fringe cases, but that's what the voting system across multiple blocks is is for. It's critical for future services that MN's maintain comms discrete from the slow blocktime. I agree, but I don't think it's critical that they do so for payment (at least % of block reward payment) reasons. |
|
|
|
What happened is: Bytecoin (BCN) took a launched a new currency and completely butchered it. They made it into a premine scam to make it easy money. TrueFunny thing is: It's actually good tech, and they could have made a killing in scene, but instead they went for the easy buck. TrueThe Monero (no affiliation with the BCN team) team forked this scam. Cleaned up the code and relaunched in fair way. What?The blog writer (who writes here under the name 'dga') is quite pro-Monero. You can read his post history yourselves. All the negatives was related to BCN. This is a bit of a stretch, but you can have it.Sorry to bring this back up here, but you should really get your facts straight. The XMR team did NOT launch XMR (Bitmonero at the time), thankful_for_today did. And he was absolutely a member of the BCN team. The project was taken over by the community (the "team", if you will), but they absolutely did not "clean up the code and relaunch", they went with what they had (dropped the BMR name and went with MRO, then XMR, but it's all the same coin). To Macno, I'd argue this is neither positive nor negative. It's just Dave blogging about history. |
|
|
|
Assume the same address could initiate a stop command in a future block to not have his old MN clutter up the payments by never responding. However, I don't see any incentive for people to do this, so there needs to be some mechanism where the block finder can insert the stop message on behalf of the masternode. You might think the lingering nodes wouldn't be an issue, but something absolutely has to be able to issue a "stop" command in case the 1,000 DRK move. Unless you could possibly modify the protocol to have nodes reject any tx formed out of the 1,000 DRK input without a "masternode stop" command included in a prior block? If you allow for removal after X number of missed pings, you have the (tiny) vector of the block finder being able to remove a masternode if he found the right blocks, but I don't know of any incentive to do this. Well, no, I think you're over-complicating things here. There are really kind of 2 lists: one for "valid" MNs and the other for "active" MNs. By creating an initialization transaction and putting it into the blockchain, a MN declares itself as "valid". It remains "valid" for as long as the 1000 DRK does not move. This means that it is *capable* of being nominated and receiving payment, *if* it proves itself to be "active". Upon nomination by block n, it has to ping back in or before block n+2. This proves it as being "active" and eligible for receiving payment in block n+3. A MN maintains its "active" status as long as it keeps responding to all nominations with pings in a timely manner. If a MN does not respond in time to a nomination, it will be marked un-"active" until the next time that it responds to a nomination. That "activating" ping will bring it back to the "active" list, but it will not be eligible for payment in that block because it was non-"active" for the previous nomination. And again, all of this information will be 100% determinable in the blockchain. Yes, I believe you are correct. It just wasn't appealing to my OCD I guess (that it appears the initialization commands could be left "hanging" with no closure as it were; the closure would just be nodes not seeing it as valid anymore, which should be fine). Elegant and simple. Good talk. |
|
|
|
|
Show Posts
