Can someone post some working Mtgox price tickers?
http://btccharts.com/
Topic: Wall Observer BTC/USD - Bitcoin price movement tracking & discussion - page 32145. (Read 26472772 times)
October 19, 2013, 01:19:08 PM
October 19, 2013, 01:18:00 PM
Can someone post some working Mtgox price tickers?
October 19, 2013, 01:14:27 PM
where will it rebounce, 170, 160 ?
October 19, 2013, 01:12:06 PM
Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.
Quote
[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.
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
. October 19, 2013, 01:09:10 PM
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.
October 19, 2013, 01:08:47 PM
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.
October 19, 2013, 01:08:05 PM
Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.
Quote
[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.
October 19, 2013, 01:04:01 PM
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? October 19, 2013, 01:03:21 PM
Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.
Quote
[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.
October 19, 2013, 01:01:47 PM
October 19, 2013, 12:58:14 PM
Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.
Quote
[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/pushtxHaha, thats actually not a bad idea. In times of doubt, blockchain.info to the rescue.
October 19, 2013, 12:56:54 PM
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/pushtxThat is a good example of a possible fallback they could implement, as I suggested.
October 19, 2013, 12:56:17 PM
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 October 19, 2013, 12:55:26 PM
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.
October 19, 2013, 12:54:43 PM
Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.
Quote
[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.
October 19, 2013, 12:53:31 PM
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 ~.~
October 19, 2013, 12:53:09 PM
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.
October 19, 2013, 12:53:01 PM
Also, I doubt they are using bitcoin-qt... I'm not sure where kazu got that from.
Quote
[22:33] <@MagicalTux> samson_: downloading new blocks as fast as bitcoind can
October 19, 2013, 12:52:15 PM
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!
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.
October 19, 2013, 12:51:06 PM
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.
there is a case to be made for using bitcoind. It's tried and true, community-reviewed and in widespread use.
It's a proof of concept, the kind you need to start with in order to rapidly develop a new application, but it's architecturally unsuitable for production use. As the Bitcoin ecosystem grows up, companies will be forced to migrate to something better suited to their use case. Jump to: