Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread Dr Adam Back
A lot of people think a layer2 is needed, that has a higher
(algorithmic) scale in use of layer1 block-space but preserves
functionality and uplifts security from layer1.  An example would be
lightning or similar.

But there are many things that could be done.  Pure offchain is a weak
form of layer2.  Its running today and maybe its handling 90-99% range
of all transactions right now (mostly in exchanges for example).  This
layer can be incrementally hardened.  It can also have standardised
APIs across vendors of custodians, and opt-in support of those APIs in
wallets.  This would provide a convenience choice.  Greenaddress also
for low-mid assurances solves the unconfirmed transactions. It's
probably not reasonable to expect bitcoin directly solve fast
unconfirmed transactions.   Probably intermediate configurations in
complexity somewhere between greenaddress (2 of 2 + timelocked 1 sig)
and lightning may exist also.  The internet doesnt stop at layer1.

(Which would then leave people who are uninterested in changing client
software to handle layer2, as layer1 will always be enough die-hards
(in the refusing the future and facing the O(n^2) scaling wall or
centralisation death with perplexing optimism :)  Ok, not so
constructive but maybe a gentle reminder that it is not constructive
in the reverse direction either to throw around often false
characterisations.  We're here now to improve bitcoin so lets do that.

What I said here seemed like it maybe subject to misinterpretation so
to clarify:

On 19 June 2015 at 11:22, Dr Adam Back a...@cypherspace.org 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
 concrete forward progress to the future or we'll be stuck here talking
 about perilously large constant changes in 5 years time!

I should clarify that I meant there I was assuming we do one increase
within the next 12 months frame that gives buffer for 5 years rd to
improve things and build layer2.

But if we do no RD on layer2, and insist that clients can never
change to become layer2 aware, and layer2 is too hard etc then our
risk would be we'd be back in the discussion of kicking the can afresh
again in some years with some even more centralising size change.

Sure we should make the transition and introduction to layer2 and an
intermediate crunch smoother, but 20MB now or else isn't really
helping.  It did help get the conversation revived, but at this point
its a hindrance.  Seriously a big hindrance.  No offence but please
find a way to gracefully stop and rejoin the constructive process.
You can disagree on factors and points and be collaborative others
disagree frequently and have done productive work cordially for years
under the BIP process.


About scaling again:

Here is what I said before in my TL;DR post about my thoughts on how
we would start on throughput short-term to have space to do layer2
development.

 I think almost everybody is on board with a combination plan:

 1. work to improve decentralisation (specific technical work already
 underway, and education)
 2. create a plan to increase block-size in a slow fashion to not cause
 system shocks (eg like Jeff is proposing or some better variant)
 3. work on actual algorithmic scaling

 In this way we can have throughput needed for scalability and security
 work to continue.

 As I said you can not scale a O(n^2) broadcast network by changing
 constants, you need algorithmic improvements.

 People are working on them already.  All of those 3 things are being
 actively worked on right now, and in the case of algorithmic scaling
 and improve decentralisation have been worked on for months.


Btw I wonder if Gavin or Mike would be willing to answer another
question I forgot from my TL;DR post which was:

- Did you accept payment from companies to lobby for 20MB blocks?  Do
you consider that something appropriate to publicly disclose if so?
Do you consider that user rights should come above or below company
interests in Bitcoin?


FWIW on pondering that last question should user rights come above or
below company interests I think my view of the guiding principle is
starkly clear to me: that user rights should be the primary thing to
optimise for.  Businesses are providing service to users, their
interests are secondary in so far as if they are enabled to provide
better service thats good.

Bitcoin is a user p2p currency, with a social contract and a strong
user ethos.  Importing and forcing company interests would likely be
the start of a slippery slope towards an end to Bitcoin.   If we allow
business rights to be paramount it seems likely that we will end back
at the status quo as bitcoin payment processors grow, conglomerate and
become paypal/bank like or actual banks and then their interests and
exposures are the same as the banks and they'll want to import their
business models

[Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread Dr Adam Back
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 he invented and with Pieter made part of
the alpha side-chain release) and a few other things.

As I went then to discuss and learn: a) what are the characteristics
needed for inclusion (clearly things need to fit in with how things
work, not demand massive rewrites to accommodate and to not conflict
with existing important design considerations), so that I could make
proposals in a practically deployable way, and then b) the
practicality of getting a proposed change that say people found
clearly useful.  Then I bumped into the realisation that this is
actually really high risk to change, and consensus critical coding
security is very complex and there are some billion $ resting on
getting this rigidly correct under live conditions, so that deployment
must be cautious and incremental and rigorously tested.

So then I focussed instead on question of whether we could improve
bitcoins development model: how could we allow bitcoin to more rapidly
and agilely test beta features or try novel things to see how they
would work (as someone might do in a feature branch of a normal FOSS
project, to code and test a proposal for later addition), but with
criteria we want real bticoins so there is economic incentive as that
is actually part of the bitcoin protocol so you've not validated
something unless you're run it in a real network with money.  I was
hypothesising therefore we need a way to run bitcoin beta network.
There's a thread about this here stretching back to may 2013.

Or similarly to run in parallel kind of subnets with different
trade-offs or features that are not easy to merge or high risk to
apply all at once to bitcoin with the inflight billions in capital and
transactions on it.

Anyway I thought that was a productive line of thinking, and generally
people seemed to agree and problem statement of 2wp: then 1wp
mechanism was proposed and then Greg extracted a concept from his
SNARK witness idea (which encapsulates a snark variant of a 2wp) but
now without snarks, then 2wp a conservative crypto 2wp proposal was
made.  This was dec 2013 I think on wizards channel.  The sidechain
alpha release now makes this a (alpha quality and so testnet coin, and
without DMMS peg) reality.  I could imagine others who have a desire
to try things could elect to do so and copy that patch-set and make
more side-chains.

This is inherently non-coercive because you largely do not directly
change bitcoin by doing this, people elect to use which ever chain
suits them best given their usecase.  If the sidechain is really early
stage it should have test-net coins in it not bitcoins in it, but
still its caveat emptor kind of beta chain, with good testing but
non-trivial to soft-fork on bitcoin but managable refactor a sidechain
to integrate something novel or try some existing feature (like the
segregated witness which robustly addresses malleability for example)

So I dont want to say side-chains are some magical solution to
everything, but its a direction that others may like to consider for
how to test or even run alternative trade-offs bitcoin side-chains in
parallel.  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
concrete forward progress to the future or we'll be stuck here talking
about perilously large constant changes in 5 years time!

This approach also avoids the one-size fits all problem.

Extension-blocks are an in-chain sub-net type of thing that has a
security boost by being soft-fork enforced (relative to side-chains
which are looser coupled and so more flexible relative to the simplest
form of extension-blocks)

Adam

On 19 June 2015 at 07:59, Eric Lombrozo elombr...@gmail.com wrote:
 I don’t think the issue is between larger blocks on the one hand and things
 like lightning on the other - these two ideas are quite orthogonal.

 Larger blocks aren’t really about addressing basic scalability concerns -
 for that we’ll clearly need architectural and algorithmic improvements…and
 will likely need to move to a model where it isn’t necessary for everyone to
 validate everyone else’s latte purchases. Larger blocks might, at best, keep
 the current system chugging along temporarily - although I’m not sure that’s
 necessarily such a great thing…we need to create a fee market sooner or
 later, and until we do this, block size issues will continue to crop up
 again and again and economic incentives will continue to be misplaced. It
 would be nice to have more time to really develop a good infrastructure for
 this…but without real market pressures, I’m not sure it will happen at all.
 

Re: [Bitcoin-development] comments on BIP 100

2015-06-15 Thread Adam Back
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-development@lists.sourceforge.net/msg07927.html

Discussion / claimed properties on

https://www.reddit.com/r/Bitcoin/comments/39kqzs/how_about_a_softfork_optin_blocksize_increase/

Adam

On 15 June 2015 at 19:53, Raystonn . rayst...@hotmail.com wrote:
 The solution is to hard-fork and merge-mine. This way, both can live, and
 mining power is not divided.

 No, this would essentially be blessing an increase to 42M bitcoins, half on
 each chain.  You could expect a severe market price correction if this were
 to happen.

 From: Rebroad (sourceforge)
 Sent: Monday, June 15, 2015 4:16 AM
 Cc: Bitcoin Dev
 Subject: Re: [Bitcoin-development] comments on BIP 100

 My understanding of this debate is that there are some people who want to
 keep Bitcoin at 1MB block limit, and there are some who want to increase it.

 I for one am curious to see how 1MB limited bitcoin evolves, and I believe
 we can all have a chance to see this AND hard-fork bitcoin to remove the
 block size restriction.

 To remove the 1MB limit required a hard fork. This is not disputed. It's
 what we do with the original (1MB limit) bitcoin that concerns me (and
 other's I am sure).

 What I would like to see is both being allowed to live. Harry Potter and
 Voldermort! (Except neither are evil!)

 The solution is to hard-fork and merge-mine. This way, both can live, and
 mining power is not divided.

 Dogecoin recently hardforked and this hardfork also involved switching to
 merge-mining, so it's been done successfully.

 So, simply, bitcoin as it is doesn't need to actually fork, but instead, at
 a certain block size, a forked bitcoin with the blocksize lmit removed will
 start to be merge-mined alongside bitcoin. Miners can be ready for this.
 Wallets can be ready for this - in fact, for most wallets and merchants they
 will possibly want to default to the bigger blocksize fork since this caters
 for more transactions per block.

 We still don't know how removing the block limit will pan out and what other
 problems with scalability will arise in the future, so by preserving the
 original bitcoin, we keep diversity, and people won't feel their investments
 in bitcoin are being unnecessarily put at risk (as their investments will
 stay in both the new and the old bitcoin).

 The bitcoin core developers can implement a patch like the one recently used
 for dogecoin, to allow the chain to fork at a set point, where at which
 point, bitcoins will be split into the new and the old. Branding will be an
 important issue here I think, so that there is as little confusion as
 possible. I think this is a small price to pay in return for not killing the
 original bitcoin (even if it's true that Satoshi did intend to remove the
 1MB limit at some point).

 If I'm missing something obvious please let me know.

 On Mon, Jun 15, 2015 at 1:50 PM, Mike Hearn m...@plan99.net wrote:

 The fact that using a centralized service is easier isn't a good reason
 IMHO. It disregards the long-term, and introduces systemic risk.


 Well sure, that's easy for you to say, but you have a salary :) Other
 developers may find the incremental benefits of decentralisation low vs
 adding additional features, for instance, and who is to say they are wrong?


 But in cases where using a decentralized approach doesn't *add* anything,
 I cannot reasonably promote it, and that's why I was against getutxos in the
 P2P protocol.


 It does add something though! It means, amongst other things, I can switch
 of all my servers, walk away for good, discard this Mike Hearn pseudonym I
 invented for Bitcoin and the app will still work :) Surely that is an
 important part of being decentralised?

 It also means that as the underlying protocol evolves over time, getutxos
 can evolve along side it. P2P protocol gets encrypted/authenticated? Great,
 one more additional bit of security. If one day miners commit to UTXO sets,
 great, one more additional bit of security. When we start including input
 values in the signature hash, great ... one more step up in security.

 Anyway, I didn't really want to reopen this debate. I just point out that
 third party services are quite happy to provide whatever developers need to
 build great apps, even if doing so fails to meet some kind of perfect
 cryptographic ideal. And that's why they're winning devs.

 Now back to your regularly scheduled block size debates ...


 --

 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 

Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork

2015-06-15 Thread Adam Back
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 funds invested in companies, we owe it to them that we
be open and transparent here.

I would really prefer on a personal nor professional basis to be
having this conversation period, never mind in public, but Mike - your
and Gavin's decision to promote a unilateral hard-fork and code fork
are extremely high risk for bitcoin and so there remains little
choice.  So I apologise again that we have to have this kind of
conversation on a technical discussion list.  This whole thing is
hugely stressful and worrying for developers, companies and investors.

I strongly urge that we return to the existing collaborative
constructive review process that has been used for the last 4 years
which is a consensus by design to prevent one rogue person from
inserting a backdoor, or lobbying for a favoured change on behalf of a
special interest group, or working for bad actor (without accusing you
of any of those - I understand you personally just want to scale
bitcoin, but are inclined to knock heads and try to force an issue you
see, rather than work collaboratively).

For you (and everyone)

- Should there be a summit of some kind, that is open attendance, and
video recorded so that people who are unable to attend can participate
too, so that people can present the technical proposals and risks in
an unbiased way?

(It is not theoretical question, I may have a sponsor and host - not
Blockstream, an independent, its a question for everyone, developers,
users, CTOs, CEOs.)



So here I come back to more frank questions:

Governance

The rest of the developers are wise to realise that they do not want
exclusive control, to avoid governance centralising into the hands of
one person, and this is why they have shared it with a consensus
process over the last 4 years.  No offence but I dont think you
personally are thinking far enough ahead to think you want personal
control of this industry.  Maybe some factions dont trust your
motives, or they dont mind, but feel more assured if a dozen other
people are closely reviewing and have collective review authority.

- Do you understand that attempting to break this process by
unilateral hard-fork is extremely weakening of Bitcoin's change
governance model?

- Do you understand that change governance is important, and that it
is important that there be multiple reviewers and sign-off to avoid
someone being blackmailed or influenced by an external party - which
could potentially result in massive theft of funds if something were
missed?

- Secondarily do you understand that even if you succeed in a
unilateral fork (and the level of lost coins and market cap and damage
to confidence is recoverable), that it sets a precedent that others
may try to follow in the future to introduce coercive features that
break the assurances of bitcoin, like fungibility reducing features
say (topically I hear you once proposed on a private forum the concept
of red-lists, other such proposals have been made and quickly
abandoned), or ultimately if there is a political process to obtain
unpopular changes by unilateral threat, the sky is the limit - rewrite
the social contract at that point without consensus, but by
calculation that people will value Bitcoin enough that they will
follow a lead to avoid risk to the system?


Security

As you probably know some extremely subtle bugs in Bitcoin have at
times slipped past even the most rigorous testings, often with
innocuous but unexpected behaviours, but some security issues  Some
extremely intricate and time-sensitive security defect and incident
response happens from time to time which is not necessarily publicly
disclosed until after the issue has been rolled out and fixed, which
can take some time due to the nature of protocol upgrades,
work-arounds, software upgrade via contacting key miners etc.  We
could take an example of the openSSL bug.

- How do you plan to deal with security  incident response for the
duration you describe where you will have control while you are
deploying the unilateral hard-fork and being in sole maintainership
control?

- Are you a member of the bitcoin security reporting list?

On 15 June 2015 at 11:56, Mike Hearn m...@plan99.net wrote:
 I will review both and mostly delegate to Gavin's good taste around the
 details, unless there is some very strong disagreement. But that seems
 unlikely.
 ...
 Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests
 aren't scored in any way. The final decision rests with the maintainer as in
 ~all open source projects.

As you know the people who have written 95% of the code (and reviewed,
and tested, and formally proved segments etc) are strenuously advising
not to push any consensus 

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

2015-06-14 Thread Adam Back
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, Andy Schroder i...@andyschroder.com wrote:
 Hello,

 I'd support moving to a Linux Foundation e-mail list. I am also against
 google groups. I agree that the gesture of moving indicates that SourceForge
 is not playing nice on other issues and that moving this list shows their
 behavior is being acknowledged.

 I understand your reason for wanting to delete the Source Forge account
 (after reading the links). However, the only problem with that is that the
 SourceForge archive is the oldest one I've found with some early messages
 from Satoshi. Myself finding Bitcoin after its inception, as well as this
 mailing list even later on, it's nice to be able to review the archives.
 SourceForge's interface to those archives is pretty bad though. I'm not sure
 if there is any way to get older messages archived on sites like gmane or
 mail-archive? Does anyone know? You mentioned importing the list archive as
 part of the migration plan, but I guess is this easy to do from SourceForge?


 Andy Schroder

 On 06/14/2015 06:12 AM, Warren Togami Jr. wrote:

 Discomfort with Sourceforge

 For a while now people have been expressing concern about Sourceforge's
 continued hosting of the bitcoin-dev mailing list.  Downloads were moved
 completely to bitcoin.org after the Sept 2014 hacking incident of the SF
 project account.  The company's behavior and perceived stability have been
 growing to be increasingly questionable.


 http://www.theregister.co.uk/2013/11/08/gimp_dumps_sourceforge_over_dodgy_ads_and_installer

 November 2013: GIMP flees SourceForge over dodgy ads and installer

 https://lwn.net/Articles/646118/

 May 28th, 2015: SourceForge replacing GIMP Windows downloads

 http://seclists.org/nmap-dev/2015/q2/194

 June 3rd, 2015: Sourceforge hijacked nmap's old site and downloads.


 When this topic came up over the past two years, it seemed that most people
 agreed it would be a good idea to move.  Someone always suggests Google
 Groups as the replacement host.  Google is quickly shot down as too
 controversial in this community, and it becomes an even more difficult
 question as to who else should host it.  Realizing this is not so simple,
 discussion then dies off until the next time somebody brings it up.


 http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/1943127.DBnVxmfOIh%401337h4x0r/#msg34192607

 Somebody brought it up again this past week.


 It seems logical that an open discussion list is not a big deal to continue
 to be hosted on Sourceforge, as there isn’t much they could do to screw it
 up.  I personally think moving it away now would be seen as a gesture that
 we do not consider their behavior to be acceptable.  There are also some
 benefits in being hosted elsewhere, at an entity able to professionally
 maintain their infrastructure while also being neutral to the content.


 Proposal: Move Bitcoin Dev List to a Neutral Competent Entity


 Bitcoin is a global infrastructure development project where it would be
 politically awkward for any of the existing Bitcoin companies or orgs to
 host due to questions it would raise about perceived political control.Â
 For example, consider a bizarro parallel universe where MtGox was the
 inventor of Bitcoin, where they hosted its development infrastructure and
 dev list under their own name.  Even if what they published was 100%
 technically and ideologically equivalent to the Bitcoin we know in our
 dimension, most people wouldn't have trusted it merely due to appearances
 and it would have easily gone nowhere.


 I had a similar thought process last week when sidechains code was
 approaching release. Sidechains, like Bitcoin itself, are intended to be a
 generic piece of infrastructure (like ethernet?) that anyone can build upon
 and use.  We thought about Google Groups or existing orgs that already host
 various open source infrastructure discussion lists like the IETF or the
 Linux Foundation.  Google is too controversial in this community, and the
 IETF is seen as possibly too politically fractured.  The Linux Foundation
 hosts a bunch of infrastructure lists and it seems that nobody in the Open
 Source industry considers them to be particularly objectionable.  I talked
 with LF about the idea of hosting generic Bitcoin-related infrastructure
 development lists.  They agreed as OSS infrastructure dev is already within
 their charter, so early this week sidechains-dev list began hosting there.


 From the perspective of our community, for bitcoin-dev it seems like a great
 fit.  Why?  While they are interested in supporting general open source
 development, the LF has literally zero stake in this.  In addition to
 

[Bitcoin-development] comments on BIP 100

2015-06-14 Thread Adam Back
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 actually not getting blocked!).

http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

may have changed since the original [1]

Over the original proposal:

1. there should be a hard cap, not indefinitely growing.

2. there should be  a growth limiter (no more than X%/year)

3. I think the miners should not be given a vote that has no costs to
cast, because their interests are not necessarily aligned with users
or businesses.

I think Greg Maxwell's difficulty adjust [2] is better here for that
reason.  It puts quadratic cost via higher difficulty for miners to
vote to increase block-size, which miners can profitably do if there
are transactions with fees available to justify it. There is also the
growth limiter as part of Greg's proposal. [3]

I think bitcoin will have to involve layering models that uplift
security to higher layers, but preserve security assurances, and
smart-contracts even, with protocols that improve the algorithmic
complexity beyond O(n^2) in users, like lightning, and there are
multiple other candidates with useful tradeoffs for various use-cases.

One thing that is concerning is that few in industry seem inclined to
take any development initiatives or even integrate a library.  I
suppose eventually that problem would self-correct as new startups
would make a more scalable wallet and services that are layer2 aware
and eat the lunch of the laggards.  But it will be helpful if we
expose companies to the back-pressure actually implied by an O(n^2)
scaling protocol and don't just immediately increase the block-size to
levels that are dangerous for decentralisation security, as an
interventionist subsidy to save them having to do basic integration
work.  Otherwise I think whichever any kind of kick the can some 2-5
years down the road we consider, we risk the whole saga repeating in a
few years, when no algorithmic progress has been made and even more
protocol inertia has set in.

Adam

[1] original proposal comments on reddit
https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/

[2] flexcap propoal by Greg Maxwell see post by Mark Freidenbach
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html

[3] growth limited proposal for flexcap by Greg Maxwell
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork

2015-06-14 Thread Adam Back
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
have questions, so I'll start with some:

( I noticed some of your initial thoughts are online here
https://www.youtube.com/watch?v=DB9goUDBAR0 or the full podcast
https://epicenterbitcoin.com/podcast/082/ )

- Are you releasing a BIP for that proposal for review?

- If the reviewers all say NACK will you take on board their suggestions?

- On the idea of a non-consensus hard-fork at all, I think we can
assume you will get a row of NACKs.  Can you explain your rationale
for going ahead anyway?  The risks are well understood and enormous.

- How do you propose to deal with the extra risks that come from
non-consensus hard-forks?  Hard-forks themselves are quite risky, but
non-consensus ones are extremely dangerous for consensus.

- If you're going it alone as it were, are you proposing that you will
personally maintain bitcoin-XT?  Or do you have a plan to later hand
over maintenance to the bitcoin developers?

- Do you have contingency plans for what to do if the non-consensus
hard-fork goes wrong and $3B is lost as a result?


As you can probably tell I think a unilateral fork without wide-scale
consensus from the technical and business communities is a deeply
inadvisable.  While apparently some companies have expressed interest
in increased scale, I can only assume they do no yet understand the
risks.  I suggest before they would actually go ahead that they seek
independent advice.

Of the overall process, I think you can agree we should not be making
technical decisions with this level of complexity and consensus risk
with financial implications of this magnitude under duress of haste?
This seems otherwise a little like the moral hazard of the 2008
financial collapse that Satoshi put the quote in the genesis block
about.

I think its best that we progress as Jeff Garzik has done to have
engineering discussions centre around BIPs, running code for review,
simulation and careful analysis.

I understand this has been going on for a long time, and some people
are frustrated with the rate of progress, but making hasty,
contentious or unilateral actions in this space is courting disaster.

Please use your considerable skills to, along with the rest of the
community, work on this problem collaboratively.

I can sincerely assure you everyone does want to scale bitcoin and
shares your long term objective on that.

Adam

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

2015-06-02 Thread Adam Back
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 loss as you can implement not after by
making it the previous holders responsibility to spend a not before
back to themselves.)

Adam

