Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread Mike Hearn
Hi Adam, I am still confused about whether you actually support an increase in the block size limit to happen right now. As you agree that this "layer 2" you speak of doesn't exist yet, and won't within the next 10-12 months (do you agree that actually?), can you please state clearly that you will

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

2015-06-19 Thread Mike Hearn
> > Mailman isn't resigning it. Should it be? Does other mailing list > software? > Mailman must take responsibility for the mail itself. It doesn't have to actually sign with DKIM to do so: for backwards compatibility, spam filters fall back to other heuristics to try and figure out the 'owner'

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

2015-06-19 Thread Mike Hearn
> > The new list currently has footers removed during testing. I am not > pleased with the need to remove the subject tag and footer to be more > compatible with DKIM users. > Lists can do what are effectively MITM attacks on people's messages in any way they like, if they resign for the messages

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread Mike Hearn
> > Yeah, but increasing block-size is not a longterm solution. Are you sure? That sort of statement is hard to answer because it doesn't say what you think long term is, or how much you expect Bitcoin to grow. Satoshi thought it was a perfectly fine long term solution because he thought hardwar

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

2015-06-19 Thread Mike Hearn
> > We already removed the footer because it was incompatible with DKIM > signing. Keeping the "[Bitcoin-dev] " prepend tag in subject is compatible > with DKIM header signing only if the poster manually prepends it in their > subject header. > I still see footers being added to this list by Sour

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread Mike Hearn
> > Or alternatively, fix the reasons why users would have negative > experiences with full blocks > It's impossible, Mark. *By definition* if Bitcoin does not have sufficient capacity for everyone's transactions, some users who were using it will be kicked out to make way for the others. Whether

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Mike Hearn
> > So then: make a proposal for a better process, post it to this list. > Alright. Here is a first cut of my proposal. It can be inserted into an amended BIP 1 after "What belongs in a successful BIP?". Let me know what you think. The following section applies to BIPs that affect the block cha

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Mike Hearn
> > If you think it's not clear enough, which may explain why you did not even > attempt to follow it for your block size increase, feel free to make > improvements. > As the outcome of a block size BIP would be a code change to Bitcoin Core, I cannot make improvements, only ask for them. Which is

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Mike Hearn
Hi Pieter, I believe Gavin plans to write a blog post about the hard fork process, but I'd like to debate this with you now, if only to give him material to work with :) Your points look to me like the hard/soft fork debate in different clothes. For example, we all agree that the rules of Bitcoi

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Mike Hearn
> > And allegations that the project is "run like wikipedia" or "an edit war" > are verifyably untrue. > Check the commit history. > This was a reference to a post by Gregory on Reddit where he said if Gavin were to do a pull request for the block size change and then merge it, he would revert it.

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Mike Hearn
OK, let's agree to unpack the two things. The first issue is how are decisions made in Bitcoin Core? I struggle to explain this to others because I don't understand it myself. Is it a vote of people with commit access? Is it a 100% agreement of "core developers" and if so, who are these people? Is

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Mike Hearn
Dude, calm down. I don't have commit access to Bitcoin Core and Gavin already said long ago he wouldn't just commit something, even though he has the ability to do so. So why did I say it? Because it's consistent with what I've always said: you cannot run a codebase like Wikipedia. Maintainers ha

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

2015-06-16 Thread Mike Hearn
> > "How do you plan to deal with security & incident response for the > duration you describe where you will have control while you are deploying > the unilateral hard-fork and being in sole maintainership control?" > How do we plan to deal with security & incident response - exactly the same way

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

2015-06-16 Thread Mike Hearn
Hi Bryan, Specifically, when Adam mentioned your conversations with non-technical > people, he did not mean "Mike has talked with people who have possibly not > made pull requests to Bitcoin Core, so therefore Mike is a non-programmer". > Yes, my comment was prickly and grumpy. No surprises, I di

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

2015-06-15 Thread Mike Hearn
Hi Adam, I replied publicly because your questions were sent to the mailing list. I'd have been happy to reply in private if so asked. I started to write up a much longer reply, but I'm tired - we've long since been going in circles. I feel like I've written down answers to almost all your questi

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

