-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 8 August 2015 02:27:35 GMT-04:00, Hector Chu via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Has there ever been any discussion of locking coins till a certain date
for
casting votes on an issue?
Yes, John Dillon proposed a very
On Wed, Aug 19, 2015 at 10:22:32AM -0700, Simon Liu via bitcoin-dev wrote:
Olivier Janssens claims that one of your colleagues is asking for Gavin
to be removed from his position. Is this true?
On Tue, Aug 18, 2015 at 06:36:45PM -0700, Peter Todd via bitcoin-dev wrote:
is false. However, in the common scenario of a firewalled node, where
the operator has neglected to explicitly set -listen=0, the code does
still download the Tor exit node list, revealing the true location of
the node
On Wed, Aug 19, 2015 at 03:45:48PM -0700, Adam Back via bitcoin-dev wrote:
Wouldnt the experience for SPV nodes be chaotic? If the full nodes
are 50:50 XT and bitcoin core, then SPV clients would connect at
random and because XT and core will diverge immediately after
activation.
Actually
On Fri, Aug 21, 2015 at 06:15:16PM -0400, Chris Pacia wrote:
On Aug 21, 2015 2:07 AM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Also, as I mentioned, just look at the popularity of wallets such as
Mycelium that are not adopting bloom filters, but going
On Fri, Aug 21, 2015 at 05:55:58PM +, Matt Corallo wrote:
Revised copy follows. re: mentioning the HTTP seeding stuff, I'm not
sure we want to encourage more people aside from bitcoinj to use
that...I thought about adding a DNS seed section to this bip, but
decided against it...still, I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 21 August 2015 20:21:22 GMT-07:00, Jorge Timón jti...@jtimon.cc wrote:
Don't you mean profits instead of revenue?
Actually no. I thought revenue would be a less subjective question to ask, with
more focus on the underlying orphan rate
On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote:
On 8/21/2015 3:21 PM, Peter Todd wrote:
To use a car analogy, Pieter Wuille has shown that the brake cylinders
have a fatigue problem, and if used in stop-and-go traffic regularly
they'll fail during heavy braking, potentially
On Sat, Aug 22, 2015 at 01:08:13AM +, Matt Corallo wrote:
Well actually, we can reference the DoS attacks that Bitcoin XT nodes
are undergoing right now - part of the attack is repeated Bloom filter
requests to soak up disk IO bandwidth. I've CC'd Gavin and Mike - as far
as I know they
On Thu, Aug 20, 2015 at 11:00:14AM +0200, Mike Hearn via bitcoin-dev wrote:
It is just that no one else is reckless enough to bypass the review process
I keep seeing this notion crop up.
I want to kill this idea right now:
- There were months of public discussion leading to up
On Fri, Aug 21, 2015 at 02:01:06AM -0400, Jeff Garzik wrote:
I don't see any link to data backing up Bloom filter usage has declined
significantly
Is there actual data showing this feature's use is declining or
non-existent?
I run a number of high speed nodes and while I don't have
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 20 August 2015 21:45:23 GMT-07:00, Gregory Maxwell via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I think this is a bit well, sad, at the moment-- a basic principle in
sound decision making is that one should try to withhold
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 21 August 2015 02:31:51 GMT-07:00, Btc Drak btcd...@gmail.com wrote:
On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
What might be valuable is to ask devs to explain what their threat
On Fri, Aug 21, 2015 at 01:48:23AM -0400, Jeff Garzik via bitcoin-dev wrote:
If this is widely deployed + enabled, what is the impact to current wallets
in use?
See my comment on the recently-opened issue, reproduced below. In short,
not all that much, especially if we adopt my suggestion of
On Fri, Aug 21, 2015 at 04:46:17AM +, Matt Corallo wrote:
Peter: Since I stole most of this text from your old BIP, should I leave
you as an author?
That's fine by me.
BIP: ?
Title: NODE_BLOOM service bit
Author: Matt Corallo b...@bluematt.me, Peter Todd p...@petertodd.org
Type:
On Tue, Aug 18, 2015 at 09:08:01PM -0400, Christophe Biocca via bitcoin-dev
wrote:
So I checked, and the code described *does not* run when behind a
proxy of any kind, including tor:
Deployment of the proposed CLTV, CSV, etc. soft-forks has been recently
complicated by the existence of XT(1) and Not-Bitcoin-XT(2) miners. Both
mine blocks with nVersion=0x2007, which would falsely trigger the
previously suggested implementation using the IsSuperMajority()
mechanism and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 17 August 2015 07:49:21 GMT-07:00, BitMinter operator via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I don't think mining pools will immediately make blocks as big as
possible if the hard limit is raised.
Note that XT includes a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The fun thing about this, is you only need 25% of hashing power running
Not-BitcoinXT to screw over the miners running XT, as XT blocks are valid
Bitcoin blocks if they're on a valid Bitcoin chain.
75% upgrade thresholds have a lot of issues...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 16 August 2015 17:03:35 GMT-07:00, Cameron Garnham via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
There are a few ways: here is my favorite (for the moment).
1. Spam the 8mb blocks with 1 Satoshi outputs to the brainwallet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 6 August 2015 10:21:54 GMT-04:00, Gavin Andresen via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On Thu, Aug 6, 2015 at 10:06 AM, Pieter Wuille
pieter.wui...@gmail.com
wrote:
But you seem to consider that a bad thing. Maybe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 4 August 2015 17:30:28 GMT-04:00, Gavin Andresen via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On Tue, Aug 4, 2015 at 2:41 PM, Dave Hudson via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
Fundamentally a block
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 4 August 2015 16:02:53 GMT-04:00, Jorge Timón via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
One thing I've noticed there seems to be disagreement on is whether
miners' upgrade confirmation (aka voting) is necessary for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 4 August 2015 14:41:53 GMT-04:00, Dave Hudson via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
The paper is nicely done, but I'm concerned that there's a real problem
with equation 4. The orphan rate is not just a function of time;
On Wed, Jul 22, 2015 at 12:52:20PM -0400, Pieter Wuille via bitcoin-dev wrote:
Hello all,
I'd like to talk a bit about my view on the relation between the Bitcoin
Core project, and the consensus rules of Bitcoin.
I believe it is the responsibility of the maintainers/developers of Bitcoin
On Fri, Jul 24, 2015 at 07:09:13AM -0700, Adam Back via bitcoin-dev wrote:
(Claim of large bitcoin ecosystem companies without full nodes) this
says to me rather we have a need for education: I run a full node
myself (intermittently), just for my puny collection of bitcoins. If
I ran a
On Fri, Jul 24, 2015 at 03:39:08PM +0200, Thomas Zander via bitcoin-dev wrote:
On Friday 24. July 2015 05.37.30 Slurms MacKenzie via bitcoin-dev wrote:
It's worth noting that even massive companies with $30M USD of funding don't
run a single Bitcoin Core node,
I assume you mean that they
, Jeff Garzik jgar...@gmail.com wrote:
On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I don't agree with you at all.
This is a case where if Jeff doesn't understand that issue, he's
proposing changes that he's not competent enough
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 23 July 2015 10:19:59 GMT-04:00, slurms--- via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org 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
On Wed, Jul 15, 2015 at 05:08:05PM -0700, Matthieu Riou via bitcoin-dev wrote:
On Wed, Jul 15, 2015 at 12:32 PM, Peter Todd p...@petertodd.org wrote:
In a Sybil attack the attacker subverts the reputation system of a
peer-to-peer network by creating a large number of pseudonymous
On Tue, Jul 21, 2015 at 11:26:35AM +0200, Jorge Timón via bitcoin-dev wrote:
I still disagree. Using height instead of time may make the
implementation more complex by requiring some additional preparations
but using height is in fact a simpler design. Why relay on clocks that
we know will
On Thu, Oct 22, 2015 at 03:58:58PM -0500, Justus Ranvier via bitcoin-dev wrote:
> On 22/10/15 15:43, Luke Dashjr wrote:
> > BIPs should in general not be
> > designed around current software
>
> I strongly disagree with this statement.
>
> There is a version byte in the payment code
Summary
---
Opt-In Full-RBF allows senders to opt-into full-RBF semantics for their
transactions in a way that allows receivers to detect if the sender has
done so. Existing "first-seen" mempool semantics are left unchanged for
transactions that do not opt-in.
At last week's IRC meeting(1)
On Sat, Nov 14, 2015 at 03:27:49PM -0800, Peter Tschipper via bitcoin-dev wrote:
> I'd like to use service bit 28 for testing the block compression
> prototype unless anyone has any objections or is using it already.
Go for it!
AFAIK the only testing service bit in use right now is bit 26, used
On Tue, Nov 03, 2015 at 09:44:02PM +, Christian Decker via bitcoin-dev
wrote:
> Ok, so assuming we can get a connected component of upgraded nodes that
> relay both the transaction and the associated external scripts then we
> could just piggyback the external scripts on top of the normal
On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote:
> BIP68 and BIP112 collectively define the CHECKSEQUENCEVERIFY semantics,
Another issue that came to mind re: CSV review is that there isn't
actually any one pull-req with all the code changes together, making it
h
On Tue, Oct 06, 2015 at 12:28:49PM +1030, Rusty Russell wrote:
> Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> writes:
> > However I don't think we've done a good job showing why we need to
> > implement this feature via nSequence.
>
> It coul
On Wed, Oct 07, 2015 at 05:19:29PM +0700, Venzen Khaosan via bitcoin-dev wrote:
> Mike Hearn,
>
> I challenge you to a public debate with the following conditions:
This is very off-topic for a development mailing list.
Go away.
--
'peter'[:-1]@petertodd.org
On Thu, Aug 27, 2015 at 11:08:32PM +0100, Btc Drak wrote:
This BIP was assigned number 113.
I have updated the text accordingly and added credits to Gregory Maxwell.
Please see the changes in the pull request:
https://github.com/bitcoin/bips/pull/182
On Thu, Aug 27, 2015 at 11:11:10PM
On Sun, Aug 30, 2015 at 01:56:34PM -0500, Bryan Bishop via bitcoin-dev wrote:
> Here is a short review of previously-proposed and exotic SIGHASH types.
>
> SIGHASH_MULTIPLE
> Similarly, petertodd has asked for a SIGHASH_DONT_SIGN_TXID before to
> make OP_CODESEPARATOR more useful.
There's also
On Sun, Aug 30, 2015 at 10:01:00PM +0200, Daniele Pinna via bitcoin-dev wrote:
> Since my longer post seems to be caught in moderator purgatory I will
> rehash its results into this much smaller message. I apologize for the
> spamming.
>
> I present a theorem whose thesis is obvious to many.
>
>
On Thu, Sep 03, 2015 at 11:18:08PM +, Gregory Maxwell via bitcoin-dev wrote:
> The process in BIP01 was written when we used a different solution for
> storing and presenting BIPs.
>
> I'm thinking of suggesting that the number request process be changed
> to opening a pull req with BIP text
On Thu, Sep 03, 2015 at 06:32:09PM +0100, Btc Drak via bitcoin-dev wrote:
> Just use a 4-byte unsigned integer where the integer is the size in
> bytes. It's concise and less complex (and less complex to implement).
> There's no need for human readable strings here.
Solid NACK on making string
On Fri, Sep 04, 2015 at 01:13:18PM -0700, Andy Chase via bitcoin-dev wrote:
> Thanks for your thoughts.
>
> My proposal isn't perfect for sure. There's likely much better ways to do
> it. But to be clear what I'm trying to solve is basically this:
>
> Who makes high-level Bitcoin decisions?
On Sat, Sep 05, 2015 at 07:11:27AM -0700, Ken Shirriff via bitcoin-dev wrote:
> Use of the bitcoin symbol in text is inconvenient, because the bitcoin
> symbol isn't in the Unicode standard. To fix this, I've written a proposal
> to have the common B-with-vertical-bars bitcoin symbol added to
https://github.com/petertodd/python-bitcoinlib/tree/python-bitcoinlib-v0.5.0rc1
FWIW if you've been experienceing OpenSSL related crashes on OSX or Arch
Linux this release should fix your issues. I don't have any way of
testing this myself, so if I could get some confirmation that this new
On Thu, Sep 03, 2015 at 01:34:54PM -0700, Dave Scotese via bitcoin-dev wrote:
> I have seen "1M" mean 1,000,000 bytes as well as 1,048,576bytes and
> 1,024,000 bytes. I believe the best policy is to use "megabyte" to mean
> 2^20 (1,048,576) bytes. Kb always means 1024 bytes, even when a lot
On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote:
On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote:
What would you think of an approach like John Dillon's proposal to
explicitly give the economic majority of coin holders a vote for the max
blocksize
On Wed, Aug 26, 2015 at 05:44:46AM +0800, Chun Wang wrote:
On Wed, Aug 26, 2015 at 5:18 AM, Simon Liu via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
I don't think this would work.
If the rule is that one user can only have one vote, how do you prevent
a user running
On Tue, Sep 15, 2015 at 12:10:37AM -0400, Jeff Garzik via bitcoin-dev wrote:
> Refactors however have a very real negative impact.
> bitcoin/bitcoin.git is not only the source tree in the universe.
> Software engineers at home, at startups, and at major companies are
> maintaining branches of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 17 September 2015 19:56:17 GMT-07:00, Alex Morcos via bitcoin-dev
wrote:
>+1
>sounds good to me!
+2
My schedule is chaotic, but I'll try to attend.
-BEGIN PGP SIGNATURE-
On Sun, Sep 06, 2015 at 08:43:24PM -0400, Peter Todd via bitcoin-dev wrote:
> https://github.com/petertodd/python-bitcoinlib/tree/python-bitcoinlib-v0.5.0rc1
No issues have been reported with the release candidate, so I've
released v0.5.0 officially pretty much as-is:
https://github.
On Mon, Sep 28, 2015 at 03:41:56PM +0200, Mike Hearn wrote:
> >
> > 1) Do you agree that CLTV should be added to the Bitcoin protocol?
> >
> > Ignoring the question how exactly it is added, hard-fork or soft-fork.
> >
>
> The opcode definition seems OK.
Good!
> > 2) Will you add a
On Mon, Sep 28, 2015 at 09:43:42AM -0400, Gavin Andresen wrote:
> On Mon, Sep 28, 2015 at 9:28 AM, Peter Todd wrote:
>
> > > 2) Mr. Todd (or somebody) needs to write up a risk/benefit security
> > > tradeoff analysis doo-hickey document and publish it. I'm reasonably
> > >
On Mon, Sep 28, 2015 at 04:33:23PM +0200, Mike Hearn wrote:
> >
> > SPV wallets can't detect hard-forks
>
>
> They don't have to - they pick the highest work chain. Any miner who hasn't
> upgraded makes blocks on the shorter chain that are then ignored (or
> rather, stored for future reorgs).
On Sun, Sep 27, 2015 at 04:26:12PM -0400, jl2...@xbt.hk wrote:
> +1 for deploying BIP65 immediately without further waiting. Agree
> with all Peter's points.
Thanks!
> By the way, is there any chance to backport it to 0.9? In the
> deployment of BIP66 some miners requested a backport to 0.9 and
Summary
---
It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.
I've backported the CLTV op-code and a IsSuperMajority() soft-fork to
the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A
pull-req for git HEAD for the soft-fork deployment has been open since
June 28th, #6351 -
On Mon, Sep 28, 2015 at 12:48:57PM +0200, Mike Hearn wrote:
> There is *no* consensus on using a soft fork to deploy this feature. It
> will result in the same problems as all the other soft forks - SPV wallets
> will become less reliable during the rollout period. I am against that, as
> it's
On Mon, Sep 28, 2015 at 09:01:02AM -0400, Gavin Andresen wrote:
> I think three things need to happen:
>
> 1) Stop pretending that "everyone must agree to make consensus rule
> changes." "Rough consensus" is what we've always gone with, and is good
> enough.
>
> 2) Mr. Todd (or somebody) needs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 24 September 2015 14:56:23 GMT-04:00, Suhas Daftuar
wrote:
>I considered that as well, but it seemed to me that other software on
>the
>network (say, different wallet implementations) might prefer the option
>of
>being
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 24 September 2015 14:37:40 GMT-04:00, Suhas Daftuar via bitcoin-dev
wrote:
>On Thu, Sep 24, 2015 at 2:17 PM, Tier Nolan via bitcoin-dev <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> Is there
On Fri, Sep 18, 2015 at 08:06:23PM +, Matt Corallo via bitcoin-dev wrote:
> I did not intend to imply that there was agreement on a desire to
> schedule a second hardfork. My wording may have been a bit too loose.
> Instead, I believe there was much agreement that doing a short-term
> hardfork
On Sun, Nov 29, 2015 at 10:32:34PM -0500, Chris via bitcoin-dev wrote:
> On 11/16/2015 07:42 PM, Peter Todd via bitcoin-dev wrote:
> > Sequence is used for opting in as it is the only "free-form" field
> > available for that purpose. Opt-in per output was proposed as wel
On Thu, Dec 17, 2015 at 04:58:02PM +, Tier Nolan via bitcoin-dev wrote:
> This is really the most important question.
>
> Bitcoin is kind of like a republic where there is separation of powers
> between various groups.
>
> The power blocs in the process include
>
> - Core Devs
> - Miners
>
On Tue, Dec 22, 2015 at 05:31:19PM -0800, Peter Todd via bitcoin-dev wrote:
> # Summary
Updates from IRC discussion:
1) There was some debate about what exactly should be required from the
current block to calculate the previous block posession proof. For
instance, requiring the coinbase outp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 30 December 2015 12:22:43 GMT-08:00, "Emin Gün Sirer"
wrote:
>On Wed, Dec 30, 2015 at 3:16 PM, Peter Todd wrote:
>
>> Note how transaction malleability can quickly sabotage naive notions
>of
>> this
On Thu, Jan 07, 2016 at 08:54:00PM -0500, Gavin Andresen via bitcoin-dev wrote:
> ---
>
> I'm really disappointed with the "Here's the spec, take it or leave it"
> attitude. What's the point of having a BIP process if the discussion just
> comes down to "We think more is better. We don't care
# Summary
1) Segregated witnesses separates transaction information about what
coins were transferred from the information proving those transfers were
legitimate.
2) In its current form, segregated witnesses makes validationless mining
easier and more profitable than the status quo,
On Tue, Dec 22, 2015 at 05:31:19PM -0800, Peter Todd via bitcoin-dev wrote:
> # Easy solution: previous witness data proof
>
> To return segregated witnesses to the status quo, we need to at least
> make having the previous block's witness data be a precondition to
> c
On Sat, Dec 19, 2015 at 03:17:03AM +0800, Chun Wang via bitcoin-dev wrote:
> In many BIPs we have seen, include the latest BIP202, it is the block
> time that determine the max block size. From from pool's point of
> view, it cannot issue a job with a fixed ntime due to the existence of
> ntime
On Sat, Dec 19, 2015 at 07:43:59PM -0800, Chris Priest via bitcoin-dev wrote:
> Then shouldn't this be something the pool deals with, not the bitcoin
> protocol?
There is no known way for pools - especially ones that allow anonymous
hashers - to effectively prevent block withholding attacks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 18 December 2015 11:52:19 GMT-08:00, "Jorge Timón via bitcoin-dev"
wrote:
>I agree that nHeight is the simplest option and is my preference.
>Another option is to use the median time from the previous
On Sat, Dec 26, 2015 at 12:12:13AM -0800, Multipool Admin wrote:
> Any attempt to 'fix' this problem, would most likely require changes to all
> mining software, why not just make mining more decentralized in general?
>
> For example, allow anyone to submit proofs of work to Bitcoind that are
>
Occured to me that this hasn't been mentioned before...
We can trivially fix the quadratic CHECK(MULTI)SIG execution time issue
by soft-forking in a limitation on just SignatureHash() to only return
true if the tx size is <100KB. (or whatever limit makes sense)
This fix has the advantage over
On Sun, Dec 20, 2015 at 12:12:49AM -0500, Emin Gün Sirer via bitcoin-dev wrote:
> There's quite a bit of confusion in this thread.
>
> Peter is referring to block withholding attacks. Ittay Eyal (as sole
> author -- I was not involved in this paper [1]) was the first
Ah, thanks for the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia wrote:
>On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 2) This reverses the useful minimization attribute of HD
On Wed, Dec 30, 2015 at 05:29:05AM -0800, Jonathan Toomim via bitcoin-dev wrote:
> As a first impression, I think this proposal is intellectually interesting,
> but crufty and hackish and should never actually be deployed. Writing code
> for Bitcoin in a future in which we have deployed a few
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10 January 2016 22:57:15 GMT-05:00, Rusty
>Cheers,
>Rusty.
>[1] Weirdly, the bitcoin network is doing this much work every 57
>days, for about $92M. If that's all the attack costs, it's under
>1M in 10 years.
Don't get too caught up
At the recent coredev.tech meetup in Zurich I spent much of my time discussing
anti-censorship improvements with Adam Back, building on his idea of blind
symmetric commitments[^bsc], and my own ideas of client-side verification. Our
goal here is to combat censorship by ensuring that miners do not
On Mon, Jun 20, 2016 at 04:21:39PM +, zaki--- via bitcoin-dev wrote:
> Hi Peter,
>
> I didn't entirely understand the process of transaction linearization.
>
> What I see is a potential process where when the miner assembles the block,
> he strips all but one sigscript per tx. The selection
On Tue, Jun 21, 2016 at 10:50:36PM +, James MacWhyte wrote:
> > Note that "client supplied identification" is being pushed for AML/KYC
> > compliance, e.g. Netki's AML/KYC compliance product:
> >
> >
> >
On Tue, Jun 21, 2016 at 08:44:37PM +, Luke Dashjr via bitcoin-dev wrote:
> On Monday, June 20, 2016 5:33:32 PM Erik Aronesty via bitcoin-dev wrote:
> > BIP 0070 has been a a moderate success, however, IMO:
> >
> > - protocol buffers are inappropriate since ease of use and extensibility is
> >
On Mon, Jun 20, 2016 at 05:33:32PM +, Erik Aronesty via bitcoin-dev wrote:
> BIP 0070 has been a a moderate success, however, IMO:
>
> - protocol buffers are inappropriate since ease of use and extensibility is
> desired over the minor gains of efficiency in this protocol. Not too late
> to
On Tue, Jun 21, 2016 at 08:44:37PM +, Luke Dashjr via bitcoin-dev wrote:
> X509 is entrenched, so it should remain supported. PGP might make sense for
> people already using it (it provides no real security for un-WoT-networked
> users), but unforunately, few people use it. Correct me if I'm
On Fri, Jun 17, 2016 at 08:22:04PM -0700, Bram Cohen wrote:
> On Wed, Jun 15, 2016 at 5:10 PM, Peter Todd wrote:
> > Agreed - regardless of approach adding latency to commitment calculations
> > of
> > all kinds is something I think we all agree can work in principle, although
On Fri, Jun 17, 2016 at 07:43:47PM -0700, Bram Cohen wrote:
> On Thu, Jun 16, 2016 at 9:34 PM, Peter Todd wrote:
>
> > So above you said that in merbinner trees each node "hash[es] in a record
> > of
> > its depth" That's actually incorrect: each node commits to the prefix
On Tue, Jun 21, 2016 at 05:14:31PM -0700, Justin Newton wrote:
> On Tue, Jun 21, 2016 at 3:13 PM, Peter Todd via bitcoin-dev <
> Hi Peter,
>Certainly AML/KYC compliance is one of the use cases that BIP 75 and our
> certificates can support. As a quick summary,
>
>
On Mon, Jun 20, 2016 at 01:26:22PM +, Police Terror via bitcoin-dev wrote:
> Bitcoin could embed a lisp interpreter such as Scheme, reverse engineer
> the current protocol into lisp (inside C++), run this alternative engine
> alongside the current one as an option for some years (only for fine
On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote:
> On Jun 23, 2016 12:56, "Peter Todd via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > In any case, I'd strongly argue that we remove BIP75 from the bips
> repository,
>
On Thu, Jun 23, 2016 at 02:01:10PM +0200, Pieter Wuille wrote:
> On Thu, Jun 23, 2016 at 1:39 PM, Peter Todd wrote:
> > On Thu, Jun 23, 2016 at 01:30:45PM +0200, Pieter Wuille wrote:
> > For the record, I think the idea of the bips repo being a pure publication
> > platform
On Thu, Jun 23, 2016 at 02:16:48PM +0200, Pieter Wuille wrote:
> On Jun 23, 2016 14:10, "Peter Todd" wrote:
>
> > Right, so you accept that we'll exert some degree of editorial control;
> the
> > question now is what editorial policies should we exert?
>
> No, I do not. I am
On Tue, Jun 14, 2016 at 05:14:23PM -0700, Bram Cohen via bitcoin-dev wrote:
> This is in response to Peter Todd's proposal for Merkle Mountain Range
> commitments in blocks:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html
>
> I'm in strong agreement that there's
On Thu, Jun 16, 2016 at 02:07:26AM -0700, Bram Cohen wrote:
> On Wed, Jun 15, 2016 at 8:26 PM, Peter Todd wrote:
> Okay, clearly my assumptions about the parts of that post I didn't read
> carefully were way off. I'll have to look through it carefully to be able
> to make
On Thu, Jun 23, 2016 at 03:58:29PM +0300, Alex Mizrahi wrote:
> >
> > The point I'm making is simply that to be useful, when you close a seal you
> > have to be able to close it over some data, in particular, another seal.
> > That's
> > the key thing that makes the idea a useful construct for
On Wed, Jun 15, 2016 at 06:16:26PM -0700, Bram Cohen wrote:
> On Wed, Jun 15, 2016 at 5:10 PM, Peter Todd wrote:
>
> > On Tue, Jun 14, 2016 at 05:14:23PM -0700, Bram Cohen via bitcoin-dev wrote:
> > >
> > > Peter proposes that there should be both UTXO and STXO commitments,
On Sat, Feb 06, 2016 at 12:45:14PM -0500, Gavin Andresen via bitcoin-dev wrote:
> On Sat, Feb 6, 2016 at 12:01 PM, Adam Back wrote:
>
> >
> > It would probably be a good idea to have a security considerations
> > section
>
>
> Containing what? I'm not aware of any
On Sun, Feb 07, 2016 at 10:06:06AM -0500, Alex Morcos via bitcoin-dev wrote:
> And the back and forth discussion over your BIP has been in large part a
> charade. People asking why you aren't picking 95% know very well why you
> aren't, but lets have an honest discussion of what the risks and in
On Mon, Feb 08, 2016 at 02:36:47PM -0800, Simon Liu via bitcoin-dev wrote:
> > 1) The segregated witness discount is changed from 75% to 50%. The block
> > size limit (ie transactions + witness/2) is set to 1.5MB. This gives a
> > maximum block size of 3MB and a "network-upgraded" block size of
On Thu, Feb 04, 2016 at 12:36:06PM -0500, Gavin Andresen via bitcoin-dev wrote:
> This BIP is unnecessary, in my opinion.
>
> I'm going to take issue with items (2) and (3) that are the motivation for
> this BIP:
>
> " 2. Full nodes and SPV nodes following original consensus rules may not be
>
A few notes on upgrade procedures associated with segregated witnesses:
Initial Deployment
==
While segregated witnesses is a soft-fork, because it adds new data
blocks that old nodes don't relay segwit nodes can't sync from
non-segwit nodes and still be fully validating; once
1 - 100 of 316 matches
Mail list logo