Re: [bitcoin-dev] [Bitcoin-development] BIP for Proof of Payment

These BIPs have been assigned 120 and 121: 120: Proof of Payment 121: Proof of Payment URI scheme Regards, Kalle Den 24 jul 2015 08:27 skrev "Kalle Rosenbaum" : > These BIPs have been assigned 120 and 121: > > 120: Proof of Payment > 121: Proof of Payment URI scheme > > Regards, > Kalle > Den 21

Re: [bitcoin-dev] Bitcoin Core and hard forks

On 7/23/2015 10:51 AM, Jorge Timón wrote: > We know perfectly well that the system will need to eventually be > sustained by fees. Fee revenue can rise just as easily without increased BTC fee rates. Two avenues that are just as effective: increased exchange rate, increased number of fee-paying t

Re: [bitcoin-dev] Making Electrum more anonymous

On 07/23/2015 08:42 PM, Slurms MacKenzie via bitcoin-dev wrote: >> From: "Eric Voskuil via bitcoin-dev" >> >> From our perspective, another important objective of query privacy is >> allowing the caller make the trade-off between the relative levels of >> privacy and performance - from absolute to

Re: [bitcoin-dev] Bitcoin Node Speed Test

On Thu, Jul 23, 2015 at 10:19 AM, slurms--- via bitcoin-dev wrote: > * A random selection of blocks was downloaded from each peer. If the selection is different for each peer the results will be broken. ___ bitcoin-dev mailing list bitcoin-dev@lists.li

Re: [bitcoin-dev] Making Electrum more anonymous

Keep in mind this is the similar premise as claimed to be offered by BIP37 bloom filters, but faulty assumptions and implementation failure in BitcoinJ have meant that bloom filters uniquely identify the wallet and offer no privacy for the user no matter what the settings are. If you imagine a s

Re: [bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

It's worth noting that even massive companies with $30M USD of funding don't run a single Bitcoin Core node, which is somewhat against the general concept people present of companies having an incentive to run their own to protect their own wallet. > Sent: Friday, July 24, 2015 at 4:57 AM > F

Re: [bitcoin-dev] Bitcoin Node Speed Test

Yes that is completely doable for the next crawl, however I am not sure how much that reflects the behavior bitcoind would see when making connections. Nodes do not make any attempt to sync with close peers, which is an undesirable property if you are attempting to be sybil resistant. With some

[bitcoin-dev] Bitcoin Roadmap 2015, or "If We Do Nothing" Analysis

I used Google to establish that there is not already a post from 2015 that mentions "roadmap" in the subject line. Such would be a good skeleton for anyone new to the list (like me). 1. Increase the 7 Tx per second - by increasing block size. 2. Do something about the trend toward centralization

Re: [bitcoin-dev] Bitcoin Node Speed Test

On Thu, Jul 23, 2015 at 09:56:36PM +0200, Marcel Jamin wrote: > He measured the upload capacity of the peers by downloading from them, or > am I being dumb? :) Lol, no, I'm being dumb. :) -- 'peter'[:-1]@petertodd.org 0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d signature.a

Re: [bitcoin-dev] Bitcoin Node Speed Test

You may see much better throughput if you run a few servers around the globe and test based on closest-by-geoip. TCP throughput is rather significantly effected by latency, though I'm not really sure what you should be testing here, ideally. On 07/23/15 14:19, slurms--- via bitcoin-dev wrote: > On

Re: [bitcoin-dev] Process for BIP number allocation

On Thu, Jul 23, 2015 at 11:36:45PM +0200, Kalle Rosenbaum wrote: > A PoP-enabled fork of Mycelium is available at > https://github.com/kallerosenbaum/wallet and the server (validating > code) is available at https://github.com/kallerosenbaum/poppoc/ > > There's also a demo site using the server co

Re: [bitcoin-dev] Making Electrum more anonymous