2015-06-15 Thread Mike Hearn
> > It's simple: either you care about validation, and you must validate > everything, or you don't, and you don't validate anything. > Pedantically: you could validate a random subset of all scripts, to give yourself probabilistic verification rather than full vs SPV. If enough people do it with a

Re: [Bitcoin-development] comments on BIP 100

2015-06-15 Thread Mike Hearn
dd something though! It means, amongst other things, I can switch of all my servers, walk away for good, discard this Mike Hearn pseudonym I invented for Bitcoin and the app will still work :) Surely that is an important part of being decentralised? It also means that as the underlying protocol evolves

Re: [Bitcoin-development] comments on BIP 100

2015-06-15 Thread Mike Hearn
> > Since you keep bringing this up, I'll try to clarify this once again. > I understand the arguments against it. And I think you are agreeing with me - Adam is bemoaning the way developers outsource stuff to third party services, and suggesting it is relevant to the block size debate. And we are

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

2015-06-15 Thread Mike Hearn
Bear in mind the problem that stops Jeff's messages getting through is that mailman 1.0 doesn't know how to handle DKIM properly. Switching to a different mailman provider won't fix that. Does mailman 3.0 even fix this? I found it difficult to tell from their website. There's a big page on the mai

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

2015-06-15 Thread Mike Hearn
Hi Adam, Provisional answers below! - Are you releasing a BIP for that proposal for review? > The work splits like this: - Gavin is writing the code and I think a BIP as well - I will review both and mostly delegate to Gavin's good taste around the details, unless there is some very s

Re: [Bitcoin-development] comments on BIP 100

2015-06-15 Thread Mike Hearn
> > That was probably insufficiently specific, let me rephrase: I am > referring to the trend that much of the industry is built on web2.0 > technology using bitcoin via a library in a web scripting language OK, good to hear that. I'm not happy about the use of web technologies in wallets/service

Re: [Bitcoin-development] comments on BIP 100

2015-06-15 Thread Mike Hearn
> StrawPay hasn't published any details of their work publicly; if they > wanted credit on the mailing list they should have done that. > There's a brief discussion here: https://www.reddit.com/r/Bitcoin/comments/2r3ri7/strawpay_cheap_and_secure_micropayments/ But yes, they are developing it be

Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-14 Thread Mike Hearn
On Sun, Jun 14, 2015 at 4:42 PM, Jeff Garzik wrote: > Since you missed it, here is the suggestion again: > http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf > Reposting as Jeff's mail got eaten by the anti-phishing filters, due to SourceForge's obsolete mailman setup.

Re: [Bitcoin-development] comments on BIP 100

2015-06-14 Thread Mike Hearn
> > One thing that is concerning is that few in industry seem inclined to > take any development initiatives or even integrate a library. Um, you mean except all the people who have built more scalable wallets over the past few years, which is the only reason anyone can even use Bitcoin from thei

Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed

2015-06-12 Thread Mike Hearn
Sure, and you did indeed say that. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-developme

Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed

2015-06-12 Thread Mike Hearn
> > are only connected to each other through a slow 2 Mbit/s link. > That's very slow indeed. For comparison, plain old 3G connections routinely cruise around 7-8 Mbit/sec. So this simulation is assuming a speed dramatically worse than a mobile phone can get! -

Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism

2015-06-11 Thread Mike Hearn
> > > Re: "dropped in an unpredictable way" - transactions would be dropped > > lowest fee/KB first, a completely predictable way. > > Quite agreed. No, Aaron is correct. It's unpredictable from the perspective of the user sending the transaction, and as they are the ones picking the fees, that i

Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism

2015-06-11 Thread Mike Hearn
> > If we assume that transactions are being dropped in an unpredictable way > when blocks are full, knowing the network congestion *right now* is > critical, and even then you just have to hope that someone who wants that > space more than you do doesn't show up after you disconnect. > Yeah, my p

Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism

2015-06-10 Thread Mike Hearn
I described an alternative way for SPV wallets to learn about fees some time ago. It requires a new transaction version that embeds output values into the signed data. Then an upgrade to the P2P protocol to send UTXO data along with transactions when they are relayed. The idea is that the wallet s

