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

2015-06-16 Thread Gregory Maxwell
On Wed, Jun 17, 2015 at 1:00 AM, Mark Friedenbach m...@friedenbach.org wrote:
 Given that we have had more than two weeks of public discussion, code is
 available and reviewed, and several community identified issues resolved, I
 would like to formally request a BIP number be assigned for this work. Will
 the BIP editor be so kind as to do so to allow the BIP consensus process to
 proceed?

BIP 68, unless you have objections.

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


Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

2015-06-14 Thread Gregory Maxwell
On Sat, Jun 6, 2015 at 4:42 AM, Rusty Russell ru...@rustcorp.com.au wrote:
 Title: Canonical Input and Output Ordering
 Author: Rusty Russell ru...@rustcorp.com.au
 Discussions-To: Bitcoin Dev bitcoin-development@lists.sourceforge.net
 Status: Draft
 Type: Standards Track
 Created: 2015-06-06

 Abstract

 This BIP provides a canonical ordering of inputs and outputs when
 creating transactions.

 Motivation

 Most bitcoin wallet implementations randomize the outputs of
 transactions they create to avoid trivial linkage analysis (especially
 change outputs), however implementations have made mistakes in this area
 in the past.

 Using a canonical ordering has the same effect, but is simpler, more
 obvious if incorrect, and can eventually be enforced by IsStandard() and
 even a soft-fork to enforce it.

 Specification

 Inputs should be ordered like so:
 index (lower value first)
 txid (little endian order, lower byte first)

 Outputs should be ordered like so:
 amount (lower value first)
 script (starting from first byte, lower byte first, shorter wins)

 Rationale

 Any single wallet is already free to implement this, but if other
 wallets do not it would reduce privacy by making those transactions
 stand out.  Thus a BIP is appropriate, especially if this were to
 become an IsStandard() rule once widely adopted.

 Because integers are fast to compare, they're sorted first, before the
 lexographical ordering.

 The other input fields do not influence the sort order, as any valid
 transactions cannot have two inputs with the same index and txid.

 Reference Implementation

 https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering


Sorry I wasn't a part of the IRC conversation where this was first
discussed, though I'm very happy to see a concrete implementation
along with the proposal.

I'm not a great fan of this proposal for two reasons: The first is
that the strict ordering requirements is incompatible with future
soft-forks that may expose additional ordering constraints. Today we
have _SINGLE, which as noted this interacts with poorly, but there
have been other constraints proposed that this would also interact
with poorly.

The second is that even absent consensus rules there may be invisible
constraints in systems-- e.g. hardware wallets that sign top down, or
future transaction covenants that have constraints about ordering,  or
proof systems that use (yuck) midstate compression for efficiency.
Right now, with random ordering these applications are fairly
indistinguishable from other random uses (since their imposed order
could come about by chance) but if everyone else was ordered, even if
wasn't enforced.. these would be highly distinguishable. Which would
be unfortunate.  Worse, if most transactions are ordered the few that
aren't could be mishandled (which is, I assume, part of why you
propose requiring the ordering-- but I think the soft fork constraints
there hurt it more).

[Sorry for the delay in stating my views here; I wanted to talk them
over with a few other people to see if I was just being stupid and
misunderstanding the proposal]

I think perhaps the motivations here are understated. We have not seen
any massive deployments of accidentally broken ordering that I'm aware
of-- and an implementation that got this wrong in a harmful way would
likely make far more fatal mistakes (e.g. non random private keys).
As an alternative to this proposal the ordering can be privately
derandomized in the same way DSA is, to avoid the need for an actual
number source.  If getting the randomness right were really the only
motivation, I'd suggest we propose a simple derandomized randomization
algorithm--- e.g. take the order from (H(input ids||client secret)).

I think there is actually an unstated motivation also driving this
(and the other) proposal related to collaborative transaction systems
like coinjoins or micropayment channels; where multiple clients need
to agree on the same ordering. Is this the case? If so we should
probably talk through some of the requirements there and see if there
isn't a better way to address it.

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


Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

2015-06-14 Thread Gregory Maxwell
On Mon, Jun 8, 2015 at 9:25 PM, Danny Thorpe danny.tho...@gmail.com wrote:
 Recommending sorting of the inputs and outputs as a best practice is fine
 (and better than random, IMO), but not as part of IsStandard() or consensus
 rules.  There are cases where the order of the inputs and outputs is
 significant.

Is it your opinion that its fine if the result is that it makes the
usage trivially distinguishable e.g. where it might be subjected to
higher tx fees, or might break some software which incorrectly expects
all transactions to be ordered since most are?

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


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

2015-06-14 Thread Gregory Maxwell
On Sun, Jun 14, 2015 at 10:12 AM, Warren Togami Jr. wtog...@gmail.com wrote:
 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
 neutrality, they seem to be suitable as a competent host.  They have

I support this proposal.

But for clarity sake, we should recognize that Linux Foundation isn't
a charity chartered to act in the public good, is a trade organization
which acts in the commercial interest of it's membership.

I do not think this presents a problem: LF's membership's interests
are not at odds with ours currently, and aren't likely to become so
(doubly so with sourceforge as the comparison point). We are, after
all, just talking about a development mailing list; in the unlikely
case that there were issues in the future it could be changed, and
they've demonstrated considerable competence at this kind of operation
as well, and I would be grateful to have their support.  I mention it
only because the 'foundation' name sometimes carries the charity
confusion, and to be clear that I think the stakes on this matter are
small enough that it doesn't require a careful weighing of interests.
These concerns may matter for other initiatives but as you note, LF
has zero stake beyond the general support of the open source
ecosystem.

I do not believe it would be wise to delete the SF account, at least
while there are many active links to it. As it might well be recreated
to 'mirror' things as a 'service' to those following the old links.

I also agree with Jeff's comments wrt, bitcoin-security.

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


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

2015-05-27 Thread Gregory Maxwell
On Wed, May 27, 2015 at 7:47 AM, Peter Todd p...@petertodd.org wrote:
 Equally this proposal is no more consensus enforcement than simply
 increasing the fee (and possibly decreasing the absolute nLockTime) for

You've misunderstood it, I think-- Functionally nlocktime but relative
to each txin's height.

But the construction gives the sequence numbers a rational meaning,
they count down the earliest position a transaction can be included.
(e.g. the highest possible sequence number can be included any time
the inputs are included) the next lower sequence number can only be
included one block later than the input its assigned to is included,
the next lower one block beyond that. All consensus enforced.   A
miner could opt to not include the higher sequence number (which is
the only one of the set which it _can_ include) it the hopes of
collecting more fees later on the next block, similar to how someone
could ignore an eligible locked transaction in the hopes that a future
double spend will be more profitable (and that it'll enjoy that
profit) but in both cases it must take nothing at all this block, and
risk being cut off by someone else (and, of course, nothing requires
users use sequence numbers only one apart...).

It makes sequence numbers work exactly like you'd expect-- within the
bounds of whats possible in a decentralized system.  At the same time,
all it is ... is relative nlocktime.

--
___
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-27 Thread Gregory Maxwell
On Wed, May 27, 2015 at 9:59 PM, Mike Hearn m...@plan99.net wrote:
 I wrote an article that explains the hashing assurance contract concept:

 https://medium.com/@octskyward/hashing-7d04a887acc8

 (it doesn't contain an in depth protocol description)

The prior (and seemingly this) assurance contract proposals pay the
miners who mines a chain supportive of your interests and miners whom
mine against your interests identically.

There is already a mechanism built into Bitcoin for paying for
security which doesn't have this problem, and which mitigates the
common action problem of people just sitting around for other people
to pay for security: transaction fees. Fixing the problem with
assurance contracts effectively makes them end up working like
transaction fees in any case.  Considering the near-failure in just
keeping development funded, I'm not sure where the believe this this
model will be workable comes from; in particular unlike a lighthouse
(but like development) security is ongoing and not primarily a fixed
one time cost. I note that many existing crowdfunding platforms
(including your own) do not do ongoing costs with this kind of binary
contract.

Also work reminding people that mining per-contract is a long
identified existential risk to Bitcoin which has been seeing more
analysis lately:
http://www.jbonneau.com/doc/BFGKN14-bitcoin_bribery.pdf

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


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

2015-05-26 Thread Gregory Maxwell
On Tue, May 26, 2015 at 5:54 PM, Tom Harding t...@thinlink.com wrote:
  It's not difficult to
 imagine real-world consequences to not having contributed to the
 transaction.

I'm having a hard time. Can you help me understand a specific case
where this makes a difference.

It appears to be a gratuitous requirement;  if I have another unused
input that happens to be larger by the required fee-- why not just use
it?

The inherent malleability of signatures makes it unreliable to depend
on the signature content of a transaction until its good and buried,
regardless. And an inability to replace an input means you could not
RBF for additional fees without taking change in more cases; there
ought to be a benefit to that.

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


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

2015-05-26 Thread Gregory Maxwell
On Tue, May 26, 2015 at 11:00 PM, Tom Harding t...@thinlink.com wrote:
 The bitcoin transaction is part of a real-world deal with unknown
 connections to the other parts

I'm having a hard time parsing this.  You might as well say that its
part of a weeblix for how informative it is, since you've not defined
it.

 not the case if paying parties are kicked out of the deal, and possibly
 don't learn about it right away.

The signatures of a transaction can always be changed any any time,
including by the miner, as they're not signed.

 A subset of parties to an Armory simulfunding transaction (an actual
 multi-input use case) could replace one signer's input after they broadcast
 it.

They can already do this.

 Maybe the
 receiver cares where he is paid from or is basing a subsequent decision on
 it.  Maybe a new output is being added, whose presence makes the transaction
 less likely to be confirmed quickly, with that speed affecting the business.

The RBF behavior always moves in the direction of more prefered or
otherwise the node would not switch to the replacement. Petertodd
should perhaps make that more clear.

But your maybes are what I was asking you to clarify. You said it
wasn't hard to imagine; so I was asking for specific clarification.

 With Kalle's Proof of Payment proposed standard, one payer in a two-input
 transaction could decide to boot the other, and claim the concert tickets
 all for himself.  The fact that he pays is not the only consideration in the
 real world -- what if these are the last 2 tickets?

They can already do that.

 I'd argue that changing how an input is signed doesn't change the deal.  For
 example if a different 2 of 3 multisig participants sign, those 3 people
 gave up that level of control when they created the multisig.

Then why do you not argue that changing the input set does not change
the weeblix?

Why is one case of writing out a participant different that the other
case of writing out a participant?

 Replacement is new - we have a choice what kind of warnings we need to give
 to signers of multi-input transactions.  IMHO we should avoid needing a
 stronger warning than is already needed for 0-conf.

How could a _stronger_ warning be required?

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


Re: [Bitcoin-development] Proposed additional options for pruned nodes

2015-05-12 Thread Gregory Maxwell
It's a little frustrating to see this just repeated without even
paying attention to the desirable characteristics from the prior
discussions.

Summarizing from memory:

(0) Block coverage should have locality; historical blocks are
(almost) always needed in contiguous ranges.   Having random peers
with totally random blocks would be horrific for performance; as you'd
have to hunt down a working peer and make a connection for each block
with high probability.

(1) Block storage on nodes with a fraction of the history should not
depend on believing random peers; because listening to peers can
easily create attacks (e.g. someone could break the network; by
convincing nodes to become unbalanced) and not useful-- it's not like
the blockchain is substantially different for anyone; if you're to the
point of needing to know coverage to fill then something is wrong.
Gaps would be handled by archive nodes, so there is no reason to
increase vulnerability by doing anything but behaving uniformly.

(2) The decision to contact a node should need O(1) communications,
not just because of the delay of chasing around just to find who has
someone; but because that chasing process usually makes the process
_highly_ sybil vulnerable.

(3) The expression of what blocks a node has should be compact (e.g.
not a dense list of blocks) so it can be rumored efficiently.

(4) Figuring out what block (ranges) a peer has given should be
computationally efficient.

(5) The communication about what blocks a node has should be compact.

(6) The coverage created by the network should be uniform, and should
remain uniform as the blockchain grows; ideally it you shouldn't need
to update your state to know what blocks a peer will store in the
future, assuming that it doesn't change the amount of data its
planning to use. (What Tier Nolan proposes sounds like it fails this
point)

(7) Growth of the blockchain shouldn't cause much (or any) need to
refetch old blocks.

I've previously proposed schemes which come close but fail one of the above.

(e.g. a scheme based on reservoir sampling that gives uniform
selection of contiguous ranges, communicating only 64 bits of data to
know what blocks a node claims to have, remaining totally uniform as
the chain grows, without any need to refetch -- but needs O(height)
work to figure out what blocks a peer has from the data it
communicated.;   or another scheme based on consistent hashes that has
log(height) computation; but sometimes may result in a node needing to
go refetch an old block range it previously didn't store-- creating
re-balancing traffic.)

So far something that meets all those criteria (and/or whatever ones
I'm not remembering) has not been discovered; but I don't really think
much time has been spent on it. I think its very likely possible.

--
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] Proposed additional options for pruned nodes

2015-05-12 Thread Gregory Maxwell
On Tue, May 12, 2015 at 8:10 PM, Jeff Garzik jgar...@bitpay.com wrote:
 True.  Part of the issue rests on the block sync horizon/cliff.  There is a
 value X which is the average number of blocks the 90th percentile of nodes
 need in order to sync.  It is sufficient for the [semi-]pruned nodes to keep
 X blocks, after which nodes must fall back to archive nodes for older data.


Prior discussion had things like the definition of pruned means you
have and will serve at least the last 288 from your tip (which is
what I put in the pruned service bip text); and another flag for I
have at least the last 2016.  (2016 should be reevaluated-- it was
just a round number near where sipa's old data showed the fetch
probability flatlined.

But that data was old,  but what it showed that the probability of a
block being fetched vs depth looked like a exponential drop-off (I
think with a 50% at 3-ish days); plus a constant low probability.
Which is probably what we should have expected.

 There was even a more radical suggestion years ago - refuse to sync if too
 old (2 weeks?), and force the user to download ancient data via torrent.

I'm not fond of this; it makes the system dependent on centralized
services (e.g. trackers and sources of torrents). A torrent also
cannot very efficiently handle fractional copies; cannot efficiently
grow over time. Bitcoin should be complete-- plus, many nodes already
have the data.

--
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] Proposed alternatives to the 20MB step function

2015-05-10 Thread Gregory Maxwell
On Sun, May 10, 2015 at 9:21 PM, Gavin Andresen gavinandre...@gmail.com wrote:
 a while I think any algorithm that ties difficulty to block size is just a
 complicated way of dictating minimum fees.

Thats not the long term effect or the motivation-- what you're seeing
is that the subsidy gets in the way here.  Consider how the procedure
behaves with subsidy being negligible compared to fees.   What it
accomplishes in that case is that it incentivizes increasing the size
until the marginal value to miners of the transaction-data being
left out is not enormously smaller than the value of the data in the
block on average.  Value in quotes because it's blind to the fees
the transaction claims.

With a large subsidy, the marginal value of the first byte in the
block is HUGE; and so that pushes up the average-- and creates the
base fee effect that you're looking at.  It's not that anyone is
picking a fee there, it's that someone picked the subsidy there.  :)
As the subsidy goes down the only thing fees are relative to is fees.

An earlier version of the proposal took subsidy out of the picture
completely by increasing it linearly with the increased difficulty;
but that creates additional complexity both to implement and to
explain to people (e.g. that the setup doesn't change the supply of
coins); ... I suppose without it that starting disadvantage parameter
(the offset that reduces the size if you're indifferent) needs to be
much smaller, unfortunately.

--
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] A way to create a fee market even without a block size limit (2013)

2015-05-10 Thread Gregory Maxwell
On Sun, May 10, 2015 at 8:45 PM, Sergio Lerner
sergioler...@certimix.com wrote:
 Can the system by gamed?

Users can pay fees or a portion of fees out of band to miner(s); this
is undetectable to the network.

It's also behavior that miners have engaged in since at least 2011 (in
two forms;  treating transactions that paid them directly via outputs
as having that much more in fees;  and taking contracts for fast
processing for identified transactions (e.g. address matching or via
an API) e.g. I'll pay you x at the end of the month for each of my
transactions you process, you can poll this API. I'm aware of at
least two companies having had this arrangement with miners).

