Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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.
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
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
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
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
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
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
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
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
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
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...
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] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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)
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)
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)
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)
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire
On Fri, Jul 18, 2014 at 5:54 PM, Emin Gün Sirer el33th4...@gmail.com wrote: The problem being tackled here is very similar to set reconciliation, where peer A thinks that the set of transactions that should be in the block is S_A, 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. I know much better is possible (see up-thread where I linked to an old proposal to use forward error correction to transfer with low data transfer (but not optimal) and negligible probability of needing a round-trip, with a tradeoff for more overhead for lower roundtrip probability). -- 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
On Fri, Jul 18, 2014 at 3:03 PM, Aaron Voisine vois...@gmail.com wrote: 9. New signatures by the sender I'm not suggesting it be required, but it would be possible to mitigate this one by requiring that all signatures deterministically generate k per RFC6979. I'm using this in breadwallet. Nope. Your homework assignment is to explain why. :) -- 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