Re: [Bitcoin-development] DevCore London

2015-06-02 Thread Mike Hearn
ds it enjoyable! On Thu, Apr 9, 2015 at 10:23 PM, Mike Hearn wrote: > Next week on April 15th Gavin, Wladimir, Corey and myself will be at > DevCore London: > >https://everyeventgives.com/event/devcore-london > > If you're in town why not come along? > > It's of

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements‏

2015-06-02 Thread Mike Hearn
> > But the majority of the hashrate can now perform double spends on your > chain! They can send bitcoins to exchanges, sell it, extract the money and > build a new longer chain to get their bitcoins back. > Obviously if the majority of the mining hash rate is doing double spending attacks on exch

Re: [Bitcoin-development] Proposed alternatives to the 20MB step

2015-06-02 Thread Mike Hearn
> > 1,000 *people* in control vs. 10 is two orders of magnitude more decentralized. Yet Bitcoin has got worse by all these metrics: there was a time before mining pools when there were ~thousands of people mining with their local CPUs and GPUs. Now the number of full nodes that matter for block

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

2015-06-01 Thread Mike Hearn
I don't see this as an issue of sensitivity or not. Miners are businesses that sell a service to Bitcoin users - the service of ordering transactions chronologically. They aren't charities. If some miners can't provide the service Bitcoin users need any more, then OK, they should not/cannot mine.

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

2015-06-01 Thread Mike Hearn
> > (at reduced security if it has software that doesnt understand it) Well, yes. Isn't that rather key to the issue? Whereas by simply increasing the block size, SPV wallets don't care (same security and protocol as before) and fully validating wallets can be updated with a very small code chan

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

2015-06-01 Thread Mike Hearn
Hi Adam, I have more experience than Gavin of building consumer wallets, so I'll make an attempt to answer your questions. > Then ask the various wallet developer how long it would take them to > update > > their software to support something like this, > > I don't think thats any particular conc

Re: [Bitcoin-development] Proposed alternatives to the 20MB step

2015-06-01 Thread Mike Hearn
> > It's surprising to see a core dev going to the public to defend a proposal > most other core devs disagree on, and then lobbying the Bitcoin ecosystem. > I agree that it is a waste of time. Many agree. The Bitcoin ecosystem doesn't really need lobbying - my experience from talking to businesse

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

2015-06-01 Thread Mike Hearn
I'm OK with a smaller size + a formula that ramps it up over time. We are far from having enough demand to fill 10MB blocks, let alone 20MB today. To put it in perspective, to be feeling squeezed inside 10MB within two years, we would need to double usage five times. I wish I knew a way to make th

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

2015-06-01 Thread Mike Hearn
> > Ignorant. You seem do not understand the current situation. We > suffered from orphans a lot when we started in 2013. It is now your > turn. Then please enlighten me. You're unable to download block templates from a trusted node outside of the country because the bandwidth requirements are to

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

2015-06-01 Thread Mike Hearn
Whilst it would be nice if miners in China can carry on forever regardless of their internet situation, nobody has any inherent "right" to mine if they can't do the job - if miners in China can't get the trivial amounts of bandwidth required through their firewall and end up being outcompeted then

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-29 Thread Mike Hearn
> > And looking at the version (aka user-agent) strings of publicly reachable > nodes on the network. > (e.g. see the count at https://getaddr.bitnodes.io/nodes/ ) > Yeah, though FYI Luke informed me last week that I somehow managed to take out the change to the user-agent string in Bitcoin XT, p

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-29 Thread Mike Hearn
> > The measure is miner consensus. How do you intend to measure > exchange/merchant acceptance? > Asking them. In fact, we already have. I have been talking to well known people and CEOs in the Bitcoin community for some time now. *All* of them support bigger blocks, this includes: - Every

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-29 Thread Mike Hearn
> > If the plan is a fix once and for all, then that should be changed too. > It could be set so that it is at least some multiple of the max block size > allowed. > Well, but RAM is not infinite :-) Effectively what these caps are doing is setting the minimum hardware requirements for running a B

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-29 Thread Mike Hearn
> > By the time a hard fork can happen, I expect average block size will be > above 500K. > Yes, possibly. > Would you support a rule that was "larger of 1MB or 2x average size" ? > That is strictly better than the situation we're in today. > It is, but only by a trivial amount - hitting the li

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-28 Thread Mike Hearn
> > Twenty is scary. > To whom? The only justification for the max size is DoS attacks, right? Back when Bitcoin had an average block size of 10kb, the max block size was 100x the average. Things worked fine, nobody was scared. The max block size is really a limit set by hardware capability, whic

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-28 Thread Mike Hearn
> > Even a 2x rule (implying 800K max blocks) would, today, be squeezing out > transactions / putting pressure to increase fees . > > So my straw-man proposal would be: max size 2x average size over last 144 > blocks, calculated at every block. > Isn't that a step backwards, then? I see no re