I've looked at IT-PIR for Libbitcoin. It's certainly more elegant than onion routing for query privacy, but doesn't improve on the collusion problem. As a result the related directory problem would also remain. "This protocol sacrifices some level of privacy to gain robustness. Because of this we

[bitcoin-dev] Bitcoin, Perceptions, and Expectations

There is now a pull request to remove mention of "zero or low fees", "fast international payments", and "instant peer-to-peer transactions" from bitcoin.org. For those non-technical users who do not read source code, this may come across as the breaking of the social contract on what Bitcoin i

Re: [bitcoin-dev] Bitcoin Core and hard forks

I agree that the fewer the necessary parties the better - however, some entities are much better positioned to offer certain services on the network than others - and the fact we can trustlessly negotiate smart contracts with them is one of the most significant developments in the cryptospace -

Re: [bitcoin-dev] Bitcoin Core and hard forks

Miners could include their fee tiers in the coinbase, but this is obviously open to manipulation, with little recourse (unless they are a pool and miners move away because of it). In any event, I think that trying out a solution that is both simple and involves the least number of parties nece

Re: [bitcoin-dev] Bitcoin Core and hard forks

I think it’s pretty clear by now that the assumption that all nodes have pretty similar computational resources leads to very misplaced incentives. Ultimately, cryptocurrencies will allow direct outsourcing of computation, making it possible to distribute computational tasks in an economically s

Re: [bitcoin-dev] Bitcoin Core and hard forks

I suppose you can use a timelocked output that is spendable by anyone you could go somewhat in this direction…the thing is it still means the wallet must make fee estimations rather than being able to get a quick quote. > On Jul 23, 2015, at 6:25 PM, Jean-Paul Kogelman > wrote: > > I think im

Re: [bitcoin-dev] Bitcoin Core and hard forks

I think implicit QoS is far simpler to implement, requires less parties and is closer to what Bitcoin started out as: a peer-to-peer digital cash system, not a peer-to-let-me-handle-that-for-you-to-peer system. jp > On Jul 24, 2015, at 9:08 AM, Eric Lombrozo wrote: > > By using third parties

Re: [bitcoin-dev] BIP draft: Hardfork bit

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >I don't understand the situation here. Is the assumption of a group of >miners suddenly switching (for example, they realise that they didn't >intend to support the new rules)? Or they're economically rational miners, and a large difficulty decrea

Re: [bitcoin-dev] Bitcoin Core and hard forks

By using third parties separate from individual miners that do bidding on your behalf you get a mechanism that allows QoS guarantees and shifting the complexity and risk from the wallet with little computational resources to a service with abundance of them. Using timelocked contracts it’s possi

Re: [bitcoin-dev] Bitcoin Core and hard forks

There really isn't any need for a 3rd party here. Those "services" can just be the miners themselves. jp > On Jul 24, 2015, at 8:56 AM, Eric Lombrozo wrote: > > >> On Jul 23, 2015, at 5:45 PM, Jean-Paul Kogelman >> wrote: >> >> Quality of service as in: >> >>> X satoshi / kb = included i

Re: [bitcoin-dev] Bitcoin Core and hard forks

Doesn't matter. It's not going to be perfect given the block time variance among other factors but it's far more workable than guessing whether or not your transaction is going to end up in a block at all. jp > On Jul 24, 2015, at 8:53 AM, Peter Todd wrote: > > -BEGIN PGP SIGNED MESSAGE

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 5:45 PM, Jean-Paul Kogelman > wrote: > > Quality of service as in: > >> X satoshi / kb = included in block currently worked on; > >> Y satoshi / kb = included in next block; > >> Z satoshi / kb = included in block after that, etc. > > Block count starts when transactio

Re: [bitcoin-dev] Bitcoin Core and hard forks

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23 July 2015 20:49:20 GMT-04:00, Jean-Paul Kogelman via bitcoin-dev wrote: > >And it's obvious how a size cap would interfere with such a QoS scheme. >Miners wouldn't be able to deliver the below guarantees if they have to >start excluding tra