I think what you suggested then just further rewards this behavior as
it allows bypassing your controls.-- I suspect generally any scheme
the looks at the fee values has this property.

--
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] Proposed alternatives to the 20MB step function

2015-05-08 Thread Gregory Maxwell
On Fri, May 8, 2015 at 8:33 PM, Mark Friedenbach m...@friedenbach.org wrote:
 These rules create an incentive environment where raising the block size has
 a real cost associated with it: a more difficult hashcash target for the
 same subsidy reward. For rational miners that cost must be counter-balanced
 by additional fees provided in the larger block. This allows block size to
 increase, but only within the confines of a self-supporting fee economy.

 When the subsidy goes away or is reduced to an insignificant fraction of the
 block reward, this incentive structure goes away. Hopefully at that time we
 would have sufficient information to soft-fork set a hard block size
 maximum. But in the mean time, the block size limit controller constrains
 the maximum allowed block size to be within a range supported by fees on the
 network, providing an emergency relief valve that we can be assured will
 only be used at significant cost.

Though I'm a fan of this class of techniques(*) and think using something
in this space is strictly superior to not, and I think it makes larger
sizes safer long term;  I do not think it adequately obviates the need
for a hard upper limit for two reasons:

(1) for software engineering and operational reasons it is very
difficult to develop, test for, or provision for something without
knowing limits. There would in fact be hard limits on real deployments
but they'd be opaque to their operators and you could easily imagine
the network forking by surprise as hosts crossed those limits.

(2)  At best this approach mitigates the collective action problem between
miners around fees;  it does not correct the incentive alignment between
miners and everyone else (miners can afford huge node costs because they
have income; but the full-node-using-users that need to exist in plenty
to keep miners honest do not), or the centralization pressures (N miners
can reduce their storage/bandwidth/cpu costs N fold by centralizing).

A dynamic limit can be combined with a hard upper to at least be no
worse than a hard upper with respect to those two points.


Another related point which has been tendered before but seems to have
been ignored is that changing how the size limit is computed can help
better align incentives and thus reduce risk.  E.g. a major cost to the
network is the UTXO impact of transactions, but since the limit is blind
to UTXO impact a miner would gain less income if substantially factoring
UTXO impact into its fee calculations; and without fee impact users have
little reason to optimize their UTXO behavior.   This can be corrected
by augmenting the size used for limit calculations.   An example would
be tx_size = MAX( real_size  1,  real_size + 4*utxo_created_size -
3*utxo_consumed_size).   The reason for the MAX is so that a block
which cleaned a bunch of big UTXO could not break software by being
super large, the utxo_consumed basically lets you credit your fees by
cleaning the utxo set; but since you get less credit than you cost the
pressure should be downward but not hugely so. The 1/2, 4, 3 I regard
as parameters which I don't have very strong opinions on which could be
set based on observations in the network today (e.g. adjusted so that a
normal cleaning transaction can hit the minimum size).  One way to think
about this is that it makes it so that every output you create prepays
the transaction fees needed to spend it by shifting space from the
current block to a future block. The fact that the prepayment is not
perfectly efficient reduces the incentive for miners to create lots of
extra outputs when they have room left in their block in order to store
space to use later [an issue that is potentially less of a concern with a
dynamic size limit].  With the right parameters there would never be such
at thing as a dust output (one which costs more to spend than its worth).

(likewise the sigops limit should be counted correctly and turned into
size augmentation (ones that get run by the txn); which would greatly
simplify selection rules: maximize income within a single scalar limit)

(*) I believe my currently favored formulation of general dynamic control
idea is that each miner expresses in their coinbase a preferred size
between some minimum (e.g. 500k) and the miner's effective-maximum;
the actual block size can be up to the effective maximum even if the
preference is lower (you're not forced to make a lower block because you
stated you wished the limit were lower).  There is a computed maximum
which is the 33-rd percentile of the last 2016 coinbase preferences
minus computed_max/52 (rounding up to 1) bytes-- or 500k if thats
larger. The effective maximum is X bytes more, where X on the range
[0, computed_maximum] e.g. the miner can double the size of their
block at most. If X  0, then the miners must also reach a target
F(x/computed_maximum) times the bits-difficulty; with F(x) = x^2+1  ---
so the maximum penalty is 2, with a quadratic shape;  for a given mempool

Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41

2015-05-08 Thread Gregory Maxwell
On Sat, May 9, 2015 at 12:00 AM, Damian Gomez dgomez1...@gmail.com wrote:

 ...of the following:

  the DH_GENERATION would in effect calculate the reponses for a total
 overage of the public component, by addding a ternary option in the actual
 DH key (which I have attached to sse if you can iunderstand my logic)
[snip code]

Intriguing; and certainly a change of the normal pace around here.

 where w represents the weight of the total number of semantical
 constraints that an idivdual has expressed throught emotivoe packets that I
 am working on (implementation os difficutlt).  I think this is the
 appropriate route to implemeting a greating block size that will be used in
 preventing interception of bundled informations and replace value.  Client
 side implmentation will cut down transaction fees for the additional 264 bit
 implementation and greatly reduce need for ewallet providers to do so.

In these posts I am reminded of and sense some qualitative
similarities with a 2012 proposal by Mr. NASDAQEnema of Bitcointalk
with respect to multigenerational token architectures. In particula,r
your AES ModuleK Hashcodes (especially in light of Winternitz
compression) may constitute an L_2 norm attractor similar to the
motherbase birthpoint metric presented in that prior work.  Rethaw and
I provided a number of points for consideration which may be equally
applicable to your work:
https://bitcointalk.org/index.php?topic=57253.msg682056#msg682056

Your invocation of emotive packets suggests that you may be a
colleague of Mr. Virtuli Beatnik?  While not (yet) recognized as a
star developer himself; his eloquent language and his mastery of skb
crypto-calculus and differential-kernel number-ontologies demonstrated
in his latest publication ( https://archive.org/details/EtherealVerses
) makes me think that he'd be an ideal collaborator for your work in
this area.

--
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] Block Size Increase

2015-05-06 Thread Gregory Maxwell
On Wed, May 6, 2015 at 10:12 PM, Matt Corallo bitcoin-l...@bluematt.me
wrote:  Recently there has been a flurry of posts by Gavin at 
http://gavinandresen.svbtle.com/ which advocate strongly for increasing 
the maximum block size. However, there hasnt been any discussion on this 
mailing list in several years as far as I can tell.

Thanks Matt; I was actually really confused by this sudden push with
not a word here or on Github--so much so that I responded on Reddit to
people pointing to commits in Gavin's personal repository saying they
were reading too much into it.

So please forgive me for the more than typical disorganization in this
message; I've been caught a bit flatfooted on this and I'm trying to
catch up. I'm juggling a fair amount of sudden pressure in my mailbox,
and trying to navigate complex discussions in about eight different
forums concurrently.

There have been about a kazillion pages of discussion elsewhere
(e.g. public IRC and Bitcointalk; private discussions in the past),
not all of which is well known, and I can't hope to summarize even a
tiny fraction of it in a single message-- but that's no reason to not
start on it.

 Block size is a question to which there is no answer, but which 
certainly has a LOT of technical tradeoffs to consider.

There are several orthogonal angles from which block size is a concern
(both increases and non-increases). Most of them have subtle implications
and each are worth its own research paper or six, so it can be difficult
to only touch them slightly without creating a gish gallop that is hard
to respond to.

We're talking about tuning one of the fundamental scarcities of the
Bitcoin Economy and cryptosystem--leaving the comfort of rule by
math and venturing into the space of political decisions; elsewhere
you'd expect to see really in-depth neutral analysis of the risks and
tradeoffs, technically and economically.  And make no mistake: there
are real tradeoffs here, though we don't know their exact contours.

Fundamentally this question exposes ideological differences between people
interested in Bitcoin.  Is Bitcoin more of a digital gold or is it more
of a competitor to Square?  Is Bitcoin something that should improve
personal and commercial autonomy from central banks?  From commercial
banks? Or from just the existing status-quo commercial banks?   What are
people's fundamental rights with Bitcoin?  Do participants have a
right to mine? How much control should third parties have over their
transactions?  How much security must be provided? Is there a deadline
for world domination or bust?  Is Bitcoin only for the developed world?
Must it be totally limited by the most impoverished parts of the world?

Bitcoin exists at the intersection of many somewhat overlapping belief
systems--and people of many views can find that Bitcoin meets their
needs even when they don't completely agree politically.  When Bitcoin
is changed fundamentally, via a hard fork, to have different properties,
the change can create winners or losers (if nothing else, then in terms
of the kind of ideology supported by it).

There are non-trivial number of people who hold extremes on any of
these general belief patterns; Even among the core developers there is
not a consensus on Bitcoin's optimal role in society and the commercial
marketplace.

To make it clear how broad the views go, even without getting into
monetary policy... some people even argue that Bitcoin should act
as censor-resistant storage system for outlawed content; -- I think
this view is unsound, not achievable with the technology, and largely
incompatible with Bitcoin's use as a money (because it potentially
creates an externalized legal/harassment liability for node operators);
but these are my personal value judgments; the view is earnestly held
by more than a few; and that's a group that certainly wants the largest
possible blocksizes (though even then that won't be enough).

The subject is complicated even more purely on the technical side
by the fact that Bitcoin has a layered security model which is not
completely defined or understood: Bitcoin is secure if a majority of
hashrate is honest (where honesty is a technical term which means
follows the right rules without fail, even at a loss), but why might
it be honest? That sends us into complex economic and social arguments,
and the security thresholds start becoming worse when we assume some
miners are economically rational instead of honest.

 increase in the near future. Long-term incentive compatibility requires
 that there be some fee pressure, and that blocks be relatively 
consistently full or very nearly full. What we see today are

To elaborate, in my view there is a at least a two fold concern on this
particular (Long term Mining incentives) front:

One is that the long-held argument is that security of the Bitcoin system
in the long term depends on fee income funding autonomous, anonymous,
decentralized miners profitably applying enough 

Re: [Bitcoin-development] Reusable payment codes

2015-04-24 Thread Gregory Maxwell
On Fri, Apr 24, 2015 at 8:00 PM, Justus Ranvier
justus.ranv...@monetas.net wrote:
 https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki

 This link contains an RFC for a new type of Bitcoin address called a
 payment code

 Payment codes are SPV-friendly alternatives to DarkWallet-style stealth
 addresses which provide useful features such as positively identifying
 senders to recipients and automatically providing for transaction refunds.

So this requires making dust payments to a constantly reused address
in order to (ab)use the blockchain as a messaging layer.

Indeed, this is more SPV compatible; but it seems likely to me that
_in practice_ it would almost completely undermine the privacy the
idea hoped to provide; because you'd have an observable linkage to a
highly reused address.

It would also more than double the data sent for the application where
'stealth addresses' are most important: one-time anonymous donations
(in other contexts; you have two way communication between the
participants, and so you can just given them a one off address without
singling in the public network.)

 Alice selects the first exposed public key of the first input of the 
 transaction

So this creates strong binding that we would really strongly like to
avoid in the network; basically what this says is that You can only
pay to person X if you use scheme Y for your own Bitcoins-- who says
any of your inputs have a ECDH pubkey at all? Of if they do, who says
its one that you have access to the private key for for use in this
scheme (e.g. it could be in a HSM that only signs according to a
policy).   We should avoid creating txout features that restrict what
kind of scriptPubkey the sender can use, or otherwise we'll never be
able to deploy new signature features. (We can see how long P2SH took
to gain adoption because some wallets refused to implement sending to
it, even though doing so was trivial).

This kind of binding was intentionally designed out of the stealth
address proposal;  I think this scheme can be made to work without any
increase in size by reusing the payment code as the ephemeral public
key (or actually being substantially smaller e.g. use the shared
secret as the chain code, but I should give it more thought)

Also, SPV wallets do not need to have access to the public keys being
spent by a particular transaction they learn about; providing that
access is fundamentally expensive and pushes things back towards
centralization.

 in uncompressed DER format

This is fundamentally more expensive to compute; please don't specify
uncompressed.

This appears incompatible with multisignature; which is unfortunate.

I do very much like the fact that this scheme establishes a shared
chain once and then doesn't need to reestablish; this was one of the
improvements I wanted for the stealth address.

I'm disappointed that there isn't any thought given to solving the
scanning privacy without forcing non-private pure-overhead messaging
transactions on heavily reused addresses. Are you aware of the IBE
approach that allows someone to request a third party scan for them
with block by block control over their delegation of scanning?

--
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] 75%/95% threshold for transaction versions

2015-04-24 Thread Gregory Maxwell
On Fri, Apr 24, 2015 at 7:58 PM, William Swanson swanson...@gmail.com wrote:
 On Thu, Apr 16, 2015 at 9:12 AM, s7r s...@sky-ip.org wrote:
 Thanks for your reply. I agree. Allen has a good point in the previous
 email too, so the suggestion might not fix anything and complicate things.

 The BIP 62 approach to malleability isn't the only option. Another
 approach is to sign the transaction in such a way that the input
 txid's are allowed to change without invalidating the signatures. That
 way, if malleability happens, you just adjust you transaction to match
 and re-broadcast. That proposal is here:

This is not a free choice. There are several concerns, from mild to
severe, that arise when you do not sign enough.

In particular not covering the ID allows for transaction replay which
can result in monetary losses far more severe than any possible
mishandling of malleability could result in. Byzantine attackers can
costlessly replay your old transactions any time anyone reuses an
address, even accidentally (which cannot be easily prevented since
they can race).

Other fun effects also show up like being able to backwards compute
signatures to result in a kind of limited covenant- coins which can
only be spent a particular way which has some implications for
fungibility. (See here for a discussion in general of covenants:
https://bitcointalk.org/index.php?topic=278122.0)

There are no free lunches;  the proposal linked to there is itself a
game of wack-a-mole with assorted masking flags; many of which we have
no notion of if they're useful for any particular application(s); and
it doesn't provide tools to address the replay issue; and in order to
'improve' malleability via that mechanism you must always mask out the
inputs completely; meaning you'd always be exposed to replay and not
just in specialized 'contract' applications where there won't be
address reuse could be a strong assumption enforced by the
application.

--
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] Build your own nHashType

2015-04-14 Thread Gregory Maxwell
On Wed, Apr 8, 2015 at 7:50 PM, Stephen Morse
stephencalebmo...@gmail.com wrote:
 Seeking feedback on a proposal that will allow a transaction signer to
 explicitly specify what is to be serialized for the signature hash. The
 basic idea is to make the nHashType general enough that we won't need a new
 sighash flag every time a new use case comes up.

 If implemented into bitcoin (via a soft fork), this would make malleability
 almost a non-issue (the TXID referenced by inputs just need to be updated
 previous TX changes) and would enable hardware wallets to securely sign
 without needing to download/process each transaction it spends from.

I'm not sure if I'm super fond of that particular non-programmatic but
many options approach; It sort of has the problem that there are
relatively few useful options that don't rapidly extend into a choose
your own adventure with too many options to count; so you take a
complexity penalty perhaps without a matching functionality payoff.

but thats not why I'm commenting...

I wonder if anyone noticed that any sighash masking that eliminates
the txin txid enables covenants?

Covenants are payments which constrain their future payments (like
deed covenants), I've written about them in the past
https://bitcointalk.org/index.php?topic=278122.0  ... they can
sometimes be pretty useful but are also potentially a irritating hit
to fungibility, at least if used stupidly.

the approach here is that you make the scriptpubkey contain [push:
0x30, 0x06, 0x02, 0x01, 0x04, 0x02, 0x01, 0x04, flags] [push pubkey
resulting from pubkey recovery] OP_CHECKSIG  and set the flags to
match only the things you want to enforce in the spending transaction
hash them up and recover the EC public point.   You can think of that
construct as giving a you a OP_MASKED_TRANSACTION_HASH_EQUALS  ... the
recovered pubkey is just a kind of message hash, though a weird and
expensive to compute one.

I don't currently see how to get a perpetual covenant out of it-- e.g.
a coin that anyone can spend, but only to its same scriptpubkey, (the
obvious way requires the ability to be able to checksig stuff on the
stack) though I wouldn't be shocked if it were possible with a
sufficiently complex sighash flag and nothing else.

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] PAPER: New algorithm for the discrete logarithm problem on elliptic curves

2015-04-07 Thread Gregory Maxwell
On Tue, Apr 7, 2015 at 9:32 PM, Jean-Paul Kogelman
jeanpaulkogel...@me.com wrote:
 https://eprint.iacr.org/2015/310.pdf

http://www.reddit.com/r/Bitcoin/comments/31rcuo/new_algorithm_for_the_discrete_logarithm_problem/cq4b52u

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Address Expiration to Prevent Reuse

2015-03-26 Thread Gregory Maxwell
On Fri, Mar 27, 2015 at 1:51 AM, Thy Shizzle thyshiz...@outlook.com wrote:
 Yes I agree, also there is talks about a government body I know of warming
 to bitcoin by issuing addresses for use by a business and then all
 transactions can be tracked for that business entity. This is one proposal I
 saw put forward by a country specific bitcoin group to their government and
 so not allowing address reuse would neuter that :(

I hope you're mistaken, because that would be a serious attack on the
design of bitcoin, which obtains privacy and fungibility, both
essential properties of any money like good, almost exclusively
through avoiding reuse.

[What business would use a money where all their competition can see
their sales and identify their customers, where their customers can
track their margins and suppliers? What individuals would use a system
where their inlaws could criticize their spending? Where their
landlord knows they got a raise, or where thieves know their net
worth?]

Though no one here is currently suggesting blocking reuse as a network
rule, the reasonable and expected response to what you're suggesting
would be to do so.

If some community wishes to choose not to use Bitcoin, great, but they
don't get to simply choose to screw up its utility for all the other
users.

You should advise this country specific bitcoin group that they
shouldn't speak for the users of a system which they clearly do not
understand.

--
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] Address Expiration to Prevent Reuse

2015-03-26 Thread Gregory Maxwell
On Thu, Mar 26, 2015 at 8:38 PM, Tom Harding t...@thinlink.com wrote:
 I addressed that by limiting the duplicate check to an X-block segment.  X
 is hard-coded in this simple scheme (X=144  = 1-day addresses).  You
 could picture a selectable expiration duration too.

If its to be heuristic in any case why not make it a client feature
instead of a consensus rule?

If someone wants to bypass anything they always can, thats what I mean
by hide their payment under a rock

E.g. I can take your pubkey, add G to it (adding 1 to the private
key), strip off the time limits, and send the funds.

What do you mean I didn't pay you? I wrote a check. locked it in a
safe, and burred it in your back garden.

The answer to this can only be that payment is only tendered when its
made _exactly_ to the payee's specifications.

If someone violates the specifications all they're doing is destroying
coins. Nothing can stop people from destroying coins...

Which is why a simpler, safer, client enforced behavior is probably
preferable. Someone who wants to go hack their client to make a
payment that isn't according to the payee will have to live with the
results, esp. as we can't prevent that in a strong sense.

--
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] Address Expiration to Prevent Reuse

2015-03-26 Thread Gregory Maxwell
On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding t...@thinlink.com wrote:
 I should have been clearer that the motivation for address expiration is to
 reduce the rate of increase of the massive pile of bitcoin addresses out
 there which have to be monitored forever for future payments.  It could make
 a significant dent if something like this worked, and were used by default
 someday.

Great, that can be accomplished by simply encoding an expiration into
the address people are using and specifying that clients enforce it.

--
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] Address Expiration to Prevent Reuse

2015-03-26 Thread Gregory Maxwell
On Thu, Mar 26, 2015 at 10:28 PM, s7r s...@sky-ip.org wrote:
 This should not be enforced by default.

No one suggested _anything_ like that. Please save the concern for
someplace its actually applicable.

 I know it's not recommended to use the same pubkey more than once, but
 the protocol was not designed this way.

For a point of pedantry, the protocol actually was designed that way
and in the initial versions of the software there was actually no user
exposed mechanism to reuse a scriptPubkey no matter how hard you
tried.

--
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] BIP32 Index Randomisation

2015-03-12 Thread Gregory Maxwell
This seems overly complicated to me, unless I'm missing something.

Instead, I think you should just give the server the master pubkey P
only without the chaincode.


Then when you transact you generate the address in whatever manner you
like and tell the server the scalar value iL which the user computes
as

iL = HMAC-SHA512(Key = cpar, Data = serP(Kpar) || ser32(i))[first 32
byes],  (per BIP 32).

and the server computes P + iL*G  and checks agreement with the address.

It would be inaccurate to call this private, as the server still
learns this particular relation. (and really users should _not_ be
using the same chaincode with different parties... as it exacerbates
the private key leak risk), but its certainly more private than giving
people the chain code.

The approach I suggest is also not gratuitously incompatible with
hardened derivation, which is what parties should be doing when they
don't actually need a third party to generate future addresses for
them without their cooperation (as appears to be the case here).










On Fri, Mar 13, 2015 at 3:48 AM, Matias Alejo Garcia mat...@bitpay.com wrote:

 Hello everyone,

 We are working on bitcore-wallet-server (BWS), a HD multisig wallet
 'facilitator'. We have a couple of questions regarding BIP32 path usage, and
 we would love to have feedback from you before moving forward.

 Currently the BWS instances hold the set of extended public keys of the
 wallet's peers to be able to derive  addresses.

 Since this is a problem from the privacy point of view, we thought using
 pseudo-random  BIP32 paths, with a seed only known be the peers, so the
 server will be able to verify that addresses  submitted by peers belong to
 the wallet, but will not be able to derive future wallet addresses.

 The workflow would be something like:

 ```
 PeergetCurrentIndex

  Server [index]

 Peer:
   pathSeed = PRNG(seed, index);

 Peer  createAddress(index, pathSeed);

 Server:
   derives the address and add it to the wallet.

  Server  new address

 Peer: Verifies the address and inform it the user.
 ```

 This way, accessing server data won't reveal future wallet addresses. The
 seed (only known by the peers) could
 be derived from hashes of their xprivs, so wallet funds can still be recover
 with:
   1) The complete set of xprivs
   2) The quorum of xprivs + the complete set of xpubs + the address seed.

 Thanks a lot in advance for any comment on this schema.

 matías

 --
 BitPay.com

 --
 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] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread Gregory Maxwell
On Wed, Mar 11, 2015 at 11:45 AM, Thomas Kerin m...@thomaskerin.io wrote:
 I used BIP0090 as a place-holder, but I would like to request a BIP number
 for this now.

We have had repeated problems in the past with people working on and
circulating prior draft proposals squatting on each others numbers,
and each demanding access to the same numbers. As a matter of
procedure I will not assign squatted numbers, but also discussion
should come in advance of number assignment; general subject here
seems reasonable but many proposals are withdrawn by the party
tendering them after further discussion shows the effort to be without
public interest or actually subsumed by other functionality. :)

Proposals should not be called BIP[nn] until they're actually a BIP.
  Feel free to call it bip-kerin-multisignature or any other
placeholder name that won't be confused with a finished BIP for
drafting.

If there is any public documentation on the process which caused you
specific confusion, please feel free to point me at it and I'll be
sure to fix it! Sorry for any confusion there.

--
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] Electrum 2.0 has been tagged

2015-03-11 Thread Gregory Maxwell
On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
ricardojdfil...@gmail.com wrote:
 i guess you look at the glass half full :)
 even though what you say is true, we should aim for wallets not to
 require those instructions, by standardizing these things in BIPs.
 let's hope bitcoin doesn't fail in standards as our industries have in
 the past...

There are genuine principled disagreements on how some things should
be done. There are genuine differences in functionality.

We cannot expect and should not expect complete compatibility. If you
must have complete compatibility: use the same software (or maybe not
even then, considering how poor the forward compatibility of some
things has been..).

What we can hope to do, and I think the best we can hope to do, is to
minimize the amount of gratuitous incompatibility and reduce the
amount of outright flawed constructions (so if there are choices which
must be made, they're at least choices among relatively good options).

--
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] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread Gregory Maxwell
On Wed, Mar 11, 2015 at 11:24 PM, Pindar Wong pindar.w...@gmail.com wrote:
 Perhaps at some point consider introducing something akin to a
 'Bitcoin-Draft' (BD) status with some autoexpiry period?

 I understand that the Internet Engineering Task Force (IETF)  has the
 concept of 'Internet Drafts (ID) and this looks like it has worked for them
 so far.

Thats more or less what posting to the list is supposed to be.
Creating a draft document requires no approval, beyond filling out the
right form.

Perhaps calling out that as a distinct step would be better, indeed.

--
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] Electrum 2.0 has been tagged

2015-03-11 Thread Gregory Maxwell
On Wed, Mar 11, 2015 at 11:50 PM, devrandom c1.sf-bitc...@niftybox.net wrote:
 That said, I do agree that mnemonic phrases should be portable, and find
 it unfortunate that the ecosystem is failing to standardize on phrase
 handling.

The fact remains that there are several apparently unresolvable
well-principled perspectives on this subject.

(And I can speak to this personally: There are several BIPs in this
space that I'd rather not see in product with my name on it.)

Unless two wallets have exactly the same feature set, cross importing
keys is going to confuse or break something. Even if you're trying to
be fairly generic the testing overhead for all possible strategies and
structures is large. Expecting compatibility here would be like
expecting two large commercial accounting packages to support the same
internal file formats. Compatibility is only straight forward when the
feature set is as limited as possible.

The space for weird behavior to harm users is pretty large... e.g. you
could load a key into two wallets, such that one can see all the funds
by the other, but not vice versa and and up losing funds by
incorrectly assuming you had no coins; or inadvertently rip of your
business partners by accounting for things incorrectly.

Even ignoring compatibility, most demanded use cases here are ones
that create concurrent read/write use of single wallet without some
coordinating service is inherently somewhat broken because you can
double spend yourself, and end up with stalled and stuck transactions
and causing people to think you tried ripping them off.

I certainly recognize the desirable aspects of just being able to load
a common wallet, and that inexperienced users expect it to just work.
But I don't think that expectation is currently very realistic except
within limited domains. It may be more realistic in the future when
the role of wallets is better established. I don't see any _harm_ in
trying to standardize what can be, I just don't expect to see a lot of
success.

Ultimately, the most fundamental compatibility is guaranteed:  you can
always send your funds to another wallet. This always works and
guarantees that you are never locked in to a single wallet. It is well
tested and cannot drive any software in to weird or confused states.

--
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] Electrum 2.0 has been tagged

2015-03-11 Thread Gregory Maxwell
On Thu, Mar 12, 2015 at 2:41 AM, devrandom c1.sf-bitc...@niftybox.net wrote:
 I think there are some important advantages to not being forced to use
 the old wallet to send coins when switching wallets. The three I can
 think of right now are: maintaining transaction history,

Just loading a key doesn't keep transaction history however, if the
loading wallet can't understand or infer metadata about the
transactions. You get some mass of data but to tell actually what the
transactions are, or what they were for, forensic accounting is
required and some data will be potentially unrecoverable.

The best way to preserve historical information is to use reporting
from the wallet in question; which will accurately record the best
available output for this. (E.g. Bitcoin-qt has a CSV export or you
can take a json list-transactions out of it).

 emergency transition when a wallet has a serious (e.g. money losing) bug

This cuts both ways, we've seen significant losses for users in
Bitcoin Core where they've used the console to import keys that they
also used in other insecure clients.

For an emergency transition the user is probably better off with an
explicit unstructured mass private key export, and a sweep function;
and guaranteeing compatibility with that is much easier; and because
it moves funds in one direction there is much less chance of going
from secure to insecure.

 and web
 wallet with server down.

I suppose it would be too much to ask that these web wallets actually
not be totally centrally controlled and have the potential of just
having someone else stand up a server. I guess not. :(

Emergencies being what the are you do with what you can... indeed, I
agree thats a reason that better compatibility is better. (But perhaps
best is that its insane to use software to handle your money that can
just be taken away from you like that...)

 Another important reason to standardize is to reduce the roll your own
 crypto temptation on the wallet creator part, where the wallet-specific
 algorithm is more likely to contain weaknesses.
 I do agree that trying to come up with one uber standard will likely
 fail and is probably counter productive.

Careful with this line of thinking: We have no mechanism in the BIP
process to exclude weak cryptography.

A BIP is not a measure of cryptographic integrity. There are existing
BIPs which I consider flawed and would not use or recommend.

It result in some level of review, maybe, and so it can be productive
to at least have more eyes on fewer things; which is a reason I
wouldn't say don't bother trying.

And indeed, I do think that what can be standardized should be, my
words weren't intended to dismiss anyone's efforts, only to encourage
realistic (I think) expectations around what will come of it.

And while I hope for no gratuitous incompatibility, I also hope that
no one working on a wallet hesitates for a minute to offer a new and
interesting functionality just because it doesn't fit into a prefab
shape.

--
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


[Bitcoin-development] BCF 2012 Miner vote

2015-02-25 Thread Gregory Maxwell
It would appear that the Bitcoin Foundation has decided that their
next two seats would be decided by miners.   (More information
available at: 
https://bitcoinfoundation.org/forum/index.php?/topic/1255-blockchain-voting/#entry13453
)

Unfortunately, they seem to have not provided the software needed to
participate.

I've taken Luke DashJr's somewhat notorious IsNotorious patch, which
he's used previously to block things like the Horse Stapler Battery
dust-spam attacks and re-purposed it so miners can avoid casting votes
in the election that they don't intend to cast.

Not really an ideal fit, but the code has the benefit of having been
run in production for some time; a necessity for deployment on short
notice.

A patch (against git master, but should apply to 0.10 cleanly at least
and probably other versions) is available at:

https://people.xiph.org/~greg/bcf2012.patch

Let me know if you have any trouble applying it, I'll be glad to do my
civic duty and do what I can to help people participate with the
system was clearly intended by the design.

[Please note that I am relying on some claims from reddit for some of
the candidate addresses (
http://www.reddit.com/r/Bitcoin/comments/2x3ffk/bitcoin_foundation_runoff_voting_live_stats_2015/
) because the official voting software is more or less completely
busted for me and I can only see some of the candidates. If any are
wrong, please let me know.]

Cheers.

--
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] bloom filtering, privacy

2015-02-20 Thread Gregory Maxwell
On Fri, Feb 20, 2015 at 4:54 PM, Mike Hearn m...@plan99.net wrote:
 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

This approach needs a filter set with a lower FP rate. It doesn't
depend on having a high FP rate for privacy (which is good, since
counting on filter false positives seems to more or less fail to
deliver actual privacy in any case.)

Larger filters mean a somewhat higher baseline bandwidth, though when
users do not reuse addresses and have more addresses than there are
txouts in the block the gap is narrower.

 Ah, I see, I didn't catch that this scheme relies on UTXO commitments

This is talking about a committed bloom filter. Not a committed UTXO set.

--
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 Gregory Maxwell
On Fri, Feb 20, 2015 at 5:59 PM, Adam Back a...@cypherspace.org wrote:
 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.

Use of the words UTXO set here is probably confusing people as it's
likely to make people think of the complete verification state. In
this case it's simply referring to block-local data. (and thus avoids
the large IO overheads of an actual UTXO set).

It's a straight forward idea: there is a scriptpubkey bitmap per block
which is committed. Users can request the map, and be SPV confident
that they received a faithful one. If there are hits, they can request
the block and be confident there was no censoring.

It's possible to tree structure additional layers to the bitmap, so
one can incrementally query to trade0off map size for false request
overhead, it's not clear to me how much of a win this would be for
normal parameters.. It's also possible to extract the txout list for
the whole block and commit to that too so it's possible to request
just the outputs and get a faithful copy of them, which is _much_
smaller than the block overall.

--
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] replace-by-fee v0.10.0rc4

2015-02-12 Thread Gregory Maxwell
On Thu, Feb 12, 2015 at 1:18 PM, Mike Hearn m...@plan99.net wrote:
 history. Lots of miners have dropped out due to hardware obsolescence, yet
 massive double spending hasn't happened.

How many thousands of BTC must be stolen by miners before you'd agree
that it has, in fact, happened?
(https://bitcointalk.org/index.php?topic=321630.0)

On Thu, Feb 12, 2015 at 3:27 PM, Jeff Garzik jgar...@bitpay.com wrote:
 The fundamental engineering truths diverge from that misty goal:
 Bitcoin is a settlement system, by design.

 The process of consensus settles upon a timeline of transactions,
 and this process -- by design -- is necessarily far from instant.
 Alt-coins that madly attempt 10-second block times etc. are simply a
 vain attempt to paper over this fundamental design attribute:
 consensus takes time.

 As such, the blockchain can never support All The Transactions, even
 if block size increases beyond 20MB.  Further layers are -- by design
 -- necessary if we want to achieve the goal of a decentralized payment
 network capable of supporting full global traffic.

I just wanted to pull this out and say that I agree with this
completely; to the point where I'm continually surprised to see people
expressing other views (but they do).

I don't have much opinion about replace-by-fee; It has pluses and
minuses. In the past I've considered it a oh perhaps best to not talk
about that idea. I think making zero conf actively less secure would
be generally regrettable, though it might make building alternatives
for fast and acceptably safe transactions more attractive sooner. I do
favor a version of replace by fee that adds the extra constraint that
all prior outputs must be paid equal or more; which would capture many
of the 'opps paid too little' without opening up the malicious double
spends quite as much (so soon).

One challenge is that without rather smart child-pays-for-parent logic
the positive argument for replace by fee doesn't really work.

On Thu, Feb 12, 2015 at 12:52 PM, Alex Mizrahi alex.mizr...@gmail.com wrote:
 This would be right if you assume that all Bitcoin miners act as a single
 entity. In that case it is true that that entity's goal is to maximize
 overall ROI.

 But each miner makes decisions on his own. Are you familiar with a concept
 of Nash equilibrium, prisoner's dilemma, etc?

 The fact that nobody is using this kind of a behavior right now doesn't mean
 that we can rely on it.

 For example, Peercoin was horribly broken in 6 months after its release
 (e.g. people reported that they are able to generate 50 consecutive blocks
 simply by bringing a cold wallet online) and yet nobody bothered to exploit
 it, and it managed to acquire non-negligible market cap.

As a point for historical accuracy: PPC was actively attacked with
stake grinding and had to use developer signed blocks to prevent the
attacker from mining all the blocks and then later made a hard fork to
make it harder, and retains the developer block signing to stop it.

This doesn't contradict your point, which I agree with: an absence of
attacks doesn't mean an absence of vulnerability, and people counting
on things that they wouldn't if they understood them better is
something to avoid. And the prior point about game theory is one I
think some people have a hard time with: partipants are looking out
for their own interests, not some global optimum.  It may not be the
case that everyone (or even anyone) is maximally short sighted; but
it's even more unreasonable to assume that no one will ever break rank
and do something selfish.

I don't know that RBF even needs to be debated on these terms, since
there is an argument for RBF as good even if we assume miners are all
fully protocol conforming.

--
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] determining change addresses using the least significant digits

2015-02-06 Thread Gregory Maxwell
On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner
cryptocurrenc...@quidecco.de wrote:
 Hi there,

 traditionally, the Bitcoin client strives to hide which output
 addresses are change addresses going back to the payer. However,
 especially with today's dynamically calculated miner fees, this
 may often be ineffective:

 A user sending a payment using the Bitcoin client will usually enter
 the payment amount only up to the number of digits which are
 considered to be significant enough. So, the least significant digits
 will often be zero for the payment. With dynamically calculated miner
 fees, this will often not be the case for the change amount, making it
 easy for an observer to classify the output addresses.

 A possible approach to handle this issue would be to add a randomized
 offset amount to the payment amount. This offset amount can be small
 in comparison to the payment amount.

Sending someone too much can really play hell with their accounting.
Unless you know they're okay with it, I wouldn't suggest it.

I often randomly round up the output when I'm paying to a depository
account... and I've thought that would be a useful feature to have,
but I dunno how to usefully present a UI for pay at least X but
you're allowed to round-up up to 0.01 BTC more.


Another strategy is this: create two change outputs, with uniform
probablity make one equal to your payment amount (which is also nice
because if your payment amount models future payment amount the change
will be usefully sized) or split your change evenly.

--
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] [softfork proposal] Strict DER signatures

2015-02-02 Thread Gregory Maxwell
On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
 The much simpler alternative is just adding this to BIP66's DERSIG
 right now, which is a one-line change that's obviously softforking. Is
 anyone opposed to doing so at this stage?

Thats my preference.

--
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] Bitcoin Core 0.9.4 not on bitcoin.org?

2015-02-01 Thread Gregory Maxwell
On Sun, Feb 1, 2015 at 8:08 PM, xor x...@freenetproject.org wrote:
 Why is that?

Because Binaries on Bitcoin.org have always been unaffected by the
issue 0.9.4 was released to address.

 Also, is it correct that there wasn't a release candidate before the release?
 Sounds dangerous to me.

The changes were tried first by many people as part of git master.
This was narrow bug fix backport required to prevent the software from
no longer working at all for people who compiled it themselves and
received software updates for their system.

--
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] [softfork proposal] Strict DER signatures

2015-01-26 Thread Gregory Maxwell
On Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
 On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille pieter.wui...@gmail.com 
 wrote:
 I therefore propose a softfork to make non-DER signatures illegal
 (they've been non-standard since v0.8.0). A draft BIP text can be
 found on:

 https://gist.github.com/sipa/5d12c343746dad376c80

 I'd like to request a BIP number for this.

Sure. BIP0066. There was also some feedback on Bitcointalk, which I
think you've addressed:
https://bitcointalk.org/index.php?topic=932054.0 I also had off-list
positive feedback from Amir Taak, so we have positive feedback from
several implementers.

One of the points that was raised which we'd discussed pre-proposal
that was brought up there that I thought I should summarize here was
the possibility that someone had previously authored an nlocked spend
with an invalidly encoded signature. In those cases the signature can
just be mutated to get it mined, and would need to be already to pass
IsStandard rules. A case that isn't covered if if they have a chain of
transactions after that nlocked transaction, but those cases would
already be at extreme risk of malleability (esp since their unchanged
form is non-standard), and that coupled with the fact that avoiding
this would undermine the intent of the BIP (independence from  a
specific encoding scheme) seems to have been convincing as much.

--
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 Gregory Maxwell
On Fri, Jan 23, 2015 at 4:18 PM, slush sl...@centrum.cz wrote:
 Can you send me any reference about this? Of course if that solves the
 problem, hard fork would not be necessary anymore. I'm just not aware of
 any.

Sure; will aggregate up the citations when I'm not travling later today.

 To sign transaction with hundreds of inputs on device with limited memory
 capabilities, I need to stream all previous transactions into device, for
 every signed input.

 That means roughly 200^2 transaction verifications for 200 inputs to sign.
 Very slow, but does not limit the device for any particular size of signed
 transaction.

I'm not sure where the ^2 is coming from.  So what I'd understand that
you'd do is stream in the input txid:vouts which you spend, then you'd
stream the actual inputs which would just be hashed and value
extracted (but no other verification), and you'd build a table of
txid:vout-value, then the actual transaction to be signed.

This should have O(inputs) hashing and communications overhead. Is
there a step I'm missing?

--
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 Gregory Maxwell
On Fri, Jan 23, 2015 at 5:40 PM, slush sl...@centrum.cz wrote:
 Yes, the step you're missing is and build the table. Dynamic memory
 allocation is something you want to avoid, as well as any artifical
 restrictions to number of inputs or outputs. Current solution is slow, but
 there's really no limitation on tx size.

 Plus there're significant restrictions to memory in embedded world. Actually
 TREZOR uses pretty powerful (and expensive) MCU just because it needs to do
 such validations and calculate such hashes. With SIGHASH_WITHINPUTVALUE or
 similar we may cut hardware cost significantly.

I'm quite familiar with embedded development :), and indeed trezor MCU
is what I would generally consider (over-)powered which is why I was
somewhat surprised by the numbers; I'm certainly not expecting you to
perform dynamic allocation... but wasn't clear on how 40 minutes and
was I just trying to understand. Using a table to avoid retransmitting
reused transactions is just an optimization and can be done in
constant memory (e.g. falling back to retransmission if filled).

So what I'm understanding now is that you stream the transaction along
with its inputs interleaved in order to reduce the memory requirement
to two midstates and a value accumulator; requiring resending the
transaction... so in the worst case transaction (since you can't get
in more than about 800 inputs at the maximum transaction size) each
input spending from (one or more, since even one would be repeated)
100kb input transactions you might send about 800MBytes of data, which
could take a half an hour if hashing runs at 45KB/s or slower?

(If so, okay then there isn't another thing that I was missing).

--
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 Gregory Maxwell
On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner etothe...@gmail.com wrote:
 Unfortunately, it seems that there was no soft-fork way to achieve this
 benefit, at least not one that had favorable properties.  Most of the
 soft-fork variations of it required the coins being spent to have been
 originated in a special way.  In other words, it would only work if the
 coins had entered the wallet with some special, modified TxOut script.  So
 it wouldn't work with existing coins, and would require senders to update
 their software to reshape the way they send transactions to be compatible
 with our goals.

I think this is unreasonable. There is a straight-forward soft-fork
approach which is safe (e.g. no risk of invalidating existing
transactions). Yes, it means that you need to use newly created
addresses to get coins that use the new signature type... but thats
only the case for people who want the new capability. This is
massively preferable to expecting _every_ _other_ user of the system
(including miners, full nodes, etc.) to replace their software with an
incompatible new version just to accommodate your transactions, for
which they may care nothing about and which would otherwise not have
any urgent need to change.

I've expected this need to be addressed simply as a side effect of a
new, more efficient, checksig operator which some people have been
working on and off on but which has taken a backseat to other more
urgent issues.

On Fri, Jan 23, 2015 at 2:51 PM, slush sl...@centrum.cz wrote:
 as hardware wallets are more widespread. I'm sitting next to TREZOR for 40
 minutes already, because it streams and validate some complex transaction.

Can you help me understand whats taking 40 minutes here? Thats a
surprisingly high number, and so I'm wondering if I'm not missing
something there.

--
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


[Bitcoin-development] OpenSSL 1.0.0p / 1.0.1k incompatible, causes blockchain rejection.

2015-01-09 Thread Gregory Maxwell
OpenSSL 1.0.0p / 1.0.1k was recently released and is being
pushed out by various operating system maintainers.  My review
determined that this update is incompatible with the Bitcoin
system and could lead to consensus forks.

Bitcoin Core released binaries from Bitcoin.org are unaffected,
as are any built with the gitian deterministic build system.

If you are running third-party or self-compiled Bitcoin Core
or an alternative implementation using OpenSSL you must not
update OpenSSL or must run a Bitcoin software containing a
workaround:

https://github.com/bitcoin/bitcoin/commit/488ed32f2ada1d1dd108fc245d025c4d5f252783
(versions of this will be backported to other stable branches soon)

The tests included with Bitcoin Core in the test_bitcoin
utility already detect this condition and fail.  (_Do not ignore or
disable the tests in order to run or distribute software
which fails_)

The incompatibility is due to the OpenSSL update changing the
behavior of ECDSA validation to reject any signature which is
not encoded in a very rigid manner.  This was a result of
OpenSSL's change for CVE-2014-8275 Certificate fingerprints
can be modified.

While for most applications it is generally acceptable to eagerly
reject some signatures, Bitcoin is a consensus system where all
participants must generally agree on the exact validity or
invalidity of the input data.  In a sense, consistency is more
important than correctness.

As a result, an uncontrolled 'fix' can constitute a security
vulnerability for the Bitcoin system.  The Bitcoin Core developers
have been aware of this class of risk for a long time and have
taken measures to mitigate it generally; e.g., shipping static
binaries, internalizing the Leveldb library... etc.

It was somewhat surprising, however, to see this kind of change show
up as a low priority fix in a security update and pushed out live
onto large numbers of systems within hours.

We were specifically aware of potential hard-forks due to signature
encoding handling and had been hoping to close them via BIP62 in 0.10.
BIP62's purpose is to improve transaction malleability handling and
as a side effect rigidly defines the encoding for signatures, but the
overall scope of BIP62 has made it take longer than we'd like to
deploy.

(Coincidentally, I wrote about this concern and our unique demands on
 cryptographic software as part of a comment on Reddit shortly before
 discovering that part of this OpenSSL update was actually
 incompatible with Bitcoin:
 
https://www.reddit.com/r/Bitcoin/comments/2rrxq7/on_why_010s_release_notes_say_we_have_reason_to/cnitbz3
)

The patches above, however, only fix one symptom of the general
problem: relying on software not designed or distributed for
consensus use (in particular OpenSSL) for consensus-normative
behavior.  Therefore, as an incremental improvement, I propose
a targeted soft-fork to enforce strict DER compliance soon,
utilizing a subset of BIP62.

Adding a blockchain rule for strict DER will reduce the risk of
consensus inconsistencies from alternative implementations of
signature parsing or signature verification, simplify BIP62,
and better isolate the cryptographic validation code from the
consensus algorithm. A failure to do so will likely leave us
in this situation, or possibly worse, again in the future.

The relevant incompatible transactions are already non-standard on
the network since 0.8.0's release in February 2013, although there
was seemingly a single miner still mining incompatible transactions.
That miner has been contacted and has fixed their software, so a
soft-fork with no chain forking should be possible.

--
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] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

2015-01-09 Thread Gregory Maxwell
On Fri, Jan 9, 2015 at 1:20 PM, Mike Hearn m...@plan99.net wrote:
 A limitation on most existing micropayment channel ideas is that payments
 can only flow in one direction.
 It's worth noting that the original protocol as designed by Satoshi did not
 have this limitation. It has evolved this way because of ad-hoc DoS fixes
 over time (btw I'm not saying they were the wrong thing to do, as non ad
 hoc solutions are significantly more work). But it seems like eventually a
 different approach to handling DoS attacks based on resource prioritisation
 and scheduling will become needed / implemented, and at that point the
 original design could be safely brought back to life.

I don't agree with your understanding.  Expecting replacement to work
and be enforced is completely unsafe. People (sanely) refuse to use
protocols which are broken by refund malleability, which is a much
narrower expectation for miners than expecting the sequence ratchet to
go one way.

--
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] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY

2015-01-09 Thread Gregory Maxwell
On Fri, Jan 9, 2015 at 1:42 PM, Mike Hearn m...@plan99.net wrote:
 Additionally, there is a school of thought that says Bitcoin must work even
 if lots of miners are malicious and willing to break arbitrary things in
 order to try and get more money. I don't think Bitcoin can really be a