Re: [Bitcoin-development] Long-term mining incentives

2015-05-28 Thread Mike Hearn
> > The prior (and seemingly this) assurance contract proposals pay the > miners who mines a chain supportive of your interests and miners whom > mine against your interests identically. > The same is true today - via inflation I pay for blocks regardless of whether they contain or double spend my

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

2015-05-28 Thread Mike Hearn
Cool, thanks. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Long-term mining incentives

2015-05-27 Thread Mike Hearn
I wrote an article that explains the hashing assurance contract concept: https://medium.com/@octskyward/hashing-7d04a887acc8 (it doesn't contain an in depth protocol description) -- ___

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

2015-05-27 Thread Mike Hearn
> > Mike, this proposal was purposefully constructed to maintain as well as > possible the semantics of Satoshi's original construction. Higher sequence > numbers -- chronologically later transactions -- are able to hit the chain > earlier, and therefore it can be reasonably argued will be selected

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

2015-05-27 Thread Mike Hearn
> > Sequence numbers appear to have been originally intended as a mechanism > for transaction replacement within the context of multi-party transaction > construction, e.g. a micropayment channel. > Yes indeed they were. Satoshis mechanism was more general than micropayment channels and could do H

Re: [Bitcoin-development] Zero-Conf for Full Node Discovery

2015-05-26 Thread Mike Hearn
Very interesting Matt. For what it's worth, in future bitcoinj is very likely to bootstrap from Cartographer nodes (signed HTTP) rather than DNS, and we're also steadily working towards Tor by default. So this approach will probably stop working at some point. As breaking PorcFest would kind of su

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-25 Thread Mike Hearn
CPFP also solves it just fine. -- 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

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-25 Thread Mike Hearn
> > If it matters, I configure the app to connect only to my own trusted > Bitcoin node, so I only ever have one active connection at most. Ah, I see, non default configuration. Because the Bitcoin network can and does change in backwards incompatible ways, the app wants to see that the transacti

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-25 Thread Mike Hearn
Wallets are incentivised to do a better job with defragmentation already, as if you have lots of tiny UTXOs then your fees end up being huge when trying to make a payment. The reason they largely don't is just one of manpower. Nobody is working on it. As a wallet developer myself, one way I'd lik

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-25 Thread Mike Hearn
> > some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you > can only spend confirmed UTXOs. I can't tell you how aggravating it is to > have to tell a friend, "Oh, oops, I can't pay you yet. I have to wait for > the last transaction I did to confirm first." All the more aggrava

Re: [Bitcoin-development] No Bitcoin For You

2015-05-25 Thread Mike Hearn
> > If capacity grows, fewer individuals would be able to run full nodes. > Hardly. Nobody is currently exhausting the CPU capacity of even a normal computer currently and even if we did a 20x increase in load overnight, that still wouldn't even warm up most machines good enough to be always on.

Re: [Bitcoin-development] Long-term mining incentives

2015-05-25 Thread Mike Hearn
Hi Thomas, My problem is that this seems to lacks a vision. > Are you aware of my proposal for network assurance contracts? There is a discussion here: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07552.html But I agree with Gavin that attempting to plan for 20 ye

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

2015-05-25 Thread Mike Hearn
Hi Andrew, Your belief that Bitcoin has to be constrained by the belief that hardware will never improve is extremist, but regardless, your concerns are easy to assuage: there is no requirement that the block chain be stored on hard disks. As you note yourself the block chain is used for building/

