|
bootstrap.dat goes into the data directory. The same directory as debug.log and peers.dat are located.
|
|
|
|
|
It would be nice to have an "addr_v2" message, which supports a list of services. Or some non-propagated way of enumerating services, like a "list_services" P2P message. I've proposed such myself.
The main issues are thinking about how this gets propagated around the network properly, getting this info from various seeding mechanisms (if possible), and trying to avoid DoS issues.
Also, we have nowhere near 64 services, so there are plenty of bits available for use right now, with zero protocol modifications.
|
|
|
|
Based on what you're saying, it sounds like the wiki should indicate that the transaction count is a single byte then, not a varint?
It is a varint. The varint for zero is a single 0 byte. When the header is part of the block, it gives the transaction count. Based on Mike's reply and in the context of the headers message, though, it sounds like there shouldn't be a varint here, just a single zero byte. For zero that comes out to the same thing but I'm trying to understand the correct parsing behavior. If I ever see a non-zero byte in that position what would the correct behavior be? Consider the entire message invalid? Alternatively, if I ignore the difference I'd need to know if I should read just that last byte or if I should try to read it as a varint. /sigh You should endeavor to follow Postel's law. In this case, that means (using RFC2119 notation): If you are creating a "headers" packet, you must include a properly coded varint representing the number of transactions that are included in the packet. The number of transactions included must be zero. (The only valid encoding for zero is a single octet: 0x00. 0x05 is right out.)If you are reading a "headers" packet, you must parse that field as a varint. You should reject any packets that include a non-zero number of transactions. You may disconnect the peer that sent it, and attempt to publicly shame the authors of that implementation. Sadly this is one of those cases where it can be easy to get it wrong. It does seem worth investigating whether there was any breakage or behavior changes since 0.3.x days. We have changed CBlock to CBlockHeader and it is entirely conceivable that one might have output the "number of transactions" variable, and another did not. Worth checking. |
|
|
|
Where do you see a version field in the "getheaders" message?
"getheaders" has two parameters, locator and hashStop.
It says there is a version field in the protocol spec. However, I should have read it more closely, version means the protocol version, so nevermind. No, it is the version of the block-locator object. The wiki is unclear. "getheaders" receives two parameters, a block-locator object and a hashStop. Inside the block-locator object, there is a version for that locator data structure only. The version applies to the locator object, not getheaders message as a whole or hashStop parameter. |
|
|
|
What is the purpose of this field? Was it intended to only get headers of a particular version?
Where do you see a version field in the "getheaders" message? "getheaders" has two parameters, locator and hashStop. Of course, each block header has the block header version. |
|
|
|
They should be slammed about labelling it bitcoin 2 - it sounds like an attempt to hijack bitcoin, newcomers might buy in assuming it's the original.
"They are attempting to ride the coattails of the Bitcoin brand" |
|
|
|
|
The suggestion on github to permit selection of output format by file extension is interesting. e.g.
GET /rest/tx/TX-HASH.json (JSON-format expanded tx)
GET /rest/tx/TX-HASH.txt (binary serialized tx, hex encoding)
etc.
|
|
|
|
I've learned a lot from reading the bitcoinjs-server source, but couldn't make it work on Windows, unfortunately.
Hopefully node-libcoin will be a full replacement for bitcoinjs-server...  |
|
|
|
|
While 8 decimal places could be considered a magic number, it is one we may expand later, without impacting the total money supply.
|
|
|
|
|
Updated OP and pull request to remove non-standard "Bitcoin-Format" header, and instead use github-style "clean" URLs.
|
|
|
|
Yeah, OP_TRUE and the like are the same as a widely-known private key. I don't see what advantage you get from treating them different at the protocol level, though I suppose a smart client could attempt to inform the user if a payment they received was more likely to be attempted to get double-spent than average, but I'm not sure the user would or should do anything different in that case anyway.
No current client will tell the user "hey, I found an anyone-can-spend" nor list that in their balance. Clients pattern-match output scripts, and only "see" ones with scripts they recognize. All other transactions are simply invisible without special software to find them and spend them. |
|
|
|
Live with it ok, but we need to know what is the good behavior!
Doesn't this look like a crazy hack/bug?
Thus my question. For me it seems like someone has overlooked it at some point; "return 1" was supposed to indicate an error, but it was somehow overlooked and now it implicitly gets cast to (uint256)1 which is a pretty valid hash value, so C++ compiler does not complain and so nobody has noticed.. Don't you have the same problem in Armory? I cannot imagine reproducing the same behavior in python, just by repeating such a mistake. This was noticed a long time ago. It is just now being re-noticed by others I discovered this over a year ago while rewriting everything into python: https://github.com/jgarzik/python-bitcoinlib/https://github.com/jgarzik/python-bitcoinlib/blob/master/bitcoin/scripteval.pyCan you spot the problem? |
|
|
|
Are there plans for a call that returns a tx's merkle branch?
What is the use case? That data falls into the category of "public blockchain data", so it is OK to add that sort of data, if there is a use. Note that the JSON format of a TX outputs its confirmed block-hash, which enables discovery of a TX's merkle branch. |
|
|
|
Would it work on the port exposed by the JSON-RPC interface set in the bitcoin.conf? So for example: localhost:8332/rest/tx/TX-HASH?
Yes. Would you have to set tx-index=1 to get transactions with all spent outputs? The same way the getrawtransaction works at the moment?
Yes. |
|
|
|
So?? This means that the actual act of getbalance() is taking a long time or something?
They are doing the same thing under the hood: making a TCP connection to bitcoind, sending/receiving JSON-RPC data. |
|
|
|
A bit more information: Bitcoind is nowhere near as slow when doing it through shell? WTF?
Not sure I understand what this means. as I understand it, "bitcoind getbalance" is just calling the daemon with jsonrpc. It shouldn't be significantly different from your php script calling it with jsonrpc.
That is correct. "bitcoind getbalance" executes a new copy of bitcoind, which connects via TCP to an existing bitcoind, sends and receives JSON-RPC, then disconnects and exits. Not much different than using PHP or cURL to make JSON-RPC calls. |
|
|
|
Does anyone know something about stratum support by pushpool?
I would be happy to merge litecoin and stratum support into the pushpool repo, if someone created a pull request. |
|
|
|
URL: https://github.com/bitcoin/bitcoin/pull/2844Adding an HTTP REST API for bitcoind has been occasionally tossed about as a useful thing. Such an API would essentially provide a decentralized block explorer capability, enabling easy external access to transaction/address/block indices that we maintain. The first two implemented API calls are simple, returning a block or TX given a simple query string based on block hash, e.g. GET /rest/block/BLOCK-HASH
This can be easily accessed via command line cURL/wget utilities. Output formats -- binary, hex or json -- may be selected by append a "/json" or "/hex" suffix to the URL, e.g. GET /rest/tx/TX-HASH/json
The general goal of the HTTP REST interface is to access unauthenticated, public blockchain information. There is no plan to add wallet interfacing/manipulation via this API. |
|
|
|
|
Show Posts
