Signatures which are non-canonical in the manners mentioned in this thread are non-standard now. There are several more restrictions which must be imposed before the malleability attacks will be gone, however.

They're trolling for suckers on IRC now:

06:37 -!- SkyMinerlabs [3e71f887@gateway/web/freenode/ip.62.113.248.135] has joined #bitcoin
06:38 < SkyMinerlabs> http://www.skyminerlabs.com/ we have released our mining PCI-E product, please check it out!

Well if they come out and say it's X GH/s and Y H/j _now_ then if:

(1) these numbers are above their advertised specs, but the final product is still above advertised but not quite as due to cooling, firmware, etc. people will feel cheated. (e.g. do good and they still hate you)

(2) if these numbers are below the advertised specs people who are waiting until the 31st to fund attorneys to commence litigation will start now, and dealing with it will distract them from shipping a product.

About the only gain— from a purely utilitarian perspective— that can come from more details is trying to pull in some more pre-orders.  Though personally I think all of us would love to hear more, I can understand why a conservative approach may win even without any disaster.

No, this is why SPV mode supporting clients exist. Perhaps you should refrain from posting in the technical subforum until you're a little more aware of how the Bitcoin system works. Also, please try to treat the other contributors with a bit more respect.  Responses like " lol" from clueless people drives away competent contributors.

Why should anyone include any transactions at all? How do you prevent someone from typing while true; do stuffecoin sendtoaddress `stuffecoin getnewaddress` ?

If you're not talking about something even possible in Bitcoin— this is the wrong subforum, altcoin subforum is over there ---->

What you appear to be describing is a cryptographically blinded commitment scheme.

See Adam Back's commitment thread: https://bitcointalk.org/index.php?topic=206303.0

Blind commitment schemes have problems with anti-dos, with paying fees (makes the anti-dos problems worse), with poor scalability (the coins become larger linear with their history size— and the history tends to grow exponentially over time with splits and merges),  and brittle security— because someone down the line can leak the whole history.  You can attack the scalability by later disclosing the history in public but then you just make the security story worse.

Most of these issues go away if add to the system a zero knoweldge proof that confirms that the blinded data is valid, consistent with the network history (e.g. spending existing coins), discloses the fee, and confirms that that its outputs, fees add up to the input... then perhaps you get something that might work acceptably. But then the challenge is getting a ZKP which is fast enough, produces small enough proofs, and doesn't depend on a trusted party to initiate the system. There is lots of work going on in the ZKP space, but a lot of it is focused on delegated computation and needs trusted initialization, though theory permits solving these problems.

Threads like this are a common way to introduce scams. I've never heard of this miner, has anyone else?

Edit:  Ah looks like other people have done some sleuthing and this seems pretty clearly scammy, as expected.

Yep most hardware in use for mining has second to multisecond latencies, not even getting into the latencies of global propagation in a network of decentralized volunteers (rather than trivially coerced corporate interests).

But I think if you fixate on one second you're not getting the value of of the paper. Just multiply their numbers by 10 if you find 1 second is a bit outrageous considering the practicalities that their analysis excluded.

This is an argument for deterministic wallets, and is largely orthogonal to change. If you're going to highly structure your assumptions about Mr. Nooberg you might as well have him importing keys and not realizing that they instantly invalidate his backups or getting new addresses but mostly intending to use old ones but messing up, or what have you.

Which is also true even if there isn't any change just because of funds being sent to other addresses.  Presumably Mr. Loanshark will say wtf, and then they'll figure it out.  Again you're assuming a very specific level of knoweldge just enough to get in this specific trouble... in this case you're also assuming they'll give up at the first, really obvious sign of trouble.

If this is a usecase that you think matters a "Generate proof of signature authority" would be a lot more foolproof, not just against a specific Mrs. Noobisky but against all possible Noobiskies, and could also do things like generate the proof in zero knoweldge so Mr. loanshark doesn't actually learn which coins are mrs. nobodies unless that was desired, and doesn't learn anything more about the value then meeting the required test.

Flipping your hypothetical right around, of Mrs. Noobisky constantly reuses the change address its usually trivial to determine the entirety of their holdings, even unintentionally.  Mrs. Noobisky intends to show Mr. Loanshark a single address assigned just enough coin to satisfy him, but the change reuse has invisibly linked all of Mrs. Noobisky's funds without her releasing it and now Mr. Loanshark realizes that she's been holding back on her ability to pay and goes and takes her computer and slits her throat. Good job, you just killed Mrs. Noobisky, you bastard!

Thats not _quite_ accurate. The P2P protocol has no way to communicate which nodes have which block other than a binary state for "full node or not" which implies all the block. To have pruning we first must change the p2p protocol to communicate nodes that are full nodes but can only serve recent blocks (+some named subset of the history, most likely). There are also a bunch of other minor details like refusing to serve blocks it doesn't have instead of just crashing on the request.

No it shouldn't, doing so completely screws up the privacy model— not just for the user in question but for all users. This creates long term risk for all Bitcoin users because it increases the viability of blacklisting schemes.

Already dumpprivkey is hidden inside a debugging console. This is not where some clueless noob is going to stumble into it by accident. Its there for a reason.

The correct way to accommodate that use case is to _never_ make single address "paper wallets", but instead to make multi-address seed paper wallets. Armory does this fine today.