Re: [Bitcoin-development] Virtual Notary.

2015-05-25 Thread Mike Hearn
Very nice Emin! This could be very useful as a building block for oracle based services. If only there were opcodes for working with X.509 ;) I'd suggest at least documenting in the FAQ how to extract the data from the certificate: openssl pkcs12 -in virtual-notary-cert-stocks-16070.p12 -nodes -p

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-08 Thread Mike Hearn
There are certainly arguments to be made for and against all of these proposals. The fixed 20mb cap isn't actually my proposal at all, it is from Gavin. I am supporting it because anything is better than nothing. Gavin originally proposed the block size be a function of time. That got dropped, I s

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-08 Thread Mike Hearn
> > * Though there are many proposals floating around which could > significantly decrease block propagation latency, none of them are > implemented today. With a 20mb cap, miners still have the option of the soft limit. I would actually be quite surprised if there were no point along the road

Re: [Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

2015-05-08 Thread Mike Hearn
Looks like a neat solution, Tier. -- 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

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Mike Hearn
> > Alan argues that 7 tps is a couple orders of magnitude too low By the way, just to clear this up - the real limit at the moment is more like 3 tps, not 7. The 7 transactions/second figure comes from calculations I did years ago, in 2011. I did them a few months before the "sendmany" command

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
> These statements may even be true, but they're no logical conclusions > even if they seem obvious to you. > I don't think those claims are strictly true, specially because they > involve predictions about what people will do. > But if they're true they require some proof or at least some explanat

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
> > The appropriate method of doing any fork, that we seem to have been > following for a long time, is to get consensus here and on IRC and on > github and *then* go pitch to the general public So your concern is just about the ordering and process of things, and not about the change itself? I

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
> > I think you are rubbing against your own presupposition that people must > find and alternative right now. Quite a lot here do not believe there is > any urgency, nor that there is an immanent problem that has to be solved > before the sky falls in. > I have explained why I believe there is so

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
> The only answer to this that anyone with a clue should give is "it > will very, very likely be able to support at least 1MB blocks roughly > every 10 minutes on average for the next eleven years, and it seems > likely that a block size increase of some form will happen at some point in > the next

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
> > Dear list, > > Apparently my emails are being marked as spam, despite being sent from > GMail's web interface. I've pinged our sysadmin. It's a problem with the mailing list software, not your setup. BitPay could disable the phishing protections but that seems like a poor solution. The only

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
> > It is an argument against my admittedly vague definition of > "non-controversial change". > If it's an argument against something you said, it's not a straw man, right ;) Consensus has to be defined as agreement between a group of people. Who are those people? If you don't know, it's impossib

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
> > It is a trivial *code* change. It is not a trivial change to the > economics of a $3.2B system. > Hmm - again I'd argue the opposite. Up until now Bitcoin has been unconstrained by the hard block size limit. If we raise it, Bitcoin will continue to be unconstrained by it. That's the default

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
> > What gives Bitcoin value aren't its technical merits but the fact that > people believe in it. > Much of the belief in Bitcoin is that it has a bright future. Certainly the huge price spikes we've seen were not triggered by equally large spikes in usage - it's speculation on that future. I qu

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
> > If his explanation was "I will change my mind after we increase block > size", I guess the community should say "then we will just ignore your > nack because it makes no sense". > Oh good! We can just kick anyone out of the consensus process if we think they make no sense. I guess that means

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
> > Can you please elaborate on what terrible things will happen if we > don't increase the block size by winter this year? > I was referring to winter next year. 0.12 isn't scheduled until the end of the year, according to Wladimir. I explained where this figure comes from in this article: https

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Mike Hearn
Hey Matt, OK, let's get started However, there hasnt been any discussion on this > mailing list in several years as far as I can tell. > Probably because this list is not a good place for making progress or reaching decisions. Those are triggered by pull requests (sometimes). If you're won

Re: [Bitcoin-development] Reusable payment codes

