|
Yes, this would be a valid attack. That is why transaction are not considered confirmed until it has been included in six blocks. In fact, you don't need vending machines, you can do it right now from two different computers that have the same wallet. In the end, the two transactions will slowly battle their way through the network and only one will get confirmed. In a very, very rare case that would likely have to be a coordinated attack, both transaction may end up being included in different blocks. But, assuming the miners aren't working to muddle the system, it will sorted out and only one will end up with 6 confirmation. The odds that both transaction accidentally end up with six is completely astronomically unlikely, which is why we consider six transaction confirmed. Honestly, barring an intentional attack on the network, you can be fairly confidant of a transaction at one confirmation, and very sure at two.
|
|
|
|
|
Addresses have a few letters and numbers (checksums) to ensure that they are valid. If you just just a random string as an address, it will most likely be considered invalid.
But there are millions or millions of millions of millions of trillions of valid addresses. If you send money to any of these 'valid' addresses, then the money will be sent and cannot be revered. There is no way to tell if an address is "in use". You can even make you own address while you computer isn't conected to the internet. The system just counts on the fact that two people will never ever just happen to claim the same address. Every address that will ever exist, exists right now.
A transaction to a valid address is never "unsuccessful". It always makes it. A computer "claiming" that address does not have to be connected.
Short answer, no.
|
|
|
|
|
How many blocks does it say it has downloaded in the bottom right? If this number isn't 131455+ then you haven't caught up to where we are yet. Wait until it does.
If it is caught up, try running bitcoin with the -rescan option.
|
|
|
|
|
At noon what time zone?
In any case, I'm going to throw down an estimate.
$68.40
|
|
|
|
|
Other is everyone solo mining. You really don't have to worry about it having a majority, the other node's are not cooperating.
|
|
|
|
|
We have no proof that it was really stolen. For all we know, someone paid allinvain in cash, $500,000 cash, for those coins. And now he is trying to convince the community that he was stolen from in an effort to get us to do something like this.
|
|
|
|
|
Lol, if prices go up high enough, you might be trying to fish it out in a couple of months.
|
|
|
|
My 14th post was: So it seems to be that the issue is that the transaction data and the generation address get hashed, and then the nonce is added and it is all hashed again like this:
{generation address}+{transaction data} -> {block hash}
{block hash}+{nonce} -> {final hash}
The pool currently gives you the block hash, you return the nonce of a share and the pool only has to check the final hash. I suppose what we need to do is change the entire system (everything) so that the pool can verify the generation address. Something like this.
{transaction data} -> {transaction hash}
{generation address}+{transaction hash}+{nonce} -> {final hash}
This way a pool member can send its own transaction hash once and the nonce of each share, but the pool still gets to verify the generation address. Is this the upshot of your proposition?
I expect at least as much. |
|
|
|
|
Fragment sentence into the forum, which is know to cause confusion?
|
|
|
|
|
It is possible that the stolen money (if actually stolen) is being laundered through multiple mt gox accounts. The constant sells and buys all going back and forth to essentially the same person may be keeping the price flat. I would assume he/she would be willing to take trade losses to help him get clean USD/bitcoins.
|
|
|
|
Based on the current market depth, buying $250k worth of BTC on mtgox would drive the price up to almost $24!
Which is also why I feel like this thread is a bull troll. |
|
|
|
These are changes they are making now. Encryption will be in the next release of the bitcoin client. No need to restart.
Would you mind giving a link to where a developer said encryption would be in the next release? or is this more just you hope it will be in the next release? And I quote: "Priority for next version: wallet encryption" You can see the progress on this issue here: https://github.com/bitcoin/bitcoin/pull/232 |
|
|
|
|
Wallets need to be encrypted by default. I think the client needs to provide a "savings" wallet with a different password that you are instructed not to use often -- for extra security.
These are changes they are making now. Encryption will be in the next release of the bitcoin client. No need to restart.
|
|
|
|
I received the weekly letter from bitoption - nice. I wanted to say that you need to configure your SPF record because otherwise all of your mails will go straight to spam like it did with me. I would guess that 90% of your mails this week went into spam. Here is a tool to check the record: http://www.kitterman.com/getspf2.pyIf you want to I can explain what to do. My letter did not spam. Everything seemed fine. |
|
|
|
|
I'm sure he can make a profit. I'm jealous.
|
|
|
|
|
Sounds good. Yeah, I thought that the stop loss system would lead to a whole bunch of problem. I suppose one can assume their bot will handle it.
I'm not sure I followed where you are going with updateAllStrikeBids. Is the idea to push all of your bids up or down a little. I admit that might be useful, depending on the final implementation of the bot.
And updateAllDateStrikeAsks, is there a reason that has a "date" in the name while the other doesn't? I'm still not completely familiar with the API so I might be missing the obvious.
PS you should have my email, I signed up with mine.
|
|
|
|
|
There are two thing I would really like to see in the API.
First, I'd like the ability to change the bid/ask price on an open contract. It just seems cleaner than canceling and replacing, and it shouldn't be too hard to implement. This would be nice on the website too.
Second, and this one is harder, I'd like to be able to place an expiration on my open contracts. A time expiration would make me feel a lot more confidant and safer, especially if I were running a bot. If I get disconnected somehow, I know my open contracts will expire in an hour or two or whatever I set. Along with this should go a "renew" option which would let me change the expiration time.
Along the line of an expiration time, it would be nice to perhaps have an expiration price. If mt gox trades above, or below, a certain price the open contract gets canceled. This could by default be set (for asks at least) to anything that would instantly be in the money, since I'm pretty sure that no one ever wants to write a contract that is immediately in the money. This would require getting constant data from mt gox, but perhaps it could be implemented.
|
|
|
|
|
Sounds good. I was thinking about doing something like that with the API anyway. I'll start tinkering. I'll let you know if I need anything.
|
|
|
|
Or it could be someone drawing interesting patterns on bitcoin monitor to draw out the conspiracy theories.  That is an awesome idea. Would someone with enough bitcoins at their disposal write "you are all mine" in the bitcoin monitor? |
|
|
|
|
Show Posts
