Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe. On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson andr...@petersson.at wrote: I have some experience here. If you are seriously suggesting these measures, you might as well kill retail transactions altogether. In practice, if a retail place starts to accept bitcoin they have a similar situation as with cash, only that the fraud potential is much lower. (e.g. 100-dollar bill for a sandwich might turn out fake later) and the fraud frequency is also much lower. 0-conf concerns were never a problem in practice. except for 2-way atms i have never heard of a problem that was caused by double spends. while adding these measures is generally positive, requiring them means excluding 99.9% of the potential users. so you might as well not do it. RBF as implemented by F2Pool just flat out lowers Bitcoins utility value. So it's a bad thing. for any online or automated system, waiting for a handful of confirmations was always recommended practice. Am 19.06.2015 um 22:39 schrieb Matt Whitlock: Retail POS merchants probably should not be accepting vanilla Bitcoin payments, as Bitcoin alone does not (and cannot) guarantee the irreversibility of a transaction until it has been buried several blocks deep in the chain. Retail merchants should be requiring a co-signature from a mutually trusted co-signer that vows never to sign a double-spend. -- ___ 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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn m...@plan99.net wrote: The first issue is how are decisions made in Bitcoin Core? I struggle to explain this to others because I don't understand it myself. Is it a vote of people with commit access? Is it a 100% agreement of core developers and if so, who are these people? Is it whoever reverts the change last? Could I write down in a document a precise description of how decisions are made? No, and that's been a fairly frustrating problem for a long time. There is a quote from United States Supreme Court Justice Potter Stewart to describe his threshold test for obscenity which is relevant here: I know it when I see it. It is hard certainly, and perhaps even impossible to write down a system of rules that is used to resolve every dispute among core developers. But that doesn't mean it isn't obvious to all the participants what is going on. If a contentious change is proposed, and if after sufficient debate there are still members of the technical community with reasoned, comprehensible objections who are not merely being obstinate in the views -- a neutral observer would agree that their concerns have not been met -- then there is a lack of consensus. If there was some sort of formal process however, the system wouldn't work. Rules can be gamed, and if you add rules to a process then that process can be gamed. Instead we all have a reasonable understanding of what technical consensus is, and we all know it when we see it. Where we do not see it, we do not proceed. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com wrote: The whole point is getting out in front of the need, to prevent significant negative impact to users when blocks are consistently full. To do that, you need to (a) plan forward, in order to (b) set a hard fork date in the future. Or alternatively, fix the reasons why users would have negative experiences with full blocks, chiefly: * Get safe forms of replace-by-fee and child-pays-for-parent finished and in 0.12. * Develop cross-platform libraries for managing micropayment channels, and get wallet authors to adopt * Use fidelity bonds, solvency proofs, and other tricks to minimize the risk of already deployed off-chain solutions as an interim measure until: * Deploy soft-fork changes for truly scalable solutions like Lightning Network. Not raising the block size limit does not mean doing nothing to solve the problem. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers
Matt, I for one do not think that the block size limit should be raised at this time. Matt Corallo also started the public conversation over this issue on the mailing list by stating that he was not in favor of acting now to raise the block size limit. I find it a reasonable position to take that even if you feel the block size limit should be raised at some time in the future, there are reasons why now is not the best time to do it. On Thu, Jun 18, 2015 at 2:42 PM, Matt Whitlock b...@mattwhitlock.name wrote: On Thursday, 18 June 2015, at 8:31 pm, Ross Nicoll wrote: I may disagree with Mike Gavin on timescale, but I do believe there's a likelihood inaction will kill Bitcoin An honest question: who is proposing inaction? I haven't seen anyone in this whole, agonizing debate arguing that 1MB blocks are adequate. The debate has been about *how* to increase the block-size limit and whether to take action ASAP (at the risk of fracturing Bitcoin) or to delay action for further debate (at the risk of overloading Bitcoin). Even those who are arguing for further debate are not arguing for *inaction*. -- ___ 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] User vote in blocksize through fees
Peter it's not clear to me that your described protocol is free of miner influence over the vote, by artificially generating transactions which they claim in their own blocks, or conforming incentives among voters by opting to be with the (slight) majority in order to minimize fees. Wouldn't it in fact be simpler to use the dynamic block size adjustment algorithm presented to the list a few weeks back, where the miner opts for a larger block by sacrificing fees? In that way the users vote for larger blocks by including sufficient fees to offset subsidy, but as it is an economic incentives miners gain nothing by inflating the fees in their own blocks. On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd p...@petertodd.org wrote: Jeff Garzik recently proposed that the upper blocksize limit be removed entirely, with a soft limit being enforced via miner vote, recorded by hashing power. This mechanism within the protocol for users to have any influence over the miner vote. We can add that back by providing a way for transactions themselves to set a flag determining whether or not they can be included in a block casting a specific vote. We can simplify Garzik's vote to say that one of the nVersion bits either votes for the blocksize to be increased, or decreased, by some fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a nVersion bit in transactions themselves, also voting for an increase or decrease. Transactions may only be included in blocks with an indentical vote, thus providing miners with a monetary incentive via fees to vote according to user wishes. Of course, to cast a don't care vote we can either define an additional bit, or sign the transaction with both versions. Equally we can even have different versions with different fees, broadcast via a mechanism such as replace-by-fee. See also John Dillon's proposal for proof-of-stake blocksize voting: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html -- 'peter'[:-1]@petertodd.org 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 -- ___ 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] [RFC] Canonical input and output ordering in transactions
Certainly, but I would drop discussion of IsStandard or consensus rules. On Jun 6, 2015 1:24 AM, Wladimir J. van der Laan laa...@gmail.com wrote: On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote: Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance contracts among other things. Sometimes the ordering is set by the signing logic itself... But in that case (unconstrained) randomization can't be used either. This is posed as an alternative to randomization. So in that regard, the proposal still makes sense. I think this move to verifyable, deterministic methods where possible is good. Wladimir -- ___ 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
Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance contracts among other things. Sometimes the ordering is set by the signing logic itself... On Jun 5, 2015 9:43 PM, 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 -- ___ 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] Tough questions for Peter Todd, Chief Scientist {Mastercoin | Counterparty | Coinkite | Darkwallet | Viacoin}
Why is this your business or the business of anyone on this list? Take it somewhere else. On Thu, Jun 4, 2015 at 2:52 PM, Sven Berg svenb...@airmail.cc wrote: 1) Hours/week have you devoted to each project out of a 40hr work week 2) Upfront and ongoing fees for use of your name 3) Break down total amounts for each project 4) Start dates of contracts for each project 5) End dates (if applicable) 6) Current and past holdings of altcoins/appcoins (including liquidation dates) 7) Describe return on investment to investors related to your activities during employment (other than marketing/price pump) 8) Describe your involvement with Initial Coin Offers (ICO) of applicable 9) Explain rational for pursuit of ICO fund sources rather than community/established businesses (Lighthouse, legit startups, etc.) -- Berg Investigations LLC. -- ___ 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] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers
Oh it is far worse than that. There is nothing preventing those coins from being spent somewhere else, so actually an expiry would enable coin theft in a reorg -- you make your spends expire right after they hit the chain the first time, and then if there is a reorg the spend and subsequent transactions are invalidated. This is an exploitable means of theft. For this reason it is very important to male sure that once a transaction makes it on the chain, it cannot be invalidated by means of a reorg. On Jun 2, 2015 6:11 AM, Adam Back a...@cypherspace.org wrote: That would also introduce the anomaly of a script that was once valid becoming later invalid, when nothing varies other than time. That is not super compatible with the current model of reprocessing transactions in later blocks if the block they were first in gets reorged. (Not a huge flexibility loss as you can implement not after by making it the previous holders responsibility to spend a not before back to themselves.) Adam On 2 June 2015 at 13:52, Stephen stephencalebmo...@gmail.com wrote: Do you think it would be useful to have an inverted version of both CSV and CLTV? To verify if an output is spent before a specific time. CLTV and CSV could be implemented by taking two stack arguments, an integer for the comparison and TRUE/FALSE. Now that I think about this more, the problem is that, for example, just having a lock time of less than some value doesn't actually mean it has to be spent before that script value, so this might not work. Likely any implementations of such a feature would have to provide the script execution environment with access to information that it doesn't have now, which is what we are trying to avoid. Best, Stephen On Jun 2, 2015, at 12:16 AM, Mark Friedenbach m...@friedenbach.org wrote: You are correct! I am maintaining a 'checksequenceverify' branch in my git repository as well, an OP_RCLTV using sequence numbers: https://github.com/maaku/bitcoin/tree/checksequenceverify Most of the interesting use cases for relative lock-time require an RCLTV opcode. What is interesting about this architecture is that it possible to cleanly separate the relative lock-time (sequence numbers) from the RCLTV opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like CLTV, the CSV opcode only checks transaction data and requires no contextual knowledge about block headers, a weakness of the other RCLTV proposals that violate the clean separation between libscript and libconsensus. In a similar way, this BIP proposal only touches the transaction validation logic without any impact to script. I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY opcode and its enabling applications. But, well, one thing at a time. On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse stephencalebmo...@gmail.com wrote: Hi Mark, Overall, I like this idea in every way except for one: unless I am missing something, we may still need an OP_RCLTV even with this being implemented. In use cases such as micropayment channels where the funds are locked up by multiple parties, the enforcement of the relative locktime can be done by the first-signing party. So, while your solution would probably work in cases like this, where multiple signing parties are involved, there may be other, seen or unforeseen, use cases that require putting the relative locktime right into the spending contract (the scriptPubKey itself). When there is only one signer, there's nothing that enforces using an nSequence and nVersion=2 that would prevent spending the output until a certain time. I hope this is received as constructive criticism, I do think this is an innovative idea. In my view, though, it seems to be less fully-featured than just repurposing an OP_NOP to create OP_RCLTV. The benefits are obviously that it saves transaction space by repurposing unused space, and would likely work for most cases where an OP_RCLTV would be needed. Best, Stephen On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach m...@friedenbach.org wrote: I have written a reference implementation and BIP draft for a soft-fork change to the consensus-enforced behaviour of sequence numbers for the purpose of supporting transaction replacement via per-input relative lock-times. This proposal was previously discussed on the mailing list in the following thread: http://sourceforge.net/p/bitcoin/mailman/message/34146752/ In short summary, this proposal seeks to enable safe transaction replacement by re-purposing the nSequence field of a transaction input to be a consensus-enforced relative lock-time. The advantages of this approach is that it makes use of the full range of the 32-bit sequence number which until now has rarely been used for anything other than a boolean control over absolute
[Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers
I have written a reference implementation and BIP draft for a soft-fork change to the consensus-enforced behaviour of sequence numbers for the purpose of supporting transaction replacement via per-input relative lock-times. This proposal was previously discussed on the mailing list in the following thread: http://sourceforge.net/p/bitcoin/mailman/message/34146752/ In short summary, this proposal seeks to enable safe transaction replacement by re-purposing the nSequence field of a transaction input to be a consensus-enforced relative lock-time. The advantages of this approach is that it makes use of the full range of the 32-bit sequence number which until now has rarely been used for anything other than a boolean control over absolute nLockTime, and it does so in a way that is semantically compatible with the originally envisioned use of sequence numbers for fast mempool transaction replacement. The disadvantages are that external constraints often prevent the full range of sequence numbers from being used when interpreted as a relative lock-time, and re-purposing nSequence as a relative lock-time precludes its use in other contexts. The latter point has been partially addressed by having the relative lock-time semantics be enforced only if the most-significant bit of nSequence is set. This preserves 31 bits for alternative use when relative lock-times are not required. The BIP draft can be found at the following gist: https://gist.github.com/maaku/be15629fe64618b14f5a The reference implementation is available at the following git repository: https://github.com/maaku/bitcoin/tree/sequencenumbers I request that the BIP editor please assign a BIP number for this work. Sincerely, Mark Friedenbach -- ___ 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 3:11 AM, Mike Hearn m...@plan99.net wrote: As I believe out of all proposed protocols Satoshi's is still the most powerful, I would suggest that any change to the semantics on nSequence be gated by a high bit or something, so the original meaning remains available if/when resource scheduling and update flood damping are implemented. That way people can try it out and if miners are breaking things too frequently by ignoring the chronological ordering people can abandon protocols that rely on it, and if they aren't they can proceed and benefit from the greater flexibility. Mike, this proposal was purposefully constructed to maintain as well as possible the semantics of Satoshi's original construction. Higher sequence numbers -- chronologically later transactions -- are able to hit the chain earlier, and therefore it can be reasonably argued will be selected by miners before the later transactions mature. Did I fail in some way to capture that original intent? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
Sequence numbers appear to have been originally intended as a mechanism for transaction replacement within the context of multi-party transaction construction, e.g. a micropayment channel. The idea is that a participant can sign successive versions of a transaction, each time incrementing the sequence field by some amount. Relay nodes perform transaction replacement according to some policy rule making use of the sequence numbers, e.g. requiring sequence numbers in a replacement to be monotonically increasing. As it happens, this cannot be made safe in the bitcoin protocol as deployed today, as there is no enforcement of the rule that miners include the most recent transaction in their blocks. As such, any protocol relying on a transaction replacement policy can be defeated by miners choosing not to follow that policy, which they may even be incentivised to do so (if older transactions provide higher fee per byte, for example). Transaction replacement is presently disabled in Bitcoin Core. These shortcomings can be fixed in an elegant way by giving sequence numbers new consensus-enforced semantics as a relative lock-time: if a sequence number is non-final (MAX_INT), its bitwise inverse is interpreted as either a relative height or time delta which is added to the height or median time of the block containing the output being spent to form a per-input lock-time. The lock-time of each input constructed in this manor, plus the nLockTime of the transaction itself if any input is non-final must be satisfied for a transaction to be valid. For example, a transaction with an txin.nSequence set to 0xff9b [== ~(uint32_t)100] is prevented by consensus rule from being selected for inclusion in a block until the 100th block following the one including the parent transaction referenced by that input. In this way one may construct, for example, a bidirectional micropayment channel where each change of direction increments sequence numbers to make the transaction become valid prior to any of the previously exchanged transactions. This also enables the discussed relative-form of CHECKLOCKTIMEVERIFY to be implemented in the same way: by checking transaction data only and not requiring contextual information like the block height or timestamp. An example implementation of this concept, as a policy change to the mempool processing of Bitcoin Core is available on github: https://github.com/maaku/bitcoin/tree/sequencenumbers -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
Please let's at least have some civility and decorum on this list. On Tue, May 26, 2015 at 1:30 PM, joli...@airmail.cc wrote: You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks and you have big banks as clients. Shit like replace-by-fee and leading the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out. Peter Todd - 8930511 Canada Ltd. 1214-1423 Mississauga Valley Blvd. Mississauga ON L5A 4A5 Canada https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511 On 2015-05-26 00:10, Peter Todd wrote: On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote: CPFP also solves it just fine. CPFP is a significantly more expensive way of paying fees than RBF, particularly for the use-case of defragmenting outputs, with cost savings ranging from 30% to 90% Case 1: CPFP vs. RBF for increasing the fee on a single tx -- Creating an spending a P2PKH output uses 34 bytes of txout, and 148 bytes of txin, 182 bytes total. Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size. I forget to click on the priority fee option, so it goes out with the minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output, creating a new transaction t2 that's 192 bytes in size. I want to pay 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of transaction fees. On the other hand, had I use RBF, my wallet would have simply rebroadcast t1 with the change address decreased. The rules require you to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new fee level, or 218uBTC of fees in total. Cost savings: 48% Case 2: Paying multiple recipients in succession Suppose that after I pay Alice, I also decide to pay Bob for his hard work demonstrating cryptographic protocols. I need to create a new transaction t2 spending t1's change address. Normally t2 would be another 226 bytes in size, resulting in 226uBTC additional fees. With RBF on the other hand I can simply double-spend t1 with a transaction paying both Alice and Bob. This new transaction is 260 bytes in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth consumed broadcasting it, resulting in an additional 36uBTC of fees. Cost savings: 84% Case 3: Paying multiple recipients from a 2-of-3 multisig wallet The above situation gets even worse with multisig. t1 in the multisig case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC in fees. With RBF we rewrite t1 with an additional output, resulting in a 399 byte transaction, with just 36uBTC in additional fees. Cost savings: 90% Case 4: Dust defragmentation My wallet has a two transaction outputs that it wants to combine into one for the purpose of UTXO defragmentation. It broadcasts transaction t1 with two inputs and one output, size 340 bytes, paying zero fees. Prior to the transaction confirming I find I need to spend those funds for a priority transaction at the 1mBTC/KB fee level. This transaction, t2a, has one input and two outputs, 226 bytes in size. However it needs to pay fees for both transactions at once, resulting in a combined total fee of 556uBTC. If this situation happens frequently, defragmenting UTXOs is likely to cost more in additional fees than it saves. With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374 bytes in size, paying 374uBTC. Even better, if one of the two inputs is sufficiently large to cover my costs I can doublespend t1 with a 1-in-2-out tx just 226 bytes in size, paying 226uBTC. Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF costs you more than you save -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development 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
I'm on my phone today so I'm somewhat constrained in my reply, but the key takeaway is that the proposal is a mechanism for miners to trade subsidy for the increased fees of a larger block. Necessarily it only makes sense to do so when the marginal fee per KB exceeds the subsidy fee per KB. It correspondingly makes sense to use a smaller block size if fees are less than subsidy, but note that fees are not uniform and as the block shrinks the marginal fee rate goes up.. Limits on both the relative and absolute amount a miner can trade subsidy for block size prevent incentive edge cases as well as prevent a sharp shock to the current fee-poor economy (by disallowing adjustment below 1MB). Also the identity transform was used only for didactic purposes. I fully expect there to be other, more interesting functions to use. On May 10, 2015 3:03 PM, Thomas Voegtlin thom...@electrum.org wrote: Le 08/05/2015 22:33, Mark Friedenbach a écrit : * For each block, the miner is allowed to select a different difficulty (nBits) within a certain range, e.g. +/- 25% of the expected difficulty, and this miner-selected difficulty is used for the proof of work check. In addition to adjusting the hashcash target, selecting a different difficulty also raises or lowers the maximum block size for that block by a function of the difference in difficulty. So increasing the difficulty of the block by an additional 25% raises the block limit for that block from 100% of the current limit to 125%, and lowering the difficulty by 10% would also lower the maximum block size for that block from 100% to 90% of the current limit. For simplicity I will assume a linear identity transform as the function, but a quadratic or other function with compounding marginal cost may be preferred. Sorry but I fail to see how a linear identity transform between block size and difficulty would work. The miner's reward for finding a block is the sum of subsidy and fees: R = S + F The probability that the miner will find a block over a time interval is inversely proportional to the difficulty D: P = K / D where K is a constant that depends on the miner's hashrate. The expected reward of the miner is: E = P * R Consider that the miner chooses a new difficulty: D' = D(1 + x). With a linear identity transform between block size and difficulty, the miner will be allowed to collect fees from a block of size: S'=S(1+x) In the best case, collected will be proportional to block size: F' = F(1+x) Thus we get: E' = P' * R' = K/(D(1+x)) * (S + F(1+x)) E' = E - x/(1+x) * S * K / D So with this linear identity transform, increasing block size never increases the miners gain. As long as the subsidy exists, the best strategy for miners is to reduce block size (i.e. to choose x0). -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
Micropayment channels are not pie in the sky proposals. They work today on Bitcoin as it is deployed without any changes. People just need to start using them. On May 10, 2015 11:03, Owen Gunden ogun...@phauna.org wrote: On 05/08/2015 11:36 PM, Gregory Maxwell wrote: 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. Along the lines of aligning incentives with a diversity of costs to a variety of network participants, I am curious about reactions to Justus' general approach: http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/ I realize it relies on pie-in-the-sky ideas like micropayment channels, but I wonder if it's a worthy long-term ideal direction for this stuff. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
It is my professional opinion that raising the block size by merely adjusting a constant without any sort of feedback mechanism would be a dangerous and foolhardy thing to do. We are custodians of a multi-billion dollar asset, and it falls upon us to weigh the consequences of our own actions against the combined value of the entire bitcoin ecosystem. Ideally we would take no action for which we are not absolutely certain of the ramifications, with the information that can be made available to us. But of course that is not always possible: there are unknown-unknowns, time pressures, and known-unknowns where information has too high a marginal cost. So where certainty is unobtainable, we must instead hedge against unwanted outcomes. The proposal to raise the block size now by redefining a constant carries with it risk associated with infrastructure scaling, centralization pressures, and delaying the necessary development of a constraint-based fee economy. It also simply kicks the can down the road in settling these issues because a larger but realistic hard limit must still exist, meaning a future hard fork may still be required. But whatever new hard limit is chosen, there is also a real possibility that it may be too high. The standard response is that it is a soft-fork change to impose a lower block size limit, which miners could do with a minimal amount of coordination. This is however undermined by the unfortunate reality that so many mining operations are absentee-run businesses, or run by individuals without a strong background in bitcoin protocol policy, or with interests which are not well aligned with other users or holders of bitcoin. We cannot rely on miners being vigilant about issues that develop, as they develop, or able to respond in the appropriate fashion that someone with full domain knowledge and an objective perspective would. The alternative then is to have some sort of dynamic block size limit controller, and ideally one which applies a cost to raising the block size in some way the preserves the decentralization and/or long-term stability features that we care about. I will now describe one such proposal: * For each block, the miner is allowed to select a different difficulty (nBits) within a certain range, e.g. +/- 25% of the expected difficulty, and this miner-selected difficulty is used for the proof of work check. In addition to adjusting the hashcash target, selecting a different difficulty also raises or lowers the maximum block size for that block by a function of the difference in difficulty. So increasing the difficulty of the block by an additional 25% raises the block limit for that block from 100% of the current limit to 125%, and lowering the difficulty by 10% would also lower the maximum block size for that block from 100% to 90% of the current limit. For simplicity I will assume a linear identity transform as the function, but a quadratic or other function with compounding marginal cost may be preferred. * The default maximum block size limit is then adjusted at regular intervals. For simplicity I will assume an adjustment at the end of each 2016 block interval, at the same time that difficulty is adjusted, but there is no reason these have to be aligned. The adjustment algorithm itself is either the selection of the median, or perhaps some sort of weighted average that respects the middle majority. There would of course be limits on how quickly the block size limit can adjusted in any one period, just as there are min/max limits on the difficulty adjustment. * To prevent perverse mining incentives, the original difficulty without adjustment is used in the aggregate work calculations for selecting the most-work chain, and the allowable miner-selected adjustment to difficulty would have to be tightly constrained. 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. Mark Friedenbach * There has over time been various discussions on the bitcointalk forums about dynamically adjusting block size limits. The true origin of the idea is unclear at this time (citations would be appreciated!) but a form of it was implemented in Bytecoin / Monero using subsidy burning
Re: [Bitcoin-development] Block Size Increase
Transactions don't expire. But if the wallet is online, it can periodically choose to release an already created transaction with a higher fee. This requires replace-by-fee to be sufficiently deployed, however. On Fri, May 8, 2015 at 1:38 PM, Raystonn . rayst...@hotmail.com wrote: I have a proposal for wallets such as yours. How about creating all transactions with an expiration time starting with a low fee, then replacing with new transactions that have a higher fee as time passes. Users can pick the fee curve they desire based on the transaction priority they want to advertise to the network. Users set the priority in the wallet, and the wallet software translates it to a specific fee curve used in the series of expiring transactions. In this manner, transactions are never left hanging for days, and probably not even for hours. -Raystonn On 8 May 2015 1:17 pm, Aaron Voisine vois...@gmail.com wrote: As the author of a popular SPV wallet, I wanted to weigh in, in support of the Gavin's 20Mb block proposal. The best argument I've heard against raising the limit is that we need fee pressure. I agree that fee pressure is the right way to economize on scarce resources. Placing hard limits on block size however is an incredibly disruptive way to go about this, and will severely negatively impact users' experience. When users pay too low a fee, they should: 1) See immediate failure as they do now with fees that fail to propagate. 2) If the fee lower than it should be but not terminal, they should see degraded performance, long delays in confirmation, but eventual success. This will encourage them to pay higher fees in future. The worst of all worlds would be to have transactions propagate, hang in limbo for days, and then fail. This is the most important scenario to avoid. Increasing the 1Mb block size limit I think is the simplest way to avoid this least desirable scenario for the immediate future. We can play around with improved transaction selection for blocks and encourage miners to adopt it to discourage low fees and create fee pressure. These could involve hybrid priority/fee selection so low fee transactions see degraded performance instead of failure. This would be the conservative low risk approach. Aaron Voisine co-founder and CEO breadwallet.com -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine vois...@gmail.com wrote: This is a clever way to tie block size to fees. I would just like to point out though that it still fundamentally is using hard block size limits to enforce scarcity. Transactions with below market fees will hang in limbo for days and fail, instead of failing immediately by not propagating, or seeing degraded, long confirmation times followed by eventual success. There are already solutions to this which are waiting to be deployed as default policy to bitcoind, and need to be implemented in other clients: replace-by-fee and child-pays-for-parent. -- 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
In a fee-dominated future, replace-by-fee is not an opt-in feature. When you create a transaction, the wallet presents a range of fees that it expects you might pay. It then signs copies of the transaction with spaced fees from this interval and broadcasts the lowest fee first. In the user interface, the transaction is shown with its transacted amount and the approved fee range. All of the inputs used are placed on hold until the transaction gets a confirmation. As time goes by and it looks like the transaction is not getting accepted, successively higher fee versions are released. You can opt-out and send a no-fee or base-fee-only transaction, but that should not be the default. On the receiving end, local policy controls how much fee should be spent trying to obtain confirmations before alerting the user, if there are fees available in the hot wallet to do this. The receiving wallet then adds its own fees via a spend if it thinks insufficient fees were provided to get a confirmation. Again, this should all be automated so long as there is a hot wallet on the receiving end. Is this more complicated than now, where blocks are not full and clients generally don't have to worry about their transactions eventually confirming? Yes, it is significantly more complicated. But such complication is unavoidable. It is a simple fact that the block size cannot increase so much as to cover every single use by every single person in the world, so there is no getting around the reality that we will have to transition into an economy where at least one side has to pay up for a transaction to get confirmation, at all. We are going to have to deal with this issue whether it is now at 1MB or later at 20MB. And frankly, it'll be much easier to do now. On Fri, May 8, 2015 at 4:15 PM, Aaron Voisine vois...@gmail.com wrote: That's fair, and we've implemented child-pays-for-parent for spending unconfirmed inputs in breadwallet. But what should the behavior be when those options aren't understood/implemented/used? My argument is that the less risky, more conservative default fallback behavior should be either non-propagation or delayed confirmation, which is generally what we have now, until we hit the block size limit. We still have lots of safe, non-controversial, easy to experiment with options to add fee pressure, causing users to economize on block space without resorting to dropping transactions after a prolonged delay. Aaron Voisine co-founder and CEO breadwallet.com On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach m...@friedenbach.org wrote: On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine vois...@gmail.com wrote: This is a clever way to tie block size to fees. I would just like to point out though that it still fundamentally is using hard block size limits to enforce scarcity. Transactions with below market fees will hang in limbo for days and fail, instead of failing immediately by not propagating, or seeing degraded, long confirmation times followed by eventual success. There are already solutions to this which are waiting to be deployed as default policy to bitcoind, and need to be implemented in other clients: replace-by-fee and child-pays-for-parent. -- 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
The problems with that are larger than time being unreliable. It is no longer reorg-safe as transactions can expire in the course of a reorg and any transaction built on the now expired transaction is invalidated. On Fri, May 8, 2015 at 1:51 PM, Raystonn rayst...@hotmail.com wrote: Replace by fee is what I was referencing. End-users interpret the old transaction as expired. Hence the nomenclature. An alternative is a new feature that operates in the reverse of time lock, expiring a transaction after a specific time. But time is a bit unreliable in the blockchain -- 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
At this moment anyone can alter the txid. Assume transactions are 100% malleable. On Apr 16, 2015 9:13 AM, s7r s...@sky-ip.org wrote: Hi Pieter, 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 problem I am trying to solve is making all transactions non-malleable by default. I guess there is a very good reason why BIP62 will not touch v1 anyway. I am trying to build a bitcoin contract which will relay on 3 things: - coinjoin / txes with inputs from multiple users which are signed by all users after they are merged together (every user is sure his coins will not be spent without the other users to spend anything, as per agreed contract); - pre-signed txes with nLockTime 'n' weeks. These txes will be signed before the inputs being spent are broadcasted/confirmed, using the txid provided by the user before broadcasting it. Malleability hurts here. - P2SH In simple terms, how malleable transactions really are in the network at this moment? Who can alter a txid without invalidating the tx? Just the parties who sign it? The miners? Anyone in the network? This is a little bit unclear to me. Another thing I would like to confirm, the 3 pieces of the bitcoin protocol mentioned above will be supported in _any_ future transaction version or block version, regardless what changes are made or features added to bitcoin core? The contract needs to be built and left unchanged for a very very long period of time... On 4/16/2015 8:22 AM, Pieter Wuille wrote: On Apr 16, 2015 1:46 AM, s7r s...@sky-ip.org mailto:s...@sky-ip.org wrote: but for transaction versions? In simple terms, if 75% from all the transactions in the latest 1000 blocks are version 'n', mark all previous transaction versions as non-standard and if 95% from all the transactions in the latest 1000 blocks are version 'n' mark all previous transaction versions as invalid. What problem are you trying to solve? The reason why BIP62 (as specified, it is just a draft) does not make v1 transactions invalid is because it is opt-in. The creator of a transaction needs to agree to protect it from malleability, and this subjects him to extra rules in the creation. Forcing v3 transactions would require every piece of wallet software to be changed. -- Pieter -- 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 -- 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] replace-by-fee v0.10.0rc4
Thank you Jorge for the contribution of the Stag Hunt terminology. It is much better than a politically charged scorched earth. On Feb 21, 2015 11:10 AM, Jorge Timón jti...@jtimon.cc wrote: I agree scorched hearth is a really bad name for the 0 conf protocol based on game theory. I would have preferred stag hunt since that's basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt) but I like the protocol and I think it would be interesting to integrate it in the payment protocol. Even if that protocol didn't existed or didn't worked, replace-by-fee is purely part of a node's policy, not part of consensus. From the whitepaper, 0 conf transactions being secure by the good will of miners was never an assumption, and it is clear to me that the system cannot provide those guaranties based on such a weak scheme. I believe thinking otherwise is naive. As to consider non-standard policies an attack to bitcoin because that's not how bitcoin used to work, then I guess minimum relay fee policies can also be considered an attack to bitcoin on the same grounds. Lastly, first-seen-wins was just a simple policy to bootstrap the system, but I expect that most nodes will eventually move to policies that are economically rational for miners such as replace-by-fee. Not only I disagree this will be the end of bitcoin or will push the price of the btc miners are mining down, I believe it will be something good for bitcoin. Since this is apparently controversial I don't want to push for replace-by-fee to become the new standard policy (something that would make sense to me). But once the policy code is sufficiently modular as to support several policies I would like bitcoin core to have a CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no policy checks at all). One step at a time I guess... On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes ho...@hozed.org wrote: On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: Most money/payment systems include some method to reverse or undo payments made in error. In these systems, the longer settlement times you mention below are a feature, not a bug, and give more time for a human to react to errors and system failures. Settlement has to be final somewhere. That is the whole point of it. Transfer costs in current electronic payment systems are a direct consequence of their non-finality. That's the point Satoshi was making in the introduction to the whitepaper: With the possibility of reversal, the need for trust spreads. The problem with that statement is I trust a merchant that I went into a store and made a payment with personally more than I trust the firmware on my hard drive [1]. The attack surface of devices in your computer is huge. A motivated attacker just needs to get an intern into a company that makes some kind of component or system that's in your computer, cloud server, hardware wallet, or what have you that has firmware capable of reading your private keys. With the possibility of mass trojaned hardware, if we are going to trust the system, it must somehow allow reversal through a human-in-the-loop. There is nothing wrong with having reversible mechanisms built on top of Bitcoin, and indeed it makes sense for most activity to happen at those higher layers. It's easy to build things that way, but impossible to build them the other way: you can't build a non-reversible layer on top of a reversible layer. We built 'reliable' TCP on top of unreliable ethernet networks. My experience with networking was if you tried to guarantee message delivery at the lowest level, the system got exceedingly complicated, expensive, and brittle. Most applications, in particular paying someone you already trust, are quite happy running on reversible systems, and in some cases more reliable and lower risk. (carrying non-reversible cash is generally considered risky) The problem is that if the base currency is assumed to be non-reversible, then it's brittle and becomes 'too big to fail'. Where the blockchain improves on everything else is in transparency. If you reverse transactions a lot, it will be obvious from an analysis. I would much rather deal with a known, predictable, and relatively continous transaction reversal rate (percentage) than have to deal with sudden failures where some anonymous bad actor makes off with a fortune. We already have zero-conf double-spend transaction reversal, why not explicitly extend that a little in a way that senders and receivers have a choice to use it, or not? [1] http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from
Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties
There should not be a requirement at this level to ensure validity. That would too constrain use cases of implementations of your protocol. It is not difficult to imagine use cases where parties generate chained transactions on top of unconfimed transactions. Although malleability currently makes this difficult to do safely in general, it is not inconceivable that there are circumstances where it would nevertheless be safe or otherwise desireable. It is a good security recommendation that clients validate the inputs to a shuffle they are participating in. What this means depends on the client -- checking the UTXO set for a full node, making some getutxos queries for a SPV client. But this should remain a recommendation, not a requirement. On Mon, Aug 11, 2014 at 4:38 AM, Tim Ruffing tim.ruff...@mmci.uni-saarland.de wrote: Hmm, you are right. Lightweight clients are an interesting point, we have to think about a policy for them. As you said, the worst case is that the tx will not confirm. So the only possible attack is DoS. For clients that rely on servers it's reasonable to trust their servers not to perform DoS. (Anyway, the servers could do worse attacks.) For SPV-clients (without servers), I'm not sure at the moment. Something like getUTXO seems to be a possibility. I think even SPV-clients can verify the validity of the tx that created the input that is designated for mixing. Then the only remaining reason why it could be invalid is that the input could have been spent already otherwise. But in this case, only one honest client with full information would suffice: a signed transaction that spends the money would convince even SPV-clients that the participant with this inputs tries to cheat. This transaction could even be provided by lightweight client that got if from a server; the transaction is signed by the cheating participant anyway. Tim On Monday 11 August 2014 02:30:16 Chris Pacia wrote: Actually getUTXO would probably work here as well. It isn't authenticated but it should be good enough for this purpose. The worst that would happen is the tx doesn't confirm. On Aug 11, 2014 2:25 AM, Chris Pacia ctpa...@gmail.com wrote: One issue I do see is the protocol requires participants to check the inputs submitted by others are valid. Lite clients (at least of the p2p variety) cannot perform this check. You could skip the verification part and if the inputs turn out to be invalid then you'll find out when it doesn't confirm. This would problem open the protocol up to dos attacks and prevent part of the blame phase from working properly. Alternatively you can have the participants submit the merkle proof for the input. This would require inputs to have at least one confirmation, however. -- ___ 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] CoinShuffle: decentralized CoinJoin without trusted third parties
On Sat, Aug 9, 2014 at 6:10 AM, Sergio Lerner sergioler...@certimix.com wrote: Hi Tim, It's clear from the paper that the second party in the protocol can de-anonymize the first party. So it's seems that dishonest shufflers would prefer to be in that position in the queue. That's not clear to me. The 2nd party doesn't know how the 3rd, 4th, 5th, etc. parties shuffled the outputs, since it doesn't have their decryption keys. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] deterministic transaction expiration
On 08/06/2014 01:02 PM, Tom Harding wrote: With first-eligible-height and last-eligible-height, creator could choose a lifetime shorter than the max, and in addition, lock the whole thing until some point in the future. Note that this would be a massive, *massive* change that would completely break bitcoin output frangibility. Merchants would have to start demanding input history back to a certain depth in order to ensure they are not exposing themselves to undue reorg-expiry risk. There are useful applications of a consensus-enforced expiry, particularly within a private (signed block) side chain, and for that reason it is useful to have a discussion about the merits of an nExpiry field or BLOCK_HEIGHT / BLOCK_TIME opcode, and methods for achieving either. However I don't see this ever becoming part of the public bitcoin network. -- 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 08/06/2014 01:20 PM, Peter Todd wrote: The general case doesn't require transmission of any merkle data; it is derived from the tx data. How can that possibly be the case? The information is hidden behind the Merkle root in the transaction. The validator needs to know whether there is an expiry and what it is. What's it supposed to do, guess? -- 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] Mining Hashrate Caps
Can someone explain to these guys and the public why promising to limit yourselves to *only* a 50% chance of successfully double-spending a 6 confirm transaction is still not acceptable? q=0.4 z=0 P=1 z=1 P=0.828861 z=2 P=0.736403 z=3 P=0.664168 z=4 P=0.603401 z=5 P=0.550625 z=6 P=0.50398 z=7 P=0.462301 z=8 P=0.424782 z=9 P=0.390828 z=10P=0.359976 z=11P=0.331858 z=12P=0.306167 z=13P=0.282649 z=14P=0.261083 z=15P=0.24128 z=16P=0.223076 z=17P=0.206324 z=18P=0.190896 z=19P=0.176676 On 07/17/2014 06:59 AM, Melvin Carvalho wrote: I noticed this article today. GHash Commits to 40% Hashrate Cap at Bitcoin Mining Summit http://www.coindesk.com/ghash-commits-40-hashrate-cap-bitcoin-mining-summit/ Here's a quote from Satoshi when the mining arms race began: We should have a gentleman’s agreement to postpone the GPU arms race as long as we can for the good of the network. It’s much easer to get new users up to speed if they don’t have to worry about GPU drivers and compatibility. It’s nice how anyone with just a CPU can compete fairly equally right now. Maybe outdated now, but I thought it was interesting. -- 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 -- 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] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:
Sergio, why is preventing mining pools a good thing? The issue is not mining pools, which provide a needed service in greatly reducing variance beyond what any proposal like this can do. The issue is centralized transaction selection policies, which is entirely orthogonal. And the solution already exists: getblocktemplate. We just need more or better infrastructure which makes use of this technology to perform local transaction selection. If you have a proposal for eliminating hosted mining while keeping variance-reducing pools, that would be an interesting read. On 06/19/2014 09:58 AM, Sergio Lerner wrote: I propose a setting that prevent mining pools AND reduce payoff variance which requires two changes: increasing the block-rate and changing the Bitcoin PoW (but still allowing current Bitcoin ASICs to work (as far as I know)). The block rate must be increased at least 20 times and block must still be near full (e.g. there must be at least 20 more transactions/second than there is today) BlockPow is kind of PoW that only practically prevents mining pools for certain cryptocurrency settings based on concepts similar to parmacoin, but in a much simple degree. The idea is that if miners try to join a pool, then they incur in overhead of transmitting information and earn less than working solo. Let b (the payload) contain a full block. b must contain all the transactions and the header, and not only the transaction hashes. b should not hide anything. Let h be the block header (which contains the previous block hash and the Merkle tree root of the transactions). Let d be the difficulty. hash-block-length(b) returns the number of blocks processed by the hash function when fed with the block b. The target is divided by hash-block-length(b) so that the difficulty does not depend on the length of the block. Some other function can be used to encourage nodes to add more or less transactions. Def: Basic BlockPoW concept For each r in the nonce-range: if H ( H( r || b ) || h || r) ) 2^-d/ hash-block-length(b) then return r return null The header (h) is appended to the hashed message to allow SPV clients to verify the PoW without requiring the full block to be downloaded. Peers can send only (x,r,h) to SPV nodes, where x = H( r || b ), so they can verify the PoW. The verification procedure is obvious, and is skipped here. r is inserted at the beginning of the message to prevent pool administrators from keeping a secret mid-state of the hash function secret in order to prevent block stealing and also to force the miner to know b in the inner mining loop. So now mining requires the knowledge of the block b to be mined, and b must be received at each block-chain epoch. This could create an incentive not to include any transaction and use an almost empty b, because that way the bandwidth requirements is decreased. But this incentive should not exists normally, since by including transactions the solo miner gets an additional revenue from fees, which is lost if the block is empty. Anyway, to prevent this possible incentive we can append to b a subset of previous blocks (e.g 100 blocks). The block subset to include could be derived from a peudo-random function seeded by the previous block hash. Then a node would still need to download part or all the block-chain in order to mine. Now if the miner wants to be a dumb node and take part of a pool, then the current working unsolved block (the template) must be sent each time from the pool admin to each miner. If the pool admin hosts 1000 miners, then to serve them with fresh block templates he needs 1000 times more bandwidth that the miners, making this much more expensive. If miners create another network topology to distribute templates, they are incurring in the same overhead as being actively part of the cryptocurrency network, so they gain nothing. For example, in a block-chain with a 5 seconds block-rate, such as in NimbleCoin http://nimbleCoin.org, each block can be as large as 200 Kbytes (100 tps are allowed). A miner will require the block template to be ready as fast as possible, say before 3 seconds, so as not to loose more than 60% of the times the transaction fees present in the block template. This means that a pool admin serving 1000 clients must have a upload bandwidth of at least 60 Mbytes/sec, and load balance servers, because all miners will demand the block template at the same time and will compete for it. The same miner, working solo, will not loose the 60% of block fees. If block fees are 10% of block reward, then solo miners earn 6% more than pool miners. Also, having a block rate of 5 seconds allows solo miners to receive payments more often and so it reduces the payment variance. This method to discourage mining pools only work as long as time is takes to transmit a block is comparable to the block interval time, e.g. 20%. This seems not to be a problem since if
Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:
Do you need to do full validation? There's an economic cost to mining invalid blocks, and even if that were acceptable there's really no reason to perform such an attack. The result would be similar to a block withholding attack, but unlike block withholding it would be trivially detectable if/when full validation was performed. To protect yourself and to detect incorrect mining software you could stochastically validate a randomly selected sample of shares, as your hardware requirements allow. On 06/19/2014 01:26 PM, slush wrote: With GBT, simply hashing the block header is not enough, because pool cannot rely on anything provided by the client. Its not only about things like withdrawal attacks, but more about hidden bugs in various miners. It is extremely hard to do full validation for *every* of submitted shares. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees
Not with current script, but there are mechanisms by which you can do a digital signature where signing two pieces of information reveals the ECDSA k parameter, thereby allowing anyone to recover the private key and steal the coins. Practically speaking, these are not very safe systems to use. For example, imagine accidentally loading up the same wallet on two machines or the wallet software crashing after signing and sending the transaction, and the user recreates sends on recovery. It also invalidates reasonably legitimate use cases for repeating addresses (in the absence of other solutions), and its not really possible to prevent people from sending multiple coins to the same address (which could then be stolen). On 06/17/2014 01:40 PM, Goss, Brian C., M.D. wrote: Can two signed transactions using the same output as an input (ie, a double spend) be used to trigger a third transaction? It would be nice if I could sign a tx that would pay m bitcoins to an arbitrary address if and only if someone could present proof that I signed more than 1 transaction using the same output. Thus, a merchant could trust that I would not attempt a double spend for a purchase of n m bitcoins. Can this type of transaction be expressed in Bitcoin's scripting language? Chaum had a similar feature in Digicash way back when...a double spend would let the second merchant compute the identity of the double spender and serve as proof of double spending. It didn't automate punishment though! My apologies if this has been discussed previously. -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Future Feature Proposal - getgist
The correct approach here is header hash-tree commitments which enable compact (logarithmic) SPV proofs that elide nearly all intervening headers since the last checkpoint. You could then query the hash tree for references to any of the headers you actually need. See this message for details: http://sourceforge.net/p/bitcoin/mailman/message/32111357/ On 06/04/2014 12:30 PM, Richard Moore wrote: Bitcoin development team, I recently started implementing my own Python full-node, and had an idea, so I’m prowling through BIP 001 for this proposal, which says to e-mail you kind folks to make sure the idea is original (enough) and that there aren’t other existing means to accomplish what I was thinking. :) The only way to grab all the headers seems to be to serially get one, then the next and so on, as you need the last hash of a headers() call to the next getheaders(). But we are on a peer-to-peer network, potentially able to getheaders() from many peers simultaneously, if we only knew the hash to look for. What I was thinking is something to the effect of a getgist() command, fully backward compatible (any node not understanding it, can silently ignore it… Otherwise version or services could be used to announce the capability, but that seems like a little overkill). The inputs to getgist() would be similar to getheaders(); version, hash_count, block_locator_hash, stop_hash and an additional field, segment_count. The response would be a normal headers() message, except, not sequential block headers… Rather they would be spaced out, preferably 2000-block-hash-aligned from the first block hash. So, for example, if you have a blockchain with 198,005 blocks, and you passed it the block locator of height 0 (the genesis block), and a segment_count of 25, you would expect (approximately, the actual algorithm needs to be figured out), the block hashes at the following 25 (segment_count) heights: 1, 8000, 16000, 24000, 32000, 4, 48000, 56000, 64000, 72000, 8, 88000, 96000, 104000, 112000, 12, 128000, 136000, 144000, 152000, 16, 168000, 176000, 184000, 192000 Which can now be spread across 25 different nodes, fetching the block headers (albeit, out of order, possibly increasing the complexity of the local block chain database) but vastly increasing the speed the whole blockchain can have all headers synced. I still need to perform some tests to see what type of speed gains there are, but I would suspect it should be segment_count times faster. Existing methods could be to use checkpoint-ish nodes or bootstrap data files, but these begin relying on semi-cetralizenesses. Ideas? Suggestions? Concerns? Prior it-ain’t-gonna-works? Thanks! RicMoo .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ric...@geneticmistakes.com mailto:ric...@geneticmistakes.com www: http://GeneticMistakes.com http://GeneticMistakes.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] PSA: Please sign your git commits
I know the likelihood of this happening is slim, but if these are the desired features we should consider switching to monotone (monotone.ca) which has a much more flexible DAG structure and workflow built around programmable multi-sig signing of commits. We could still maintain the github account as a two-way repository interface, but acceptance of a pull request would require some threshold signature sign-off in monotone. I would seriously suggest anybody on this list exploring monotone if you haven't already, at least for your personal projects if it is too late to make that choice for bitcoin. Besides the benefits of using it, we should be supporting build infrastructure that enables less trusted, less centralized development. http://www.monotone.ca/ Mark On 05/23/2014 12:12 AM, Wladimir wrote: On Thu, May 22, 2014 at 8:06 PM, Jeff Garzik jgar...@bitpay.com wrote: Related: Current multi-sig wallet technology being rolled out now, with 2FA and other fancy doodads, is now arguably more secure than my PGP keyring. My PGP keyring is, to draw an analogy, a non-multisig wallet (set of keys), with all the associated theft/data destruction/backup risks. The more improvements I see in bitcoin wallets, the more antiquated my PGP keyring appears. Zero concept of multisig. The PGP keyring compromise process is rarely exercised. 2FA is lacking. At least offline signing works well. Mostly. Would be incredible to have multisig for git commits as well. I don't think git supports multiple signers for one commit at this point - amending the signature replaces the last one - but it would allow for some interesting multi-factor designs in which the damage when a dev's computer is compromised would be reduced. Sounds like a lot of work to get a good workflow there, though. My mail about single-signing commits was already longer than I expected when I started writing there. Even though the process is really simple. Though if anyone's interest is piqued by this, please pick it up. Wladimir -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bug with handing of OP_RETURN?
I don't think such a pull request would be accepted. The point was to minimize impact to the block chain. Each extras txout adds 9 bytes minimum, with zero benefit over serializing the data together in a single OP_RETURN. On 05/03/2014 11:39 AM, Peter Todd wrote: The standard format ended up being exactly: OP_RETURN 0 to 40-byte PUSHDATA You've split the data across two PUSHDATA's. The standard should have let the data be split up like that; pull requests accepted. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bug with handing of OP_RETURN?
Is it more complex? The current implementation using template matching seems more complex than `if script.vch[0] == OP_RETURN script.vch.size() 42` On 05/03/2014 12:08 PM, Gregory Maxwell wrote: On Sat, May 3, 2014 at 11:55 AM, Mark Friedenbach m...@monetize.io wrote: I don't think such a pull request would be accepted. The point was to minimize impact to the block chain. Each extras txout adds 9 bytes minimum, with zero benefit over serializing the data together in a single OP_RETURN. In this case it's not a question extra txouts, its a question of additional pushes. Assuming you didn't get the push overhead for free, the only issue I see with that off the cuff is extra complexity in the IsStandard rule... but really, why? Your application already needs to define the meaning of the data— what point is there in making your hash commitment less uniform with the rest of the network? -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About Compact SPV proofs via block header commitments
On 04/28/2014 07:32 AM, Sergio Lerner wrote: So you agree that: you need a periodic connection to a honest node, but during an attack you may loose that connection. This is the assumption we should be working on, and my use case (described in http://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/) assumes that. No, that's sortof tangential. What you are solving is some higher level application on top of SPV proofs, compact or otherwise. SPV proofs have many broad applications, such as 2-way pegs where proof-of-work is used to reach consensus over the most-work side-chain header, and a non-51% attack is detectable from observed difficulty and interblock times. Do you need an honest peer to learn about the best chain? Yes. Do you need to *trust* that you have an honest peer? No, because a non-51% attack against you is probabilistically detectable with existing tools. Maybe SmartSPV is useful, maybe not. The application domain is not something I've been concerned with in the past. But what you describe is a higher-level protocol that uses block headers to determine which chain to trust. My simple point from the start has been that you can use back-link commitments and compact SPV proofs to accomplish what you want fewer messages, less bandwidth, and equal security. The two proposals are not in conflict with each other. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About Compact SPV proofs via block header commitments
I don't think there's an official definition of SPV proof. I wasn't trying to make a argument from definition (that would be fallacious!). Rather I suspected that we had different concepts in mind and wanted to check. That said, I do think that the definition I gave matches how the term is used in the Satoshi whitepaper, and the way in which SPV clients like BitcoinJ work. Best chain is typically taken to mean the most-work, *valid* chain. Without invoking moon math or assumptions of honest peers and jamming-free networks, the only way to know a chain is valid is to witness the each and every block. SPV nodes on the other hand, simply trust that the most-work chain is a valid chain, based on economic arguments about the opportunity cost of mining invalid blocks. These SPV nodes use block headers as proofs to determine the most-work block connected to the genesis block or most recent checkpoint. So yes, operationally at least this is what the community seems to mean by SPV proof. Now regarding your use case: For the remaining peers, the client starts asking for parents blocks until all parents agree (this is the last common parent). This linear scan of block headers is what I would prefer to avoid. By using back-links you make it have log(N) space usage. On 04/26/2014 07:39 PM, Sergio Lerner wrote: El 26/04/2014 10:43 p.m., Mark Friedenbach escribió: Sergio, First of all, let's define what an SPV proof is: it is a succinct sequence of bits which can be transmitted as part of a non-interactive protocol that convincingly establishes for a client without access to the block chain that for some block B, B has an ancestor A at some specified height and work distance back, and the cost of creating a false proof is at least as much work as it claims to represent. Ok. I was thinking with another definition SPV proof. For me a SPV proof is a sequence of bits which can be transmitted as part of a non-interactive protocol that convincingly establishes for a client without access to the block chain that a block B is part of the best-chain. I understand that SPV nodes require SPV proofs as defined in my definition, but I can't realize how to prove that SPV nodes require SPV proofs under your definition. So your definition sounds to me like one possible solution, but not the need. Is your definition something well-established in the community? -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal for extra nonce in block header
I'm not convinced of the necessity of this idea in general, but if it were to be implemented I would recommend serializing the nVersion field as a VarInt (Pieter Wuille's multi-byte serialization format) and using the remaining space of the 4 bytes as your extra nonce. That would allow serialization of numbers up to 0x1020407f (slightly over 28 bits) before the 4-byte field is exhausted. For version numbers less than 0x204080 there will be at least one byte of padding space left over for extra-nonce usage (two bytes if less than 0x4080, three bytes if less than 0x80). For version values up to 127, the format is exactly identical when the padding bytes are zero. On 04/27/2014 12:07 AM, Timo Hanke wrote: I'd like to put the following draft of a BIP up for discussion. Timo # Abstract There are incentives for miners to find cheap, non-standard ways to generate new work, which are not necessarily in the best interest of the protocol. In order to reduce these incentives this proposal re-assigns 2 bytes from the version field of the block header to a new extra nonce field. # Copyright # Specification The block version number field in the block header is reduced in size from 4 to 2 bytes. The third and fourth byte in the block header are assigned to the new extra nonce field inside the block header. # Motivation The motivation of this proposal is to provide miners with a cheap constant-complexity method to create new work that does not require altering the transaction tree. Furthermore, the motivation is to protect the version and timestamp fields in the block header from abuse. # Rationale Traditionally, the extra nonce is part of the coinbase field of the generation transaction, which is always the very first transaction of a block. After incrementing the extra nonce the minimum amount of work a miner has to do to re-calculate the block header is a) to hash the coinbase transaction and b) to re-calculate the left-most branch of the merkle tree all the way to the merkle root. This is necessary overhead a miner has to do besides hashing the block header itself. We shall call the process that leads to a new block header from the same transaction set the _pre-hashing_. First it should be noted that the relative cost of pre-hashing in its traditional form depends on the block size, which may create an unwanted incentive for miners to keep the block size small. However, this is not the main motivation for the current proposal. While the block header is hashed by ASICs, pre-hashing typically happens on a CPU because of the greater flexibility required. Consequently, as ASIC cost per hash performance drops the relative cost of pre-hashing increases. This creates an incentive for miners to find cheaper ways to create new work than by means of pre-hashing. An example of this currently happening is the on-device rolling of the timestamp into the future. These ways of creating new work are unlikely to be in the best interest of the protocol. For example, rolling the timestamp faster than the real time is unwanted (more so on faster blockchains). The version number in the block header is a possible target for alteration with the goal of cheaply creating new work. Currently, blocks with arbitrarily large version numbers get relayed and accepted by the network. As this is unwanted behaviour, there should not exist any incentive for a miner to abuse the version number in this way. The solution is to reduce the range of version numbers from 2^32 to 2^16 and to declare the third and forth bytes of the block header as legitimate space for an extra nonce. This will reduce the incentive for a miner to abuse the shortened version number by a factor in the order of 2^16. As a side effect, this proposal greatly reduces the bandwidth requirements of a blind pool protocol by only submitting the block header to the miner. # Backwards Compatibility Old versions of the client will accept blocks of this kind but will throw an alert at the user to upgrade. The only code change would be a cast of the version number to a short. Besides the upgrade alert, old and new versions of the client can co-exist and there is no need to introduce a new block version number or to phase-out old block versions. # Reference Implementation # Final implementation -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] About Compact SPV proofs via block header commitments
On 04/27/2014 05:36 AM, Sergio Lerner wrote: Without invoking moon math or assumptions of honest peers and jamming-free networks, the only way to know a chain is valid is to witness the each and every block. SPV nodes on the other hand, simply trust that the most-work chain is a valid chain, based on economic arguments about the opportunity cost of mining invalid blocks. I argue that you cannot talk about the most-work chain without actually making an assumption about honest peers. I should have said without invoking moon math or interactive protocols requiring honest peers over jamming-free networks. The interactive protocol was more the point than the honest peers and jamming-free network. Yes, without an honest peer and an un-jammed network, you might never learn about the most-work chain in the first place. But having the security of the proof not depend on query access to an honest full node is absolutely necessary for some applications and certainly desirable in others. Although strictly speaking what I said may not be 100% true. The single alternative solution I've seen involves some sort of Fiat–Shamir transform that could give you a probabilistic proof by including random additional paths through the block chain chosen based on the combined hash of the headers. However this is disadvantageous as it massively increases the proof size and verification time, and you have to include a lot of data to achieve assurance that more work was required to generate the fraud than an honest chain. If you do not make the assumption, you compute the economic arguments wrong. Not necessarily. By requiring connectivity you know that what you are receiving is built off of the main chain, for example, and you can still make assumptions about resulting opportunity costs. First this is a method that uses NPPs, not SPV proofs. Since the method chooses all peers that are synchronized (have the latest current block) then going back means only skipping a potential short fork (which I suppose has never been more than 3 blocks during normal network conditions). You're looking for a common ancestor, not the checkpoint. So the linear scan is actually O(1). The exact value can be approximated by the sum of the convergent infinite geometrical sequence of forking probabilities, which it's about 1.03 without considering selfish-mining, and probably less than 2.03 considering it. Unless you're connected to attacker nodes which are wildly divergent from each other. It's relatively easy to create a massive fake history of difficulty-1 blocks. If you assume honest peers things get very easy. But that's not a safe assumption to be making. With back-link block-history commitments, on the other hand, an interactive protocol allows you to do a binary search to find common ancestors, and have trust that the intermediate links actually exist. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Selector Script
I think you're misunderstanding the point. The way you get IsStandard changed is that you make an application-oriented BIP detailing the use of some new standard transaction type (say, generalized hash-locked transactions for atomic swaps). We then discuss that proposal for its technical merits and reach consensus about the best way to do, for example, cross-chain atomic swaps. It is then implemented. So please, focus on some BIP(s) detailing applications of hash-locked transactions, and we will engage more constructively -- I promise that I will as cross-chain atomic swaps scratch my itch as well. On 04/25/2014 01:48 PM, Tier Nolan wrote: On Fri, Apr 25, 2014 at 9:26 PM, Luke-Jr l...@dashjr.org mailto:l...@dashjr.org wrote: They define standard for interoperability between software. So, if you want nodes to relay these transactions, you need to convince them, not merely write a BIP for the transaction format. I agree with you in theory, each miner could decide their inclusion rules for themselves. In practice, if the reference client is updated, then most miners will accept those transactions. In addition, it would eventually propagate to alt-coins (or at least the supported ones). I could simply submit the changes as a pull request for the reference client, but I was hoping that by doing it this way, it would increase the odds of it being accepted. Defining a BIP for cross-chain trading would be one way to do that. I don't think it quite requires the same coordination in the short term. I could write up the sequence as an info BIP. The malleability issue has been known for years. I wouldn't expect any special effort made to fix it... It is possible to tweak the protocol so that it still works. However, it means that 3rd parties are required (that could go in the BIP too). There is some ongoing discussion of a softfork to basically redo the Script language entirely, but it will take quite a bit of time and development before we'll see it in the wild. Implementing multi-P2SH gets a lot of the benefits of MAST, in terms of efficiency. Luke P.S. Did the BIP editor assign these numbers? If not, best to keep them numberless until assigned, to avoid confusion when people Google the real BIP 44 and 45... Not yet, but that is just my personal repo. I did email gmaxwell, but he said that they can't be assigned until some discussion has happened. I take your point that the name appears in the link though, so could cause issues with searching. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proof-of-Stake branch?
There's no need to be confrontational. I don't think anyone here objects to the basic concept of proof-of-stake. Some people, myself included, have proposed protocols which involve some sort of proof of stake mechanism, and the idea itself originated as a mechanism for eliminating checkpoints, something which is very much on topic and of concern to many here. The problems come when one tries to *replace* proof-of-work mining with proof-of-stake mining. You encounter problems related to the fact that with proof-of-stake nothing is actually at stake. You are free to sign as many different forks as you wish, and worse have incentive to do so, because whatever fork does win, you want it to be yours. In the worst case this results in double-spends at will, and in the best case with any of the various proposed protections deployed, it merely reduces to proof-of-work as miners grind blocks until they find one that names them or one of their sock puppets as the signer of the next block. I sincerely doubt you will find a solution to this, as it appears to be a fundamental issue with proof-of-stake, in that it must leverage an existing mechanism for enforced scarcity (e.g. proof-of-work) in order to work in a consensus algorithm. Is there some solution that you have in mind for this? Mark On 04/25/2014 12:33 AM, Troy Benjegerdes wrote: Do it. Someone will scream harm. The loudest voices screaming how it would be harmful are doing the most harm. The only way to know is build it, and test it. If the network breaks, then it is better we find out sooner rather than later. My only suggestion is call it 'bitstake' or something to clearly differentiate it from Bitcoin. This also might be an interesting application of the side chains concept Peter Todd has discussed. On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote: Hello all. I understand that Proof-of-Stake as a replacement for Proof-of-Work is a prohibited yet disputed change to Bitcoin Core. I would like to create a Bitcoin branch that provides a sandboxed testbed for researching the best PoS implementations. In the years to come, perhaps circumstances might arise, such as shifting of user opinion as to whether PoS should be moved from the prohibited list to the hard-fork list. - A poll I conducted today on bitcointalk, https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing title suggests some minority support for Bitcoin Proof-of-Stake. I invite any of you to critically comment on that thread. Annual 10% bitcoin dividends can be ours if Proof-of-Stake full nodes outnumber existing Proof-of-Work full nodes by three-to-one. What is your choice? I do not care or do not know enough. - 5 (16.1%) I would download and run the existing Proof-of-Work program to fight the change. - 14 (45.2%) I would download and run the new Proof-of-Stake program to favor the change. - 12 (38.7%) Total Voters: 31 - Before I branch the source code and learn the proper way of doing things in this community, I ask you simply if creating the branch is harmful? My goal is to develop, test and document PoS, while exploring its vulnerabilities and fixing them in a transparent fashion. Thanks for taking a bit of your time to read this message. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proof-of-Stake branch?
That makes double-spends trivially easy: sign two blocks, withholding one. Then at a later point in time reveal the second signed block (demonstrating your own fraud) and force a reorg. On 04/26/2014 04:44 PM, Gareth Williams wrote: What about using fraud proofs? Your coinbase only matures if nobody publishes proof that you signed a competing block. Then something is at least at stake. When it's your chance to sign a block, attempting to sign and publish more than one at the same height reliably punishes you (you effectively waste your chance and receive no reward.) I can't remember who I saw discussing this idea. Might have been Vitalik Buterin? On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach m...@monetize.io wrote: There's no need to be confrontational. I don't think anyone here objects to the basic concept of proof-of-stake. Some people, myself included, have proposed protocols which involve some sort of proof of stake mechanism, and the idea itself originated as a mechanism for eliminating checkpoints, something which is very much on topic and of concern to many here. The problems come when one tries to *replace* proof-of-work mining with proof-of-stake mining. You encounter problems related to the fact that with proof-of-stake nothing is actually at stake. You are free to sign as many different forks as you wish, and worse have incentive to do so, because whatever fork does win, you want it to be yours. In the worst case this results in double-spends at will, and in the best case with any of the various proposed protections deployed, it merely reduces to proof-of-work as miners grind blocks until they find one that names them or one of their sock puppets as the signer of the next block. I sincerely doubt you will find a solution to this, as it appears to be a fundamental issue with proof-of-stake, in that it must leverage an existing mechanism for enforced scarcity (e.g. proof-of-work) in order to work in a consensus algorithm. Is there some solution that you have in mind for this? Mark On 04/25/2014 12:33 AM, Troy Benjegerdes wrote: Do it. Someone will scream harm. The loudest voices screaming how it would be harmful are doing the most harm. The only way to know is build it, and test it. If the network breaks, then it is better we find out sooner rather than later. My only suggestion is call it 'bitstake' or something to clearly differentiate it from Bitcoin. This also might be an interesting application of the side chains concept Peter Todd has discussed. On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote: Hello all. I understand that Proof-of-Stake as a replacement for Proof-of-Work is a prohibited yet disputed change to Bitcoin Core. I would like to create a Bitcoin branch that provides a sandboxed testbed for researching the best PoS implementations. In the years to come, perhaps circumstances might arise, such as shifting of user opinion as to whether PoS should be moved from the prohibited list to the hard-fork list. - A poll I conducted today on bitcointalk, https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing title suggests some minority support for Bitcoin Proof-of-Stake. I invite any of you to critically comment on that thread. Annual 10% bitcoin dividends can be ours if Proof-of-Stake full nodes outnumber existing Proof-of-Work full nodes by three-to-one. What is your choice? I do not care or do not know enough. - 5 (16.1%) I would download and run the existing Proof-of-Work program to fight the change. - 14 (45.2%) I would download and run the new Proof-of-Stake program to favor the change. - 12 (38.7%) Total Voters: 31 - Before I branch the source code and learn the proper way of doing things in this community, I ask you simply if creating the branch is harmful? My goal is to develop, test and document PoS, while exploring its vulnerabilities and fixing them in a transparent fashion. Thanks for taking a bit of your time to read this message. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu
Re: [Bitcoin-development] About Compact SPV proofs via block header commitments
Sergio, First of all, let's define what an SPV proof is: it is a succinct sequence of bits which can be transmitted as part of a non-interactive protocol that convincingly establishes for a client without access to the block chain that for some block B, B has an ancestor A at some specified height and work distance back, and the cost of creating a false proof is at least as much work as it claims to represent. The previous email you quote demonstrates how with additional backlink commitments this can be done in logarithmic space: using an average of log(N) headers to construct an SPV proof from block A to block B where N is the height differential. It can be verified without access to the block chain or other peers. Note that with back links the cost of creating a fraudulent SPV proof is the same as 51% attacking bitcoin itself. The protocol you outlined does not have this property. Other than that, honestly I'm not really sure what you are trying to accomplish. An interactive proof is does not meet the above requirements and is not usable for the driving application of two-way pegs. Maybe you had some other application in mind? I've looked at your SmartSPV proposal, but fail to see how it doesn't reduce to simply blind trust in your view of the network from your peers. SPV proofs on the other hand put an economic cost to fraud. On 04/26/2014 06:08 PM, Sergio Lerner wrote: I read the post in this threads about Compact SPV proofs via block header commitments (archived e-mail in https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04318.html). I was working on the same problem almost at the same time, which is something that's becoming very common nowadays.. The proposal starts with the following claim: In simple payment verification (SPV) proofs it is currently necessary that every intervening block header be provided between two blocks in order to establish both connectivity and proof of work. I think this is false. Let's first assume that at the time of an attack we're connected only to the attacker (no honest nodes). An non-interactive SPV proof needs to prove that a transaction belongs to the best chain because creating a counterfeit proof cost more than the amount of money involved in the proof. Suppose that the proof consist at least of a block header and a merkle branch to the claimed transaction. Do the proof need connectivity with the last checkpoint known by the verifier? (here checkpoint is any block known for sure to be in the best chain) Not much, because connectivity only proves that the proof was not pre-computed before the checkpoint. Only if the checkpoint is very near (say 10 blocks back) it brings some practical evidence that the attacker did not have much time to prepare an attack. Do the proof need to know the interleaving proof-of-work? Not much. If the distance between blocks is less than 2016 blocks, then the difficulty may have change only by a factor of 4. Currently difficult adjustments are much lower (I suppose that about 1.1 or so). Then one can assume that the proof block target difficulty is almost the same as the last known difficulty if the block distance is less than 2016. If the distance is more, we just load all the interleaving re-target blocks to detect the actual difficulty. Do the proof need to have a certain number of confirmations? Yes and no, because this is the only evidence that the prover has either spend money in creating the fake block or took a genuine block. The cost of creating a fake block can be approximated as the minimum of: - The current reward of the block (since currently fees are much lower than the reward) - The average block fees (when the reward goes to zero) - The minimum electricity cost of mining the block. As time passes one could assume that the electricity cost of mining will approach the other two. But there is the problem of parallel synchronized attacks: if an attacker can reuse the same fake SPV proof to attack several victims, then the reward for cheating increases proportionally but the cost stays the same. For instance, if 6 confirmations are required, and each block can hold 2000 transactions, the attacker can find 2000 victims and re-use the same 6 block chain to prove payments to 2000 victims. Also the cost of mining 6 blocks can be amortized by mining 7, and attacking in the first two 4000 victims, etc... Any scheme than relies on non-interactive SPV proofs will fail if Bitcoin will scale up-to a point where victims can be easily found and synchronized. So I think one should assume that at least one peer is honest... But if we assume than during the attack least one peer is honest, then we could directly ask every peer to give us the blocks of their best-chains at the same heights of the presented proof. No back-links are necessary. If any peer shows a different block, then we should carefully detect which of the two
Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Testnet vs mainnet is quite a separate issue than bitcoin vs altcoin. Unfortunately few of the alts ever figured this out. On 04/22/2014 01:39 AM, Tamas Blummer wrote: Extra encoding for testnet is quite useless complexity in face of many alt chains. BIPS should be chain agnostic. Regards, Tamas Blummer http://bitsofproof.com -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Economics of information propagation
That wasn't what I was saying. Right now the primacy of a block is determined by the time at which the `block` message is received, which is delays due to both the time it takes to transmit the block data and the time it takes to validate. Headers-first, on the other hand, has the option of basing primacy on the time the block header is received, which is O(1) time to transmit and to SPV-validate. Mining on that block doesn't actually commence until the full block is received and validated. To see how this works, take an example: two blocks with a common parent are found relatively close to each other, block A and block B. A is found first but is a large block with the maximum block size and many slow scripts. B is found a few seconds later and is an empty block. In the current regime it is entirely possible that block B, the later but smaller block, would get received and processed first by more mining peers than the larger block A, exactly as described in Jonathan Levin's email. With headers-first, however, the cost of propagation of the block header is the same and we should expect block A to win out over block B nearly every time. Miners will continue working on the old, known valid parent block until the contents of block A are received and processed. So the smaller block B is still found, and since it's data moves across the network faster, miners even briefly mine on block B. But as soon as they receive and process the contents of block A, they switch to that. The earlier, larger block A will only become stale if *two* blocks are found in the extra time it takes for block A to propagate the network. That is a substantially different risk, and probably a negligible concern to most miners. On 04/20/2014 09:06 PM, Peter Todd wrote: That is mistaken: you can't mine on top of just a block header, leaving small miners disadvantaged as they are earning no profit while they wait for the information to validate the block and update their UTXO sets. This results in the same problem as before, as the large pools who mine most blocks can validate either instantly - the self-mine case - or more quickly than the smaller miners. Of course, in reality smaller miners can just mine on top of block headers and include no transactions and do no validation, but that is extremely harmful to the security of Bitcoin. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Economics of information propagation
As soon as we switch to headers first - which will be soon - there will be no difference in propagation time no matter how large the block is. Only 80 bites will be required to propagate the block header which establishes priority for when the block is fully validated. On Apr 20, 2014 6:56 PM, Jonathan Levin jonathan.le...@sant.ox.ac.uk wrote: Hi all, I am a post-graduate economist writing a paper on the incentives of mining. Even though this issue has been debated in the forums, I think it is important to get a sense of the magnitude of the incentives at play and determine what implications this has for the transaction fee market. As it has been pointed out before the marginal cost for miners does not stem from the private cost of the miner validating the signature and including it in the list of transactions in the block but rather the increased probability that the block will be orphaned as a result of slower propagation. Gavin did some back of the envelope worst case calculations but these overstated the effect of propagation delay. The reason being the 80ms additional time to reach 50% of the network is spread throughout the time that it takes to reach 50% of the network. During this time miners are notified about the block and treat it as the longest chain and hence are no longer mining with the aim to produce a competing block. I am looking to calculate the change in the curvature of the probability mass function that a block hears about my block in any given second as a function of the block size. Although there is likely to be significant noise here, there seems to be some stable linear relationships with the time that it takes to reach different quartiles. Has anyone done this? I have used some empirical data that I am happy to share but ideally I would like analytical solutions. Following Peter Todd, I also find the concerning result that propagation delays results in increasing returns to higher shares of the hashing power. Indeed it may well be in the interest of large pools to publish large blocks to increase propagation delays on the network which would increase orphan rates particularly for small miners and miners that have not invested in sufficient bandwidth / connectivity. If a small miner hears about a block after 4.5 seconds on average there is a 0.7% chance that there is already a block in circulation. Large miners can increase the time that it takes for small miners to hear about blocks by increasing the size of their blocks. For example if the time that it takes for a small miner to hear about the block goes to 12 seconds there is a 2 percent chance there is already a block in circulation for the small miner. There is also a 1.2% chance that there will be a competing block published after a small miner propagates in the time that it gets to full propagation. Am I getting this right that the probability of a miner’s block being orphaned is comprised of the probability that the miner was not the first to find a valid block and the probability that given they are first, someone else in the absence of hearing about it finds a competing valid block. One question is: Are orphans probabilistic and only resolved after hearing about a new block that lengthens the chain or is there a way to know in advance? Is it frowned upon to mine on top of a block that you have just found even though it is very likely going to end up an orphan? Would be happy to share the draft form of the paper and receive any feedback. Finally, at coinometrics we are working on a modified client to capture information on network propagation and would invite any suggestions of any other useful statistics that would be useful in the development of software. Best, Jonathan On 21 Apr 2014, at 01:16, bitcoin-development-requ...@lists.sourceforge.net bitcoin-development-requ...@lists.sourceforge.net wrote: Send Bitcoin-development mailing list submissions to bitcoin-development@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/bitcoin-development or, via email, send a message with subject or body 'help' to bitcoin-development-requ...@lists.sourceforge.net You can reach the person managing the list at bitcoin-development-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of Bitcoin-development digest... Today's Topics: 1. Re: bits: Unit of account (Oliver Egginger) 2. Re: bits: Unit of account (Christophe Biocca) 3. Re: bits: Unit of account (Gmail) 4. Re: bits: Unit of account (Mike Caldwell) 5. Re: bits: Unit of account (Justin A) -- Message: 1 Date: Sun, 20 Apr 2014 20:43:24 +0200 From: Oliver Egginger bitc...@olivere.de Subject: Re:
Re: [Bitcoin-development] Timed testing
Not necessarily. Running a private server involves listening to the p2p network for incoming transactions, performing validation on receipt and organizing a mempool, performing transaction selection, and relaying blocks to auditors - none of which is tested in a reindex. A reindex would give you an optimistic upper bound though, if that's all you care about. On 04/17/2014 08:49 AM, Mike Hearn wrote: 2) If I wanted to measure validation performance, to get the number of peak tps that could be processed without taking block sides or network latency into account, how would I do that? Has anybody tried this before? You can just reindex/replay the chain. It's been done many times. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)
XP is no longer receiving security patches from Microsoft, and hasn't been for some time. There are known remote exploits that aren't going to be fixed, ever. On Apr 16, 2014 8:15 AM, Kevin kevinsisco61...@gmail.com wrote: On 4/16/2014 4:14 AM, Wladimir wrote: Hello, Today I noticed that even my bank is warning people to not do internet banking with Windows XP. If it is no longer secure enough for online banking it's CERTAINLY not secure enough to run a wallet (for a node only it would be ok-ish as they have no keys to protect). Any opinions on what to do here? Just warn and allow the user to continue? Redirect them to a 'Windows XP is dangerous' message on bitcoin.org? (Microsoft uses http://windows.microsoft.com/en-us/windows/end-support-help) The drawback of dropping XP support completely would be that a lot of computers (especially in China and Russia etc) are still running XP, so this could cause the network to lose nodes. If you're maintainer of other wallet software: how are you handling this? Are you going to drop XP support completely? If so, starting from when? Regards, Wladimir -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today!http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development I think we should get to the bottom of this. Should we assume that xp is not secure enough? What is this warning? Who is issuing this warning? -- Kevin -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)
On 04/16/2014 09:27 AM, Kevin wrote: Should we then add an alert message to wallet installers such as, Such and such will not run on windows xp? It's not really our place to police that ... plus it's perfectly safe to be running Bitcoin Core as a full node on XP. It's just the wallet functionality that people should be careful about. We're talking about such a small intersection of people who are running XP, have systems powerful enough to run Bitcoin Core, and use the wallet functionality. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)
We don't support XP. In fact we don't support *any* distribution, but I will assume you mean provide a binary which runs on X. Can you find any reference to Windows XP on the website? I can't. On 04/16/2014 09:41 AM, Chris Williams wrote: It may not be our place to say whether XP is secure or not, but if we say that we support it then we have to run test passes against XP as a platform, and if an XP user reports a bug, then we have to do something to address it. So, it becomes a test and support issue, not a security issue. That’s why it doesn’t make sense to support an OS platform that the original vendor (MS) no longer supports themselves. On Apr 16, 2014, at 9:35 AM, Mark Friedenbach m...@monetize.io wrote: On 04/16/2014 09:27 AM, Kevin wrote: Should we then add an alert message to wallet installers such as, Such and such will not run on windows xp? It's not really our place to police that ... plus it's perfectly safe to be running Bitcoin Core as a full node on XP. It's just the wallet functionality that people should be careful about. We're talking about such a small intersection of people who are running XP, have systems powerful enough to run Bitcoin Core, and use the wallet functionality. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)
On 04/16/2014 02:29 PM, Kevin wrote: Okay, so how about an autoupdate function which pulls a work around off the server? Sooner or later, the vulnerabilities must be faced. NO. Bitcoin Core will never have an auto-update functionality. That would be a single point of failure whose compromise could result in the theft of every last bitcoin held in a Bitcoin Core wallet. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain pruning
You took the quote out of context: a full node can copy the chain state from someone else, and check that its hash matches what the block chain commits to. It's important to note that this is a strict reduction in security: we're now trusting that the longest chain (with most proof of work) commits to a valid UTXO set (at some point in the past). The described synchronization mechanism would be to determine the most-work block header (SPV level of security!), and then sync the UTXO set committed to within that block. This is strictly less security than building the UTXO set yourself because it is susceptible to a 51% attack which violates protocol rules. On 04/10/2014 11:19 AM, Paul Rabahy wrote: You say UTXO commitments is a strict reduction in security. If UTXO commitments were rolled in as a soft fork, I do not see any new attacks that could happen to a person trusting the committed UTXO + any remaining blocks to catch up to the head. I would imagine the soft fork to proceed similar to the following. 1. Miners begin including UTXO commitments. 2. Miners begin rejecting blocks with invalid UTXO commitments. 3. Miners begin rejecting blocks with no UTXO commitments. To start up a fresh client it would follow the following. 1. Sync headers. 2. Pick a committed UTXO that is deep enough to not get orphaned. 3. Sync blocks from commitment to head. I would argue that a client following this methodology is strictly more secure than SPV, and I don't see any attacks that make it less secure than a full client. It is obviously still susceptible to a 51% attack, but so is the traditional block chain. I also do not see any sybil attacks that are strengthened by this change because it is not modifying the networking code. I guess if the soft fork happened, then miners began to not include the UTXO commitment anymore, it would lower the overall network hash rate, but this would be self-harming to the miners so they have an incentive to not do it. Please let me know if I have missed something. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Chain pruning
Checkpoints will go away, eventually. On 04/10/2014 02:34 PM, Jesus Cea wrote: On 10/04/14 18:59, Pieter Wuille wrote: It's important to note that this is a strict reduction in security: we're now trusting that the longest chain (with most proof of work) commits to a valid UTXO set (at some point in the past). AFAIK, current bitcoin code code already set blockchain checkpoints from time to time. It is a garanteed that a longer chain starting before the checkpoint is not going to be accepted suddently. See https://bitcointalk.org/index.php?topic=194078.0. Could be perfectly valid to store only unspend wallets before last checkpoint, if during the blockchain download the node did all the checks. Would be interesting, of course, to be able to verify unspend wallet accounting having only that checkpoint data (the merkle tree can do that, I guess). So you could detect a data corruption or manipulation in your local harddisk. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
On 04/09/2014 09:09 AM, Tamas Blummer wrote: Yes, SPV is a sufficient API to a trusted node to build sophisticated features not offered by the core. SPV clients of the border router will build their own archive and indices based on their interest of the chain therefore the border router core does not need to store (and process) anything not needed for consensus, its memory or disk footprint would be as low as an optimal storage of UTXO. Storing zero full blocks does nothing to aid the network. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
I've advocated for this in the past, and reasonable counter-arguments I was presented with are: (1) bittorrent is horribly insecure - it would be easy to DoS the initial block download if that were the goal, and (2) there's a reasonable pathway to doing this all in-protocol, so there's no reason to introduce external dependencies. On 04/09/2014 01:31 PM, slush wrote: Another idea: Integrate torrent download of bootstrap.dat into bitcoind. Normal user (especially a beginner) won't learn how to download bootstrap separately and import it into bitcoind; he simply give up the synchronization once he realize it takes too much time. From my experience downloading the bootstrap significantly improves catching the blockchain, which may attract some more users to run bitcoind. Not sure about C++, but simple torrent client in python is like 30 lines of code (using libtorrent). Marek On Wed, Apr 9, 2014 at 10:12 PM, slush sl...@centrum.cz mailto:sl...@centrum.cz wrote: I believe there're plenty bitcoind instances running, but they don't have configured port forwarding properly.There's uPNP support in bitcoind, but it works only on simple setups. Maybe there're some not yet considered way how to expose these *existing* instances to Internet, to strenghten the network. Maybe just self-test indicating the node is not reachable from outside (together with short howto like in some torrent clients). These days IPv6 is slowly deploying to server environments, but maybe there's some simple way how to bundle ipv6 tunnelling into bitcoind so any instance will become ipv6-reachable automatically? Maybe there're other ideas how to improve current situation without needs of reworking the architecture. Marek On Wed, Apr 9, 2014 at 9:33 PM, Gregory Maxwell gmaxw...@gmail.com mailto:gmaxw...@gmail.com wrote: On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier justusranv...@gmail.com mailto:justusranv...@gmail.com wrote: Anyone reading the archives of the list will see about triple the number of people independently confirming the resource usage problem than they will see denying it, so I'm not particularly worried. The list has open membership, there is no particular qualification or background required to post here. Optimal use of an information source requires critical reading and understanding the limitations of the medium. Counting comments is usually not a great way to assess technical considerations on an open public forum. Doubly so because those comments were not actually talking about the same thing I am talking about. Existing implementations are inefficient in many known ways (and, no doubt, some unknown ones). This list is about developing protocol and implementations including improving their efficiency. When talking about incentives the costs you need to consider are the costs of the best realistic option. As far as I know there is no doubt from anyone technically experienced that under the current network rules full nodes can be operated with vastly less resources than current implementations use, it's just a question of the relatively modest implementation improvements. When you argue that Bitcoin doesn't have the right incentives (and thus something??) I retort that the actual resource _requirements_ are for the protocol very low. I gave specific example numbers to enable correction or clarification if I've said something wrong or controversial. Pointing out that existing implementations are not that currently as efficient as the underlying requirements and that some large number of users do not like the efficiency of existing implementations doesn't tell me anything I disagree with or didn't already know. Whats being discussed around here contributes to prioritizing improvements over the existing implementations. I hope this clarifies something. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
Flavien, capital is wealth or resources available for the stated purpose of the company. These bitcoins represent nothing more than a speculative floor owned by the investors, not the company. On 04/07/2014 07:00 AM, Flavien Charlon wrote: Jorge, they'd have to be. Otherwise, assuming the price of the share goes low enough, you could buy a share of the company, melt the gold plate, and sell it for a profit. If the gold is part of the capital of the company, the cheapest a share can be is the price of the gold on which the stock certificate is printed. This is why I think the importance of padding with colored coins is overblown. On Mon, Apr 7, 2014 at 1:12 PM, Jorge Timón jti...@monetize.io mailto:jti...@monetize.io wrote: On 4/7/14, Flavien Charlon flavien.char...@coinprism.com mailto:flavien.char...@coinprism.com wrote: Also those 54 BTC (actually 5.4 BTC if the dust is now 540 satoshis) become part of the capital of the company, and can always be recovered by uncoloring the shares. It's an investment, not an expense, so I think it is acceptable. This doesn't make much sense to me. If you print shares on gold plates instead of paper, is that gold part of the capital of the company? I don't think so. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
Right now running a full-node on my home DSL connection (1Mbps) makes other internet activity periodically unresponsive. I think we've already hit a point where resource requirements are pushing out casual users, although of course we can't be certain that accounts for all lost nodes. On 04/07/2014 08:53 AM, Gregory Maxwell wrote: On Mon, Apr 7, 2014 at 8:45 AM, Justus Ranvier justusranv...@gmail.com wrote: 1. The resource requirements of a full node are moving beyond the capabilities of casual users. This isn't inherently a problem - after all most people don't grow their own food, tailor their own clothes, or keep blacksmith tools handy in to forge their own horseshoes either. Right now running a full node consumes about $1 in disk space non-reoccurring and costs a couple cents in power per month. This isn't to say things are all ducky. But if you're going to say the resource requirements are beyond the capabilities of casual users I'm afraid I'm going to have to say: citation needed. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development . -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
On 04/07/2014 09:57 AM, Gregory Maxwell wrote: That is an implementation issue— mostly one that arises as an indirect consequence of not having headers first and the parallel fetch, not a requirements issue. Oh, absolutely. But the question why are people not running full nodes? has to do with the current implementation, not abstract capabilities of a future version of the bitcoind code base. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
On 04/07/2014 12:00 PM, Tamas Blummer wrote: Once a single transaction in pruned in a block, the block is no longer eligible to be served to other nodes. Which transactions are pruned can be rather custom e.g. even depending on the wallet(s) of the node, therefore I guess it is more handy to return some bitmap of pruned/full blocks than ranges. The point is that the node has decided not to prune transactions from that block, so that it is capable of returning full blocks within that range. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
On 04/07/2014 12:20 PM, Tamas Blummer wrote: Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous. And how do you find those blocks? I have a suggestion: have nodes advertise which range of full blocks they possess, then you can perform synchronization from the adversed ranges! -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tree-chains preliminary summary
I'm afraid I'm going to be the jerk that requested more details and then only nitpicks seemingly minor points in your introduction. But its because I need more time to digest the contents of your proposal. Until then: But moving value between chains is inconvenient; right now moving value requires trusted third parties. Two-way atomic chain transfers does help here, but as recent discussions on the topic showed there's all sorts of edge cases with reorganizations that are tricky to handle; at worst they could lead to inflation. This isn't true. The re-org issue is fairly handled in the 2-way pegging scheme that Greg Maxwell developed and Adam Back described a week ago on this list. Depending on the implementation it could even be configurable by the person performing the peg too - allowing the transfer to specify the confirmation depth required during the quieting period in order to protect against re-orgs up to a sufficient depth. I think this is worked out quite well with sufficient enumeration of edge cases, and I don't think they are particularly tricky to handle or lead to money-losing situations under the explicit security assumptions. More importantly, to your last point there is absolutely no way this scheme can lead to inflation. The worst that could happen is theft of coins willingly put into the pegging pool. But in no way is it possible to inflate the coin supply. I will look at your proposal in more depth. But I also think you should give 2-way pegging a fair shake as pegging to side chains and private accounting servers may eliminate the need. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
On 03/24/2014 01:34 PM, Troy Benjegerdes wrote: I'm here because I want to sell corn for bitcoin, and I believe it will be more profitable for me to do that with a bitcoin-blockchain-based system in which I have the capability to audit the code that executes the trade. A discussion over such a system would be on-topic. Indeed I have made my own proposals for systems with that capability in the past: http://sourceforge.net/p/bitcoin/mailman/message/31322676/ There's no reason to invoke alts however. There are ways where this can be done within the bitcoin ecosystem, using bitcoins: http://sourceforge.net/p/bitcoin/mailman/message/32108143/ I think that's fair, so long as we limit bitcoin-development discussion to issues that are relevant to the owners of the hashrate and companies that pay developer salaries. What I'm asking for is some honesty that Bitcoin is a centralized system and to stop arguing technical points on the altar of distributed/decentralized whatever. It's pretty clear if you want decentralized you should go with altchains. Bitcoin is not a centralized system, and neither is its development. I don't even know how to respond to that. Bringing up altchains is a total red herring. This is *bitcoin*-development. Please don't make it have to become a moderated mailing list. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
This isn't distributed-systems-development, it is bitcoin-development. Discussion over chain parameters is a fine thing to have among people who are interested in that sort of thing. But not here. On 03/23/2014 04:17 PM, Troy Benjegerdes wrote: I find it very irresponsible for Bitcoiners to on one hand extol the virtues of distributed systems and then in the same message claim any discussion about alternate chains as 'off-topic'. If bitcoin-core is for *distributed systems*, then all the different altcoins with different hash algorithms should be viable topics for discussion. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee
Please, by all means: ignore our well-reasoned arguments about externalized storage and validation cost and alternative solutions. Please re-discover how proof of publication doesn't require burdening the network with silly extra data that must be transmitted, kept, and validated from now until the heat death of the universe. Your failure will make my meager bitcoin holdings all the more valuable! As despite persistent assertions to the contrary, making quality software freely available at zero cost does not pay well, even in finance. You will not find core developers in the Bitcoin 1%. Please feel free to flame me back, but off-list. This is for *bitcoin* development. On 03/22/2014 08:08 AM, Troy Benjegerdes wrote: On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote: There's been a lot of recent hoopla over proof-of-publication, with the OP_RETURN data length getting reduced to a rather useless 40 bytes at the last minute prior to the 0.9 release. Secondly I noticed a overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken into account, making it possible to broadcast unminable transactions and bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG outputs given that the sigops limit and the way they use up a fixed 20 sigops per op makes them hard to do fee calculations for. They also make it easy to bloat the UTXO set, potentially a bad thing. This would of course require things using them to change. Currently that's just Counterparty, so I gave them the heads up in my email. I've spend some time looking at the Datacoin code, and I've come to the conclusion the next copycatcoin I release will have an explicit 'data' field with something like 169 bytes (a bakers dozen squared), which will add 1 byte to each transaction if unused, and provide a small, but usable data field for proof of publication. As a new coin, I can also do a hardfork that increases the data size limit much easier if there is a compelling reason to make it bigger. I think this will prove to be a much more reliable infrastructure for proof of publication than various hacks to overcome 40 byte limits with Bitcoin. I am disclosing this here so the bitcoin 1% has plenty of time to evaluate the market risk they face from the 40 byte limit, and put some pressure to implement some of the alternatives Todd proposes. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
Jeff, there are *plenty* of places that lack local Internet access for one or both participants. Obviously making the case where both participants lack access to the bitcoin network is difficult to secure, but not impossible (e.g. use a telephany-based system to connect to a centralized double-spend database, as VISA does). I expect the case where one participant has Internet access (the merchant) and the other does not to be very, very common. The majority of transactions I do on a daily basis are like this, and I live in Silicon Valley! On 03/22/2014 09:35 AM, Jeff Garzik wrote: Let's not pull out silly examples. Of course you can find locations that lack Internet. Those locations are completely unsuitable to bitcoin transactions, since the receiver cannot verify double-spending or anything else about the transaction. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Compact SPV proofs via block header commitments
, as the compact proofs scale logarithmically with the number of blocks. Finally the most important and driving use case: symmetrical two-way pegging between bitcoin and side-chains is made efficient enough to be reduced to practice by the availability of compact SPV proofs[1]. The compact SPV proofs allow both the necessary proofs-of-spend and proofs-of-reorg to fit within current blockchain size limitations, and provide incentives for keeping this data out of the block chain until it is absolutely necessary. ==References== This specific compact SPV proof proposal arose from pegging discussion involving a number of people #bitcoin-wizards: Greg Maxwell, Matt Corallo, Pieter Wuille, Luke-Jr, Jorge Timon, and Mark Friedenbach. It is believed that the first explanation of this general idea is due to Andrew Miller in his 7 Aug 2012 forum post titled The High-Value-Hash Highway[2]. [1]http://sourceforge.net/p/bitcoin/mailman/message/32108143/ [2]https://bitcointalk.org/index.php?topic=98986.0 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTJy/eAAoJEAdzVfsmodw4zC4P/izBRTutwypwQ70TxPxxHYfH I4QOpf+MgWHxrD+DKKyqkC2icgUBQz96K1vEhA86PrmK8DITs5yGHLSw7CEF/rlG hZErVY65IpowPt+JnlwOqHcqaoJ277s+4qpd/D9F7L1ROAMUDzzonf7V1Znr/fax lL4b8whfUI5jeRQby/tMiGPUB/1YJcbGmFccTW9gkGWMvoqZiiXcW7ZKuLrq5tbW RFIsrSt7rv3D0Cp2Fiyaxnryr2F0QOTqahHLn50+585eHpVFrA9A5T6xiBcEMzlQ l5cHRZb+lVIktWuYomBiqWljPLo5qercVDrehIq9FFSYuJqzudNx9ZXrpF1ZR4in UfZvlYqMFO/ZOTG33JWeeMonKlVwfHH2WreggzSq/JD/cH8dUj63A266Gaf6cl83 vEfhgVBDTXZnl5H9Z7wymja6R9m9Eo/Xf+GwRV4vyx1b9gcZXML4Zm4bTp4EXFHA StBGrYKmMpEb/gguk/hxJLsm0i9pVaQpMC0u3kClHTA5o0IFF9F5+mVjOb59HlDX AQx96TSwJzhl0l0jcxYye8bXmZFJvpzpsKRPwNISllLEagjplwK2Ub8q5du27lH5 R2qukcso6N5weGggUu1f7NrqcBALdz4E80SSpwu4YtJ6wdI4zsypaq4leqbSRSKh /hLKeOV5fEGNmwTtrDmN =j9cm -END PGP SIGNATURE- -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
This ship may have already sailed, but... Using milli- and micro- notation for currency units is also not very well supported. Last time this thread was active, I believe there was a suggestion to use 1 XBT == 1 uBTC. This would bring us completely within the realm of supported behavior in accounting applications. On 03/13/2014 09:29 AM, Jeff Garzik wrote: On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner etothe...@gmail.com wrote: Of course, as Mike said, this ship may have already sailed, but if there's any way to revisit this, I'm there. We're just about to do another Armory release and could support this very easily. mBTC now just means the issue -will- be revisited in the future. Just a question of when, not if. People and software in various nations handle big numbers for small values (e.g. Yen) just fine. People and software do -not- handle extra decimal places well, field experience shows. vendor hat: on To roll out QuickBooks support --without converting any numbers, a key financial attribute-- mBTC is simply insufficient today, not in the future. I also argue that it is a security risk, as follows: To support accounting packages limited to 2 decimal places, decimal point conversion must be performed. This produces a situation where your accounting system shows numbers that do not visually match the numbers in the bitcoin software. That, in turn, making auditing more difficult, particularly for outsiders. Shipping with mBTC defaults was decidedly unwise, considering that -- like BTC -- it fails to solve existing, known problems that uBTC can solve, and considering the inevitable mBTC-uBTC switch. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth
Only if you view bitcoin as no more than a payment network. On Mar 1, 2014 10:24 AM, Jeff Garzik jgar...@bitpay.com wrote: This is wandering far off-topic for this mailing list. On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org wrote: You can make the same argument against Bitcoin itself you know... A Bitmessage-like network would be trivial to front-run via a sybil attack. It's the fundemental problem with marketplaces - the data they're trying to publish has to be public. I don't see the Bitcoin analogy... Anyway, I still don't think the seller cares, if he sells at the price he was asking, what would he care about front running those parallel networks. I've seen many street markets without public information and they work just well. The spot price for ammonia fertilizer, refined gasoline at terminals, and price of tea in china are not 'public information', yet these are some of the largest traded commodities in the world, far exceeding the drop in the bucket that all cryptocoin transactions make. I'd further argue that the *actual* price of corn (cash bid price at elevators and ethanol plants) is not public information either. There is a great deal of money traded in collecting and then distributing the 'cleared price' information. Have a look at http://www.interquote.com/template.cfm?navgroup=aboutlisturlcode=12view=1 I don't think this will be a tragedy, because like we discussed on IRC, I don't think the primary goal of markets is price discovery, but trade itself. About historic data, the actual trades are always public, and some kind of archivers could collect and maintain old orders for historic bid and asks, etc. And again, how do you know that record is honest? Fact is without proof-of-publication you just don't. Well, the trades that appeared in the chain actually occurred. Buying to yourself at fake prices? Be careful, the miner could just separate the order and fill it himself. Or anyone paying a higher fee, for that matter. You just made my long-term strategic argument for investing in my own mining hardware so I can be sure to trade reliably. Again, you haven't addressed why the seller cares more about accurate historic market data than just his own fees and sell. You mean a reverse nLockTime that makes a transaction invalid after a certain amount of time - that's dangerous in a reorg unfortunately as it can make transactions permenantly invalid. People who take money from buyers and sellers care most about 'accurate historic market data'. I just want to exchange my corn for e85, fertilizer, and electricity, and audit the code that runs accounting for the exchange. I really don't give a shit if there is 'accurate historic market data' as long as **MY** personal trade data is accurate and I got a good enough price, and I know who I'm dealing with. I know someone smarter than me and with more money, market leverage, and political connections **WILL** game the system and distort the market data history so they can take more money from buyers and sellers without actually doing some usefull market function. As long as use buyers and sellers can see the code, and have a good eye for knowing when someone's pushing the market around, we can just put our orders in and relieve some speculators of their money. Just get me working code for cross-chain trades, and we'll work on the accurate historic data problem later. Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Transaction fees are a DoS mitigating cost to the person making the transaction, but they are generally not paid to the people who actually incur costs in validating the blockchain. Actual transaction processing costs are an externality that is completely unpaid for. When I add a 1Kb transaction to the blockchain, there is an attached fee which probabilistically goes to one of the miners. But every other full node on the network also receives this transaction, processes it, and adds it to local storage. From now until the heat death of the universe that 1Kb of data will be redundantly stored and transmitted to every single person who validates the block chain. None of these countless people are reimbursed for their storage, bandwidth, and processing costs. Not even a single satoshi. Yes, transaction fees are broken. But it is their very nature which is broken (sending coins to the miners, not the greater validator set), and no little tweak like the one Warren links to will fix this. But, in the absence of a reformed fee regime - which it is not clear is even possible - one could at least make the hand-wavey argument that people who validate the block chain receive benefit from it as a payment network. Therefore processing of the block chain is paid for by the utility it provides once fully synced. However even this weak argument does not extend to general data storage. If you want to put all of wikileaks or whatever in the block chain, then you are extracting a rent from every full node which is forced to process and store this data for eternity without compensation or derived utility. You are extorting users of the payment network into providing a storage service at no cost, because the alternative (losing bitcoin as a payment network) would cost them more. That is not ethical behavior. That is not behavior which responsible developers should allow in the reference client. Mark On 02/28/2014 06:42 AM, Warren Togami Jr. wrote: On Thu, Feb 27, 2014 at 7:25 PM, Troy Benjegerdes ho...@hozed.org mailto:ho...@hozed.org wrote: Either the transaction fees are sufficient to pay the cost for whatever random junk anyone wants to put there, or they are not, and if they are not, then I suggest you re-think the fee structure rather than trying to pre-regulate me putting 80 character pithy quotes in the blockhain. https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d In one way in particular, the transaction fees per kilobyte completely failed to account for the actual cost to the network. If Bitcoin had adopted a common-sense rule like this, I would have had no reason to join Litecoin development last year. This is one of the few economic design flaws that Satoshi overlooked in the original design. As much as I personally hate the idea of data storage in the blockchain, this at least discourages the creation of permanent UTXO. Warren Togami -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTEOKjAAoJEAdzVfsmodw4vGIQAJ9OQvHl1+dIaDelrf03lGIf kQsiuB4JG1rRghsZZiW4NixPbB/Bdm4+m4pep01eiVOPXa+/32AgWVzSYyyMVRYB oTu24ITgtCu5vkjiHyzSavFnqsi+zMxVpscUekA6l6Tkr3RBNnrIssMiazYc+Bkx fP2vZehmPHQtp09WkapZ3DMqbMzQ7qPTGlKd1V+9X4S5uUNTdfT6JkC0HIqUSdVQ PHjjbuulgkdz4b7A6C2dE5kwXVKF9YFHL3zEtObfWDCiyY8wf2XHYI6nVGLbyQeN nrYCsMH99lUy+zmnbccqSPKhe0p5IaBLauk75zcLxEfzxuKVTvVg2LCaCXQaworv vBoAURdrB2pCfK8dZ7mllVLLLcNk+iOG0NDZHYE9e884OBfeuaG/zNgmgOD8GC1H FaDkIpm79x/i3ti3h8vdZPeY0fWdI8yuD9aCQZtvONM9hXdd7Qb07eHqIk7tY/In 7h6zdq27GQUdWN37yslxtDENY2q3yQ39+fjMGQEKVIE6rNwDyjurMCNHAWJp0hZO 7S/rDe2W2tHGPYakscHQh1g/uMAEEb4mGGc5yrfWxyOn5eb9OZiZb8RVXlnDwwH9 qr8qwLJ1b0Uxo981lyEmnLZSpCpAZvDLpjmocqirycNZpvyPnJJbE809vS/koD3d OutJkMja4TBuqaMSdKEI =KbW/ -END PGP SIGNATURE- -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool.
[Bitcoin-development] Base-32 error correction coding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What follows is a proposed BIP for human-friendly base-32 serialization with error correction encoding. A formatted version is viewable as part of a gist with related code: https://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki An implementation of this BIP and associated APIs is made available as a pull request, with comprehensive testing: https://github.com/bitcoin/bitcoin/pull/3713 This format is anticipated to be useful for helpdesk-related data (e.g. the proposed normalized transaction ID), and future wallet backup paper wallet serialization formats. == Abstract == The BIP proposes an human-centered encoding format for base-32 data serialization. It differs from the presumptive default hexadecimal or base58 encodings in the following ways: 1. Visually distinctive in that it includes the full range of alphanumeric digits in its base-32 encoding, except the characters 0, l, v, and 2. which are too easily confused with 1, i, u, r, or z in font or handwriting. 2. Automatic correction of up to 1 transcription error per 31 coded digits (130 bits of payload data). For a 256-bit hash or secret key, this enables seamless recovery from up to two transcription errors so long as they occur in separate halves of the coded representation. 3. Highly probable detection of errors beyond the error correction threshold, with a false negative rate on the order of 25 bits, or 1 in 33 million likelihood. 4. Case-insensitive encoding ensures that it may be displayed in an easier to read uniform case, and it is faster and more comfortable to vocally read off a base-32 encoded number than the alternatives of hexadecimal or base58. In addition to the error correction code transformation of base-32 data, a padding scheme is specified for extending numbers or bit vectors of any length to a multiple of 5 bits suitable for base-32 encoding. == z-base-32 == The bitcoin reference client already has one implementation of base-32 encoding following the RFC 3548 standard, using the following alphabet: const char *pbase32 = abcdefghijklmnopqrstuvwxyz234567; For error correction coded strings this BIP specifies usage of Phil Zimmermann's z-base-32 encoding alphabet[], which provides better resistance to transcriptive errors than the RFC 3548 standard: const char *pzbase32 = ybndrfg8ejkmcpqxot1uwisza345h769; The same RFC 3548 coder is used for z-base-32, except that unnecessary '=' padding characters are stripped before performing the alphabet substitution. For example, the hexadecimal string 'ae653be0049be3' is RFC 3548 encoded as 'vzstxyaetprq', and z-base-32 encoded as 'i31uzayruxto'. == CRC-5-USB error correction coding == Herein we describe an error correction encoding using cyclic redundancy check polynomial division[], which requires 5 error correction digits per 26 digits of input, instead of the theoretically optimal 4, but is much, much easier to implement correctly then available non-patented error correction codes. Cyclic redundancy check polynomial division provides a very straightforward, patent-free mechanism for reliably detecting transcription errors in input, and performing up to 1-digit corrections per 26 digit block. === Encoding === The input to this error correction encoder is a sequence of 26 base-32 digits. These digits are decoded into 5-bit unsigned integers with values equal to their offset into the base-32 alphabet string. If the input is less than 26 digits in length, it is extended with zero-valued digits. If For example, the string 'vzstxyaetprq' using the RFC 3548 alphabet becomes the code point sequence: 21 25 18 19 23 24 0 4 19 15 17 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0' |--input-|-padding--| Expositionally it helps to think of this array as a 26-element column vector of 5-bit binary integers: 0b10101 0b11001 0b10010 0b10011 0b10111 0b11000 0b0 0b00100 0b10011 0b0 0b10001 0b1 ... 14 zero elements ... If we explode the bits of each element into 5, 1-bit columns, we get a 26 x 5 matrix: 1 0 1 0 1 1 1 0 0 1 1 0 0 1 0 1 0 0 1 1 1 0 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0 0 1 0 0 1 1 0 1 1 1 1 1 0 0 0 1 1 0 0 0 0 ... 14 x 5 zero elements ... The array is then transposed, such that we get a 5 x 26 matrix where each row represents the 5th, 4th, 3rd, 2nd, or 1st bit, respectfully, of each element: 1 1 1 1 1 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 1 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 |-input|--padding-| We then use each of these rows separately as input into a cyclic redundancy check polynomial division operation,
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
On 02/12/2014 08:44 AM, Alan Reiner wrote: Changing the protocol to use these static IDs is a pretty fundamental change that would never happen in Bitcoin. But they can still be useful at the application level to mitigate these issues. Not to mention that it would be potentially very insecure to have consensus depend on data (scriptSigs) which are not hashed in the Merkle structure of a block. Not that anyone on this list has suggested such a change, but I've seen it raised multiple times on the forum Mark -- Android apps run on BlackBerry 10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039: Final call
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since you are taking the hash of Unicode data, I would strongly recommend using a canonical form, e.g. Normalized Form C. On 01/20/2014 09:42 AM, slush wrote: Hi all, during recent months we've reconsidered all comments which we received from the community about our BIP39 proposal and we tried to meet all requirements for such standard. Specifically the proposal now doesn't require any specific wordlist, so every client can use its very own list of preferred words. Generated mnemonic can be then applied to any other BIP39-compatible client. Please follow current draft at https://github.com/trezor/bips/blob/master/bip-0039.mediawiki. Because we're quickly moving towards release of Trezor firmware and we need to finalize this part of the firmware, we're asking for the last comments to current BIP39 draft. Thanks, slush -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS3ZzAAAoJEAdzVfsmodw4L3sP/2VjvICLTYlkZcY6brBIZhoU P6ei6qECzmBCWpW5iC1r99j76bPwP3M6jH6P7iBljj72J5NgHXq+K8GvA5M6qu0o 6s+WJ7HYJ8KwRZuvGPvcopXBKJAJXadrN7xSPikYD2zMm2KCZTUI5IurR1p/dpUR 3HzL2RdjbDugBOiAjiMMq0dAs1x9/vmF0F2KDZHiCJEtP/+gbtOE/KmXrnrAJSNI Aswb/lZg1GWGpOs+iCdEaRfST2PIL/jGgnteJ4iKHvh2+dOW0/AhINo5g56LTVvU Q+pAv8SRLad/30PVaWAStrtLMxu+j0JQ1wgEkRCrsQ0xE3iKtmbppzh2dIQ8Idrt EkjqoykB2wn4Kw+QcT2TXIcBV7LBqSurE/jDWWIFtHxdV0++8PDYFOesq2Xf9Rif VStYnUVvUhuzGXD3oOnIGpEvMm2i30Qyi33oJLvqfWUBkzJzFdtZ+YYBYlbpwBOQ YLEr2DmVHLk/MXWL1POruvnIT4N+6uyh59HKHKRJI0nGMmRR3cBLkM8vEEHerD3P ucg++TTdqXM6XoSmIk55CQnGdglDJEOGc+gzaGffqeDMJhmz/apEawN5en7ogN0o XfWDWSdtwMvlza3F6cMejvBkuFZTLUxyaedP13vOTDhUIbmqsliyhwA2YrXE7udQ 1JMYADuvb18LYE/hQJX3 =Ycdc -END PGP SIGNATURE- -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
On 01/18/2014 03:05 AM, Wladimir wrote: On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla ABISprotocol hat: on regarding: stuff not getting into blockchain in a day's time, microdonations not facilitated as much as they could be, Please point to your pull requests improving these issues. If your organization didn't contribute anything to further these issues then there can't be much surprise that they didn't make it in, either. https://github.com/bitcoin/bitcoin/pull/1647 -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/17/2014 01:15 AM, Mike Hearn wrote: I must say, this shed is mighty fine looking. It'd be a great place to store our bikes. But, what colour should we paint it? How about we split the difference and go with privacy address? As Too close to private key, IMHO. Peter notes, that's what people actually like and want. The problem with stealth is it's got strong connotations with American military hardware and perhaps thieves sneaking around in the night: And ninjas. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS2PWHAAoJEAdzVfsmodw4QKoP/iCB62bthf+VyOAZFtP/LbU3 op//I06zOd6oj3zSM0B3Qwz0+H3L9OqWeo9yP1KzYb8YG7RelGf6KOh0LBQoo0bY eEv8EqvJiW0JOi7gmMsaBgxtZ99TKibGVWMramAV+pSOkKbbbQ23O8a3Y2uopZIg eypB9sUO9STTc/vwEKZRtefoXHWDUF8bXel/YfTGJQjOuxN/z6gsXRPp4xDvySL3 Ll3OvgEGrqIjIodvMZY+V5wzxj/TlU5kCKS6Vug/JEM1U0DmiBBikaR6Yus5m/fC yyxEQH8jATLZVsAac4Z16rQXj1nTRh4w6X9KCTynEaba5Z8fz38habUNxyjT8JG+ cP+QDQac9Nnxuw6gzM4QRkOiQas5eVNRdzNJ48k2SGDLb7AYPBO/URAV8Cd05caY Gx1ruC3MVGu7Fu1/9rtKeWMcNyAvpklzs9DhHfqNmYcRCl6NcoaCvxfq3NesI4Z9 uQrTfL9VBUXJJ2z8ZLe3ZAdBz46159JXCBKHIWwZ+fm0uPkelvoUo8oP+OdxwP1x wGCYmfvuf8lSnud8WM5EDDGo4+7GUU5Pnh9p+o6Lyp4d0WoplUmSvz2XriiANQjq z/Xo3B321sdLOEI/Nrqnn3S/hMveru7HO7xQx1aUATvYga4ZyFZh/Yp0bwOAESBZ GoG0piwQbQhoQZMslV4T =40o3 -END PGP SIGNATURE- -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CPFP is *extremely* important. People have lost money because this feature is missing. I think it's critical that it makes it into 0.9 If I get a low-priority donation from a blockchain.info wallet, that money can disappear if it doesn't make it into a block in 24 hours - bc.i will forget the transaction and happily respend its inputs on the next transaction that user makes. I wouldn't mind paying $1 in fees to receive a $50 donation. But without CPFP there's no way to do that. On 01/17/2014 12:53 PM, Jeff Garzik wrote: vendor hat: on BitPay sure would like to see CPFP in upstream. I think the main hurdle to merging was that various people disagreed on various edge case handling and implementation details, but no fundamental objections. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS2ZrQAAoJEAdzVfsmodw4CrwP+gM2iXLcvQK2VlhoN7kRCnvH +YJ87fXlMl0IcRqVDyaCF6w3+U/9VG+p+/eFvBNzxMMTbylWbsSXF6GxavwPhVt4 zw//VNLIfOu+88HsUofamvZJGHQOArwzlOYRgX1Lr9ms3KSQ2QWkW+Z6QD7qmkO2 bJNzxJ+vffmz24mQ6hg7a33YW+403TbeqxcPewbjNr76hvPEjzlTPhpVo4A/gqSu 6rcJPQIkFdTZX/xy5hyZsQzswNv/bYyrE9XhEIimsqt96sjTDrB4EZKzfkQ/jLeP fudEcGEvRzJL9BSsa6mfUBzct2ilpii33q1vIIVYfIQIJmYl7U6YubloT235l2C7 0v0RWn5Kux2R9B4YFKjR09Jc2273mrnGuUj7hKD0LPHfn/Jzxy1Ce4AIcaodlgwP u7vpvWiVEUcJkl3rn3enAyKCtD7zqe4k73ALq4yWjnDZRFEQ9DJEdEPEy+H8HlXY RFOtFxAr/Vdyp9STAgjve46M4g/Qc5C10qIueTyJO1h8XDPfV8HnZJNVJP3wtj0K pC5vq7ADxkQ60F9w+vNEdo85AVWhITQ/Kq7dbSq5J1LxddivzRurnp2uX+U2LEkV 9Hd2HuIM7E4uR0JZKRqPsFCJrpBuI4YPGHQB5pbq9eYAG4BdmTwTXUvd2FacI3mL beN/c4m26MKQJTiMQyTl =u7Qb -END PGP SIGNATURE- -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/15/2014 04:05 PM, Jeremy Spilman wrote: Might I propose reusable address. Say it like it is. This is the only suggestion so far that I really like. No amount of finger wagging got people to stop using the block chain for data storage, but news of the OP_RETURN change to relay rules in 0.9 got people to at least be less damaging in how they do it. Having an officially named reusable address format won't stop people from doing dumb things (e.g. vanity addresses), but at least maybe they'll stop using traditional addresses for it. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS1yafAAoJEAdzVfsmodw40ccQAI0EFAyODzx7yXvlq9idctSd xisH4xsOMlsW4lV7xReMnhQsCZ5A+qTMcCd7n7a0bveAxWg1srqBDONLXtHZfwiN Px/TfoJKPt1oIHnCoyN8G6pcuHhbUbL3lV19sH02dGnM9Ystf9F4oeqwDTITYb5i huqShMfaTdLEig76zPCLQcOT88deIWZgIxc3R4Do4aCDoyh//2LVZKfzQyEJzVms njgxcVLVRlomofPW+a+60zm/iLsrbmDjwvWSH8IB4d5ik1aO3732pWgNz3X4HSLk 1s9hVEnpN3GLIWmCcPkbrE9RZtcitghjwrt/xOMKQaqprUuFW4COc0fsfzdLIRtP bhrA/dnhVSxiUnjc7gLJBnB9+udVKdk2aTdJvSMB1PvhW9QKPjU/H4AW/yQYmism rSr9imurbi3WosTewtwdcQD47SNS4ALMh//3MeHWOBUMEHP7Tki6i8qR+/xOK+vx zMc4dnnTQsbgu9bKhrU7ia4eoe/UDvPoLck5cb2+PwYTInfdYBWn1ivbHO7S5ppP R+/Tc8h3TyLLcPQmH0tpSX+C/YwvctiGsd+iXBRfSTe7o+0wLn8NcDNGi7QI0ipQ iCHJup9K0FJqf9OuH9qYeaWht7cyuRJ5H4P/HNESGZaPSdTHDpStSmAzdtbBZOkI qrFg7irL2+CxXwI4H6vC =XEtz -END PGP SIGNATURE- -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/06/2014 10:31 PM, Thomas Voegtlin wrote: You are right. The 256-way branching follows from the fact that the tree was implemented using a key-value database operating with byte strings (leveldb). With this implementation constraint, a different branching would probably be possible but wasteful. Not really. Just use a suffix to determine the number of bits used in the final key byte. For example, the string abc would have the key 0x61626308 // abc\x08 Dropping the final bit would mean masking it off and having a different terminating value: 0x61626207 // abb\x07 That way you keep the lexical ordering of keys necessary for database iteration, and the efficient binary encoding. I see the advantage of doing that, but this looks really far-fetched.. My understanding is that it would require a complete change in the way clients and miners work. Could such a change be brought iteratively? It is an iterative change, I believe. You might be confusing this idea with Peter Todd's TXO commitment proposal using MMR trees, which is a drastic change with its own set of tradeoffs. Just to be clear, here's what I'm proposing: 1) Restructure the current UTXO index to be a Merkle tree, basically by splitting coins into individual outputs and adding interior nodes to the leveldb database. 2) Add hash commitments of this structure to the coinbase. It's still mapping txid's to unspent outputs, just as before - this has nothing to do with the script keyed wallet index. It's just now nodes can prefix optional proofs to block or transaction messages which prove by reference to the current best block's hash the spend status of the inputs of a transaction, or all the inputs of all the transactions of a block. If the more expensive proof-updatable hashing is used, then these proofs can even be composed or rebased onto a new block by applying the contents of an operational proof representing the diff between two blocks / the application of a series of transactions. This means that a node which does not have access to the UTXO set can nevertheless receive transactions or entire blocks with prefixed proofs and check the validity of the transaction with just the information available (proof + transaction contents). All that is required after the above soft-fork is a protocol version update and/or a service bit to indicate the ability to send or receive proof-prefixed messages. I'd call that an incremental update. [Aside: adding the wallet index requires storing the entire UTXO set in duplicated form, indexed this time by scriptPubKey or H(scriptPubKey), and including proofs of this structure as well. It is unlikely that any soft-fork would occur forcing consensus over the wallet index, but it could be done as a meta-chain or as an index covering just the contents of the block.] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSzKQ2AAoJEAdzVfsmodw4hyoQAJ0f6P3ijZCEw7IPd/RcrmkI Viv4j17ZyAAcbNUplvjzhr/tIIKYPg51ltvfkp8cGRHgez88QsljzvM8B5n+nbPa jaaI6eiJ3AU1bR8hWYKtlXFwMvRjyr3ofl8hhTvYptGv9x3/Tr+2FwxIRY0413m6 2h95vItsvBs8v7clqLoBEqx9uyUpsH3+J32V4oGubrNAFXh1oOHi4Ban+TOKYaQV GHZaIZ3bVAvcMd5riaWSPUPLHwJnxQ8w6SlVRy2UNUPe+9yTuy4n1GW4vk4WHvop FgZFrM3LBmh1MhlYHRdEUUtwk3mfDuGbfW5UJVMri0Nis1PsXr5VK4qQaMbd/9e6 M2uWKslY9QCnzMajnHen9OwotteAJy2I1KHVcxXb0tFqrvqZ6o/auIe0G4VdKYuI XfNF3mokX93tiSflmphDba6qgB/W+Y6UD2gG2AeFuMGhFF/Hy62pVC6Zx7PKZ3vL Kh27rKkO/0FJau2JCQm5xBiQgCnKghqOiHefY3o+l+Y9kJ8fXKWCuwJ0lJ3LxZ2u 8H6sp6Jm9Ct9L90wSn7VmmI5H3bRe8sa7sylH4BR2T6jP3/tKDYTEeNWj+F9FfO1 FxsjYrjAyv1HxYYKd/Y1svEVSsKMv3a2SR9pF36ynBABdFjvx+oEuCyCO4tspFe6 15eA1QoMKvEQe/Ww5kRC =L9WT -END PGP SIGNATURE- -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/06/2014 10:13 AM, Peter Todd wrote: On Sun, Jan 05, 2014 at 07:43:58PM +0100, Thomas Voegtlin wrote: I have written a Python-levelDB implementation of this UTXO hashtree, which is currently being tested, and will be added to Electrum servers. Along the lines of my recent post on blockchain data: Is it going to be possible to do partial prefix queries on that tree? There's really two tree structures being talked about here. Correct me if I'm wrong Thomas, but last time I looked at your code it was still implementing a 256-way PATRICIA trie, correct? This structure lends itself to indexing either scriptPubKey or H(scriptPubKey) with approximately the same performance characteristics, and in the Ultimate blockchain compression thread there is much debate about which to use. In the process of experimentation I've since moved from a 256-way PATRICIA trie to a bitwise, non-level-compressed trie structure - what I call proof-updatable trees in the BIP. These have the advantage of allowing stateless application of one proof to another, and as consequence enable mining mempool operations without access to the UTXO set, so long as proofs are initially provided in the transaction block wire format. The disadvantage is that performance is closely tied to key length, making H(scriptPubKey) the much more desirable option. I'm sure you see that as an advantage, however :) Also have you considered creating per-block indexes of all scriptPubKeys, spent or unspent, queryable via the same partial prefix method? This would be quite easy to do, separate from the UTXO structure but using the same trie format. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSy0iFAAoJEAdzVfsmodw434MQAIA/fDYT7SfMtfLEgDQKhXCn slRqFEx/HXjvgHHSYnbr9V+8LrGzNvT2ImebbV9ge8VlziAFNGIUq2EYhFs4kHWu GVm9aL8Jj/27SvM0tRwr9n2XIifKOh2sVINAjbv+UwPv/O+cULU95/b53DEF6aqI OWxioOR50TPe4t9AevAGVypNLm1DsyDdymhO9xyBN92xGTNj5QKL5hHG3kcsLIl1 7KaxO0w4UC2sdSGj9FeyH1b0zYg8FlzjJHc1CUshHwUwyYo8LRJtRypL5lrayERg Er/kIGEDovcenNBW8G79l+8VKPfB/lMTssT2pDiQL+1e1fg46CIQxHSyap2JSFTE jgleRk/+1NK/ZjOQ8dEBPZK3TE1WY3qlm/ekjG/8W5kXqcxzFBoAkeBNXuJ/8UMi mKe+DTmbp0xnvLO1p+hpugXKfrQSpcFL+ZvJHlFS1lz7O1N3WvuDCNP9El+L6ueM nFzjr1NTnX0z4vYtscI7qBKVqUrB7Z84c3O/lSYpw4Jilxl4trzV4cn7+AF7KWGM ktR9JJeIoNcJ2Zx4EpRp6OSwhtLkWZyLpPnidQ2p6ev2ytXpTpGsW/i5XS2w57UD 2IG5E0Q7Xzvd58lI/YollWQcagVOZdyzYXa+wVZoFQ6gLF47andpUmtUJOhI7gxv T/rWhPhkTMUn8TdvUcV/ =N9zM -END PGP SIGNATURE- -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin-qt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JSON-RPC is a huge security risk. It's perfectly reasonable that enabling it requires some technical mumbo-jumbo. Are there specific configuration settings that you would like to see exposed by the GUI? On 12/19/2013 11:49 PM, Chris Evans wrote: maybe make it so bitcoin.conf settings can be edited with in the app instead of external editor, and make it easier to enable rpc server mode... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSs/e3AAoJEAdzVfsmodw4mEkP/3XdrWMoly5t2ALN/YAj1QCv nviQfzcv7vQKEO1ZnLMmyo1npIMRf5UqZCD6kfWS7g4vtEHjP2KNQXdwcNkDPbdL 7BjHGHghoGfjPosTz2HV8I79g+6o+f9KCYxUz56dRVs1eNjF/QAMKbHY5M2QD7UZ 3BVxdEGD2UkIN89dUSq+Ljrt+ugPlOYFiehrLhOSqYTLtoG2von7JQR8q6HRKmzC hWSuT20aV66VL03ps5Dt/c8NVr0p0nNYRVY1vPzkcjN+1UpMBUvgn8E2d5XrchD+ uqTeWCMv2bhmFTr0qaVQwBY5Et5q6/OBJbWcF02qFq0/hy/SuZPIp/5fZEOuSpns /QJRGRyMLtCpRH4iNxlhcZeiQs8MoV02AHYiSN/9Z9yZDEBZkpbKO9Ce6S0GwmEX iXeloVaIil5dqtr8P9aWXW12jgohGy84oFGwK0Bxrk+HfT04OCSU0lqjRQVFzfdl /K0jqgRdrXZz2wQYOO6+GjQvb8CP/7WfRxivKqcKdQT9CrsW+DvgaAkTy3tBJcel aGrPynsNnDdatXK0Nyhirn/gSvxSW/Z2x2CIaPCq+jw4HrnmJu+j5AXcD8yKo8+c FsTap1/TXeFPcDP6B7eUT+nV+hR6qXYLOuHpFwbTvt/8SJ0jAgj9Yhyq8PmL4rok mdrqhFHk3i/RMYqGK59Q =WCub -END PGP SIGNATURE- -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jeremy, Let's give a preview of the application-oriented BIPs I mentioned: Stateless validation and mining involves prefixing transaction and block messages with proofs of their UTxO state changes. These are the operational proofs I describe in the draft, and they work on prefix trees whose root hashes committed to the coinbase in a soft-fork upgrade of the validation rules. Ultimate blockchain compression involves consensus over an address index, which can be queried over the p2p network by lightweight nodes. The structure of the index is an authenticated prefix tree, and the results of such a query is an an inclusion proof. Document time-stamping and this new method of merged mining use the same structure: a prefix tree whose root hash value is committed to a pruneable output of the coinbase transaction. Document timestamp proofs and merged mining proof-of-works are inclusion proofs over this tree. I hope that shows how the BIP directly affects interoperability of the bitcoin protocol and clients which use these applications. I released this BIP first to get some feedback on the structure itself, which will be used by all of the application-specific BIPs which follow. Stepping back and speaking generically, the purpose of a BIP as I see it is to standardize details which affect interoperability between clients. In fact, at a cursory glance only about half of the BIPs deal with protocol issues directly - the rest deal with local / user-interface issues like key derivation or JSON-RPC APIs. Even if none of the applications involved protocol changes, I still think BIPs like this would be of value in that they serve to standardize things which are or will seek to become commonly used and widely implemented. Cheers, Mark On 12/19/2013 10:48 PM, Jeremy Spilman wrote: Wow there's a lot here to think about. I'm pretty sure I haven't grasped the full implications yet. I see it proposes to also introduce additional BIPs describing the use of the data stucture for stateless validation mining, the UBC address index for SPV+ operating modes, document timestamping and merged mining. Can the BIP stand alone as a BIP without some specific changes to the protocol or end-user accessible features defined within it? It seems like an extremely useful data stucture, but as I understand it the purpose of BIPS is defining interoperability points, not implementation details? Unless the tree itself is becoming part of the protocol, seems like its spec, test vectors, and reference implementation can live elsewhere, but I would love to read about BIPS which use this tree to accomplish some amazing scalability or security benefits. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJStChCAAoJEAdzVfsmodw42DcQAIlgkukh5K/XYloIiT5pgaHS xCZXtOvxpNUep8x35rvEO1ePjvPvUkbUE2jRw2se1rSMkhzw3PpHHtXV/gIOGqUe WVKeeIM5pZX56sEcEdUQ1pTwB2rmtSNeyCuHl8fLatk8eLhcAHcpv/7esLuAjWCr EE840s8+q3ltuzKi3nqxK84bwIohgSMKhncfonNp5lMAtug8Itqopq3DPDoxwiK/ qUwSz5UCEMH6oNHnywzhKGUhBErqo4q8IgAKcZYBZZ9n4BRjf4ngoCw9n5wCef8v tyTvwrg0nSQTQa67cg7RCsY7SisrI9gaMvCYTSvEMKdw9X0aqAX1p0yZpTbV+dIr Q2ZT6gJmg2sD22zKY1/58oq+PiNO+nRS81OG2znZofsIfhOVW0bIZAQ8+zZtFW40 vXxMuHCNieCK8e7f9A6LLv/Zz7rmNxdQ6cHBEL1nIs1Y4d1FpHJVI2LHi54QmVXf C5PKF/e7K2eD3LZMNxS818rZaiJJ7qmpjS3rkG2owHyJHEhBJIlkYXfI1YCraT+b R5AzAh2Oz0Nyb5ChP2VSaecJNjGvRMo7Z6HCytmgAGOEcDDZkxSv0kkprbvchqXx XziFgA4iSajBKYWPiPLGMADfMPT6zd4fhDjyaN8+LPO3d3ZK1VwmQDLRQ3DxfeIP RgchHR/pS77XI7hCFwtN =ao17 -END PGP SIGNATURE- -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Sorry Peter, this was meant for the whole list:) On 12/20/2013 05:17 AM, Peter Todd wrote: I've thought about this for awhile and come to the conclusion that UTXO commitments are a really bad idea. I myself wanted to see them implemented about a year ago for fidelity bonded banks, but I've changed my mind and I hope you do too. They force miners and every full node with SPV clients to store the entire UTXO set in perpetuity. This is incorrect. If the slower proof-updatable hashes are used, then mining only requires what I've called operational proofs to be attached to received transactions and blocks. Access to the UTXO set is required to make new transactions, at least for the outputs of the transaction, but I do not believe this is as significant a problem as you do. It is a service that can be outsourced for a minimal fee - include an explicit output of the necessary amount to a scriptPubKey specified by the archival node, and they will make sure the proper proofs are attached. This is bad by itself, but then they make it even worse by making Bitcoin really useful and convenient to use as a decentralized database; UTXO commitments make it easy and convenient to implement systems like Namecoin on top of Bitcoin, yet we don't have the UTXO expiration that might make such uses reasonable. Right now the UTXO set is reasonable small - ~300MB - but that can and will change if we make it an attractive way to store data. UTXO commitments do exactly that. You might have to explain this to me, but it is not clear to me how the validation index could be twisted into providing a Namecoin-like system. Or the address index either, which I presume is what you are referring to. Namecoin works by assigning domains to outputs, and then tracking ownership and configuration of that domain through chains of outputs. But the UTXO set doesn't contain connecting information. At best all it would be is a glorified, and expensive time-stamper, unattractive because there are already better solutions. You're also *not* giving users what they actually want: the transactions associated with their wallets. Even though Electrum could easily work via a pure UTXO database they implemented transaction lookup instead; Electrum servers cough up every transaction associated with a user's wallet. If you're going to do that, it's just as easy to do per-block lookup trees which don't force the UTXO set to be stored. At the cost of having the supposedly lightweight client query for each of its coins on every single block, to construct a negative proof-of-spend. There's also a more subtle issue: the security model of UTXO commitments sucks. It encourages wallets to essentially trust single confirmations because it's unlikely that nodes will want to store the multiple copies of the UTXO set required to provide proof of multiple confirmations. Basically the issue is when you start your wallet you get a proof of UTXO set for the most recent block; that's just one confirmation. To get more confirmations you have to wait for subsequent blocks, checking the set on each block. Per block indexes on the other hand naturally lead wallets to count confirmations properly. I don't think this is true, or at least you are not considering available optimizations. You certainly don't need to store multiple copies of the UTXO set. I'm a little confused as to the exact situation you are describing. When a key is loaded into a wallet, or a wallet comes online after a significant absence, it looks for coins in the current UTXO set. If any coins are found, their attached transaction record has a block height field, so the confirmation count can be derived from that. As blocks go by that count is naturally increased. I'm not sure how this is different from the current situation. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJStI9aAAoJEAdzVfsmodw4IooP/1uK9cvP1vxXyQRbAHf9oFXw AmZ8p1+t8f6MHUpjkv/Xn0poFNU8qSnNz65drQdq8ErcJnqe4V3Wt6G32/uCxvZs 6AX6bRYQIfhHY0DBPgfacO5/ALdlnS4NdjWFCA5hHDgLd30BpbU1WK1ze985TXrd +ucQkzcMYEDW2lb+sFvfhpi9ZPFd34ZrNzH//oS794eYKWAmj7jXqdgxk5AKat61 Xileq5beE4xom3pChXc3PtIJKsoil5SjE20/FW52wcCdyaEFG0kwl937pEGjQnlP mylK/ilfZ6cvRC8MmVnl/6AC4V2hjB4Ncej03jG3JI2FdaJEOHuHg0uh8/Zl1I4A YVIKyrHQhQb/VGsfXtW3zokHzDeEtJwlx+PPFaLc9QurFirNjSnenhbw4Vpbg3Xt dH1Qd9xWcT85a19Oz8Q4rt3z7UmX9J/geZrUHCuPtr47yXU0e1Cc6ZP9zDYNtfKU q6MjNZiaLJ/Wp0n4IeQ/4/wqy0rM/psP9i5d6IdP96tayVM9aKj5Lh9lU/Od5wGO 2PPB4kvhJfMbx3o+S7UK5vra7ysZzULpoVGDpUR3xRM72l//vlNhSLK5nILVO3r8 sIC5+3WoZLUKvuNo45/BDxXHZajrWLCU84WrwHVm1u7SHfBQcoES/rhcx2zlgyx0 /Iwxsgb7Fznl+eM2bEpZ =TtaV -END PGP SIGNATURE- -- Rapidly troubleshoot problems before they affect your business. Most IT organizations
Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/20/2013 11:48 AM, Gregory Maxwell wrote: A couple very early comments— I shared some of these with you on IRC but I thought I'd post them to make them more likely to not get lost. I got the inputs from IRC, but thank you for posting to the list so that others can see and review. Whats a VARCHAR() A zero terminated string? A length prefixed string? How is the length encoded? Hopefully not in a way that has redundancy, since things that don't survive a serialization round trip is a major trap. A length-prefixed string, using the shortest representation VARINT for the length. Same as how scripts are serialized in transactions. Is the 'middle' the best place for the extradata? Have you contemplated the possibility that some applications might use midstate compression? Yes I considered midstate compression which is why the branch hashes come last, but extra was an oversight. In every application I've considered it's either not used (and therefore a single byte), or updated whenever the node or its children updates. Honestly I don't expect midestate compression to offer much since in the nodes that are updated frequently it is unlikely that there will be enough static data at the front to fill even a 512 bit block of the smaller hash function. But it doesn't hurt to prepare just in case. I'll move it to the end. On that general subject, since the structure here pretty much always guarantees two compression function invocations. SHA512/256 might actually be faster in this application. Yes, this is a great suggestion. Moving to SHA-512/256 will let most inner nodes fit inside a single block, so long as the extra field is not too long. Also apparently SHA-512 is faster on 64-bit CPUs, which is a nice advantage. I didn't know that. I'm concerned about speed but I did not go with a faster hash function because users are more likely to have hardware acceleration for the SHA-2 family. Re: using sha256 instead of sha256^2, we need to think carefully about the implications of Merkle-Damgard generic length extension attacks. It would be unfortunately to introduce them here, even though they're currently mostly theoretical for sha256. The serialization format encodes lengths in such a way that you cannot extend the data structure merely by appending bits. You would have to change the prior, already hashed bits as well. I believe this makes it immune to length extension attacks. WRT hash function performance, hash functions are so ludicrously fast (and will be more so as processors get SHA2 instructions) that the performance of the raw compression function would hardly ever be a performance consideration unless you're using a slow interpreted language (... and that sounds like a personal problem to me). So I don't think CPU performance should be a major consideration in this BIP. Well.. the UTXO tree is big. Let's assume 5,000 transactions per block, with an average of 3 inputs/outputs per transaction. This is close to the worst-case scenario with the current block size. That's 15,000 insert, update, or delete operations. The number of hashes required when level-compression is used is log2 the number of items in the tree, which for bitcoin is currently about 2.5 million transactions. So that's about ~21 hashes per input/ouput, or 315,000 hash operations. A CPU is able to do about 100,000 hashes per second per core, that'll probably take about a second on a modern 4- or 8-core machine. For updatable proofs, the number of hash operations is equal to the number of bits in the key, which for the validation index is always 256. That means 3.84 million hashes, or about 10 seconds on a 4-core machine. The numbers for the wallet index are worse, as it scales with the number of outputs, which is necessarily larger, and the keys are longer. This is not an insignificant cost in the near term, although it is the type of operation that could be easily offloaded to a GPU or FPGA. What I do think should be a consideration is the cost of validating the structure under a zero-knowledge proof. An example application is a blind proof for a SIN or a proof of how much coin you control... or even a proof that a block was a correctly validated one, and in these cases additional compression function calls are indeed pretty expensive. But they're not the only cost, any conditional logic in the hash tree evaluation is expensive, and particular, I think that any place where data from children will be combined with a variable offset (especially if its not word aligned) would potentially be rather expensive. This is something I know less about, and I welcome constructive input. There is *no* reason that the hash serialization needs to have fancy space-saving features. You could even make the SIG_HASH node serialization into fixed-size, word-aligned data structures. But this is absolutely not my field, and I may need some hand-holding. Do
[Bitcoin-development] BIP proposal: Authenticated prefix trees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello fellow bitcoin developers. Included below is the first draft of a BIP for a new Merkle-compressed data structure. The need for this data structure arose out of the misnamed Ultimate blockchain compression project, but it has since been recognized to have many other applications. In addition to this BIP I am preparing three additional BIPs describing the use of this data structure in stateless validation mining, the UBC address index for SPV+ operating modes, document timestamping and merged mining. A Python implementation of this data structure is available here: https://github.com/monetizeio/python-bitcoin A C++ implementation is being worked on. As per the BIP-1 procedure, I am submitting this rough draft to the community for discussion. I welcome all comments and criticisms of both form and content. - -Mark ==Abstract== This BIP describes a [http://en.wikipedia.org/wiki/Hash_tree Merkle hash tree] variant of the [http://en.wikipedia.org/wiki/Trie prefix-tree data structure], ideally suited for encoding key-value indices which support memory-efficient proofs. ==Motivation== There are a number of applications which would benefit from having a data structure with the following properties: * '''Arbitrary mapping of keys to values.''' A ''key'' can be any bytestring, and its ''value'' any other bytestring. * '''Duplicate keys disallowed.''' Every key has one, and only one value associated with it. Some applications demand assurance that no key value is reused, and that this constraint can be checked without requiring access to the entire data structure. * '''Efficient look-up by key.''' The data structure should support sub-linear lookup operations with respect to the number of keys in the mapping. Logarithmic time or linear with respect to the length of the key should be achievable and would be sufficient for realistic applications. * '''Merkle compression of mapping structure.''' It should be possible to produce a reduced description of the tree consisting of a single root hash value which is deterministically calculated from the mapping structure. * '''Efficient proofs of inclusion.''' It should be possible to extract a proof of key/value mapping which is limited in size and verification time by the length of the key in the worst case. * '''Computation of updates using local information.''' Given a set of inclusion proofs, it should be possible to calculate adjustments to the local mapping structure (update or deletion of included mappings, or insertion between two included mappings which are adjacent in the global structure). Such applications include committed validation indices which enable stateless mining nodes, committed wallet indices which enable trust-less querying of the unspent transaction output set by codescriptPubKey/code, efficient document time-stamping, and secure efficient merged mining. This BIP describes an authenticated prefix tree which has the above properties, but leaves the myriad applications to be formalized in future BIPs. ==Data structure== This BIP defines a binary prefix tree. Such a structure provides a mapping of bitstrings (the ''keys'') to bytestrings (the ''values''). It is an acyclic binary tree which implicitly encodes keys within the traversal path -- a left branch is a 0, and a right branch is a 1. Each node is reachable by only one unique path, and reading off the branches taken (0 for each left, 1 for each right) as one follows the path from root to target yields the node's key. The particular binary prefix tree defined by this BIP is a hybrid PATRICIA / de la Brandais tree structure. [http://en.wikipedia.org/wiki/Radix_tree PATRICIA trees] compress a long sequence of non-branching nodes into a single interior node with a per-branch ''skip prefix''. This achieves significant savings in storage space, root hash calculation, and traversal time. A de la Brandais trie achieves compression by only storing branches actually taken in a node. The space savings are minimal for a binary tree, but place the serialized size of a non-branching interior node under the SHA-256 block size, thereby reducing the number of hash operations required to perform updates and validate proofs. This BIP describes the authenticated prefix tree and its many variations in terms of its serialized representation. Additional BIPs describe the application of authenticated prefix trees to such applications as committed indices, document time-stamping, and merged mining. ==Serialization format== As a hierarchical structure, the serialization of an entire tree is the serialization of its root node. A serialized node is the concatenation of five structures: node := flags || VARCHAR(extra) || value || left || right The codeflags/code is a single byte field whose composite values determine the bytes that follow. flags = (left_flags 0) | (right_flags 2) | (has_value4) |
Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Transactions != blocks. There is no need for a merge block. You are free to trade transactions off-line, so long as you are certain the other parties are not secretly double-spending coins they send you on the block chain. When connection to the bitcoin network is re-established, you simply transmit the transactions and in the regular course of things they make their way into one of the next blocks. Any transactions which derive from the double-spent one are invalid. But that's your problem, not the miners - chase after Bob and get him to give you the money he owes. On 12/17/2013 02:41 PM, Troy Benjegerdes wrote: I want to get some feedback.. I've used distributed version control systems for a long time, and the most useful feature is to be able to merge two different forks. So what's the equivalent of this for Bitcoin or other crypto-currencies? Let's suppose that me and my friends get 'islanded' from the rest of the internet for a week, but we still want to trade bitcoin. It would work if there are local miners, until we reconnect. Suppose we have the main chain (Alice), while bob is on a boat, trading with some friends, but has no network connectivity. When bob reconnects with Alice, a 'Merge' transaction happens where a miner looks at bob's forked blockchain, sees no double-spends, and includes BOTH chains. Now suppose someone on bob's boat has a buggy client, or sent a transaction before disconnect that results in a double-spend on the merge. So we have a merge conflict, which generally requires human interaction, so bob and his friends broadcast a MERGE request with a transaction fee sufficient to cover reconciling the double-spends, AND incentivize a miner to do some extra work to merge. Thoughts everyone? -- Troy -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSsNTOAAoJEAdzVfsmodw4rBUP/jBFvPks4h0k1GQEPQPYvqNa 3OhuSlC9EfHmjXxftj6j0lH6JO60BFIoA3P76oFycQRqzNSw3YoldQ1MttpNAAZg ftiJJjYcuVmDYYWxfWPZN7ZsHrrhGkMn+i0PB1vXU3PB3sStb18vhbIoTZmwH7Rk vaUaX8EKFh6R8Y+6nqFMKu8eALaFQPJFP1aNo31ixsFFJrl02zQeIZiTbrOensEj 6AhXm2oYRqB1aolMmy/m5zcA3IicayJ6seoCQcRhPty6G2l+/4opgATdEBjzgczW Yhw20YkayyvPa+Fsqwad5AzgGYbm7OA0U6mO/pfeNhglNSt/TGfuSPe1oM9hWt9/ 8gP3PG4O4Fxi+gOAlNABgmoRKvQK8T3TX+eoayxPJiLxi+5l3+1CK0FK1+mKPThr heFrc5e9QlUIgATOpLYSs/elgAFM6N2Sez+RNiOg201M10VVKqXzBgZRQ+IYRRk6 jbaBKxsQ/ql5+2vwaUkplg/6Y6rfvRItQ+8xwXEvxazPAAh3Mp0fPbqas+F0e1Ie SwVTq517iV7eu+kMxOJEqaCky8ihbaUmshjeEccXdbodpygxCR2dZ0xAkvwXYtnK +ZjLQ7o8ySZs89Jvdx8H2fsu6m3hS/7Mm+zJVGV/hLHLoL7IrYPzTHcOHv8eT106 IYM30Hv+vDrt+f8ZRZ80 =09Pt -END PGP SIGNATURE- -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Merge avoidance and P2P connection encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/13/2013 09:26 AM, Mike Hearn wrote: I'm thinking about a use case I hope will become common next year - pastebin style hosting sites for payment requests. Like, if I as a regular end user wish to use the payment protocol, I could just upload a (possibly signed) payment request to: payr.com/a62gahZ http://payr.com/a62gahZ or whatever, and then payr.com http://payr.com can take care of incrementing the iteration count on each download of my file. That's why it's useful for it to be unsigned. Or alternatively, the user-signed payment request without iteration count is enclosed within a payr.com-signed envelope that contains the iteration count. Having fields completely unsigned by anybody leaves me a little nervous. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSq12pAAoJEAdzVfsmodw4MC4QAI9cjmQXz8AVawwr1htFc6b+ DVAAs1Y4hzbChPeeJCmy13m8a/BuXqc6G0WEWGSzIIa1or3IXCd01JQ2a5waD0IC uOjlIMD0tTT7yxwxRjxPc2df82s82traGJC2caOMYjrN4T5VPtj7erB2poNyvOF+ p0lmj+duxUZ8IoyDaih5mgNKzIVujfX7o3lPoOMDdIi6Q1LF9SZ9XbUAxHCpCLfw ieqVIm8zqtH0NprZ7/JLbqstl1iq5jCPKbORc+9qQWESZH1hFAeS29/ptjnRR8y6 HqrpDP236vSlrLDW4dLcW9UiQP42tSTwrLCgud08VqeKapSlMX8fjukLyNlTD7h5 GtPHEo1/j+LmpMfwsXA2OotUIVQBeFfEoi7PwV/Jd+SRVqC6zCTPky1lfg0P7JXA 7qD9m3u/Ey0+nk888zzff8N7AfBe7GaqFuUByXIyHh6dkcr0xUHBU4afiadFpNhg 8dTvmP4yqY0g05uz/Cq/ZqrSb5y/yPqsysuruAjWG2GT0M8rFM9oYepVHpUJr01K QOHY6qSoqyX/KDCkZgpTMZFDq9gvyPyMFuCQbdecNcCeMPV5kiwPyqqH4rHliJ8I gsXW44re5GfdL90nCOTboYFf2CFEn+66zyJ5vBskKSyDRDcU3t5YyCtrDzXdtJMu MjVeMFRluY700zLBajw0 =+MjP -END PGP SIGNATURE- -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/15/13 4:41 PM, Drak wrote: For years, people had a problem with email address, instead using email number but they got there eventually. Most people nowadays use email address So payment address or bitcoin address make better sense here when qualified as a foo address and not just an address You could also call it payment id, but I dont think invoice id since no-one pays to an invoice id that's just a reference for a payment, not the destination. People are very familiar with Paypal these days, and are familiar with paypal address or their paypal id so again I think valid contenders are bitcoin address or bitcoin id. No, no no. That's precisely the problem! Bitcoin pubkey-hashes are not like email address, physical address, or paypal address. These latter things are fixed pieces of information that stay constant over time. Bitcoin keys, on the other hand, must be one-use-only. We want to break this association, not strengthen it. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShsDqAAoJEAdzVfsmodw4e+UQAJBk3N7y/1ph8k6K/tPn2RB4 t0TiI46j0WuUghnCiDSOhQiL0EnUWUX8tCa6jH/3ASafBLKVey2LA7LeYoFZXpqJ QEk5S7+eroA6uzzhViDTcoJJ7yH+ivd6dioVApirfnHVYiq6TZuTULhN/5zM6g1J WehI9Rg2C7wj+I71yPJDeGAdtyOeX0iKQy3hN+q7+RIgeZC1viwsq81u6dzVjIZM aPIk6S2VYHSUKhd7wSg+AprCV7jwftKhxDrW6R6KmOGYIG+JdqVnaErc5Wm7ujXk Jnoh6UsQrcx9ck8I4sRTcbb5jGme1taN8RDcKifYqzTVQAr/ziVRqYY57fNAJMm2 lJZ0ctVD1+UB96DzQB4wCuWRoFF5+I9kD2hoEAXA4O9tqcou48lTQ25DAnkcusd+ dD0SfcRsgda8XqnWffGPYaW0E0dQuvu6elO+rzSh4DSCMkroKIvUwdak8Ah5M2lC DyE/efwO9csImbTc1QukedkPskbOqPOo36sH5GdmObKKFCpORIzIO0aDQE1NM2Ib rJurpU0iJ8eA+QT9lpyWG+jjahYpqyVhPcpfVsIewKhI0izBa352IYPbpCv/pdfM oMO/tBfIwUW3jjav3zyFE47hAwistqfV4xds93K9rqpOmLtDIhSuzfmbuXwmciCM d7/3rYQ6FxtyNkEUa27L =5MWw -END PGP SIGNATURE- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/15/13 5:19 PM, Drak wrote: Maybe, but again from the user's perspective they pay someone, and they receive money - just like you do with paypal using an email address. The technical bits in the middle dont matter to the user and trying to crap stuff in to be technically correct is just confusing to them. The UI needs to be about the user and fit with his experience of the world. It's not about being technically correct. It is about protecting the user from grave breaches of privacy. It is for their own benefit that they should not be reusing addresses, and if they understood why they wouldn't. Unfortunately calling it a bitcoin address and including an address book in the reference client has had the effect of making people think that these objects are like paypal address, or email addresses, but they are not and they should not be treated the same. Mark -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShsr4AAoJEAdzVfsmodw46nIP/AlDcJh2ET9qYT2ZvddciTk3 dtQDArCkwCW3kYbVjIFT8YtNFftEfkq/qBNnILipLJNN49QduAIlt3aetEE6eJBZ oqYOV2R7GW2yhLDv/GrT6GnB1C9nQ4OuKC6RNpXX4bMpZSrbP9yfyyLqecF1tMBV i8De4XLz1uUvZOo/jwHNeYy/BAZktwdk5hWlgG2yKebRbqVX1Xv70Qb1cPpBgCWm uRDL3bqdZuh6i8NNDQpBqMJ/MP4ZWpIgdHkfO6a3QCq3H0JXyug4t5lkNngCrAI3 KGlSOuYK4Fsfw97xQUBFIaSYFOU+yPDRQK4UGcTqWPLt5YHzUxBFNkOXSnVReudq Em/wlbDkPqm7R6by54fVkG85snJrwmTbD7uxGz2fe1LyzB3HhdOTZyZ1KiyDHqGA zDUFxmH0XNhvVcJvcSFlc38A54oOHTJmfJ3rxJU/q0/5N3ZIBdF8fQ4xIvXXDeeA dO+tul5q78tbO6xyTrbsHO8JRYt4Un8Hjc5mkdqp9gzA8beJFm5+jMZlGBfdl5jR lS9sW7QBxr6m+n2PJ97i+1CgoxTfzOh3jyj93G6Hqx3reTfCu5fSWUhwRnFzJXav qqPBP4Cl+6ocK7+4V1lyfAzMqpYx+GCJ1JZhD0hhwrGglgVPfE0bz7BUGea8U3+T 0pCTlkhWzEbzDp7NtFdY =ShxL -END PGP SIGNATURE- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For this reason I'm in favor of skipping mBTC and moving straight to uBTC. Having eight, or even five decimal places is not intuitive to the average user. Two decimal places is becoming standard for new national currencies, and we wouldn't be too far from human scale everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't think very many people on this list would consider bitcoin overvalued in the long term perspective. Better to go through a confusing renumbering only once. Mark On 11/14/13 12:01 PM, Alan Reiner wrote: ... I'm also of the opinion that it's freakin' hard to change the base unit in such an established system. There is no easy way to do this that doesn't cause more heartache than it's worth... -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShT2JAAoJEAdzVfsmodw4DXAQAIJTNbpwBGTXuFyaxXQULf20 hMs7OlQZSOZOdsmSiPv2augxzbpa2DhhZjiosrScSBCjxMeYd4S6WgTt/b8moAYR HD8pm88JyCKDOd7bOmzTkgDOTBBFfH+islmOY9VTdeKGHeOHH6yyLMKwnUpa+S89 4YtdzlIXAtfT37dpR5E4cHPmAYCbrRsNOB6j5ohVl2VqRou2vkwoJr/YvaW54M8i ucIZyai2qjNWyJLcZC9QWi9Yw/W/n9QYE2mHyL0qWNaIrZVn6WGty8KpYq+i7aeU 4N4UdtLT7FAhWYec9nmEec868WsUsd+H3/WSWViMinUKO4YA3cyxWDL7MTmTRsci g0R4WGYCzMM3cEWz5ycf5KEBPH/nDlbqFmEartTffqKXgrK5Ohhw+28Iqw5KcDX8 SVx34lw2yHWmTeIMY8d3qYKqBdcsvixDUD3xvq+ZqEIa+bZw12s4LIzqmir84TB8 fB4bdq5GddXX0PK4pboXL+Nib0OVK72YgYnVs/ejlBmeiG8Ixoz4/ygR5MHm8jcw tSiwH0xohOJWg3lJj0vZorubXoECcOqwPzsZkwnT9irbrvOuk2jCPvrkEC8U9fgA XHgirStS49/lI/iUWrRchoTt5iuwG18G4+E81V/DMsrSkYlipuf2DlEXiapn3hWz ccP053+6o5Rgpc7J1aa0 =QW1i -END PGP SIGNATURE- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/13 2:00 PM, Alan Reiner wrote: Just keep in mind it will be a little awkward that 54.3 uBTC is the smallest unit that can be transferred [easily] and the standard fees are 500 uBTC.It's not a deal breaker, it's just something that needs to be taken into consideration when it comes to user perception (which is one of the reasons we would make such a change in the first place). Holy crap these fees are huge! I thought Bitcoin didn't have fees! Well.. they are huge. 20 cents suggested fee for a irrevocable transaction? -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShU0EAAoJEAdzVfsmodw4TlAP/33KPX3ypMZ0PyHQVg3OCX21 hUXhTQBBO3JjO7x4HoNqdV0fApfCldq4cl/pNENG74inVuYNH+dUwUBIF6q6Qzfs RU45++yytPob28ZojgrQgZq7/lAvi9qvsg5tLMyLt72uf3Kz1whmiRAHI5qaJ/xW 5w9LfOxXHFVkTQsUPzIjbD2kYAqUNILMzndKSv4YwRruYNm60gxCh2mQvgNr3s1Z oGdLsPhx6AA1+Y6tgvnZVm71dwYUyg7OAafzGtpGEz953/cQwbgTqsZ3CrOiPk67 OJ9XxRPREOyKTDYo1WcM1GlQAq9LOHkMcU5OWS7TX2DzZAbLc7TqmqSMuAHdn6d5 eh+AgRWN1ppgVzHaCfgGSfP4NdXHRuMbDvSSoeiP+JLZ1ateT1aesklOaPRFfieW NUJ61XAFWYCuVEK/ctUhSKMd19Rao23yuly+PtrMHvCw6Zn/LrpA4z2nD4vTFTXi WeFyYwjIDjKBeuQMfWg5I2uMpo+9vC/DA3cwPticV7+LD7wsATHVNWVzuHlmjgTX CPO4tVkqBPk7NsqDreOaVhvgnbAUHknyeDqguYS2LppDGu4P4XiOIHpS3reRyHuc /NbXAvDkR23JGQFeHgdR/E983TdsqUiH3US43Cy3ikEcWm79eNG0cPGuHHVZBjPh AACKjmPS+JR7rBAKFSGl =f9P7 -END PGP SIGNATURE- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/13 3:01 PM, Luke-Jr wrote: I think we all know the problems with the term address. People naturally compare it to postal addresses, email addresses, etc, which operate fundamentally different. I suggest that we switch to using invoice id to refer to what is now known as addresses, as that seems to get the more natural understanding to people. On the other hand, with the advent of the payment protocol, perhaps address/invoice id use will die out soon? Thoughts? key id (thanks sipa). I know it's a more technical term, but that is rather the point. It was a fundamental error to call hashed-pubkeys addresses as people either associate this with account or physical addresses, which also rarely change. Security and privacy guarantees of the system are defeated when key pairs are reused. We should ideally adopt terminology that lead people to associations of ephemeral, temporary use. key id is at least neutral in this regard. Can anyone think of something better? Mark -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShVieAAoJEAdzVfsmodw4TlkP/i2cZm9NolReIsv6WBNQUGZ6 0VJveOcsOmEXj3ixSyzPRitFl52EOfU+LZaM3liwFPczuIOXZUXOLAJqakxGGsFa cWwvZjrBk13aTR+4dXZ6OWcCNmTfm6+st2+v1MpQcXlHD8J1WtrdrzKr3fNSntir yHbNmF6hPfgLr64m52BhUVrxBg9eiIFDI6VCzmUgk+paNmIxs9dgx7POnz1/hQb3 2FGfNt2J81t4F78mpzjtKx+vHRyHpIKJ2+3mjzcQ7IBkhBgPYnp69TwBSGXbg7l9 6yV0P7DGjWepO5+s96GCjbScYpmZO0gx0ZTn/eamfxh20XuX2fZBEVNd1KnhX4Xq D4UwylGNa5FteRgURtVN5Xdb82jB2qhhr/IkGSgKds24zhHzgvBgvLJBgwtQHwil M/y2DMC70WVEXf0Fz96L1kNYUA6062/ZNlwITRWxkUUJprF+xyN3R+BVWMggBMnR Vjht74MZMkJyYlPQr8BRbYdhgMwv6dh0v5T4M6ck6MjKYj/GLsnEfHyY2d/BNg8c 2nkcBC8Dtv9KoFOk6STS1n7R4ooqepmdsRNPBZUzKvv/NN1B1A8jeluLiN9hSzl1 ubDF/34LJTji8bP9jfDBEND94xdaKjTl+2ISweRttBOOVqCtQlzCQ4udiT7vAntb AYYMBYmYO/A926T+K6Lp =kFj9 -END PGP SIGNATURE- -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Committing to extra block data/a better merge-mine standard
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/4/13 10:16 AM, Peter Todd wrote: Again, the right way to do this is define the standard to use the last txout so that midstate compression can be applied in the future. We can re-use this for merge-mining and other commitments easily by defining a simple standard based on defined path directions. Essentially for each thing you might want to commit, perhaps a merge-mined coin, a p2pool share, a UTXO commitment, whatever, generate a random 128-bit UUID. Now interpret the bits of that UUID as an allowed path: 0 = left, 1 = right, from the top of the tree. When you build the tree, make sure everything that is going to be committed to uses it's allowed path; the tree will look a bit jagged. If everyone picks their per-purpose UUIDs randomly the paths won't collide for very many levels on average, and path lengths will remain short. Validating that some given data was committed properly is simple and easy: just check the path, and check that the directions from the top of the tree followed the spec. You mean... an authenticated prefix tree? Composable/commutative properties are not needed as far as I can see, so you could make the path validation, traversal, and proof size smaller by using level compression. I had previously proposed to this list a hash256-to-UUID mechanism explicitly for this purpose. Recap: use 122 of the low 128 bits of the aux-chain's genesis block to form a version=4 (random) or version=6 (previously unused) UUID. However since making that proposal I am now leaning towards simply using the hash of the genesis block directly to identify aux chains since level compression will allow longer keys with the same path length. I'm in the middle of writing BIPs to this end, among my many other tasks. But basically it's the same as you describe (OP_RETURN 32-byte auth tree root for the last output), except keys don't necessarily have to be UUIDs. If there is general interest, I can make finishing this a higher priority. Mark -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSd/FmAAoJEAdzVfsmodw4pA0QALtgKLKsMNFocUanKGNp5T1F 918IjFt/HASRMs4GXiPpIeTB+o5Id6aCsg1ikKRuL9xD+WKoSyo83JP5UmcxGjFA WTPi/0/ArYRh8L7ECvWoBSanNrun3z72p3KMI1Aa8qcJCgWbPx88AYeJv0Ki4JOo 1Pxc883772bOJnazrh4f/C4gcrqrlgs29PwI1rc3yCD9dmJhVmkz+O0/yfq+U8Gg FXrpqR14mUM36wGX2HjqEual7Ry/7TEz5Ne4o8uncaVHtGgaYVw45a5Hk6rdo1rH F3EV9nIpsLhGyqbKPqSxSju2h3eYQxQXKUP14mJS+ja/mKFXVc3PXDV+IHtXAplk 4gW8vtTWtVIDJAGTTh5RkJu5yAr57vq9lUMTNGGk6v1C3xOPP2C097sHRLaD4kD+ olsw5M9NW/Qpn1X3SCN3K85f7dvV3+fucmWL8mPM9KMLfc38fgs7I5SQgurMngsS 2D5jSwcZVjI/4n6ocgK3Y66yKC5xuzOOi2ZV+pPM38TjUeCF8fbjRnoIWyaBPDWy mKA0bJiw5NMzi+IsNK5YDS5Gqb3qxS6tYLCp1+hesW3pBj35Zv/LdSh5DyecRETW J0ye56lw/DfRAfNf+YERvrznqC2WVDZcQaElACq8R/nPJ2HD53p+SfxMSbljVO+I SDsDOSvAzfQjQBLGdkx7 =5fPS -END PGP SIGNATURE- -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Committing to extra block data/a better merge-mine standard
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/4/13 11:38 AM, Mike Hearn wrote: The Merkle branch doesn't get stored indefinitely though, whereas the coinbase hash does. The data stored in the coinbase [output] can always just be the 256-bit root hash truncated to less. I doubt the additional bytes make much difference really, so the additional complexity may not be worth it. But it wouldn't be an issue to do. The bits make a difference if you are merged mining. You can use the birthday attack to construct two data trees whose hash match the (truncated) value, each containing separate aux block headers. This allows you to double-count the bitcoin PoW for more than one aux block on the same chain, potentially facilitating aux chain attacks. If you want 128 bits of security for merged mined aux chains, you need 256 bits of hash in the coinbase. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSd/shAAoJEAdzVfsmodw48a0P/RaCOctBDvhU0THnsUw6nRBm A8oH3Kpio4ZltU4oIT0tznZbUOG2j2xVrmATqXDYOZQ6FuGihjmkKJ9jHgl57pb5 0qDdCBiEuWtLIh2+Awrb3Y0s8czyCQP9/1CJyzdEFmI8rSwCaqJMa6B2Ny6Xz6+8 eiK45YdXCPgdTAb56FKOi9WzOe0g1aOO5KiUOci22xRkXvh4qPYrt2F0LIgjZTdC koyXU6dcKON9H8Cecu+ag7jJ5A9ZDj7oIq5rflEyolh2V4ie0tGQ50rFGg/ii6iQ Tz9AWwigsHEkuinBTuN5041Xb8nAgHLvA60RQ41lWUHJxfAvDE+wN6NqgHmMVaRo NHqlZcCuEl1jn7HW81XQTpgarrXHk1G7b2vK10pB/lUxUNIstZvCSjcp8QdtmC9v tIhC2czSnsQaE6kIBuHxDNZxOlZ8DxBYCAgXSkycwznwzGhFPP0xB1lV9HfaP5+i aikmx5SQmqBXQQKsxmIacoykrfu5x+O2TB/bq8JhJ1ak2jG9LVFyQqjorABVAgA7 pLEN6EomWht5qstaLVfHYpNsLMf6WA7UzRG08HKItUeDPtG7bDx8vBx5TvIUjT44 A0i09bOt8ZIgp+lJ8lFLWiPLChViAoy7fqKy2vrdsZerOF3l4LUQeQO/xnfZc+dG AEG+7iCBOMxJSVoJ5bP6 =nydG -END PGP SIGNATURE- -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Message Signing based authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Or SIGHASH of a transaction spending those coins or updating the SIN... On 11/2/13 2:14 PM, Johnathan Corgan wrote: On 11/01/2013 10:01 PM, bitcoingr...@gmx.com wrote: Server provides a token for the client to sign. Anyone else concerned about signing an arbitrary string? Could be a hash of $EVIL_DOCUMENT, no? I'd want to XOR the string with my own randomly generated nonce, sign that, then pass the nonce and the signature back to the server for verification. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSdXPaAAoJEAdzVfsmodw4+m8P/1Ce/PwZOYfiFuFJ8pmT2tb2 ro7tw7zSr12RSTvs+qRl7lDzJzQ6BDXOdXZCkcU0Vj3TDm8fdrrXN/iw3iQYU/5Y 3K7hj2mGqQUMovCLw0CbrMWrMvor7FhO6MZsRwe0+VxDV/dDrX5f5vSEhnkR26be NrzOFU4hqGM3R4eLq8Bmw5rVD/VCrRzKoXXAvJb1EwM1+fQPjKi+bNMJu3reyfXU 5eMbbiM6tUMmPXy9M6vZrN+6ad53x3KUVP6+/hXxsrnfPp57WQzRZlvwTo/qdJ1C Oxl71m6o2zkXbLTFmg1xmK/A4V1BPTLD6nLDIsw+wTBBfdn22pfDv6Q8d3VRctrd 6x+PMkwysoMjhemmkXCY/7G9GD6AGsrYSqIShSULd9QO5WxAFzRO01ewiRUCUFHi Dn0LEjy8/R/CWK3jvj9uL3vQh9DLdOtqf/X7cEtjF3LThVP+stFTsmXObhTh/8Ai YYjpnwOFG5ZtDzRZfP3OCwyhqlsaMlNgN4xnyR4GPaoJRP3a0zllblIbTWzg6nhY jbON5Ec9N9txGhagYOoAvcQYqGyJdffkBzW82CRUsFYuYYmW2oLUQXPhAGDBIzzj g/7RjMlM1OEp3qctxMZQlrTj7VJmhD768PRLh2XvEDmEC5Qb8Tcq28Nq5t85/O/6 i3+pzT5rMuiIZWLx7Msv =tAUY -END PGP SIGNATURE- -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback requested: reject p2p message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If I understand the code correctly, it's not about rejecting blocks. It's about noticing that 50% of recent blocks are declaring a version number that is meaningless to you. Chances are, there's been a soft fork and you should upgrade. On 10/30/13 1:24 AM, Mike Hearn wrote: But if you are getting soft-forked recent versions of the reference implementation WILL alert you; see this code in main.cpp: Perhaps I'm confused about how we're using the term soft fork. My understanding is that this is where a new upgrade is designed to look valid to old nodes, and if you don't upgrade you rely on the miner majority to get you back on track. For instance, P2SH was done this way - old nodes that didn't upgrade during that transition believed all spends of P2SH outputs were valid, even those spending someone elses coins. In this case, the code you cite won't do anything because your client will never reject a block during a soft-forking upgrade, even if it does something that's supposed to be invalid or nonsensical. If a new block version changes the serialization format or script language or SIGHASH rules such that old clients reject the block, then they will end up on a hard fork and the alerting code will trigger, which is correct and as it should be. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJScMvBAAoJEAdzVfsmodw4I5sQAL0Wq4e7b6/KX2zl9RmtFl5S qM9ZJkJV8qzirj1hMgVwvnuOj147Vb3EkJujxeMa8ujepXKZ215mMCLnCHPzWPpJ jTtOBn1FCkCUbyt9uSbZ+56NR+ElmSOsDpAJ8IR9VywHriCxm4OIAMCLTR6CKRfr 6NWySvjEMlsSHyr7DFaJTlMqo+KIUWGmP7tdPu1L2AvNE+613dI5q76IjUHYoxhu 2dDtanYUvFCsdLZEnjTr1N45BBf1mTSlPfmA1ZWHgM779h6VIyb0TeO+iCaxpvWp 2RpSDj3+diFdMUK2uu69ZcwkREH0/RoQLOys6U5DfaGkpPtjY0YXB5DwN9quKgzX padWzbQ0flpwWLYOPYrWATz4sWflxZJu6wHAcUkRS5k9crOLVjritXs1205x7YET 0H9jtbqXmBRXidCP2BOZPdq0PGDF8g2VeEHR69JRe3F3dBfSvbgHfKoiF1jpLLqb rttoP+nD4ZRX8FesV2E/DEZgDZJMd8eqDKNDjq7Db4BTDg24Nq2ATNE2fBtenXwI nXVNdmnvjDxjF0weJGlYgaQTfgVwHRxs+j4qgY4VLM0qEYplhHgg+KmOMFUtxAF/ sZv6w56XtCZS3LdNONAJSZzXIcqgmcodiWKVxkTL29dsWKikcBL5cG9ipdfmjQKT eccFOHArsbW3eSfKP/Mb =FSQI -END PGP SIGNATURE- -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Making fee estimation better
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There's no reason the signing can't be done all at once. The wallet app would create and sign three transactions, paying avg-std.D, avg, and avg+std.D fee. It just waits to broadcast the latter two until it has to. On 10/25/13 5:02 AM, Andreas Petersson wrote: Worth thinking about the whole ecosystem of wallets involved; they all have to handle double-spends gracefully to make tx replacement of any kind user friendly. We should try to give people a heads up that this is coming soon if that's your thinking. If there is a situation where wallets are supposed to constantly monitor the tx propagation and recreate their transactions with different fees, this would make a lot of usecases inconvenient. half-offline bluetooth transactions, users with unstable connections, battery power lost, etc, etc. - and last but not least power concerns on hardware wallets on the bitcoincard (tx signing drains a significant amount of power and should therefore only be done once) -Andreas -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSanJVAAoJEAdzVfsmodw4RHYQAKBrku4S80GXtbt4wBgkRMgx EQuobBrwtknxHOhKyYuBeAJ+h8ao1zSSNeqLvS5fJShH7vwBD2UOePLw4Nsy5p9U pe56c07pRmgi+EWdq/3o1tggp9HN0FR3HDRwt03U4qrPTx449kHb11aOw5KZH7VS ZiG09gKxkMPOtUy9dmVukjkG3zQ1AWjax+aOoseCnkU8u1I4kfhOyWLIjD7ciMm4 07gD8MzBLHTfJ6/pwUczQCby76Xdg51G/5d/toT3EnXyEOC7tCbI4xunAn1eIyg3 eCUNYaOQ7WYV9tjBUDGFwjVkGDJ8KdzEUqMPEK5nAWF29vmrwBSGJ4H2C47OkTQA 58Ie0hEYc5FMNuUCUWz3IGt2zoQ/8YENtNUDKG8oVoNhAIp5zkLK8wsMAJjZP6WM z56JUl8NZ2Ka5U1OelImGGVZIx4NXrXlccyxemAn3/c+krkpNv0CHAeMCeNbPG8i e4l2vQandiBW4NBGVYcm5A/EO6VJHAJhLEPT0pjmbuq4qTACo4Fgeb0LpOnWb/1a 6b1SdGGhMMrXeR2IaIbnx0+0WArixsOPl9w+R9WbrMh8g7hYBLH8EpGrRj0omim7 OoJb+W599HU37XZyWtuov+8Ouh5DpnP9l4hvNxHmro77uPPq10i/ibMd0Bnm4zZd ALtIYpYYgUCN1D9lQwPQ =BjIH -END PGP SIGNATURE- -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Faster databases than LevelDB
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Also somewhat related, I have been looking for some time now to abstract out the UTXO and block databases so that a variety of key/value stores could be used as a backend, configured by a command line parameter. In particular, it would be interesting for some server applications to support HyperDex, which is basically a distributed, fault-tolerant version of LevelDB: http://hyperdex.org/ By the same mechanism you could just as easily support a Sophia backend. Mark On 9/17/13 4:00 AM, Mike Hearn wrote: LevelDB is fast - very fast if you give it enough CPU time and disk seeks. But it's not the last word in performance. HyperLevelDB is a forked LevelDB with some changes, mostly, finer grained locking and changes to how compaction works: http://hyperdex.org/performance/leveldb/ However, it comes with a caveat - one of the changes they made is to take away write throttling if compaction falls behind, the app itself is expected to do that. Sophia is a competitor to LevelDB. The website claims that in benchmarks it completely smokes LevelDB. I have not explored how it does this or tried to replicate their benchmarks myself: http://sphia.org/index.html http://sphia.org/benchmarks.html It's written in C and BSD licensed. As an example of the kind of speedup they claim to be capable of, they say LevelDB could do 167,476 random reads per second on their SSD based machine. Sophia could do 438,084 reads/sec. Random reads are of course the most interesting for us because that's what UTXO lookups involve. They also compare against HyperLevelDB, where the differences are much less pronounced and actually HyperLevelDB appears to be able to do random writes faster than Sophia. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSOIymAAoJEAdzVfsmodw4H48QALC+ae4wRLEg3lrg9sgayfOn ukLM079PXgEbARFPt6WxkLnNGYzEbb7IzT0uvaKH4VIW/rrORy9VqNPmliF+834h XygUwfAzU04K/oLyCsdWZcOugj2P8aufNeA6whLS5IijDLtHb3Ueu4ORNcfLBGqp KKfqPj0QHseusiLJ9f3IW+LrdM1vAoT1jryTngpQy2i+qFFDM6CN3THCq4adJvjr AnYlfLoJSZ0/obz/krwLv6vP1BbwxXzv5CfD0Q2bdoEV/EgWDP3Bd5tUzUCjj53/ qMmhaACoVlarohh64s3JNSDSkHDFSbHFt65ZgNQbNY1wmSeyilQcd8FGWOF/WRzW Z/pl2IdhoCm3t86xSggRGivj/EVeBJlD36i7ohpDbVWFPsf6B4e5M6xSdso/2WBp fr55TwehCaGE+UHa0gITkE/si1txvY4gti0bLNvwFDEcZ3qsXRsz4CyLlZLMBbPX 4aRNGyqv2yJ2AivkEyNOUugo1Q8RKEKZWfWWDecI53DHdebzKX1zu9GLJwlGJqGw Qzm7Tdb7S8J/D6IIHf4Xq2LDhQ2fnPylmGSmtuVFEMxeDhmdbNqKSr3kqlWQf3T8 Oa8bm6kUQFJ+11jLEkVEGZJC4e42+faQBxR+CsqvVsTEezDCP1dE7D3QV8ry9YBc DwXt3299Q03B5LoxpWTq =KseH -END PGP SIGNATURE- -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys
Getting OT... For a while I've wanted to combine one of these mnemonic code generators with an NLP engine to do something like output a short story as the passphrase, even a humorous onem with the key encoded in the story itself (remember the gist of the story and that's sufficient to reconstruct the key). Also, obligatory link about the failures of unsanitized word lists: http://iam.peteashton.com/keep-calm-rape-tshirt-amazon/ It can really backfire to get one of these things wrong. Mark On 9/10/13 3:08 PM, Gregory Maxwell wrote: On Tue, Sep 10, 2013 at 2:03 PM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: Well let's hope something like murder black people, stupid asian person or whip african slave doesn't come up. :-) Maybe it would have been better without the aggressive words? Ouch. This sounds like something that $20 of mechanical turk time could help out with a lot. Put up the 2048 words and ask people to rate them for potential offensiveness and threatening. :) Nouns often make for fairly neutral words, though careful for place names which have had political complications. E.g. gdansk vs danzig. -- How ServiceNow helps IT people transform IT departments: 1. Consolidate legacy IT systems to a single system of record for IT 2. Standardize and globalize service processes across IT 3. Implement zero-touch automation to replace manual, redundant tasks http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Freimarkets: a proposal for user assets, distributed exchange, and off-chain txns
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Off-and-on for the past couple years, Jorge Timón and I have been developing an extension of the Bitcoin and (pre-OpenCoin) Ripple distributed protocols which enable user-specified bearer instruments, distributed peer-to-peer exchange, off-chain accounting, auctions, derivatives and transitive transactions, and the multitude of financial contracts having such primitives would make possible. The specification is now reasonably complete enough that we would like to receive input from the community. The PDF is available for viewing here: http://freico.in/docs/freimarkets-v0.0.1.pdf We're looking for public comments about this or related approaches. In particular we've spent a fair chunk of time working out how to handle coordination of private accounting servers with the public chain and derivatives contracts, both of which are basically cryptographic protocols expressed as bitcoin scripts. Input from any of the resident cryptographers would be very appreciated. Happy hacking, Mark Friedenbach -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSF/rKAAoJEAdzVfsmodw4xVYP/jLoB6eDlgREawfbcW6kXe4s 25YnP19Hvk0NBk0Fv9G6zhAaOdHlR4dkcq2TueAqGHA+Drtp06eVkWDfqQOioGjx LrQF6ct9AbBZNN8glo7+JY70hecbEgWeW77cSrDTFxQAWwNnq0hVwVFb6++9rY9+ 6Q4jwJtqawWlMYRlFOiK1VW/MvI2WV4bypAjuOYsTnXZ8eFjyO+obZYUuMs6JUWd XojkDeL60NB6JHVoeyx270bvbP1Of5ErLZRuhC26MA9K4S6jlgfvLCqYBHnjRMHI KI/K7wqcpbbyldCSIcIsVtSrwBZRUgYfUFEFXvFjwzC0EwgGFwQC3pCqTWzskpo4 KS8ZMpgr7BjI+M0GSpRyh5x0aqZkptaaogCssHzoykmEwm6dyK8cdtdhtFAsGAMs dYpftZ/NJ17tOkUd22TXpIxWPckFBOmuV/hlr0wFpj50glttMH/8NwqKtGcjO21e ecuiJzXbjCGlFpKIG+JI5BOXvEeD5VoegsfLTwA9Egkuhh8FXyiqIPUEEV0W1DAC 0CIsX8XmWnKeRBWWa/2AHVuSQlBlut9gX1zRElaU5YSW58zsE3UeVPvSOJOh6ZKZ eLkRjzuyDrpuJiRKXFdTS857grUhYs+E5xeVkkZWy+q3XqQ7LofcZjp3Xt8tmx4j LSaZTewUL15MjQR0Ow8a =xyHR -END PGP SIGNATURE- -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/18/13 8:09 PM, John Dillon wrote: On the other hand, a tx with some txin proofs can be safely relayed by SPV nodes, an interesting concept. Do the UTXO commitment people have keeping proof size small in mind? More than a kilobyte, probably less than a few tens of kilobytes. It depends on parameters (branching factor, script vs hash(script)) that are tweakable with time/space and long-term/short-term tradeoffs. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSEakMAAoJEAdzVfsmodw4B9wQAIu82nxMAyMiTpFcWW6v0fQ9 26bzOznyIhzAlFUeCXvgwtqoxjRcheLOnsFsAr0TLdLYrx00o4+MS0GepV40gEpd Ds/itvAnW8aWdCls0qy1hljWrsp8R3IfXWchXy13kjOhTIx8JaALeHEzOCsJVxCf nWrV7UNLRO1eXhLUnFLnZ3/HdljMZnLqLexSGXorn4I2zwg5HGNMJxIenU3vDj8s 68k4rSk/eUptG97ZmJxCysn7nt5F1cxRutsVOPxsC/4+FptMYf9YJRJDNpvttYyl ztI2xV+ARfEvSZs0lqGAcpvKwVV4IvZDGXhUCiS6LQ99tvMid4kjIGYPwlyK6SJW LoYVbvjbauEIPn4URW8XilMB5EEJisr5/7ZV/aDLEFcBA/is5ePuQioo/81yOWUw k5PghJ/TBMBQhxOGCz86onCI1YwrWfhu2sz6xNIHm9lbyZQcw3N/ai77FQqxxkxp iBbIAvhk4sQ7lPt4QHmiL4isPzaiScKVTjvzfc5hAHSmu6xQysf8VA/SwUSgAJZB iUPYRz5URaw8a/WDlo7YA6BRV/l7RloEcWGs6br3jVYxtJSaxqDwwrUV3SdDtzBR uiE1OVPp8ihY3OJbnZkbvy3lXXlLjwrLVwMUgprhUo793QtktZH+O0V+StcGKLGD 4rdK6Z3C8Wx9FY2fvkBy =HZdx -END PGP SIGNATURE- -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John, What you are recommending is a drastic change that the conservative bitcoin developers probably wouldn't get behind (but let's see). However proof-of-stake voting on protocol soft-forks has vast implications even beyond the block size limit. Within Freicoin, we have looked at is as a possibility for determining how to distribute the demurrage, a proposal we are calling 'Republicoin' due to the fact that with proxy voting we expect a system to emerge similar to the government budgeting in parliamentary republics. Distributed, non-coersive government by protocol, if you will. So anyway, even if you get shot down, please continue to pursue this proposal. It very likely has uses that you haven't thought of yet. Cheers, Mark On 6/9/13 9:09 PM, John Dillon wrote: It has been suggested that we leave the decision of what the blocksize to be entirely up to miners. However this leaves a parameter that affects every Bitcoin participant in the control of a small minority. Of course we can not force miners to increase the blocksize if they choose to decrease it, because the contents of the blocks they make are their decision and their decision only. However proposals to leave the maximum size unlimited to allow miners to force us to accept arbitrarily large blocks even if the will of the majority of Bitcoin participants is that they wish to remain able to validate the blockchain. What we need is a way to balance this asymetrical power relationship. Proof-of-stake voting gives us a way of achieving that balance. Essentially for a miner to prove that the majority will of the poeple is to accept a larger blocksize they must prove that the majority has in fact voted for that increase. The upper limit on the blocksize is then determined by the median of all votes, where each txout in the UTXO set is one vote, weighted by txout value. A txout without a corresponding vote is considered to be a vote for the status quo. To allow the voting process to continue even if coins are lost votes, including default votes, are weighted inversely according to their age in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old will be recorded the same as a 1 year old vote weighted as 0.67BTC, and a 1 day old and 6 months old UTXO are treated equivalently. The 1 year minimum is simply to make voting required no more than once per year. (of course, a real implementation should do all of these figures by block height, IE after 52,560 blocks instead of after 1 year) A vote will consist of a txout with a scriptPubKey of the following form: OP_RETURN magic vote_id txid vout vote scriptSig Where scriptSig is a valid signature for a transaction with nLockTime 500,000,000-1 spending txid:vout to scriptPubKey: OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL vote_id is the ID of the specific vote being made, and magic is included to allow UTXO proof implementations a as yet unspecified way of identifying votes and including the weighted median as part of the UTXO tree sums. (it also allows SPV clients to verify the vote if the UTXO set is a Patricia tree of scriptPubKeys) vote is just the numerical vote itself. The vote must compute the median, rather than the mean, so as to not allow someone to skew the vote by simply setting their value extremely high. Someone who still remembers their statistics classes should chime in on the right way to compute a median in a merkle-sum-tree. The slightly unusual construction of votes makes implementation by wallet software as simple as possible within existing code-paths. Votes could still be constructed even in wallets lacking specific voting capability provided the wallet software does have the ability to set nLockTime. Of course in the future the voting mechanism can be used for additional votes with an additional vote_id. For instance the Bitcoin community could vote to increase the inflation subsidy, another example of a situation where the wishes of miners may conflict with the wishes of the broader community. Users may of course actually create these specially encoded txouts themselves and get them into the blockchain. However doing so is not needed as a given vote is only required to actually be in the chain by a miner wishing to increase the blocksize. Thus we should extend the P2P protocol with a mechanism by which votes can be broadcast independently of transactions. To prevent DoS attacks only votes with known vote_id's will be accepted, and only for txid:vout's already in the blockchain, and a record of txouts for whom votes have already broadcast will be kept. (this record need not be authoritative as its purpose is only to prevent DoS attacks) Miners wishing to increase the blocksize can record these votes and include them in the blocks they mine as required. To reduce the cost of including votes in blocks 5% of every block should be
Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Jun 01, 2013 at 10:32:07PM -0400, Gavin wrote: Feels like a new opcode might be better. Eg data 100 OP_NOP1 ... Where op_nop1 is redefined to be 'verify depth' ... I would suggest the more general 'push depth onto stack'. You can then use the usual math/relational operators which otherwise have seen little use. Assuming it's even a good idea to go down this route at all. Mark -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRrTNTAAoJEAdzVfsmodw4mf0QAJAej83Pth0ZVfua3I5+RR58 7gHpt2rBHP8KuwDH6J3VbxZDKy0n+6/nC5+kjI+G0tYGt3yU4wARJA+afB+zxScT DPO1iMRxcwOz6KtPWpyCEEOW4ZlILQmbhGyA7XZ+Oy+hZZMBWvPCt4BQsyTjUJ4Y +gTDqdkNk9B2HZh5gskXRkOYWGB9517tTQ0zYWLtVm2sgeJvRkd73WLZGHm4nrLI 20OLaTP0RuW5+qfV4BSQp/Y3k/9OqrAFXiXo5NAs6PL81x3/IDGKpsfnZNLxPU0i QLg9RdHZ9769fTgACO8822pLaWQ4LtLB4FA/mVYBhr/ORWSIKfod7TPGF3AYiIpF db2IESX2HFAxMQ9xTi/2R9zYwCvVpQWwZNse+DEMhoQhykcNv/+sZBE93xHGSgsq XKBOXLJGCxnUwszz+CSmwrQVmwPqLAU/fFybnAI/6VHMMd8phgNV5oLluAaZyBTi DpImUul2fqKaJeRjQBB1Qya7az0Qvf4LSHFDQKYYWG/H03R5CxFkxiM/XsiyuzpK 7+MVh6gnWaoayB/eAh0KVgWXUrQQGUBwvVmSk6DU73yQ8Db0BHaxBaUihlsJrMTX Ybh8d8GSbXsaUjolvJ/dSclcAw7ovW91jqEhRoBq9AKQA23RjHChzT8M1UkXZclZ 8k6XWOJy+NaNmklEwMqF =iDLz -END PGP SIGNATURE- -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