2015-04-27 Thread Mike Hearn
> > 1. There will be a 1:1 relationship between a payment code owner and their > identity. > Bear in mind, the spec defines "identity" to mean: *Identity is a particular extended public/private key pair. * So that's not quite what is meant normally by identity. It's not a government / real

Re: [Bitcoin-development] Fwd: Reusable payment codes

2015-04-26 Thread Mike Hearn
Could you maybe write a short bit of text comparing this approach to extending BIP70 and combining it with a simple Subspace style store-and-forward network? -- One dashboard for servers and applications across Physical-Vir

Re: [Bitcoin-development] Where do I start?

2015-04-16 Thread Mike Hearn
Hey Gabe, That's diving into the deep end for sure! :) > What are some current things that are lacking in Bitcoin core? Or am I > better off making something else for the ecosystem? > That depends on your interests. Many of the highest priority tasks in Bitcoin Core are rather complicated, unfor

[Bitcoin-development] DevCore London

2015-04-09 Thread Mike Hearn
Next week on April 15th Gavin, Wladimir, Corey and myself will be at DevCore London: https://everyeventgives.com/event/devcore-london If you're in town why not come along? It's often the case that conferences can be just talking shops, without much meat for real developers. So in the afternoo

Re: [Bitcoin-development] Build your own nHashType

2015-04-09 Thread Mike Hearn
> > I don't think it's quite a blank check, but it would enable replay attacks > in the form of sending the money to the same place it was sent before if an > address ever receives coins again. > Right, good point. I wonder if this sort of auto forwarding could even be a useful feature. I can't th

Re: [Bitcoin-development] Build your own nHashType

2015-04-09 Thread Mike Hearn
Hi Stephen, It's an interesting idea. I'm not sure that all the combinations make sense. Excluding the connected output script or value but still signing the prev tx hash appears pointless: the script cannot change anyway, and you still need to know what it is to actually calculate the inputs to i

[Bitcoin-development] Double spending and replace by fee

2015-03-28 Thread Mike Hearn
I've written a couple of blog posts on replace by fee and double spending mitigations. They sum up the last few years (!) worth of discussions on this list and elsewhere, from my own perspective. I make no claim to be comprehensive or unbiased but I keep being asked about these topics so figured I

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

2015-03-13 Thread Mike Hearn
> > Don't SPV clients announce their intentions by the act of uploading a > filter? > Well they don't set NODE_NETWORK, so they don't claim to be providing network services. But then I guess the Chainalysis nodes could easily just clear that bit flag too. > What I'd actually like to see is for n

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

2015-03-13 Thread Mike Hearn
> > I'm not talking about keeping logs, I mean purporting to be a network > peer in order to gain a connection slot and then not behaving as one > (not relaying transactions) That definition would include all SPV clients? I get what you are trying to do. It just seems extremely tricky. -

Re: [Bitcoin-development] Proof of Payment

2015-03-13 Thread Mike Hearn
> > As soon as that PaymentRequest leaves the wallet on its way to the hotel > server, it is up for grabs > Is it? I'm assuming TLS is being used here. And the hotel server also has a copy of the PaymentRequest, as the hotel actually issued it and that's how they're deciding the receipt is valid.

Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups

2015-03-13 Thread Mike Hearn
That would be rather new and tricky legal territory. But even putting the legal issues to one side, there are definitional issues. For instance if the Chainalysis nodes started following the protocol specs better and became just regular nodes that happen to keep logs, would that still be a violat

Re: [Bitcoin-development] BIP32 Index Randomisation

2015-03-13 Thread Mike Hearn
> > You are killing us Mike! :) We really don't like to think that BWS is > a webwallet. Note > that private keys are not stored (not even encrypted) at the server. Sure, sorry, by web wallet I meant a blockchain.info/CoPay type setup where the client has the private keys and signs txns, but othe

Re: [Bitcoin-development] Proof of Payment

2015-03-13 Thread Mike Hearn
Hi Kalle, I think you're thinking along the right lines, but I am skeptical that this protocol adds much. A saved payment request is meant to be unique per transaction e.g. because the destination address is unique for that payment (for privacy reasons). Where would you store the signed payment re

Re: [Bitcoin-development] BIP32 Index Randomisation

