|
Does anybody have estimates of total, worldwide USD or EUR transactions in an average 10-minute timespan?
|
|
|
|
- getblockbyhash <hash>
Returns details of the block with <hash> (hexadecimal). - getblockbynumber <number>
Returns details of block <number> in the longest block chain. - gettransaction <hash>
Returns details of transaction with <hash> (hexadecimal).
Your changes appear to come darned close to superceding my getblock and listtransaction patches. With a few minor changes, you can completely supercede my patches: - add listtransactions or gettransactions, calling your txToJSON, for each wallet tx matching the given query parameters
- add the following fields to txToJSON from my patch: bitcoin address, label, category (credit, debit, generated, etc.), amount
- any reason why you didn't use 'getblockbycount' as elsewhere discussed? I named mine that based on your own logic
|
|
|
|
Come to think of it, maybe I should combine the getblockby* routines into one; there's no chance of mistaking a 64-character hex block hash for a 5-digit (or, in many years, a six or seven or ten digit) block number.
I thought about that before, too, but the rpc interface is internally typed. Sure, we can specify a string for the parameter, and interpret the string as either a block hash or a block number, but satoshi might grumble at the overloading of parameters? None of the existing RPC commands have multi-use parameters. |
|
|
|
|
My preferred arrangement would be a 'monitorall' command, which POSTs each incoming transaction to a URL, regardless of bitcoinaddress, as long as it's a wallet transaction.
|
|
|
|
I thought bankers are superconservative folks that would never go near something like bitcoins. Of course, I was wrong.
The same superconservative folks that dumped tons of money into subprime mortgages?  |
|
|
|
For those that remember, I got my Bitcoin article published this month @ elliottwave.com
What is the permanent URL for that article? My search skillz do not turn up anything on this forum or google. |
|
|
|
As noted in this wiki page and in this satoshi post, the -paytxfee switch may be employed give your sent transactions "priority." Prioritized transactions appear to be defined as increasing the likelihood that a transaction will be included in a block, even if that block is very large (byte-wise or tx-wise). Considering that 99.9% of blocks are outside the range that will incur tx fees, it can be said that tx fees are largely useless today. But it makes me curious... Are there any other areas of the bitcoin client or network that could somehow prioritize transactions based on tx fees? Examples: - if you have a list of transactions to send out to the network, send prioritized ones to more connected nodes
- restart mining work immediately if priority tx arrives, but continue working on existing block for a while, if free tx arrives
And with my businessman's cap on, I would think it prudent practice for any bitcoin business to use -paytxfee=0.02 by default, just to be safe, guaranteeing priority on the existing network and existing clients, in cases of extreme network load. Other comments about how to use tx fees welcome... I strongly believe that a healthy tx fee structure is important to the long term health of the bitcoin P2P network. |
|
|
|
Some people might want to add the
pcoin->GetDepthInMainChain() < 1
in GetBalance() too.
Well, I would rather split "balance" in two: confirmed and unconfirmed balances. |
|
|
|
At (roughly) line 3191 in main.cpp (SelectCoins), change the if statement to this: if (!pcoin->IsFinal() || pcoin->fSpent || pcoin->GetDepthInMainChain() < 1) Your client will then no longer consider coins with 0 confirmations when choosing coins. IMO, this should make it into the upstream bitcoin client, as either - a command line switch, requiring confirmation for all sent coins
- a two-pass search: search first for confirmed coins. if not enough confirmed coins are available, use unconfirmed coins.
|
|
|
|
Patch updated to latest SVN, and for a change suggested by gavin: - sort by time, after sorting by number of confirmations
|
|
|
|
|
Patch updated for latest SVN.
|
|
|
|
Patch updated to latest SVN, with a few of the suggested gavinchanges: - 'getblock' renamed to 'getblockbycount'
- s/ver/version/
- vin_sz and vout_sz removed, redundant
|
|
|
|
How could there be a 'kill switch' at all? Wouldn't that both require that the internet protocal be rewritten to not route around censorship as if it were a fault as well as require that every major nation worldwide agree that the president of the United States should have such a power over their domestic infrastructure?
They can shut down the major exchanges, such as the ones formerly known as MAE-East and MAE-West, or the one in Tampa. |
|
|
|
Jabber also presents another interesting opportunity: anonymous exchanges via Jabber. Someone sets up an exchange at MyExchange@example.com jabber address, and publishes an API. Users send and receive PGP-signed Jabber messages at MyExchange@example.com, instructing the software to buy and sell BTC for Pecunix / Paypal / etc. |
|
|
|
Today's Financial Times: Brazil in ‘currency war’ alertAn “international currency war” has broken out, according to Guido Mantega, Brazil’s finance minister, as governments around the globe compete to lower their exchange rates to boost competitiveness.
Mr Mantega’s comments in São Paulo on Monday follow a series of recent interventions by central banks, in Japan, South Korea and Taiwan in an effort to make their currencies cheaper. China, an export powerhouse, has continued to suppress the value of the renminbi, in spite of pressure from the US to allow it to rise, while officials from countries ranging from Singapore to Colombia have issued warnings over the strength of their currencies.
|
|
|
|
Just seen that in the bitcoinwatch.com site we have Russian Rubles included. Great progress! Where is EUR and JPY? Where is an open market for EUR and JPY? |
|
|
|
|
This scheme is also stupid because it will make businesses and individuals more vulnerable to criminals and industrial espionage.
|
|
|
|
I heard some guy has 25% of all bitcoins. What happens if he will trade it for dollars on the market? He has LOTS of coins so he may offer low price for them and everybody will buy it from him. Then it will cause inflation and lowering the exchange rate greatly for many months if not years. Will bitcoin cope with such a disease? We don't talk about motives of that dude. He may do it just for lulz or whatever. He might get all those bitcoins when the difficulty was low or he has a large cluster that generates blocks on a large scale. The same goes to all large generating clusters which may ruin the economics instantly.
Any thoughts on it?
Anyone with lots of coins may disrupt the bitcoin economy. However, maintaining high level of bitcoin monetary value is an obvious incentive against dumping a huge number of coins on the market all at once. Selling 1 million bitcoins at once will fetch much less money than selling 1 million bitcoins slowly, over time. Bitcoin dumping is likely only to occur in (a) panic selling or (b) griefer scenarios. |
|
|
|
|
Is there an index that indexes all transaction ids for all blocks?
Or should 'gettransaction' only work for wallet transactions?
|
|
|
|
These already exist. They are called coyotes... |
|
|
|
|
Show Posts
