Re: [Bitcoin-development] Request for review/testing: headers-first synchronization in Bitcoin Core
On 12.10.2014 01:34, Pieter Wuille wrote: * No orphan blocks stored in memory anymore (reducing memory usage during sync). Will this slow down reorgs after a fork, compared to today? Regards, Geir H. Hansen, Bitminter -- Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://p.sf.net/sfu/Zoho ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.7 release planning
On 11.08.2012 20:56, Wladimir wrote: Duplicate strings are not a problem. Some strings are used multiple times in the program, and thus appear multiple times in the translation. This is because there are cases in which a string that is the same in English is translated differently in another language based on the context. That makes sense. But it's hard to translate when you just see the same string twice and don't know the context where it will be used. At least Qt translator fills duplicates in automatically, with the option to change them if desired. I'm not sure about Transifex but I've heard it's the same there. No, I just use copy and paste. Use UPnP to map the listening port (default: 0) Use UPnP to map the listening port (default: 1 when listening) The default depends on compiler flags, hence the two messages. I suppose the message could be split up, so that Use UPnP to map the listening port is factored out. Sorry, forgot there was a compiler flag for this. No need to split this up. As long as there is no explanation or description for each string I think it's easier to translate whole sentences. On 11.08.2012 20:32, Wladimir wrote: By the way, by far the most common support request I have at my pool is users withdrawing coins and not seeing it in their wallet because it's not up-to-date with the block chain. Might be worth adding something in the bitcoin-qt GUI to make it more obvious that users can't see new transactions and why. For 0.7 we've added a red (out of sync) warning to the balances when the block chain is out of date. Perfect. This will prevent a lot of confusion. Thanks! Regards, Geir H. Hansen, bitminter.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version 0.7 release planning
On 02.08.2012 18:43, Jeff Garzik wrote: There seems to be consensus that we should go ahead and do a release, before leveldb or ultraprune or anything major lands. There is no major landmark feature, but just a useful collection of small changes. It seems like a good time to Release Early, Release Often and make a checkpoint release. Looks like much goodness in this version. Thanks for all this work. Any chance that options to limit the size of blocks and prioritize paid vs free txes could make it in? By the way, by far the most common support request I have at my pool is users withdrawing coins and not seeing it in their wallet because it's not up-to-date with the block chain. Might be worth adding something in the bitcoin-qt GUI to make it more obvious that users can't see new transactions and why. 2) Translations update 2012-08-01 (fetched from Transifex) I just now updated the Norwegian translation on Transifex, if you'd like to do another pull before the release. For some reason there were many strings I had already translated that now had no translation and had to be done again (even ones that had the same English text). Many languages are now only about 50% translated. Also there were new duplicated strings: Verify a message to ensure it was signed with a specified Bitcoin address Sign a message to prove you own a Bitcoin address Clear All These two seem odd: Use UPnP to map the listening port (default: 0) Use UPnP to map the listening port (default: 1 when listening) Regards, Geir H. Hansen, bitminter.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] getmemorypool BIP process
On 04.03.2012 02:04, Luke-Jr wrote: On Saturday, March 03, 2012 6:51:34 PM Geir Harald Hansen wrote: Long polling as currently implemented in pools has a race condition. Does the miner reconnect first or does another block change happen first? Double block changes are common with merged mining and I'm doing all sorts of tricks in my pool backend to reduce this problem. How would you suggest addressing this? I presume if a share solves blocks on multiple chains, you just longpoll once when that's successful? If the client doesn't tell you which block change it saw last, you can't avoid this problem completely. How about another entry longpollid in long poll responses. The last seen longpollid should be included by the client in future long poll requests. This enables the server to see if the client has missed any block changes. The ID could perhaps be submitted in an HTTP header (X-LongPollID?) if we wish to keep the JSON-RPC params empty, or params could hold an object with a key longpollid. Could be a string or number, like workid. Hmm, the problem is that adding any parameters to getmemorypool itself breaks compatibility with bitcoind 0.5, and using HTTP headers makes it HTTP-specific again. Any ideas? I think long polling and reconnecting to LP is an HTTP-specific problem anyway? So it may be best to go with an HTTP header. See below for an idea for a capabilities reporting system, though, which would allow putting this data into JSON. Another useful value in the getmemorypool response would be height, so the miner can include the correct height in the coinbase. I would like that in bitcoind as well. One JSON-RPC call instead of two, and no race condition between getmemorypool and getblocknumber. Good catch. Should this be required (since it might be necessary for future Bitcoin blocks), or just should for compatibility? I think should makes sense. It should be explained how target vs. fulltarget works. What is unclear about this? Reading through it again it is mostly clear except for one thing, how to submit share/merkle style. It doesn't say exactly how to submit this data. It says merkle tree, but a merkle branch should suffice. Also, I believe the coinbase must always be the first transaction of a block? So we won't need the transaction's index in the merkle tree (it's always index zero). This would then be just an array of sha256 hashes making up the merkle branch for the coinbase. I'd prefer if block header, coinbase tx and merkle branch were submitted in 3 pieces. When merged mining and submitting a block generating proof to the aux backend you put an auxiliary proof of work between the block header and transactions. So the header and transactions are not necessarily adjacent. Also, there's no merkle branch in a regular bitcoin block. Perhaps some things should be optional for a client to implement? Doing this safely needs some way for clients to communicate capabilities to the server, which has the problem of passing parameters to getmemorypool. Let's add an optional servercapabilities key on the server side, the value being a space-delimited list of what's supported by the server. If that list contains clientcapabilities then the client may, instead of sending an empty request, send an object where one of the keys is clientcapabilities, and the value is a space-delimited list of extensions. Those names are a bit long, maybe caps is better. Ok, this is not entirely clean. For the first request the client won't know what the server supports. For subsequent requests I guess always assume the last caps the server reported. I think noncerange is of limited use and there's a good chance of getting the endianness wrong. There is no mining hardware to date that exhausts even half the nonce space, so I'd really prefer to see this as a required feature on the miner side. On the other hand, it's merely an extension for getwork, so I can see the problem so long as we're using getwork proxies. Yes, you can end up getting half a nonce range from an upstream server, and not being able to make use of it because your downstream clients don't support it. A single GPU can make full use of the noncerange if you allow the timestamp to slip a few seconds into the past. I believe most miners do that today. Also worth including are the hostlist and switchto getwork extensions. I think those can fit right into the JSON response, to keep with being transport-agnostic, but otherwise look like they do for getwork. Regards, Geir H. Hansen -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin
Re: [Bitcoin-development] getmemorypool BIP process
On 28.02.2012 23:06, Luke-Jr wrote: Please review and comment/critique: https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool Looking forward to implementing this in my pool backend and miner. A few comments: transactions add or remove transactions (both of the above; default if transactions omitted) In the above, you may want to specify that the transactions referred to here is the one in the first table (JSON-RPC response object) and not the mutations. For a moment I thought free tx editing was the default. Long polling as currently implemented in pools has a race condition. Does the miner reconnect first or does another block change happen first? Double block changes are common with merged mining and I'm doing all sorts of tricks in my pool backend to reduce this problem. How about another entry longpollid in long poll responses. The last seen longpollid should be included by the client in future long poll requests. This enables the server to see if the client has missed any block changes. The ID could perhaps be submitted in an HTTP header (X-LongPollID?) if we wish to keep the JSON-RPC params empty, or params could hold an object with a key longpollid. Could be a string or number, like workid. Another useful value in the getmemorypool response would be height, so the miner can include the correct height in the coinbase. I would like that in bitcoind as well. One JSON-RPC call instead of two, and no race condition between getmemorypool and getblocknumber. It should be explained how target vs. fulltarget works. Perhaps some things should be optional for a client to implement? I think noncerange is of limited use and there's a good chance of getting the endianness wrong. Regards, Geir Harald Hansen -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