On 2 June 2015 at 13:52, Stephen stephencalebmo...@gmail.com wrote:
 Do you think it would be useful to have an inverted version of both CSV and
 CLTV? To verify if an output is spent before a specific time. CLTV and CSV
 could be implemented by taking two stack arguments, an integer for the
 comparison and TRUE/FALSE.

 Now that I think about this more, the problem is that, for example, just
 having a lock time of less than some value doesn't actually mean it has to
 be spent before that script value, so this might not work. Likely any
 implementations of such a feature would have to provide the script execution
 environment with access to information that it doesn't have now, which is
 what we are trying to avoid.

 Best,
 Stephen



 On Jun 2, 2015, at 12:16 AM, Mark Friedenbach m...@friedenbach.org wrote:

 You are correct! I am maintaining a 'checksequenceverify' branch in my git
 repository as well, an OP_RCLTV using sequence numbers:

 https://github.com/maaku/bitcoin/tree/checksequenceverify

 Most of the interesting use cases for relative lock-time require an RCLTV
 opcode. What is interesting about this architecture is that it possible to
 cleanly separate the relative lock-time (sequence numbers) from the RCLTV
 opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like
 CLTV, the CSV opcode only checks transaction data and requires no contextual
 knowledge about block headers, a weakness of the other RCLTV proposals that
 violate the clean separation between libscript and libconsensus. In a
 similar way, this BIP proposal only touches the transaction validation logic
 without any impact to script.

 I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY
 opcode and its enabling applications. But, well, one thing at a time.

 On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse stephencalebmo...@gmail.com
 wrote:

 Hi Mark,

 Overall, I like this idea in every way except for one: unless I am missing
 something, we may still need an OP_RCLTV even with this being implemented.

 In use cases such as micropayment channels where the funds are locked up
 by multiple parties, the enforcement of the relative locktime can be done by
 the first-signing party. So, while your solution would probably work in
 cases like this, where multiple signing parties are involved, there may be
 other, seen or unforeseen, use cases that require putting the relative
 locktime right into the spending contract (the scriptPubKey itself). When
 there is only one signer, there's nothing that enforces using an nSequence
 and nVersion=2 that would prevent spending the output until a certain time.

 I hope this is received as constructive criticism, I do think this is an
 innovative idea. In my view, though, it seems to be less fully-featured than
 just repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously
 that it saves transaction space by repurposing unused space, and would
 likely work for most cases where an OP_RCLTV would be needed.

 Best,
 Stephen

 On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach m...@friedenbach.org
 wrote:

 I have written a reference implementation and BIP draft for a soft-fork
 change to the consensus-enforced behaviour of sequence numbers for the
 purpose of supporting transaction replacement via per-input relative
 lock-times. This proposal was previously discussed on the mailing list in
 the following thread:

 http://sourceforge.net/p/bitcoin/mailman/message/34146752/

 In short summary, this proposal seeks to enable safe transaction
 replacement by re-purposing the nSequence field of a transaction input to be
 a consensus-enforced relative lock-time.

 The advantages of this approach is that it makes use of the full range of
 the 32-bit sequence number which until now has rarely been used for anything
 other than a boolean control over absolute nLockTime, and it does so in a
 way that is semantically compatible with the originally envisioned use of
 sequence numbers for fast mempool transaction replacement.

 The disadvantages are that external constraints often prevent the full
 range of sequence numbers from being used when interpreted as a relative
 lock-time, and re-purposing nSequence as a relative lock-time precludes its
 use in other contexts. The latter point has been partially addressed by
 having the relative lock-time semantics be enforced only if the
 most-significant bit of nSequence is set. This preserves 31 bits for
 alternative use when relative lock-times are not required.

 The BIP draft can be found at 

[Bitcoin-development] soft-fork block size increase (extension blocks)

2015-06-01 Thread Adam Back
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 than hard forks.
Particularly if a hard-fork were really provoked without clear and
wide consensus - dragons lay there.

 Then ask the various wallet developer how long it would take them to update
 their software to support something like this,

I don't think thats any particular concern, extension block payments
are forwards and backwards compatible.  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.  The people that have
the need for it will work on it.  Market at work.  If it turns out
they dont really have a need for it, just projected huge numbers for
their business plan that say dont materialise, well no foul.

 and do some UI mockups of what the experience would look like for users.

I am not a UX guy, but for example it might be appropriate for tipping
services or other micropayments to use an extension block.  Or small
retail payments.  They can choose what address they use.  Merchants,
integrators etc can do likewise.
It gives plenty enough scope that people can work with useful
trade-offs while others work on lightning.

 If there are two engineering solutions to a problem, one really simple, and
 one complex, why would you pick the complex one?

Because the more complex one is safer, more flexible, more future
proof and better for decentralisation (and so as a bonus and might
actually get done without more months of argument as its less
contentious because it gives users choice to opt-in).  Bitcoin itself
is complex, a central ledger is simpler but as we know uninteresting
which is to say this is a security tradeoff.

Obviously I do appreciate KISS as a design principle, and utility of
incremental improvements, but this is a security trade-off we're
discussing here.  I am proposing a way to not weaken security, while
getting what you think is important - access to more TPS with a higher
centralisation tradeoff (for those who opt-in to it, rather than for
everyone whether that tradeoff is strongly against their interests or
not).

The decentralisation metrics are getting worse, not better, see Greg
Maxwell's comments
http://www.reddit.com/r/Bitcoin/comments/37vg8y/is_the_blockstream_company_the_reason_why_4_core/crqg381

This would not by those metrics be a good moment in history to make
the situation worse.

 Especially if the complex solution has all of the problems of the simple
 one (20MB extension blocks are just as dangerous as 20MB main blocks,
 yes? If not, why not?)

Not at all, thats the point.  Bitcoin has a one-size fits all
blocksize.  People can pool mine the 8MB extension block, while solo
or GBT mining the 1MB block.  Thats more centralising than staying at
1MB (because to get the fees from the extension block some people
without that kind of bandwidth are pool mining 8/9th of the lower
security/decentralisation transactions.  But its less centralising
than a fixed blocksize of 9MB (1+8 for apples/apples) because
realistically if those transactions are not spam, they would've
happened offchain, and offchain until we get lightning like systems
up, means central systems which are worse than the slight
centralisation of 8MB blocks being single servers and prone to custody
 security failure.  I think you made that point yourself in a recent
post also.

Sound good? ;)  Seriously I think its the least bad idea I've heard on
this topic.

As an aside, a risk with using companies as a sounding board, is that
you can get a misleading sense of consensus.  Did they understand the
tradeoff between security (decentralisation) and blocksize.  Did they
care?  Do they represent users interests?  Would they have voted
instead for extension blocks if it was presented in similar terms?  (I
have to imagine they might have preferred extension blocks given the
better story if you gloss over complexity and tradeoffs).

Adam

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

2015-06-01 Thread Adam Back
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 extension blocks
 and I withdraw from that to a wallet that doesn't, the money will never
 arrive from my perspective. Yet the exchange will claim they sent it and
 they will wash their hands of the matter. Disaster.

To be clear in case you are missing part of the mechanism.: it is
forward and backwards compatible meaning a 1MB address can receive
payments from an 8MB address (at reduced security if it has software
that doesnt understand it) and a 1MB address can pay an 8MB address by
paying to an OP_TRUE that has meaning to the extension block nodes.

A 1MB client wont even understand the difference between a 1MB and 8MB
out payment.  An 8MB client will understand and pay 1MB addresses in a
different way (moving the coin back to the 1MB chain).

So its opt-in and incrementally deployable.  Exchanges could encourage
their users to use wallets that support 8MB blocks, eg by charging a
fee for 1MB transactions.  If 1MB blocks experience significant fee
pressure, this will be persuasive.  Or they could chose not to and eat
the cost.  This is all normal market adoption of a new cheaper
technical option (in this case with a tradeoff of reduced
security/more centralisation for those opting in to it).

 Because the more complex one is safer, more flexible, more future
 proof and better for decentralisation

 I disagree with all of those points. I find Lightning/Stroem etc to be more
 dangerous, less flexible, and worse for decentralisation. I explain why
 here:

Extension blocks  lightning are unrelated things.

While I understand the need for being practical, there is IMO, amongst
engineering maxims something as far as being too pragmatic,
dangerously pragmatic even.  We cant do stuff in bitcoin that has bad
carry costs, nor throw out the baby with the bathwater.

The situation is just that we are facing a security vs volume tradeoff
and different people will have different requirements and comfort
zones.  If I am not misremembering, I think you've sided typically
with the huge block, big data center only end of the spectrum.  What I
am proposing empowers you to do experiments in that direction without
getting into a requirements conflict with people who value more
strongly the bitcoin properties arising from it being robustly
decentralised.

I am not sure personally where the blocksize discussion comes out - if
it stays as is for a year, in a wait and see, reduce spam, see
fee-pressure take effect as it has before, work on improving improve
decentralisation metrics, relay latency, and do a blocksize increment
to kick the can if-and-when it becomes necessary and in the mean-time
try to do something more long-term ambitious about scale rather than
volume.  Bitcoin without scale improvements probably wont get the
volume people would like.  So scale is more important than volume; and
security (decentralisation) is important too.  To the extreme analogy
we could fix scale tomorrow by throwing up a single high perf
database, but then we'd break the security properties arising from
decentralisation.  We should improve both within an approximately safe
envelope IMO.

Adam

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

2015-06-01 Thread Adam Back
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-group and high hashrate are definitionally
the well connected, so the cost of getting good connectivity to high
hashrate groups is naturally borne by people outside of those groups.
Or thats the incentive anyway.

Adam


On 1 June 2015 at 19:30, Mike Hearn m...@plan99.net wrote:
 I don't see this as an issue of sensitivity or not. Miners are businesses
 that sell a service to Bitcoin users - the service of ordering transactions
 chronologically. They aren't charities.

 If some miners can't provide the service Bitcoin users need any more, then
 OK, they should not/cannot mine. Lots of miners have come and gone since
 Bitcoin started as different technology generations came and went. That's
 just business.

 --

 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction

2015-05-29 Thread Adam Back
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 extension block
(say 10MB) and the existing 1MB block.  The extension block is
committed to in the 1MB chain.  Users can transfer bitcoin into the
extension block, and they can transfer them out.

The interesting thing is this makes block sizes changes opt-in and
gives users choice.  Choice is good.  Bitcoin has a one-size-fits-all
blocksize at present hence the block size debate.  If a bigger
block-size were an opt-in choice, and some people wanted 10MB or even
100MB blocks for low value transactions I expect it would be far
easier a discussion - people who think 100MB blocks are dangerously
centralising, would not opt to use them (or would put only small
values they can afford to lose in them).  There are some security
implications though, so this also is nuanced, and more on that in a
bit.

Fee pressure still exists for blocks of difference size as the
security assurances are not the same.  It is plausible that some
people would pay more for transactions in the 1MB block.

Now there are three choices of validation level, rather than the
normal 2-levels of SPV or full-node, with extension blocks we get a
choice: A) a user could run a full node for both 1MB and 10MB blocks,
and get full security for both 1MB and 10MB block transactions (but at
higher bandwidth cost), or B) a user could run a full node on the 1MB
block, but operate as an SPV node for the 10MB block, or C) run in SPV
mode for both 1MB and 10MB blocks.

Similarly for mining - miners could validate 1MB and 10MB transactions
(solo mine or GBT-style), or they could self-validate 1MB transactions
and pool mine 10MB transactions (have a pool validate those).

1MB full node users who do not upgrade to software that understands
extension blocks, could run in SPV mode with respect to 10MB blocks.
Here lies the risk - this imposes a security downgrade on the 1MB
non-upgraded users, and also on users who upgrade but dont have the
bandwidth to validate 10MB blocks.


We could defend non-upgrade users by making receiving funds that came
via the extension block opt-in also, eg an optional to use new address
version and construct the extension block so that payments out of it
can only go to new version addresses.

We could harden 1MB block SPV security (when receiving weaker
extension block transactions) in a number of ways: UTXO commitments,
fraud proofs (and fraud bounties) for moving from the extension block
to the 1MB block.  We could optionally require coins moving via the
extension block to the 1MB block to be matured (eg 100 blocks delay)


Anyway something else to evaluate.  Not as simple to code as a
hard-fork, but way safer transition than a hard-fork, and opt-in - if
you prefer the higher decentralisation of 1MB blocks, keep using them;
if you prefer 10MB blocks you can opt-in to them.

Adam

On 29 May 2015 at 17:39, Raystonn . rayst...@hotmail.com wrote:
 Regarding Tier’s proposal: The lower security you mention for extended
 blocks would delay, possibly forever, the larger blocks maximum block size
 that we want for the entire network.  That doesn’t sound like an optimal
 solution.

 Regarding consensus for larger maximum block size, what we are seeing on
 this list is typical of what we see in the U.S. Congress.  Support for
 changes by the stakeholders (support for bills by the citizens as a whole)
 has become irrelevant to the probability of these changes being adopted.
 Lobbyists have all the sway in getting their policies enacted.  In our case,
 I would bet on some lobbying of core developers by wealthy miners.

 Someone recently proposed that secret ballots could help eliminate the power
 of lobbyists in Congress.  Nobody invests in that which cannot be confirmed.
 Secret ballots mean the vote you are buying cannot be confirmed.  Perhaps
 this will work for Bitcoin Core as well.


 From: Tier Nolan
 Sent: Friday, May 29, 2015 7:22 AM
 Cc: Bitcoin Dev
 Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB
 stepfunction

 On Fri, May 29, 2015 at 3:09 PM, Tier Nolan tier.no...@gmail.com wrote:



 On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen gavinandre...@gmail.com
 wrote:

 But if there is still no consensus among developers but the bigger
 blocks now movement is successful, I'll ask for help getting big miners to
 do the same, and use the soft-fork block version voting mechanism to
 (hopefully) get a majority and then a super-majority willing to produce
 bigger blocks. The purpose of that process is to prove to any doubters that
 they'd better start supporting bigger blocks or they'll be left behind, and
 to give them a chance to upgrade before that happens.


 How do you define that the movement is successful?


 Sorry again, I 

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

2015-05-26 Thread Adam Back
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 19:22, Danny Thorpe danny.tho...@gmail.com wrote:
 What prevents RBF from being used for fraudulent payment reversals?

 Pay 1BTC to Alice for hard goods, then after you receive the goods broadcast
 a double spend of that transaction to pay Alice nothing? Your only cost is
 the higher network fee of the 2nd tx.

 Thanks,
 -Danny

 On Mon, May 25, 2015 at 5:10 PM, Peter Todd p...@petertodd.org wrote:

 On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
  CPFP also solves it just fine.

 CPFP is a significantly more expensive way of paying fees than RBF,
 particularly for the use-case of defragmenting outputs, with cost
 savings ranging from 30% to 90%


 Case 1: CPFP vs. RBF for increasing the fee on a single tx
 --

 Creating an spending a P2PKH output uses 34 bytes of txout, and 148
 bytes of txin, 182 bytes total.

 Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
 Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size.
 I forget to click on the priority fee option, so it goes out with the
 minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
 creating a new transaction t2 that's 192 bytes in size. I want to pay
 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
 transaction fees.

 On the other hand, had I use RBF, my wallet would have simply
 rebroadcast t1 with the change address decreased. The rules require you
 to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new
 fee level, or 218uBTC of fees in total.

 Cost savings: 48%


 Case 2: Paying multiple recipients in succession
 

 Suppose that after I pay Alice, I also decide to pay Bob for his hard
 work demonstrating cryptographic protocols. I need to create a new
 transaction t2 spending t1's change address. Normally t2 would be
 another 226 bytes in size, resulting in 226uBTC additional fees.

 With RBF on the other hand I can simply double-spend t1 with a
 transaction paying both Alice and Bob. This new transaction is 260 bytes
 in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
 consumed broadcasting it, resulting in an additional 36uBTC of fees.

 Cost savings: 84%


 Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
 

 The above situation gets even worse with multisig. t1 in the multisig
 case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
 in fees. With RBF we rewrite t1 with an additional output, resulting in
 a 399 byte transaction, with just 36uBTC in additional fees.

 Cost savings: 90%


 Case 4: Dust defragmentation
 

 My wallet has a two transaction outputs that it wants to combine into
 one for the purpose of UTXO defragmentation. It broadcasts transaction
 t1 with two inputs and one output, size 340 bytes, paying zero fees.

 Prior to the transaction confirming I find I need to spend those funds
 for a priority transaction at the 1mBTC/KB fee level. This transaction,
 t2a, has one input and two outputs, 226 bytes in size. However it needs
 to pay fees for both transactions at once, resulting in a combined total
 fee of 556uBTC. If this situation happens frequently, defragmenting
 UTXOs is likely to cost more in additional fees than it saves.

 With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
 bytes in size, paying 374uBTC. Even better, if one of the two inputs is
 sufficiently large to cover my costs I can doublespend t1 with a
 1-in-2-out tx just 226 bytes in size, paying 226uBTC.

 Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
   costs you more than you save

 --
 'peter'[:-1]@petertodd.org
 134ce6577d4122094479f548b997baf84367eaf0c190bc9f


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring 

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

2015-05-26 Thread Adam Back
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 fees.

(As well as optionally tacking on additional pending payments to other
addresses funded from the higher input).

Adam

On 26 May 2015 at 22:29, s7r s...@sky-ip.org wrote:
 What is wrong with the man testing some ideas on his custom branch? This
 is how improvements come to life. I saw in the BIPs some really
 interesting ideas and nice brainstorming which came from Peter Todd.

 Now, my question, if replace by fee doesn't allow me to change the
 inputs or the outputs, I can only add outputs... what can I do with this
 feature? If I sent a tx and want to replace it with a higher fee one,
 the higher fee one can only have maybe additional change addresses or
 another payment, if the inputs suffice? Do we have any real use cases?

 P.S. is it planned to include this by default in bitcoin core 10.0.3 or
 it will remain just on Peter's branch?

 On 5/26/2015 11:30 PM, joli...@airmail.cc wrote:
 You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
 and you have big banks as clients. Shit like replace-by-fee and leading
 the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.

 Peter Todd - 8930511 Canada Ltd.
 1214-1423 Mississauga Valley Blvd.
 Mississauga ON L5A 4A5
 Canada

 https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511

 On 2015-05-26 00:10, Peter Todd wrote:
 On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
 CPFP also solves it just fine.

 CPFP is a significantly more expensive way of paying fees than RBF,
 particularly for the use-case of defragmenting outputs, with cost
 savings ranging from 30% to 90%


 Case 1: CPFP vs. RBF for increasing the fee on a single tx
 --

 Creating an spending a P2PKH output uses 34 bytes of txout, and 148
 bytes of txin, 182 bytes total.

 Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
 Alice. This results in a 1in/2out transaction t1 that's 226 bytes in
 size.
 I forget to click on the priority fee option, so it goes out with the
 minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
 creating a new transaction t2 that's 192 bytes in size. I want to pay
 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
 transaction fees.

 On the other hand, had I use RBF, my wallet would have simply
 rebroadcast t1 with the change address decreased. The rules require you
 to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the
 new
 fee level, or 218uBTC of fees in total.

 Cost savings: 48%


 Case 2: Paying multiple recipients in succession
 

 Suppose that after I pay Alice, I also decide to pay Bob for his hard
 work demonstrating cryptographic protocols. I need to create a new
 transaction t2 spending t1's change address. Normally t2 would be
 another 226 bytes in size, resulting in 226uBTC additional fees.

 With RBF on the other hand I can simply double-spend t1 with a
 transaction paying both Alice and Bob. This new transaction is 260
 bytes
 in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
 consumed broadcasting it, resulting in an additional 36uBTC of fees.

 Cost savings: 84%


 Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
 

 The above situation gets even worse with multisig. t1 in the multisig
 case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
 in fees. With RBF we rewrite t1 with an additional output, resulting in
 a 399 byte transaction, with just 36uBTC in additional fees.

 Cost savings: 90%


 Case 4: Dust defragmentation
 

 My wallet has a two transaction outputs that it wants to combine into
 one for the purpose of UTXO defragmentation. It broadcasts transaction
 t1 with two inputs and one output, size 340 bytes, paying zero fees.

 Prior to the transaction confirming I find I need to spend those funds
 for a priority transaction at the 1mBTC/KB fee level. This transaction,
 t2a, has one input and two outputs, 226 bytes in size. However it needs
 to pay fees for both transactions at once, resulting in a combined
 total
 fee of 556uBTC. If this situation happens frequently, defragmenting
 UTXOs is likely to cost more in additional fees than it saves.

 With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
 bytes in size, paying 374uBTC. Even better, if one of the two inputs is
 sufficiently large to cover my costs I can doublespend t1 with a
 1-in-2-out tx just 226 bytes in size, paying 226uBTC.

 Cost savings: 32% to 59%, or even infinite if defragmentation 

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

2015-05-26 Thread Adam Back
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 change address is unused.

(If you had bundled extra transactions into the replacement, spending
from the additional inputs, then you'll need to resubmit those as a
separate transaction).

(You have to keep in mind re-orgs so for example the original tx could
be put into a block, and then that block could get reorged by another
block that grows into a longer chain with the replacement tx in it (or
vice versa)).

Adam

On 26 May 2015 at 23:09, Danny Thorpe danny.tho...@gmail.com wrote:
 Thanks for the clarification.

 So, since RBF applies only to pending transactions in the mempool awaiting
 incorporation into a block, there is a window of opportunity in which the
 pending tx is incorporated into a block at the same time that the spender is
 constructing and publishing a replacement for that pending tx.

 The replacement transaction would be rejected by the peer network as a
 double spend because it conflicts with the now confirmed original tx, and
 the spender will have to go back and create a new stand-alone transaction to
 accomplish what they hoped to do with an RBF replacement.

 So an implementation that wishes to take advantage of RBF will still need to
 have a plan B implementation path to handle the corner case of a
 replacement tx being rejected as a double spend.

 Is this correct?

 I'm just trying to get my head around the implementation cost vs benefit of
 RBF in the context of my applications.

 Thanks,
 -Danny

 On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille pieter.wui...@gmail.com
 wrote:

 It's just a mempool policy rule.

 Allowing the contents of blocks to change (other than by mining a
 competing chain) would be pretty much the largest possible change to
 Bitcoin's design



 --

 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Long-term mining incentives

2015-05-12 Thread Adam Back
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 innovation might be
found (or alternatively maybe its not mathematically possible).

Towards that it would be useful to try further to prove this one way
or another (prove that proof of stake cant work if that is generically
mathematically provable).

Adam

On 12 May 2015 at 14:24, Pedro Worcel pe...@worcel.com wrote:
 Disclaimer: I don't know anything about Bitcoin.

 2) Proof-of-idle supported (I wish Tadge Dryja would publish his
 proof-of-idle idea)
 3) Fees purely as transaction-spam-prevention measure, chain security via
 alternative consensus algorithm (in this scenario there is very little
 mining).

 I don't understand why you would casually mention moving away from Proof of
 Work, I thought that was the big breakthrough that made Bitcoin possible at
 all?

 Thanks,
 Pedro

 2015-05-13 4:10 GMT+12:00 Gavin Andresen gavinandre...@gmail.com:

 Added back the list, I didn't mean to reply privately:

 Fair enough, I'll try to find time in the next month or three to write up
 four plausible future scenarios for how mining incentives might work:

 1) Fee-supported with very large blocks containing lots of tiny-fee
 transactions
 2) Proof-of-idle supported (I wish Tadge Dryja would publish his
 proof-of-idle idea)
 3) Fees purely as transaction-spam-prevention measure, chain security via
 alternative consensus algorithm (in this scenario there is very little
 mining).
 4) Fee supported with small blocks containing high-fee transactions moving
 coins to/from sidechains.

 Would that be helpful, or do you have some reason for thinking that we
 should pick just one and focus all of our efforts on making that one
 scenario happen?

 I always think it is better, when possible, not to bet on one horse.


 On Tue, May 12, 2015 at 10:39 AM, Thomas Voegtlin thom...@electrum.org
 wrote:

 Le 12/05/2015 15:44, Gavin Andresen a écrit :
  Ok, here's my scenario:
 
  https://blog.bitcoinfoundation.org/a-scalability-roadmap/
 
  It might be wrong. I welcome other people to present their road maps.
 

 [answering to you only because you answered to me and not to the list;
 feel free to repost this to the list though]

 Yes, that's exactly the kind of roadmap I am asking for. But your blog
 post does not say anything about long term mining incentives, it only
 talks about scalability. My point is that we need the same kind of thing
 for miners incentives.




 --
 --
 Gavin Andresen


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Adam Back
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
reaction for example, and reset difficulty at the same time, or freeze
transactions until some minimum hashrate is reached.  People would figure
out what is the least bad way forward.

