I'm getting this error: Your credit card payment failed with the error code "The configuration with processor is invalid. Call Merchant Service Provider." I tried two different credit cards. |
|
|
|
The encoded protocol buffer is just 55 bytes, wheras the bitcoin version is 85 0x00 sets (each one representing 2 bytes each I assume). This means that my badly designed protocol buffer is over half the size of the hand built layout!
The "0x00" groups each represent one byte. The length of the standard version packet is 87 bytes plus 20 for the header. The header could be massively optimized as well: message start "magic bytes" - 0xF9 0xBE 0xB4 0xD9
command - name of command, 0 padded to 12 bytes "version\0\0\0\0\0"
size - 4 byte int
checksum (absent for messages without data and version messages) - 4 bytes
Obviously using proto buffers here, while absolutely a breaking change, would save a fair bit of space, especially because the "I've created a transaction" packet has the name "tx" meaning that there's at least 10 bytes of overhead in every one of those packets. |
|
|
|
The reason I didn't implement listtransactions is I want to make sure web programmers don't use it. It would be very easy to latch onto that for watching for received payments. There is no reliable way to do it that way and make sure nothing can slip through the cracks. Until we have solid example code using getreceivedbyaddress and getreceivedbylabel to point to and say "use this! use this! don't use listtransactions!", I don't think we should implement listtransactions.
Why is it unreliable? It provides the same information that the GUI provides, and that works fine for watching for payments... When we do implement listtransactions, maybe one way to fight that is to make it all text. It should not break down the fields into e.g. comment, confirmations, credit, debit. It could be one pretty formatted string like "0/unconfirmed 0:0:0 date comment debit 4 credit 0" or something so it's hard for programmers to do the wrong thing and process it. It's only for viewing the status of your server. I guess that would be kinda annoying for web interfaces that would rather format it into html columns though.
We really shouldn't adopt a policy of protecting users from themselves. If we do, there should at least be a "devmode" switch or config line to turn it off. |
|
|
|
Coins - why the decision to not serialize them or otherwise uniquely identify individual coins? (This misconception seems to come up repeatedly)
Well, from the software's point of view, each 1.00BTC is actually 100,000,000 units. If you think the block list is big now, imagine how bad it would be if it were tracking 355,300,000,000,000 individual units! Accounts - why the decision not to keep a running balance by bitcoin address in the block list.
It's redundant data. It would help clients to verify transactions without having to (worst-case) verify the entire block chain, but it would also take up space in the block list. |
|
|
|
Some people have been suggesting that protocol buffers might be larger than the custom written packet layout. I suspect that actually it would be *smaller* due to some of the clever encoding used in protocol buffers.
I agree that it could be smaller; not necessarily because of clever encoding, but because it would allow us to drop reserved bytes and the like. To resolve this, I think a test is in order, I shall encode a wallet file/network packet using protocol buffers and compare the size the packets in the current scheme. However, I have no idea what's in a packet, what data is stored in a packet, and in what format?
That would be the hard part, of course. If you want to test with the version packet (not really ideal, since it's only sent once per connection), I've decoded that fully: http://bitcointalk.org/index.php?topic=231.msg6250#msg6250 |
|
|
|
It's called open source  The community is already guaranteed to continue. It would be useful if somebody else had commit access to the SVN and there was an explicit plan in place to continue in Satoshi's absence. |
|
|
|
I wonder if a better interface might be to follow 'listreceivedbyaddress' and print everything by default, only applying limits if limits were specified. ie. make your "count=0" the default.
Perhaps. In that case, you should switch the order of includegenerated and count. Perhaps even make includegenerated true? Generations are included by default in the UI, after all. |
|
|
|
|
Could you make count=0 return all transactions?
|
|
|
|
Very nice! Send Satoshi an email and ask him to add it to trunk. By the way, anyone having trouble applying this on unix can use: curl http://pastebin.ca/raw/1911295 | awk 'sub("$", "\r")' | patchThat'll make the line endings on the removed parts match the Windows line endings in the code files. |
|
|
|
The on google code or github wiki looks very nice to document our efforts. Could I get access to it?
Sure. I sent you a PM. Anyone who wants to be part of the project just drop me a PM with your Google Account / Gmail email address. |
|
|
|
|
Do you have a project page?
|
|
|
|
CDecker and I are working on reimplementing Bitcoin in Python. I'm not sure 100% what will come of this, but I plan to at least fully document the network protocol on our Google Code page: http://code.google.com/p/pybitcoin/ |
|
|
|
|
Just another reason to get working on over-the-wire encryption.
|
|
|
|
I'll answer the ones I can 2016 - Why does the difficulty adjust every 2016 blocks? Why not 2000, or 2048?
This is 2 weeks * 10 minutes / block. 2 weeks - Why does the block adjustment map to a two week period? Why not every week or everyday?
I think daily adjustments would be / have been better. Two weeks seems a bit arbitrary to me, and I see no disadvantages to making it happen more often. There isn't a low latency attack, since difficulty adjustments are tied to blocks and you can't successfully generate coins without the newest block. 10 minutes - Why do we want to generate a block every 10 minutes? Did this drive the above choices or is it a result of them?
I understand the trade off here; we're balancing speed of transaction confirmation with bandwidth usage and the risk of low latency advantage. If blocks were generated every 10 seconds, then people with a faster internet connection would have an advantage, which is against Satoshi's goal. However, if they were generated every hour, it would take at least an hour to confirm a transaction. BitCoin Addresses - Why use the hash of a hash (good idea!) for an address, rather than simply using the full public key.
Addr = RIPEMD160( SHA256( public_key ) ) This makes addresses 160 bits long (shorter = better for usability) but also ensures that the input to the RIPEMD160 is an unpatterned 256-bit number (assuming there are no flaws in SHA256). Certificates - Why not store public keys as part of standard 509 certificates, or in PGP format, The same for private keys.
I dunno - that's a good idea. I think there's a real advantage to being able to trade the keys independently of the Bitcoin network. |
|
|
|
On Debian testing 32-bit, I get a few build errors, all resembling: script.cpp:114: error: ‘OP_NOP1’ was not declared in this scope I got these when attempting to "make bitcoind" without "make clean" or "make" first. It looks like the bitcoind build instructions don't compile the headers first, but they also don't delete the headers.h.gch, so the old headers are used if present. If anyone else gets this error, the simplest solution is to "make clean" and retry the build. |
|
|
|
|
That already exists.
bitcoin -datadir=/path/to/files
|
|
|
|
I extracted just the speed-information bit added to RPC "getinfo"
Alright. I'll mail Satoshi my patch - maybe he'll accept it into the mainline. |
|
|
|
|
I too am a bit skeptical of the power of the spec in the merchant market, but I think it would be great for exchanges, which need to get scraped often.
The white/blacklisting stuff could be better handled by FOAF and the like.
|
|
|
|
|
So andyc, any comment on this? As the bcspec.org maintainer, it would be nice to hear your ideas.
|
|
|
|
|
Show Posts
