rpietila Altcoin Observer

[smooth]

Okay so Cryptonite retains GUIDs for at least the 'lockheight' (a blockchain length) allowance so the replay attack can't occur within that allowance. One side-effect of this slightly kludgy design decision if your transaction isn't included in a block before the allowance, then it is invalid and you will need to resend it. However, I assume they are keeping weeks or months of transaction history “in view” so shouldn't be an issue. Even at micro-transaction scales, this extra tx header data doesn't add more than 40 bytes per tx with sufficient collision resistance for the txid.

They are keeping two weeks currently. There was a bit of breath holding when the coin passed two weeks in age and switched to truncated blockchain mode, but everything seemed to work.

[smooth]

There is just so much money invested in scrypt asics, and most of them haven't seen the light of day

And some of them probably wont ever would be my guess.

that I think it will have another boom cycle (and an accompanying boom in the number of tx/day). But who knows...

Hey its always possible. But even scrypt doesn't just mean LTC any more. It is still a big part of the scrypt space, but much less than it used to be.

[AnonyMint]

I don't have time to read this thread, so I don't know if this has been pointed out already. In our upthread discussion about Cryptonite and the MBC (mini blockchain), I failed to point out that the unscalable (without centralized mining) Bitcoin blockchain (and worse for Monero) can never be pruned because it relies on GUIDs to prevent double-spend replay transactions (or am I unaware that Bitcoin's tx GUID somehow incorporates the block hash?). If anyone is aware of a solution for that please let me know. Because I think it is major vulnerability of the MBC. Has Cryptonite addressed it in some way?

Their white paper says this:

In order to make sure the same signed transaction isn't processed by the network more than once, the block header must also contain a “lockheight” field. The transaction becomes invalid once the lockheight is outside the range of blocks which nodes are required to keep (lets call this the blocks “in view”), and same txid cannot be included twice in any of the blocks which are in view. This makes it impossible to use the same txid twice. However this solution requires that the txid is not malleable.

I think block header there is a typo...should that be transaction header?

Definitely should be 'transaction header'.

Okay so Cryptonite retains GUIDs for at least the 'lockheight' (a blockchain length) allowance so the replay attack can't occur within that allowance. Off the top of my head, I assume one side-effect of this slightly kludgy design decision if your transaction isn't included in a block before the allowance, then it is invalid and you will need to resend it. However, I assume they are keeping weeks or months of transaction history “in view” so shouldn't be an issue.

Edit: Pruning Bitcoin's txids won't require that transactions include this block chain length expiration field, because address reuse can't create a duplicate txid. The txid in Bitcoin is not a nonce rather the hash of the transaction which contains the output being spent, i.e. there is no way to reload an address with a duplicate txid, because all transactions are iterative hashes of hashes of hashes (etc) of the historical tree of preceding transactions history feeding the input.

Thus it is appears I was incorrect originally and Cryptonite's 'lockheight' field is unnecessary if they've implemented txids the same as for Bitcoin. Apparently for space efficiency they may have implemented txids as nonces instead of hash of the transaction?

one feature lost is the ability to sign a transaction and hold it indefinitely before sending to the blockchain network. I can't think of any practical need for such a feature, can you? Silly me, then the balance being spent could be double-spent before you could send to blockchain, so there is no use for the lost feature.

I suppose multi-sig is not adversely affected, because for one reason they need to complete within the retained transaction history. And for another reason I suppose multiple signatures are multiple layered transactions. But I guess it can affect multi-sig in that if you want to retain the tx history indefinitely until all the dependent sigs complete, then 'lockheight' can't be known a priori. However, setting 'lockheight' to weeks or a month is probably sufficient since a block doesn't have to be pruned once its 'lockheight' expires.

[smoothie]

Here is the 6-hour resolution chart of the LTC/USD currency pair from the BTC-e exchange. Note the two down legs of the great capitulation of 2014. Prices fell 28% in two days from $6.865 down to $5. Then fell another 30% from $5 down to $3.5. From the November peak price at $48.48, litecoin prices have fallen 13.85x. This is a more dramatic bubble run-up and collapse than the great bitcoin bubble of June 2013.

These litecoin prices have fallen to approximately twice the pre-bubble valuation and thus are very tempting, insofar as the analogy to the great bitcoin bubble holds . . .

June 2013? I don't remember that. 

[smoothie]

These litecoin prices have fallen to approximately twice the pre-bubble valuation and thus are very tempting, insofar as the analogy to the great bitcoin bubble holds . . .

Unlike BTC, there is no reason to expect increasing LTC adoption.

This was said in 2011, 2012, and 2013...

Yet things have not been further from those statements in those respective years those statements were made.

[itod]

There is definitely increased BTC adoption going on. There is real growth in retail acceptance and some other categories such as travel, and some real startups doing interesting things and building out meaningful capabilities that didn't exist before such as remittances, bitcoin debit card, new investment vehicles coming soon, etc. Whether that is a reason to buy BTC speculatively is a question only an investor can decide.

This is an easy question to answer. Growth in BTC retail acceptance is a great incentive for BTC price drop. People are not buying bitcoin to spend them immediately, all those spent BTC are from longer term holders. It's obvious what retailers do with BTC they acquire: they drop them on the exchanges that same moment through BitPay or other payment processors. I believe this is one of the main reasons for current drive towards lower BTC price.

Hoping the LTC will rebound from this enormous drop like BTC did in the past is very optimistic IMHO. It may, but it's very unlikely. BTC is not in the same league with LTC, there were reasons why it recovered which doesn't apply to LTC at all, but you can never be certain how things roll out in crypto.

[thefunkybits]

Monero XMR seems to be one of the only alts in the green today....


0.01 plez 

[smooth]

This is an easy question to answer. Growth in BTC retail acceptance is a great incentive for BTC price drop. People are not buying bitcoin to spend them immediately, all those spent BTC are from longer term holders. It's obvious what retailers do with BTC they acquire: they drop them on the exchanges that same moment through BitPay or other payment processors. I believe this is one of the main reasons for current drive towards lower BTC price.

I agree but I argue this is a short term effect and since retail has been going on for a while a some of that is already played out.

I don't agree that the goal is people buying BTC in order to spend them. That would be just neutral (since the retailers would generally just sell). The goal is for more people to recognize the coins as valuable and accept them as such. This requires there be useful ways to spend them, which is why retail is contributing to the growth of bitcoin despite the inevitable short term price pressure.

But this is somewhat off topic for the Altcoin observer thread so perhaps we should conclude this discussion soon.

[Majormax]

That's exactly why an 80% drop now for LTC means a lot more than a 70% drop in BTC back in 2012. In 2012 when activity picked up again, it was almost entirely going back to BTC. Any increase in activity now won't be going back to LTC. There is simply no reason for that to happen. There are many more and better alternatives to LTC now.

OK, I see your point. I agree there are better alternatives, but I still feel like LTC has at least one more giant pump before (if) it dies a long slow death. There is just so much money invested in scrypt asics, and most of them haven't seen the light of day, that I think it will have another boom cycle (and an accompanying boom in the number of tx/day). But who knows...

Would those script ASICS be specific to LTC ?  .. or would LTC possibly become the 'byproduct' of a merge mine for a better alternative coin (thus depressing its price further).

[coinsolidation]

That's exactly why an 80% drop now for LTC means a lot more than a 70% drop in BTC back in 2012. In 2012 when activity picked up again, it was almost entirely going back to BTC. Any increase in activity now won't be going back to LTC. There is simply no reason for that to happen. There are many more and better alternatives to LTC now.

OK, I see your point. I agree there are better alternatives, but I still feel like LTC has at least one more giant pump before (if) it dies a long slow death. There is just so much money invested in scrypt asics, and most of them haven't seen the light of day, that I think it will have another boom cycle (and an accompanying boom in the number of tx/day). But who knows...

Would those script ASICS be specific to LTC ?  .. or would LTC possibly become the 'byproduct' of a merge mine for a better alternative coin (thus depressing its price further).

It does not take much for ASIC owners to work out that they will break even and start getting ROI much faster on currencies that are growing rather than shrinking.

[dga]

Apologies if this is a duplicate, but trying to add more actual information to the pile of cryptonote derivatives -- BBR's Zoidberg wrote up a whitepaper about his Blockchain PoW construction and its realization in Wild Keccak:

http://boolberry.com/files/Block_Chain_Based_Proof_of_Work.pdf

As a follow-up to his earlier explanations of
  Improved anonymity:  http://www.slideshare.net/boolberry/boolberry-solves-cryptonoteflaws-37055246
  Ring signature pruning:    http://www.slideshare.net/boolberry/boolberry-reduces-blockchain-bloat

I'm sure there will be pushback on these as there was to the others, but kudos to him and the Boolberry team for putting it out there for others to read, steal from, and criticize.  (Disclaimer:  I looked at an earlier draft of this one and provided some minor writing feedback.  I'm not an author of it and am not part of the BBR team.)