Adam
On May 7, 2015 3:09 PM, Roy Badami r...@gnomon.org.uk wrote:

 On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
  I would not modify my node if the change introduced a perpetual 100 BTC
  subsidy per block, even if 99% of miners went along with it.

 Surely, in that scenario Bitcoin is dead.  If the fork you prefer has
 only 1% of the hash power it is trivially vulnerably not just to a 51%
 attack but to a 501% attack, not to mention the fact that you'd only
 be getting one block every 16 hours.

 
  A hardfork is safe when 100% of (economically relevant) users upgrade. If
  miners don't upgrade at that point, they just lose money.
 
  This is why a hashrate-triggered hardfork does not make sense. Either you
  believe everyone will upgrade anyway, and the hashrate doesn't matter. Or
  you are not certain, and the fork is risky, independent of what hashrate
  upgrades.

 Beliefs are all very well, but they can be wrong.  Of course we should
 not go ahead with a fork that we believe to be dangerous, but
 requiring a supermajority of miners is surely a wise precaution.  I
 fail to see any realistic scenario where 99% of miners vote for the
 hard fork to go ahead, and the econonomic majority votes to stay on
 the blockchain whose hashrate has just dropped two orders of magnitude
 - so low that the mean time between blocks is now over 16 hours.

 
  And the march 2013 fork showed that miners upgrade at a different
 schedule
  than the rest of the network.
  On May 7, 2015 5:44 PM, Roy Badami r...@gnomon.org.uk wrote:
 
  
On the other hand, if 99.99% of the miners updated and only 75% of
merchants and 75% of users updated, then that would be a serioud
 split of
the network.
  
   But is that a plausible scenario?  Certainly *if* the concensus rules
   required a 99% supermajority of miners for the hard fork to go ahead,
   then there would be absoltely no rational reason for merchants and
   users to refuse to upgrade, even if they don't support the changes
   introduces by the hard fork.  Their only choice, if the fork succeeds,
   is between the active chain and the one that is effectively stalled -
   and, of course, they can make that choice ahead of time.
  
   roy
  
  
  
 --
   One dashboard for servers and applications across
 Physical-Virtual-Cloud
   Widest out-of-the-box monitoring support with 50+ applications
   Performance metrics, stats and reports that give you Actionable
 Insights
   Deep dive visibility with transaction tracing using APM Insight.
   http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
   ___
   Bitcoin-development mailing list
   Bitcoin-development@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/bitcoin-development
  


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Adam Back
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 implemented in policy and not consensus, but it provides
fast transactions and a lot of the current ecosystem is using it for
low value transactions.  why would anyone want to vandalise that.

to echo Mike bitcoin itself kind of depends on some honest majority,
we can otherwise get to situations soon enough where its more
profitable to double-spend than mine honestly as subsidy drops and
transaction values increase even without 0-confirm transactions.
subsidy doesnt last forever (though it lasts a really long time) and
even right now if you involve values that dwarf subsidy you could make
a criminally rational behaviour that was more profitable.  we even
saw 0-confirm odds-attacks against satoshi dice clones.  but if we
assume the criminal rational model, its a is a race to the bottom
logic, and bitcoin is already broken if we have someone who wants to
go for it with high values.  that'd be scorched earth also.

(I read the rest of the arguments, i understood them, I disagree, no
need to repeat in reply.)

So how about instead, to be constructive, whether you agree with the
anti-arson view or not, lets talk about solutions.  Here's one idea:

We introduce a new signature type that marks itself as can be spent by
miners if a double-spend is seen (before 1-confirm.)  We'd define a
double-spend as a spend that excludes outputs to avoid affecting valid
double-spend scenarios.  And we add behaviour to relay those
double-spends (at priority).  We may even want the double-spend to be
serialisation incomplete but verifiable to deter back-channel payments
to pretend not to receive one, in collusion with the double-spending
party.

Now the risk to the sender is if they accidentally double-spend.  How
could they do that?  By having a hardware or software crash where they
sent a tx but crashed before writing a record of having sent it.  The
correct thing to do would be to transactionally write the transaction
before sending it.  Still you can get a fail if the hardware
irrecoverably fails, and you have to resume from backup.  Or if you
run multiple non-synced wallets on the same coins.

Typically if you recover from backup the 1-confirmation window will
have passed so the risk is limited.

The feature is opt-in so you dont have to put high value coins at risk
of failure.

(Its related to the idea of a one-use signature, where two signatures
reveals a simultaneous equation that can recover the private key;
except here the miner is allowed to take the coins without needing the
private key).

Its soft-forkable because its a new transaction type.

ps I agree with Greg also that longer-term more scalable solutions are
interesting, but I'd like to see the core network work as a stepping
stone.  As Justus observed: the scalable solutions so far have had
non-ideal ethos tradeoffs so are not drop-in upgrades to on-chain
0-confirm.

Adam

On 22 February 2015 at 04:06, Jeff Garzik jgar...@bitpay.com wrote:
 On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote:
 On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote:
 This isn't some theoretical exercise.  Like it or not many use
 insecure 0-conf transactions for rapid payments.  Deploying something
 that makes 0-conf transactions unusable would have a wide, negative
 impact on present day bitcoin payments, thus scorched earth

 And maybe by maintaining first seen policies we're harming the system
 in the long term by encouraging people to widely deploy systems based
 on extremely weak assumptions.

 Lacking a coded, reviewed alternative, that's only a platitude.
 Widely used 0-conf payments are where we're at today.  Simply ceasing
 the maintaining [of] first seen policies alone is simply not a
 realistic option.  The negative impact to today's userbase would be
 huge.

 Instant payments need a security upgrade, yes.

 --
 Jeff Garzik
 Bitcoin core developer and open source evangelist
 BitPay, Inc.  https://bitpay.com/

 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Download BIRT iHub F-Type - The 

Re: [Bitcoin-development] bloom filtering, privacy

2015-02-21 Thread Adam Back
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 transactions, there is
no harm downloading headers  bloom filters without Tor - there is no
identity nor addresses revealed by doing so.  So over Tor you would
just be fetching transactions that match the address.

For downloading transactions unless you frequently receive
transactions you wont be fetching every block.  Or are you assuming
bloom filters dialled up to the point of huge false positives?  You
said otherwise.

Mid-term I'd say you want some basic request tunneling as part of
bitcoin, that maybe isnt Tor, to avoid sharing their fate if Tor
controversies are a risk to Tor service.  Some of the bitcoin-Tor
specific weak points could maybe then be addressed.

Relatedly I think bitcoin could do with a store-and-forward message
bus with privacy and strong reliability via redundancy (but less
redundancy maybe than consensus all-nodes must receiving and agree and
store forever).  That  provides an efficient store-and-forward SPV
receivable stealth-address solution that doesnt suck: send the
recipient their payment, if they like it they broadcast it themselves.
As a bonus store-and-forward message mixes are better able to provide
meaningful network privacy than interactive privacy networks.  You
could spend over the same channel

You seem to be saying at one point that Tor is useless against
pervasive eavesdropper threat model (which I am not sure I agree with,
minimally it makes them work for the info and adds uncertainty; and
not been paying super close attention but I think some of the Snowden
releases suggest Tor is a net win) and secondly that other types of
attackers are disinterested (how do we know that?) or maybe that you
dont care about privacy vs them (maybe some users do!)

It would certainly be nice to get real privacy from a wider range of
attackers but nothing (current situation) is clearly worse; using
block bloom filters we'd make the pervasive case harder work, and the
nosy full node learn nothing.

Adam

On 21 February 2015 at 13:28, Mike Hearn m...@plan99.net wrote:
 Let's put the UTXO commitments/anti-fraud proofs to one side for a moment. I
 would like to see them happen one day, but they aren't critical to these
 protocols and are just proving to be a distraction.



 Then they make fresh random connections to different nodes and request
 download of the respective individual transactions from the full node.


 ...

 About privacy the node can make different random connections to
 different nodes to fetch addresses . The full node cant
 correlate the addresses as belonging to the same person by correlating
 the download requests for them, because they are made via different
 nodes.


 Apologies for the wall of text, but I don't think this will work nor solve
 any real problem. And I must justify such a strong statement clearly.

 First: technical issues

 When you download the per-block Bloom filter and test, what you get back is
 a set of script elements (addresses, keys, OP_RETURN tags etc). But then in
 the next step you are saying that you connect to random peers and request
 individual transactions. We don't know that at this point. All we know are a
 set of addresses that possibly matched. So I think what you mean is wallets
 connect to random peers and request transactions in block N that match a
 given set of addresses.

 This is what Bloom filtering already does, of course. Doing the test against
 the per-block filter first doesn't seem to buy us much because with
 thousands of transactions per block, even a very tiny FP rate will still
 trigger a match on every single one.

 The second problem I see is that we can't do this in parallel because of the
 following edge case: wallet contains key K and someone sends it money using
 an OP_CHECKSIG output. The input which spends this output does not contain
 any predictable data, thus we do not know what to look for in the following
 blocks to detect a spend of it until we have seen the first transaction and
 know its hash.

 In practice this means we must either scan through the chain in sequence and
 update our matching criteria if we see such an output (this is what the
 Bloom filtering protocol already does server-side), or we must constrain the
 user such that output scripts always force repetition of predictable data -
 this is what mostly happens today due to pay-to-address outputs, but not
 always, and correctness is more important than completeness.

 If we can't do it in parallel then we must suffer a node round-trip for
 every single block we traverse, because we can't request long runs of blocks
 with a single command. That latency will kill performance dead. It's a non
 starter.

 But let's imagine we don't care about 

[Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Adam Back
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

http://eprint.iacr.org/2014/763.pdf

Mike had posted a detailed response on the topic on why its complex
and becomes bandwidth inefficient to improve it usefully.

https://groups.google.com/forum/#!msg/bitcoinj/Ys13qkTwcNg/9qxnhwnkeoIJ

The basic summary of which I think is that its not even intended to
provide any practical privacy protection, its just about compacting
the query for a set of addresses.

So I was wondering what about changing to committing a bloom filter of
the addresses in the block.  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.  (Someone appeared on
bitcoin wizards IRC a while back and made this observation.)

From there its a question of fetching the candidate TXOs.

Am I missing anything?

Adam

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Adam Back
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 block matches. But with reasonable FP
 rates every block will match at least a few transactions (this is already the
 case - the FP rate is low but high enough that we get back FPs on nearly
  every block). So you end up downloading every block?

I mean because the user is scanning he can binary search which set of
addresses from his wallet are possibly in the block and then request
the specific addresses and some will be false positives and some real,
but with the bloom commitment (and UTXO trie organised commitment) he
can verify that the positive hits are correct via the merkle path, and
that the false positives are not being wrongly withheld by obtaining
merkle path proof that they are not in the trie.

Adam

On 20 February 2015 at 16:54, Mike Hearn m...@plan99.net wrote:
 Hey Adam,


 Mike had posted a detailed response on the topic on why its complex
 and becomes bandwidth inefficient to improve it usefully.


 To clarify, we could improve privacy and still preserve usefully high
 performance, it's just a lot of complicated programming work. You need to
 find out from the OS how much bandwidth you have to play with, for example,
 and do all the very complex tracking to surf the wave and keep yourself in
 roughly the right place.

 The basic summary of which I think is that its not even intended to
 provide any practical privacy protection, its just about compacting
 the query for a set of addresses.


 The original intent of Bloom filtering was to allow both. We want our cake
 and we want to eat it.

 The protocol can still do that, with sufficiently smart clients. The problem
 is that being sufficiently smart in this regard has never come to the top of
 the TODO list - users are always complaining about other things, so those
 things are what gets priority.

 It's not IMO a protocol issue per se. It's a code complexity and manpower
 issue.


 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 block matches. But with reasonable FP rates
 every block will match at least a few transactions (this is already the case
 - the FP rate is low but high enough that we get back FPs on nearly every
 block). So you end up downloading every block? That won't work.

 Eventually, wallets need to stop doing linear scans of the entire block
 chain to find tx data. That worked fine when blocks were 10kb, it's still
 working OK even though we scaled through two orders of magnitude, but we can
 imagine that if we reach 10mb blocks then this whole approach will just be
 too slow.

 The main reason wallets are scanning the chain today (beyond lack of
 protocol support for querying the UTXO set by script), is that they want to
 show users time-ordered lists of transactions. Financial apps should show
 you payment histories, everyone knows this, and without knowing roughly when
 a tx happened and which inputs/outputs were mine, providing a useful
 rendering is hard. Even with this data the UI is pretty useless, but at
 least it's not actually missing.

 By combining Subspace and BIP70 we can finally replace the payments list UI
 with actual proper metadata that isn't extracted from the block chain, and
 at that point non-scanning architectures become a lot more deployable.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Adam Back
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 in it.

Now the user downloads the headers and bloom data for all blocks.  The
know the bloom data is correct in an SPV sense because of the
commitment.  They can scan it offline and locally by searching for
addresses from their wallet in it.  Not sure off hand what is the most
efficient strategy, probably its pretty fast locally anyway.

Now they know (modulo false positives) which addresses of theirs maybe
in the block.

So now they ask a full node for merkle paths + transactions for the
addresses from the UTXO set from the block(s) that it was found in.

Separately UTXO commitments could optionally be combined to improve
security in two ways:

- the normal SPV increase that you can also see that the transaction
is actually in the last blocks UTXO set.

- to avoid withholding by the full node, if the UTXO commitment is a
trie (sorted) they can expect a merkle path to lexically adjacent
nodes either side of where the claimed missing address would be as a
proof that there really are no transactions for that address in the
block.  (Distinguishing false positive from node withholding)

Adam

On 20 February 2015 at 17:43, Mike Hearn m...@plan99.net wrote:
 Ah, I see, I didn't catch that this scheme relies on UTXO commitments
 (presumably with Mark's PATRICIA tree system?).

 If you're doing a binary search over block contents then does that imply
 multiple protocol round trips per synced block? I'm still having trouble
 visualising how this works. Perhaps you could write down an example run for
 me.

 How does it interact with the need to download chains rather than individual
 transactions, and do so without round-tripping to the remote node for each
 block? Bloom filtering currently pulls down blocks in batches without much
 client/server interaction and that is useful for performance.

 Like I said, I'd rather just junk the whole notion of chain scanning and get
 to a point where clients are only syncing headers. If nodes were calculating
 a script-(outpoint, merkle branch) map in LevelDB and allowing range
 queries over it, then you could quickly pull down relevant UTXOs along with
 the paths that indicated they did at one point exist. Nodes can still
 withhold evidence that those outputs were spent, but the same is true today
 and in practice this doesn't seem to be an issue.

 The primary advantage of that approach is it does not require a change to
 the consensus rules. But there are lots of unanswered questions about how it
 interacts with HD lookahead and so on.


--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-14 Thread Adam Back
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 part, wallet, user to not use software
with consensus protocol rw-writes nor variants, you WILL lose money.

You could view bitcoin as a digital signature algorithm speculatively
tinkering with the algo is highly prone to binary failure mode and
unbounded funds loss.

Want to be clear this is not a political nor emotive issue. It is a
critical technical requirement for security if users of software people
write.

Please promote this meme.

Adam
On Feb 14, 2015 6:24 AM, Tamas Blummer ta...@bitsofproof.com wrote:

 Peter,

 You did not address me but libbitcoin. Since our story and your evaluation
 is probably similar, I chime in.

 On Feb 14, 2015, at 2:13 PM, Peter Todd p...@petertodd.org wrote:

 So stop wasting your time. Help get the consensus critical code out of
 Bitcoin Core and into a stand-alone libconsensus library,


 We have seen that the consensus critical code practically extends to
 Berkley DB limits or OpenSSL laxness, therefore
 it is inconceivable that a consensus library is not the same as Bitcoin
 Core, less its P2P service rules, wallet and RPC server.


 On Feb 14, 2015, at 2:13 PM, Peter Todd p...@petertodd.org wrote:


 Or you can be stereotypical programmers and dick around on github for
 the next ten years chasing stupid consensus bugs in code no-one uses.



 The Core code base is unfriendly to feature extensions because of its
 criticality, legacy design and ancient technology. It is also a commodity
 that the ecosystem takes for granted and free.

 I honestly admire the core team that works and progresses within these
 limits and perception.

 I am not willing to work within the core’s legacy technology limits. Does
 it mean I am dicking around? I think not.
 It was my way to go down the rabbit hole by re-digging it and I created
 successful commercial products on the way.

 It is entirely rational for me to focus on innovation that uses the core
 as a border router for this block chain.

 I am rather thankful for the ideas of the side chains, that enable
 innovation that is no longer measured on unapologetic compatibility with a
 given code base, but its services to end user.

 Tamas Blummer
 Bits of Proof



 --
 Dive into the World of Parallel Programming. The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Adam Back
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 network validate that the
value in the sig matches full nodes view of the tx value avoids that
issue.  Simple, elegant, but... we have no live beta mechanism, and
hence risk  testing makes that tricky.  Plus the full network upgrade
issue if its not backwards compatible.

Adam

On 23 January 2015 at 16:08, Tamas Blummer ta...@bitsofproof.com wrote:
 You mean an isolated signing device without memory right?

 An isolated node would still know the transactions substantiating its coins,
 why would it sign them away to fees ?

 Tamas Blummer

 On Jan 23, 2015, at 4:47 PM, slush sl...@centrum.cz wrote:

 Correct, plus the most likely scenario in such attack is that the malware
 even don't push such tx with excessive fees to the network, but send it
 directly to attacker's pool/miner.

 M.

 On Fri, Jan 23, 2015 at 4:42 PM, Alan Reiner etothe...@gmail.com wrote:

 Unfortunately, one major attack vector is someone isolating your node,
 getting you to sign away your whole wallet to fee, and then selling it to a
 mining pool to mine it before you can figure why your transactions aren't
 making it to the network.  In such an attack, the relay rules aren't
 relevant, and if the attacker can DoS you for 24 hours, it doesn't take a
 ton of mining power to make the attack extremely likely to succeed.




 On 01/23/2015 10:31 AM, Tamas Blummer wrote:

 Not a fix, but would reduce the financial risk, if nodes were not relaying
 excessive fee transactions.

 Tamas Blummer






 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Adam Back
Issues like that particular one (simple elegant fix, strong utility
justification) plus previously more privacy stuff (like committed tx,
homomorphic encrypted values) was what got me wondering about a way to
do a live beta (one-way peg) and then to get excited about the 2wp 
Greg's mechanism for that.

I think it would be hypothetically possible to make a special
singleton sidechain which is merge mined, and has a consensus rule to
require some proportion of reward be sent to it via coinbase tx (a
mechanism to address incentive incompatibility) and a general timeline
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 16:12, Adam Back a...@cypherspace.org wrote:
 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 network validate that the
 value in the sig matches full nodes view of the tx value avoids that
 issue.  Simple, elegant, but... we have no live beta mechanism, and
 hence risk  testing makes that tricky.  Plus the full network upgrade
 issue if its not backwards compatible.

 Adam

 On 23 January 2015 at 16:08, Tamas Blummer ta...@bitsofproof.com wrote:
 You mean an isolated signing device without memory right?

 An isolated node would still know the transactions substantiating its coins,
 why would it sign them away to fees ?

 Tamas Blummer

 On Jan 23, 2015, at 4:47 PM, slush sl...@centrum.cz wrote:

 Correct, plus the most likely scenario in such attack is that the malware
 even don't push such tx with excessive fees to the network, but send it
 directly to attacker's pool/miner.

 M.

 On Fri, Jan 23, 2015 at 4:42 PM, Alan Reiner etothe...@gmail.com wrote:

 Unfortunately, one major attack vector is someone isolating your node,
 getting you to sign away your whole wallet to fee, and then selling it to a
 mining pool to mine it before you can figure why your transactions aren't
 making it to the network.  In such an attack, the relay rules aren't
 relevant, and if the attacker can DoS you for 24 hours, it doesn't take a
 ton of mining power to make the attack extremely likely to succeed.




 On 01/23/2015 10:31 AM, Tamas Blummer wrote:

 Not a fix, but would reduce the financial risk, if nodes were not relaying
 excessive fee transactions.

 Tamas Blummer






 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles

2014-12-22 Thread Adam Back
(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 the candidate layer
properties that one could use as building blocks to construct a
decentralised PoW-chain assured immutable history based ecash system
as:

- time-stamping (really just time-ordered as network time is weak)

- namespace (first come first served name value pairs)

I thought it was interesting to look at potential minimum enabling
functionality in order to explore whether the consensus critical code
could be simplified for security, and also to understand the tradeoffs
towards seeing if there were any improvements that could be found.
(And it seems its pretty hard to find any improvements was my
conclusion).


Time-stamping (or time-ordering) at a requirements level does not have
to imply that there is a uniqueness guarantee, or even that the nodes
see what they are time-stamping (it could be committed with a random
nonce) and indeed hiding the committed data from the service and
public view is a common property of time-stamping.  Time-ordering just
creates an immutable (and not strongly deduplicated) stream of data
items that came from various users and had a time-ordering placed on
them.

Minimally the person who submitted the data item would need to know
the merkle path to it, and that might be achieved by publishing the
merkle tree, where some or all of the leaves are hidden commitments.

For bitcoin composability purposes you might require that there be no
hidden commitments, and then other miners and full nodes could
download all the merkle trees for each PoW-interval and ignore
duplicates.


Namespace service adds the uniqueness and first-come first-served
property up-front (as its more efficient for people catching up to not
have to download and discard duplicates/double-spends), and this more
strict rule requires miners to know about (and presumably index) all
previous information to avoid violating this rule. I assume name
attributes to hold information like a public key to approve changes in
ownership, an IP address, an email address etc.  For efficient proof
reasons there is still a merkle tree per PoW time-interval binding
names into a hash-chain.

For bitcoin re-described using a namespace the unique coins are the
names, and values and ownership public key etc are attributes of the
name; names (coins) are only added (via mining) or after deletion
(spend/transfer) of previous names.  Transfers are approved via
digital signature.

The additional property bitcoin requires is that the values add up.


I presume the phrase proof of publication means to draw out separately
that the full-node version of bitcoin requires a rule that miners
should not build on top of blocks unless they have copies of all data
committed to.  Otherwise a malicious party can hide ownership
transfers that can be revealed later, so that no one is assured of
ownership: any possibility for a gap in the ownership chain calls into
question ownership.  So from that perspective a miner consensus rule
that it should not build on top of blocks that it hasnt seen a full
gap-free history for makes the PoW chain a kind of proof that the
miner population at one time saw all data hashed into it.

I think you need one more thing which is that the miners (and other
full nodes who have copies of the data) are willing to share that
historic data with you.  There is some meta-incentive for bitcoin
holders to help others catchup and be assured of the history and
information has to be broadcast as there are many miners and
full-nodes.


I presume anti-relay term is meant at system level, rather than node
level, though technically bitcoin nodes in the current protocol
version dont relay double-spent transactions.  Particularly that
miners wont bless double-spent transactions (and will do PoW only over
non double-spent transfers).


While there does seem to be some confusion from some people perhaps
not realising that it is essential that there are no gaps in the
ownership chain, I am not sure there are necessarily any practical
implication of philosophical differences between proof of publication
 anti-relay (or namespace for that matter).  It is also important
that there is no way to attack the insertion logic so that eg someone
cant get a hash into an internal nor leaf node of the merkle tree
without the miners first seeing that data.

Presumably as they are all describing ways to think about bitcoin and
assuming no one is confused about how bitcoin works, the distinction
just comes down to what features are assumed to be naturally included
in the layer definition, and what features have to be added.  For
example I think its relatively normally assumed that people can look
up names.


I suppose it might be possible to put a 

Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles

2014-12-21 Thread Adam Back
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 AntiReplaySign() has been used once for a given pubkey
 it is impossible to re-run the primitive on a different message m'. This
 is of course impossible to implement with math alone, but we can
 implement it with a trusted third party.

Well while you cant prevent it you could render it insecure enabling
miners to take funds.

That could work via a one-show signature; normal ECDSA being address
a=H(Q), public key Q=dG, R=kG, r=R.x, s=(H(m)+rd)/k, signature (r,s),
verify: a=?H(Q) and sR=?H(m)G+rQ one-show being: a=H(Q,R), verify
being: a=?H(Q,R) and sR=?H(m)G+rQ.  Now that is unsafe to double-spend
by design as only that specific R is usable and as we know reusing R
with different messages leaks the private key because: s=(H(m)+rd)/k
and s'=(H(m')+rd)/k implies sk=H(m)+rd and s'k=H(m')+rd so
k=(H(m)-H(m'))/(s'-s), and d=(sk-H(m))/r.

Adam

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] one-show signatures (Re: The relationship between Proof-of-Publication and Anti-Replay Oracles)

