[Bitcoin-development] No Bitcoin For You
A recent post, which I cannot find after much effort, made an excellent point. If capacity grows, fewer individuals would be able to run full nodes. Those individuals, like many already, would have to give up running a full-node wallet :( That sounds bad, until you consider that the alternative is running a full node on the bitcoin 'settlement network', while massive numbers of people *give up any hope of directly owning bitcoin at all*. If today's global payments are 100Ktps, and move to the Lightning Network, they will have to be consolidated by a factor of 25000:1 to fit into bitcoin's current 4tps capacity as a settlement network. You executing a personal transaction on that network will be about as likely as you personally conducting a $100 SWIFT transfer to yourself today. For current holders, just selling or spending will get very expensive! Forcing block capacity to stay small, so that individuals can run full nodes, is precisely what will force bitcoin to become a backbone that is too expensive for individuals to use. I can't avoid the conclusion that Bitcoin has to scale, and we might as well be thinking about how. There may be a an escape window. As current trends continue toward a landscape of billions of SPV wallets, it may still be possible for individuals collectively to make up the majority of the network, if more parts of the network itself rely on SPV-level security. With SPV-level security, it might be possible to implement a scalable DHT-type network of nodes that collectively store and index the exhaustive and fast-growing corpus of transaction history, up to and including currently unconfirmed transactions. Each individual node could host a slice of the transaction set with a configurable size, let's say down to a few GB today. Such a network would have the desirable property of being run by the community. Most transactions would be submitted to it, and like today's network, it would disseminate blocks (which would be rapidly torn apart and digested). Therefore miners and other full nodes would depend on it, which is rather critical as those nodes grow closer to data-center proportions. -- 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] Bitcoin Core 0.10.2 release candidate 1 available
The subject should obviously be Bitcoin Core 0.10.2 release candidate 1 available, not the other way around, -- 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] Bitcoin Core 0.10.1 release candidate 2 available
Binaries for bitcoin Core version 0.10.2rc1 are now available from: https://bitcoin.org/bin/0.10.2/test Source code can be found on github under the signed tag https://github.com/bitcoin/bitcoin/tree/v0.10.2rc1 This is a release candidate for a minor version release, with mainly a fix for a bug that affected Windows users with non-ASCII characters in the data directory. The release also contains translation updates. If you experienced no issues with 0.10.1, there is no need to upgrade. Preliminary release notes for the 0.10.2 release can be found here: https://github.com/bitcoin/bitcoin/blob/v0.10.2rc1/doc/release-notes.md Release candidates are test runs for releases, when no critical problems are found this release candidate will be tagged as 0.10.2. Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues -- 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] [BIP] Normalized Transaction IDs
Ok, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep referencing using hashes of complete transactions (including signatures), while the OP_CHECKAWESOMESIG looks up the previous transaction (which we already need to do anyway in order to insert the prevOut pubkeyScript), normalizes the prevout and calculates its normalized transaction ID. It then inserts the normalized transaction IDs in the OutPoint before calculating its own hash which is then signed. Is that correct so far? Let me try to summarize the discussion so far: I think we have consensus that transaction malleability needs to be addressed, and normalized transaction IDs seem to be the way to go forward. The discussion now is how to use normalized transaction IDs and we have two approaches to implement them: - OP_CHECKAWESOMESIG which continues to use the current hashes to reference a specific signed instance of a class of semantically identical transactions. Internally only the semantic class is enforced. Transactions can be fixed to reference the correct signed instance if the transaction has been changed along the way.is a softfork using the if I don't know this opcode the TX is automatically valid trick On Thu, May 14, 2015 at 2:40 AM Pieter Wuille pieter.wui...@gmail.com wrote: On Wed, May 13, 2015 at 1:32 PM, Tier Nolan tier.no...@gmail.com wrote: On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille pieter.wui...@gmail.com wrote: This was what I was suggesting all along, sorry if I wasn't clear. That's great. So, basically the multi-level refund problem is solved by this? Yes. So to be clear, I think there are 2 desirable end-goal proposals (ignoring difficulty of changing things for a minute): * Transactions and blocks keep referring to other transactions by full txid, but signature hashes are computed off normalized txids (which are recursively defined to use normalized txids all the way back to coinbases). Is this what you are suggesting now as well? * Blocks commit to full transaction data, but transactions and signature hashes use normalized txids. The benefit of the latter solution is that it doesn't need fixing up transactions whose inputs have been malleated, but comes at the cost of doing a very invasive hard fork. -- Pieter -- 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
