I have a hard time believing any of this without proof.

The solution is to eliminate the risk. Once 0-confirmation transactions can be reversed easily, the entire transaction fee issue can be basically forgotten about.

Until then, making it very difficult to send low-fee transactions is necessary. There are some types of transactions that will be universally rejected.

You could add additional inputs or remove some of the inputs if there were several. You could even change the input scripts (as long as they still work).

I restored those four.

Send me the links of deleted threads, and I'll investigate. I think you just hit "remove topic" instead of "set topic non-sticky"...

 

It wasn't me...

Which threads were deleted?

It's strange because the outputs are of different types. It's a mixed pubkey/address transaction.

This isn't really strange, since really old versions used to do this. I changed it to say "mixed types".

The balance is totally useless for anything like this, as you've seen.

If anyone claims that Bitcoin is somehow associated with Linux, remind them that Bitcoin was originally developed on Windows, and the first version was Windows-only with no command-line at all.

Don't scrape the HTML pages. There are better API pages:
http://blockexplorer.com/q/getreceivedbyaddress
http://blockexplorer.com/q/mytransactions

The way you cancel it is by sending a locked transaction using the same coins. Then your other transaction becomes invalid.

If the merchant is malicious, you would want to cancel the transaction a few days before it becomes locked. Otherwise they have a chance of getting their version in a block before your version.

You can change anything if you own all of the inputs. You can even reverse it. Miners can tell because the inputs of the new transaction all have higher sequence numbers than the old ones.

With the non-default SIGHASH modes, multiple people can contribute inputs into a transaction. Then you can only change certain things, depending on the mode.

They are the same. getblocknumber is obsolete.

It used to be that getblocknumber would return the highest block number, while getblockcount would return the total number of blocks. Confusingly, this behavior was switched when getblocknumber was made obsolete, so getblockcount now actually gives the highest block number.

The total number of blocks is different from the highest block number because the genesis block is block #0.

Thanks a lot for all the offers! I will consider them all tomorrow.


I would prefer that someone else maintain it, though I can do it.

I won't accept physical machines sent to me, as one of the main things this is meant to solve is situations when my power or Internet is offline.


ABE has reduced functionality.


I'll probably need more than 2GB in the long-term.


I will consider this if load becomes the main problem, but I'm really trying to solve downtime right now. This request was prompted by the fact that my Internet access will be down for a day or two in the near future.

To get the performance that BBE currently has (which is not perfect), I give PostgreSQL almost my entire 3 GB of memory. Linode charges $160/month for 4GB. Less memory will equal less performance unless disk speed is much better (which I doubt will be the case with any VPS).

They don't have to store it. The network will forget about your 0-confirmation transactions after a few days if you don't rebroadcast them.

Yes, it's lock_time. Each input's "sequence" is also related to this.

There are many features that are not exposed. Check out:
https://en.bitcoin.it/wiki/Contracts
https://en.bitcoin.it/wiki/Script

Edit: I no longer need a mirror.

I need someone to run a permanent mirror of blockexplorer.com. I will switch to the mirror while doing maintenance, and I will share load with it in times of heavy load.

You will need to agree to these terms:
- Your mirror will only be accessible via IP address when it is not blockexplorer.com
- Your mirror will be excluded with robots.txt when it is not blockexplorer.com
- You may not allow the code to be released
- You may not base any software off of my code
- You may not automatically publish any data gotten from the BBE database

You can, however, use the local BBE database to gather information that you use privately or manually publish. You can publish the IP address for times when BBE is unexpectedly down.

Requirements:
- PostgreSQL
- PHP with sockets and bcmath
- Some web server able to alias all requests to one file (I use Apache)
- The ability to compile Bitcoin with my modified version of getblock

Typical load is about 800,000 requests per day, with a burst of perhaps 1.5 million requests per day. Most of these are quite small, however. Average upload is 60 KB/s. My server has a Pentium D 3.4GHz CPU with 3GB of memory, and it's doing alright for now.

You must be extremely trustworthy, as I will share the HTTPS private key.

PM me if you are interested.

The Bitcoin node at 99.27.237.13 is permanently moving to a different IP address in about a week. This node was in the first set of seednodes and the first version of the "fallback nodes" page, and it is blockexplorer.com. It is possible that you are connecting to it with -addnode. Please check your configuration and remove this IP if it exists.