2014-12-21 Thread Adam Back
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 do with math what you said was not possible where
you said This [preventing signing more than one message] is
impossible to implement with math alone.

Adam

On 21 December 2014 at 15:29, Peter Todd p...@petertodd.org
 There's no need to get into the specifics of crypto math so early; you
 can just as easily and only slightly less efficiently obtain the same
 result with a few extensions to the Bitcoin scripting system to verify
 ECDSA signatures directly.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Adam Back
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 and want that logic to extend to the extra features;
c) they are thinking out of band, but they think they are forced to
send the data there in order to achieve atomicity.

I think the data that is sent on the blockchain is design-compressed
minimal necessary to achieve transaction integrity, and its important
for scalability that we keep it that way.  About the rationales for
using that scarce scalability impacting channel:

a) convenience: is not a great reason to my mind. there are lots of
channels: email, web forms, point2point various transports NFC, TCP,
HTTP for payment protocol or extensions or new protocols.  I think
there could be a need for a reliable privacy preserving store and
forward decentralised infrastructure to act as a channel for such
purposes.  Until then email could be pretty convenient, if you dont
get the message due to spam filter etc ask them to resend.  Or a web
storage locker related to the app.

b) backup: the blockchain is not an efficient reliable generic backup
mechanism because its broadcast.  there are cheaper and relatively
simple ways to get end2end secure backup, the main challenge of which
is having secure keys and not forgetting them.  bitcoin already has
that covered as its a central requirement of blockchain security.  If
you want to archive your payment protocol receipts store them on some
cloud storage service or disk encrypted with related keys.  for
example tahoe-lafs is optimised for the decentralised long-term
storage kind of use.

c) atomicity. as an example application requiring atomicity that may
use op_return stealth addresses where if the stealth auxiliary message
was sent out of band, then if message is lost, and the sender didnt
keep it or cant be relied on to care, then the money could be
permanently lost to both parties.

It occurred to me recently the kind of use requiring atomicity as
stealth address in c) can be achieved by sending both the extra
message (the stealth packet) AND the signed bitcoin transaction over
the reliable store  forward (eg email for now).  Then the recipient
can do the calculations involving the auxiliary message and payment
message, and relay the message to the blockchain IFF they receive the
message (and chose to accept it).  If they dont receive the message
they can ask for it to be resent.  And if the payment is unclaimed the
sender still owns it and can double-spend to avoid risk of later
spending in their replacement message, or double-spend to self if the
recipient declines the payment.  This has privacy, efficiency and SPV
advantages over sending to the blockchain.

I think we could make a case that as a design principle auxiliary data
could do with a bitcoin-related but separate reliable store and
forward channel, as email has been sufficiently spammed to end up with
loss of reliability.  So I think a payment message transport would be
good here: invoices  receipts, and other things necessary for
applications, transaction disputes, records for normal p2p trades and
business functions reliable store and forward substrate with
decentralisation  privacy. For email the existing mechanism with
closest semantics, add-on privacy features exist: mixmaster,
nymservers, webmail + encryption, webmail over Tor etc for privacy
related uses.  Slow transports can offer better security than
interactive transports.

Adam

On 17 November 2014 10:35, Pieter Wuille pieter.wui...@gmail.com wrote:
 On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner etothe...@gmail.com wrote:

 On 11/16/2014 02:04 PM, Jorge Timón wrote:
 I remember people asking in #bitcoin-dev Does anyone know any use
 case for greater sizes OP_RETURNs? and me answering I do not know of
 any use cases that require bigger sizes.

 For reference, there was a brief time where I was irritated that the
 size had been reduced to 40 bytes, because I had an application where I
 wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
 need at least 64 bytes for that.   Unfortunately I can't remember now
 what that application was, so it's difficult for me to argue for it.
 But I don't think that's an unreasonable use case:  sending a payment
 with a signature, essentially all timestamped in the blockchain.

 You can still send the signature out of band (for example using the
 payment protocol), and just have the transaction commit to a hash of
 that signature (or message in general), either using an OP_RETURN
 output to store the hash, or using the pay-to-contract scheme that
 Jorge mentioned above. That has exactly the same timestamping
 properties.

 My main concern with OP_RETURN is that it seems to encourage people to
 use the blockchain as a convenient transport 

Re: [Bitcoin-development] death by halving

2014-10-25 Thread Adam Back
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 ongoing
(which depends on halving also), in that there are claims that the btc
price experiences some downwards pressure when margins are slim as
miners sell almost all of them when the electrical cost takes most of
the profit, and otherwise tend more to hold coins longer term.

- that people who cant make money mining with 1/2 reward will resort
to attacking the network rather than living with it for 2weeks until
difficulty adjustment).  actually it will be longer than two weeks if
its going to result in a difficulty fall.

- that the miners wont act in their own meta-interest to aim for the
plausible new hashrate supported by the lower reward.  mining
equipment investment horizon being 3-6mo+ so it can easily make
economic sense to subsidise it for a bit to smooth the transition.

- fees might go up to unjam the network also, so the people
benefitting from the transactions utility also help cover the
transition costs.  or maybe someone makes an assurance contract to pay
the short fall and phase it out over a few months to smooth the shift.

- there is a wide range of electrical efficiency, and some are much
worse than others so there maybe a convenient equilibrium where there
are enough left who can still profit.

- alternatively you might say why not 1/100th reward reduction per 2
week period rather than 1/2 every 4 years, a difficulty retarget could
be a convenient point to do that.

Adam

On 25 October 2014 11:06, Alex Mizrahi alex.mizr...@gmail.com wrote:
 # Death by halving

 ## Summary

 If miner's income margin are less than 50% (which is a healthy situation
 when mining hardware is readily available), we might experience catastrophic
 loss of hashpower (and, more importantly, catastrophic loss of security)
 after reward halving.

 ## A simple model

 Let's define miner's income margin as `MIM = (R-C_e)/R`, where R is the
 total revenue miner receives over a period of time, and C_e is the cost of
 electricity spent on mining over the same period of time. (Note that for the
 sake of simplicity we do not take into account equipment costs, amortization
 and other costs mining might incur.)

 Also we will assume that transaction fees collected by miner are negligible
 as compared to the subsidy.

 Theorem 1. If for a certain miner MIM is less than 0.5 before subsidy
 halving and bitcoin and electricity prices stay the same, then mining is no
 longer profitable after the halving.

 Indeed, suppose the revenue after the halving is R' = R/2.
MIM = (R-C_e)/R  0.5
R/2  C_e.

R' = R/2  C_e.

 If revenue after halving R' doesn't cover electricity cost, a rational miner
 should stop mining, as it's cheaper to acquire bitcoins from the market.

 ~~~

 Under these assumptions, if the majority of miners have MIM less than 0.5,
 Bitcoin is going to experience a significant loss of hashing power.
 But are these assumptions reasonable? We need a study a more complex model
 which takes into account changes in bitcoin price and difficulty changes
 over time.
 But, first, let's analyze significance of 'loss of hashpower'.

 ## Catastrophic loss of hashpower

 Bitcoin security model relies on assumption that a malicious actor cannot
 acquire more than 50% of network's current hashpower.
 E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Based Double
 Spending_ paper which shows that as long as the malicious actor controls
 only a small fraction of total hashpower, attacks have well-define costs.
 But if the attacker-controlled hashrate is higher than 50%, attacks become
 virtually costless, as the attacker receives double-spending revenue on top
 of his mining revenue, and his risk is close to zero.

 Note that the simple model described in the aforementioned paper doesn't
 take into account attack's effect on the bitcoin price and the price of the
 Bitcoin mining equipment. I hope that one day we'll see more elaborate
 attack models, but in the meantime, we'll have to resort to hand-waving.

 Consider a situation where almost all available hashpower is available for a
 lease to the highest bidder on the open market. In this case someone who
 owns sufficient capital could easily pull off an attack.

 But why is hashpower not available on the market? Quite likely equipment
 owners are aware of the fact that such an attack would make Bitcoin useless,
 and thus worthless, which would also make their equipment worthless. Thus
 they prefer to do mining for a known mining pools with good track record.
 (Although hashpower marketplaces exist: https://nicehash.com/ they aren't
 particularly popular.)

 Now let's consider a situation where mining bitcoins is no longer profitable
 and the majority of hashpower 

Re: [Bitcoin-development] side-chains 2-way pegging (Re: is there a way to do bitcoin-staging?)

2014-10-22 Thread Adam Back
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 an update on 1-way pegging (aka bitcoin staging, explained in quoted text
 at bottom): it turns out secure 2-way pegging is also possible (with some
 bitcoin change to help support it).  The interesting thing is this allows
 interoperability in terms of being able to move bitcoin into and out of a
 side chain.  The side chains may have some different parameters, or
 experimental things people might want to come up with (subject to some
 minimum compatibility at the level of being able to produce an SPV proof of
 a given form).

 At the time of the 1-way peg discussion I considered 2-way peg as desirable
 and it seemed plausible with bitcoin changes, but the motivation for 1-way
 peg was to make it less risky to make changes on bitcoin, so that seemed
 like a catch-22 loop.  Also in the 2-way peg thought experiment I had not
 realized how simple it was to still impose a security firewall in the 2-way
 peg also.


 So Greg Maxwell proposed in Dec last year a practically compact way to do
 2-way pegging using SPV proofs.  And also provided a simple argument of how
 this can provide a security firewall.  (Security firewall means the impact
 of security bugs on the side-chain is limited to the people with coins in
 it; bitcoin holders who did not use it are unaffected). [1]

 How it works:

 1. to maintain the 21m coins promise, you start a side-chain with no
 in-chain mining subsidy, all bitcoin creation happens on bitcoin chain (as
 with 1-way peg).  Reach a reasonable hash rate.  (Other semantics than 1:1
 peg should be possible, but this is the base case).

 2. you move coins to the side-chain by spending them to a fancy script,
 which suspends them, and allows them to be reanimated by the production of
 an SPV proof of burn on the side-chain.

 3. the side-chain has no mining reward, but it allows you to mint coins at
 no mining cost by providing an SPV proof that the coin has been suspended as
 in 2 on bitcoin.  The SPV proof must be buried significantly before being
 used to reduce risk of reorganization.  The side-chain is an SPV client to
 the bitcoin network, and so maintains a view of the bitcoin hash chain (but
 not the block data).

 4. the bitcoin chain is firewalled from security bugs on the side chain,
 because bitcoin imposes the rule that no more coins can be reanimated than
 are currently suspend (with respect to a given chain).

 5. to simplify what they hypothetical bitcoin change would need to consider
 and understand, after a coin is reanimated there is a maturity period
 imposed (say same as fresh mined coins).  During the maturity period the
 reanimation script allows a fraud proof to spend the coins back.  A fraud
 bounty fee (equal to the reanimate fee) can be offered by the mover to
 incentivize side-chain full nodes to watch reanimations and search for fraud
 proofs.

 6. a fraud proof is an SPV proof with a longer chain showing that the proof
 of burn was orphaned.

 There are a few options to compress the SPV proof, via Fiat-Shamir transform
 to provide a compact proof of amount work contained in a merkle tree of
 proofs of work (as proposed by Fabien Coelho link on
 http://hashcash.org/papers/) with params like 90% of work is proven.  But
 better is something Greg proposed based on skip-lists organized in a tree,
 where 'lucky' proofs of work are used to skip back further.  (Recalling that
 if you search for a 64-bit leading-0 proof-of-work, half the time you get a
 65-bit, quarter 66-bit etc.)  With this mechanism you can accurately
 prove the amount of proof of work in a compressed tree (rather than ~90%).


 Apart from pegging from bitcoin to a side-chain, if a private chain is made
 with same rules to the side-chain it becomes possible with some
 modifications to the above algorithm to peg the side-chain to a private
 chain.  Private chain meaning a chain with the same format but signature of
 single server in place of hashing, and timestamping of the block signatures
 in the mined side chain.  And then reactive security on top of that by full
 nodes/auditors trying to find fraud proofs (rewrites of history relative to
 side-chain mined time-stamp or approved double-spends).  The reaction is to
 publish a fraud proof and move coins back to the side chain, and then
 regroup on a new server.  (Open transactions has this audit + reactive model
 but as far as I know does it via escrow, eg the voting pools for k of n
 escrow of the assets on the private server.) I also proposed the same
 reactive audit model but for auditable namespaces [4].

 Private chains add some possiblity for higher scaling, while retaining
 bitcoin security properties.  (You need to add the ability for a user

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Adam Back
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 associated with a
gmail account.  Quite frustrating.

On 15 October 2014 16:46, Mike Hearn m...@plan99.net wrote:
 Great idea. Jeff Garzik was looking for a better mailing list solution
 than SourceForge, but assuming
 there isn't a clearly better solution I think we should create a
 strictly moderated bitcoin-bips@lists.sourceforge list.


 Let's stay away from SF.net or any mailman-controlled lists if at all
 possible. They break DKIM signatures which means they're no longer
 compatible with Yahoo, all mail from Yahoo users gets spamfoldered
 immediately. Google Groups gets this right. Perhaps other list operators do
 too. Groups also has moderation features.

 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-09 Thread Adam Back
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.

When I tried building things that need nlocktime I found it quite
inconvenient that it was wasnt a function rather than a script
property, so I like this proposal.

Adam

On 9 October 2014 04:13, Alan Reiner etothe...@gmail.com wrote:
 By the way, I really like this proposal.  I haven't spent much time thinking
 about the deeper subtleties and risks associated with it, but I see a lot of
 opportunities.  One just came to mind that I didn't see mentioned in his
 original proposal:

 Non-Interactive Recurring payments with ID-association:
 You want to make N recurring payments of 1 BTC each month to a service.
 Sign N transactions each of them use a CHECKLOCKTIMEVERIFY block number
 approximately X months in the future (one for each month).   The script
 allows the customer to move the coins at any time, but after the locktime
 the merchant/service has signing access.  The merchant software will
 continually watch for and sweep all coins that become available via this
 mechanism and credit the appropriate customer account.  The customer
 maintains control of the funds until payment time, the merchant can
 automatically collect it each month without requiring user interaction, and
 the customer can cancel it just by spending it elsewhere before the
 locktime.

 This scheme has an added benefit:  both the merchant's address and the
 user's address is in the script.  Given an appropriate scheme for linking
 addresses to accounts (perhaps sending the service a watch-only BIP32
 branch), the service can use the other address in the script to recognize
 and link that payment to the user's account.  This allows you to continue
 paying and extending your subscription without having to explicitly link
 each payment to the account.  The wallet will simply make sure to use a
 return address that is in a BIP32 branch that was provided to the service
 during signup, and the service will automatically extend your subscription
 every month based on that info when it sweeps payments.

 Along with everything else that was mentioned by Peter in his original
 proposal, I see OP_CHECKLOCKTIMEVERIFY as an enabling feature, not just a
 simple improvement.

 -Alan



 On 10/08/2014 06:26 AM, Wladimir wrote:

 On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn m...@plan99.net wrote:

 That is easy to change; I'll submit a pull request.

 That's certainly a useful improvement. It won't help the existing userbase
 though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release.

 The next minor release (0.9.4) could have Gavin's change already.

 I don't think CHECKLOCKTIMEVERIFY will make it into the next major
 release though. Once headers-first and pruning is merged (which is
 expected to be a matter of weeks). I'd like to split off the 0.10
 branch and give it some time to stabilize with a feature freeze, then
 do a release before the end of the year.

 So 0.11, in say 6 months, would be soonest.

 Wladimir

 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___

[Bitcoin-development] good bitcoin summary paper in more detail than Satoshi paper (Re: Bitcoin Protocol Specification)

2014-05-20 Thread Adam Back
Actually I read the paper now as it was linked somewhere else also, and its
quite good.  So now I can summarize it:

Its a writeup of bitcoin in 29 pages, which covers things in the original
bitcoin paper but with more detail of formats, scripts with some examples,
formats etc.  Quite nice paper, 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 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 ask, those of you that have a bit of spare time, to
take a look at a Bitcoin protocol specification I've written. It is still
in development and, as some of you have already indicated, needs
improvement. I'd be very thankful if some of you could take the
time to review it. If there are any errors or suggestions from your
side, I'd gladly hear them. My e-mail can be found on the front page
of the document:

http://enetium.com/resources/Bitcoin.pdf

Warm greetings,
Chris


--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] patents...

2014-05-19 Thread Adam Back
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 defensive
pool?

I imagine a number of other bitcoin companies have patented things, but if
you think ahead a little bit, or look at prior ecash history, patents held
by individuals or companies can be outright dangerous.  

We saw this in the past eg the digicash patents after the company went
bankrupt were sold by the investor to some random large company that parked
it in its huge pile of patents, didnt use it, and prevented anyone else from
using it - stalling Chaum dependent payment innovation for perhaps 5 years
until the thing expired, and a Chaum patent expiry party was held.

Just some food for thought.

hmm Yes and this topic now is more than a bit non dev related.  Sorry about
that.  There seems to be no convenient mailing list format for non-dev stuff
or I would Cc and set Reply-To for example?  (Web forums somewhat suck IMO). 

Adam

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Protocol Specification

2014-05-18 Thread Adam Back
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 ask, those of you that have a bit of spare time, to
take a look at a Bitcoin protocol specification I've written. It is still
in development and, as some of you have already indicated, needs
improvement. I'd be very thankful if some of you could take the
time to review it. If there are any errors or suggestions from your
side, I'd gladly hear them. My e-mail can be found on the front page
of the document:

http://enetium.com/resources/Bitcoin.pdf

Warm greetings,
Chris


--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] mid-term bitcoin security (Re: Warning message when running wallet in Windows XP (or drop support?))

2014-04-16 Thread Adam Back
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 address-substitution via untrusted network/user
and weak site with 1mil lines of swiss-cheese security app-store.  So some
kind of address authentication TOFU.  Aside from X509 bloatware which could
be extended from payment protocol to do that, I'd argue for a native simple
TOFU format like Alan Reiner's multiplier * base approach (where base is the
TOFU handle).  And/or something like the IBE address proposal (which gives a
bandwidth efficiently SPV queryable way to check if funds received).  Worst
case if weil-pairing gets broken it auto-devolves to the current status
quo.

Btw not to reignite the stealth vs reusable address bike shedding, but
contrarily I was thinking it maybe actually better to try to rebrand address
as invoice number.  People understand double paying an invoice is not a
good idea.  And if they receive the same invoice twice they'll query it.

Adam

On Wed, Apr 16, 2014 at 11:41:48AM +0200, Wladimir wrote:
   On Wed, Apr 16, 2014 at 10:45 AM, Melvin Carvalho
   [1]melvincarva...@gmail.com wrote:

   XP with a trezor would work fine tho?

   Probably - but that's a very rare edge case. People that are security
   conscious enough to buy a Trezor will not run XP. Also I don't dare to
   say that there is not some way to sociaal-engineer the user with
   malware on a compromised OS even with a trezor.
   Maybe: for 0.9.2 add a warning message and push people to upgrade
   (either to Win8.1 or something else), then in the next major release
   0.10.0 drop XP support completely.
   Wladimir

References

   1. mailto:melvincarva...@gmail.com

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech

___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)

2014-04-16 Thread Adam Back
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
phishing, watering holes, malware and the average windows computer is
probably compromised a dozen times over.  Apparently for sometime it was not
easily possible to secure it install boot - install OS, connect to network
to download security updates, IP range scanned and compromised faster than
you can patch it.

Adam

On Wed, Apr 16, 2014 at 05:28:27PM +0200, Wladimir wrote:
   On Wed, Apr 16, 2014 at 5:20 PM, Pieter Wuille
   [1]pieter.wui...@gmail.com wrote:

   On Wed, Apr 16, 2014 at 5:12 PM, Kevin [2]kevinsisco61...@gmail.com
   wrote:
I think we should get to the bottom of this. Â Should we assume that
   xp is
not secure enough?

 Yes.

   It will quickly grow extremely insecure.
   People will be actively analyzing patches to post-XP versions to find
   security problems that are patched there, to see if they can be
   exploited on XP.
   Wladimir

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-21 Thread Adam Back
Maybe its time to explore raw ECDSA signed message based certs.

btw I dont think its quite 4kB.  eg bitpay's looks to be about 1.5kB in der
format.  And they contain a 2048-bit RSA server key, and 2048-bit RSA
signatures (256byte each right there = 512bytes).  And even 2048 is weaker
than 256-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 scan (ZXing scanner, 3 years ago). You will want to stay below 500
bytes for convenient scanning. That said, I'm convinced there is a lot
of room for scanning improvements.

 How much of the payment protocol message size comes from use of x509?

As said in the OP, a minimal PR uses 50 bytes. X.509 seems to put about
4000 bytes on top of that.

As you can see, we have quite some room for improvements to PR payload
(PaymentDetails). X.509 certification will probably not be possible via
QR, at least not until specialized CA's will issue space-efficient certs
(using ECDSA?).

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-21 Thread Adam Back
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,
   has been telling CA's that they need to pay mad bux for the Certicom
   ECC patents. So that's another reason why most certs are still using
   RSA.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] 2-way pegging (Re: is there a way to do bitcoin-staging?)

2014-03-16 Thread Adam Back
 Freidenbach, Luke Dashjr. 
The 2-way peg seems to have first been described by Greg.  Greg thought of
2-way pegging in the context of ZK-SNARKS and the coinwitness thread [2]. 
(As a ZK-SNARK could compactly prove full validation of a side chain rules).

There was also something seemingly similar sounding but not described in
detail by Alex Mizrahi in the context of color coins in this post [3].

Adam

[1] http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt
[2] https://bitcointalk.org/index.php?topic=277389.40
[3] https://bitcointalk.org/index.php?topic=277389.msg4167554#msg4167554
[4] http://www.cypherspace.org/p2p/auditable-namespace.html

On Mon, Oct 14, 2013 at 08:08: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.

Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin 0.x
stable and leap-frogs as beta becomes stable after testing.

Its a live beta, meaning real value, real contracts.  But we dont want it to
be an alt-coin with a floating value exactly, we want it to be bitcoin, but
the bleeding edge bitcoin so we want to respect the 21 million coin limit,
and allow coins to move between bitcoin and betacoin with some necessary
security related restrictions.

There is no mining reward on the betacoin network (can be merge mined for
security), and the way you opt to move a bitcoin into the betacoin network
is to mark it as transferred in some UTXO recognized way.  It cant be
reanimated, its dead.  (eg spend to a specific recognized invalid address on
the bitcoin network).  In this way its not really a destruction, but a move,
moving the coin from bitcoin to betacoin network.

This respects the 21 million coin cap, and avoids betacoin bugs flowing back
and affecting bitcoin security or value-store properties.  Users may buy or
swap betacoin for bitcoin to facilitate moving money back from betacoin to
bitcoin.  However that is market priced so the bitcoin network is security
insulated from beta.  A significant security bug in beta would cause a
market freeze, until it is rectified.

The cost of a betacoin is capped at one BTC because no one will pay more
than one bitcoin for a betacoin because they could alternatively move their
own coin.  The reverse is market priced.

Once bitcoin beta stabalizes, eg say year or two type of time-frame, a
decision is reached to promote 1.0 beta to 2.0 stable, the remaining
bitcoins can be moved, and the old network switched off, with mining past a
flag day moving to the betacoin.

During the beta period betacoin is NOT an alpha, people can rely on it and
use it in anger for real value transactions.  eg if it enables more script
features, or coin coloring, scalabity tweaks etc people can use it. 
Probably for large value store they are always going to prefer
bitcoin-stable, but applications that need the coloring features, or
advanced scripting etc can go ahead and beta.

Bitcoin-stable may pull validated changes and merge them, as a way to pull
in any features needed in the shorter term and benefit from the betacoin
validation.  (Testing isnt as much validation as real-money at stake
survivability).

The arguments are I think that:

- it allows faster development allowing bitcoin to progress features faster,

- it avoids mindshare dilution if alternatively an alt-coin with a hit
  missing feature takes off;

- it concentrates such useful-feature alt activities into one OPEN source
  and OPEN control foundation mediated area (rather than suspected land
  grabs on colored fees or such like bitcoin respun as a business model
  things),

- maybe gets the developers that would've been working on their pet
  alt-coin, or their startup alt-coin to work together putting more
  developers, testers and resources onto something with open control (open
  source does not necessarily mean that much) and bitcoin mindshare
  branding, its STILL bitcoin, its just the beta network.

- it respects the 21 million limit, starting new mining races probably
  dillutes the artificial scarcity semantic

- while insulating bitcoin from betacoin security defects (I dont mean
  betacoin as a testnet, it should have prudent rigorous testing like
  bitcoin, just the very act of adding a feature creates risk that bitcoin
  stable can be hesitant to take).

Probably the main issue as always is more (trustable) very high caliber
testers and developers.  Maybe if the alt-coin minded startups and
developers donate their time to bitcoin-beta (or bitcoin-stable) for the
bits they are missing, we'll get more hands to work on something of reusable
value to humanity, in parallel with their startup's objectives and as a way
for them to get their needed features, while giving back to the bitcoin
community, and helping bitcoin progress faster.

Maybe bitcoin

Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)

2014-03-08 Thread Adam Back
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 (secure)
direct multiparty signature quite difficult.

ps probably only 1 party needs to hash their key

P=aG  
H(P) -

- Q=bG

   P -

Adam

On Sat, Mar 08, 2014 at 12:37:30PM +0200, Joel Kaartinen wrote:
   If both parties insist on seeing a hash of the other party's public key
   before they'll show their own public key, they can be sure that the
   public key is not chosen based on the public key they themselves
   presented.

--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses)

2014-02-02 Thread Adam Back
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 tunable
amount of false positives.  You already have privacy becaue the query is
only revealed to the semi-trusted full node, and its query scope is limited
to one or a chosen batch of blocks.  But you can if desired add additional
ambiguity as Peter described by reducing the number of bits of 0 in the
decrypted block.  There is no need for matching a specific prefix as its
already a recipient specific calculation.  (It means the actual encrypted
value where it is chosen would have to mimic false positives: random with
n-bits of trailing 0s and expected probability distribution).

It should be compatible for combining with sharding or public prefixes, as
Peter mentioned but for short public prefixes those still has some (reduced)
blockchain ledger logged possibility to reduce anonymity set when combined
with flow analysis.

Maybe you could vary a public prefix per block.  Eg the public prefix for a
given user is the LSBits of the per block IBE derived pubic key for a given
user.  I am not sure if that helps or hinders.  Maybe it hurts anonymity set
because the analyst (Eve) is given multiple chances over time to exclude an
analysed flow candidate.

It would desirable to find a non-IBE way to do this.  (And more
computationally efficient / precomputable / indexable)

Or you could use different address types depending on the circumstance:
one-use, stealth, or IBE.  Kind of difficult to automate that (to know what
the user is planning to do with it) and avoid user confusion.  Clearly users
are quite confused and the convenient and understandable thing is to have a
(safely) reusable address.

Adam

On Sun, Feb 02, 2014 at 07:26:10AM -0500, Peter Todd wrote:
On Sun, Feb 02, 2014 at 01:16:20AM -0800, Jeremy Spilman wrote:
 
 Consequently you can now securely and very network/space efficiently
 securely delegate searching a block by computing the private key for the
 IBE pub key that any sender would use for that block, and sending it as
 a query to a random (or node-capture defended random selected node).
 The node can decrypt the encrypted bloom baits with it, but remains
 powerless to correlate with bloom baits to other payments received by
 the same user in bother blocks.
 

 I'm not sure I've fully wrapped my head around it.

   d/Q- Identity key
   E  - Generate an epoch-pubkey: E = Q * H1(epoch)
   r/P- Ephemeral privkey/pubkey, or discoverable from inputs
   S = r * K  - Shared secret (ECDE)

There needs to be two separate payor pubkeys, which I called elsewhere
the Filter and Recover pubkeys - the latter I think corresponds to
what you meant by identity key. From those two pubkeys two separate
shared secrets are derived.

The key idea is that you can encrypt a short string of zeros with the
Filter pubkey using ECDH and place the resulting filter bait in the
transaction. This lets the payor give the secret key corresponding to
that pubkey to a semi-trusted third party. That third party can then
trial decrypt all filter bait seen in transactions in the blockchain,
and every time the decrypted string has a sufficient number of zeros
it's considered a filter pass and the transaction is given to the payor.
For n zero bits one in 2^n transactions will match at random, which sets
your false positive rate.

Basically think of it as a way to outsource the work required for
zero-prefix stealth addresses, but with (less) of a sacrifice of
anonymity compared to just giving the third-party your recovery pubkey.
Identity-based encryption only comes into it because it's nice to be
able to further limit what transactions the server knows about to
specific time intervals rather than forver into the future.

Interestingly both schemes can be used at once - a short public prefix
combined with a second private filter. What's interesting there is that
the public prefix can do a first-pass filtering, with the second private
filter relatively long but still providing plausible deniability - you
can always claim 100% of the matching transactions were false positives
because you didn't receive any funds!

 The full node then uses this privkey to decrypt the same byte in all
 the transactions in that epoch/block which match the expected
 layout/template, e.g. given a certain length OP_RETURN, pull the
 specific byte and decrypt.

 This decrypted byte is then in turn used as bloom bait which may or
 may not cause the transaction to be sent back to the SPV client.

There's no bloom filters involved; as I said before bloom bait is a
misleading name. Filter bait is a better term given it's a generic
concept.

 What encryption scheme is being used here?

XOR with the ECDH-calculated nonce is fine. (run the nonce 

[Bitcoin-development] (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses)

2014-01-25 Thread Adam Back
I think I figured out a proof of existance for a space efficient way to do
better than bloom filters/prefix/bloom-bait.  (Must have been dreaming on it
as I woke up with the idea following Peter's suggestion to try prove instead
if its possible or not:).

I wrote up the details here:

https://bitcointalk.org/index.php?topic=431756.new

In summary with a use of novel application of IBE (*) based on weil-pairing
so the recipient can send a delegation private key that is specific to the
block being queried.  It means the node that services the query has no
ability to correlate with queries in other blocks from the some user.  The
sender derives a pub=IBE-extract(master-pub, id=previous block hash).  The
above link has more explanation, links and costs/risks.

I think it maybe within possibility to do further than this because it is
not technically necessary to delegate decryption, only to delegate
filtering, which can be a simpler requirement so there remains perhaps
(speculatively) a possibility to do it without introducing weil pairing
hardness problem or using eg I mentioned public key steganography or
something like that if there is anything similarly efficient but with 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 clearly a very nice win if reusable addresses could
 be made SPV-like in network characteristics and privacy, but we dont have
 a plausible mechanism yet IMO.  [...]

 If we can find some efficient crypto to solve that last one, we could even
 adopt them generally if it was efficient enough without needing interactive
 one-use address release.

Conversely, it'd be interesting if someone can dig up a proof showing
that doing much better than Gregory's ambiguity tradeoff is impossible.


--
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] Bait for reusable addresses

2014-01-24 Thread Adam Back
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 effective than it has been.

So SPV can be tuned as Mike just said, and as Greg pointed out somewhere
bloom is more private than prefix because its a wallet to node connection,
not a node broadcast, and Mike mentioned embedded Tor in another post to
boost node-capture issues with hostile network.

So reusable addresses are cool for full node recipients (0-bit prefix) or
trusted server offload (your own desktop, VPS, or trusted service provider
node, and solve real problems for the use case of static and donation
addresses particularly with this second delegatable key for no-funds at risk
search (which is even good as Jeremey said for your own node, in a offline
wallet use case).

Now while it would be clearly a very nice win if reusable addresses could be
made SPV-like in network characteristics and privacy, but we dont have a
plausible mechanism yet IMO.  Close as we got was Greg's enhancement of
my/your bloom bait/prefix concept to make multiple candidate baits to
provide some ambiguity (still allows elimination, just slightly less of it).

If we can find some efficient crypto to solve that last one, we could even
adopt them generally if it was efficient enough without needing interactive
one-use address release.

Maybe we should ask some math/theoretical crypto people if there is anything
like public key watermarking or something that could solve this problem
efficiently.

For the related but different case of transaction level authenticity I like
Alan's server derived but communicated scalar  base to allow the client to
do at least TOFU.

Payment protocol may add another level of identity framework on top of TOFU
addresses (at a lower level than the payment messages defined now), and
without then needing a batch upload of offline signed secondary address
sigature that Mike described a while back, at least in person, maybe online
somewhere (an add on with similar purpose and effect to Alan's TOFU, but
then with revocation, identity and certification for merchants).

I have not talked about payment protocols main app level function I think we
all understand and agree on the purpose and use of the server and optional
client certs in that.  People may wish to add other cert types later (eg
PGP, SSH etc) but this version covers the common merchant tech, and allows
client-side certs to be experimented with for identity also (eg imagine as a
way to enrol with regulated entities like exchanges.)

Tell me if I am misunderstanding anything :)

Adam

On Fri, Jan 24, 2014 at 12:26:19PM +, Mike Hearn wrote:
 brittleness. The real world experience is that users, or to be exact
 wallet authors, turn down SPV privacy parameters until bloom filters
 have almost no privacy in exchange for little bandwidth usage.

   That's not fundamental though, it just reflects that the only
   implementation of this is used on a wide range of devices and doesn't
   yet have any notion of bandwidth modes or monitoring. It can and will
   be resolved at some point.Â

--
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] BIP0039: Final call

2014-01-20 Thread Adam Back
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 brute force eg H(mnemonic||1) mod 2^k == 0 where k is
the amount of check digit redundancy.  But that might be expensive for a
trezor if k is very big at all.  And then key = H(mnemonic).

Adam

On Mon, Jan 20, 2014 at 05:35:02PM -0500, Peter Todd wrote:
On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
 On Mon, Jan 20, 2014 at 11:42 AM, slush sl...@centrum.cz wrote:

  Hi all,
 
  during recent months we've reconsidered all comments which we received
  from the community about our BIP39 proposal and we tried to meet all
  requirements for such standard. Specifically the proposal now doesn't
  require any specific wordlist, so every client can use its very own list of
  preferred words. Generated mnemonic can be then applied to any other
  BIP39-compatible client. Please follow current draft at
  https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.

 So, because the [mnemonic]-[bip32 root] is just hashing, you've
 effectively made your mnemonic sentence into a brainwallet? Since every
 mnemonic sentence can now lead to a bip32 root, and only the client that
 created the mnemonic can verify the mnemonic passes its checksum (assuming
 all clients use different wordlists, the only client that can help you if
 you fat-finger the sentence is the client that created it)?

That issue is more than enough to get a NACK from me on making the
current BIP39 draft a standard - I can easily see that leading to users
losing a lot of money.

Have any wallets implemented BIP39 this way already in released code?

-- 
'peter'[:-1]@petertodd.org
9c3092c0b245722363df8b29cfbb86368f4f7303e655983a



--
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] Payment protocol and reliable Payment messages

2014-01-14 Thread Adam Back
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 is 10% more after the user has already partly committed to the
purchase.  Ryanair, an airline near and dear to Europeans ;) is infamous for
aggressive use of such tactics.  Or worse systematic abuse of sorry that
was a pricing mistake.

In trading situations its even more important, you're facing a dynamic
price, and revocable bids after acceptance but before payment allow system
gaming.  There were court cases about such things and trading systems gamed. 
So I think this is the use case to consider.  Payment request is an offer,
payment message is an acceptance, transaction broadcast is settlment.  After
acceptance the asker must not be allowed to retract ther ask.

Going back to Pieter's comment it seems there are two approaches: i) send
payment message to merchant, merchant broadcasts tx to network to claim
funds; ii) user broadcasts tx, and sends payment message to merchant.

In case i) the user is relying on the merchant in terms of retraction, for
many use-cases that doesnt matter, or consumer law says they can do that in
some places.  Though transferable proof the merchant is systematically
retracting advertised offers could be indirectly useful as it maybe evidence
of unfair trading, which can result in censure for the merchant!

In case ii) I think Andreas has a point.  Maybe the way to do that is to
also bind the transaction to the payment message.  Eg include the hash of
the payment message in the tx (circular ref may have to use multisig
approach?), or as Timo Hanke's paper where the offer/acceptance contact hash
is bound to the address (ie the address paid is Q'=H(Q+H(contract)G).

Adam

On Tue, Jan 14, 2014 at 11:45:59AM +0100, Mike Hearn wrote:
 Imagine you get a good offer (payment request) from a merchant. You
 would like to accept that offer, however the merchant has changed
 his
 mind.

   Usually if the merchant has not delivered, then at that point it's not
   a problem and he is allowed to change his mind. It's only if they
   change their mind *after* you pay that it's a problem, right?

--
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-14 Thread Adam Back
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


--
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] Dedicated server for bitcoin.org, your thoughts?

2014-01-03 Thread Adam Back
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 funds.  I dont think its such a difficult question.  Ask your
more technical friends to confirm this hash is correct.

Its interesting that hashes are more trustworthy than signatures, since all
the NSLs and backdoors, its hard to trust a signature.

I have the same problem with linux distros that want to install hundreds of
components downloaded over the internet, based on signatures.  I would far
rather a merkle hash of the distribution at that point in time, which
authenticates directly any of the optional downloadable components.

(Or better yet a distro that like comes on a CD and doesnt download
anything...  Amazing how most CD and even DVD iso images immediately
download stupid things like fonts???  What were they thinking?  I downloaded
fedora  4GB of stuff and they need to download a font just to get past step
2 of the installer?  Thats a sensless, retrograde, selective backdoor
opportunity.)

Adam

On Fri, Jan 03, 2014 at 11:22:35AM +, Tier Nolan wrote:
   On Fri, Jan 3, 2014 at 9:59 AM, Drak [1]d...@zikula.org wrote:

   Which is why, as pointed out several times at 30c3 by several renowned
   figures, why cryptography has remained squarely outside of mainstream
   use. It needs to just work and until you can trust the connection and
   what the end point sends you, automatically, it's a big fail and the
   attack vectors are many.
   sarcasmI can just see my mother or grandma manually checking the hash
   of a download... /sarcasm

   Maybe a simple compromise would be to add a secure downloader to the
   bitcoin client.
   The download link could point to a meta-data file that has info on the
   download.
   file_url=
   hash_url=
   sig_url=
   message=This is version x.y.z of the bitcoin client
   It still suffers from the root CA problem though.  The bitcoin client
   would accept Gavin's signature or a core team signature.
   At least it would provide forward security.
   It could also be used to download files for different projects, with
   explicit warnings that you are adding a new trusted key.
   When you try to download, you would be given a window
   Project: Some Alternative Wallet
   Signed by: P. Lead
   Message:
   Confirm download Yes No
   However, even if you do that, each trusted key is only linked to a
   particular project.
   It would say if the project and/or leader is unknown.

References

   1. mailto:d...@zikula.org

--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk

___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] An idea for alternative payment scheme

2014-01-03 Thread Adam Back
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 to see if its one he can compute the private key
for.  Or the sender has to send the recipient out of band the derivation
key.

However at present most of the bitcoin infrastructure is using the bitcoin
broadcast channel as the communication channel, which also supports payer
and payee not being simultaneously online.  You have to be careful also not
to lose the key.  You dont want a subsequent payer data loss event to lose
money for the recipient.  You want the message to be sent atomically.

It does seem like a very attractive proposition to be able to fix the
address reuse issue.  Admonishment to not reuse addresses doesnt seem to
have been successful so far, and there are multiple widely used wallets that
reuse addresses (probably in part because they didnt implement HD wallets
and so are scared of losing addresses due to backup failure risks of non HD
wallets and fresh addresses).

Adam

On Fri, Jan 03, 2014 at 10:30:38AM -0800, Gregory Maxwell wrote:
On Fri, Jan 3, 2014 at 10:00 AM, Nadav Ivgi na...@shesek.info wrote:
 I had an idea for a payment scheme that uses key derivation, but instead of
 the payee deriving the addresses, the payer would do it.

 It would work like that:

 The payee publishes his master public key
 The payer generates a random receipt number (say, 25 random bytes)
 The payer derives an address from the master public key using the receipt
 number and pays to it
 The payer sends the receipt to the payee
 The payee derives a private key with that receipt and adds it to his wallet

Allow me to introduce an even more wild idea.

The payee publishes two public keys PP  PP2.

The payer picks the first k value he intends to use in his signatures.

The payer multiplies PP2*k = n.

The payer pays to pubkey PP+n  with r in his first signature, or if
none of the txins are ECDSA signed, in an OP_RETURN additional output.

The payer advises the payee that PP+(pp2_secret*r) is something he can
redeem. But this is technically optional because the payee can simply
inspect every transaction to check for this condition.

This is a (subset) of a scheme by Bytecoin published a long time ago
on Bitcoin talk.

It has the advantage that if payer drops his computer down a well
after making the payment the funds are not lost, and yet it is still
completely confidential.

(The downside is particular way I've specified this breaks using
deterministic DSA unless you use the OP_RETURN, ... it could instead
be done by using one of the signature pubkeys, but the pubkeys may
only exist in the prior txin, which kinda stinks. Also the private
keys for the pubkeys may only exist in some external hardware, where a
OP_RETURN nonce could be produced when signing).

These schemes have an advantage over the plain payment protocol
intended use (where you can just give them their receipt number, or
just the whole key) in that they allow the first round of
communication to be broadcast (e.g. payee announced to EVERYONE that
he's accepting payments) while preserving privacy.

--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] bitcoin 1.x 0.x in parallel (Re: is there a way to do bitcoin-staging?)

2013-11-21 Thread Adam Back
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.

Probably bitcoin staging is the wrong name.  I mean like development of
bitcoin 1.x in parallel with bitcoin 0.x which includes like test net for
both, and strong (though maybe not quite as high) assurance of qa and care
as bitcoin 0.x.  Just as a way to get features like Mark Freidenbach's
freimarket script extensions, and some of the disabled scripts validated on
1.x testnet and then after rigorous testing deployed onto 1.x  Because they
are new features even with good testing that introduces non-zero risk, hence
the 1 way peg idea.  Welcome to suggest better names for the idea...

Of course maybe the other issue is insufficient people with the skills and
motivation to support two parallel efforts.

It gives somewhere to code and test and then deploy clearly useful things
but that dont warrant a hard fork.

Adam

Melvin wrote:
   I think there may be a simpler way to do this.
   Create a new genesis block for a staging network, but in all other
   aspects, as far as possible, keep the properties the same as bitcoin.
   Do not actively be opposed to it being traded, but people need to know
   that, although there is no intention to reset the chain, new and
   potentially not fully tested, changes can be rolled into the network.
   Anyone mining staging coins should be prepared for the value to go to
   zero.
   Perhaps also a straw poll voting system could be set up for those
   that own staging coins could sign messages saying which patches they
   would like to test out next.  When patches are stable in the staging
   area, they could be promoted to the main net ...

--
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing 
conversations that shape the rapidly evolving mobile landscape. Sign up now. 
http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] moving the default display to mbtc

2013-11-15 Thread Adam Back
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 trillion zimbabwe dollar note I carry in my wallet for bitcoin
contrast/amusement purposes:

http://www.ebay.com/itm/50-TRILLION-ZIMBABWE-DOLLARS-CURRENCY-MONEY-US-SELLER-/110671104681

I like Alan's suggestion to show both to avoid denomination confusion.  That
is the one danger, and high risk given irrevocability.

Adam

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Zeroconf-safe tx replacement (replace-for-fee)

2013-11-04 Thread Adam Back
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
arent adding hardly any privacy.

We need more robust privacy fixes independently.  I do not support damaging
the 0-conf feature, so I think this later approach is a better track for
revising fees.

Adam

On Mon, Nov 04, 2013 at 05:52:43AM -0500, Peter Todd wrote:
On Mon, Oct 28, 2013 at 07:17:50AM +, John Dillon wrote:
 This discussion seems to be a lot of hot air over a simple observation that
 estimates are imperfect and always will be. I do not understand you vehement
 opposition the notion that a backup is a good thing except in the context 
 that
 replacement to change fees is halfway to profit-seeking replacement by fee.


 Peter Todd:

 You did a fair bit of leg work for replace-by-fee. Seems to me that
 replace-for-fee will help prep infrastructure to eventual replace-by-fee 
 usage,
 while avoiding some of the politics around zero-conf transactions.

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Payment protocol for onion URLs.

2013-10-28 Thread Adam Back
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 put a bitcoin address on their SSL site.

If someone can get into your site deeply enough to modify your SSL served
code and you're trying to run ecommerce you have other problems.

Never the less if they care they can clear sign the bitcoin addr with xmlsig
and their X.509 private key, and/or with PGP and a WoT.

I think its smarter to pollute bitcoin main with X509.  Make a little helper
util if there are not enough xmlsig tools that you cant pick one up
opensource for multiple languages.

This then avoids the binding to Tor - you can publish a bitcoin address
authenticated anyway you like.  Eg tahoe-LAFS auth/integrity, i2p, tor, pgp
- you name it.

Maybe I voice this opinion a bit late in the cycle, but I think it would do
bitcoin a favor otherwise its a camels nose in the tent into the TLAs that
control their own X.509 CAs, or issue NSL letters for CA private keys, or
forged certs.  It's all happening and thanks to Snowden we now have even
more evidence...

Adam

On Fri, Oct 25, 2013 at 09:06:48PM -0700, Gregory Maxwell wrote:
On Fri, Oct 25, 2013 at 8:41 PM, Luke-Jr l...@dashjr.org wrote:
 Is there any point to additional encryption over tor (which afaik is already
 encrypted end-to-end)? Is there a safe way to make this work through tor 
 entry
 nodes/gateways?

The x.509 in the payment protocol itself is for authentication and
non-repudiation, not confidentiality.

It's used to sign the payment request so that later there is
cryptographic evidence in the event of a dispute:
He didn't send me my alpaca socks! Thats not the address I told you to pay!
He told me he'd send my 99 red-balloons, not just one!  No way,
that was the price for 1 red-balloon!

Just using SSL or .onion (or whatever else) gets you confidentiality
and authentication.  Neither of these things get you non-repudiation.

 It'd be nice to have a way to support namecoin-provided keys too...

The payment protocol is extensible, so I hope that someday someone
will support namecoin authenticated messages (but note: this requires
namecoin to support trust-free SPV resolvers, otherwise there is no
way to extract a compact proof that can be stuck into a payment
request) and GPG authenticated messages.

But those things will require a fair amount of code (even fixing the
namecoin protocol in the nmc case), and GPG could be done just by
externally signing the actual payment request like you'd sign any
file... and considering the sorry state of their _practical_
usability, I don't think they're worth doing at this time.

By contrast, I _think_ the tor onion support would require only a
relatively few lines of code since it could just be the existing x.509
mechanism with just a simple special validation rule for .onion, plus
a little tool to repack the keys.  I think it would easily be more
widely used than namecoin (though probably both would not really be
used, as gavin notes).

w/ Gavin's comments I'll go check in with the tor folks and see if
anyone has ever though of doing this before and if there is already a
canonical structure for the x.509 certs used in this way.

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] two comments on brain-wallet security (and BIP 38)

2013-10-15 Thread Adam 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:

x2 = random 24bytes
Q = x2*P
k = Scrypt( salt2=H(Q)||salt, pass=P )
e = AES_k( x2 )

manufacturer puts es inside coin.

- send coin, (salt, e, Q) to user

then optionally creates conf code:

B = x2*G
c = AES_k( B )

- send conf code c to user

verify code c:

(by recreating P, then k from Q  P, decrypt c to get B, check Q = x1*B)

x1 = Scrypt( salt, pass )
P = x1*G
k = Scrypt( salt2=H(Q)||salt, pass=P )

Which seems reasonable enough, however its unfortunate that you have to
repeat the Scrypt work at setup.

One thing that occurs to me eg as mentioned by Rivest et al in their
time-lock puzzle paper is that it is easy to create work, if you are ok with
parallelizable symmetric constructions (like scrypt(i) or PBKDF2(i) with i
iterations) without *doing* the work during setup.

It seems to me therefore that the above protocol could avoid the javascript
overhead issue that forces users to choose a weak iteration level if they
want to create the wallet in that way.

eg create a 32-bit random salt, replace scrypt(i=16384, salt, pass) with
scrypt(i=1,salt, pass) to be brute forced based on deleted salt.  Immediate
2^32 = 4billion iteration salt without any significant setup cost.  (Or if
you want to limit the parallelism say scrypt(i=65536, salt, pass) with a
deleted 16-bit salt.  That should be parallelizable up to 65536 GPU cores
(32x 7970 chips).

Symmetric time-lock puzzles can achieve decrypt asymmetry without repeating
the work at setup...

(Rivest et al goes on to avoid using that symmetric construct with an RSA
related mechanism, because they are trying to lock information for an
approximate future date, rather than protected by a specific amount of
grinding work.)


I proposed a different blind (securely server-offloadable) deterministic
proof of work relating to (asymmetric RSA-style) time-lock puzzles.  The
difference from time-lock is it is made blind (so the work can be securely
offloaded without the server learning your password or resulting key) and
can be easily made parallelizable also which is desirable for server
offload.

https://bitcointalk.org/index.php?topic=311000.new#new

I think that could take brain-wallets to a new level of security, if you
protect the amount by an amount of computation proportional to the value, eg
0.1% or 0.01% redemption cost paid to blind proof of work miners.

Adam

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?)

2013-10-07 Thread Adam Back
An update on the homomorphic coins, some more math validation  a test
implementation needs to be done, but a surprisingly good outcome so far of
predicted 2.5kB homomorphic valued coin.  Only coin splitting has to incur
the 2.5kB range proof.  Coin adding, full spending and mining is free,
because adding existing range proofed and validated coins cant overflow by
definition (21 mil coin cap).  You can also (obviously I guess) add a
homomorphicaly encrypted 0 value to a few other peoples coin balance to
get a kind of taint mitigation.

https://bitcointalk.org/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 (I thought t=2, but t=51).  Damn!  Back to
the not so efficient version (which is more zerocoin-esque in size/cost), or
the more experimental Schoenmaker non-standard p, q non EC one, or other
creative ideas to change the coin representation to simplify the proof (of
which this was a failed attempt).  See the bitcointalk thread for details.

https://bitcointalk.org/index.php?topic=305791.new#new

Adam

On Tue, Oct 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 be interested to hear them
(although bitcoin-dev is probably not the right place yet).

Thanks for providing the impetus to write down the current state, the
efficient version of which I only figured out a few days ago :)

I have been researching this for a few months on and off, because it seems
like an interesting construct in its own right, a different aspect of
payment privacy (eg for auditable but commercial sensistive information) but
also that other than its direct use it may enable some features that we have
not thought of yet.

I moved it to bitcointalk:

https://bitcointalk.org/index.php?topic=305791.new#new

Its efficient finally (after many dead ends): approximately 2x cost of
current in terms of coin size and coin verification cost, however it also
gives some perf advantages back in a different way - necessary changes to
schnorr (EC version of Schnorr based proofs) allow n of n multiparty sigs,
or k of n multiparty sigs for the verification cost and signature size of
one pair of ECS signatures, for n  2 its a space and efficiency improvement
over current bitcoin.

Adam

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?)

2013-10-01 Thread Adam Back
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 probably not the right place yet).

Thanks for providing the impetus to write down the current state, the
efficient version of which I only figured out a few days ago :)

I have been researching this for a few months on and off, because it seems
like an interesting construct in its own right, a different aspect of
payment privacy (eg for auditable but commercial sensistive information) but
also that other than its direct use it may enable some features that we have
not thought of yet.

I moved it to bitcointalk:

https://bitcointalk.org/index.php?topic=305791.new#new

Its efficient finally (after many dead ends): approximately 2x cost of
current in terms of coin size and coin verification cost, however it also
gives some perf advantages back in a different way - necessary changes to
schnorr (EC version of Schnorr based proofs) allow n of n multiparty sigs,
or k of n multiparty sigs for the verification cost and signature size of
one pair of ECS signatures, for n  2 its a space and efficiency improvement
over current bitcoin.

Adam

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?)

2013-10-01 Thread Adam Back
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 to
the not so efficient version (which is more zerocoin-esque in size/cost), or
the more experimental Schoenmaker non-standard p, q non EC one, or other
creative ideas to change the coin representation to simplify the proof (of
which this was a failed attempt).  See the bitcointalk thread for details.

https://bitcointalk.org/index.php?topic=305791.new#new

Adam

On Tue, Oct 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 be interested to hear them
(although bitcoin-dev is probably not the right place yet).

Thanks for providing the impetus to write down the current state, the
efficient version of which I only figured out a few days ago :)

I have been researching this for a few months on and off, because it seems
like an interesting construct in its own right, a different aspect of
payment privacy (eg for auditable but commercial sensistive information) but
also that other than its direct use it may enable some features that we have
not thought of yet.

I moved it to bitcointalk:

https://bitcointalk.org/index.php?topic=305791.new#new

Its efficient finally (after many dead ends): approximately 2x cost of
current in terms of coin size and coin verification cost, however it also
gives some perf advantages back in a different way - necessary changes to
schnorr (EC version of Schnorr based proofs) allow n of n multiparty sigs,
or k of n multiparty sigs for the verification cost and signature size of
one pair of ECS signatures, for n  2 its a space and efficiency improvement
over current bitcoin.

Adam

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] smart contracts -- possible use case? yes or no?

2013-09-29 Thread Adam Back
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
(advanced crypto, byzantine networking argument etc) that could address
them.  eg payee/payer blacklisting by a large group of miners and committed
transaction proposal to address it.

However even for that type of thing I think bitcoin-dev would probably
rather focus eg on something that has reached the stage of having a BIP.  Eg
it might be better to discuss early stage or speculative ideas on
bitcointalk.org technical thread.

https://bitcointalk.org/index.php?board=6.0

taxation in particular there are examples where even the political sphere
accepts significantly anonymous taxation.  eg for europeans with certain
types of investment in a swiss bank, the swiss bank sends however many
million as a single payment across all users per european country to their
passport home country (minus 25% cut for the swiss government).  Perhaps
such things could be possible for bitcoin.  Again I think bitcoin talk would
be a good place for such a discussion if that was the OP question
indirectly.

Adam

On Sun, Sep 29, 2013 at 06:32:10PM +1000, Gavin Andresen wrote:
   On Sun, Sep 29, 2013 at 12:28 PM, Neil Fincham [1]n...@asdf.co.nz
   wrote:

   I subscribe to this list so I can keep up-to date with bitcoin
   development, can we keep philosophy and tax evasion out of it?

   Yes, that's off-topic for this mailing list. Lets stick to technical
   issues that we can solve by writing code.
   --
   --
   Gavin Andresen

References

   1. mailto:n...@asdf.co.nz

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk

___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-14 Thread Adam Back
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 sacrificed bitcoin).

I say that because if users who want zerocoins can obtain them at 1:1
exchange via sacrifice (a mathematical peg), it is of no additional cost to
them to instead buy them from someone who previously obtained them via
sacrifice for bitcoin (rather than sacrificing a new bitcoin).  So
presumably for goodwill, or nominal fee (a small discount), people would buy
rather than sacrifice where there is availability.

Adam

On Sun, Jul 14, 2013 at 07:22:10PM +, John Dillon wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, Jul 14, 2013 at 11:18 AM, Jorge Timón jti...@monetize.io wrote:
 All the arguments in favor of this pegging use zerocoin's point of
 view. Sure it would be much better for it, but are additional costs to
 the bitcoin network and you cannot do it with every chain.

Seems that Peter is describing a system that requires no changes at all to the
Bitcoin codebase and thus there are no costs whatsoever.

Peter: I'm a bit confused by this concept of bi-directional sacrifice though,
I assume there exists only a sacrifice in one direction right? Wouldn't selling
a zerocoin be just a matter of giving zerocoin a rule so that the zerocoin tx
moving it to the new owner only happens if a specific form of bitcoin tx
happens too?

 Merged mining is not mining the coin for free. The total reward (ie
 btc + frc + nmc + dvc) should tend to equal the mining costs. But the
 value comes from demand, not costs. So if people demand it more it
 price will rise no matter how is mined. And if the price rises it will
 make sense to spend more on mining.
 Bitcoins are worth because it costs to mine them is a Marxian labor
 thory of value argument.
 It's the other way arround as Menger taught us.

Merge mining is very much mining a coin for free. Ask not what the total reward
is, ask that the marginal cost of merge mining an additional coin is. The issue
is that unless there is a cost to mining a *invalid* block the merge mined coin
has little protection from miners who mine invalid blocks, either maliciously
or through negligence. If the coin isn't worth much, either because it's market
value is low or the worth is negative to the malicious miner, your theories of
value have nothing to do with the issue.

Gregory Maxwell has written about this issue before on the #bitcoin-dev IRC
channel and on bitcointalk as well if memory serves. I advise you to look up
his description of the problem, almost everything he writes on the topic of
crypto-coin theory is spot-on correct.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJR4vpGAAoJEEWCsU4mNhiPwu0IAMrzkVfI0CQuNJRCR+jwhNts
juEerApSSpBes6CjLBJJYZWDdMReSl6izqNDancnJygYc+Q5/IkwBispyZyeIVqY
HbV+jyAFQeVaJBZp8N+ZUDfN9/35SkPb4Y30dkq6V76hBfl+59bWq4qG0dhiO915
SBWAUPLspb5GOyu494GJUr4SPzgs9mAKfNGeQR2anOLj8Qam8Khfa4Zm5T5dX8WQ
vBunUCLykPvWBC3nuTDBU5gQu4TGW9ivGB4p6yLr7MyaPQYZEnYGqgU/yIfAhnBj
MfIfs6njPwhGMwteNmwLoS0VLRBFjWZDflquJ0NK6mNLR3c9yjOFMFPTTZFVinQ=
=b40P
-END PGP SIGNATURE-

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-13 Thread Adam Back
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 mining is what it is, adding more
alt-coins just dillutes the compute available for a given coin.  (Modulo
different mining functions like scrypt vs hashcash there is some
non-overlapping available compute because different hardware is more
efficient, or even cost-effective at all).

Merge mining is less desirable for the alt-coin - its mining is essentially
free, on top of bitcoin mining.  Cost free is maybe a weaker starting point
bootstrapping digital scarcity based market price.

I think that serves to explain why bitcoin sacrifice as a mining method is a
simple and stable cost starting point for an alt-coin.  

I think this could be highly controversial [alt-coin pegging].  Maybe
everybody likes it, but can you expand more on the justifications to peg
the two currencies?

Bitcoin sacrifice related applications do not require code changes to
bitcoin itself, which avoids the discussion about fairness of which alt-coin
is supported, and about sacrifice-based pegging being added or not.

I dont think it necessarily hurts investors in bitcoins as it just creates
some deflation in the supply of bitcoin.

If you're requiring one chain look at the othe for validations (miners
will have to validate both to mine btc) you don't need the cross-chain
contract, you can do it better.

You can sacrifice bitcoins as a way to mine zerocoins without having the
bitcoin network validate zerocoin.  For all bitcoin clients care the
sacrifice could be useless.

Bi-directional sacrifice is more tricky.  ie being allowed to re-create
previously destroyed bitcoins, based on the sacrifice of zerocoin.  That
would have other coin validation requirements.

But I am not sure 1:1 is necessarily far from the right price - the price is
arbitrary for a divisible token, so 1:1 is as good as any.  And the price
equality depends on the extra functionality or value from the
characteristics of the other coin.  The only thing I can see is zerocoin is
more cpu expensive to validate, the coins are bigger, but provide more
payment privacy (and so less taint).  Removing taint may mean that zercoins
should be worth more.  However if any tainted bitcoins can be converted to
zerocoin via sacrifice at 1:1, maybe the taint issue goes away - any coins
that are tainted to the point of value-loss will be converted to zerocoin,
and consequently the price to convert back should also be 1:1?

You could do something like this:

https://bitcointalk.org/index.php?topic=31643.0

p2p transfer is a good idea.

Adam

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-05 Thread Adam Back
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 merging
into bitcoin as it slows validation, bloats the blockchain, and also a
policy aspect it also imports cryptographic privacy into bitcoin.

On the forum thread on zerocoin math etc I suggested maybe people interested
to explore bitcoin could create an all-zerocoin alt-coin that is either-or
mined and p2p exchangeable for bitcoin.

Do people think that should work?  It seems to me it should with minimal,
bitcoin changes.  I think the rule for either-or mining should be as simple
as skipping the value / double-spend validation of the blocks that are
zerocoin mining blocks.  Obviously zerocoin blocks can themselves end up on
forks, that get resolved, but that fork resolution can perhaps be shared? 
(Because the fork resolution is simply to accept the longest fork).

 what about making an all zerocoin based alt-coin (no bitcoins, nothing but
 zerocoins), that is either-or mined with bitcoin.  Then people can trade
 in and out of zerocoins by buying or selling them for bitcoin with an
 atomic transaction, probably p2p without some trusted exchange like mtgox.
 
 Either-or mined (as distinct from merge-mined) I mean that each mined coin
 set is either a set of 25 bitcoins or a set of 25 zerocoins.  If its a
 zerocoin set its not a valid bitcoin set, and if its a bitcoin its not a
 valid zerocoin.  I'm not sure the zerocoins or bitcoins have to do much
 with mining events for the other network other than check they have the
 expected number of bits as they wont automatically know how to validate
 the other network.  Some miners may choose to validate both networks, but
 thats a choice for them.
 
 In that way people can experiment with zerocoin, without bloating the
 block chain, complicating bitcoin, and without slowing validation on the
 bitcoin network.  And the two coins should have approximately the same
 cost (and maybe therefore value, though the price would be subject to
 demand/supply and any taint discount for bitcoins; zerocoins are taint
 free, or perfectly blended taint at least).

Adam

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol

2013-06-19 Thread Adam Back
This maybe simpler and trivially compatible with existing type2 public keys
(ones that are multiples of a parent public key): send an ECDSA signature of
the multiplier, and as we know you can compute (recover) the parent public
key from an the ECDSA signature made using it.

Adam

On Wed, 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 Schnorr proof of knowledge (which both demonstrate
knowledge of the discrete log of Q to base G.)

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] is there a way to do bitcoin-staging?

2013-06-14 Thread Adam Back
Agreed.  What I mean is a coinbase for parity-priced alt-coin would be
intentionally considered (and required by the alt-coin to be considered) an
invalid bitcoin address, and vice versa.  The difference is for this purpose
it is both valid alt-coin coinbase (as well as unspendable bitcoin
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 to choose the altcoin or btc at mine time, and altcoin chain
 considering btc mine unspendable and bitcoin considering ac unspendable.

One way to look at what you are describing is to say you want to prove
your sacrifice of potential BTC earnings. That goes back to the PoW
hashcash stuff I mentioned earlier, and is accomplished by simply mining
shares with an unspendable coinbase to prove you did work that could
have resulted in Bitcoins, but didn't.

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] is there a way to do bitcoin-staging?

2013-06-13 Thread Adam Back
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 to choose the altcoin or btc at mine time, and altcoin chain
considering btc mine unspendable and bitcoin considering ac unspendable.

In terms of validation which miners are currently doing to help SVP clients,
it implies verification of both chains.  Or more incrementally each mine
should indicate in its serialization which chain it has validated.  This wa
about a hypothethical pure zerocoin altcoin hence zc/zerocoin:

Maybe we can say that a mergemine does not count as a validation of the
network for the respective network unless there is serialization in the
coinbase indicating that the network is validated.  In that way you could
have zerocoin mined and zerocoin validated, zero mined and bitcoin validated
(strange but possible), zerocoin mined and both zero and bit coin validated,
and also the same for bitcoin mined and zerocoin validated (strange but
possible), bitcoin mined and bitcoin validated (normal bitcoin ignoring
zerocoin) and bitcoin mined and bitcoin and zerocoin validated.  Then the
validation events on zerocoin network might not be as frequent.  Maybe
miners will tend to validate both networks as then they can claim fees on
both networks, even if the protocol prevents direct merged mining on both
networks (one or the other mined, and whatever chains validated as indicated
by coinbase serialization).

(I described it in this thread
https://bitcointalk.org/index.php?topic=175156.msg2420768#msg2420768 which
is mostly about understanding zerocoin, but digressed at that point to a
hypothetical pure zerocoin alt-coin that retains a fair merged mine and
exchangeless tradeability with main bitcoin.)

I think another gap is the exchangeless tradeability.  Apparently the
contract based proposals have race conditions, and ransom issues (refuse to
complete agreed commitment phase without being part-paid again).  I didnt
follow that discussion yet but Greg Maxwell and Sergio Lerner were
discussing and that seemed to be their conclusion, and Sergio's proposed
solution relied on a non-standard and not-fully-worked-through assumption
for the alt-coin (probably non-SPV compatible I think).

ps I thought it was quite interesting that seemingly you could make a pure
zerocoin alt-coin, it turns out you could direct mine them, and do zc-zc
transactions.  

They are fixed denomination however I think you could extend them with
homomorphic amounts.  I noticed Matthew Green mentioned this idea in his
presentation at microsoft research (saw in the video they have put online). 
 From my perspective (he didnt specify how other than as an attribute) its
something like a Brands credential where you can prove in ZK that two
attributes sum to a given value without revealing the attributes at all. 
The missing last part is you have to prove that the attributes are less than
some threshold to avoid people cheating and adding q to their balance. 
(Arithmetic in the exponents is modulo q in the subgroup used in zerocoin). 
There are several approaches to doing this some of them not that cheap (eg
involving k DSA-like signatures to prove vale v  2^k).  The idea of proving
it is less than k where k is say 128 is that then to add q, you have to
spend 2^128 coins which you cant do.  You can either make the values
uncertain by having v eg have 44 bits of useful precision and a few binary
00s and then 80-bits of randomness, or you can use a second never disclosed
random attribute like in a Pederson commitment or Brands credential eg 
c=g^v h^r mod p where r is random and never disclosed, but the user proves
knowledge of discrete log representation of c in terms of powers of g and h.
The downside of k signatures is validation CPU cost, and worse transaction
size.

There are several other approaches which seem to be able to prove v  2^k
with less than k, eg even 1 DSA-like signature.  I need to gather that info
in one place and write something referencing the literature I found so far. 
A homomorphically verifiable coin balance transfer could be interesting
outside 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 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
bitcoin-staging?  where the coins are the same coins as on bitcoin, the
mining power goes to bitcoin main, so some aspect of merged mining, but no
native mining.  and ability to use bitcoins by locking them on bitcoin to
move them to bitcoin-staging and vice versa (ie exchange them 1:1
cryptographically, no exchange).

Did anyone figure anything like that out?  Seems vaguely doable and
maybe productive

Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

2013-06-02 Thread Adam Back
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 UTXO
set if the unspendable address choices are not standardized)

b) spend to anyone which I take it goes to a random person who happens to
see the address first and race the spend to me out on to the network, and
hope miners dnt replace it with spend to miner, which is insecure

c) doesnt delay by 100 blocks just delay the spend to me race?  Also most
likely to be one by a big miner once they adapt and join the race.

d) some new standardized spend to fees (only miners can claim).

e) spend to charity/non-profit of choice could be useful also

f) I guess we see something related in zerocoin - locked but unlockable via
another type of transaction later.

g) why not instead make the beneficiary the address of the service the user
is consuming that is being DoS protected by the proof-of-sacrifice?  Seems
more useful than burning virtual money, then it helps the bitcoin network
AND it helps the service provide better service!

so if I understand what you proposed d) seems like a useful concept if that
is not currently possible.  eg alternatively could we not just propose a
standard recognized address that clearly no-one knows the EC discrete log
of?

Adam

On Sat, Jun 01, 2013 at 03:30:36PM -0400, Peter Todd wrote:
Currently the most compact way (proof-size) to sacrifice Bitcoins that
does not involve making them unspendable is to create a anyone-can-spend
output as the last txout in the coinbase of a block:

scriptPubKey: data OP_TRUE

The proof is then the SHA256 midstate, the txout, and the merkle path to
the block header. However this mechanism needs miner support, and it is
not possible to pay for such a sacrifice securely, or create an
assurance contract to create one.

A anyone-can-spend in a regular txout is another option, but there is no
way to prevent a miner from including a transaction spending that txout
in the same block. Once that happens, there is no way to prove the miner
didn't create both, thus invalidating the sacrifice. The announce-commit
protocol solves that problem, but at the cost of a much larger proof,
especially if multiple parties want to get together to pay the cost of
the sacrifice. (the proof must include the entire tx used to make the
sacrifice)

However if we add a rule where txouts ending in OP_TRUE are unspendable
for 100 blocks, similar to coinbases, we fix these problems. The rule
can be done as a soft-fork with 95% support in the same way the
blockheight rule was implemented. Along with that change
anyone-can-spend outputs should be make IsStandard() so they will be
relayed.

The alternative is sacrifices to unspendable outputs, which is very
undesirable compared to sending the money to miners to further
strengthen the security of the network.

We should always make it easy for people to write code that does what is
best for Bitcoin.

-- 
'peter'[:-1]@petertodd.org
00ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293



--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2

___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Decentralizing mining

2013-05-31 Thread Adam Back
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 challenge field is the reason
Satoshi's first year mining is marked (plus forgetting to reset the
counter).  (Bitcoind I believe considered the direct miners key as defense
enough as a stand in for self-chosen challenge, which has a few problems).

The base counter I think is only 32-bits, the extranonce2 itself being
random can be incremented while still looking random.  But incrementing
extranonce directy while initializing it to 0 is not good (per previous
mining extranone marked coins bug - is that even fixed?)

(You dont want to  reveal the miners power in his pool shares, if the full
counter is revealed with no randomness it also reveals how many iterations
he can do since the block start).

Adam

On Fri, May 31, 2013 at 12:57:58PM -0400, Peter Todd wrote:
I just posted the following to bitcointalk.

https://bitcointalk.org/index.php?topic=221164.0


Right now between two to four running the largest pools control Bitcoin
in the short term. That's a lot of hashing power in the hands of very,
very few people. In addition pools have little incentive to run secure
operations, and many pools have been hacked with their funds stolen.
Those hacks could just have easily been used to attack the network
itself.

This needs to change.

Pooled-solo mining is a concept Gregory Maxwell, Luke Dashjr and I were
discussing at the conference two weeks ago. (credit goes to Greg and
Luke; I was mostly just listening) Basically the idea is that miners
with mining equipment run a local Bitcoin node and use that node to
construct the blocks they mine - the same as if they were solo mining.
The pools job is then to only track shares and organize payouts.

If the pool gets hacked the worst that can happen is miners are ripped
off, rather than Bitcoin itself being attacked. With pooled-solo mining
even a pool with a majority of hashing power wouldn't be able to do much
harm to Bitcoin. (depending on the implementation they may be able to
blacklist specific transactions - the pool needs to know what
transactions are in the share to credit fees properly)

Tech-wise Luke created getblocktemplate last year as a means to audit
mining pools. I'm sure Greg and Luke can explain the nitty gritty
details better than I can, but essentially the plan is to take
getblocktemplate and extend it as required for pooled-solo mining. This
will include pool and miner software initially, and later improvements
to GUIs and what not to make the whole process easier.


With the success of my recent video project I also want to make this
Keep Bitcoin Free's next project, specifically funding a developer
(likely Luke) to make this happen. Additionally once software is written
and easily usable a good follow-up would be a video and other media to
promote the idea to miners. No guarantees we'll be able to come up with
commercially competitive remuneration, but we can at least come up with
a Thank you tip. But first lets discuss the technical requirements to
get an idea of what the scope is.


Finally, for the record, a big part of the reason why myself and other
Keep Bitcoin Free supporters are interested in doing this is very much
to take power over the direction of the network from big pools and put
it into the hands of thousands of individual miners. It's much easier to
convince people that changes to Bitcoin, like increasing the blocksize,
are directly impacting decentralization when individual miners are
seeing that happen to themselves.

-- 
'peter'[:-1]@petertodd.org
00c14fa7031b2431ab32785efdf1e5aaecc83555ee52a2fc550b



--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2

___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-16 Thread Adam Back
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 creates quadratic costs in evaluating a private
clique's claims  so

I believe the coin size and verification cost is linear not quadratic, but
maybe it depends on the parameter you're measuing in.  The coin size is
linear with the number of committed (uncompacted) spends.  You can view
reveals as committed compaction.  For efficiency a recipient of a committed
coin may as well compact and spend in one transaction so no new messages are
created.

Btw I believe if one were concerned about the committed coin size, I can see
a small tweak that would keep the size of the committed coins small eg
256-bit regardless of number of spends (no longer grows), and let the block
store the encrytped  MACed commitment.  Then compaction is no longer a
concern.  However I think that is SPV - SPV client unfriendly.  (A full
client - SPV client should still be workable as the full client could
alternatively send the client the MACed data and key, rather than have him
look at it from his block history.)  (Crypto sketch below).

However I am not sure multi-spend committed coin size is really a concern
because to the extent people hold long commitments without revealing to the
network for the long term, that is a bandwidth saving to the network.

Overall about privacy it would be typically temporary, though the peers have
the technical means to react and defend themselves by using longer committed
chains if dishonest mining is detected on a significant scale.

instead an implementation would make the identities public but only once
they're burred a bit.

That was the seed idea.  The more aggressive spend lots of times in
committed form is just a technical threat that will keep dishonest mining
in check.  By definition the coin is already irrevocably spent before the
reveal (without the threat of having the dishonest miners endlessly redoing
their own deeply burried work).  The only person who could be punished by
policy by 50% dishonest miner (retroactively) is the recipient, not the
spender, and the punishment is very muted: all he can do is prevent coin
compaction.  If the committed coins are small, compact doesnt even hurt the
committed coin user, just network itself.  Therefore a dishonest miner is
wasting his time his dishonesty cant enforce his dishonest policy.

To store the commitments in the block chain replace:

 (blind-sender, auth-tag, tx-commit)
 
 blind-sender = SHA1( SHA256( 1, pub ) )
 auth = HMAC-SHA256-128( K, tx-commit )
 tx-commit = SHA-256( tx )
 K = SHA-256( pub )

with:

(blind-sender, auth-tag, encrypted-tx-commit)

blind-sender = SHA1( SHA256( 1, pub ) )
auth = HMAC-SHA256-128( K, encrypted-tx-commit )
encrypted-tx-commit = AES( K, tx-commit )   (*)
K = SHA-256( pub )

then a reveal is just to send the recipient the public key (32 bytes)
per hop, still linear but ~3x smaller.

I suggested fixed size committed coin spends, that also you can do but with
public key crypto needed probably, and so dropping to the verification
efficiency of standard transactions.  Sketch 2:

(blind-sender, auth-tag, encrypted-tx-commit)

(pub key P = xG, G = base point)

blind-sender = cP (public key EC multiplied by constant c)
sig = ECDSA( cx, encrypted-tx-commit )
encrypted-tx-commit = AES( K, tx-commit )
K = random

as K is random, knowledge of P if stored unencrypted does not allow
committed spend-to-junk.  To reveal to a recipient just send them P and K at
each hop.  (Same K each time, anyone on the committed coin spend chain can
already chose to reveal at any time so no loss of security.)

You dont need to verify a second signature inside the tx-commit because you
already signed the encrypted-tx which binds to it (encryption with out MAC
is malleable but you cant change it at all without invalidating the
encryption).  Just need to check the input tx in the tx-commit has P as its
recipient.  P does not even need to go into tx-commit as its already bound
by cP and signature security (cant create a signature with someone elses
key).  So I think the commited coins of this form are the same size and
verification cost for the network.  And small and fixed size to spend
offline.  (32+32=64 bytes fixed).

Adam

(*) You should not as a principle re-use keys across algorithms, I omitted a
second key for simplicity.  Really K1 = SHA256( 1||pub ), K2 = SHA256(
2||pub ) encrypted-tx-commit = AES( K1, tx-commit ), auth = HMAC( K2,
encrypted-tx-committ ).  Or more simply a combined authenticated mode like
CCM or GCM and a single key managed by the mode.

--
AlienVault Unified Security Management 

Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-16 Thread Adam Back
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)
   sig = ECDSA( cx, encrypted-tx-commit )
   encrypted-tx-commit = AES( K, tx-commit )
   K = random

as K is random, knowledge of P if stored unencrypted does not allow
committed spend-to-junk.  To reveal to a recipient just send them P and K at
each hop.  (Same K each time, anyone on the committed coin spend chain can
already chose to reveal at any time so no loss of security.)

Actually same K every time is not so hot, as then earlier in the committed
spend chain, can force a reveal for someone later.  A clearer requirement is
that each person should only be able to reveal committed coin chains up to
the point of their direct involvement.

So that is easily fixable, just include the K for the input committed coin
in the encrypted-tx-commit, as above but:

encrypted-tx-commit = AES( K_i, K_{i-1} || tx-commit )
K_i = random

(different K for each spend).

And actually for symmetric encrypted variant the coin as specified was
already evaluatable with fixed size committed spend (of the last public key)
- I just didnt realize it in the previous mail: the input public key is
necessarily revealed when processing the decrypted tx-commit, allowing
identification and validation of the txin, and validation recursively back
to the first non-committed coin.  With symmetric verification, the
limitation is one-use coin committed addresses (and inability to remove
spend to committed junk with public validation, though there is the tx fee
as a discouragement, it does bloat a recipients verification and so maybe
frustates SPV-SPV consumption of committed coins).

(blind-sender, auth-tag, encrypted-tx-commit)

 blind-sender = SHA1( SHA256( 1, pub ) )
 auth = HMAC-SHA256-128( K, encrypted-tx-commit )
 encrypted-tx-commit = AES( K, tx-commit )
 K = SHA-256( pub )

Adam

ps and it would be better and clearer to read also in terms of purpose of
hashes, to use a KDF like IEEE P1363 KDF2, or PKCS#5 PBKDF2 with 1
iteration, rather than adhoc hashes for key derivation.

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-15 Thread Adam Back
 from
scratch.  Often if simple lower powered intermittent recipient sends the
coin will be burried hundreds of blocks back.  In addition 6 chain long
branches are extremely unlikely with honest payers, so clients can (and
maybe already do?) act with suspicion of they see one.


Going further, I said for best security, the recipient should never even
reveal (to the network) until he is actually about to spend, but futher he
does not even have to reveal publicly ever, he can choose to reveal only to
the recipient with a direct connection (no p2p flood fill of transaction.)
And the direct spend argument composes, ie the 2nd recipient can not do the
same thing again.  (public key A sends to public key B sends to public key
C: B publishes COM( transaction B-C ), sends the reveal of COM( transaction
A-B ), and COM transaction B-C ) to C.  C waits 6 confirmations and is
convinced.  So its the approach is composable, and in fact the network
doesnt learn the size of the transaction even, though the spend grows each
time.  Eventually presumably someone will publish will the confirmations to
the network to trim the tansaction size, though it is not strictly
necessary, and the transaction flow is small and direct (no network scaling
issues), so that it wouldnt be a huge problem to have a 1MB payment
representing 1000s of hops of network blind transactions.  (For the
composable network blind respending the commitment has to commit publicly to
both the sender and next hop recipient keys, so the network can see how long
the chain is).

Probably you can cope with multiple inputs and outputs, and maybe given even
you can work with a 100% dishonest network mining network (all the dishonest
miner can do is selectively DoS transactions if they are all network blind
except the mining), maybe the mining can even be decoupled from the voting,
as you no 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:09:02PM +0200, Adam Back wrote:
 [...]

One related concept is commitments.  I think its relatively easy to commit
to a payment and lock a coin without identifying yourself, until the
commitment is released.  You might do the commitment, wait 6-blocks for
confirmation, then reveal the commitment.  Then that is like a self-issued
green coin with no need for trust, that can be immediately cleared.  The
recipient has to be committed to at the same time to prevent double
spending.

So just commit = H( input-pub ) H( transaction ) and put it in the block
chain.  Where transaction the is usual ( input signature, output-pub,
script).  (Fee for the commit would have to come from an unlinked coin or
the input-pub reveals the coin).  Wait 6 blocks, send/reveal the transaction
(free because fee was already paid).  Validators check input-pub hash
against committed coins by hash, check the transaction hash, and the usual
ransaction validations = sum inputs, otherwise reject.  The user better pay
change if any to a different public key, as the inputs public keys are one
use - are after the reveal they are DoS lockable by other people reposting
H( input-pub ).

The input-pub coin is locked as normal transactions have their public key hash
validate as not being locked.

Adam

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] double-spend deletes (or converts to fees) (Re: reward for making probabalistic double-spending via conflicting transactions easy)

2013-05-15 Thread Adam Back
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 chance, so much of the time you'll get away with a double spend. 
We don't yet have a mechanism to propagate double-spend warnings, and funny
enough, in the case of a single txin transaction the double-spend warning
is also enough information to allow miners to implement replace-by-fee.

About double-spends it might be better if the double-spend results in no-one
keeping the money ie it gets deleted by definition (except for the fees, or
the whole payment gets converted into a 0BTC output so 100% fees).  Ideally
you'd want a way for known double spends to be circulated at priority in the
p2p network, even routed directly to earlier recipients if known.  However
have to watch out for even the fees being double spent in other
transactions.  Maybe the fees could be demanded to be self-created (no
trusted green-coin issuer) 6-confirmation spend-to-miner green-coins.

(Note double spends are not-binary.  An attacker can spend a 25BTC coin via
50x 1BTC transactions.  Which 25 are valid?  Currently it is the first 25
from the network perspective of the miner that succeeds on the current
block.  (And that view overrides, even if other miners had differing views,
unless the block later becomes an orphan).  Its surely easy for a double
spender to accumulate fast connections to known powerful miners to get the
spends that benefit him to them first.)

In that way (with double-spend deletes) the would be double-spender can not
gain within the bitcoin protocol by double spending.  He can gain outside of
the protocol eg by persuading merchants to give him non-revocable resellable
non-physical goods (or physical but anonymous goods).  But that is harder
work, and people selling goods with no recourse will be defensive about
confirmations.

ps I still dont think replace-by-fee is a good idea, at least the way it was
implemented with changeable outputs, but I think that discussion seemed
closed, so I wont rehash it.

Adam

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-15 Thread Adam Back
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 address I control.

Bit-commitments are based on deterministic one-way functions eg like SHA1(
SHA256( public key ) ) Obviously it has to be a different one-way function
to the coin address calculation which is RIPEMD( SHA256( public key ) ) as
that is already public.  Alternatively it can be a different serialization
using the same hash eg RIPEMD( SHA256( 1 || public key ) ).

There is only one commitment possible per public key - so you can only
create one commitment that would validate to a receiver, or to the network. 
The network checks that there are no non-blind double spends of committed
coins which it can do as spends require disclosure of the public key, which
allows existing commitments to be verified, and it similarly qchecks that
there are no blind double-commitments.

Each committed coin would be:

one-spend-commit = Com( spender pub ), Com( transaction )

where Com is implemented as the above hash.  The network just places the
commitments in order as with conventional transactions.

The committed coins are not linkable to your non-blind coin because you did
not reveal your public key in the (largely passive) act of receiving to a
coin address.

On the topic of reversibility, I suspect in the long term the lack of
chargebacks will create issues as criminals learn that for the first
time in history, kidnap  ransom is effective. 

The temporary unlinkability (until commitment reveal) is a necessary side
effect, not a cryptographic anonymity feature like zerocoin.  The
transactions are identical to bitcoins once revealed.  How long the
committed transaction chains can be between reveals is an implementation
choice could be 1 hop, or as long as you like.  (Actually it appears to be
up to the individual users how long the maximum chain they accept is - the
network itself, though ordering the committed spends (if there are multiple
spends on the same key) cant even tell how long the commitment payment
chains are).

Obviously the first coins in the network ordered committed coins on the same
key up to the coin value are spends as verified by the recipient, the rest
are double-spend and ignored.  If someone wants to waste fees by sending
more spends than there inputs thats up to them.

Probably the typical user doesnt care about long committed chains  other
than their wallet will bloat if the chains are too long, so probably they
would periodically compact it by revealing the long chains.  Committed coins
are probably a bit less SPV client friendly, though with correct formatting
in the merkle trees between blocks, probably a committed coin holder can
provide enough proof to an SPV client to verify even multi-spend committed
coins directly (without a network feed).

About privacy, up to the entire commitment chain can be opened at any time
(to other people or to the bitcoin network in general) with the cooperation
of any user on the chain (up to the point they saw it), so while the blind
commitment protocol is not vulnerable to a  50% power quorum unilaterally
imposed policy (without even needing client updates), it is fully dependent
on the good will of the recipients for its temporary unlinkability.  Thats
the point: it puts policy control in the users hands not in the  50% power
quorum.

If you want cryptographic anonymity its better to look to zerocoin.  You may
have noticed zero coin talked about optional fraud tracing.  Its usually
trivial to add tracing to an otherwise privay preserving protocol.

The blind commitment if implemented as described (and its not obvious how to
get more privacy from it) offers somewhat like community policing.  Users on
the chain can still themselves do fraud tracing, or any policy they choose,
on any blind committed coins that they receive.  If they dont like the
colour of them they can refund them.  The point is to enforce that this is a
free uncoerced community choice, by individual end users, not a  50% cpu
power quorum choice surreptitiously imposed.

Adam

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-15 Thread Adam Back
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 transaction size.

As I said on the forum:

 Note committed transactions are more compact than regular transactions -
 they are just two hashes, so they reduce network bandwidth and make
 bitcoin more scalable to the extent that transaction reveals stay off
 network.  (As well as more secure against centralization policy risks). 

Surely its lower bandwidth for nodes to send only committed transactions to
the p2p network, and pass committed payment chains direct to recipients.

Say committed transaction size is c (20bytes+32bytes+16bytes +header ~ 72
bytes?) And full transaction smallest size is t (txin=20bytes, amount out
4bytes, sender pub key 32bytes, recip address 20bytes, change address
20bytes, formatting 5 bytes, ECDSA signature 64bytes, script 10 byte surely
~ 175bytes)?  Thats over twice the size.  Probably average more, and it is
sent to every node.  Its always going to be lower bandwidth to send
transactions to the recipients than to send to the network, even if you have
to increase the transaction size with each respend.  The alternative is for
the entire network to see the same transaction.

I think the commitment needs to bind the two parts together eg 

(blind-sender, auth-tag, tx-commit)

blind-sender = SHA1( SHA256( 1, pub ) )
auth = HMAC-SHA256-128( K, tx-commit )
tx-commit = SHA-256( tx )

Or some variantion, and you must not reuse the pub key, and must send change
if any to a different address, otherwise chain recipients or malicious
forwarders could lock your coin, by putting random junk onto the network
which would be unverifiable, and non-disclaimable - you cant prove you dont
know the preimage of some junk.  The MAC prevents it.  Maybe there's a more
compact way to do it even, but that works efficient demonstration of
security feasibility.

Other public key variants could be possible, P = xG is the ECDSA public key,
x the private key, G base point.  Sender could reveal P' = cP, c some fixed
constant (computing c from cP is ECDL problem considered oneway  hard), and
a signature by private key x' = cx over the tx-commit.  That is a publicly
auditable commitment also, but one tht can make an ECDSA signature over the
tx-commit hash, and can be revealed by revealing P later.  However that
imposes public key computation on the validation (which it already currently
does, but faster validation as above is nicer).  With that one you dont even
have to verify the transaction signature on reveal :)  You already did it,
just provide the tx that hashes to the signed hash, and P for the recipient
to verify the signature was made by cP.

Adam

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-14 Thread Adam Back
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 destroy-by-miner fee transaction is a
normal bitcoin transaction sent by any user, that might look like

Input 1: 1.0 BTC
Output 1: 0.5 BTC

(the miner fee is implicitly 0.5 BTC, paid to whomever mines the
transaction into a block)

Sadly the bitcoin protocol prevents zero-output,
give-it-all-to-the-miner transactions.

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 not so good.

Or do you mean to say you could have (implicit reward 25BTC) and reward
transaction .001 BTC to self and 24.999 BTC with existing bitcoin format and
validation semantics?  That would be close enough to give-to-miner.  Also
the output sum  0BTC limitation could be changed to = maybe... (just one
well placed character :)

Adam

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] ecash and revocability

2013-05-14 Thread Adam Back
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 a discussion of digigold (e-gold stored the
physical gold, digigold offered ecash backed in that physical gold). 
Digigold ran on Systemics payment server/sox protocol.  Because of inferred
regulatory concerns and patent licensing issues digigold  systemics were
not using blind signatures.  However with systemics sox server, like
bitcoin, you could create multiple accounts on demand and shuffle payments
around for a degree of privacy.  The bitcoin analogy would be the
transaction log lived in the systemics server, so it had a central failure
point, but arguably more privacy as the log was not public.  Also systemics
SOX protocol (Ian Grigg  Gary Howland) had some aspect of bitcoins smart
contract concepts - ricardian contracts. 
http://iang.org/papers/ricardian_contract.html 

(Btw the anonymous reply itself was interesting -
http://marc.info/?l=cypherpunksm=95280154629912w=2 that could have been
Nakamoto, the only missing thing from the parts on the discussion room floor
to bitcoin is mathematical inflation control.)

The thread actually started here
http://marc.info/?l=cypherpunksm=95280154629912w=2 and then continues here
http://marc.info/?l=cypherpunksm=95280154629900w=2 because of a subject
line change and then http://marc.info/?l=cypherpunksm=95280154629916w=2
and http://marc.info/?l=cypherpunksm=95280154629948w=2
more subject line change confusion.

A related thread a few days later also covers Sander  Ta-Shma (which
zerocoin is based on):

http://marc.info/?l=cypherpunksm=95280154630167w=2

there were many more threads about various ecash technologies.

Adam

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] bitcoin taint unilateral revocability (Re: ecash and revocability)

2013-05-14 Thread Adam Back
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.  Ecash should not be
revocable.  I think bitcoin currently has a partial problem because of
taint.

Now blinding based unlinkability, in a distributed cryptographic payer/payee
anonymous system like Sander  Ta Shma [1] and zerocoin has so far been
based on ZKP of set membership.  Of course that is somewhat expensive,
though zerocoin improved the ZKP with an relatively efficient (but still
cut-and-choose) proof.

Bitcoins relative lack of privacy creates a problem with tainted coins
risking becoming unspendable, or spendable only with some users, or at a
discount.  So while the policy coded says all coins are equally acceptable,
the information exists so people can unilaterally reject them, depending on
what the taint is.  So far revocability hasnt reared it's head that I heard,
nor taint inspection too much?  However people have the choice and technical
means to check the taint and send the bitcoins back.


Another aspect is that bitcoin, like systemics sox/digigold, makes a
different privacy tradeoff.  Somewhat private, but not very much.

But it creates the question: could the taint issue be fixed efficiently (eg
even without blinding or ZKP of set membership?)


One related concept is commitments.  I think its relatively easy to commit
to a payment and lock a coin without identifying yourself, until the
commitment is released.  You might do the commitment, wait 6-blocks for
confirmation, then reveal the commitment.  Then that is like a self-issued
green coin with no need for trust, that can be immediately cleared.  The
recipient has to be committed to at the same time to prevent double
spending.

So just commit = H( input-pub ) H( transaction ) and put it in the block
chain.  Where transaction the is usual ( input signature, output-pub,
script).  (Fee for the commit would have to come from an unlinked coin or
the input-pub reveals the coin).  Wait 6 blocks, send/reveal the transaction
(free because fee was already paid).  Validators check input-pub hash
against committed coins by hash, check the transaction hash, and the usual
ransaction validations = sum inputs, otherwise reject.  The user better pay
change if any to a different public key, as the inputs public keys are one
use - are after the reveal they are DoS lockable by other people reposting
H( input-pub ).

The input-pub coin is locked as normal transactions have their public key hash
validate as not being locked.

Adam

[1] Sander  Ta Shma Auditable, Anonymous Electronic Cash
 http://www.cs.tau.ac.il/~amnon/Papers/ST.crypto99.pdf

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-14 Thread Adam Back
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 not so good. [...]
[...]
Just referring to a standard, fee-bearing, user-created bitcoin
transaction, where output_value  input_value.  The fee is paid to the
first miner who includes that transaction in a block, as part of the
protocol.

Yes but thats inferior in the sense that it is spamming the bitcoin payment
protocol slightly, to the small reward of miners, and involves actual money
and traceability to real-name (where did you get the coin from to spend). 

If alternatively you just proof you direct mined on a block with a coinbase
that immediately makes payment to future miners its better because: a) you
can do that with no new traffic for the bitcoin network (except when you
mine a whole block, you'll post it); and b) anyone with a reasonable
verification on the blockchain head (even if the spender has to give it to
them!) can verify it without any other network traffic; and c) if its
micro-mined on the spot it can be bound to the service whereas if you give
it to fees as an on network transaction you are limited to values above the
min tx fee.  

So idealy I think you need to be able to simultanously mine and give reward
to future block miners.

What you could do with out that is d) mine for the reward of bitcoin
foundation/software author/or service provider.  In the last case (service
provider) its an extreme form of Rivests peppercoin probabilistic payment

Adam

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides

2013-05-14 Thread Adam Back
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 security of DNS ;)

Adam

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-13 Thread Adam Back
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 think there are 3 choices:

1. merged-mine (almost zero incremental cost as the bitcoin mining return is
still earned)

2. destroy bitcoin (hash of public key is all 00s so no computible private
key)

3. anyone-can-spend (= first to spend gets coin?)

Surely in 3 if you mine the bitcoin its no particular assurance a you will
do your best to make sure that it is *you* tht spends it, so it devolves to
merged-mine.  (Eg delay revealing it for 10 seconds while you broadcast your
spend widely)

