Wall Observer BTC/USD - Bitcoin price movement tracking & discussion

[theonewhowaskazu]

They're reloading the blockchain but it's 47,000 blocks behind so it's going to take some time.

Oh my god. Really?

/facepalm

the gox strikes again!

Seriously, they're running a professional bitcoin exchange, and all this time, they're using Bitcoin QT? WTF?

tbh: there is a case to be made for using bitcoind. It's tried and true, community-reviewed and in widespread use. Emergency patch availability should be quite high, a broad developer base exists.

Sure, but you'd think they'd at the very least have their own backup node ready to broadcast WITHOUT needing the blockchain. That seems like a much simpler piece of software than QT, anyway, and since it doesn't have to download anything, the chances of stuff going wrong is significantly lower.

[1713238525]

1713238525

[1713238525]

1713238525

[1713238525]

1713238525

[1713238525]

1713238525

[1713238525]

1713238525

[1713238525]

1713238525

[dserrano5]

Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.

[22:33] <@MagicalTux> samson_: downloading new blocks as fast as bitcoind can

[notme]

I'm just saying that all they need is the network communication code to be able to broadcast the withdrawal transactions, and they should have redundancy in their setup in case a bug is triggered in one client or a server goes down.  Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.

Their problem is that their wallet and their blockchain database and their network code are all in one package, so they can't generate transactions because they don't know which outputs they have to spend.

Once those three things get separated it become a lot easier. If you've still got a working blockchain database, and you are keeping track of which outputs you've spend and which you haven't, then you can generate the transaction manually and use the pushtx feature on blockchain.info to broadcast it if need be.

That's not true.  They give you the transaction id when you withdrawal, which means the transaction has to be created and signed.  It is later broadcast on the network.  There is always some delay, but with the outage the delay was longer than normal.

[theonewhowaskazu]

They should also have several fallbacks.  They already generate and sign the transactions with their own code, so they just need to broadcast it.  Any client can do that.

These alternate implementations do things like separate the blockchain management from the network communication from the wallet.

It means you can do things set up clustering on the various pieces for better performance and load balancing.

You know, grown-up software stuff.

I understand that.  I'm just saying that all they need is the network communication code to be able to broadcast the withdrawal transactions, and they should have redundancy in their setup in case a bug is triggered in one client or a server goes down.  Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.

If they aren't using Bitcoin-QT/Bitcoind, they wouldn't need to download the entire blockchain just to sign a transaction ~.~

[notme]

Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.

[22:33] <@MagicalTux> samson_: downloading new blocks as fast as bitcoind can

bitcoind != bitcoin-qt, but whatever.... also, just because they use bitcoind to handle the networking and blockchain doesn't mean that bitcoind has the only copy of the data and the only codepaths that can work with said data.

[samson]

They should also have several fallbacks.  They already generate and sign the transactions with their own code, so they just need to broadcast it.  Any client can do that.

These alternate implementations do things like separate the blockchain management from the network communication from the wallet.

It means you can do things set up clustering on the various pieces for better performance and load balancing.

You know, grown-up software stuff.

I understand that.  I'm just saying that all they need is the network communication code to be able to broadcast the withdrawal transactions, and they should have redundancy in their setup in case a bug is triggered in one client or a server goes down.  Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.

If they aren't using Bitcoin-QT/Bitcoind, they wouldn't need to download the entire blockchain just to sign a transaction ~.~

I keep two constantly live copies of the blockchain on the PC's in my little office.

[justusranvier]

They give you the transaction id when you withdrawal, which means the transaction has to be created and signed.  It is later broadcast on the network.  There is always some delay, but with the outage the delay was longer than normal.

In that case they should just route the transaction through: http://blockchain.info/pushtx

[notme]

They give you the transaction id when you withdrawal, which means the transaction has to be created and signed.  It is later broadcast on the network.  There is always some delay, but with the outage the delay was longer than normal.

In that case they should just route the transaction through: http://blockchain.info/pushtx

That is a good example of a possible fallback they could implement, as I suggested.

[theonewhowaskazu]

Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.

[22:33] <@MagicalTux> samson_: downloading new blocks as fast as bitcoind can

bitcoind != bitcoin-qt, but whatever.... also, just because they use bitcoind to handle the networking and blockchain doesn't mean that bitcoind has the only copy of the data and the only codepaths that can work with said data.

Actually they are the exact same thing. QT just contains what is effectively a GUI wrapper.