Re: [bitcoin-dev] Bitcoin Core and hard forks

And it's obvious how a size cap would interfere with such a QoS scheme. Miners wouldn't be able to deliver the below guarantees if they have to start excluding transactions. > On Jul 24, 2015, at 8:45 AM, Jean-Paul Kogelman via bitcoin-dev > wrote: > > Quality of service as in: > >> X sat

Re: [bitcoin-dev] Bitcoin Core and hard forks

Quality of service as in: > X satoshi / kb = included in block currently worked on; > Y satoshi / kb = included in next block; > Z satoshi / kb = included in block after that, etc. Block count starts when transaction is first seen. Miners can set X, Y, Z. Market develops when miners start set

Re: [bitcoin-dev] Bitcoin Core and hard forks

Are you referring to mining contracts? > On Jul 23, 2015, at 5:32 PM, Eric Lombrozo wrote: > > >> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman >> wrote: >> >> You are not going to get a fair fee market if your only form of enforcement >> is the threat of exclusion. >> >> A more fair fee

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 5:22 PM, Jean-Paul Kogelman > wrote: > > You are not going to get a fair fee market if your only form of enforcement > is the threat of exclusion. > > A more fair fee market will develop if miners start offering quality of > service, preferably at multiple tiers. At tha

Re: [bitcoin-dev] Bitcoin Core and hard forks

You are not going to get a fair fee market if your only form of enforcement is the threat of exclusion. A more fair fee market will develop if miners start offering quality of service, preferably at multiple tiers. At that point any interference from a block size cap will only be detrimental. I

Re: [bitcoin-dev] Bitcoin Core and hard forks

Increasing the block size does not hinder research and development of Lightning or other technologies. On 07/23/2015 05:04 PM, Eric Lombrozo via bitcoin-dev wrote: > I should also add that I think those who claim that fee pressure will > scare away users and break the industry are *seriously* und

Re: [bitcoin-dev] Bitcoin Core and hard forks

I should also add that I think those who claim that fee pressure will scare away users and break the industry are *seriously* underestimating human ingenuity in the face of a challenge. We can do this - we can overcome this obstacle…we can find good solutions to a fee market. Unless someone can

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 4:42 PM, Benedict Chan wrote: > > Scaling the network will come in the form of a combination of many > optimizations. Just because we do not know for sure how to eventually > serve 7 billion people does not mean we should make decisions on > global validation that impact ou

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 1:52 PM, Eric Lombrozo via bitcoin-dev wrote: > On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo wrote: >> >> Mainstream usage of cryptocurrency will be enabled primarily by direct >> party-to-party contract negotiation…with the use of the blockchain primarily >> as a disput

Re: [bitcoin-dev] Process for BIP number allocation

A PoP-enabled fork of Mycelium is available at https://github.com/kallerosenbaum/wallet and the server (validating code) is available at https://github.com/kallerosenbaum/poppoc/ There's also a demo site using the server code at http://www.rosenbaum.se:8080/ and a demo video at https://www.youtube

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

> Mike has sincerely said that he would like "Bitcoin Core to have a > benevolent dictator like other free software projects", and I wanted > to make clear that I wasn't putting words in his mouth He is just pointing out reality. Decentralization is really just a collection of centralized proces

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Thu, Jul 23, 2015 at 4:57 PM, Milly Bitcoin via bitcoin-dev wrote: > On 7/23/2015 10:30 AM, Jorge Timón via bitcoin-dev wrote: > >> [4] http://lmgtfy.com/?q=mike+hearn+dictator&l=1 Mike has sincerely said that he would like "Bitcoin Core to have a benevolent dictator like other free software p

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo > wrote: > Mainstream usage of cryptocurrency will be enabled primarily by direct > party-to-party contract negotiation…with the use of the blockchain primarily > as a dispute resolution mechanism. The block size isn’t

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 9:52 PM, Jameson Lopp via bitcoin-dev wrote: > Running a node certainly has real-world costs that shouldn't be ignored. > There are plenty of advocates who argue that Bitcoin should strive to keep > it feasible for the average user to run their own node (as opposed to > Sat

