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
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 own CA,
On Mon, May 06, 2013 at 11:25:50AM -0700, Gregory Maxwell wrote:
On Mon, May 6, 2013 at 11:04 AM, Adam Back a...@cypherspace.org wrote:
bitcoins primaryvulnerability IMO (so far) is network attacks to induce
network splits, local lower difficulty to a point that a local and
artificially
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 priv key); or
I think the general solution here is providing a feature-reach
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
, Adam Back a...@cypherspace.org 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.
But Peter's coinbase hashcash protocol carefully ensures [...] the amount
of value the miner would have then given away
So back in 1999, in an ecash thread on cypherpunks I claimed:
http://marc.info/?l=cypherpunksm=95280154629900w=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 context of
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
ecash.
So I still think that is an important point
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 thats
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 the
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:09:02PM +0200, Adam Back wrote:
[...]
One
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
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 an
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
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 publication
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 key EC multiplied by constant c
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
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
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 burden on bitcoin main which is a security
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 parity would be done by the
miner having
, 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 Schnorr proof of knowledge (which both
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
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
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
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
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
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 any solutions, I'd
#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 (I thought t=2, but t=51). Damn! Back
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
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
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
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.
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
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
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
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
I think prefix has analysis side effects. There are (at least) 4 things
that link payments: the graph of payment flows, timing, precise amounts, IP
addresses, but with prefix a 5th: the prefix allows public elmination of
candidates connections, I think that may make network flow analysis even
widely used hardness assumptions.
Adam
(*) analogous to the way IBE is used as a building block for Non-Interactive
Forward Secrecy (NIFS)
On Fri, Jan 24, 2014 at 11:13:30AM -0500, Peter Todd wrote:
On Fri, Jan 24, 2014 at 04:42:35PM +0100, Adam Back wrote:
Now while it would be clearly a very nice
I think you Peter Jeremy figured it out - dont disagree with the
explanation details.
And it seems better explained between the two posts than I did. I think
Peter is right that you do not need an explicit prefix, the prefix after
decryption can be a chosen number of leading 0s and this gives a
Also the other limitation for ECDSA is that there is no known protocol to
create a signture with a+b (where keys P=aG, Q=bG, R=P+Q=(a+b)G). without
either a sending its private key to b or viceversa (or both to a third
party).
With Schnorr sigs you can do it, but the k^-1 term in ECDSA makes a
, Adam Back wrote:
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
ECDSA.
Adam
On Fri, Mar 21, 2014 at 11:25:59AM +0100, Andreas Schildbach wrote:
On 03/20/2014 01:12 PM, Adam Back wrote:
Whats a sensible limit on practical/convenient QR code size?
Technically 3 KB. In my experience codes above 1.5 KB become impossible
to scan (ZXing scanner, 3 years ago
According to Bernstein it's patent FUD (expired, ancient and solid prior
art).
http://lists.randombit.net/pipermail/cryptography/2013-August/005126.html
Adam
On Fri, Mar 21, 2014 at 12:33:57PM +0100, Mike Hearn wrote:
Oh, one other reason I found - apparently RIM, at least in the past,
Big picture/mid-term I think air-gaps and zero-trust ecosystem components
are the only solution. (zero-trust meaning like real-time auditability, or
type 2/type 3 exchanges based on atomic-swap, trustless escrow etc).
Need a mass-production and air-drop of trezors :)
There is one more problem
Not to get snarky or OS elitist but as I understand it windows security,
even during its support period has been measured in low digit number of days
in the year when is NOT an outstanding known remote root compromise or
combination of remote user compromise + priviledge escalation. Add in
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:
Suggestion: maybe you
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
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 a...@cypherspace.org wrote:
So
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
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
On 20 December 2014 at 14:48, Peter Todd p...@petertodd.org 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
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
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
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
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 privacy.
And then what? So you know
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
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
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
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
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
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,
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
Mike Hearn m...@plan99.net 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
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
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
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
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 supports
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
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
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
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
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
78 matches
Mail list logo