[fluffypony]

I'm sure there will be pushback on these as there was to the others, but kudos to him and the Boolberry team for putting it out there for others to read, steal from, and criticize.  (Disclaimer:  I looked at an earlier draft of this one and provided some minor writing feedback.  I'm not an author of it and am not part of the BBR team.)

Busy reading through it - he leads into it with a huge fallacy that is either incredibly naive or very disingenuous of him. When describing CryptoNight he states: "These constraints were supposed to protect hash from GPU and ASIC implementation" [sic]. Literally the first paragraph in the CryptoNote whitepaper that describes the PoW algorithm says: "Our primary goal is to close the gap between CPU (majority) and GPU/FPGA/ASIC (minority) miners. It is appropriate that some users can have a certain advantage over others, but their investments should grow at least linearly with the power. More generally, producing special-purpose devices has to be as less profitable as possible."

Misrepresenting the facts of the matter in a whitepaper, purposely or not, is unconscionable.

[TooDumbForBitcoin]

I'm sure there will be pushback on these as there was to the others, but kudos to him and the Boolberry team for putting it out there for others to read, steal from, and criticize.  (Disclaimer:  I looked at an earlier draft of this one and provided some minor writing feedback.  I'm not an author of it and am not part of the BBR team.)

Busy reading through it - he leads into it with a huge fallacy that is either incredibly naive or very disingenuous of him. When describing CryptoNight he states: "These constraints were supposed to protect hash from GPU and ASIC implementation" [sic]. Literally the first paragraph in the CryptoNote whitepaper that describes the PoW algorithm says: "Our primary goal is to close the gap between CPU (majority) and GPU/FPGA/ASIC (minority) miners. It is appropriate that some users can have a certain advantage over others, but their investments should grow at least linearly with the power. More generally, producing special-purpose devices has to be as less profitable as possible."

