Btw How awful that I didn't cite my sources, please exucse me, this is definitely not my intention sometimes I get too caught up in my own excitemtnt 1) Martin, J., Alvisi, L., Fast Byzantine Consensus. *IEEE Transactions on Dependable and Secure Computing. 2006. *3(3) doi: Please see John-Phillipe Martin and Lorenzo ALvisi 2) https://eprint.iacr.org/2011/191.pdf One_Time Winternitz Signatures. On Mon, May 11, 2015 at 1:20 PM, < bitcoin-development-request@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-request@lists.sourceforge.net > > You can reach the person managing the list at > bitcoin-development-owner@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: Bitcoin-development Digest, Vol 48, Issue 62 (Damian Gomez) > > > ---------- Forwarded message ---------- > From: Damian Gomez > To: bitcoin-development@lists.sourceforge.net > Cc: > Date: Mon, 11 May 2015 13:20:46 -0700 > Subject: Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, > Issue 62 > Hllo > > I want to build from a conversation that I had w/ Peter (T?) regarding the > increase in block size in the bitcoin from its's current structure would be > the proposasl of an prepend to the hash chain itself that would be the > first DER decoded script in order to verify integrity(trust) within a set > of transactions and the originiator themselves. > > It is my belief that the process to begin a new encryption tool using a > variant of the WinterNitz OTS for its existential unforgeability to be the > added signatures with every Wallet transaction in order to provide a > consesnus systemt that takes into accont a personal level of intergrity for > the intention fo a transaction to occur. This signature would then be > hashes for there to be an intermediate proxy state that then verifies and > evaluates the trust fucntion for the receiving trnsactions. This > evaluation loop would itself be a state in which the mining power and the > rewards derived from them would be an increased level of integrity as > provided for the "brainers" of a systems who are then the "signatuers" of > the transaction authenticity, and additiaonally program extranonces of x > bits {72} in order to have a double valid signature that the rest of the > nodes would accept in order to have a valid address from which to be able > to continuously receive transactions. > > There is a level of diffculty in obtaining brainers, fees would only apply > uin so much as they are able to create authentic transactions based off the > voting power of the rest of the received nodes. The greater number of > faults within the system from a brainer then the more, so would his > computational power be restricted in order to provide a reward feedback > system. This singularity in a Byzantine consensus is only achieved if the > route of an appropriate transformation occurs, one that is invariant to the > participants of the system, thus being able to provide initial vector > transformations from a person's online identity is the responsibilty that > we have to ensure and calulate a lagrangian method that utilisizes a set of > convolutional neural network funcitons [backpropagation, fuzzy logic] and > and tranformation function taking the vectors of tranformations in a > kahunen-loeve algorithm and using the convergence of a baryon wave function > in order to proceed with a baseline reading of the current level of > integrity in the state today that is an instance of actionable acceleration > within a system. > > This is something that I am trying to continue to parse out. Therefore > there are still heavy questions to be answered(the most important being the > consent of the people to measure their own levels of integrity through > mined information)> There must always be the option to disconnect from a > transactional system where payments occur in order to allow a level of > solace and peace within individuals -- withour repercussions and a seperate > system that supports the offline realm as well. (THis is a design problem) > > Ultimately, quite literally such a transaction system could exist to > provide detailed analysis that promotes integrity being the basis for > sharing information. The fee structure would be eliminated, due to the > level of integrity and procesing power to have messages and transactions > and reviews of unfiduciary responsible orgnizations be merited as highly > true (.9 in fizzy logic) in order to promote a well-being in the state. > That is its own reward, the strenght of having more processing speed. > > > FYI(thank you to peter whom nudged my thinking and interest (again) in > this area. ) > > This is something I am attempting to design in order to program it. Though > I am not an expert and my technology stack is limited to java and c (and my > issues from it). I provided a class the other day the was pseudo code for > the beginning of the consensus. Now I might to now if I am missing any of > teh technical paradigms that might make this illogical? I now with the > advent of 7petabyte computers one could easily store 2.5 petabytes of human > information for just an instance of integrity not to mention otehr > emotions. > > > > *Also, might someone be able to provide a bit of information on Bitcoin > core project?* > > thank you again. Damain. > > On Mon, May 11, 2015 at 10:29 AM, < > bitcoin-development-request@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-request@lists.sourceforge.net >> >> You can reach the person managing the list at >> bitcoin-development-owner@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. Fwd: Bitcoin core 0.11 planning (Wladimir) >> 2. Re: Bitcoin core 0.11 planning (Wladimir) >> 3. Long-term mining incentives (Thomas Voegtlin) >> 4. Re: Long-term mining incentives >> (insecurity@national.shitposting.agency) >> 5. Re: Reducing the block rate instead of increasing the maximum >> block size (Luke Dashjr) >> 6. Re: Long-term mining incentives (Gavin Andresen) >> >> >> ---------- Forwarded message ---------- >> From: Wladimir >> To: Bitcoin Dev >> Cc: >> Date: Mon, 11 May 2015 14:49:53 +0000 >> Subject: [Bitcoin-development] Fwd: Bitcoin core 0.11 planning >> On Tue, Apr 28, 2015 at 11:01 AM, Pieter Wuille >> wrote: >> > As softforks almost certainly require backports to older releases and >> other >> > software anyway, I don't think they should necessarily be bound to >> Bitcoin >> > Core major releases. If they don't require large code changes, we can >> easily >> > do them in minor releases too. >> >> Agree here - there is no need to time consensus changes with a major >> release, as they need to be ported back to older releases anyhow. >> (I don't really classify them as software features, but properties of >> the underlying system that we need to adopt to) >> >> Wladimir >> >> >> >> >> ---------- Forwarded message ---------- >> From: Wladimir >> To: Bitcoin Dev >> Cc: >> Date: Mon, 11 May 2015 15:00:03 +0000 >> Subject: Re: [Bitcoin-development] Bitcoin core 0.11 planning >> A reminder - feature freeze and string freeze is coming up this Friday >> the 15th. >> >> Let me know if your pull request is ready to be merged before then, >> >> Wladimir >> >> On Tue, Apr 28, 2015 at 7:44 AM, Wladimir J. van der Laan >> wrote: >> > Hello all, >> > >> > The release window for 0.11 is nearing, I'd propose the following >> schedule: >> > >> > 2015-05-01 Soft translation string freeze >> > Open Transifex translations for 0.11 >> > Finalize and close translation for 0.9 >> > >> > 2015-05-15 Feature freeze, string freeze >> > >> > 2015-06-01 Split off 0.11 branch >> > Tag and release 0.11.0rc1 >> > Start merging for 0.12 on master branch >> > >> > 2015-07-01 Release 0.11.0 final (aim) >> > >> > In contrast to former releases, which were protracted for months, let's >> try to be more strict about the dates. Of course it is always possible for >> last-minute critical issues to interfere with the planning. The release >> will not be held up for features, though, and anything that will not make >> it to 0.11 will be postponed to next release scheduled for end of the year. >> > >> > Wladimir >> >> >> >> >> ---------- Forwarded message ---------- >> From: Thomas Voegtlin >> To: Bitcoin Development >> Cc: >> Date: Mon, 11 May 2015 18:28:46 +0200 >> Subject: [Bitcoin-development] Long-term mining incentives >> The discussion on block size increase has brought some attention to the >> other elephant in the room: Long-term mining incentives. >> >> Bitcoin derives its current market value from the assumption that a >> stable, steady-state regime will be reached in the future, where miners >> have an incentive to keep mining to protect the network. Such a steady >> state regime does not exist today, because miners get most of their >> reward from the block subsidy, which will progressively be removed. >> >> Thus, today's 3 billion USD question is the following: Will a steady >> state regime be reached in the future? Can such a regime exist? What are >> the necessary conditions for its existence? >> >> Satoshi's paper suggests that this may be achieved through miner fees. >> Quite a few people seem to take this for granted, and are working to >> make it happen (developing cpfp and replace-by-fee). This explains part >> of the opposition to raising the block size limit; some people would >> like to see some fee pressure building up first, in order to get closer >> to a regime where miners are incentivised by transaction fees instead of >> block subsidy. Indeed, the emergence of a working fee market would be >> extremely reassuring for the long-term viability of bitcoin. So, the >> thinking goes, by raising the block size limit, we would be postponing a >> crucial reality check. We would be buying time, at the expenses of >> Bitcoin's decentralization. >> >> OTOH, proponents of a block size increase have a very good point: if the >> block size is not raised soon, Bitcoin is going to enter a new, unknown >> and potentially harmful regime. In the current regime, almost all >> transaction get confirmed quickly, and fee pressure does not exist. Mike >> Hearn suggested that, when blocks reach full capacity and users start to >> experience confirmation delays and confirmation uncertainty, users will >> simply go away and stop using Bitcoin. To me, that outcome sounds very >> plausible indeed. Thus, proponents of the block size increase are >> conservative; they are trying to preserve the current regime, which is >> known to work, instead of letting the network enter uncharted territory. >> >> My problem is that this seems to lacks a vision. If the maximal block >> size is increased only to buy time, or because some people think that 7 >> tps is not enough to compete with VISA, then I guess it would be >> healthier to try and develop off-chain infrastructure first, such as the >> Lightning network. >> >> OTOH, I also fail to see evidence that a limited block capacity will >> lead to a functional fee market, able to sustain a steady state. A >> functional market requires well-informed participants who make rational >> choices and accept the outcomes of their choices. That is not the case >> today, and to believe that it will magically happen because blocks start >> to reach full capacity sounds a lot like like wishful thinking. >> >> So here is my question, to both proponents and opponents of a block size >> increase: What steady-state regime do you envision for Bitcoin, and what >> is is your plan to get there? More specifically, how will the >> steady-state regime look like? Will users experience fee pressure and >> delays, or will it look more like a scaled up version of what we enjoy >> today? Should fee pressure be increased jointly with subsidy decrease, >> or as soon as possible, or never? What incentives will exist for miners >> once the subsidy is gone? Will miners have an incentive to permanently >> fork off the last block and capture its fees? Do you expect Bitcoin to >> work because miners are altruistic/selfish/honest/caring? >> >> A clear vision would be welcome. >> >> >> >> >> ---------- Forwarded message ---------- >> From: insecurity@national.shitposting.agency >> To: thomasv@electrum.org >> Cc: bitcoin-development@lists.sourceforge.net >> Date: Mon, 11 May 2015 16:52:10 +0000 >> Subject: Re: [Bitcoin-development] Long-term mining incentives >> On 2015-05-11 16:28, Thomas Voegtlin wrote: >> >>> My problem is that this seems to lacks a vision. If the maximal block >>> size is increased only to buy time, or because some people think that 7 >>> tps is not enough to compete with VISA, then I guess it would be >>> healthier to try and develop off-chain infrastructure first, such as the >>> Lightning network. >>> >> >> If your end goal is "compete with VISA" you might as well just give up >> and go home right now. There's lots of terrible proposals where people >> try to demonstrate that so many hundred thousand transactions a second >> are possible if we just make the block size 500GB. In the real world >> with physical limits, you literally can not verify more than a few >> thousand ECDSA signatures a second on a CPU core. The tradeoff taken >> in Bitcoin is that the signatures are pretty small, but they are also >> slow to verify on any sort of scale. There's no way competing with a >> centralised entity using on-chain transactions is even a sane goal. >> >> >> >> >> ---------- Forwarded message ---------- >> From: Luke Dashjr >> To: bitcoin-development@lists.sourceforge.net >> Cc: >> Date: Mon, 11 May 2015 16:47:47 +0000 >> Subject: Re: [Bitcoin-development] Reducing the block rate instead of >> increasing the maximum block size >> On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote: >> > 1. It will encourage centralization, because participants of mining >> > pools will loose more money because of excessive initial block template >> > latency, which leads to higher stale shares >> > >> > When a new block is solved, that information needs to propagate >> > throughout the Bitcoin network up to the mining pool operator nodes, >> > then a new block header candidate is created, and this header must be >> > propagated to all the mining pool users, ether by a push or a pull >> > model. Generally the mining server pushes new work units to the >> > individual miners. If done other way around, the server would need to >> > handle a high load of continuous work requests that would be difficult >> > to distinguish from a DDoS attack. So if the server pushes new block >> > header candidates to clients, then the problem boils down to increasing >> > bandwidth of the servers to achieve a tenfold increase in work >> > distribution. Or distributing the servers geographically to achieve a >> > lower latency. Propagating blocks does not require additional CPU >> > resources, so mining pools administrators would need to increase >> > moderately their investment in the server infrastructure to achieve >> > lower latency and higher bandwidth, but I guess the investment would be >> > low. >> >> 1. Latency is what matters here, not bandwidth so much. And latency >> reduction >> is either expensive or impossible. >> 2. Mining pools are mostly run at a loss (with exception to only the most >> centralised pools), and have nothing to invest in increasing >> infrastructure. >> >> > 3, It will reduce the security of the network >> > >> > The security of the network is based on two facts: >> > A- The miners are incentivized to extend the best chain >> > B- The probability of a reversal based on a long block competition >> > decreases as more confirmation blocks are appended. >> > C- Renting or buying hardware to perform a 51% attack is costly. >> > >> > A still holds. B holds for the same amount of confirmation blocks, so 6 >> > confirmation blocks in a 10-minute block-chain is approximately >> > equivalent to 6 confirmation blocks in a 1-minute block-chain. >> > Only C changes, as renting the hashing power for 6 minutes is ten times >> > less expensive as renting it for 1 hour. However, there is no shop where >> > one can find 51% of the hashing power to rent right now, nor probably >> > will ever be if Bitcoin succeeds. Last, you can still have a 1 hour >> > confirmation (60 1-minute blocks) if you wish for high-valued payments, >> > so the security decreases only if participant wish to decrease it. >> >> You're overlooking at least: >> 1. The real network has to suffer wasted work as a result of the stale >> blocks, >> while an attacker does not. If 20% of blocks are stale, the attacker only >> needs 40% of the legitimate hashrate to achieve 50%-in-practice. >> 2. Since blocks are individually weaker, it becomes cheaper to DoS nodes >> with >> invalid blocks. (not sure if this is a real concern, but it ought to be >> considered and addressed) >> >> > 4. Reducing the block propagation time on the average case is good, but >> > what happen in the worse case? >> > >> > Most methods proposed to reduce the block propagation delay do it only >> > on the average case. Any kind of block compression relies on both >> > parties sharing some previous information. In the worse case it's true >> > that a miner can create and try to broadcast a block that takes too much >> > time to verify or bandwidth to transmit. This is currently true on the >> > Bitcoin network. Nevertheless there is no such incentive for miners, >> > since they will be shooting on their own foots. Peter Todd has argued >> > that the best strategy for miners is actually to reach 51% of the >> > network, but not more. In other words, to exclude the slowest 49% >> > percent. But this strategy of creating bloated blocks is too risky in >> > practice, and surely doomed to fail, as network conditions dynamically >> > change. Also it would be perceived as an attack to the network, and the >> > miner (if it is a public mining pool) would be probably blacklisted. >> >> One can probably overcome changing network conditions merely by trying to >> reach 75% and exclude the slowest 25%. Also, there is no way to identify >> or >> blacklist miners. >> >> > 5. Thousands of SPV wallets running in mobile devices would need to be >> > upgraded (thanks Mike). >> > >> > That depends on the current upgrade rate for SPV wallets like Bitcoin >> > Wallet and BreadWallet. Suppose that the upgrade rate is 80%/year: we >> > develop the source code for the change now and apply the change in Q2 >> > 2016, then most of the nodes will already be upgraded by when the >> > hardfork takes place. Also a public notice telling people to upgrade in >> > web pages, bitcointalk, SPV wallets warnings, coindesk, one year in >> > advance will give plenty of time to SPV wallet users to upgrade. >> >> I agree this shouldn't be a real concern. SPV wallets are also more >> likely and >> less risky (globally) to be auto-updated. >> >> > 6. If there are 10x more blocks, then there are 10x more block headers, >> > and that increases the amount of bandwidth SPV wallets need to catch up >> > with the chain >> > >> > A standard smartphone with average cellular downstream speed downloads >> > 2.6 headers per second (1600 kbits/sec) [3], so if synchronization were >> > to be done only at night when the phone is connected to the power line, >> > then it would take 9 minutes to synchronize with 1440 headers/day. If a >> > person should accept a payment, and the smart-phone is 1 day >> > out-of-synch, then it takes less time to download all the missing >> > headers than to wait for a 10-minute one block confirmation. Obviously >> > all smartphones with 3G have a downstream bandwidth much higher, >> > averaging 1 Mbps. So the whole synchronization will be done less than a >> > 1-minute block confirmation. >> >> Uh, I think you need to be using at least median speeds. As an example, I >> can >> only sustain (over 3G) about 40 kbps, with a peak of around 400 kbps. 3G >> has >> worse range/coverage than 2G. No doubt the *average* is skewed so high >> because >> of densely populated areas like San Francisco having 400+ Mbps cellular >> data. >> It's not reasonable to assume sync only at night: most payments will be >> during >> the day, on battery - so increased power use must also be considered. >> >> > According to CISCO mobile bandwidth connection speed increases 20% every >> > year. >> >> Only in small densely populated areas of first-world countries. >> >> Luke >> >> >> >> >> ---------- Forwarded message ---------- >> From: Gavin Andresen >> To: insecurity@national.shitposting.agency >> Cc: Bitcoin Dev >> Date: Mon, 11 May 2015 13:29:02 -0400 >> Subject: Re: [Bitcoin-development] Long-term mining incentives >> I think long-term the chain will not be secured purely by proof-of-work. >> I think when the Bitcoin network was tiny running solely on people's home >> computers proof-of-work was the right way to secure the chain, and the only >> fair way to both secure the chain and distribute the coins. >> >> See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a for some >> half-baked thoughts along those lines. I don't think proof-of-work is the >> last word in distributed consensus (I also don't think any alternatives are >> anywhere near ready to deploy, but they might be in ten years). >> >> I also think it is premature to worry about what will happen in twenty or >> thirty years when the block subsidy is insignificant. A lot will happen in >> the next twenty years. I could spin a vision of what will secure the chain >> in twenty years, but I'd put a low probability on that vision actually >> turning out to be correct. >> >> That is why I keep saying Bitcoin is an experiment. But I also believe >> that the incentives are correct, and there are a lot of very motivated, >> smart, hard-working people who will make it work. When you're talking about >> trying to predict what will happen decades from now, I think that is the >> best you can (honestly) do. >> >> -- >> -- >> Gavin Andresen >> >> >> ------------------------------------------------------------------------------ >> One dashboard for servers and applications across Physical-Virtual-Cloud >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insights >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >