Re: [Bitcoin-development] [PATCH] Change recommended fee to 0.001 BTC
On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr l...@dashjr.org wrote: On Monday, March 11, 2013 8:34:52 PM Rune Kjær Svendsen wrote: Ok. I'll fork on Github. Looking at the source, and some Qt documentation, it should be doable to do string substitution for both the value and the unit. Side note: I imagine you'd be substituting a formatted string, and using some other function to format the string (which already exists to decide how to display units elsewhere). I'm not entirely sure what you mean by this. I plan on using the method described on this page http://doc.qt.digia.com/3.1/i18n.html under Use QString::arg() for Simple Arguments and then just putting a %1 and %2 in the translation strings and substituting for value and unit, respectively. Haven't tested it yet, but that's what I plan to do. Where do you want the constant defined? In main.h alongside MIN_TX_FEE and MIN_RELAY_TX_FEE? /Rune -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Implementing batch processing for -blocknotify
Hello dear list I have an application that wants to keep up with new blocks as they come in. For that I can use the -blocknotify option with bitcoind, which will execute my application for each new block. The problem is that my app isn't necessarily quick enough to finish its work before a new block comes in and the app is executed again. This means the that bitcoind might keep executing my application even though the previous instance hasn't finished, and that's fairly inefficient resource-wise, as many instances of the application will be running simultaneously. I've discussed this with wumpus on bitcoin-dev, and we figured out a solution that might be better. It could replace -blocknotify or we could put it in a new function called -batchblocknotify The idea is that when bitcoind is executed with the -batchblocknotify option, and it's missing a lot of blocks, upon the first incoming block, the command specified by -batchblocknotify is executed, and if additional blocks come in while this command is still running, we add the block hashes to a list instead of executing the command again. When the previous command finishes, we execute it again and pass two parameters to it: 1. the first block hash in the list of queued blocks, and 2. the number of blocks that have come in while the last command was executing. This prevents bitcoind from fork bombing the system, and allows the command to handle incoming blocks in batches. Would this make sense as an approach? I've been looking at the code and I'm not sure how to implement it. As far as I can see, I need to pass an object - whose state is retained between calls - to the thread function (runCommand) that runs the command, which contains a variable that keeps track of whether a previously executed command is still running, and that contains a list of block hashes that haven't been processed. And I'm not sure how to do this. The runCommand thread is started in SetBestChain() in main.cpp. SetBestChain() is executed by ConnectBestBlock() in main.cpp. ConnectBestBlock() is executed by CBlock::AddToBlockIndex() in main.cpp. CBlock::AddToBlockIndex() is executed by CBlock::AcceptBlock() in main.cpp. CBlock::AcceptBlock() is executed by ProcessBlock() in main.cpp. ProcessBlock() is executed by ProcessMessage() in main.cpp. And so on, and so forth. What's the right way to create an object that can be passed to the runCommand thread, whose state is retained, so it can hold information about whether the -batchblocknotify command is still executing, and contain a list of blocks that are waiting to be passed to the -batchblocknotify command? I assume I shouldn't add a new parameter to the ProcessMessage() function, which passes it to ProcessBlock(), which passes it to AcceptBlock() which passes it to AddToBlockIndex()... and so on. Would it be appropriate to store this object inside the CValidationState class that is passed to SetBestChain()? I'm not quite so how to go about this. /Rune -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Implementing batch processing for -blocknotify
On Fri, May 31, 2013 at 2:10 PM, Michael Hendricks mich...@ndrix.orgwrote: On Fri, May 31, 2013 at 5:56 AM, Rune Kjær Svendsen runesv...@gmail.comwrote: I have an application that wants to keep up with new blocks as they come in. For that I can use the -blocknotify option with bitcoind, which will execute my application for each new block. The problem is that my app isn't necessarily quick enough to finish its work before a new block comes in and the app is executed again. In a similar circumstance, I changed my -blocknotify script to quickly append necessary information to a queue and immediately exit. A separate script runs at all times monitoring this queue for work and performs the labor intensive calculations. I've thought about this as well. It just seems somewhat clunky to me. I'd really prefer having bitcoind put out messages in batches, if it's doable, that is. I'd run into a lot of concurrency issues, as far as I can see, where I can't be sure that the queue isn't written to while, for example, it is opened by the program that needs to process the queue items. What if a disk operation takes a long time to finish, and a two queue operations want to add to the queue simultaneously? This really brings forward all the horrors of concurrent programming. On Fri, May 31, 2013 at 2:17 PM, Jeremy Spilman jer...@taplink.co wrote: Would it work to just block the bitcoind thread until your process exits? I don't think that's optimal, no. That would slow down synchronization drastically. It would be really nimble for bitcoind to be able to synchronize at full speed, and only send out events when necessary, batching together previously queued items. -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] HTTP REST API for bitcoind
I think this is a useful feature, but I din't see why it should be a part of bitcoind. I've created a simple HTTP REST wrapper around bitcoind's RPC interface in Python: https://github.com/runeksvendsen/btchttp/blob/master/btchttp.py It simply runs a HTTP server that translates HTTP GET requests into the relevant RPC request, and responds to the GET request with the relevant data. /Rune On Tue, Jul 23, 2013 at 9:36 PM, Mark Friedenbach m...@monetize.io wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/23/13 3:29 AM, Andreas Schildbach wrote: Yes, I understand that. For this reason, I would vote for adding the usual HTTP authentication/SSL stuff to the REST API. That way, SPV users can decide to run their own instance of the API (providing the needed resources themselves). Or, a trusted party can set up a server. For example, I would be willing to set it up for users of Bitcoin Wallet. I don't expect shitloads of paper wallets sweeps for the forseeable future. Anyone who wants HTTP authentication or TLS can wrap it with nginx, or something similar. In the process they could put appropriate restrictions in place on incoming requests, and the onus would be on them, not us to keep it secure. Mark -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR7ttWAAoJEAdzVfsmodw4UmIP/36lK2TDc7mLTT8rbflJhl3v TL4CFKhXj6OuzG7tyino3Djs4EQnyk+CbpfOmJ8kYr29GPaZttuDJhYXtJqQBQCi DPq79ktudHnVMLPirEs7dUrLo+TAqhYX+8Sj+eTlW+p6YZg3JbkOAIPJG7597OK4 zzU8Oxr0XKJFfGscKfkPThxJboNqzJYGl3otHUMXM4HsbIRYmrx4QSr8y7dsVgTd YZnD4bJO+eY4ZPzCcFdkPD/8bXQyKC5nPOH8/79lARNLESwB4OW79uf9q86EuH2O jZQ1qwpRNHblrNWS1/U2E4+7hEidvgZBwQhj+HbWgKiPWh4Df1lEXq6bLQQwdn6/ b+jfiwg7xpb7eB2M4gPZ0uF/1TIcGJN3+LWEULFNTT/vsjyD/UU63ahZ1kVv7X0m W1NrbKjXxDbip+x3N7HLIu3zqAAaa0ele7OysyFCL6ZlwwafwJiEZZgHn2Iw7I1L S7lYBbFoLfXlOMVXNaKHPEV5gQEveMROJVBtnWkqShPQM0N/+Z+TXZes37up0GVo d7ptPfNbUNDTFc8Jj3+5rIyy3dUvSyMJlHZhsLmtCUnbQ867ZOgeUS52a8XQ+nJY 8IsShLfLk6fRWmHrwo9lzZQ/TbbUNyoUje0Ns6iL7G3IZwDqJH3kAGb/bkj/piDu tPNcN8bkYeNobTFIH+o4 =jV80 -END PGP SIGNATURE- -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
Instead of trying to remove the possibility of transaction malleability, would it make sense to define a new, canonical transaction hash/ID (cTxID), which would be a hash of the part of the transaction data which we know is not malleable, and have clients use this cTxID internally, thus making the traditional transaction hash irrelevant for a client to function correctly? We already have a non-malleable transaction hash: the hash that is signed, ie. the transaction with each scriptSig replaced by the scriptPubKey it redeems. This could be the cTxID. Or is this simply a too fundamental change to the way bitcoin-qt (and all other clients) work in order to be feasible? As far as I can see, it completely solves the issue of not having a canonical ID for a transaction, but it also increases the computational requirements for a node. For one, as far as I can see, it requires the node to index all transactions, because in order to calculate a cTxID, it would be necessary to fetch all transactions referred to by the transaction in question, in order to pull in the scriptPubKeys that are redeemed. On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd p...@petertodd.org wrote: On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote: Hello all, it was something I planned to do since a long time, but with the recent related issues popping up, I finally got around to writing a BIP about how we can get rid of transaction malleability over time. The proposed document is here: https://gist.github.com/sipa/8907691 I expect most rules to not be controversial. Maybe rules 1 and 3, as they require modifications to wallet software (Bitcoin Core 0.9 and BitcoinJ already implement it, though) and potentially invalidate some script functionality. However, these new rules remain optional and controlled by an nVersion increase. Comments please! You should probably add making CHECKMULTISIG require the dummy value to be exactly equal to OP_FALSE; verifying that in the transaction itself is laborious. A more subtle example is we may want both CHECKSIG and CHECKMULTISIG to fail the transaction if the signature is invalid but not exactly equal to OP_FALSE; some transaction forms are significantly more compact if you can have failed signatures, but that's a source of malleability. (are there counter examples people can think of?) But as I said on IRC, I'm a bit hesitant to bake in assumptions about malleability when we have no solid idea if ECC signatures are or are not malleable on a fundemental level; if whack-a-mole anti-malleability is all we've got it could be ugly if a break is found. Similarly, we may find we missed something, or some needed change makes the malleability rules difficult to work with for some new script type that is required. I'd rather see a new CHECKSIG mode for the case where malleability absolutely must be eliminated - certain multi-party protocols - and fix wallet software instead. (the malleability problems people see are closely related to inability to handle double-spends and reorgs) But I can easily see that being an impossible goal engineering wise... -- 'peter'[:-1]@petertodd.org 0001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1 -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] IMPULSE: Instant Payments using the Bitcoin protocol
Hi list Found this on reddit: http://impulse.is/ PDF: http://impulse.is/impulse.pdf I'd love to hear this list's thoughts. /runeks -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