Misrepresenting the facts of the matter in a whitepaper, purposely or not, is unconscionable.

Looks like two different ways to say the same thing.  "protect from" has the same meaning as "close the gap between" in terms of reducing the ability for GPU/ASIC to skyrocket the hash beyond the capabilities of CPU to do so.

[aminorex]

...purposely or not, is unconscionable.

how does the saying go...when the accidental becomes unconscionable the neurotic become...demotivational?

when you have to explain the joke you know you've failed.

[fluffypony]

I'm sure there will be pushback on these as there was to the others, but kudos to him and the Boolberry team for putting it out there for others to read, steal from, and criticize.  (Disclaimer:  I looked at an earlier draft of this one and provided some minor writing feedback.  I'm not an author of it and am not part of the BBR team.)

Busy reading through it - he leads into it with a huge fallacy that is either incredibly naive or very disingenuous of him. When describing CryptoNight he states: "These constraints were supposed to protect hash from GPU and ASIC implementation" [sic]. Literally the first paragraph in the CryptoNote whitepaper that describes the PoW algorithm says: "Our primary goal is to close the gap between CPU (majority) and GPU/FPGA/ASIC (minority) miners. It is appropriate that some users can have a certain advantage over others, but their investments should grow at least linearly with the power. More generally, producing special-purpose devices has to be as less profitable as possible."

Misrepresenting the facts of the matter in a whitepaper, purposely or not, is unconscionable.

Looks like two different ways to say the same thing.  "protect from" has the same meaning as "close the gap between" in terms of reducing the ability for GPU/ASIC to skyrocket the hash beyond the capabilities of CPU to do so.

The full sentence in the whitepaper is: "These constraints were supposed to protect hash from GPU and ASIC implementation, but a GPU miner appeared on the scene in 2 weeks after this technology got public attention." Thus, contextually we know that his meaning in the word "protect" is "ensure they do not exist". He considers the very existence of a GPU miner a failure of the algorithm, when, in fact, a GPU miner can and should exist as long as it the performance gap is closed. Currently GPU miners are 2-3x as performant / efficient as CPU miners, and by dga's calculations they shan't exceed ~5x the performance / efficiency. Thus the algorithm has completely succeeded at what it purports to do, and has met its primary goal.