Peter talks about value, but the proof only proves cost equal to bitcoin. 
Those are not the same thing.  And they are so-far non-respendable.

I still dont understand what he was saying.  If you do please speakup.


I think potentially a publicly auditable pooled mining protocol would be a
place to start thinking about respendble micropayments.  I made a post
on the bitcointalk forum outlining how that could be done:

https://bitcointalk.org/index.php?topic=1976.msg2035637#msg2035637

if you have a publicly auditable pool, where users can prove to each other
outside of the bitcoin transaction log that they contributed a number of
shares to a block, those could be traded somehow.  Possibly eg with the pool
keeping a double-spend db.  If the payments are low value, people maybe
happy trusting a pool.  If the pool cheats, everyone stops using the pool. 
You rely on the pool not to spend the backing bitcoin blocks.  But it
remains possible for the pool to cashout people who collected enough shares. 
Probably you could do that with blinding if desired.

 [probabilistic micro-payments]

I think you are misremembering [...] It is not a probabalistic scheme.

You are right I was thinking of Rivest's peppercoin.

 In this way one can merge mine bitcoin  hashcash to the benefit of the
 recipient (or some beneficiary trusted not to be paying the proceeds to the
 spammer).  And in a way that scales to email scale, and does not involve
 installing a bitcoin client in every client, nor mail server.

Blockchain header data may very well be one of the most widely distributed
single data sets in the history of mankind, and most of its closest cousins are
definitions such as the ASCII table or near definitions like the DNS root
servers. Not something with new data every 10 minutes.

Well there doesnt need to be a one-true-blockchain DNS, though the power to
output a hash at any reasonable rate is a big proportion of the network
power.  And the outputs are instantly verifiable, so it forms a kind of
trapdoor hashchain (where the trap door is not a secret but havng a huge
amount of CPU power).  And there can and should be many blockchain via DNS.

For namesaces in general another approach other than DHT/flood is numerous
competing hierarchical, heavily cached, but publicly auditable.  Cheaters
are shunned.  Same effect, more scalable, most people are not cheating most
of the time.

http://cypherspace.org/p2p/auditable-namespace.html

Adam

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-13 Thread Adam Back
Some musings about the differences between Peter's proof-of-sacrifice (you
did the work but elected to make the small reward chance unclaimable), vs
conventional actually doing the work but then destroying the bitcoin!

- proof-of-sacrifice seems similiar to hashcash except its difficulty is
   time stamped and measured against the bitcoins dynamic difficulty,
   (coordinated inflation control being something posited but never
   implemented in hashcash).  So thats kind of interesting, particularly if
   you can do it with very low bandwidth, and decentralized; unclear.

- with proof-of-sacrifice its more offline because you do not need an on
   block-chain double spend protection (via flood-fill, validation, and block
   chain mining) because it is simply unspendable, though you could show
   the same proof to multiple people.  In any case the values are far too low
   to spam the block chain with.

- because proof-of-sacrifice is small you can afford to mine them on the
   spot and make them payable to the identity of the recipient, like cheques:
   they identify the recipient, so they are automaticaly non-respendable in
   the eyes of the recipient (he keeps his own double-spend db, and people
   wont accept cheques made payabe to other people).  This is how hashcash
   works for email.  Also a time-stamp ensures you dont even need a big
   double-spend db, as you can prune it if you reject expired cheqes.

- you could give a proof-of-sacrifice a private key, just like bitcoins;
   then they could be pre-mined and identity or other info could be signed
   later.  However then you have double spending issues again.  You can 

- I mentioned amortizable hashcash under-contribution feature you can make
   it so the recipient uncovers the actual value of the coin (if it is
   merge-mined).  (Put recipient public key in coinbase, hash for min share
   size eg 32-bits leading 0s call that collision; send to recipient, he
   decrypts the hash with private key, so the decryption is verifiable with
   public key.  Then the full value of the coin is 
   zerobit( collision ) + zerobits( decrypt( collision ) )
   if that alternate validation was allowed in bitcoin.

- what about if a pool could lock the reward (rather than receive it or
   destroy it) eg some kind of merkle root instead of a public key hash in
   the reward recipient address field in the coinbase.  Then the miners who
   created that block have actual share proofs that are claims against
   something eventually redeemable.  Maybe if they collect enough
   share-proofs to reach a minimum bitcoin transaction size, they can redeem
   a big strip of shares for a few mBTC, but claims below that are rejected
   by the network due to tx fee.  (btw I think it seems possible to have a
   publicly auditable pool so it cant skim nor disclaim shares.)

I've been thinking about a decentralized way to create an anonymous
identity, something I think it key to any number of decentralized, P2P
and anonymous markets.  

There were some systems that charged hashcash for pseudonyms i2p names (i2p
is a ToR like system)...  see htp://www.i2p2.e/naming.html then there was of
course namecoin.  There was some remailer/email nymserver integration as
well.

Getting back on topic, somewhat, one idea I had for creation cost of a
SIN was associating the creation cost of a SIN with a bitcoin
transaction's miner fee.  Anybody in the world could, therefore,
create a SIN in a decentralized fashion, simply by following a
published protocol for burning a specified amount of bitcoins via
miner fee.  It can be cryptographically proven with 100% certainty who

Yes it seems that having a proof-of-sacrifice that hardens the block chain
is the important part.

When you said destroy-via-miner-fee:

Don't forget:  4. destroy-via-miner-fee, which is useful because it
provides funding for a public service (bitcoin transaction
verification).

Is that directly possible?  Because the reward transaction has no source,
and no fee?  Or can you put a 25BTC fee in the reward transaction in the
coinbase?

If so that seems like the best option for proof-of-sacrifice rather than
proving destroying the possibility of reward.  But alternatively the bitcoin
foundation as recipient, or EFF etc.  25BTC is a big reward might have some
double roll-over lottery effects - everyone piles in for the occasional
25BTC!

Adam

On Mon, May 13, 2013 at 02:38:15PM -0400, Jeff Garzik wrote:
On Mon, May 13, 2013 at 6:54 AM, 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 in a anyone-can-spend
output.

 I think there are 3 choices:

 1. merged-mine (almost zero incremental cost as the bitcoin mining return is
 still earned)

 2. destroy bitcoin (hash of public key

[Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-11 Thread Adam Back
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
question, thats why hashcash itself has no communication overhead other than
a header in the mail - its only scalability limit is email itself.

Rivest's PayWord for people who dont know the reference in this context is
the observation that for a low value micro-payment, you dont mind if you
only receive a payment 1 time in k so long as the expected payment is n
after receiving n (eg satoshi sized) payments.  Eg like a penny tip jar so
long as your expected payment is correct long term (win as often as you
lose) you dont mind.  And a fair 100% payout lottery can be fun of itself.

So let say each email client sends in an email header the head of the
bitcoin hash chain, it has seen via other emails, which can be offline
verified back to the genesis hash.  Maybe some clients even have bitcoin
installed and ask the bitcoin client for the hash chain head.  The client
also generates an address on setup, and sends its bitcoin address in a
header.  If you send to a new address you dont know their address, so you
send to eg me (Adam;) as a default, or the bitcoin foundation, or an invalid
address to destroy the coin - the recipient assumes that is not the sender
as those address are in the client.  A sender can under-contribute but makes
no gain.  Under-contributing is fixable if desired (see under-contribute in
amortizable hashcash paper, but using PK decryption with recipients private
key x as its non-interactive b'=D(x,share).) 

Then clients merge mine involving the recipients bitcoin address (or one of
the default addresses).

Even if the merged stamp provdes to be an orphan, even a very old one, its
valid in a hashcash anti-spam sense, meeting the same purpose as destroyed
coin.

Maybe one can put the bitcoin hash in DNS with a 5min TTL and have mail
clients read that to reduce scope for stale mining.

In this way one can merge mine bitcoin  hashcash to the benefit of the
recipient (or some beneficiary trusted not to be paying the proceeds to the
spammer).  And in a way that scales to email scale, and does not involve
installing a bitcoin client in every client, nor mail server.

Adam

On Sat, May 11, 2013 at 12:53:42AM -0400, Peter Todd wrote:
It has been previously(1) proposed that hashcash using the same PoW
function as the Bitcoin block hashing algorithm be used to create
hashcash whose value is denominated in Bitcoins. This poses two problems
however: widespread use of such hashcash would harm overall network
security and determining the value of the hashcash requires knowing the
revenue miners can gain from transaction fees at a given block height -
a non-computable function. However, with some modifications we can
extend the idea to directly denominate the hashcash in Bitcoins at the
cost of a small increase in proof size.

Recall that the fundemental problem is the need to do some work to make
digest D have value V, resulting in a proof that can be given to a third
party. We want V to be denominated in Bitcoins, and we want the actual
economic cost to create P to be as close as possible to the face-value
V. Finally should computing P result in a valid Bitcoin block header,
the creator of the proof should have a strong incentive to publish their
header to the P2P network and extend the current best chain.


# Proof structure

Lets look at the elements of the proof from the block header to the
digest.


## PoW Block Header

This must be a valid block header. It is particularly important to
ensure that the header can be linked to the actual blockchain, although
the header itself does not need to be a part of the chain, and hence the
block hash does not need to meet the difficulty requirements.


### Previous Block Headers

The proof may optionally include one or more previous block headers in
the event that the PoW block header's previous block is an orphan.
Unlike the PoW block header, these block headers MUST meet the
difficulty requirements although an implementation MAY skip actually
checking the difficulty if a difficulty retarget has not happened or the
PoW is timestamped. (see below)


## Partial Transaction and Merkle Path

The partial transaction consists of a SHA256 midstate followed by
exactly one transaction output. The merkle path to the PoW block header
MUST prove the transaction was the coinbase transaction and not any
other transaction.


## Transaction Output

The last transaction output must have a scriptPubKey consisting of
exactly one PUSHDATA op which pushes H(D | N) to the stack. Its value,
V', is the basis for determining the value of the proof of work. V' must
satisfy V'  k*Vi(h) where Vi is the inflation reward for the PoW block
height and k  1 For a number of reasons, including making 

Re: [Bitcoin-development] An initial replace-by-fee implementation is now available

2013-05-09 Thread Adam Back
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 the reward must be
unchanged, otherwise the revision is considered invalid and discarded?

(ie same payment amount, same input coins, same recipient and same change
address.)

Adam

On Thu, May 09, 2013 at 09:58:50AM +, John Dillon wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

After some consultation with affected sites by myself and Peter we have decided
to release an initial replace-by-fee implementation and setup a server using
those rules on testnet. This implementation does not include recursive fee
evaluation, and is therefore vulnerable to DoS attack, so hopefully that will
continue to allow adoption to proceed gradually. We can-not recommend mining on
mainnet with it. It does not include an undo RPC command or an adjust fees,
and Peter says he has not implemented one yet.  Patches are welcome.

Specifically there were requests from vulnerable parties, which interestingly
included a site that knew they had bugs related to replacement but not
financial vulnerabilities, to put up a server on testnet to check wallet code.
The vulnerable requested to remain undisclosed. An additional consideration was
the upcoming anti-dust rules which are yet another example of why zero-conf is
so much more dangerous to accept than single-conf. Two of the people contacting
us brought up that issue in fact.

The code is on github:

https://github.com/petertodd/bitcoin/tree/replace-by-fee

and a replace-by-fee server operating on testnet is available at
testnet-replace-by-fee.bitcoin.petertodd.org To test you will need to use the
raw transaction API and manually create the replacement transaction. Do note
that your wallet will retain the existing one and no mechanism yet exists to
delete the old transaction from your wallet. Again, a certain amount of
cludgyness to this is intentional to discourage premature non-testing use.


Regarding the reward, I've decided Peter will collect the full amount even
though the work is not %100 complete (the mempool aspect) due to his concern
about staging an implementation properly, working with vulnerable sites, and
overall genuine interest in the actual issues at hand rather than the reward.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRi3LeAAoJEEWCsU4mNhiPwscH/2CI0d3h/3jix3iyz2I9I8Sz
6nbP8eA01l9kzG37cH1rFAbt7C+fL/nardV4U1qmiwC0MN7NPpX6BFn5eQ2PUKbu
41+AnjgWicB2tnCC07ngboQ1JCeZ+RTfATepuMxEdWFBsc8ZQXs0apWS01FT+TDq
J/a7QkhNfTaAQzXyqmLp0TQO7/Z7ysmCftOhtGbfvfhF2o23BuphQiRVA9IOoUuj
Fgb5wrfQqJ8TjvXRXAUQ7SUlzfN9BlPxMkTc6NhbcgIpuq1Kb43mLoDl3s2irH4A
GtjRtobV5Cfozm1r+8KPtIYEoQoj0PqTjO5YMwD/vTaRfNzdS4Tse5LQLGT6Jug=
=M1mj
-END PGP SIGNATURE-

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] minor bitcoin-qt gripes moving BTC off specific key

2013-05-07 Thread Adam Back
At ZKS other than freedom network (ToR precursor) we had psueudonyms
associated with cookie managers.  The idea was you create pseudonyms for
different purposes to segregate your online linkability.  

medical
casual browsing
social media
private
work
true name

Seems to me that people are always going to make mistakes with individual
keys, even if the feature were there and accidentally link all their coin
sources together.  I presume people saw the analysis of the slush related
25k BTC theft, even seemingly the thief made possible slips while trying
presumably not to:

http://anonymity-in-bitcoin.blogspot.com/2011/07/bitcoin-is-not-anonymous.html

Does the client have any privacy algorithm (to minimise coin source cross
linking) to reach a given payment?

eg consider say I use social media, with a screen name; I collect reddit
tips etc; I pay them out to others, or use them to buy virtual goods
associated with the same purpose.  

It would be rather useful to help people achieve that, there is already the
ability to create addresses, label them.  But I think just for the GUI to
allow you to control which address the payment is from would be enough, it
doesnt seem like such a complicated concept.  And if people dont care, they
only need create one address.

Technically ZKS wasnt anonymous networking like ToR but pseudonymous
networking.  Multiple wallets for different unlinked purposes would be
somewhat analogous to ZKS freedom pseudonymous networking  cookie-jar. 
Because of the pseudonymity in ZKS misbehavers could be blocked by exit
nodes based on pseudonym.  Of course they can always create a new pseudonym
but then they lose their accumulated reputation.  You can even make people
pay for pseudonyms, as I recall users got 5 free pseudonyms but had to pay
for more.

(Though I have to admit the concensus after some years at ZKS was most end
users didnt understand what a pseudonym was!  They just wanted to be
private and have the computer magically solve it for them.)

If you want to simplify maybe you could consider normal (linked to AML
trading accounts, orders for physically delivered goods etc), and private
analogus to the private browsing mode in various browsers.  Maybe beyond 2
is an advanced feature but still available.

Adam

On Tue, May 07, 2013 at 03:19:50PM +0200, 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 priv key); or

I think the general solution here is providing a feature-reach Python RPC 
client,
which can do things like remember passwords, command history/tab completion,
perhaps even batch lookups of compound commands (getblock $(getblockhash X, for
example, ...). The naive RPC client built into bitcoind is not a good fit for
many features, as they can much more efficiently be developed outside of the
core binary,


 2. a button to import a private key (and option to transfer it to another
key - if you are not the sole controller the private key)

I'm quite opposed to any per-key fiddling in the GUI. This will inevitably lead
to (even more) people misunderstanding how wallets work and shooting themself 
in
the foot. I don't mind an expert mode (coin control) that enables such 
features,
but in general, we should for entire-wallet export and import rather than
individual keys.

Import  sweep an address is something else, that sounds safe to.

 3. a UX way to transfer BTC off a specific adress (eg choose from
address), rather than having to spend the entire wallet onto a new
address, just to get BTC off a specific address.  Doing it that way has
problems: creates more network traffic/bigger packets, higher fees (if
any transactions are young/low confirmation), and generally damages
privacy as all your funds end up linked.

This belongs in coin control, IMHO.

-- 
Pieter


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Adam Back
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
nodes and perhaps merchant interest and general good-will to lean on.

At ZKS I proposed we should fix the exit node issue (exit sees where you go
often in the clear) with an apache mod so the freedom aip tunnel (ToR tunnel
equiv) could terminate right on the web site.  (ZKS freedom network is long
dead but some of the ideas I think made it into ToR, eg I hope my end2end
forward anonymity idea that is implemented in Zach Brown's cebolla.)

Anyway I'd have about DNS being of limited value: bitcoins primary
vulnerability IMO (so far) is network attacks to induce network splits,
local lower difficulty to a point that a local and artificially isolated
area of the network can be fooled into accepting an orphan branch as the
one-true block chain, maybe even from node first install time.

(btw I notice most of the binaries and tar balls are not signed, nor served
from SSL - at least for linux).

Therefore as it applies to discover, you want to be able to discover peers
through as many network routes, and even steganographic protocols as
possible.  eg if a popular web server (say apache, or an apache module) put
a steganographic peer discover relay from its own network area, even for a
small bitcoin fee, that would help a lot.  (Steganographic in the SSL sense
would just mean that the peer seed request to /btcseed.cgi would not be
distinguishable to someone highly sophisticated on the inside of the router
all the peers traffic is routed through.  Eg you could easily do this with a
special magic header that overwrites something else or deletes some
unnecessary header so that the request at least is a standard size, and pad
the response to the same size as the site index.html or whatever).  If the
user picks a few SSL sites and cross checks (more for high value) a subset
of peers available on all and uses them as his seed that seems like a better
direction.

In that way an attacker cant control the network without denying service to
popular SSL sites, which would be a warning sign to users, or having at his
disposal a SSL sub-CA cert (like happened with diginotar and gmail).  You
may be able to pin CAs for popular sites.  Obviously to the extent you're
using SSL you want to generally use EDH for forward-secrecy.  And not RC4 :)

Probably anysite that accepts bitcoin payment will be happy to run such a
mod-bitcoin.


With ToR, it has a similar bootstrap problem to bitcoin.  So while that may
help it is also passing the buck, not necessarily solving the problem.  And
as I said I think its possible bitcoin has a higher assurance need in that
the attackers motivated my $$ might put more effort in than the odd
dictatorship trying to pay lip service to preventing people reading pages on
a blacklist.


Given the vulnerability of DNS to poisoning I would not trust it too much. 
I know its just a bootstrap, but ideally you dont want to bootstrap from a
known publicly vulnerable protocol - it invites DNS poison net splits
against new users.


Also to the extent that users local clock is under his control (with
unuthentcated NTP?) he should also treat sudden dramatic changes in luck
(deviations from 10min interval) as suspicious.  

Unfortunately at present because of the first past the post nature of the
bitcoin lottery, reduced variance hashcash cannot be used, so its hard to
infer too much even from quite significant luck changes.

Adam

On Mon, May 06, 2013 at 06:47:22PM +0200, Mike Hearn wrote:
 Speaking of, off-topic for this discussion, but in the future
 node-to-node communicate should be encrypted and signed

Yes, I'd like to do this. The threat isn't really ISPs which are
mostly trustable (the worst they normally do outside of places like
China is dick about with ads), the big threat is people who use
untrusted WiFi without realising and end up thinking they received
money when actually they were just connected to a hotspot running in
the attackers pocket. I'm rather expecting that kind of thing to
happen in future.

I think we can converge on the best solution with several iterations:

Iteration 1) Make it clear in the UI that if the phone is connected to
WiFi, payments from untrusted people should not be accepted. Currently
the Android app merely says the money won't be spendable for a few
minutes. It needs to communicate the may not exist aspect more
clearly. If you're connected via a cell tower, the existing wording is
fine - it's very unlikely your telco is trying to scam you in a
person-to-person transaction, traffic is encrypted and 3G+ connections
authenticate the network so you can't be MITMd except by your telco.
Assuming you have a good list of IPs, of course.

Iteration 2) Give nodes keys that appear in addr 

Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Adam Back
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, providing a ZKP.  If the node ever double spends a coin,
 it loses its reputation as the coin address is revealed.

Be careful not to mix up the concept of a relay node with someone
posessing Bitcoins. Node's don't spend coins, people/wallets do.

My comment was to say that a good behaviour bond for a relay node could be
put on an address that is defined as unspendable until such time as an
auditor can prove the node engaged in the undesired behaviour, at which
point the audit receives the payment as part of his proof.  Or until the
node ceases to operate.  Its a smart contract.

However I added to that, that it is still possible to do that while
preseving privacy, to point out that it is technically possible, for people
to be aware of in their mental toolbox, if it helps solve an otherwise
tricky problem.

So that would be a privacy preserving smart contract, the parties are
unknown, and unknowable (with unconditional security even), but still the
smart contract executes.  In some sense a privacy preserving smart-contract
is closer to the real point of Szabo's smart-contract idea because you cant
try to renege on the contract in a conventional court - because you cant
identify your counter-party.  Bitcoins privacy feature is fairly weak so
that is probably often not true.

Of course you'd probably need zerocoin to stand much chance of proving an
address private key of an unlinked coin was in the double-spend disclosed
attribute in the first place, and as we know zerocoin is not that efficient.

 Make the node identity expensive to obtain. For instance, construct PoW's
 including the node pubkey somehow,

that could be easily done with the work of creating a vanity address.  eg
address containing many leading 0s.

Adam

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)

2013-05-06 Thread Adam Back
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 isolated area of the network can be fooled into accepting an
 orphan branch as the one-true block chain,

It currently costs about 2016*25*$120 = six million dollars to
reduce the difficulty in your isolated fork by a factor of 4.

Well I take your point that you have to produce 2016 blocks, but at a lower
rate.  But that doesnt directly translate into my cost, I am thinking pure
network hacking.

Maybe I could hack a pool to co-opt it into my netsplit and do the work for
me, or segment enough of the network to have some miners in it, and they do
the work.

I am just thinking $500k/day worth of relatively perfect crime reward is a
lot of motivation for hacking networks.  Many routers home and even carrier
are vulnerable to people armed with cisco source code  0-days.  The
netsplit doesnt have to be geographical, nor even topological, nor even
particularly long-lived.

If you control enough people's network routing at a low enough level, you
dont even have to stop transactions, nor do any mining work, just stop
blocks from the netsplit crossing over, and hold that position for say a day
(if your netsplit has 1/24 of network hash rate in it, so the split gets 6
confirmations to reassure the victims) and let the miners do the work.  Do
enough transactions to do a big cash out (spend differently on the two
netsplits).  Obviously a big and human inattentive pool, dark-miner etc is
the ideal target to put into the netsplit to increase the power while
controlling less nodes.

Malware could do the same thing for clients, dont forget most are running
windows.  Malware could also start a miner if none present.

 maybe even from node first install time.

Protecting against that— making sure any such attack has to start from
a high difficulty— is, in my opinion, the biggest continued
justification for checkpoints.

Do you know if there is any downwards limit on difficulty?  I know it takes
going slow for a long and noticeable time, but I am just curious on the
theoretical limit.

 (btw I notice most of the binaries and tar balls are not signed, nor served
 from SSL - at least for linux).

They are signed.

I dont see the signatures.

http://bitcoin.org/en/download

I see no signatures for linux and none in the tarball.  There are some
public keys inside the tarball, thats it.  Also no SSL.  sourceforge support
SSL so you can download that.  But bitcoin.org doesnt even answer 443, and
the source forge link is HTTP.  But even if the sourceforge link was SSL one
should not serve an SSL download link from an HTTP page, any more than type
a password into an HTTPS form action on an HTTP page.  The attacker can just
redirect and the user doesnt know what is legitimate.

Consequently even if there is code signing on the windows exe, the user
doesnt know that, nor who they should be signed by, and as they are served
via HTTP, its bypassable.

I guess by far the easiest way to attack right now (at least linux users) is
just to change the binaries to create a user operated netsplit, or just have
all their wallets empty to you via a mix once the amount gets interesting.

(All attacks hypothetical of course - I'm actually a white-hat type of
person).

Adam

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development