[bitcoin-dev] BIP Draft: Minimum Viable TXIn Hash

Please see the following draft BIP which should decrease the amount of bytes needed per transaction. This is very much a draft BIP, as the design space for this type of improvement is large. This BIP can be rolled out by a soft fork. Improvements are around 12% for standard "one in two out" txn,

Re: [bitcoin-dev] Bitcoin Node Speed Test

That is how I read it as well. On Thu, Jul 23, 2015 at 12:56 PM Marcel Jamin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > He measured the upload capacity of the peers by downloading from them, or > am I being dumb? :) > > > 2015-07-23 18:05 GMT+02:00 Peter Todd via bitcoin-d

Re: [bitcoin-dev] Bitcoin Node Speed Test

He measured the upload capacity of the peers by downloading from them, or am I being dumb? :) 2015-07-23 18:05 GMT+02:00 Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org>: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > > On 23 July 2015 10:19:59 GMT-04:00, slurms---

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo wrote: > > On Jul 23, 2015, at 11:10 AM, Jameson Lopp wrote: > > Larger block sizes don't scale the network, they merely increase how much > load we allow the network to bear. > > > Very well put, Jameson. And the cost of bearing this load must be p

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 12:35 PM, Gavin Andresen wrote: > > There are lots of things we can do to decrease costs, and a lot of things > have ALREADY been done (e.g. running a pruned full node). I also wanted to point out I fully agree with you that there are still many optimizations we could do

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 12:35 PM, Gavin Andresen wrote: > > > On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo > wrote: > Mainstream usage of cryptocurrency will be enabled primarily by direct > party-to-party contract negotiation…with the use of the blockchain primari

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 3:14 PM, Eric Lombrozo wrote: > Mainstream usage of cryptocurrency will be enabled primarily by direct > party-to-party contract negotiation…with the use of the blockchain > primarily as a dispute resolution mechanism. The block size isn’t about > scaling but about supply

Re: [bitcoin-dev] Process for BIP number allocation

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23 July 2015 06:21:55 GMT-04:00, Kalle Rosenbaum via bitcoin-dev wrote: >Hi all > >I suggest that we add to the "BIP Editor Responsibilities & Workflow" >section of BIP0001 that if the BIP editor for some reason won't handle >the BIP within a

Re: [bitcoin-dev] BIP draft: Hardfork bit

Quoting Tier Nolan via bitcoin-dev : On Thu, Jul 23, 2015 at 5:23 PM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: 2) Full nodes and SPV nodes following original consensus rules may not be aware of the deployment of a hardfork. They may stick to an economic-minority

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 11:10 AM, Jameson Lopp wrote: > > Larger block sizes don't scale the network, they merely increase how much > load we allow the network to bear. Very well put, Jameson. And the cost of bearing this load must be paid for. And unless we’re willing to accept that computatio

Re: [bitcoin-dev] Bitcoin Core and hard forks

> > You complained about the lack of quantitative analysis being used, I gave > it to you. There's nothing "negative" about displaying data which doesn't > completely back up what your position is, I made a sensible conclusion > based on the facts I have in front of me. Ignoring the information I >

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 7:14 PM, Robert Learney via bitcoin-dev wrote: > That’s not exactly what’s happened though, is it Cipher? Gavin put forward > 20Mb then after analysis and discussion has moved to 8Mb, whereas the other > camp of core developers is firmly stuck in the ‘1Mb or bust’ group. H

Re: [bitcoin-dev] Electrum Server Speed Test