They give you the transaction id when you withdrawal, which means the transaction has to be created and signed.  It is later broadcast on the network.  There is always some delay, but with the outage the delay was longer than normal.

In that case they should just route the transaction through: http://blockchain.info/pushtx

Haha, thats actually not a bad idea. In times of doubt, blockchain.info to the rescue.

[ChartBuddy]

[notme]

Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.

[22:33] <@MagicalTux> samson_: downloading new blocks as fast as bitcoind can

bitcoind != bitcoin-qt, but whatever.... also, just because they use bitcoind to handle the networking and blockchain doesn't mean that bitcoind has the only copy of the data and the only codepaths that can work with said data.

Actually they are the exact same thing. QT just contains what is effectively a GUI wrapper.

Since I am a programmer by trade, the difference seems pretty large to me, but I fully understand that under the hood they have the same engine.  But bitcoin-qt has a lot more code, and has a much larger attack surface.

[justusranvier]

That is a good example of a possible fallback they could implement, as I suggested.

Yes. I'm curious, though, how they manage to do that with an extended downtime on their node. Do they route all incoming deposits directly to cold storage or do they route incoming deposits to the hot wallet and only move some of it to cold storage when it gets too big?

[theonewhowaskazu]

Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.

[22:33] <@MagicalTux> samson_: downloading new blocks as fast as bitcoind can

bitcoind != bitcoin-qt, but whatever.... also, just because they use bitcoind to handle the networking and blockchain doesn't mean that bitcoind has the only copy of the data and the only codepaths that can work with said data.

Actually they are the exact same thing. QT just contains what is effectively a GUI wrapper.

Since I am a programmer by trade, the difference seems pretty large to me, but I fully understand that under the hood they have the same engine.  But bitcoin-qt has a lot more code, and has a much larger attack surface.

What are you going to attack on Bitcoin-QT that you can't attack on Bitcoind? The connection to the Bitcoin network is by far the most vulnerable place in both, and they happen to run essentially the same code.

[notme]

That is a good example of a possible fallback they could implement, as I suggested.

Yes. I'm curious, though, how they manage to do that with an extended downtime on their node. Do they route all incoming deposits directly to cold storage or do they route incoming deposits to the hot wallet and only move some of it to cold storage when it gets too big?

I don't know how they route deposits and handle cold/hot wallet balances.  They should also be able to fall back to other methods for checking on deposits.  They know the addresses.  I don't know if they have the keys for deposit address though without bitcoind, so they might not be able to move the coins.  It would be interesting to see the details of their setup.  A lot could probably be gleaned by a thorough examination of the blockchain given some known deposit addresses and withdrawal origin addresses.

[samson]

That is a good example of a possible fallback they could implement, as I suggested.

Yes. I'm curious, though, how they manage to do that with an extended downtime on their node. Do they route all incoming deposits directly to cold storage or do they route incoming deposits to the hot wallet and only move some of it to cold storage when it gets too big?

They don't do anything as the deposits don't get processed until the blocks arrive.

[notme]

Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.

[22:33] <@MagicalTux> samson_: downloading new blocks as fast as bitcoind can

bitcoind != bitcoin-qt, but whatever.... also, just because they use bitcoind to handle the networking and blockchain doesn't mean that bitcoind has the only copy of the data and the only codepaths that can work with said data.

Actually they are the exact same thing. QT just contains what is effectively a GUI wrapper.

Since I am a programmer by trade, the difference seems pretty large to me, but I fully understand that under the hood they have the same engine.  But bitcoin-qt has a lot more code, and has a much larger attack surface.

What are you going to attack on Bitcoin-QT that you can't attack on Bitcoind? The connection to the Bitcoin network is by far the most vulnerable place in both, and they happen to run essentially the same code.

The GUI code....  Yes, networking absolutely demands the tightest security and cleanest code, but that's exactly why most vulnerabilities are found in less important code.  It does not have as much attention paid to it.  Once you can execute arbitrary code, you can do anything you want with the network code or wallet code.  Hopefully the user doesn't unlock their wallet .

[hd060053]

where will it rebounce, 170, 160 ?

[ardana123]

Can someone post some working Mtgox price tickers?

[knight22]

Can someone post some working Mtgox price tickers?

http://btccharts.com/

[Odalv]

Can someone post some working Mtgox price tickers?

http://bitcoinity.org/markets/mtgox/USD