Arguably the attribute made public was, technically, that litecoin was best mined on CPUs. If I found a bug that let me make additional litecoin out of thin air, would it be immoral for litecoin to fix it? You couldn't really make the same argument to introduce such a bug.

In any case— just a thought.

This is the first time I've heard someone suggest that. I thought it was generally accepted that Bitcoin's price in march was primary related to the increased press Bitcoin received from the cyprus default and bank funds confiscation. 

If the refund is constructed using P2SH you can get the other side to sign just the hash, and they won't be able to recognize the payment into the escrow— being both unable to see their own pubkey in it (due to p2sh) and having not seen the refund they signed. Thats one of the workarounds...

Full mutability fixes are very slow going. MTGOX is still producing transactions with non-canonical R,S. Bitcoin-QT GIT now uses the smaller of the two possible S values in signatures, but I'm not aware of any other signers that do. I think its not unlikely that we're going to see hardware wallets deploy which fail to do this.  I'm now wondering if we shouldn't start 'fixing' these transactions on relay and just letting them cope with their txids changing out from under them rather than failing to forward completely.

As for other fix progress: https://github.com/bitcoin/bitcoin/pull/3025

A point I've argued many times. But in hindsight I was somewhat wrong. No finite collection of fixed algorithms (Even a large set) can be ASIC proof (in fact, large sets probably just lead to ASIC monopolies due to higher NRE).  But if you change the POW periodically in ways which aren't predicable months in advance, and in ways that can't just be generalized with anything more specialized than general purpose consumer hardware... then I do think you would actually have achieved a fairly high degree of asic-proof-ness. There is just the question of the costs of periodic changes being worth the benefits, and what cadence is required to make investment unwise.

Indeed, I thought LTC's motivations were outright stupid here— and what you were 'quoting' there could easily have been me. I still think resisting ASICs is a not very useful goal, but it is a clearly stated goal of the system, and it does serve to distinguish it from Bitcoin.

After working with a number of ASIC makers in Bitcoin space, I have to say that some of the luster has worn off a bit from my prior enthusiasm too, not enough to disagree with my prior position, but enough to say that was more complicated than I gave it credit for:  ATI never raised their prices (usually after recovering NRE from sucker buyers who eat all the risk, even though the asics have no resale value) to the point where it was difficult to make a return on being a miner yourself, ATI never ran huge farms with substantial chunks of the network hashrate, etc. But this is an aside.  I don't mean to doom and gloom ASICs: so long as specialized hardware is possible— and it always is— having the honest users using it is good... but LTC sold a Bill of Goods that excluded this stuff, and so ASICs showing up is arguably a bug.
 

One possibility is just a "minimum change". E.g. changing the number of salsa rounds by a few and tossing an xor between them at some spot or another.  It would totally break any fixed function hardware, but would be a 2 LOC for any cpu/gpu miner.   I think something like that would be an unfortunate loss of an opportunity, but it would also keep open the possibility of change in the future by avoiding fixed function hardware.

According to reports scrypt ASICs may soon exist, finally completely eliminating this feature distinguishing Litecoin from Bitcoin— at first LTC was supposed to be CPU only but that failed, then GPU only and thats failing.

I never thought much of the goal here, but at least it was a distinction— if, IMO, a kinda dumb one.  The thing I like least about alts is the lack of distinction and innovation they frequently suffer, and so being another asic mined coins but with different asics seems like such a waste to me.

If the LTC community wanted it could change POW and the practice of being willing to change it would probably be a stronger protection for general purpose hardware than the use of any particularity or set of particular schemes could ever be. Though since (it seems to me) so much of the LTC community is miners the change would have to be to another CPU+GPU friendly one so the existing miners wouldn't be left out.

There are a lot of options here— including different POWs already deployed other ALTs or something novel.  What got me musing on this subject was the question of: If I threw out an alt that used ECDSA signature validation as its POW would someone write ultra fast GPU code for ECDSA (which would be very useful in helping to scale node performance, even in Bitcoin)?

I suspect that if LTC doesn't change POW now that the introduction of fixed function hardware will mean that it never can. Perhaps its already too late, though I don't know: LTC has always advertised itself as being <s>GPU</s>ASIC proof, and a violation of that is an outright bug, which arguably should be fixed no different than if it were possible to mine more than 84 million litecoins.

Such a change could be made mostly seamlessly— a new version released, and a deadline for upgrade, not too unlike the Bitcoin 0.8 hardfork or the nversion=2 blocks. Existing miners could even use coinbase votes (indicating their ability to support the switch in the blocks they mine) to trigger the change so that it could be done in a way which is assured to not exclude too much of the existing hashrate (though, presumably, using a coinbase vote would fail if there are secretly large asic farms already). Miners would need to upgrade software, but they'd just have to update sometime before the switchover, no tricky synchronization would be required.

I wonder what people think of this? Is this the sort of thing that could get near-unanimous consensus in the LTC community?

Now, can you CoinSwap-ify your protocol so that in the case where everyone plays honestly the fact that they just used a coinflip is not visible in the blockchain?

Whats going to happen with unpaid units if they don't pay? 

It wouldn't be hard for p2pool to at least prioritize it's users spending their generated coin— but P2Pool has never had a large enough share of the global hashrate to make it seem worth doing.