Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
There's a reason why luke-jr's pull request for CPfP remains open. There is general agreement that it appears to be useful. CPfP works to close the mismatch between how bitcoin transaction fees are attached by the sender, versus modern economic situations where the receiver is willing to pay a fee. On Sat, Jan 18, 2014 at 12:38 PM, Mark Friedenbach wrote: > On 01/18/2014 03:05 AM, Wladimir wrote: >> On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla >> >> >> >> regarding: >> stuff not getting into blockchain in a day's time, >> microdonations not facilitated as much as they could be, >> >> Please point to your pull requests improving these issues. >> >> If your organization didn't contribute anything to further these issues >> then there can't be much surprise that they didn't make it in, either. > > https://github.com/bitcoin/bitcoin/pull/1647 > > -- > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman wrote: > In the case where payment is being sent only to Q1, and Q2 is for discovery > only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 > byte vs 32 bytes in the OP_RETURN, and of course faster multiplication. > > 80-bits of security I assume still greatly exceeds the actual level of > privacy you get with the overall solution, and since Q2 is never protecting > actual funds... > > But if it's a "real weakening" of the privacy then definitely not worth it, > and even the added complexity of another curve seems possibly not worth it... Well super-fast hand optimized code for (your choice of) 160 bit curve may not ever exist, making it slower in practice. Plus the extra code to carry around even if it does exist… -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
> On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner wrote: >> Isn't there a much faster asymmetric scheme that we can use? I've heard >> people talk about ed25519, though I'm not sure it can be used for encryption. > > Doing ECDH with our curve is within a factor of ~2 of the fastest > encryption available at this security level, AFAIK. And separate > encryption would ~double the amount of data vs using the ephemeral key > for derivation. > > Using another cryptosystem would mandate carry around additional code > for a fast implementation of that cryptosystem, which wouldn't be > fantastic. > > So I'm not sure much can be improved there. In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication. 80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds... But if it's a "real weakening" of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it... -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
Like any other mechanism that puts extra data in the blockchain, the sender pays the fees. This mechanism is to improve privacy for static addresses (donation links on websites and so on). I personally don't think it will be used nearly as much as BIP0032 or the payment protocol (both of which don't need on-blockchain data), precisely because it increases the fees required to send funds, but this doesn't externalize costs anymore than any other use of the blockchain does. People who don't care about privacy and want smallest cost and maximum convenience already use SPV nodes. Their resource usage will not be affected in the least. On Sat, Jan 18, 2014 at 12:44 PM, Troy Benjegerdes wrote: > On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote: >> On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman wrote: >> > Choosing how many bits to put in the prefix may be difficult, particularly >> > if transaction load changes dramatically over time. 0 or 1 bits may be >> > just fine for a single user running their own node, whereas a central >> > service might want 4 or 5 bits to keep their computation costs scalable. >> >> Ignoring prefixes the cost for each reusable address is only a small >> percentage of the full node cost (rational: each transaction has one >> or more ECDSA signatures, and the derivation is no more expensive), so >> I would only expect computation to be an issue for large centralized >> services. (non-full nodes suffer more from just the bandwidth impact). > > I have not seen anyone address my high-level question to (somewhat) > complicated > mechanisms to keep coin flows private. > > Who pays for it? From what I see it's going to double the amount of data > needed per address, further centralizing 'full' nodes. I'm fine if the NSA > is paying for privacy (I actually trust them more than banks and advertisers), > but let's just be honest, okay? > > If socializing the cost of privacy is Bitcoin's goal, and giving the benefits > to a few that understand it and/or have the resources to determine privacy > providers that won't scam them, then say so, so I can get on with launching > a 'transparencycoin' with a modified code that explicitly ALWAYS re-uses > addresses, and has miners and pools that charge more for addresses they have > never seen before. I bet it will be more distributed and have about half the > average transaction cost of Bitcoin, because most people *just don't care* > about privacy if they get cheap and/or free services. > > > -- Troy, transparency advocate who is quite transparent that if you buy me > farmland, I'll shut up about transparency, because I'll be too busy growing > food and giving part of it away. > > -- > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? & spv-privacy (Re: Stealth Addresses)
On Wed, Jan 15, 2014 at 05:32:31PM -0800, Gregory Maxwell wrote: > On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman wrote: > > Choosing how many bits to put in the prefix may be difficult, particularly > > if transaction load changes dramatically over time. 0 or 1 bits may be > > just fine for a single user running their own node, whereas a central > > service might want 4 or 5 bits to keep their computation costs scalable. > > Ignoring prefixes the cost for each reusable address is only a small > percentage of the full node cost (rational: each transaction has one > or more ECDSA signatures, and the derivation is no more expensive), so > I would only expect computation to be an issue for large centralized > services. (non-full nodes suffer more from just the bandwidth impact). I have not seen anyone address my high-level question to (somewhat) complicated mechanisms to keep coin flows private. Who pays for it? From what I see it's going to double the amount of data needed per address, further centralizing 'full' nodes. I'm fine if the NSA is paying for privacy (I actually trust them more than banks and advertisers), but let's just be honest, okay? If socializing the cost of privacy is Bitcoin's goal, and giving the benefits to a few that understand it and/or have the resources to determine privacy providers that won't scam them, then say so, so I can get on with launching a 'transparencycoin' with a modified code that explicitly ALWAYS re-uses addresses, and has miners and pools that charge more for addresses they have never seen before. I bet it will be more distributed and have about half the average transaction cost of Bitcoin, because most people *just don't care* about privacy if they get cheap and/or free services. -- Troy, transparency advocate who is quite transparent that if you buy me farmland, I'll shut up about transparency, because I'll be too busy growing food and giving part of it away. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
On 01/18/2014 03:05 AM, Wladimir wrote: > On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla > > > > regarding: > stuff not getting into blockchain in a day's time, > microdonations not facilitated as much as they could be, > > Please point to your pull requests improving these issues. > > If your organization didn't contribute anything to further these issues > then there can't be much surprise that they didn't make it in, either. https://github.com/bitcoin/bitcoin/pull/1647 -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We rebroadcast incoming transactions without fees at several nodes, including bc.info, to keep them in mempools. On 01/17/2014 10:04 PM, Mark Friedenbach wrote: > CPFP is *extremely* important. People have lost money because this > feature is missing. I think it's critical that it makes it into > 0.9 > > If I get a low-priority donation from a blockchain.info wallet, > that money can disappear if it doesn't make it into a block in 24 > hours - bc.i will forget the transaction and happily respend its > inputs on the next transaction that user makes. > > I wouldn't mind paying $1 in fees to receive a $50 donation. But > without CPFP there's no way to do that. > > > On 01/17/2014 12:53 PM, Jeff Garzik wrote: >> BitPay sure would like to see CPFP in >> upstream. > >> I think the main hurdle to merging was that various people >> disagreed on various edge case handling and implementation >> details, but no fundamental objections. > > > -- > > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In > Between. Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJS2mbQAAoJEIilnEpWGBYhH+8H/2nIZjrrZIPi/4ZeTi71cZOe 78oD4mzWM9zvRbjbGfIWrgTnkRQi4OQ/GorbRiyoAeKzAQ+SdeY8dkRsS14zpqpC w4efoJOTxgi69giBWGPWlPvAtTwD65EcfJmUs5XeGi7J/3E0qTyry6sDu8t2ip84 hLUnqMOcNhc0J/k0KvBbEyl1YXcRWMjz5X2pMtY9yeMk+qFQPR1+RjZ+91OCRyui Z47jhHlbhc5daXAWrq4fb54uNSJWUnYky7yN2pDTovAVq5PNNVNJTdxbjXSyYmcP FwFNkARrgXRlSvf07FN991aa2u4CTkjRgA9uRrvcTtLXr8g2F0yymfPr0AQrgZg= =J9Z4 -END PGP SIGNATURE- -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
clarification, I am not a doge dev. It was intended just as a joke, to make you laugh. regarding pull requests improving these issues I am under the impression that the developers will take care of what needs to be taken care of in that regard. Am presently in collaboration on a bitcoin project that may implement aspects of the ABIS concept as presented, but it is in very very early stage(es). I hope you had a good laugh, that was my intent. good morning / afternoon / evening > On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla < > odinn.cyberguerri...@riseup.net> wrote: > >> >> >> regarding: >> stuff not getting into blockchain in a day's time, >> microdonations not facilitated as much as they could be, >> > > Please point to your pull requests improving these issues. > > If your organization didn't contribute anything to further these issues > then there can't be much surprise that they didn't make it in, either. > > that would be: >> >> very bad >> much news >> such fail >> >> Seriously, that would not be so good. >> >> Hope I made you laugh a bit >> > > So it's more like a jester's hat then :) > How did I end up on the dogecoin-development list?!? > > Wladimir > -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla < odinn.cyberguerri...@riseup.net> wrote: > > > regarding: > stuff not getting into blockchain in a day's time, > microdonations not facilitated as much as they could be, > Please point to your pull requests improving these issues. If your organization didn't contribute anything to further these issues then there can't be much surprise that they didn't make it in, either. that would be: > > very bad > much news > such fail > > Seriously, that would not be so good. > > Hope I made you laugh a bit > So it's more like a jester's hat then :) How did I end up on the dogecoin-development list?!? Wladimir -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
regarding: stuff not getting into blockchain in a day's time, microdonations not facilitated as much as they could be, that would be: very bad much news such fail Seriously, that would not be so good. Hope I made you laugh a bit > BitPay sure would like to see CPFP in upstream. > > I think the main hurdle to merging was that various people disagreed > on various edge case handling and implementation details, but no > fundamental objections. > > > On Fri, Jan 17, 2014 at 1:41 PM, Luke-Jr wrote: >> On Friday, January 17, 2014 11:44:09 AM Wladimir wrote: >>> On Thu, Jan 16, 2014 at 4:23 PM, Luke-Jr wrote: >>> > https://github.com/bitcoin/bitcoin/pulls/luke-jr >>> > >>> > These are pretty much all well-tested and stable for months now. >>> >>> #3242: Autoconf improvements needs rebase, and comment from jgarzik and >>> me >>> taken into account (about -enable-frontends=). >> >> I'll try to get this done over the weekend. >> >>> The others appear to be more controversial as they affect >>> mining/consensus. >>> I'd really like to see ACKs from more reviewers and testers there >>> before >>> merging. >> >> Can you elaborate on this? I can see how Proposals might, if buggy, >> affect >> consensus, but the rest shouldn't. I don't think there's anything >> controversial in any of these (does someone disagree with CPFP?). >> >> Luke >> >> -- >> CenturyLink Cloud: The Leader in Enterprise Cloud Services. >> Learn Why More Businesses Are Choosing CenturyLink Cloud For >> Critical Workloads, Development Environments & Everything In Between. >> Get a Quote or Start a Free Trial Today. >> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> ___ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > -- > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