2015-03-13 Thread Mike Hearn
It sounds like the main issue is this is a web wallet server of some kind. If the clients were SPV then they'd be checking their own balances and downloading their own tx history, which would mean the coordination tasks could be done by storing encrypted blobs on the server rather than the server i

Re: [Bitcoin-development] BIP32 Index Randomisation

2015-03-13 Thread Mike Hearn
Hey Matias, We are working on bitcore-wallet-server (BWS), a HD multisig wallet > 'facilitator'. > Currently the BWS instances hold the set of extended public keys of the > wallet's peers to be able to derive addresses. > Could you describe what exactly BWS does? It sounds like the server doesn'

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-12 Thread Mike Hearn
> > b) "Creation date" is just a short-term hack. > I agree, but we need things to be easy in the short term as well as the long term :) The long term solution is clearly to have the 12 word seed be an encryption key for a wallet backup with all associated metadata. We're heading in that directio

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-11 Thread Mike Hearn
> > I'd like to offer that the best practice for the shared wallet use case > should be multi-device multi-sig. Sure. But in practice people will want to have a pool of spending money that they can spend when they are out and about, and also with one click from their web browser on their primary

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-11 Thread Mike Hearn
Users will want to have wallets shared between devices, it's as simple as that, especially for mobile/desktop wallets. Trying to stop them from doing that by making things gratuitously incompatible isn't the right approach: they'll just find workarounds or wallet apps will learn how to import seed

Re: [Bitcoin-development] BIP for standard multi-signature P2SH addresses

2015-03-11 Thread Mike Hearn
bitcoinj also uses this convention. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software d

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-11 Thread Mike Hearn
Sigh. The wallet words system is turning into kind of a mess. I thought the word list is in fact not a fixed part of the spec, because the entropy is a hash of the words. But perhaps I'm misunderstanding something. The main problem regular SPV wallets have with BIP39 is that there is no birth tim

Re: [Bitcoin-development] New paper: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies

2015-03-04 Thread Mike Hearn
Nice, Andrew. Just one minor point. SPV clients do not need to maintain an ever growing list of PoW solutions. BitcoinJ uses a ring buffer with 5000 headers and thus has O(1) disk usage. Re-orgs past the event horizon cannot be processed but are assumed to be sufficiently rare that manual interven

Re: [Bitcoin-development] Electrum 2.0 has been tagged

2015-03-02 Thread Mike Hearn
Congrats Thomas! Glad to see Electrum 2 finally launch. > * New seed derivation method (not compatible with BIP39). Does this mean a "12 words" wallet created by Electrum won't work if imported into some other wallet that supports BIP39? Vice versa? This seems unfortunate. I guess if seeds are

Re: [Bitcoin-development] Providing Payment Request within URI

2015-02-25 Thread Mike Hearn
Andreas' wallet supports this, but don't do it. Payment requests can get larger in future even without signing. Exploding the capacity of a QR code is very easy. Instead, take a look at the Bluetooth/NFC discussion happening in a different thread. On Tue, Feb 24, 2015 at 4:58 PM, Oleg Andreev wr

Re: [Bitcoin-development] Request for comments on hybrid PoW/PoS enhancement for Bitcoin

2015-02-25 Thread Mike Hearn
Hi Chris, Just FYI you may not have received much feedback on this because Gmail put it into the spam folder for some reason. So I'm guessing a lot of people didn't see it. My main feedback is - I do not really see how this is different from actual mining. Mining also incentives the running of fu

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-25 Thread Mike Hearn
> > Does this not also require the BT publication of the script for a P2SH > address? You mean if the URI you're serving is like this? bitcoin:3aBcD?bt= Yes it would. I guess then, the server would indicate both the script, and the key within that script that it wanted to use. A

Re: [Bitcoin-development] Bitcoin at POS using BIP70, NFC and offline payments - implementer feedback

2015-02-23 Thread Mike Hearn
> > I don't see how you propose to treat the bitcoin address as a secp256k1 > public key, or do you mean something else? > Sorry, I skipped a step. I shouldn't make assumptions about what's obvious. The server would provide the public key and the client would convert it to address form then match

  1   2   3   4   5   6   7   8   9   >