This being unsafe doesn't require a lot though, if 1% of the
hashpower is naughty, an attacker will have a 1% success rate. Naughty
can also just mean broken in various ways, like mining while somewhat
partitioned (didn't hear the update) potentially due to a DOS attack,
or because of some garbage collection policy made it forget the
transaction to conserve resources.  An unkind user can simply run
software that automatically attempts (by sending naughty miners an
earlier conflict right before the locktime expires).  Use Blue
Rewards wallet for 2% cash back for all the Bitcoin purchases you make
online! :P

Of course, all the miners who don't play along will very much see how
much income they're missing.

 so clients can enforce that all versions have the same fee attached

Sadly, they cannot.  This is why I specifically mentioned child pays for parent.

In any case,  sometimes a 1% fault rate is acceptable. But generally
for cases that they are, even weaker constructs (e.g. no payment
channel at all, just accept an IOU) are also often acceptable, and
cannot be modulated in their success by resource starvation attacks on
the network.

We have objective proof of substantial miners behaving maliciously,
that much isn't a speculative concern.

The school of thought view is a bit too black and white. My
perspective is that absolute soundness is best (rules which cannot be
broken at all), followed by cryptographic soundness (rules that
breaking requires P=NP, theft of a secret, or insane luck), followed
by economic soundness (rules that cannot be profitably broken),
followed by honesty soundness (rules that hold when the participants
follow the rules and aren't faulty).  We should try to move up that
stack as far towards absolutely soundness as possible; and be
increasingly cautious about compromises as we move down it espeically
because the last two are unstable and difficult to reason about
because they strongly import the vulgarities of humanity into the
security model.   If we could make the whole system absolutely sound
or cryptographically sound, I would think we should (and would) even
if it implied other compromises. But we can't and so users of Bitcoin
must navigate this risk stack.

One thing that I think you miss in this argument is that one man's
integrity is another man's malice.  The history of security and
privacy is filled with instances where someone's trust was violated
because there someone was, rightly or wrongly, convinced that Some
Reason was Good Enough to justify it. Because of this a risk analysis
has to import the clarity of judgement, morality, coerceability,
personal values, etc. of everyone in the trust chain; and many of
these things are unknowable; this greatly increases the costs of
transacting, and the efforts to mitigate those costs (and the failures
to remove the harms) result in an unequitable enviroment where some
people get unjust rewards and unequal access to justice. The gain from
cryptographic tools is being able to make some level of stronger
assurances which cut out most of that trust, they're predictable,
'cheap' on a marginal basis, and fair in a fundamental sense (in
theory everyone has equal access to math).  So, while I could even buy
the argument that miners will never believe themselves to be actually
malicious, history shows that people's ability to convince themselves
of the justification of something is basically unbounded, even
outright thieves often believe they're owed their spoils-- and there
are a lot of ways to misbehave in Bitcoin that stop short of theft.
And so, where we cannot have cryptographic security enforce the rules,
we-- those who use and depend on Bitcoin-- _generally_ ought to behave
in ways that cannot be harmed by a failure to follow the rules so that
we don't _invite_ failures to follow the rules and thereby create an
institution of it.

Of course, all things equal I don't want to choose for other people
what tools they can use and what risks they take. But in the case of
relaying locked transactions this isn't an otherwise neutral choice: A
straight forward relay and store any locked spend policy has
unbounded space and communications complexity.  It's not clear to me
that if any real degree of you can take your risks, it'll probably
work, but maybe not can be supported without a very large resource
cost to the network, and without creating incentives to DOS attack the
network (e.g. to make it forget previous spends).  It may be that
there is some set of constraints that actually do make it workable and
don't create the incentives though... meaning that it may _merely_ be
unsafe for people who choose to use it. If so, then it might be
reasonable but 

Re: [Bitcoin-development] Re-enabling simple tx replacement

2015-01-04 Thread Gregory Maxwell
On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll j...@jrn.me.uk wrote:
 Dear all,

 I've been looking at atomic cross-chain trading (
 https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the
 Bitcoin and Dogecoin blockchains, and have a mostly functional
 prototype. However as it stands if the refund transaction is relayed
 before the actual spend transaction, it blocks the legitimate spend
 transaction from being accepted into the memory pool.

Unless there is a serious bug that I am not aware of this is not the
case. The unlocked transaction is not relayable and will not be
mempooled (well, until right before it locks).

 I've drafted a patch for this
 https://github.com/rnicoll/bitcoin/commit/e668d36607f008990ccaac7275e463a6efdd9b5a
 but have not yet raised a PR, as historically this has lead to a lot of
 discussion in Github which is better suited to this mailing list.

 I'm therefore looking for feedback while I continue testing that patch,
 and any comments would be welcomed.

This appears to have absolutely no protection against denial of
service, it seems to me that a single user can rapidly update their
transaction and exhaust the relay bandwidth of the entire network.

--
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] Re-enabling simple tx replacement

2015-01-04 Thread Gregory Maxwell
On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll j...@jrn.me.uk wrote:
 Grabbing a simple test case:
 https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8
 - that won't lock until 0028 UTC on the 5th.

 I've tried closing the wallet, moving the wallet.dat file out of the
 way, and then attempting the spend transaction (which can be locked
 immediately), and it either rejects it on acceptance to mempool, or it
 is never included in a block.

Can you send me the actual raw transaction (that site doesn't appear
have a way to get it, only some cooked json output; which doesn't
include the sequence number).

As I said, it's a severe bug if unlocked transactions are being
relayed or mempooled far in advance.

 They can only replace a non-final transaction with a final transaction,

Ah I missed that the replacement had to be final. Thats indeed a much
more sane thing to do than I was thinking (sorry for some reason I saw
the +1 and thought it was just checking the sequence number was
higher.)

 I don't think that's a major issue?

If they can relay the first one to begin with its an an issue, the
replacement just makes it twice an issue. :)

--
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] Re-enabling simple tx replacement

2015-01-04 Thread Gregory Maxwell
On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
 Can you send me the actual raw transaction (that site doesn't appear
 have a way to get it, only some cooked json output; which doesn't
 include the sequence number).

Nevermind, I guess. I think I figured out your problem: The behaviour
on testnet is busted because the non-mempooling is enforced by
IsStandardTx which is bypassed in testnet. We should enforce that
elsewhere.

This isn't the case on the real network.

--
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] BIP: Voluntary deposit bonds

2014-12-30 Thread Gregory Maxwell
On Tue, Dec 30, 2014 at 4:25 PM, Sergio Lerner
sergioler...@certimix.com wrote:
 Slight off-topic:
 That looks like an abuse of the VM. Even P2SH is an abuse of the VM.
 Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking about a
 simple change that goes along the lines of Satoshi's original design.
 Bitcoin was a beautiful design, and extra complexity is making it ugly.
 We need Bitcoin to be simple to understand for new programmers so they
 can keep the project going. It doesn't help the project that one needs
 to be a guru to code for Bitcoin.

Sergio there is no abuse there,  OP_NOP3 in that case would be
redefined to OP_COINBASE_FOO_CONSISTENCY.

(I say FOO because it's not clear what rule you actually hope to apply there.)

What you suggested has no purpose by itself: it would need an
additional change which overlays functionality in order to actually do
something. Such a change would likely be ugly-- it's easy to be
elegant when you do nothing.

--
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] BIP: Voluntary deposit bonds

2014-12-29 Thread Gregory Maxwell
On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner
sergioler...@certimix.com wrote:
 I propose to allow miners to voluntarily lock funds by letting miners
 add additional inputs to the coinbase transaction. Currently the
 coinbase transaction does not allow any real input  to be added (only a
 pseudo-input).
 This is a hard-fork, and we could include it the next time a hardfork is
 made.
 The modifications to the code are minimal (no more than 12 lines
 modified where IsCoinBase() is called), and they generally involve
 removing code, not adding.


If the motivation is purely enabling different rules in a soft-fork
than I think nothing needs to be done.

Instead of providing inputs to a coinbase: you provide an unusual
anyone can spend transaction in the block which pays to fees; and
simultaneously add a soft-forking rule that makes that anyone can
spend rule no longer anyone can spend.

To make that more concrete.  E.g. You make your anyone can spend
output   PUSHhash of coinbase output script_pubkeys OP_NOP3.  Now
this anyone can pay transaction is really just a coinbase input.

The construction is reasonably efficient, and also more flexible-- in
that it could control the data under the hash in more flexible ways
than available in the existing sighash flags.


As an aside, I'm not sure that I agree with the claim that making
coinbases have inputs is a simple modification... as we use one of the
inputs already as the special coinbase field and at least that must be
special cased.

--
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] Area of Focus

2014-12-20 Thread Gregory Maxwell
On Sat, Dec 20, 2014 at 11:14 AM, Jeremy Spilman jer...@taplink.co wrote:
 are dnsseeds being blocked
 ostensibly because they are acting as dyanamic DNS infrastructure for
 malware sites?

Pretty much appears to be the case. In every instance it appears to be
automated. This predates the msft no-ip.com stuff.
We also had similar problems with the IRC based method that the
software originally used.

It's the same story for mail relay spam blacklisting.  There is a
whole industry out there selling people semi-snake-oil blocking
solutions to make the baddness of the internet go away. The low margin
business demands a cheap and highly automated approach... lots of
inappropriate things get blocked. Nagging people to fix things is time
consuming, better to move out of their sights a bit, so that they at
least have to specifically target Bitcoin. If they do, it'll at least
be worth the time spent fixing it.

I believe opendns is blocking all of sipa.be still as we speak, so if
you'd like to see it for yourself try to load http://bitcoin.sipa.be
while using opendns.

--
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] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged

2014-12-15 Thread Gregory Maxwell
On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd p...@petertodd.org wrote:
[snip]
 Pull-req #4890², specifically commit c7829ea7, changed the

This change was authored more than three months ago and merged more
than two months ago.
[And also, AFAICT, prior to you authoring BIP65]

I didn't participate in that pull-req, though I saw it... it had five
other contributors working on it and I try to have minimal opinions on
code organization and formatting.

But the idea sounded (and still sounds) reasonable to me.  Of course,
anything could still be backed out if it turned out to be ill-advised
(even post 0.10, as I think now we've had months of testing with this
code in place and removing it may be more risky)... but your comments
here are really not timely.
Everyone has limited resources, which is understandable, but the
concerns you are here are ones that didn't involve looking at the code
to raise, and would have been better process wise raised earlier.

 We need to fix this if CHECKLOCKTIMEVERIFY is to be merged.

I don't see why you conclude this. Rather than violating the layering
by re-parsing the transaction as the lower level, just make this data
additional information that is needed available.
Yes, does mean that rebasing an altcoin that made modifications here
will take more effort and understanding of the code than a purely
mechanical change.

 Secondly, that this change was made, and the manner in which is was made, is I
 think indicative of a development process that has been taking significant
 risks with regard to refactoring the consensus critical codebase.

I don't agree. The character of this change is fairly narrow. We have
moderately good test coverage here, and there were five participants
on the PR.

 While it would be nice to have a library encapsulating the consensus code, 
 this
 shouldn't come at the cost of safety, especially when the actual users of that

This is all true stuff, but the fact of it doesn't follow that any
particular change was especially risky.

Beyond the general 'things were changed in a way that made rebasing
an-altcoin take more work' do you have a specific concern here?

Other than travling back in time three months and doing something
differently, do you have any suggestions to ameliorate that concern?
E.g. are their additional tests we don't already have that you think
would increase your confidence with respect to specific safety
concerns?

 A much safer approach would be to keep the code changes required for a
 consensus library to only simple movements of code for this release, accept
 that the interface to that library won't be ideal, and wait until we have
 feedback from multiple opensource projects with publicly evaluatable code on
 where to go next with the API.

There won't be any public users of the library until there can
actually _be_ a library.

PR4890's primary objective was disentangling the script validation
from the node state introduced by the the signature caching changes a
couple years ago, making it possible to build the consensus components
without application specific threading logic... and makes it possible
to have a plain script evaluator call without having to replicate all
of bitcoind's threading, signature cache, etc. logic.  Without a
change like this you can't invoke the script engine without having a
much larger chunk of bitcoind running.

0.10 is a major release, not a maintenance release. It's specifically
in major releases that we make changes which are not purely code
motion and narrow bugfixes (Though many of the changes in 0.10 were
nicely factored into verify pure code motion changes from behavioral
changes). There are many very important, even critical, behavioural
changes in 0.10.  That these changes have their own risks are part of
why they aren't in 0.9.x.

--
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] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...

2014-11-28 Thread Gregory Maxwell
On Fri, Nov 28, 2014 at 11:45 AM, Flavien Charlon
flavien.char...@coinprism.com wrote:
 This breaks existing invariants and would make the coins potentially less
 fungible because they wouldn't be reorg safe.

 I'm not sure coins are ever reorg safe. All it takes is a double spend in
 the history of your coins for them to become invalid after a reorg. Because
 of that, there are already less fungible coins. This is why we recommend 6
 confirmations for important payments.

I used the word 'less' intentionally.   A double spend requires an
active action. Roughly 1% of blocks are lost to reorganizations by
chance, longer otherwise harmless reorgs as we've had in the past
could forever destroy large chunks of coins if descendants had the
unwelcome properties of having additional constraints on them. Past
instances where the network had a dozen block reorganization which
were harmless and simply confirmed the same transactions likely would
have caused substantial losses if it reorganizations precluded the
recovery of many transactions which were valid when placed earlier in
the chain.

Additionally your '6 confirmations' is a uniform rule. The
recommendation is just a count, it's tidy.  It's not a traverse the
recent history of each coin you receive to determine if its script
conditions make it unusually fragile and subject to irrecoverable
loss, which is the space you can get into with layering violations
and transaction validity depending on arbitrary block data.

--
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=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-11-27 Thread Gregory Maxwell
On Thu, Nov 27, 2014 at 5:44 PM, Mistr Bigs mister...@gmail.com wrote:
 I might be mistaken, but it seems to me this paper discusses unintended ways
 of obtaining the IP addresses of clients involved in transactions on the
 core Bitcoin network.

You're mistaken. :)

If a node is used exclusively via tor it effectively doesn't have a IP address.

(short of bugs of a class that aren't discussed here)

The paper is about fingerprinting approaches that probabilistically
connect transactions to hosts that you can already identify their IPs.

--
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=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...

2014-11-27 Thread Gregory Maxwell
On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore m...@ricmoo.com wrote:
 Heya,

 I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and
 thought it might make more sense to instead have a OP_CHECKLOCKTIME which
 would simply push an OP_TRUE or OP_FALSE onto the stack?

Updating the stack is not soft-fork compatible and any use would
immediately fork the network.

A invertible test is also not soft-fork compatible e.g. someone writes
a script that does {new thing) OP_NOT,  in other words the test
must fail, then the network would fork because older nodes would see
it as passing (which was the required criteria for non-forking the
network in the non-inverted caes).

You can happily get non-nullable true/false behaviour without these
risks by having the VERIFY test inside a branch and having the signer
provide its falseness as an input to the branch. This is explained in
the BIP.

E.g. OP_IF limit OP_CHECKLOCKTIMEVERIFY OP_ELSE what you'd do if it
doesn't pass OP_END

A useful an powerful mental model is that SCRIPT is not running a
program, but instead the signer is proving to the network that they
know inputs that make the program return true.

(In practise we verify this by actually doing some execution, though
this isn't technically necessary it's the simplest thing to implement
although it is inefficient... but even in this simple model keeping in
mind that we're VERIFYING not executing in the network opens our eyes
to transformations like the IF bracketing of a VERIFY opcode.)

 That way someone could include multiple OP_CHECKLOCKTIME conditions in a
 single script.

They can do this, with the above approach.

 As a second question, would it possibly make more sense to, rather than
 relying on the nLockTime in a transaction, allow an opcode that would use
 similar semantics, but against an item in the stack? Then you could
 essentially include multiple nLockTimes in a single script and make
 arbitrarily interesting (complicated?) scripts based on block height and/or
 block timestamp.

 The OP_CHECKLOCKTIMEVERIFY can still be easily implemented, by using

 nLockTimeThatWouldBeInTx OP_CHECKLOCKTIME OP_VERIFY

Then the scripts validity isn't a pure function of the the
transaction, and once valid transactions could become invalid while in
the mempool. This breaks existing invariants and would make the coins
potentially less fungible because they wouldn't be reorg safe. That
locktime validity is basically monotonic is a useful intentional
property. :)


The things you're suggesting were all carefully designed out of the
proposal, perhaps the BIP text needs some more clarification to make
this more clear.

--
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=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-11-27 Thread Gregory Maxwell
On Fri, Nov 28, 2014 at 12:45 AM, Mistr Bigs mister...@gmail.com wrote:
 That's what I was trying to say... The researchers are deanonymizing
 transactions from non-Tor connected hosts. So why are we talking about Tor
 limitations in response to this? Shouldn't we be discussing how to address
 the issues in Bitcoin proper?