That's purely the time on the wall for electrum-server, validation in bitcoind happens before. As ThomasV has pointed out it is significantly faster with a solid state disk (but much more expensive to operate), if we get to that point it'll only be expensive servers with lots of SSD space which

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 10:14 AM, Robert Learney via bitcoin-dev > wrote: > > That’s not exactly what’s happened though, is it Cipher? Gavin put forward > 20Mb then after analysis and discussion has moved to 8Mb, whereas the other > camp of core developers is firmly stuck in the ‘1Mb or bust’ g

Re: [bitcoin-dev] Electrum Server Speed Test

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Does "to process into the index" include time for transport and/or block validation (presumably by bitcoind) or this this exclusively the time for Electrum Server to index a validated block? e On 07/23/2015 08:56 AM, Slurms MacKenzie via bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core and hard forks

That’s not exactly what’s happened though, is it Cipher? Gavin put forward 20Mb then after analysis and discussion has moved to 8Mb, whereas the other camp of core developers is firmly stuck in the ‘1Mb or bust’ group. -Rob. > On 23 Jul 2015, at 17:50, cipher anthem via bitcoin-dev > wrote: >

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 1:42 AM, Cory Fields via bitcoin-dev wrote: > I'm not sure why Bitcoin Core and the rules and policies that it > enforces are being conflated in this thread. There's nothing stopping > us from adding the ability for the user to decide what their consensus > parameters shoul

Re: [bitcoin-dev] Bitcoin Core and hard forks

> Sent: Thursday, July 23, 2015 at 7:28 PM > From: "Gavin Andresen via bitcoin-dev" > To: "Tom Harding" > Cc: bitcoin-dev@lists.linuxfoundation.org > Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks > > I'm frankly tired of all the negativity here You complained about the lack of quantita

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 1:43 PM, Eric Lombrozo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > I'd really like to move from "IMPOSSIBLE because... (electrum hasn't

Re: [bitcoin-dev] BIP draft: Hardfork bit

On Thu, Jul 23, 2015 at 5:23 PM, jl2012 via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 2) Full nodes and SPV nodes following original consensus rules may not be > aware of the deployment of a hardfork. They may stick to an > economic-minority fork and unknowingly accept devalued

Re: [bitcoin-dev] Electrum Server Speed Test

There is some room for optimization in the Electrum server: - the utxo database (patricia tree) should be made a binary tree. - the server is written in python, which is slow. I am not too worried about the short-term; a block takes on average 15s to process on my server. For example, here are t

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 6:17 PM, Tom Harding via bitcoin-dev wrote: > On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote: > >> If the user expectation is that a price would never arise because >> supply is going to be increased ad infinitum and they will always be >> able to send fast in-chai

Re: [bitcoin-dev] Bitcoin Core and hard forks

