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

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

[Damian Gomez]

[-- Attachment #1: Type: text/plain, Size: 24593 bytes --]

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 <dgomez1092@gmail.com>
> 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 <laanwj@gmail.com>
>> To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
>> 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 <pieter.wuille@gmail.com>
>> 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 <laanwj@gmail.com>
>> To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
>> 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
>> <laanwj@gmail.com> 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 <thomasv@electrum.org>
>> To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
>> 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 <luke@dashjr.org>
>> 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 <gavinandresen@gmail.com>
>> To: insecurity@national.shitposting.agency
>> Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
>> 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
>
>

[-- Attachment #2: Type: text/html, Size: 29447 bytes --]