Because if the user does not use tor or an analogous infrastructure
(e.g. something else reimplementing tor's functionality) the user can
be deanonymized in many different ways.

At the end of the day, if I'm listening widely to the network, and
your host is regularly the first to hand me your transactions then I
can draw reasonably reliable conclusions... and this is true even if
there is a complete absence of identifiable characteristics otherwise.

And, on the flip side if the host is persistently behind tor, even
with some watermarkable behaviour, their privacy is protected.  So
making sure that hosts can continually use tor (or similar systems)
should be the higher priority.  (And, of course, not reimplementing
tor  leverages the millions of dollars of investment and dozens of
subject matter experts working on that system).

--
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=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Deanonymisation of clients in Bitcoin P2P network paper

2014-11-26 Thread Gregory Maxwell
 Since this attack vector has been discussed, I started making some
 measurements on how effective it is to connect to Bitcoin using Tor,
 and I found that the number of connections dropping to near-zero is
 a situation which occurs rather frequently, which suggests that there
 is still room to improve on the DoS handling.

I'm confused by this, I run quite a few nodes exclusively on tor and
chart their connectivity and have seen no such connection dropping
behaviour.

Can you tell me more about how you measured this?

[As an aside I agree that there are lots of things to improve here,
but the fact that users can in theory be forced off of tor via DOS
attacks is not immediately concerning to me because its a conscious
choice users would make to abandon their privacy (and the behaviour of
the system here is known and intentional). There are other mechanisms
available for people to relay their transactions than connecting
directly to the bitcoin network; so their choice isn't just abandon
privacy or don't use bitcoin at all.]

--
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=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP draft - Auxiliary Header Format

2014-11-09 Thread Gregory Maxwell
Some initial comments...

Tying in the protocol changes is really confusing and the fact that
they seem to be required out the gates would seemingly make this much
harder to deploy.   Is there a need to do that? Why can't the p2p part
be entirely separate from the comitted data?

On Mon, Nov 10, 2014 at 12:39 AM, Tier Nolan tier.no...@gmail.com wrote:
 I made some changes to the draft.  The merkleblock now has the auxiliary
 header information too.

 There is a tradeoff between overhead and delayed transactions.  Is 12.5%
 transactions being delayed to the next block unacceptable?  Would adding
 padding transactions be an improvement?

 Creating the seed transactions is an implementation headache.

 Each node needs to have control over an UTXO to create the final transaction
 in the block that has the digest of the auxiliary header.  This means that
 it is not possible to simply start a node and have it mine.  It has to
 somehow be given the private key.  If two nodes were given the same key by
 accident, then one could end up blocking the other.

 On one end of the scale is adding a transaction with a few thousand outputs
 into the block chain.  The signatures for locktime restricted transactions
 that spend those outputs could be hard-coded into the software.  This is the
 easiest to implement, but would mean a large table of signatures.  The
 person who generates the signature list would have to be trusted not to
 spend the outputs early.

 The other end of the scale means that mining nodes need to include a wallets
 to manage their UTXO entry.  Miners can split a zero value output into lots
 of outputs, if they wish.

 A middle ground would be for nodes to be able to detect the special
 transactions and use them.  A server could send out timelocked transactions
 that pay to a particular address but the transaction would be timelocked.
 The private key for the output would be known.  However, miners who mine
 version 2 blocks wouldn't be able to spend them early.


 On Sat, Nov 8, 2014 at 11:45 PM, Tier Nolan tier.no...@gmail.com wrote:

 I created a draft BIP detailing a way to add auxiliary headers to Bitcoin
 in a bandwidth efficient way.  The overhead per auxiliary header is only
 around 104 bytes per header.  This is much smaller than would be required by
 embedding the hash of the header in the coinbase of the block.

 It is a soft fork and it uses the last transaction in the block to store
 the hash of the auxiliary header.

 It makes use of the fact that the last transaction in the block has a much
 less complex Merkle branch than the other transactions.

 https://github.com/TierNolan/bips/blob/aux_header/bip-aux-header.mediawiki



 --

 ___
 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] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Gregory Maxwell
On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd p...@petertodd.org wrote:
 BIP62 does make life easier for wallet authors as they don't have to
 deal with malleability - maybe! -

Yes, I agree for most contract purposes CTLV is what you want to be
using, instead of refund transactions beyond being more clearly
correct, it shrinks the protocol state machine by one step.

Though BIP62 also achieves the secondary goal of making required
implementation behaviour more explicit (e.g. the parts enforced in all
transactions), and that shouldn't be discounted.

They're somewhat orthogonal, somwhat complementary things.

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


Re: [Bitcoin-development] Increasing regularity of block times?

2014-10-30 Thread Gregory Maxwell
On Thu, Oct 30, 2014 at 11:18 PM, Rusty Russell ru...@rustcorp.com.au wrote:
 Hi all,

 I've been toying with an algorithm to place a ceiling on
 confirmation latency by allowing weaker blocks after a certain time.
 Hope this isn't noise, but thought someone must have considered this
 before, or know of flaws in the scheme?

 Gory details:
 http://rustyrussell.github.io/pettycoin/2014/10/30/More-Regular-Block-Times.html

Irregularity is a required property for convergence. Imagine what
would happen in a network where a blocks were produced at an exact
interval: Almost everyone would produce one the exact same time, and
the network would fragment and because the process would continue it
would not converge. It is precisely the variance  being some huge
multiple of the network radius which allows the network to converge at
all.

When lower variance is tolerable for convergence it can be achieved by
reducing the expectation. Maybe some other distribution can be proven
to be convergent to, it's difficult to reason about.

Bitcoin testnet implements a rule that allows lower difficulty blocks
after a delay (20 minutes, in fact), but it's a testing-toy... not
secure or intended to be so. At least one altcoin has copied that
behavior and been exploited on account of it.

If you're simply looking for faster evidence that the network is
working on a particular transaction set, at some lower timescale:,
then thats already possible.  e.g. look into how the p2pool sharechain
builds a consensus around mining work used for pooling. The same
mechanism can be used to give faster transaction selection evidence.

I'll dig up some citations for you later. Cheers.

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


[Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Gregory Maxwell
On Tue, Oct 28, 2014 at 8:17 PM, Ferdinando M. Ametrano
ferdinando.ametr...@gmail.com wrote:

 On Oct 25, 2014 9:19 PM, Gavin Andresen gavinandre...@gmail.com wrote:
  We had a halving, and it was a non-event.
  Is there some reason to believe next time will be different?

 In november 2008 bitcoin was a much younger ecosystem,

Or very old, indeed, if you are using unsigned arithmetic. [...]

 and the halving happened during a quite stable positive price trend

Hardly,

http://bitcoincharts.com/charts/mtgoxUSD#rg60zczsg2012-10-01zeg2012-12-01ztgSzm1g10zm2g25zv

 Moreover, halving is not strictly necessary to respect the spirit of 
 Nakamoto's monetary rule

It isn't, but many people have performed planning around the current
behaviour. The current behaviour has also not shown itself to be
problematic (and we've actually experienced its largest effect already
without incident), and there are arguable benefits like encouraging
investment in mining infrastructure.

This thread is, in my opinion, a waste of time.  It's yet again
another perennial bikeshedding proposal brought up many times since at
least 2011, suggesting random changes for
non-existing(/not-yet-existing) issues.

There is a lot more complexity to the system than the subsidy schedule.

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


Re: [Bitcoin-development] Fwd: death by halving

2014-10-28 Thread Gregory Maxwell
On Tue, Oct 28, 2014 at 9:19 PM, Jérémie Dubois-Lacoste
jeremie...@gmail.com wrote:
 The fact that a topic was brought up many times since a long time,
 does not mean it is not relevant.

I am not saying that it is not relevant, I'm saying the discussion
is pointless:

No new information has arrived since the very first times that this
has been discussed except
that the first halving passed without incident.
If people were not sufficiently convinced that this was a serious
concern before there was concrete evidence (however small) that it was
okay, then discussion is not likely going to turn out differently the
50th or 100th time it is repeated...
except, perhaps, by wearing out all the most experienced and
knowledgeable among us as we become tired of rehashing the same
discussions over and over again.

On Tue, Oct 28, 2014 at 9:23 PM, Ferdinando M. Ametrano
ferdinando.ametr...@gmail.com wrote:
[snip]
 As of now the cost per block is probably already about 100USD, probably in
 the 50-150USD.

This is wildly at odds with reality. I don't mean to insult, but
please understand that every post you make here consumes the time of
dozens (or, hopefully, hundreds) of people. Every minute you spend
refining your post has a potential return of many minutes for the rest
of the users of the list.

At current difficulty, with a SP30 (one of the
leading-in-power-efficiency) marginal break-even is ~1144.8852 * $/kwh
== $/btc.

At $0.10/kwh each block has an expected cost right now, discounting
all one time hardware costs, close to $3000.

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


Re: [Bitcoin-development] DS Deprecation Window

2014-10-27 Thread Gregory Maxwell
On Tue, Oct 28, 2014 at 2:26 AM, Tom Harding t...@thinlink.com wrote:
 Matt,

 You're right, thanks.  Without double-spend relay, miner won't know that
 some txes conflict with anything.

Even with that, the miner cannot tell, his only safe option is to
include no transactions at all.

Consider a malicious miner can concurrently flood all other miners
with orthogonal double spends (which he doesn't mine himself). These
other miners will all be spending some amount of their time mining on
these transactions before realizing others consider them
double-spends.

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


Re: [Bitcoin-development] BIP process

2014-10-15 Thread Gregory Maxwell
On Wed, Oct 15, 2014 at 8:29 AM, Wladimir laa...@gmail.com wrote:
 Hello,

 I'm trying to create a bit of process around the
 https://github.com/bitcoin/bips repository.

 A) Currently a lot of pulls are open for various BIPs and it is not
 clear who should comment on them, or who decides on changes to be
 merged.

 Currently all BIP changes have to go through the Bitcoin Core team,
 which is a narrow bottleneck and makes little sense when you think
 about it. But I don't want to go back to the wiki state in which
 everyone can make arbitrary changes to any BIP - we need to distribute
 the process somehow.

 I'd like to propose to make the author (or someone they delegate to)
 the primary contact for each BIP. They should comment on changes, and
 either accept or reject them. If they accept them, the change will be
 merged.

 Of course this means that there is a responsibility for the author to
 adhere to BIP 1. For example if your BIP is final, don't allow any
 technical changes. To do small clarifications, spelling or adding
 implementations or examples is OK, but changing or adding to a
 protocol is not - this needs a new BIP. Changing your BIP status
 without community consensus is also not OK.

 B) I also think it makes sense to move the BIP discussion (both about
 the BIP process and individual BIPs) to a separate mailing list.

 bitcoin-development currently has a dual function: discussion of
 Bitcoin Core implementation concerns, as well as global changes to
 Bitcoin (in the form of BIPs).

 This makes the list too busy for some people, but it is critical that
 everyone writing a Bitcoin node or client is up-to-date with proposals
 and can comment on them.


This all makes a lot of sense to me, and would help a lot with the
workflow.  Unfortunately github pulls and issues really have nothing
to faciltate a multistage workflow... e.g. where something can go
through several steps.

We're also having problems with people failing to comment on things,
not even I looked at this and have no opinion, which is really
obstructing things.

--
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] Malleable booleans

2014-10-14 Thread Gregory Maxwell
On Tue, Oct 14, 2014 at 7:27 AM, Thomas Zander tho...@thomaszander.se wrote:
 What about rejecting a script where a bool is not explicitly zero or one?

I believe this is what he actually meant.

--
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] Malleable booleans

2014-10-13 Thread Gregory Maxwell
On Tue, Oct 14, 2014 at 2:34 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
 Hi all,

 while working on a BIP62 implementation I discovered yet another type
 of malleability: the interpretation of booleans.

 Any byte array with non-zero bytes in it (ignoring the highest bit of
 the last byte, which is the sign bit when interpreting as a number) is
 interpreted as true, anything else as false. Other than numbers,
 they're not even restricted to 4 bytes. Worse, the code for dealing
 with booleans is not very consistent: OP_BOOLAND and OP_BOOLOR first
 interpret their arguments as numbers, and then compare them to 0 to
 turn them into boolean values.

 This means that scripts that use booleans as inputs will be inherently
 malleable. Given that that seems actually useful (passing in booleans
 to guide some OP_IF's during execution of several alternatives), I
 would like to change BIP62 to also state that interpreted booleans
 must be of minimal encoded size (in addition to numbers).

 Any opinions for or against?


An argument against is that you can currently do something like this:


OP_DUP OP_IF OP_HASH160 PUSH OP_EQUALVERIFY OP_ELSE  stuff
OP_CHECKSIGVERIFY OP_ENDIF

E.g. if your input is non-zero you're giving a hash, if it's zero
you're skipping that and running another branch.

Of course you could just encode your script another way... but by that
same logic you can 1 OP_QUALVERIFY to bool-ize any input in the true
path.  The inconsistency in handling makes it more likely that script
authors will screw up with bad (for them) consequences, however.

[I just asked pieter out of band to clarify if he means minimal
encoded size, or must be 0 or 1 minimally encoded... as the former
doesn't fix the malleability, but the later is more disruptive]

--
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] Request for review/testing: headers-first synchronization in Bitcoin Core

2014-10-12 Thread Gregory Maxwell
On Sat, Oct 11, 2014 at 11:34 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
 * Parallel block downloading (much faster sync on typical network 
 connections).

Much faster is an understatement. Benchmarking here shows one hour
five minutes syncing to 295000.   Old code isn't even at 25 after
7 hours.


(I'm using 295k as the target here because after that point ecdsa
dominates, and then your 6+x faster libsecp256k1 makes more of a
difference)

--
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://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 Gregory Maxwell
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back a...@cypherspace.org wrote:
 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.

Right, ... moreover, even with all the malleability fixes, they only
work if you refrain from using certain features (e.g. cannot do an
anyone-can-pay) and we cannot be completely sure all accidental
vectors for malleability are gone (we've been unable to construct a
proof that our strengthening of ECDSA turns it into a strong
signature, though it seems likely).

Having the locktime control in a scriptPubKey sidesteps all those
limitations and simplifies protocols (e.g. not requiring some three
step state machine and a bunch of risky validation code to be sure a
refund you receive is actually workable).

--
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


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

2014-10-09 Thread Gregory Maxwell
On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd p...@petertodd.org wrote:
 Speaking of, can anyone think of an example of a complex transaction
 use-case that is affected by malleability which can't be fixed by
 CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head
 trying to think of a good example.

Yea, no problem since we lack covenants.

Or a least no problem making an example, maybe you'll find it too
contrived since I'm not sure what would motivate it:

You and I put 5 btc each into a kickstarter-escrow to pay Alice+some
oracle that decides if alice did her job.  But if a timeout expires
before alice manages to get the sign off the funds must be returned
completely to their original payers.

Returning them to in two outputs, one to me, one to you is trivial
with a pre-signed refund.

You could make there be multiple alice outputs or refund, but then you
can't guarantee an atomic reversal (e.g. maybe Alice gets half if we
race).

--
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


Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-07 Thread Gregory Maxwell
On Tue, Oct 7, 2014 at 7:04 PM, Sergio Lerner sergioler...@certimix.com wrote:
 Using the my previous terminology, automatic fee-sharing (ORBS) is a
 solution to the freeze problem (FRONT) but opens the windows to
 CHAKIDO double-spending. and CHAKIDO double-spending is a much worse
 problem than FRONT.

I'm not following this. Perhaps I'm getting lost in terminology here.

It's already to provide double spending bounties to greedy-rational
miners, via a simple approach that has been known since at least early
in 2011.I pay someone then create a later fraudulent doublespend
which is nlocked at the height the original payment occurred, paying
large fees. Then I spend the output of the fraudulent spend nlocked
one block higher, and spend the output of that one again, nlocked one
block higher, and so on... each step paying fees.

A hypothetical purely greedy miner which considers all sequences of
acceptable forks and transactions would see that they have higher
expected returns assisting the theft (assuming the honest party
doesn't fight back by also adopting a similar strategy), at least if
the population of greedy miners is large relative to altruistic ones.

I don't see how miners being able to roll forward fees makes anything
worse, since the transactions themselves can also roll forward fees.

--
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


Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-05 Thread Gregory Maxwell
On Sun, Oct 5, 2014 at 4:00 PM, Sergio Lerner sergioler...@certimix.com wrote:
 I would like to share with you a vulnerability in the Bitcoin protocol I've
 been thinking of which might have impact on the future of Bitcoin. Please
 criticize it!
 The Freeze on Transaction Problem

I should point you to some of the tools that have been discussed in
the past which are potentially helpful here:

The first is the use of locktime on normal transactions.  This
behavior is already in Bitcoin core git:   The idea is that users of
the system should locktime their transaction at a point as high as
they expect it to get included.  If used well this means that there
should always be a base of fees which can only be collected by future
blocks, creating an incentive to move forward.  This may be
particularly effective if the limitations on blocksize mean that there
is always a healthy standing load.

The second is having block commitments in transactions
(https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas). The idea is that
the data under signature in a transaction could commit to some recent
block which _must_ be in the chain or the transaction's fee cannot be
collected (or, at least, not all of the fee).  This would allow
transacting users to 'vote with their fees' on the honest chain.
Arguably this could also be used to pay for doublespending forks, but
you can already do that by paying fees via a chain that stems from the
doublespend.  This greatly complicates strategy for forking miners,
since future transactions which you haven't even seen yet may have
fees conditional on the honest chain.

I think both of the above are obviously useful, should be done, but
don't completely address the concern, they may be adequate.

The third is fee forwarding.  An example form would be that the miner
gets half the fees, the rest are added to a pool which pays out half
in every successive block.  This can prevent unusually high fees from
making as much reorg pressure and more correctly models what people
would like to pay for: getting their txn buried.   The huge problem
with this class is that miners can demand users pay fees out of
band, e.g. with additional txouts (just make a different version of
the tx for each miner you wish to pay) and escape the process.  I have
had some notions about fees that come in the form of adjusting the
difficulty of creating a block slightly (which is something that can't
be paid out of band), but such schemes becomes very complicated very
fast.  I am unsure if any form of fee forwarding is workable.

Something you might want to try to formalize in your analysis is the
proportion of the network which is rational vs
honest/altruistic.  Intuitively, if there is a significant amount
of honest hashrate which is refusing to aid the greedy behavior even
at a potential loss to themselves this strategy becomes a loser even
for the purely greedy participants. It would be interesting to
characterize the income tradeoffs for different amounts of altruism,
or whatever convergence problems an attempt by altruistic
participaints to punish the forkers might create.

--
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


Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-05 Thread Gregory Maxwell
On Sun, Oct 5, 2014 at 4:40 PM, Gregory Maxwell gmaxw...@gmail.com
 I should point you to some of the tools that have been discussed in
 the past which are potentially helpful here:

Ah, I should also mention a somewhat more far out approach which helps
here as a side effect:

If transactions were using the BLS short signature scheme (a very
compact EC signature based on pairing cryptography) there is a scheme
so that you securely can aggregate the signatures from multiple
messages into a single signature (also has nice bandwidth properties)
and still verify it. It also works recursively, so aggregates can be
further aggregated.

A consequence of this is that you cannot remove a (set of)
signature(s) from the aggregate without knowing the (set of)
signature(s) by itself.

If the coinbase transaction also contains a signature and if some
non-trivial portion of fee paying users relayed their transaction
privately to miners it,  then other miners would only learn of the
transaction in aggregated form.  Without knowing the transaction by
itself they could not pull it out of a block separately from the
coinbase payment and add it to their own block in a fork.

(In general this provides several anti-censorship properties, since if
someone passed you an aggregate of several transactions you could only
accept or reject them as a group unless you knew the members
separately).

The use in aggregation can be done in a way which is purely additive
(e.g. in addition to regular DSA signatures), so even if the
cryptosystem is broken the only harm would be allowing
disaggregation... but unfortunately the pairing crypto is pretty slow
(verification takes a 0.5ms-ish pairing operation per transaction).

--
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


Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-05 Thread Gregory Maxwell
On Sun, Oct 5, 2014 at 4:54 PM, Jorge Timón jti...@blockstream.io wrote:
 In any case, it is interesting to think about this things since mining
 subsidies will eventually disappear and then transaction fees will
 ALWAYS be higher than subsidies.

You can imagine that instead of subsidy Bitcoin came with a initial
set of nlocktimed transactions that pay fees, one block at a time, for
each block from the start until the subsidy goes away.

Perhaps that mental model might make it clear why some people think
that the nlocked transactions and the block size being lower than the
instant offered demand (there is always a backlog) are both things
which address the concern of this thread. :)

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
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-03 Thread Gregory Maxwell
On Fri, Oct 3, 2014 at 7:28 AM, Matt Whitlock b...@mattwhitlock.name wrote:
 Is there a reason why we can't have the new opcode simply replace the top 
 stack item with the block height of the txout being redeemed?

This would not be soft-forking compatible.

It also would be unsafe in that it would result in transactions which
once mined could not be restored in a reorg through no fault of the
participants, which makes the coins less fungible and differently safe
to accept. It risks creating weird pressures around immediate block
admission since a one additional block delay could forever censor such
a transaction (E.g. increases the power of single miners to censor or
steal). Avoiding this is a conscious decision in Bitcoin and also part
of the justification for the 100 block maturity of newly generated
coins.

It also would require violating the script/transaction/block layering
more substantially, complicating implementations, and making the
validity of a script no longer a deterministic pure function of the
transaction.

Avoiding these issues is a conscious design in OP_CHECKLOCKTIMEVERIFY.
I would strenuously oppose a proposal which failed in any of these
respects.

 Then arbitrary logic could be implemented, including output cannot be spent 
 until a certain time and also output can ONLY be spent until a certain 
 time, as well as complex logic with alternative key groups with differing 
 time constraints.

You can already achieve the not spendable after logic with a
cancellation spend that moves the coin in the usual way. (Which
doesn't even require the participant be online, with the help of some
network service to queue unlocked transactions).

 OP_CHECKLOCKTIMEVERIFY, as conceived, seems too limited, IMHO.

It is intentionally so, and yet it covers the intended use cases;
including ones with alternative key groups, they are just not
exclusive.

--
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


Re: [Bitcoin-development] BIP43 Purpose code for voting pool HD wallets

2014-09-25 Thread Gregory Maxwell
On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier jus...@monetas.net wrote:
 Two draft information BIPs are attached.

I've pinged some people privately but also pinging the list… no
commentary on this proposal?

--
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


Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?

2014-09-15 Thread Gregory Maxwell
On Mon, Sep 15, 2014 at 3:51 PM, Matt Whitlock b...@mattwhitlock.name wrote:
 On Monday, 15 September 2014, at 5:10 pm, Thomas Zander wrote:
 So for instance I start including a bitcoin public key in my email signature.
 I don't sign the emails or anything like that, just to establish that 
 everyone
 has my public key many times in their email archives.
 Then when I need to proof its me, I can provide a signature on the content
 that the requester wants me to sign.

 That would not work. You would need to sign your messages. If you were merely 
 attaching your public key to them, then the email server could have been 
 systematically replacing your public key with some other public key, and 
 then, when you would later try to provide a signature, your signature would 
 not verify under the public key that everyone else had been seeing attached 
 to your messages.

If the server could replace the public key, it could replace the
signature in all the same places.

Please, can this stuff move to another list? It's offtopic.

--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Small update to BIP 62

2014-09-01 Thread Gregory Maxwell
On Fri, Jul 18, 2014 at 8:14 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
 Hi all,

 I've sent a pull request to make a small change to BIP 62 (my
 anti-malleability proposal) which is still a draft; see:
 * https://github.com/bitcoin/bips/pull/90 (the request)
 * https://github.com/sipa/bips/blob/bip62up/bip-0062.mediawiki (the result)

 It makes two of the 7 new rules mandatory in new blocks, even for
 old-style transactions. Both are already non-standard since 0.8.0, and
 have no use cases in my opinion.

 The reason for this change is dropping the requirement for signature
 verification engines to be bug-for-bug compatible with OpenSSL (which
 supports many non-standard encodings for signatures). Requiring strict
 DER compliance for signatures means any implementation just needs to
 support DER.

Not related to this change but the definition of rule 4 may not be
sufficiently specific— without a definition someone could reasonably
reach a different conclusion about OP_1NEGATE being a push
operation, or might even decide any operation which added to the
stack was a push operation.

Any particular reason to enforce 2 and 4 but not also 5?  Violation of
5 is already non-standard and like 2,4 should be safely enforceable.

Perhaps the rules should be reordered so that the applicable to all
transactions ones are contiguous and first?

 The first six and part of the seventh can be fixed by extra consensus rules.

This should clarify that the scriptPubkey can still specify rules that
are inherently malleable— e.g. require the input stack contain two
pushes which OP_ADD to 11.  Or a more elaborate one— a 1 of 2 check
multisig where the pubkey not selected for signing is selected by a
push in the signature. The current text seems to ignore isomorphisms
of this type. ... they're not important for what the BIP is trying to
achieve, but the document shouldn't cause people to not think that
sort of thing exists.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Reconsidering github

2014-08-23 Thread Gregory Maxwell
On Sat, Aug 23, 2014 at 1:36 PM, Paul Rabahy prab...@gmail.com wrote:
 I want go give a bit of an outsiders perspective. I thoroughly understand
 the concepts of bitcoin and am a professional programmer, but have never
 taken the time to compile my own copy of bitcoin core.

 I have looked at the pull requests on Github many times. I have cloned the
 repo to my own computer, but haven't really used that to do much. I find
 Github very easy to use, and (to me) it has the lowest bar to get more eyes
 passively looking at the code. As a security guy, I appreciate the extra
 time and effort that goes into signing commits and merges even if I have not
 personally verified the signatures. I would like to see bitcoin core
 continue to use github, but have no objection to additional mirrors of the
 repo being hosted on different sites.

Nothing suggested here would ever remove the ability to go and explore
and read the changes just as you're doing so.

Already the way it works is that our local repositories are
authoritative for each of us. (Git itself is a decentralized system
regardless of github's efforts to make it look otherwise).

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-19 Thread Gregory Maxwell
On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
justusranv...@riseup.net wrote:
 If that's not acceptable, even using TLS with self-signed certificates
 would be an improvement.

TLS is a huge complex attack surface, any use of it requires an
additional dependency with a large amount of difficult to audit code.
TLS is trivially DOS attacked and every major/widely used TLS
implementation has had multiple memory disclosure or remote execution
vulnerabilities even in just the last several years.

We've dodged several emergency scale vulnerabilities by not having TLS.

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


Re: [Bitcoin-development] Reconsidering github

2014-08-19 Thread Gregory Maxwell
On Tue, Aug 19, 2014 at 5:02 AM, Jeff Garzik jgar...@bitpay.com wrote:
 It would be nice if the issues and git repo for Bitcoin Core were not
 on such a centralized service as github, nice and convenient as it is.

 To that end, I note that Linux does its own git repo, and now requires
 2FA: 
 http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication

 As a first step, one possibility is putting the primary repo on
 bitcoin.org somewhere, and simply mirroring that to github for each
 push.

The obvious thing to do is setup the second repository and get it
going. Git doesn't really care all that much whats primary.  If we
have a working workflow elsewhere then making a change won't be a leap
of faith.

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


Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-19 Thread Gregory Maxwell
On Tue, Aug 19, 2014 at 4:39 PM, Justus Ranvier
justusranv...@riseup.net wrote:
 While the rest of the 'net is busy deprecating HTTP and all other
 unencrypted transport methods, why is it(*) even a debate?

I think it's desirable (and you can go look in #bitcoin-dev logs for
me talking about it in the past)— but all of engineering is
tradeoffs... and the ones involved here don't make it a high priority
in my book, esp when people should be using Bitcoin over tor in any
case, which provides better privacy and also covers encrypt + auth.

In general I think authentication is more important than encryption,
since authentication is table stakes required for a number of
anti-partitioning-attack measures.  My past thinking on opportunistic
encryption is that once you're authenticating also encrypting would be
fairly little work, but it should be auth that drives that kind of
effort.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Reconsidering github

2014-08-19 Thread Gregory Maxwell
On Tue, Aug 19, 2014 at 6:26 PM, Troy Benjegerdes ho...@hozed.org wrote:
 If a project cannot be organized enough to run its own hosting/web presense/
 counterintelligence/security that starts with installing an OS and patching
 kernels, then it is really not wise for me to trust my financial future to
 software written by such a group.

Please take the hyperbole elsewhere. Good dialog it's going to happen
with the insults and adhomenem.

Regardless of where the repositories live their integrity is protected
by digital signatures and cryptographic hashes. Running them elsewhere
can be virtuous for other reasons, but it doesn't play much into this
since the same tools must be used to guarantee their security.

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Outbound connections rotation

2014-08-18 Thread Gregory Maxwell
On Mon, Aug 18, 2014 at 9:46 AM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote:
 Hi there,
 I'd like to start a discussion on periodic rotation of outbound connections.
 E.g. every 2-10 minutes an outbound connections is dropped and replaced
 by a new one.

Connection rotation would be fine for improving a node's knoweldge
about available peers and making the network stronger against
partitioning.

I haven't implemented this because I think your motivation is
_precisely_ opposite the behavior. If you keep a constant set of
outbound peers only those peers learn the origin of your transactions,
and so it is unlikely that any particular attacker will gain strong
evidence. If you rotate where you send out your transactions then with
very high probability a sybil pretending to be many nodes will observe
you transmitting directly.

Ultimately, since the traffic is clear text, if you expect to have any
privacy at all in your broadcasts you should be broadcasting over tor
or i2p.

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


[Bitcoin-development] Fwd: Outbound connections rotation

2014-08-18 Thread Gregory Maxwell
On Mon, Aug 18, 2014 at 10:30 AM, Pieter Wuille pieter.wui...@gmail.com wrote:
 Yes, I believe peer rotation is useful, but not for privacy - just for
 improving the network's internal knowledge.

 I haven't looked at the implementation yet, but how I imagined it would be
 every X minutes you attempt a new outgoing connection, even if you're
 already at the outbound limit. Then, if a connection attempt succeeds,
 another connection (according to some scoring system) is replaced by it.
 Given such a mechanism, plus reasonable assurances that better connections
 survive for a longer time, I have no problem with rotating every few
 minutes.

Previously when you and I had discussed this I'd proposed that some
number (say) four of the most long lived connections which had proven
themselves useful (e.g. by relaying blocks) be pinned up and not be
eligible for dropping. By protecting some subset of peers you
guarantee that an attacker which simply introduces a lot of nodes
cannot partition the network which existed prior to when the attack
started.

On Mon, Aug 18, 2014 at 10:27 AM, Mike Hearn m...@plan99.net wrote:
 I think the attack Ivan is talking about does not require sybil attacks to 
 work though, just listening to lots of peers

I may not be understanding you. Might be a definitions thing, I'm
using the definition: A sybil attack is when a party takes on many
identities (nodes) in the network.

What ivan highlights is a bit of a tradeoff between concealing
identities and linkages.  Relaying transactions through only a single
peer ever (until that one is no longer on the network) is the best
strategy for concealing your identity (ignoring tor and what not), as
only that peer learns anything about your identity.  But it may reveal
a lot about how different transactions are linked, since people
observing that peer will observe that your transactions are
correlated.

The optimal strategy for avoiding linkages (ignoring tor, again), is
to randomly pick a different peer for each transaction and relay the
transaction only to that peer.  This can (and probably should) be
distinct from your normal network connectivity.

Probably for anti-linkage I'd suggest that a facility for that kind of
announcement should be done. If used over tor it would also protect
your identity.   Then the regular topology of the network can be
optimized for learning and partition resistance.

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


Re: [Bitcoin-development] Outbound connections rotation

2014-08-18 Thread Gregory Maxwell
On Mon, Aug 18, 2014 at 11:37 AM, Ivan Pustogarov
ivan.pustoga...@uni.lu wrote:
 the same for a long time, an attacker which does not have any peers at all
 but just listens the Bitcoin network can link together differed BC addresses
 and learn the IP of the client.

I don't understand what you're talking about here; if you have no peer
at all you will learn nothing about the Bitcoin network.

Can you clarify?


 The 8 entry peers are unique per client so if two
 users share the same IP, they can be distinguished.

What mechanism are you referring to specifically?

 Outbound connections are still rotated from time to time due to remote side
 disconnections. Plus outbound connections do not survive BC client restarts
 (unlike Tor Guard nodes).

On our initial connections we do have a preference for nodes we knew
were up recently. This could be made further. That the current
behavior isn't great isn't an argument for making it worse on that
dimension.

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


Re: [Bitcoin-development] Outbound connections rotation

2014-08-18 Thread Gregory Maxwell
On Mon, Aug 18, 2014 at 1:33 PM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote:
 The attack I'm trying to address is described here: 
 https://www.cryptolux.org/index.php/Bitcoin
 It was discussed here: https://bitcointalk.org/index.php?topic=632124.0

 It uses the following observation. Each NATed client connects to the Bitcoin 
 network
 through 8 entry peers; he also advertises his public IP address to these 
 peers which
 allows an attacker to make the mapping 8-entry-peers, client-IP-address.

I'm afraid I'm losing you here.  The node advertises himself to
everyone he is connected to and in/or out, those nodes pass along
those advertisements.  When I receive an advertisement from a node I
do not know how far away the advertised peers is, presumably I can
accurately exclude it from being 0-hops— itself—) 1 or more should be
indistinguishable. Is there a reason that they're distinguishable that
I'm missing?

Can you explain to me how you propose to produce this mapping?

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


Re: [Bitcoin-development] Outbound connections rotation

2014-08-18 Thread Gregory Maxwell
On Mon, Aug 18, 2014 at 2:02 PM, Ivan Pustogarov ivan.pustoga...@uni.lu wrote:
 For each neighbour, a Bitcoin peer keeps the history of addresses that
 it forwarded to the neighbour. If an address was already forwarded
 to a neighbour it is not retransmitted again.

Okay, sorry, I thought you were saying something else. I understand.

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


Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-31 Thread Gregory Maxwell
On Thu, Jul 31, 2014 at 1:47 PM, Kaz Wesley kezi...@gmail.com wrote:
 trip to request the missing tx; if we could somehow get the What's
 the Difference approach to effectively operate on full transactions
 instead

I explain how to do this on the network block coding page.

Given that you know the sizes and orders of the transactions (e.g.
from a reconciliation step first), the sender sends non-syndromic
forward error correcting code data somewhat larger than their estimate
of how much data the user is missing.  Then you drop the data you know
into place and then recover the missing blocks using the fec.

There is no overhead in this approach except for FEC blocks that are
incompletely missing (and so must be completely discarded), and the
need to have the transmitted the transaction list and sizes first.
(note, that just more bandwidth, not an additional round trip).

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-31 Thread Gregory Maxwell
On Thu, Jul 31, 2014 at 2:41 PM, Kaz Wesley kezi...@gmail.com wrote:
 the need to have transmitted the transaction list [..] first

 32 bits per transaction is at least double the communication overhead
 of the simple approach, and only offers a bound on the probability of
 needing a round trip.

(e.g. from a reconciliation step first) the list can be communicated
in the space roughly equal to the size of the difference in sets plus
coding the permutation from the permissible orderings.   If you did
have some simple approach that guaranteed that some transactions
would be present, then you could code those with indexes... the FEC
still lets you fill in the missing transactions without knowing in
advance all that will be missing.   (Also, the suggestion on the
network block coding page of using part of a cryptographic permutation
as the key means that for unknown transactions the transmission of the
new unknown keys is always goodput— doesn't add overhead)

It's only a bound but you can pick whatever bound you want,
including— if you send data equal to the missing amount, then it'll be
always successful, but no bandwidth savings.   Though if the transport
is unordered (e.g. UDP or non-blocking SCTP) even sending 100% of the
missing amount can save time by eliminating a round trip that might
otherwise be needed for a retransmission.

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-31 Thread Gregory Maxwell
On Thu, Jul 31, 2014 at 3:27 PM, Kaz Wesley kezi...@gmail.com wrote:
 the FEC still lets you fill in the missing transactions without knowing in 
 advance all that will be missing.

 I don't see why we need to solve that problem, since the protocol
 already involves exchanging the information necessary to determine
 (with some false positives) what a peer is missing, and needs to
 continue doing so regardless of how blocks are transmitted.

False positives, and if you have more than one peer— false negatives.
(or a rule for what you must keep which is conservative in order to
avoid creating huge storage requirements— but then also has false
negatives).


 As far as I can tell, channel memory sparseblocks achieve most of the
 possible bandwidth savings, and when FEC-based mempool synchronization
 is implemented its benefits can be applied to the sparseblocks by
 resetting the channel memory to the mutual mempool state each time
 mempool differences are exchanged. Am I missing a benefit to doing FEC
 at block forwarding time that can't be realized by FEC-based mempool
 synchronization, implemented separately from channel-memory based
 index-coding?

Yes, minimizing latency in the face of multiple peers.

Otherwise no. And certantly no reason to to implement something simple first.

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] deterministic transaction expiration

2014-07-31 Thread Gregory Maxwell
On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock b...@mattwhitlock.name wrote:
 It would make more sense to introduce a new script opcode that pushes the 
 current block height onto the operand stack. Then you could implement 
 arbitrary logic about which blocks the transaction can be valid in. This 
 would require that the client revalidate all transactions in its mempool 
 (really, only those making use of this opcode) whenever the chain tip changes.

Transactions that become invalid later are have pretty severe
consequences because they might mean that completely in an absence of
fraud transactions are forever precluded due to a otherwise harmless
reorg.

While there may be uses for that, the resulting outputs should be
considered differently fungible— like coinbases which are immature—
and should probably be only used with great caution... not as a
mechanism for ordinary transactions.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] deterministic transaction expiration

2014-07-31 Thread Gregory Maxwell
On Thu, Jul 31, 2014 at 8:26 PM, Matt Whitlock b...@mattwhitlock.name wrote:
 I understand what you're saying, but I don't understand why it's a problem. 
 Transactions shouldn't be considered final until a reasonable number of 
 confirmations anyway, so the possibility that an accepted transaction could 
 become invalid due to a chain reorganization is not a new danger. Ordinary 
 transactions can similarly become invalid due to chain reorganizations, due 
 to inputs already having been spent in the new branch.

A distinction there is that they can only become invalid via a
conflict— replaced by another transaction authored by the prior
signers. If no other transaction could be created (e.g. you're a
multisigner and won't sign it again) then there is no such risk.  It
now introduces chance events (act of god) into the mix where they
they didn't exist before.  Basically it takes was what is a very loose
one way coupling and makes it much tighter. I'm sure if you spend a
bit thinking you can come up with some more corner cases that it would
expose— e.g. flooding the network with unrelated high fee transactions
in order to push a transaction out to where it can never be mined at
all.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

2014-07-28 Thread Gregory Maxwell
On Mon, Jul 28, 2014 at 5:31 AM, Robert McKay rob...@mckay.com wrote:
 I don't think Sybil attack is the right term for this.. there is only
 one IP address.. one identity.

The bitcoin protocol is more or less identityless. It's using up lots
of network capacity, number of sockets is as pretty close as you
get.

 I'm not even sure that this behaviour can be considered abuse.. it's
 pretty much following the rules and maybe even improving the transaction
 and block propagation.

It isn't relaying transactions or blocks as far as anyone with a
connection to it can tell.

and sure, probably not much to worry about— people have been running
spy nodes for a long time, at least that much is not new.

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

2014-07-27 Thread Gregory Maxwell
On Sun, Jul 27, 2014 at 7:12 PM, Jeremy jlru...@mit.edu wrote:
 Hey,

 There is a potential network exploit going on. In the last three days, a
 node (unnamed) came online and is now processing the most traffic out of any
 tor node -- and it is mostly plaintext Bitcoin traffic.

 http://torstatus.blutmagie.de/router_detail.php?FP=0d6d2caafbb32ba85ee5162395f610ae42930124

 Alex Stamos (cc'ed) and I have been discussing on twitter what this could
 mean, wanted to raise it to the attention of this group for discussion.

 What we know so far:

 - Only port 8333 is open
 - The node has been up for 3 days, and is doing a lot of bandwidth, mostly
 plaintext Bitcoin traffic

How do you know what traffic it's actually doing.

 - This is probably pretty expensive to run? Alex suggests that the most
 expensive server at the company hosting is 299€/mo with 50TB of traffic

I'm confused as to how its doing anything at all, as it doesn't have
the exit flag. (IIRC, Tor directories won't give you the exit flag
unless you exit 80/443 to a pretty substantial chunk of IPv4 space).
Because of this no normal tor node should be selecting it as an exit.

Could this just be lying about its traffic levels?

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

2014-07-27 Thread Gregory Maxwell
On Sun, Jul 27, 2014 at 7:40 PM, Peter Todd p...@petertodd.org wrote:
 Anyway, just goes to show that we need to implement better incoming
 connection limiting. gmaxwell has a good scheme with interactive
 proof-of-memory - where's your latest writeup?

Or its a complete snipe hunt, I'm unable to find any nodes with it
connected to them. Does anyone here have any?

Last discussion on the measures for anti-global-resource-consumption
was at https://bitcointalk.org/index.php?topic=310323.0  but it hasn't
seemed to be a huge issue such that adding more protocol surface area
was justified.

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

2014-07-27 Thread Gregory Maxwell
On Sun, Jul 27, 2014 at 7:45 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
 Or its a complete snipe hunt, I'm unable to find any nodes with it
 connected to them. Does anyone here have any?
[unimportant update] Turns out that my IPv4 nodes already have
iptables blocking of that subnet, presumably due to other misconduct
there, which might be why I'm not seeing it.

Several other people appear to be observing it, and all it seems to be
doing is listening without sending transactions— e.g. surveillance
node... not the first time thats happened, but the weird tor
non-exit-flagged-exit adds a fun level of intrigue to it.

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic

2014-07-27 Thread Gregory Maxwell
On Sun, Jul 27, 2014 at 7:54 PM, m...@bitwatch.co m...@bitwatch.co wrote:
 These website list Tor nodes by bandwidth:

 http://torstatus.blutmagie.de/index.php
 https://torstatus.rueckgr.at/index.php?SR=BandwidthSO=Desc

 And the details reveal it's a port 8333 only exit node:
 http://torstatus.blutmagie.de/router_detail.php?FP=0d6d2caafbb32ba85ee5162395f610ae42930124

As I pointed out above, — it isn't really.  Without the exit flag, I
believe no tor node will select it to exit 8333 unless manually
configured. (someone following tor more closely than I could correct
if I'm wrong here)


 blockchain.info has some records about the related IP going back to the
 end of this May:

 https://blockchain.info/ip-address/5.9.93.101?offset=300

dsnrk and mr_burdell on freenode show that the bitnodes crawler showed
it accepting _inbound_ bitcoin connections 2-3 weeks ago, though it
doesn't now.

Fits a pattern of someone running a bitcoin node widely connecting to
everyone it can on IPv4 in order to try to deanonymize people, and
also running a tor exit (and locally intercepting 8333 there),  but I
suspect the tor exit part is not actually working— though they're
trying to get it working by accepting huge amounts of relay bandwidth.

I'm trying to manually exit through it so I can see if its
intercepting the connections, but I seem to not be able.

Some other data from the hosts its connecting out to proves that its
lying about what software its running (I'm hesitant to just say how I
can be sure of that, since doing so just tells someone how to do a
more faithful emulation; so that that for whatever its worth).

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Time

2014-07-24 Thread Gregory Maxwell
On Thu, Jul 24, 2014 at 7:35 PM, Aaron Voisine vois...@gmail.com wrote:
 The upcoming release of breadwallet uses the height of the blockchain to
 enforce timed pin code lockouts for preventing an attacker from quickly
 making multiple pin guesses. This prevents them changing the devices system
 time to get around the lockout period.

Is breadwallet tamper resistant  zero on tamper hardware? otherwise
this sounds like security theater I attach a debugger to the
process (or modify the program) and ignore the block sourced time.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Policy for DNS seeds

2014-07-21 Thread Gregory Maxwell
On Mon, Jul 21, 2014 at 12:24 PM, Peter Todd p...@petertodd.org wrote:
 Might be worthwhile to also write an Expectations for DNSSeed users
 outlining what security properties the seeds actually have, and what
 kind of attacks are possible.

Agreed.  I've seen some amount of use of dnsseeds which I would
consider inadvisable considering their weakness.

 Many users would be better served with
 seeds that offer authenticated and encrypted connections to the seeds
 for instance. (esp. if they're using authed/encrypted connections to
 nodes, e.g. Tor hidden services)

Also agreed, we ought to have a separate onionseed process for hosts
which can reach hidden services which would be inherently
authenticated and somewhat more anonymous. The existing introduction
method already doesn't work well for onlynet=onion hosts, so that
would be a good place to start.

 1. The DNSseed results must consist exclusively of fairly selected and
 functioning Bitcoin nodes from the public network to the best of the
 operators understanding and capability.

 Along the lines of my above point, for Bitcoin Core users of the
 DNSSeeds what constitutes a functioning Bitcoin node is much more
 broad than what other users might need.

I was deliberately vague here in that I'm trying to avoid foreclosing
reasonable activities like omitting nodes which are uselessly slow,
diverged from the network, or running very old software.  The test I'm
suggesting is that if why am I doing this is to connect users to
functioning nodes then it's probably okay, but if its to achieve some
other end— probably not.

 Note that singling out a group of hosts to receive different results
 with DNS is especially difficult as you'll be usually singling out
 different ISP's rather than hosts themselves. That said if we ever start
 operating HTTPS or similar seeds this expectation will become even more
 relevant for them.

Yes, this is one of the reasons we use DNS (and also one of the
reasons the document suggests a non-zero minimum ttl)... but belt and
suspenders, even though technical measures are protective here it's
good to make it clear that this isn't acceptable.

 While there have been
 suggestions to use the testnet seeds for testing vulnerabilities, the
 public discussion clause should suffice to allow those exceptions.

Yep. That was the intent. (well not testnet, but the notion that if
there really were a good reason to do something else a discussion
should cover it)

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire

2014-07-19 Thread Gregory Maxwell
On Fri, Jul 18, 2014 at 8:06 PM, Emin Gün Sirer el33th4...@gmail.com wrote:

 Most things I've seen working in this space are attempting to minimize
 the data transfered. At least for the miner-interested case the round
 complexity is much more important because a single RTT is enough to
 basically send the whole block on a lot of very relevant paths.

 Agreed. Yaron's scheme is magical because it is non-interactive. I send you
 a packet of O(expected-delta) and you immediately figure out the delta
 without further back and forth communication, each requiring an RTT.

Oh that does sound interesting— its the property I was trying to
approximate with the FEC..  It achieves the one-shot, but there is
overhead. One plus we have is that we can do some tricks to make some
computational soundness arguments that we'd actually get average
performance on average (e.g. that someone can't author transactions in
such a way as to jam the process).

 In any case, I have no horse here (I think changing the client so it's
 multithreaded is the best way to go), but Yaron's work is pretty cool and
 may be applicable.


Thank you, I've certantly queued the paper for reading.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Small update to BIP 62

2014-07-19 Thread Gregory Maxwell
On Fri, Jul 18, 2014 at 9:38 PM, Aaron Voisine vois...@gmail.com wrote:
 Well, you could always create a transaction with a different signature
 hash, say, by changing something trivial like nLockTime, or changing
 the order of inputs or outputs. Is that what you're talking about? Or
 is there some sophistry I'm ignorant of having to do with the elliptic
 curve math in the signature itself?

No, though thats true too. I was talking about the properties of the DSA nonce:

An attacker is not obligated to follow your protocol unless you can
prevent him. You can _say_ use derandomized DSA all you like, but he
can just not do so, there is no (reasonable) way to prove you're using
a particular nonce generation scheme without revealing the private key
in the process. The verifier cannot know the nonce or he can trivially
recover your private key thus he can't just repeat the computation
(well, plus if you're using RFC6979 the computation includes the
private key), so short of a very fancy ZKP (stuff at the forefront of
cryptographic/computer science) or precommiting to a nonce per public
key (e.g. single use public keys), you cannot control how a DSA nonce
was generated in the verifier in a way that would prevent equivalent
but not identical signatures.

(I believe there was some P.O.S. altcoin that was vulnerable because
of precisely the above too— thinking specifying a deterministic signer
would prevent someone from grinding signatures to improve their mining
odds... there are signature systems which are naturally
randomness-free: most hash based signatures and pairing short
signatures are two examples that come to mind... but not DSA, schnorr,
or any of their derivatives).

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Signature with negative integer?

2014-07-19 Thread Gregory Maxwell
On Fri, Jul 18, 2014 at 9:33 PM, Richard Moore m...@ricmoo.com wrote:
 Hey all,
 I'm wondering if anyone can help explain to me tx 
 70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d...

A rather timely post.  See the other thread on BIP0062. What you're
looking at is an example of a well-known-to-implementers-here where
invisible and undocumented over permissiveness in interpreting
invalid encoding in a cryptographic library (OpenSSL in our case)
which would have been probably-not-unwelcome in many other protocol
uses results in an unexpected consensus critical normative rule in
Bitcoin.

Modern releases of Bitcoin core will no longer relay or mine them but
they're still valid in blocks should they show up.

BIP62 proposes, among other things, soft-forking (backwards
compatible) changes that will strictly limit the DER encoding to avoid
ambiguity. If adopted by the network implementations would still need
to grandfather in existing weird transactions but could do so on a
txid by txid basis since there would be no more broken encoding
permitted in blocks, and use different DER decoding code without risk
of consensus inconsistency (so long as it uses der decoding which is
functionally identical to what BIP62 requires— of course).

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


  1   2   3   4   >