> On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev > wrote: > > I'd really like to move from "IMPOSSIBLE because... (electrum hasn't been > optimized > (by the way: you should run on SSDs, LevelDB isn't designed for spinning > disks), > what if the network is attacked? (attacked

Re: [bitcoin-dev] Bitcoin Node Speed Test

This looks like the beginnings of some great analysis. Per Peter's remarks, I think it would be productive to run the test(s) on a simulated network with worst case network failure(s) so that we can determine the safety margin needed. I have potential access to h/w resources that would be availab

Re: [bitcoin-dev] Electrum Server Speed Test

I think our friendly original party worm is just trying to evaluate where we are currently so arguments can be based on data. I would tend to agree that there are performance improvements to be made and would rather do that work than limit the block size. On Thu, Jul 23, 2015 at 10:28 AM Matt

Re: [bitcoin-dev] Electrum Server Speed Test

Great data points, but isn't this an argument for improving Electrum Server's database performance, not for holding Bitcoin back? (Nice alias, by the way. Whimmy wham wham wozzle!) On Thursday, 23 July 2015, at 5:56 pm, Slurms MacKenzie via bitcoin-dev wrote: > Similar to the Bitcoin Node Speed

Re: [bitcoin-dev] Electrum Server Speed Test

I have concerns about the performance of the Electrum server software as well. It seems to load data one block at a time (which normally makes sense) and I think it is even single threaded on transactions inside the block. To try to addresses these issues, I made my own implementation of the elec

Re: [bitcoin-dev] Bitcoin Node Speed Test

The library used isn't open source, so unfortunately not. It shouldn't be too hard to replicate in python-bitcoinlib or bitcoinj though.   Sent: Thursday, July 23, 2015 at 6:55 PM From: "Jameson Lopp" To: slu...@gmx.us Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Bitcoin

Re: [bitcoin-dev] Bitcoin Node Speed Test

I was testing against otherwise idle nodes, fetching blocks back from the tip of the chain in an attempt to eliminate any unfair effects of caching. During the time my crawler was running there was no new blocks on the network (luck more than design), so other than initially syncing nodes and tran

Re: [bitcoin-dev] Bitcoin Core and hard forks

Why not help on a project that actually seems to offer great scalability like the lightning network? There have been great progress there.   Seems like you did your calculations some time ago to prove that your increase is reasonable, yet when others come with different numbers that don't suppor

Re: [bitcoin-dev] Bitcoin Node Speed Test

Thank you a lot for doing this test! Two questions: 1) A node is typically connected to many nodes that would all in parallel download said block. In your test you measured how fast new blocks that presumably are being uploaded in parallel to all those other nodes are being uploaded? Or did you d

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Thu, Jul 23, 2015 at 12:17 PM, Tom Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote: > > they will simply advance the front and start another battle, because > > their true hidden faction is the "not ever side". Pl

[bitcoin-dev] BIP draft: Hardfork bit

Please feel free to comment, for technical issues and language BIP: ?? Title: Hardfork bit Author: jl2012 Status: Draft Type: Standard Track Created: 2015-07-23 Abstract This document specifies a proposed change to the semantics of the most significant bit of the “version” field in Bitcoin b

Re: [bitcoin-dev] Bitcoin Core and hard forks

