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 wrote:
> On
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-r
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 wh
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
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 w
This is good news! Thank you very much Ben for the answer.
On Thu, 16 Jan 2014 17:52:39 -0800
Ben Davenport 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 transact
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
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 ho
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 stron
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 whi
> >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
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 c
Put this into a separate thread about Alan Reiner's user validatable HD
address idea.
On Wed, Jan 15, 2014 at 05:02:10PM -0800, Jeremy Spilman wrote:
>On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back wrote
>>Maybe in the payment address case the service should choose the
>>derivation factor and com
On Wed, Jan 15, 2014 at 05:02:10PM -0800, Jeremy Spilman wrote:
>The second pubKey is useful [...] even just being able to scan for
>transactions yourself without keeping bitcoin-encumbered private keys
>decrypted in memory.
Agreed.
>On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back wrote:
>>But I t
On Thu, Jan 16, 2014 at 10:14:24AM +, Drak wrote:
> On 16 January 2014 00:05, Jeremy Spilman <[1]jer...@taplink.co> wrote:
> > Might I propose "reusable address".
>
> The problem is all addresses are reusable and to an average user,
> addresses are already reusable so there is little to
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 include
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
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,
On 16 January 2014 00:05, 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'.
>
The problem is all addresses are reusable and to an average
On Thu, Jan 16, 2014 at 7:26 AM, Gary Rowe 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
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
rele
21 matches
Mail list logo