[tromp]

The full sentence in the whitepaper is: "These constraints were supposed to protect hash from GPU and ASIC implementation, but a GPU miner appeared on the scene in 2 weeks after this technology got public attention." Thus, contextually we know that his meaning in the word "protect" is "ensure they do not exist". He considers the very existence of a GPU miner a failure of the algorithm, when, in fact, a GPU miner can and should exist as long as it the performance gap is closed. Currently GPU miners are 2-3x as performant / efficient as CPU miners, and by dga's calculations they shan't exceed ~5x the performance / efficiency. Thus the algorithm has completely succeeded at what it purports to do, and has met its primary goal.

If we're nitpicking, then closing the gap would mean that GPUs are no faster than (the fastest) CPU.
A 2x-3x gap is a narrowed, not a closed gap.

[fluffypony]

The full sentence in the whitepaper is: "These constraints were supposed to protect hash from GPU and ASIC implementation, but a GPU miner appeared on the scene in 2 weeks after this technology got public attention." Thus, contextually we know that his meaning in the word "protect" is "ensure they do not exist". He considers the very existence of a GPU miner a failure of the algorithm, when, in fact, a GPU miner can and should exist as long as it the performance gap is closed. Currently GPU miners are 2-3x as performant / efficient as CPU miners, and by dga's calculations they shan't exceed ~5x the performance / efficiency. Thus the algorithm has completely succeeded at what it purports to do, and has met its primary goal.

If we're nitpicking, then closing the gap would mean that GPUs are no faster than (the fastest) CPU.
A 2x-3x gap is a narrowed, not a closed gap.

That is true, but you and I are resigned in the knowledge that a purpose-built device will always be able to outperform a general purpose device, even if the cost of that purpose-built device is fiscally prohibitive. Thus, the gap cannot ever truly be closed, in the truest sense of the word. Thankfully, this is clarified somewhat: "It is appropriate that some users can have a certain advantage over others, but their investments should grow at least linearly with the power."

Holistically the take away is and should be that the performance gap needed to be reduced between CPUs, GPUs, FPGAs, and ASICs. CryptoNight delivers on that goal quite sufficiently.

Note: I much prefer Cuckoo Cycle over CryptoNight, and am watching its ongoing development with expectation and excitement. Although we do not expect to switch PoWs anytime soon, Cuckoo Cycle is on a very short list of candidates for future consideration.

[TheUniporn]

Although we do not expect to switch PoWs anytime soon, Cuckoo Cycle is on a very short list of candidates for future consideration.

I like that this kind of decisions are on the table. I think most devs just chicken out of fear of ruining the price while that's what they're actually doing themselves by sticking with the easy way.

[Este Nuno]

Hey. I'm not sure if this is true but apparently Ethereum might use something called DPOS (1). I haven't read the paper yet (2) but according to (1) vitalik agrees that proof of work is dead.

I believe this needs serious analysis in case they are right and onto something.

(1) https://bitcointalk.org/index.php?topic=740684

(2) https://bitcointalk.org/index.php?topic=558316.0

SlipperySlope and anyone else who has an interest in PoS:

What are you opinions on this DPoS? Is this the holy grail that people have been waiting for? I thought Vitalik was a PoW hardliner. So I was a bit surprised to read this.

[drawingthesun]

That is true, but you and I are resigned in the knowledge that a purpose-built device will always be able to outperform a general purpose device, even if the cost of that purpose-built device is fiscally prohibitive. Thus, the gap cannot ever truly be closed, in the truest sense of the word. Thankfully, this is clarified somewhat: "It is appropriate that some users can have a certain advantage over others, but their investments should grow at least linearly with the power."

Vitalik is trying to get his PoW to use the general purpose computations from the contracts to prove that they are running CPU's.

I am not sure how far he is along with this idea, because the latest is that he is considering this new dPoS thing. But if he uses PoW and uses the turing complete contracts as proof for the PoW then a cpu would be the optimal hardware for mining, because an ASIC for Ethereum would simply be a better CPU, and then you're up against Intel.

Of course, his ideas might not be possible, which is why they still have no mining algorithm.