On 7/23/2015 5:17 AM, Jorge Timón via bitcoin-dev wrote: > If the user expectation is that a price would never arise because > supply is going to be increased ad infinitum and they will always be > able to send fast in-chain bitcoin transactions for free, just like > breath air (an abundant resour

Re: [bitcoin-dev] Bitcoin Node Speed Test

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23 July 2015 10:19:59 GMT-04:00, slurms--- via bitcoin-dev wrote: >This does not support the theory that the network has the available >bandwidth for increased block sizes, as in its current state 37% of >nodes would fail to upload a 20MB bloc

[bitcoin-dev] Electrum Server Speed Test

Similar to the Bitcoin Node Speed Test, this is a quick quantitative look at how the Electrum server software handles under load. The Electrum wallet is extremely popular, and the distributed servers which power it are all hosted by volunteers without budget. The server requires a fully indexed

Re: [bitcoin-dev] Bitcoin Node Speed Test

Are you willing to share the code that you used to run the test? - Jameson On Thu, Jul 23, 2015 at 10:19 AM, slurms--- via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On this day, the Bitcoin network was crawled and reachable nodes surveyed > to find their maximum throughput in

Re: [bitcoin-dev] For discussion: limit transaction size to mitigate CVE-2013-2292

On Mon, Jul 20, 2015 at 4:55 PM, Gregory Maxwell wrote: > On Mon, Jul 20, 2015 at 7:10 PM, Gavin Andresen via bitcoin-dev > wrote: > > Mitigate a potential CPU exhaustion denial-of-service attack by limiting > > the maximum size of a transaction included in a block. > > This seems like a fairly

Re: [bitcoin-dev] Bitcoin Node Speed Test

Ahh, data... a breath of fresh air... Can you re-analyze for 8MB blocks? There is no current proposal for 20MB blocks. Also, most hashing power is now using Matt Corallo's fast block propagation network; slow 'block' propagation to merchants/end-users doesn't really matter (as long as it doesn't

Re: [bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On 7/23/2015 10:30 AM, Jorge Timón via bitcoin-dev wrote: [4] http://lmgtfy.com/?q=mike+hearn+dictator&l=1 ___ You spend too much time on reddit. All this drama queen stuff is getting ridiculous. Russ __

[bitcoin-dev] Libconsensus separated repository (was Bitcoin Core and hard forks)

On Thu, Jul 23, 2015 at 2:49 AM, Eric Voskuil via bitcoin-dev wrote: > On 07/22/2015 05:13 PM, Eric Lombrozo via bitcoin-dev wrote: >> Only being partly serious - I strongly am in favor of a sufficiently > modularized codebase that swapping out consensus rules is fairly > straightforward and easy

[bitcoin-dev] Bitcoin Node Speed Test

On this day, the Bitcoin network was crawled and reachable nodes surveyed to find their maximum throughput in order to determine if it can safely support a faster block rate. Specifically this is an attempt to prove or disprove the common statement that 1MB blocks were only suitable slower inter

Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

Le 23/07/2015 11:48, Thomas Voegtlin via bitcoin-dev a écrit : > > One benefit of having an intermediate "_wallet" level is to allow zone > delegation. Is that the reason for that choice? > Thinking about it, I think that it would be better to separate those two operations: on one hand, the list

Re: [bitcoin-dev] Making Electrum more anonymous

This looks like a prime application for this PIR library: http://percy.sourceforge.net/apidocs/index.html Eric Voskuil via bitcoin-dev schrieb am Do., 23. Juli 2015 um 02:07 Uhr: > This is a good point. I didn't delve into the specifics of > implementation due to the larger issues that I raised.

Re: [bitcoin-dev] Bitcoin Core and hard forks

On Wed, Jul 22, 2015 at 8:24 PM, Jeff Garzik via bitcoin-dev wrote: > To the user, talk of a fee market is equivalent to talk about block size - > various opinions are tossed about, but it doesn't really impact them. Fees > have been low for 6 years. > > We see this with the actual data - no fee

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

Peter Todd, as discussed on IRC, I'm not opposed to median time, which has many of the properties nheight has, I'm just opposed to just using nTime which is what all "hardfork proposals" I've seen so far (including this one) do. On Wed, Jul 22, 2015 at 12:05 AM, Ross Nicoll wrote: > On 21/07/2015

Re: [bitcoin-dev] [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

Discussions about whether to get miner's confirmation on uncontroversial hardforks or not, and about whether to use nHeight, nMedianTime or just use nTime are spreading all around. Hopefully getting a BIP number (even though this is still a draft) will help concentrating discussions about deploymen

[bitcoin-dev] Process for BIP number allocation

Hi all I suggest that we add to the "BIP Editor Responsibilities & Workflow" section of BIP0001 that if the BIP editor for some reason won't handle the BIP within a week, he/she should notify the author within that same week with an estimate on when it will be handled. Maybe we could extend it to

Re: [bitcoin-dev] Proposal: extend bip70 with OpenAlias

Le 17/07/2015 03:01, Justin Newton via bitcoin-dev a écrit : >> 3> We use a 2 tier lookup format. [...] >> >> We do the same thing, except in a single call. [...] > > We looked at doing this in a single lookup as you did. With one or two > currencies this can be potentially more efficient. As

Re: [bitcoin-dev] Bitcoin Core and hard forks

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I've seen a lot of talk on this list debating the role of Bitcoin Core and its maintainers WRT consensus, typically focused around whether they can technically force anyone to run their code (of course, they can't.) I've yet to see the discussi

Re: [bitcoin-dev] Bitcoin Core and hard forks

The code so far is fairly limited in scope, essentially making it possible to change the values in consensus/params.h based on block height. The actual code to interpret those values does need to be provided ahead of time, of course, so there's still developer time to implement, it just moves c