Suggestion: maybe you want to write and post here a paragraph summarizing
the topic of your paper so people can know if they feel qualified and if
they need to review it from their interests.
Adam
On Sun, May 18, 2014 at 03:35:33PM +0200, Krzysztof Okupski wrote:
>Dear all,
>
>I'd like to kindly
someone recently wrote (not pointing fingers, nor demanding a spirited
defense from that person, its a generic comment):
> PS: the device has patents pending
btw about patents, I wonder if people who feel the need to do that, would
you consider putting those patents into like a linux foundation
, concise presentation of many bitcoin details
that are otherwise hard to put together, requiring examining source or
asking people knowledgeable at algorithm/code level.
>>http://enetium.com/resources/Bitcoin.pdf
Adam
On Sun, May 18, 2014 at 04:38:53PM +0200, Adam Back wrote:
>Suggesti
Advertising NODE BLOOM as a service sounds good.
But the critique of bloom filters, I am not so sure prefix filters are
better. Prefix filters offer questionable privacy tradeoffs in my opinion.
Same problem as with stealth address proposed use of prefixes.
All for scalability, efficiency and d
On Fri, Jun 06, 2014 at 05:04:41AM -0400, Peter Todd wrote:
>On Fri, Jun 06, 2014 at 10:48:52AM +0200, Adam Back wrote:
>> Prefix filters offer questionable privacy tradeoffs in my opinion. Same
>> problem as with stealth address proposed use of prefixes.
>
>That's
I think you can do everything with the existing script level nlocktime
in some kind of turing completeness sense (maybe); but there is a
complexity cost that often you have to resort to extra dependent
transaction(s) (and work-around malleability until that is fully
fixed) just to get the effect.
please not google groups *, I'd vote for sourceforge or other simple
open list software over google groups.
Adam
* Google lists are somehow a little proprietary or gmail lockin
focused eg it makes things extra hard to subscribe with a non-google
address if google has any hint that your address is
For those following this thread, we have now written a paper
describing the side-chains, 2-way pegs and compact SPV proofs.
(With additional authors Andrew Poelstra & Andrew Miller).
http://blockstream.com/sidechains.pdf
Adam
On 16 March 2014 15:58, Adam Back wrote:
> So an update o
Some thoughts about Alex's analysis:
- bitcoin price may increase (though doubling immediately might be
unlikely) after the halving (because the new coins are in short
supply). Apparently there is some evidence of a feedback loop between
number of freshly mined coins sold to cover electrical costs
It seems to me that people maybe arriving at the idea that they should
put transaction data in the blockchain for three related reasons: a)
its there and its convenient; and b) they are thinking about permanent
storage and being able to recover from backup using a master seed to a
bip32 address-set
On 20 December 2014 at 14:48, Peter Todd wrote:
> We need the following primitives operating on message m, pubkey p, and a
> valid signature sig1 for m, p:
>
> AntiReplaySign(m, p, sig1) -> sig2
> VerifyAntiReplaySig(m, p, sig2) -> True or False
>
> Additionally once AntiReplaySign() has b
Yes you could for example define a new rule that two signatures
(double-spend) authorises something - eg miners to take funds. (And
this would work with existing ECDSA addresses & unrestricted R-value
choices).
I wasnt really making a point other than an aside that it maybe is
sort-of possible to
(Again nothing new to say here, just putting my notes in this
discussion, where I started with an earlier discussion that Peter
wrote up with a subject of "disentangling" blockchain design).
In the discussion last year that started the analysis of
"disentangling" blockchain design I had broken out
its an always offline node, so it knows nothing really other than a
BIP 32 hierarchy of keys & a signature request.
So the signature request has to drag with it information to validate
what the value is, in order to be sure not to sign away 99% to fees.
Signing the transaction value and having the
ine
eg 12mo to next version +/- etc. might be an interesting thing to
explore as a place to store live versions of "hard fork wishlist"
items where people who need them early can help validate them.
I am not sure that helps the full network upgrade issue though.
Adam
On 23 January 2015 at 1
Strongly with Peter on this. That its highly complex to maintain strict
consensus between bitcoin versions, does not justify consensus rewrite
experiments; it tells you that the risk is exponentially worse and people
should use and rally around libconsensus.
I would advise any bitcoin ecosystem p
I saw there was some discussion on this topic on the bitcoinj list.
(I dont think I can post there without subscribing probably.)
Someone had posted about the lack of privacy provision from the
current implementation parameters and real-world factors similar to
described in this academic paper
h
Mike Hearn wrote:
> Adam Back wrote:
> > Its seems surprising no one thought of it
> > that way before (as it seems obvious when you hear it) but that seems
> > to address the privacy issues as the user can fetch the block bloom
> > filters and then scan it in complete
The idea is not mine, some random guy appeared in #bitcoin-wizards one
day and said something about it, and lots of people reacted, wow why
didnt we think about that before.
It goes something like each block contains a commitment to a bloom
filter that has all of the addresses in the block stored
Seems like Greg & I may be saying different things. Maybe I am
misunderstanding something at the wire level or in size/scalability
but what I was trying to say is I think simpler.
By UTXO commitment I mean a merkle tree of unspent addresses is
committed in each block. Also a bloom filter contain
Whats the objective? Is it to require accidental disclosure of two
private keys to compute the master private key?
Adam
On 21 February 2015 at 13:20, 木ノ下じょな wrote:
> Hello All,
>
> I have put together a proposal for a new generation methodology of HD
> wallets.
>
> The method is a modification
If you want to be constructive and index transactions that are not
p2sh but non-simple and contain checksig so the address is visible,
you could do that with a block bloom filter also.
I wasnt sure if the comments about the need to batch requests was
about downloading headers & filters, or about t
I agree with Mike & Jeff. Blowing up 0-confirm transactions is vandalism.
bitcoin transactions are all probabilistic. there is a small chance
1-confirm transactions can be reversed, and a different but also
usable chance that 0-confirm transactions can be reversed. I know
0-confirm is implement
ker 0-conf transactions.
If I understand this is also your own motivation.
Feel free to comment on or improve the proposal or find other approaches.
Adam
On 22 February 2015 at 12:34, Peter Todd wrote:
> On Sun, Feb 22, 2015 at 08:02:03AM +0000, Adam Back wrote:
>
> FWIW I've been a
Well this is all very extreme circumstances, and you'd have to assume no
rational player with an interest in bitcoin would go there, but to play
your analysis forward: users are also not powerless at the extreme: they
could change the hash function rendering current deployed ASICs useless in
reacti
I think its fair to say no one knows how to make a consensus that
works in a decentralised fashion that doesnt weaken the bitcoin
security model without proof-of-work for now.
I am presuming Gavin is just saying in the context of not pre-judging
the future that maybe in the far future another inno
The general idea for replace by fee is that it would be restricted so
as to make it safe, eg all the original addresses should receive no
less bitcoin (more addresses can be added).
The scorched earth game theory stuff (allowing removing recipients) is
kind of orthogonal.
Adam
On 26 May 2015 at
Well so for example it could have an additional input (to increase the
BTC paid into the transaction) and pay more to an existing change
address and higher fee, or add an additional change address, and leave
a larger fee, or if you had a right-sized coin add an additional input
that all goes to fee
I think the point is the replacement tx spends the same inputs (plus
additional inputs), so if the original tx is accepted, and your
replacement rejected, thats good news - you dont have to pay the
higher fee, the extra input remains unspent (and can be used later for
other purpose) and the extra c
Or as far as that goes, permuting (the non-dependent) transactions in
the block by permuting the internal merkle tree nodes at increasing
depths. (Dependent because transactions that depend on each other
have to come in-order; but one could eg put the n-1 of each n sequence
of in-order transaction
I discussed the extension block idea on wizards a while back and it is
a way to soft-fork an opt-in block-size increase. Like everything
here there are pros and cons.
The security is better than Raylstonn inferred from Tier's explanation
I think.. It works as Tier described - there is an extensi
Agree with everything you said. Spot on observations on all counts.
Thank you for speaking up.
Adam
On 1 June 2015 at 13:45, Jérôme Legoupil wrote:
>>What do other people think?
>>
>>
>>If we can't come to an agreement soon, then I'll ask for help
>>reviewing/submitting patches to Mike's Bitcoi
Hi Gavin
Sorry for slow response & broken threading - mailbox filled up & only
saw your response on archive.
I do earnestly think opt-in block-size increases are politically
cleaner (gives different people different sized blocks by their own
volition without forcing a compromise) and less risky t
Mike wrote:
>> Businesses who are keen to
>> have more transactions, would make it their problem to implement in
>> their wallet, or ask the wallet vendor/maintainer they're working with
>> to do it. Nothing breaks if they dont use it.
>
>
> I don't see how this is the case. If an exchange support
So lets rephrase that and say instead more correctly it is the job of
miners (collectively) to be well connected globally - and indeed there
are incentivised to be or they tend to receive blocks at higher
latency and so are at increased risk of orphans. And miner groups
with good block latency in-
That would also introduce the anomaly of a script that was once valid
becoming later invalid, when nothing varies other than time. That is
not super compatible with the current model of reprocessing
transactions in later blocks if the block they were first in gets
reorged.
(Not a huge flexibility
Hi
I made these comments elsewhere, but I think really we should be
having these kind of conversations here rather than scattered around.
These are about Jeff Garzik's outline draft BIP 100 I guess this is
the latest draft: (One good thing about getting off SF would be
finally JGarzik's emails a
It might be as well to keep the archive but disable new posts as
otherwise we create bit-rot for people who linked to posts on
sourceforge.
The list is also archived on mail-archive though.
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/
Adam
On 14 June 2015 at 22:55, And
Hi Mike
On 15 June 2015 at 00:23, Mike Hearn wrote:
>> One thing that is concerning is that few in industry seem inclined to
>> take any development initiatives or even integrate a library.
>
> Um, you mean except all the people who have built more scalable wallets over
> the past few years, whic
Mike Hearn wrote:
> Which is why there will soon be a fork that does it.
I understand why you would be keen to scale bitcoin, everyone here is.
But as you seem to be saying that you will do a unilateral hard-fork,
and fork the code-base simultaneously, probably a number of people
have questions,
Hi Mike
Well thank you for replying openly on this topic, its helpful.
I apologise in advance if this gets quite to the point and at times
blunt, but transparency is important, and we owe it to the users who
see Bitcoin as the start of a new future and the$3b of invested funds
and $600m of VC fun
I think he's more talking about like extension-blocks, however they
are actually soft-forkable even (and keep the 21m coins obviously)
See See
https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07937.html
and Tier Nolan tech detail
https://www.mail-archive.com/bitcoin-d
Bitcoin p2p seeding requirements hav some ToR similarities, and we went
through the same security considerations with Zero-Knowledge systems freedom
network. Though bitcoins attacker profile and motivation is different - so
the defense maybe even more demanding. At least you have no shortage of
n
btw with nodes for transport security you might use self-certifying keys.
Referring to Zooko's triangle, then the key is the node identity. Similar
to a bitcion address. So then just another ECDSA key and use emphemeral
ECDH for transport authenticated with the nodes key.
Maybe there can be som
On Mon, May 06, 2013 at 03:08:57PM -0400, Peter Todd wrote:
>> Hmm: maybe one could use a Brands private credential with offline double
>> spend detection, with the reputation but not coin address of the node
>> disclosed, and the nodes coin address embedded in the proof. Each node
>> could be is
On Mon, May 06, 2013 at 11:25:50AM -0700, Gregory Maxwell wrote:
>On Mon, May 6, 2013 at 11:04 AM, Adam Back wrote:
>> bitcoins primaryvulnerability IMO (so far) is network attacks to induce
>> network splits, local lower difficulty to a point that a local and
>> artificially
Well its a bit more hopeful than that :)
On Tue, May 07, 2013 at 11:17:17AM +0200, Mike Hearn wrote:
>> Seems like the website redesign managed to hide the signatures pretty
>> good.
>
>Security theater indeed - even if people check the signatures, where
>did they get the identities of the signers
Hi
Three minor security/other issues:
1. please a way to unlock the wallet without displaying wallet password in
console screen (console unlock wallet, to import priv key); or
2. a button to import a private key (and option to transfer it to another
key - if you are not the sole controlle
Pieter Wuille wrote:
>On Tue, May 07, 2013 at 02:16:41PM +0200, Adam Back wrote:
>> Hi
>>
>> Three minor security/other issues:
>>
>> 1. please a way to unlock the wallet without displaying wallet password in
>>console screen (console unlock wallet, to import
In this thread discussing this idea
https://bitcointalk.org/index.php?topic=179612.0
it is suggested that the approach risks making 0-confirm double-spends
easier.
I dont see why this should be. Cant part of the validation of accepting a
fee revision be that every aspct of the revision except
at 07:46:05AM -0400, Peter Todd wrote:
>On Thu, May 09, 2013 at 01:19:13PM +0200, Adam Back wrote:
>> In this thread discussing this idea
>>
>> https://bitcointalk.org/index.php?topic=179612.0
>>
>> it is suggested that the approach risks making 0-confirm doubl
I didnt quite understand the writeup and the references were ambiguous.
But if you are talking about bitcoin/hashcash merged mining for email: it is
something I think should possible. Of course for email the scale means
bitcoin style flood-fill and direct tiny payments are completely out of the
q
On Mon, May 13, 2013 at 07:31:21AM +, John Dillon wrote:
>[with] merge-mining [you get] more value from just one unit of work.
correct.
>But Peter's coinbase hashcash protocol carefully ensures [...] the amount
>of value the miner would have then given away in a "anyone-can-spend"
>output.
I
On Mon, May 13, 2013 at 02:38:15PM -0400, Jeff Garzik wrote:
>On Mon, May 13, 2013 at 6:54 AM, Adam Back wrote:
>> On Mon, May 13, 2013 at 07:31:21AM +, John Dillon wrote:
>>>[with] merge-mining [you get] more value from just one unit of work.
>>
>> correct.
>&g
On Mon, May 13, 2013 at 06:00:27PM -0400, Jeff Garzik wrote:
>When a transaction's input value exceeds its output value, the
>remainder is the transaction fee. The miner's reward for processing
>transactions is the 25 BTC initial currency distribution + the sum of
>all per-transaction fees. A des
So back in 1999, in an ecash thread on cypherpunks I claimed:
http://marc.info/?l=cypherpunks&m=95280154629900&w=2
> I wouldn't say ecash has to use blinding, but I would argue it would be a
> misuse of the word "ecash", if something which was revocable were dubbed
> ecash.
This was in the conte
On Tue, May 14, 2013 at 01:51:51PM +0200, Adam Back wrote:
> Adam Back in Sep 1999, cypherpunks list:
>>I wouldn't say ecash has to use blinding, but I would argue it would be a
>>misuse of the word "ecash", if something which was revocable were dubbed
>>
On Tue, May 14, 2013 at 12:50:27PM -0400, Jeff Garzik wrote:
>> Well if it is a later transaction, not an integral part of the reward
>> transaction (that is definitionally mined by being serialized into the
>> coinbase), the user may elect to withhold the promised transaction
>> give-to-miner, so
On Tue, May 14, 2013 at 09:39:46PM +0200, Harald Schilly wrote:
>If you have your own domain, you can store your key there as a TXT entry.
>
>$ dig +short harald._pka.schil.ly. TXT
>
>and even use it automatically:
>$ gpg … --auto-key-locate pka -r email@address.domain
Nice. But we all kow about
o longer demand much from the voting process. That admits more
interesting things like pool free direct mining, low variance hashcash
coins, probably. Many things to think through.
I suppose the commitment could be described as a blind symmetric commitment.
Adam
On Tue, May 14, 2013 at 04:0
On Wed, May 15, 2013 at 07:19:06AM -0400, Peter Todd wrote:
>Protocols aren't set in stone - any attacker that controls enough
>hashing power to pose a 51% attack can simply demand that you use a
>Bitcoin client modified [to facilitate evaluation of his policy]
Protocol voting is a vote per user p
On Wed, May 15, 2013 at 07:38:27AM -0400, Peter Todd wrote:
>no-one seems to think much about how in practice very few vendors have a
>setup to detect if conflicting transactions were broadcast on the network
>simultaneously - after all if that is the case which transaction gets mined
>is up to cha
On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote:
>If the commitment is opaque at the time of inclusion in the block then
>I will create multiple commitments and then after revealing the
>commitment and spend to you I will reveal the earlier commitment which
>commits the coins to
btw I posted some of this thread on the dev forum:
https://bitcointalk.org/index.php?topic=206303.msg2157994#msg2157994
A related idea is occuring to me that maybe these committed transactions
could actually as a side effect make bitcoin scale slightly better by
reducing the p2p flood filled tran
On Wed, May 15, 2013 at 07:45:34PM -0700, Gregory Maxwell wrote:
>[committed coins] depending on how its done, at most conceals the
>transactions from people who aren't a party to them... though as time goes
>on eventually everyone becomes a party to a sufficiently old coin, and
>avoiding publicat
More somewhat improved crypto stuff...
On Thu, May 16, 2013 at 01:32:22PM +0200, Adam Back wrote:
>I suggested fixed size committed coin spends [...]
>
>(blind-sender, auth-tag, encrypted-tx-commit)
>
>(pub key P = xG, G = base point)
>
> blind-sender = cP (public
Is there a way to experiment with new features - eg committed coins - that
doesnt involve an altcoin in the conventional sense, and also doesnt impose
a big testing burden on bitcoin main which is a security and testing risk?
eg lets say some form of merged mine where an alt-coin lets call it
bitc
I like this idea a lot.
To add: I think it is a bug and security risk if pooled-solo or (current
pooled miners) do not add randomness to their extraNonce2 (like 128-bits of
it). For privacy and to avoid various hostile-pre-mining attacks it should
be done this way. Lack of the self-chosen challe
So the idea is that people may want to use proof-of-work unrelated to
bitcoin, and abuse bitcoin to obtain that proof, in a way denominated in BTC
(and with a published USD exchange rate). And the ways they can do that are
to:
a) create unspendable addresses (which maybe you cant compact in the U
side of zerocoin - eg for bitcoin, or an alt-coin.
Adam
On Sun, May 19, 2013 at 03:23:59PM +0200, Adam Back wrote:
>Is there a way to experiment with new features - eg committed coins - that
>doesnt involve an altcoin in the conventional sense, and also doesnt impose
>a big testing bur
coinbase).
Adam
On Fri, Jun 14, 2013 at 03:20:58PM -0400, Peter Todd wrote:
>On Thu, Jun 13, 2013 at 03:39:32PM +0200, Adam Back wrote:
>> I had one thought towards this which is a different kind of merged mining.
>>
>> I think a "fair" merged mining aiming for price parit
I think Timo's point is that while you cant do discrete log, you can do y-th
root. So if P = xG is a parent public key (x private key, G base point),
then your proposed multiplier address is hash of Q=yP. However its easy to
find another P such that Q=zP'. ie just "divide by z" (EC multiply by z
ed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
>[q-th root with unknown no discrete log artefact]
>
>If it was a concern I guess you could require a proof of knowledge of
>discrete log. ie as well as public key parent, multiplier the address must
>include ECDSA sig or S
Hi
I presume everyone saw the announce from Matthew Green & Ian Miers at JHU on
the release of libzerocoin: https://github.com/Zerocoin/libzerocoin
So now that raises the question of how can people experiment with real money
with zerocoin. I think its fair to summarize there is resistance to mer
On Sat, Jul 13, 2013 at 11:51:14AM +0200, Jorge Timón wrote:
>I don't see the need to peg zerocoins to bitcoins.
Without a bitcoin peg on the creation cost of zerocoins, it is hard for a
new alt-coin to have a stable value. Bitcoin itself is volatile enough.
Generally the available compute for m
I think bi-directional sacrifice is probably not needed to assure a close to
1:1 bi-directional peg.
(Bi-directional sacrifice meaning also to convert a zerocoin to a bitcoin
you sacrifice a zerocoin and bitcoin would be modified to accept a zerocoin
sacrifice as a way to replace a previously sacr
There are some policy decision points in the protocol (and code) that may
become centralized risks or choke points that undermine the p2p nature. So
the extent that those can be argued to have in principle have a technical
fix, it could be quite interesting to research the necessary technology
(ad
On Sun, Sep 29, 2013 at 10:49:00AM -0700, Mark Friedenbach wrote:
>This kind of thing - providing external audits of customer accounts
>without revealing private data - would be generally useful beyond
>taxation. If you have any solutions, I'd be interested to hear them
>(although bitcoin-dev is pr
01, 2013 at 04:26:03PM +0200, Adam Back wrote:
>On Sun, Sep 29, 2013 at 10:49:00AM -0700, Mark Friedenbach wrote:
>>This kind of thing - providing external audits of customer accounts
>>without revealing private data - would be generally useful beyond
>>taxation. If you have
g/index.php?topic=305791.msg3294618#msg3294618
Adam
On Tue, Oct 01, 2013 at 09:11:43PM +0200, Adam Back wrote:
>Err actually not (efficient) I made a mistake that came out when I started
>writing it up about how the t parameter in the proof relates to bitcoin
>precision and coin representation
Determinstic ECDSA signature aka k=H(d,m) insead of k=random, with signature
(r,s) calculated r=[kG].x, s=k^-1(H(m)+rd) with public key Q=dG and
verificaton relation [H(m)s^-1G+rs^-1Q].x=?r is cool and should be done.
Otherwise RNG issues like EC_DRBG or even leaked partial bits like the RNG
bias
level
malleability is discovered in ECDSA it remains secure.)
Adam
Adam Back wrote:
>So I was thinking a more generic / robust way to fix this would be to change
>the txid from H(sig,inputs,outputs,script) to H(pubkey,inputs,outputs,script)
>or something like that in effect so that the mal
Coming back to the staging idea, maybe this is a realistic model that could
work. The objective being to provide a way for bitcoin to move to a live
beta and stable being worked on in parallel like fedora vs RHEL or odd/even
linux kernel versions.
Development runs in parallel on bitcoin 1.x beta
So I had a go at deciphering BIP 038 in summary what I think its doing is
(ommitting lot and sequence and deterinistic IVs for simplicity):
user:
x1 = Scrypt( salt=random, pass )
P = x1*G
send (salt, P) to coin manufacturer ->
manufacturer:
I think its a mistake relying directly on X509, its subject to corrpution
attacks, involves ASN.1 and enough openSSL X.500 encoding abiguity (or other
code base) to be a security nightmare.
Why not make the payment messages signed by bitcoin keys. If someone wants
to associate with X.509 they can
Might leak less wiggle room and be simpler/more robut to validate that
*everything* has to be the same except for the amount going to one (presumed
change) address. A privacy leak I know, but dont do that - ie send enough
change the first time. And network analysis has shown change addresses
aren
(Talking about the paper, not the BIP). With regard to racing the other
winner which catches up when private pool length=1:
i) the model does not appear to take into account that when another pool
goes on to mine a block, and the attacker publishes their selfishly-withheld
block, the selfish pool
While we're discussing the emotive (though actually of real relevance for
bitcoin user comprehension and sentiment) I couldnt resisnt to add some
trivia reference it is amusing that a currency rarely in history had to
deflate (remove 0s) rather than inflate (add 0s). Viz this hyperinflated
fifty t
Yeah but that sounds pretty much like test-net and starts a new digital
scarcity on an alpha-qa level network, with an implied promise that maybe if
you're lucky your coins might survive the alpha testing and have some value.
I'm not talking about some slightly stabler version of test-net.
Probab
I think the one thing that SSL does provide is some protection against ARP
or DNS poisoning to trick the user into downloading from a different site.
The PGP WoT surrounding bitcoin or OS related ISOs be weak - I am not sure
if I could even check it directly myself despite spending a few hours
tra
You know if you want to make some form of investment, you might like make an
attempt to look them up on the internet, check the phone number in a phone
book or directory enquiries, look for references and reviews?
So it is with the hash of the binary you are about to trust with your
investment fun
Seems like you (Nadav) are the third person to reinvent this idea so far :)
I wrote up some of the post-Bytecoin variants here:
https://bitcointalk.org/index.php?topic=317835.msg4103530#msg4103530
The general limitation so far is its not SPV compatible, so the recipient
has to test each payment
He's probably thinking of fair advertising rules. There are regulations
motivated by consumer protection/advertising standards (prevents merchant
listing attractive prices in media, and then when consumer goes to pay the
merchant says "oh actually that doesnt include X and Y, and the minimum
price
Maybe even pay to (address derived from) contract hash has a hole: it
assumes the merchant cashes the funds (or cashes then reimburses via the
refund address). There is another rational (though abusive) move for the
merchant: let the buyers funds sit in limbo. Then the buyer has the onus to
go in
I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G
and therefore that Util.SingleSHA256() multiplies by G internally?
Adam
-
So I like static address name too. In the write up for my variant I called
it something less sexy than stealth "unlinkable public address":
https://bitcointalk.org/index.php?topic=317835.msg4103530#msg4103530
(there are 3 variants that are approximately the same thing).
Maybe we could call it a
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
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 wr
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
>>d
Because the mnemonic is an encoding of a 128-bit random number using its
hash as a private key (or derived part of one) is not a problem, its just an
alternate alphabet encoding of the random private key.
Not being able to generically understand the checksum. Seems tricky to
solve other than say
1 - 100 of 113 matches
Mail list logo
