[Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

2014-01-16 Thread Wladimir
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

2014-01-16 Thread Wladimir
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

2014-01-16 Thread Drak
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

2014-01-16 Thread Mike Hearn
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

2014-01-16 Thread Mike Hearn
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

2014-01-16 Thread Warren Togami Jr.
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

2014-01-16 Thread Luke-Jr
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)

2014-01-16 Thread Troy Benjegerdes
 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

2014-01-16 Thread Peter Todd
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

2014-01-16 Thread Byte Coin
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


[Bitcoin-development] Suggestion: allow receivers to pay optional fee for transactions without fees

2014-01-16 Thread Dâniel Fraga
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


Re: [Bitcoin-development] Suggestion: allow receivers to pay optional fee for transactions without fees

2014-01-16 Thread Ben Davenport
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

2014-01-16 Thread Dâniel Fraga
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

2014-01-16 Thread Christophe Biocca
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

2014-01-16 Thread Johnathan Corgan
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

2014-01-16 Thread Jeremy Spilman
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

2014-01-16 Thread Luke-Jr
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

2014-01-16 Thread Drak
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