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 62HlloI 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 incentivesI 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