Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/18/13 8:09 PM, John Dillon wrote: On the other hand, a tx with some txin proofs can be safely relayed by SPV nodes, an interesting concept. Do the UTXO commitment people have keeping proof size small in mind? More than a kilobyte, probably less than a few tens of kilobytes. It depends on parameters (branching factor, script vs hash(script)) that are tweakable with time/space and long-term/short-term tradeoffs. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSEakMAAoJEAdzVfsmodw4B9wQAIu82nxMAyMiTpFcWW6v0fQ9 26bzOznyIhzAlFUeCXvgwtqoxjRcheLOnsFsAr0TLdLYrx00o4+MS0GepV40gEpd Ds/itvAnW8aWdCls0qy1hljWrsp8R3IfXWchXy13kjOhTIx8JaALeHEzOCsJVxCf nWrV7UNLRO1eXhLUnFLnZ3/HdljMZnLqLexSGXorn4I2zwg5HGNMJxIenU3vDj8s 68k4rSk/eUptG97ZmJxCysn7nt5F1cxRutsVOPxsC/4+FptMYf9YJRJDNpvttYyl ztI2xV+ARfEvSZs0lqGAcpvKwVV4IvZDGXhUCiS6LQ99tvMid4kjIGYPwlyK6SJW LoYVbvjbauEIPn4URW8XilMB5EEJisr5/7ZV/aDLEFcBA/is5ePuQioo/81yOWUw k5PghJ/TBMBQhxOGCz86onCI1YwrWfhu2sz6xNIHm9lbyZQcw3N/ai77FQqxxkxp iBbIAvhk4sQ7lPt4QHmiL4isPzaiScKVTjvzfc5hAHSmu6xQysf8VA/SwUSgAJZB iUPYRz5URaw8a/WDlo7YA6BRV/l7RloEcWGs6br3jVYxtJSaxqDwwrUV3SdDtzBR uiE1OVPp8ihY3OJbnZkbvy3lXXlLjwrLVwMUgprhUo793QtktZH+O0V+StcGKLGD 4rdK6Z3C8Wx9FY2fvkBy =HZdx -END PGP SIGNATURE- -- 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
[Bitcoin-development] CoinWitness: Really Really ultimate blockchain compression
I've posted a somewhat blue-skies idea on troll^wBitcointalk that some here might find interesting: https://bitcointalk.org/index.php?topic=277389.0 -- 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] Gavin's post-0.9 TODO list...
On Mon, Aug 19, 2013 at 5:09 AM, John Dillon john.dillon...@googlemail.comwrote: Here's another question for you Mike: So does bitcoinj have any protections against peers flooding you with useless garbage? It'd be easy to rack up a user's data bill for instance by just creating junk unconfirmed transactions matching the bloom filter. Unconfirmed transactions that are received show up as unspendable and in most wallets they have a little graphic that changes as more peers announce the tx. So if a peer sent non-existent transactions then they'd allow show up as seen by only one peer, which would look different to how normal broadcast transactions show up. Whether users really notice this graphic or understand what it means is debatable, of course, but all Bitcoin wallets have that problem. I've yet to see any that would successfully communicate the notion of confidence to new, untrained users. That's why the default is to not let you spend unconfirmed transactions, unless they were created by yourself (you're allowed to spend change). bitcoinj does not attempt to handle DoS attacks by malicious remote peers today, because such an attack has never been observed, has no obvious profit motive and as you don't get to choose which nodes the wallets connect to it'd be difficult to pull off. Unless you control the users internet connection of course, but that's a well known caveat which is documented on the website. -- 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
[Bitcoin-development] Proposal: remove getwork RPC from bitcoind
Pull request https://github.com/bitcoin/bitcoin/pull/2905 proposes to remove getwork RPC from bitcoind: https://en.bitcoin.it/wiki/Getwork On mainnet, almost everybody uses a pool (and therefore, not getwork directly to bitcoind). Those few who solo mine use a pool server to talk to bitcoind via getblocktemplate or other means. Tests show that attempts to solo mine on mainnet via getwork lead to delays and problems. On testnet, getwork has a better chance of continuing to work. Nevertheless, the same tools (open source pool servers or p2pool) are available for testnet, obviating the continued need to support getwork. However, at one time, getwork to bitcoind was widely used. I wanted to poke the audience, to gauge response to removing getwork. If a driving use case remains of which we're unaware, speak up, please. We don't want to break anybody needlessly. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind
On Mon, Aug 19, 2013 at 10:09 PM, Frank F frank...@gmail.com wrote: I strongly object to removing the only mechanism that allows anyone to say that bitcoin is p2p, in the truest sense of the word. Moves like this that favor only the pool operators and private mining interests are signs that bitcoin is headed towards a monopoly/cartel model, and that would be a tragic outcome for something that holds a great promise. Nobody knows what mining will look like in the future, and denying the individual novice the ability to mine at a small scale, even if we may think it is inefficient now, is not a good path to start down. If there are technical problems with getwork, maybe they should be addressed and fixed instead of outright abandoned. They were addressed and fixed in a successor API, getblocktemplate. It's even more decentralization-friendly, as it allows the caller to see what transactions the daemon is trying to put into a block, and even modify it. The suggestion here is not to remove functionality - only to remove an obsolete API for doing so. -- Pieter -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind
On Mon, Aug 19, 2013 at 1:09 PM, Frank F frank...@gmail.com wrote: If there are technical problems with getwork, maybe they should be addressed and fixed instead of outright abandoned. They have been, resulting in a replacement called getblocktemplate which (presumably) almost everyone talking to bitcoin(d|-qt) has been using for a long time. I think removing the ability to mine in the stock package would be regrettable, but to be honest we already don't have it for the mainnet. I think we should do as Jeff suggests and remove getwork. But I think we should also package along a proper getblocktemplate miner to remove any doubt that we're providing a full network node here. (I note that the choice of miner is also easy: Regardless of people's preferences which way or another, AFAIK only luke's bfgminer stuff can mine directly against bitcoin getblocktemplate with no pool in the middle. It also supports a huge variety of hardware, and a superset of our target platforms) -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind
FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned people that getwork will be removed in the next major version. Pooler's CPU minerd which supports both sha256d and scrypt recently grew stratum support. Perhaps he could be convinced to add GBT support too, which would help this goal of completely removing the internal miner and getwork. Warren On Mon, Aug 19, 2013 at 10:23 AM, Gregory Maxwell gmaxw...@gmail.comwrote: On Mon, Aug 19, 2013 at 1:16 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I think removing the ability to mine in the stock package would be regrettable, I am naughty and should clarify. I had ass.u.me.d that Jeff's patch also removed the internal CPU miner, because doing so is necessary for actually getting rid of most of the getwork code. It doesn't actually. Though this doesn't change the fact that the internal miner is mostly a pretext for integrated mining. Since it only really works on testnet it also means our testnet testing using it is not a good test of the actual production software. I'd rather remove the internal miner too, getting rid of the extra code and complexity, and package up a GBT miner which would actually be usable on the mainnet. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind
On Mon, Aug 19, 2013 at 4:33 PM, Warren Togami Jr. wtog...@gmail.com wrote: FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned people that getwork will be removed in the next major version. Pooler's CPU minerd which supports both sha256d and scrypt recently grew stratum support. Perhaps he could be convinced to add GBT support too, which would help this goal of completely removing the internal miner and getwork. The internal miner is still actively used for testnet, here. -- Jeff Garzik Senior Software Engineer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind
Removing getwork and the old miner and packaging a better miner seems the best solution for the reasons already mentioned. Not directly related, but this remembered me that we planned to remove the accounting features on freicoin. We don't want to adapt them for demurrage and we think business shouldn't use it and should code their own accounting system instead. One that keeps a full log of the accounting, etc. Unfortunately the first exchange to support freicoin (cryptonit) used this feature for accounting user balances on the exchange. So the question is, is there any good reason to maintain this? Is any serious business really using this or anyone at all? I'm talking about removing the following rpc calls: getaccount getaddressesbyaccount getbalance getreceivedbyaccount listaccounts listreceivedbyaccount move sendfrom setaccount ...and modifying these: getnewaddress listreceivedbyaddress listtransactions sendmany I think this would also leave a cleaner API, but I'm just interested on what the objections would be to this removal. How crazy does this sound? Should we reconsider their removal for freicoin, proceed or create a pull request for bitcoin? -- Jorge Timón http://freico.in/ -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind
On 08/19/2013 10:34 PM, Jeff Garzik wrote: FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned people that getwork will be removed in the next major version. Pooler's CPU minerd which supports both sha256d and scrypt recently grew stratum support. Perhaps he could be convinced to add GBT support too, which would help this goal of completely removing the internal miner and getwork. The internal miner is still actively used for testnet, here. Here, too. If I'm too impatient to wait for the next block that is. I think it'd be a pity if the easy way to mine blocks would be removed. -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72
On Tue, Aug 20, 2013 at 8:15 AM, Andreas Petersson andr...@petersson.atwrote: I was just reviewing the integration work to integrate the Payment Protocol into our products. Is there any notion of a standardized invoice serialisation? If i pay for two Burgers and one Club Mate, how would my Bitcoin Wallet be able to know that? No. There are XML-based (shudder) standards for electronic invoicing that include all sorts of bells and whistles; the PaymentDetails message could easily encapsulate one of them in an 'invoice' field extension. Or we could reinvent the wheel and come up with our own, but I'd rather use an existing standard (or maybe a subset of an existing standard). I didn't want to wade into that swamp for the 1.0 version of the payment protocol. Right now, i would simply put that into memo and come up with my own serialisation mechanism. Two Burgers, one Club Mate seems pretty user-friendly. Second, is there a way to communicate acceptance levels of TX (unconfirmed, 1 conf, 6 conf) maybe using several PaymentACK? No, because the Payment-PaymentACK communication round-trip is done in one, non-persistent http request-response round-trip. I don't think we want to allow merchants to push messages to the wallet (wouldn't take long for merchants to use the opportunity to push annoying advertising at me, I think), and I don't think we want wallets to poll the merchant. Although maybe a payment protocol version 2.0 feature could be a PaymentACK extension that says ask me how the transaction is going at THIS URL in THIS many minutes. -- -- Gavin Andresen -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
