it maybe subject to misinterpretation so
to clarify:
On 19 June 2015 at 11:22, Dr Adam Back wrote:
> For example it could hypothetically allow 10MB blocks on
> one chain and 100kB blocks on the main chain. People say complexity,
> scary. Sure I am talking longer term, but we have to also make
&
Nicely put Eric. Relatedly my initial experience with Bitcoin in
trying to improve bitcoin in fungibility, privacy & decentralisation,
I found some interesting things, like Confidential Transactions (that
Greg Maxwell has now optimised via a new generalisation of the
hash-ring signature construct
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
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
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
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
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
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
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
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-
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
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
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
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
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
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
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
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.
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
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
, 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
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
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
On Sun, Apr 27, 2014 at 10:53:08PM +1000, Gareth Williams wrote:
>Bitcoin is this perfect /trustless/ mathematical machine [...]
>
>2. the economic majority will not cooperate to reinterpret history
>
> [this proposal was...] replacing it with:
>
>2. the economic majority will not cooperate to rei
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
phishin
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 ad
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,
> h
6-bit 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 sc
Whats a sensible limit on practical/convenient QR code size?
How much of the payment protocol message size comes from use of x509?
(Just exploring what the options are).
Adam
On Thu, Mar 20, 2014 at 11:36:09AM +0100, Mike Hearn wrote:
> Encoding entire payment requests into qrcodes is definit
07PM +0200, 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.
>
>
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 (se
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
more
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
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
more
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
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
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
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
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
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
-
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
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
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
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
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
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
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
(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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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 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
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 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
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 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
>>
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
1 - 100 of 113 matches
Mail list logo