|
Anyone could do this... it wouldn't require huge effort or cost. Might well be MtGox themselves trying to make their problem seem more serious and global.
|
|
|
|
If a coins value can be determined by its network hashrate then maybe you should sell ltc and buy something else  LTC: 77.93 GH/s, DOGE: 103.84 GH/s Im not saying doge is a better long term investment, but it will go through a couple of block halvings this year and if its popularity stays on the same level the value should increase by quite a lot. Not sure where you get those numbers lol, but the continuous doge hashrate is definitely not that high. Doge has around 1/3 the network strength of LTC. Doge is a hillarious and profitable (for now) joke. But the chances of it appreciating in value seem pretty slim. The variable reward blocks are attracting a lot of profit-switching pools like middlecoin to rape the high reward blocks, but then almost nobody mines the low reward blocks. Only accurate metric for doge hashrate is difficulty (this is why coinchoose shows ? ? ? for network hashrate). |
|
|
|
|
Hold your LTC... $30 and beyond will almost certainly happen again, unless all cryptos go to the ground, in which case diversifying won't help you.
This, is from someone that held a big chunk of LTC all the way down from $4+ to under $1.70... Sure, I sold some during the last bubble, but I am still strongly long litecoin. This is a long game - LTC has the backing and technicals to go far. And crypto isn't going anywhere. Hold and be strong.
|
|
|
|
|
I will answer your question honestly: I had never heard of EBT until now.
Now... because it doesn't look very profitable to mine, doesn't seem to offer anything innovative at all, and the name isn't very clever.
That said, I might solo mine a bit for shits and giggles, because super low-diff coins are fun (for all of about a day).
|
|
|
|
|
Absolutely... Litecoin is the strongest network next to BTC, with the best history, strong core dev team, and the most potential. If you are a crypto investor not holding LTC, you are crazy.
Trust in a system storing value is largely based around history. A new coin simply can never beat LTC's history, due to the mechanics of time.
As for ASICs, it looks like the future there is bright. ASICs are coming for scrypt, yes. But they look to be only an incremental advancement that will not completely invalidate GPUs like we saw with BTC. Certainly, ASIC equipment will be developed for any crypto that becomes valuable enough, but scrypt remains resistant to these advanced. Point in case - you can still mine LTC with a bank of CPUs. Certainly not true with SHA once GPUs came onboard. The same will go for ASICs and GPUs, and later generation ASICs.
|
|
|
|
|
I think you will have a very hard time finding precident for a defamafion or slander lawsuit for what someone wrote on a forum.... not to mention screenshots are about as far as it gets from admisible legal evidence.
Ripple is certainly more interesting since they opened up the source code for running a full node... but it should be forked and the units of trade made reasonably distributed.
|
|
|
|
interesting stuff here !~quantum computer in the middle? =0
Nothing quantum required. Just a well connected node re-writing sigscripts. No reason to worry. |
|
|
|
I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.
The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol. It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal. Ah yes, using the actual txouts, sure. Still, maintaining this extra database is unneccesary. The BTC protocol already provides the means to do with without extra data. MtGox has also acknowledged your suggested technique as a possibility, and is trying to avoid that overhead. 1 more column in a table and a couple extra lines of code is overhead? Instead they cause a massive crash by blaming it on the bitcoin protocol. But knowing gox they would have implemented it wrong on their production server and screwed things up worse. Heh, not saying their claim of overhead is reasonable, just re-stating it. And yes... Gox seems full of fail right now. I mean come on, throw a fix together and get your business going again, and then work on core protocol changes. |
|
|
|
I still want to circle this back to my unanswered concern:
If my Bitcoin-Qt shows red (withdrawals) for both transactions on it's main window, and both (1 uncomfirmed and 1 many-times confirmed) in its tranacttions log - does the perceived account balance reflect ONE or BOTH withdrawals?
my concern is that this could make incorrectly-updated clients to report lower-than-actual bitcoin quantities and possibly cause these bitcoins to be forgotten when the user transfers the 'visible' balance elsewhere and leave behind the amount from the unconfirmed double spend that still belongs to the left-behind address?
Spends should be linked to specific txouts, not addresses, so the balance should always be correct. You know... I am starting to wonder if MtGox is running this Maliability bot to fuck with the blockchain even more. |
|
|
|
I totally understood that. And again I cannot agree more with you. However, at issue is how Gox perceives this. They're probably thinking from the angle when an auditor or end user standing in front of their face asking for proof that their ABCDE wallet address has been credited for XYZ amount. With a transaction, it has a time, amount and the ABCDE in it, all in one place signed by Gox. With an address, despite the exchange's own claim that it's a one-time and unique, an address by definition CAN be used to send funds to many addresses. Address to transaction is a one-to-many relationship, so you would have to locate the transaction(even there is only one) first in order to get time, amount and the receiving address that the auditor/user need to see, they care the receiving side's proof more than the sending side's.
Ah, I see what you are saying. I suppose from that angle, a re-producable and verifiable hash of a transaction that is actually standardized as part of the protocol might have benefit. At the same time, knowing the tx address is unique can allow you to detect the resultant txid and record that for auditing purposes. A txid is verifiable and permanent after commited to the blockchain, afterall, just not before. So the unique address approach for this is valid and requires no new data to be stored, but wouldn't completely do away with txid's given the type of auditing you suggest MtGox desires. So, it becomes: - show user unique sending address as confirmation - track transaction with sending address - record txid once transaction is included in the blockchain |
|
|
|
|
1-stale shares: set a time limit instead of 1 block, and advise people to set their queue depth to 0 (probably the most key thing other then intensity). I wouldn't start rejecting these outright, because tuning your miner without regard for rejects is unlikely to give you more then a 2% benefit in hashrate, people hate rejects/stales, and it is unlikely to actually increase profits unless you also train wafflepool's miners to tune their rigs for fast switching. A sudden jump in rejects will cause people to leave, not re-tune their rigs.
Crypsty: this, and new profitable coins, is probably why h2o of middlecoin has to pay 2 employees (to manually trade).
|
|
|
|
Or: just stop tracking using txid's... You don't even have to generate and store a seperate tx hash.
1. Identify address in hot wallet with enough btc
2. Spend all coins in that address to the recipient and a change address
3. For the change address, use any other address in the hot wallet.
4. Never re-use an address after you have spent from it (and always empty the address completely when you spend)
5. Use sending address as your txid (a reliably unique identifier that will not change)
I'm totally with you on that, it should be an equally secure and effective measure. But if you read between the lines from their latest announcement you get the feeling that they were hung up on the idea of linking a specific Bitcoin network transaction to a particular user request of theirs, perhaps for auditing or non-repudiation needs. Some people may view using the addresses alone as an inadequate proof of a transaction since the owner of the addresses can only be inferred from a signed transaction and a related balance change in both the sending and receiving adresses can only be established via a valid transaction, which is what Gox desperately trying to get. If you only use an address for a single spend, and then never again, the sending address IS a unique identifier for that transaction, and can be easily linked to a withdrawal request. |
|
|
|
I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.
The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol. It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal. Ah yes, using the actual txouts, sure. Still, maintaining this extra database is unneccesary. The BTC protocol already provides the means to do with without extra data. MtGox has also acknowledged your suggested technique as a possibility, and is trying to avoid that overhead. |
|
|
|
Why? They aren't actually double spends. Blockchain needs to fix their definition... Duplicate transactions with different txid's are fine and no cause for alarm. Transaction maliability is irrelevent to bitcoin functioning. |
|
|
|
|
This is not a double spend in any way, shape, or form. You have double spent if you get two different transactions confirmed in the blockchain.
0 confirmation transactions are irrelevent... anyone can re-spend non-confirmed txouts quite trivially.
Transaction maliability is fine... it isn't a bug or a fault.
Someone is re-broadcasting tx's with slight modifications that result in different txid's. If anything, the person is benefiting the network by forcing idiots like the MtGox devs to stop relying on the txid before it is confirmed in a block.
|
|
|
|
I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.
The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol. |
|
|
|
|
Or: just stop tracking using txid's... You don't even have to generate and store a seperate tx hash.
1. Identify address in hot wallet with enough btc
2. Spend all coins in that address to the recipient and a change address
3. For the change address, use any other address in the hot wallet.
4. Never re-use an address after you have spent from it (and always empty the address completely when you spend)
5. Use sending address as your txid (a reliably unique identifier that will not change)
|
|
|
|
|
So, shall we speculate how many bitcoins MtGox lost when someone realized they were not checking their txouts properly? Could be 1000s of BTC. But, I bet it was nothing at all... MtGox just screwed up on how they track their txouts, and re-spent txouts that were already spent. Cross fingers the next announcement isn't MtGox has lost your bitcoins (which would probably be yet another lie)...
Bitcoin wiki: "assuming a txout exists because the client created it previously is unsafe." Obvious MtGox failed to heed this advise... This is MtGox stupidity plain and simple. I hope anyone still using MtGox (god knows why) withdrawals everything as soon as they have the opportunity (presuming they ever re-enable withdrawals).
I also think it is high time the Bitcoin foundation removed MtGox's member status and kicked out their failing leader (if you can even call him that). Badmouthing the bitcoin protocol because you have a faulty inplementation with a lack of checks and balances is ridiculous and should not be acceptable to the foundation or the community. I would say the foundation's credibility is severly at stake here.
Transaction maliability is not a 'defect'... it is a known and published reality of the bitcoin protocol. Txid's identify a transaction reliably _after_ it is included in a block. Using txid as an identifier to track your txouts is beyond stupid. (Which must be the case if MtGox was trying to re-use txouts that where previously spent but confirmed with different txids).
|
|
|
|
|
Solution: do not re-use addresses. Send all change to another address, and track spends on the blockchain using the sending address... No chance of duplicated tracking data (the sending address basically becomes your tx hash). voila. No problem here other then MtGox incompetance. Demanding a change to the core protocol is ridiculous.
|
|
|
|
|
Show Posts
