No, you could not make 2 shorts at same amount that day as it never went back to 153 again. And let me not start about you mourning 10 000 loss that day just to see you claiming your usual self-loving bullshit that it was all part of your plan when price went to good direction few hours later.

I don't really need to be in peace or war with you to be honest, if it is normal stuff I'd have relation with you just as with anyone else who acts normally. You're just full of bullshit and acting like a redneck in need of attention, praise and reputation from random nobodies on internet forums. I tried to not care but couldn't deal with it today as it became too obvious. And most important - such extensive bullshit talk can cause people to act irrational on market so i'ts important to warn them about you.

You remind me on this guy and that speaks  a volume:

Cross posting in case anyone's able to offer advice or help me track this

http://www.reddit.com/r/Bitcoin/comments/1czrua/just_lost_160_btc_from_address_managed_with/

In December 2010, a group calling itself fail0verflow announced recovery of the ECDSA private key used by Sony to sign software for the PlayStation 3 game console. However, this attack can be considered invalid against ECDSA because it is Sony who failed to implement valid signature(s). That is, the attack was made possible because Sony failed to generate a new random k for each signature.

There's no reward.  The idea is that miners would broadcast hits.  The cost is tiny, it is just 80 more bytes to send.

Collisions aren't really that big a deal, if there are 2 hits, then that link has 2 possible paths, but it doesn't matter which you follow.

Yes of course 

On April 10th you wont need MtGox codes anymore to withdraw.

I cant say more until its tested and implemented, but I will have the ability to 'request' a payment from your MtGox account. You login to your account, and approve the transfer to my account. All this can be done from within the BitInstant website

-Charlie

Actually, this could be implemented as a soft fork.  

Part of the timestamp could be re-purposed as as extended previous field.  If a 256 range of seconds are assigned for this purpose, then that gives 8 bits for a prev field.  

Can ASIC miners modify the step size for their counters?  If so, then the nonce could be used directly.

The previous field of a block becomes

<hash of previous main chain block>:<Least significant byte of the hash of the aux chain header>

Only the headers matter.  There is no transaction verification on the parallel chain.  It is just to show processing is happening.

Alt chain headers are valid if they have at least 1/64th of the PoW of the main chain blocks and point to a previous block on the alt chain.

The process would be something like

Main Block A: Prev Z, LSB of hash = 62
- Header A-1: Prev A, LSB of hash = 31, LSB of timestamp = 62
- Header A-2-a: Prev A, LSB of hash = 191, LSB of timestamp = 31
- Header A-2-b: Prev A, LSB of hash = 101, LSB of timestamp = 31 (orphan, both valid though)
- Header A-3: Prev A, LSB of hash = 88, LSB of timestamp = 101
...
...
- Header A-26: Prev A, LSB of hash = 176, LSB of timestamp = 4


Main Block B, Prev A, LSB of hash 99, LSB of timestamp = 176

The sub-chain can never have more than 256 sub-blocks.  However, if the chain is that long it proves that at least 256 links were found.  Orphans are interchangeable, they just show that that step was reached, so as a length of 256 is reached, most alt-blocks would collide with other early steps.

Miners should not broadcast those ones.

Also, ties should be broken based on the length of the alt chain.

If a miners receives A->B->C and then gets C*, it should switch mining to C*, if C* has a longer alt chain lead in.

So you want to make it easier to pull off a double spend on a zero-confirmation transaction?

Being able to rely on the zero-confirmation transaction "no-replacement" rule is extremely important for the usability of bitcoin. I think it would take a big hit if it were eliminated.

It would basically mean that unless you can rely on the spender being honest, you cannot accept a zero-conf transaction from them. Right now, all you need to be able to trust is that most miners are honest and are using the standard bitcoin client software with the no-replacement rule. It's been working so far, so I don't see the point of changing it.

What's the worst that can happen if the rule is not revoked? Someone pulls off a double spend? OK, then people will stop relying on zero-conf txs. The price of not doing any thing is possibly a few double spend attacks, probably with a combined value of less than the $500 John Dillon is offering as a bounty. The price of doing something is that people are guaranteed to not be able to use zero-conf txs any more, which would remove millions, if not hundreds of millions of dollars worth of value from bitcoin.

There could also be possible solutions to making zero-conf txs safer from double spends, and by eliminating them altogether, we'll never be able to try them and find out. This proposal is completely unnecessary.


If you want an undo button, add a feature in the client where after a user presses 'send', a timer starts, that after 10 minutes, fires off the transaction, and an 'undo' button on that timer, that if clicked before the timer reaches zero, cancels the countdown. No need to make double-spending zero-conf transactions trivial.

It means that most blocks are kept fixed size and don't require validation (other than verifying the sha hash).  Transactions can be aggregated in a 10 minute period.

This would be a hark fork or alt chain.

The idea would be to ban transaction except for every Nth block.  Almost all blocks are empty.

This allows speeding up the block generation rate, without needing lots of extra validation.

For example, if the block rate was 10 seconds but only every 60th block contained transactions, then the effective block rate would still only be one block every 10 minutes.

The merkle root in the other blocks could encode an address for fees to be paid.  These blocks would be 80 bytes forever.

The other blocks would be 80 bytes always.  No matter how many transactions the system is handling, most blocks would be tiny.  As time passes, network latency should become insignificant.

This means that random block chain reversions would be less like.  6 blocks would happen in 1 minute instead of 1 hour.

The payout would have to be split in some way.  A validator could submit a block and assign some of the fees to any miners who build on it.  There would be a trade-off.  Miners would build on the block with the most fees.

Validators could have something like reputation, which grows with time if they submit valid blocks.  Proof that they have submitted bad blocks would set their reputation back to zero.

Trading as low as 84 now and seems still going down. Triangle is broken and seems not merely consolidation. The last high at around 82 could be decisive and I bet it will not hold.

It's late here. I expect to wake up with 70s.

How Satoshi mining pattern disappears...

May we know from which sites are you taking those graph pls ?

thx !

maybe. or just consolidation. bid side looks strong but ask side has also filled up with people ready to unload. tons of selling pressure, it's up to the market to decide whether or not $100 bitcoins can really be taken seriously again.