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
>
> 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'
>
> 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
>
> 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
>
> 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
>
> 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
>
> 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
>
> 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
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
>
> 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.
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
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
>
> "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
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
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
>
> 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
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
>
> 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
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
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
>
> 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
> 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
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.
>
> 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
Sure, and you did indeed say that.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-developme
>
> 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: "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
>
> 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
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
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
>
> 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
>
> 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
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.
>
> (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
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
>
> 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
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
>
> 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
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
>
> 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
>
> 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
>
> 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
>
> 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
>
> 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
>
> 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
>
> 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
Cool, thanks.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
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)
--
___
>
> 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
>
> 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
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
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
>
> 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
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
>
> 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
>
> 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.
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
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/
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
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
>
> * 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
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
>
> 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
> 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
>
> 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
>
> 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
> 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
>
> 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
>
> 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
>
> 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
>
> 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
>
> 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
>
> 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
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
>
> 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
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
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
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
>
> 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
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
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
>
> 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
>
> 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.
-
>
> 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.
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
>
> 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
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
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
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'
>
> 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
>
> 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
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
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
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
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
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
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
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
>
> 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
>
> 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 - 100 of 877 matches
Mail list logo