[Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
Hello all, It has been way to long since last major release. Many improvements and new features have been added to master since, so we'd like to do a 0.9rc1 release soon. The current aim is next month, February 2014. Of course there are still some open issues that need to be resolved before release https://github.com/bitcoin/bitcoin/issues?milestone=12state=open If there is something else that you're working on and needs to end up in 0.9, or know of some nasty bug in master that should absolutely be solved first, please tell. 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=119420431iu=/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 Thu, Jan 16, 2014 at 7:26 AM, Gary Rowe g.r...@froot.co.uk wrote: I like reusable address. Simple and clear, I like it too. I see the term is routing is used in finance in the USA, but as a Dutch person I associate routing address with network routing, not with banking. It's non-trivial to translate to a local term. 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=119420431iu=/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 16 January 2014 00:05, Jeremy Spilman jer...@taplink.co wrote: Might I propose reusable address. I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'. The problem is all addresses are reusable and to an average user, addresses are already reusable so there is little to distinguish the address format. It might be better to call it a public address in common terminology. Drak -- 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=119420431iu=/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
I think we have a winner in reusable address. Yes an existing address can be reused and will superficially appear to work, it just won't work well. Calling them reusable addresses helps reinforce the idea in peoples mind that the other kind shouldn't be reused. On Thu, Jan 16, 2014 at 11:14 AM, Drak d...@zikula.org wrote: On 16 January 2014 00:05, Jeremy Spilman jer...@taplink.co wrote: Might I propose reusable address. I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'. The problem is all addresses are reusable and to an average user, addresses are already reusable so there is little to distinguish the address format. It might be better to call it a public address in common terminology. Drak -- 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=119420431iu=/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=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tor / SPV
Yes correct, using hidden services just as a kind of more complicated, out of process/sandboxable SSL. would the overall transactions/second the Bitcoin network could handle go down? If all nodes talked to each other all the time over Tor, probably yes because Bitcoin is quite sensitive to latency. But what I'm proposing here is less ambitious. It's just about protecting (parts of) end-user-to-network communication, which is a much less risky sort of change. P2P nodes would still talk to each other in the clear. SSL for everything is still an idea I like, but it's true that increasing bitcoind attack surface area is not something to take lightly. Considering that the clearnet sybil protection also relies on scaling up the resource requirements for an attacker, why not require hidden service addresses following a certain pattern, like a fixed prefix? I'm sure we can come up with all kinds of neat anti-sybil techniques, but IMHO they are separate projects. I'm trying to find an upgrade that's small enough to be easily switched on by default for lots of users, today, that is low risk for the network overall. Later on we can add elaborations. The SPV node could connect to the IP using Tor. It would preserve the privacy of the SPV node - hard to see it's running Bitcoin. It also reduces the ability of an attacker to MITM because the routing varies with each exit node. Right so the key question is, to what extent does Tor open you up to MITM attacks? I don't have a good feel for this. I read about exit nodes routinely doing very naughty things, but I don't know how widespread that is. Probably you're right that with random selection of exits you're not excessively likely to get MITMd. How does Tor itself manage anti-sybil? I know they have the directory consensus and they measure nodes to ensure they're delivering the resources they claim to have. Punting anti-sybil up to the Tor people and letting them worry about it is quite an attractive idea. -- 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=119420431iu=/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
Just a small note of caution for those joining in testing. https://github.com/bitcoin/bitcoin/issues/3529 Currently the master branch has this issue where leveldb renames all of .sst files to .ldb. This makes running the 0.8.x version of Bitcoin think the index is corrupt. Until a fix is included in Bitcoin master, a workaround to allow 0.8.x to work again is to simply rename all the files from .ldb back to .sst. (This workaround worked for me today but failed yesterday. It's possible I made an error yesterday. If it fails for you please report as we really need to know if there are other leveldb incompatibilities.) https://github.com/bitcoin/leveldb/pull/3 The fix for Bitcoin's leveldb is being discussed here. Warren On Wed, Jan 15, 2014 at 11:09 PM, Wladimir laa...@gmail.com wrote: Hello all, It has been way to long since last major release. Many improvements and new features have been added to master since, so we'd like to do a 0.9rc1 release soon. The current aim is next month, February 2014. Of course there are still some open issues that need to be resolved before release https://github.com/bitcoin/bitcoin/issues?milestone=12state=open If there is something else that you're working on and needs to end up in 0.9, or know of some nasty bug in master that should absolutely be solved first, please tell. 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=119420431iu=/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=119420431iu=/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 Thursday, January 16, 2014 9:09:52 AM Wladimir wrote: Hello all, It has been way to long since last major release. Many improvements and new features have been added to master since, so we'd like to do a 0.9rc1 release soon. The current aim is next month, February 2014. Of course there are still some open issues that need to be resolved before release https://github.com/bitcoin/bitcoin/issues?milestone=12state=open If there is something else that you're working on and needs to end up in 0.9, or know of some nasty bug in master that should absolutely be solved first, please tell. Wladimir https://github.com/bitcoin/bitcoin/pulls/luke-jr These are pretty much all well-tested and stable for months now. -- 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=119420431iu=/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)
But I think it's great people can choose how to trade privacy for computation/bandwidth however they want, and services can compete to offer monitoring for 0+ bit prefixes. Its not a decision with user localised effect. If most users use it with parameters giving high elimination probability, that affects everyone else's privacy also. Also statistical effects are accumulative as more plausibly related addresses are eliminated at each potentially linked transaction. I think once the network flow analysis guys are done with incorporating it, and if reusable addresses saw significant use, my prediction is the result will be pretty close to privacy game over and it will undo most if not all of the hard-won privacy benefit of CoinJoin. (Recalling CoinJoin is only adding a bit or two of entropy per join, this elimination effect could easily undo more than that). You've got a major social engineering problem here. 1) who is marketing privacy 2) how do you validate 'privacy providers' Just like all the scamcoins, there will be scamprivacy providers, which will drive the market price of privacy down to zero. Who's paying the network/development/bandwidth/etc cost for privacy? I'd guess 85% of real users don't really care about some abstract 'privacy' ideal, they just want payments to work and to download cat pictures. If you say 'regular address re-use is deprecated, and the top 1% in bitcoin weatlh who own 95% of the miners want privacy', well fine. But you just opened yourself up to 'OccupyBitcoin', and an altcoin that ENCOURAGES plain old regular address re-use and transparency. Does this stuff still work if regular address re-use is a transparency feature and not a bug? -- 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=119420431iu=/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 Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote: Might I propose reusable address. I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'. It definitely packs a marketing punch which could help drive adoption. The feature is only useful if/when broadly adopted. I'm very against the name reusable addresses and strongly belive we should stick with the name stealth addresses. You gotta look at it from the perspective of a user; lets take standard pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many times as I want and everything works just great. I also can enter the address on blockchain.info's search box, and every transaction related to the address, and the balance of it, pops up immediately. What is that telling me? A: Addresses starting with 1 are reusable. B: Transactions associated with them appear to be public knowledge. Now I upgrade my wallet software and it says I now have a reusable address. My reaction is Huh? Normal addresses are reusable, what's special about this weird reusable address thing that my buddy Bob's wallet software couldn't pay. I might even try to enter in a reusable address in blockchain.info, which won't work, and I'll just figure must be some new unsupported thing and move on with my life. On the other hand, suppose my wallet says I now have stealth address support. I'm going to think Huh, stealth? I guess that means privacy right? I like privacy. If I try searching for a stealth address on blockchain.info, when it doesn't work I might think twig on Oh right! It said stealth addresses are private, so maybe the transactions are hidden? I might also think Maybe this is like stealth/incognito mode in my browser? So like, there's no history being kept for others to see? Regardless, I'm going to be thinking well I hear scary stuff about Bitcoin privacy, and this stealth thing sounds like it's gonna help, so I should learn more about that Finally keep in mind that stealth addresses have had a tonne of very fast, and very wide reaching PR. The name is in the public conciousness already, and trying to change it now just because of vague bad associations is going to throw away the momentum of that good PR and slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I based on conversations there with people there, technical and non-technical, almost everyone had heard about them and almost everyone seemed to understand the basic idea of why they were a good thing. That just wouldn't have happened with a name that tried to hide what stealth addresses were for, and by changing the name now we risk people not making the connection when wallet software gets upgraded to support them. -- 'peter'[:-1]@petertodd.org 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740 signature.asc Description: Digital 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=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Reusable addresses
I'm very pleased that my old idea is getting some traction and that I have been appropriately credited! I also think the term reusable addresses is preferable to anything to do with stealth for the reasons mentioned. You should note that the privacy guarantees they provide are not that strong but their limitations have been adequately discussed elsewhere. On an unrelated note - I'd like to solicit some help in restoring access to my Bytecoin account on http://bitcointalk.org/ Cheers! Bytecoin -- 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=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Suggestion: allow receivers to pay optional fee for transactions without fees
You can create a transaction which spends the output to yourself, attaching a fee to that transaction. In order for miners to grab the transaction fee on that transaction, they would have to also mine the original transaction. Likely, you'd have to do this by hand, but software could be written to simplify doing it. No protocol changes needed. Ben On Thu, Jan 16, 2014 at 5:39 PM, Dâniel Fraga frag...@gmail.com wrote: Someone sent me a very small donation (0.00121 BTC) without paying fees. I don't know who sent it and I know this type of transaction are usually rejected by miners. Take a look at it below: https://imageshack.com/i/ngv5g8j Even with the a low probability of confirmation, I was hoping that after a few days it could be included in a block, but Blockchain.info simply removed it (I know the sender sent from a Blockchain.info wallet, because he added a note): https://blockchain.info/pt/tx/3cde47ee3979a46b36bd61bdb0caf9c11dea58ac99f17fb17b95728766de70e0 As you can see now it shows as Transaction not found. My suggestion is: it would be nice if the receiver could have a chance to pay the fee when the sender didn't pay any fee. For example, I could pay a fee of 0.0001 BTC and receive 0.00121 BTC. In the end I'd have 0.00111 BTC. Better than nothing. Would it be technically possible to do that or it would be too much trouble to change the protocol to allow the receiver to pay an optional fee? Ps: I'm not a programmer, but if the receiver could optionally attach some fee to the transaction, even if he/she didn't sent the transaction, this could be solved. Bitcoin-qt could even warn the receiver he received a transaction without fee and if he wants faster confirmation he could pay a fee. Ps2: if this is a silly suggestion, just ignore it. I tried on Bitcointalk, but nobody answered. -- Linux 3.12.0: One Giant Leap for Frogkind http://www.youtube.com/DanielFragaBR http://mcxnow.com Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL -- 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=119420431iu=/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=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Suggestion: allow receivers to pay optional fee for transactions without fees
This is good news! Thank you very much Ben for the answer. On Thu, 16 Jan 2014 17:52:39 -0800 Ben Davenport bendavenp...@gmail.com wrote: You can create a transaction which spends the output to yourself, attaching a fee to that transaction. In order for miners to grab the transaction fee on that transaction, they would have to also mine the original transaction. Likely, you'd have to do this by hand, but software could be written to simplify doing it. No protocol changes needed. Ben On Thu, Jan 16, 2014 at 5:39 PM, Dâniel Fraga frag...@gmail.com wrote: Someone sent me a very small donation (0.00121 BTC) without paying fees. I don't know who sent it and I know this type of transaction are usually rejected by miners. Take a look at it below: https://imageshack.com/i/ngv5g8j Even with the a low probability of confirmation, I was hoping that after a few days it could be included in a block, but Blockchain.info simply removed it (I know the sender sent from a Blockchain.info wallet, because he added a note): https://blockchain.info/pt/tx/3cde47ee3979a46b36bd61bdb0caf9c11dea58ac99f17fb17b95728766de70e0 As you can see now it shows as Transaction not found. My suggestion is: it would be nice if the receiver could have a chance to pay the fee when the sender didn't pay any fee. For example, I could pay a fee of 0.0001 BTC and receive 0.00121 BTC. In the end I'd have 0.00111 BTC. Better than nothing. Would it be technically possible to do that or it would be too much trouble to change the protocol to allow the receiver to pay an optional fee? Ps: I'm not a programmer, but if the receiver could optionally attach some fee to the transaction, even if he/she didn't sent the transaction, this could be solved. Bitcoin-qt could even warn the receiver he received a transaction without fee and if he wants faster confirmation he could pay a fee. Ps2: if this is a silly suggestion, just ignore it. I tried on Bitcointalk, but nobody answered. -- Linux 3.12.0: One Giant Leap for Frogkind http://www.youtube.com/DanielFragaBR http://mcxnow.com Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL -- 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=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Linux 3.12.0: One Giant Leap for Frogkind http://www.youtube.com/DanielFragaBR http://mcxnow.com Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL -- 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=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Suggestion: allow receivers to pay optional fee for transactions without fees
To clarify, there are proposals to make miners recognize this situation and account for it, only eligius is running it at the moment IIRC: http://bitcoin.stackexchange.com/questions/8390/are-there-any-pools-or-large-miners-running-child-pays-for-parent-patch Right now if you were to try it likely wouldn't result in inclusion. But this is on the radar, and I suspect it'll eventually get merged into mainline. On Thu, Jan 16, 2014 at 9:06 PM, Dâniel Fraga frag...@gmail.com wrote: This is good news! Thank you very much Ben for the answer. On Thu, 16 Jan 2014 17:52:39 -0800 Ben Davenport bendavenp...@gmail.com wrote: You can create a transaction which spends the output to yourself, attaching a fee to that transaction. In order for miners to grab the transaction fee on that transaction, they would have to also mine the original transaction. Likely, you'd have to do this by hand, but software could be written to simplify doing it. No protocol changes needed. Ben On Thu, Jan 16, 2014 at 5:39 PM, Dâniel Fraga frag...@gmail.com wrote: Someone sent me a very small donation (0.00121 BTC) without paying fees. I don't know who sent it and I know this type of transaction are usually rejected by miners. Take a look at it below: https://imageshack.com/i/ngv5g8j Even with the a low probability of confirmation, I was hoping that after a few days it could be included in a block, but Blockchain.info simply removed it (I know the sender sent from a Blockchain.info wallet, because he added a note): https://blockchain.info/pt/tx/3cde47ee3979a46b36bd61bdb0caf9c11dea58ac99f17fb17b95728766de70e0 As you can see now it shows as Transaction not found. My suggestion is: it would be nice if the receiver could have a chance to pay the fee when the sender didn't pay any fee. For example, I could pay a fee of 0.0001 BTC and receive 0.00121 BTC. In the end I'd have 0.00111 BTC. Better than nothing. Would it be technically possible to do that or it would be too much trouble to change the protocol to allow the receiver to pay an optional fee? Ps: I'm not a programmer, but if the receiver could optionally attach some fee to the transaction, even if he/she didn't sent the transaction, this could be solved. Bitcoin-qt could even warn the receiver he received a transaction without fee and if he wants faster confirmation he could pay a fee. Ps2: if this is a silly suggestion, just ignore it. I tried on Bitcointalk, but nobody answered. -- Linux 3.12.0: One Giant Leap for Frogkind http://www.youtube.com/DanielFragaBR http://mcxnow.com Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL -- 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=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Linux 3.12.0: One Giant Leap for Frogkind http://www.youtube.com/DanielFragaBR http://mcxnow.com Bitcoin: 12H6661yoLDUZaYPdah6urZS5WiXwTAUgL -- 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=119420431iu=/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=119420431iu=/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 01/16/2014 01:28 PM, Peter Todd wrote: I'm very against the name reusable addresses and strongly belive we should stick with the name stealth addresses. I agree wholeheartedly against using reusable address. I personally am fine with stealth address, but can see where there might be a negative connotation. Might I suggest master address, which is neutral in connotation, but indicates both that it is fixed and that payment addresses are generated as needed from it. But please, no reusable address. -- Johnathan Corgan, Corgan Labs SDR Training and Development Services http://corganlabs.com attachment: johnathan.vcf signature.asc Description: OpenPGP digital 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=119420431iu=/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
I hear you, and I really don't care that much what it's called, as much as, does it work and how! I might even try to enter in a reusable address in blockchain.info, which won't work, and I'll just figure must be some new unsupported thing and move on with my life. Regardless of what it's called, Blockchain.info should tell the user, hey this address doesn't let the whole world see every single payment that's made to it! If you paid something to this address, only you know how to find the payment - look for the stealth address in your transaction list. So if we call the address that has the pubKeys the reusable address and the address that's generated from the shared secret the stealth address then is everyone happy? :-) -- 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=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Suggestion: allow receivers to pay optional fee for transactions without fees
On Friday, January 17, 2014 2:39:31 AM Christophe Biocca wrote: To clarify, there are proposals to make miners recognize this situation and account for it, only eligius is running it at the moment IIRC: http://bitcoin.stackexchange.com/questions/8390/are-there-any-pools-or-larg e-miners-running-child-pays-for-parent-patch Right now if you were to try it likely wouldn't result in inclusion. But this is on the radar, and I suspect it'll eventually get merged into mainline. If you did it and relayed directly to Eligius, it'd probably get mined.. the hard part is creating the transaction - once that's done it's smooth sailing ;) Side note: mining nodes should *not* be running mainline. In fact, they should be setting up their own customised transaction policies. -- 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=119420431iu=/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
Peter I agree with you about reusable addresses, but aren't we also trying to get away from the word address entirely? How about calling it a payment key or reusable payment key instead? using stealth is just asking for bad press imo. On 16 January 2014 21:28, Peter Todd p...@petertodd.org wrote: On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote: Might I propose reusable address. I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'. It definitely packs a marketing punch which could help drive adoption. The feature is only useful if/when broadly adopted. I'm very against the name reusable addresses and strongly belive we should stick with the name stealth addresses. You gotta look at it from the perspective of a user; lets take standard pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many times as I want and everything works just great. I also can enter the address on blockchain.info's search box, and every transaction related to the address, and the balance of it, pops up immediately. What is that telling me? A: Addresses starting with 1 are reusable. B: Transactions associated with them appear to be public knowledge. Now I upgrade my wallet software and it says I now have a reusable address. My reaction is Huh? Normal addresses are reusable, what's special about this weird reusable address thing that my buddy Bob's wallet software couldn't pay. I might even try to enter in a reusable address in blockchain.info, which won't work, and I'll just figure must be some new unsupported thing and move on with my life. On the other hand, suppose my wallet says I now have stealth address support. I'm going to think Huh, stealth? I guess that means privacy right? I like privacy. If I try searching for a stealth address on blockchain.info, when it doesn't work I might think twig on Oh right! It said stealth addresses are private, so maybe the transactions are hidden? I might also think Maybe this is like stealth/incognito mode in my browser? So like, there's no history being kept for others to see? Regardless, I'm going to be thinking well I hear scary stuff about Bitcoin privacy, and this stealth thing sounds like it's gonna help, so I should learn more about that Finally keep in mind that stealth addresses have had a tonne of very fast, and very wide reaching PR. The name is in the public conciousness already, and trying to change it now just because of vague bad associations is going to throw away the momentum of that good PR and slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I based on conversations there with people there, technical and non-technical, almost everyone had heard about them and almost everyone seemed to understand the basic idea of why they were a good thing. That just wouldn't have happened with a name that tried to hide what stealth addresses were for, and by changing the name now we risk people not making the connection when wallet software gets upgraded to support them. -- 'peter'[:-1]@petertodd.org 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740 -- 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=119420431iu=/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=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
