On Tue, May 6, 2014 at 5:12 AM, wrote:
> You are right there is a bug in there.
>
> But the value is not 25% I think. Tinker some more. :-)
>
>>
>> Afaict, 3 is a perfectly valid value, meaning 25% of sig-> key recoveries
>> would fail erroneously...
Values 2 and 3 are only needed in theory. Th
I believe stealth addresses and the payment protocol both have their
use cases, and that they don't overlap.
If you do not want to communicate with the receiver, you typically do
not want them to know who is paying or for what (otherwise you're
already talking to them in some way, right?). That's
On Fri, May 9, 2014 at 8:13 PM, Peter Todd wrote:
> I don't think we're going to find that's practical unfortunately due to
> change. Every payment I make ties up txouts, so if we try to base the
> atomicity of payments on whether or not the payee decides to broadcast
> the transaction the payor i
On May 14, 2014 1:42 PM, "Jameson Lopp" wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Thanks; I've received several suggestions for other metrics to collect
that I hope to implement soon, but you're right in that tracking per-peer
pings is a different type of metric than what I'm
I don't think it would be too hard to add support for a option to the
seeder "for non-matching requests, forward to other DNS server at
IP:PORT", so you could cascade them.
On Fri, May 30, 2014 at 4:51 PM, Robert McKay wrote:
> No, I don't think so. The problem is the 'aa' flag is missing (see th
On Fri, May 30, 2014 at 5:40 PM, Andreas Schildbach
wrote:
> I maybe have made this suggestion in the past, but why don't we teach
> the seeder (or maybe even plain bitcoind) how to write a zone file and
> then use matured DNS servers to serve this zone?
>
> I admit I never ran my own DNS so I'm n
On Thu, Jun 5, 2014 at 7:43 PM, Richard Moore wrote:
> I was considering names like getcheckpoints() to use the terminology that
> already seemed to be in place, but they were too long :)
>
> I have been using getheaders() in my thick client to quickly grab all the
> headers before downloading the
On Fri, Jun 6, 2014 at 10:29 AM, Wladimir wrote:
> On Wed, Jun 4, 2014 at 12:42 PM, Jannis Froese
> wrote:
>
>> I think most concerns about the current use of asserts would be resolved
>> if the currently used asserts would be changed to a nicer definition which
>> is independent of NDEBUG, and a
Whenever you do a reissuing of a transaction that didn't go through
earlier, you should make sure to reuse one of the inputs for it. That
guarantees that both cannot confirm simultaneously.
On Sat, Jun 7, 2014 at 12:21 AM, Raúl Martínez wrote:
> Alice does not intercept the transaction, she only
On Sat, Jun 7, 2014 at 10:29 AM, Wladimir wrote:
> On Sat, Jun 7, 2014 at 3:55 AM, Jeff Garzik wrote:
>> As such, it is planned to remove "getwork" in the next release. Most
>> if not all pool servers have switched away from "getwork" years ago.
>
> To be clear, they switched to "getblocktemplat
I'd like to point out that there is quite a difference between "what
core nodes should be like" and "what the codebase core nodes are built
from must support".
Given sufficiently modularized code (which I think everyone seems to
be in favor of, regardless of the goals), you can likely build a
bina
Hi all,
I've sent a pull request to make a small change to BIP 62 (my
anti-malleability proposal) which is still a draft; see:
* https://github.com/bitcoin/bips/pull/90 (the request)
* https://github.com/sipa/bips/blob/bip62up/bip-0062.mediawiki (the result)
It makes two of the 7 new rules mandat
On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn wrote:
> The rationale doesn't seem to apply to rule #4, what's so special about that
> one?
Nothing really. If it's controversial in any way, I'm fine with
changing that. It's just one those things that nobody needs, nobody
uses, has never been standar
On Fri, Jul 18, 2014 at 5:45 PM, Pieter Wuille wrote:
> But perhaps we should investigate how many non-DER signatures still
> make it into blocks first...
In the last 11 blocks (4148 transactions), apparently none.
--
On Fri, Jul 18, 2014 at 7:25 PM, Pieter Wuille wrote:
> On Fri, Jul 18, 2014 at 5:45 PM, Pieter Wuille
> wrote:
>> But perhaps we should investigate how many non-DER signatures still
>> make it into blocks first...
>
> In the last 11 blocks (4148 transactions), apparent
On Jul 18, 2014 4:56 PM, "Wladimir" wrote:
>
> On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn wrote:
> > The rationale doesn't seem to apply to rule #4, what's so special about
that
> > one?
>
> > 4. Non-push operations in scriptSig Any non-push operation in a
scriptSig invalidates it.
>
> Having no
At least my crawler (bitcoin-seeder:0.01) software shouldn't reconnect
more frequently than once every 15 minutes. But maybe the two
connections you saw were instances?
On Wed, Jul 30, 2014 at 3:50 PM, Wladimir wrote:
>> The version message helpfully tells me my own IP address but not theirs ;p
>
On Sun, Aug 10, 2014 at 4:07 PM, Bob McElrath wrote:
> I had the same problem (repeatedly) which came down a hardware problem.
This is actually an independent problem (though something to be aware
of). Flaky hardware can make synchronization fail completely - as it
relies on being able to exactly
Yes, I believe peer rotation is useful, but not for privacy - just for
improving the network's internal knowledge.
I haven't looked at the implementation yet, but how I imagined it would be
every X minutes you attempt a new outgoing connection, even if you're
already at the outbound limit. Then, i
On Sat, Aug 23, 2014 at 8:17 AM, Troy Benjegerdes wrote:
> On Fri, Aug 22, 2014 at 09:20:11PM +0200, xor wrote:
>> On Tuesday, August 19, 2014 08:02:37 AM Jeff Garzik wrote:
>> > It would be nice if the issues and git repo for Bitcoin Core were not
>> > on such a centralized service as github, nic
On Mon, Sep 1, 2014 at 10:48 PM, Gregory Maxwell wrote:
> Not related to this change but the definition of rule 4 may not be
> sufficiently specific-- without a definition someone could reasonably
> reach a different conclusion about OP_1NEGATE being a "push
> operation", or might even decide any
On Wed, Sep 3, 2014 at 6:34 PM, Pieter Wuille wrote:
> On Mon, Sep 1, 2014 at 10:48 PM, Gregory Maxwell wrote:
>> Not related to this change but the definition of rule 4 may not be
>> sufficiently specific-- without a definition someone could reasonably
>> reach a diffe
On Mon, Sep 8, 2014 at 1:31 AM, Pieter Wuille wrote:
> I've sent out a new pull request
> (https://github.com/bitcoin/bips/pull/102/files) that:
> * Changes the order of the rules.
> * Adds more reference documentation about minimal pushes and number encodings.
> * Clarified
On Fri, Sep 12, 2014 at 6:35 PM, Pieter Wuille wrote:
> Changes: https://github.com/bitcoin/bips/pull/102/files
>
> Gregory, Jeff: does this address your concerns?
> Others: comments?
I've made another change in the PR, as language about strictly only
compressed or uncompresse
t;> >> Such guidelines are a perfect example of why PGP WoT is useless and
>> >> stupid geek wanking.
>> >>
>> >> A person's behavioural signature is what is relevant. We know how
>> >> Satoshi coded and wrote. It was the online Satoshi
Hi all,
I believe that a large change that I've been working on for Bitcoin
Core is ready for review and testing: headers-first synchronization.
In short, it changes the way the best chain is discovered, downloaded
and verified, with several advantages:
* Parallel block downloading (much faster sy
Hi all,
while working on a BIP62 implementation I discovered yet another type
of malleability: the interpretation of booleans.
Any byte array with non-zero bytes in it (ignoring the highest bit of
the last byte, which is the sign bit when interpreting as a number) is
interpreted as true, anything
To be clear: I indeed meant to only allow 0 and 1 as booleans (or,
more precisely: [] and [0x01]). Evaluating any stack element as a
boolean that is not any of these would result in script failure.
The only places where this is relevant:
* Inputs to OP_IF and OP_NOTIF (which are currently allowed
Hi all,
one of the rules in BIP62 is the "clean stack" requirement, which
makes passing more inputs to a script than necessary illegal.
Unfortunately, this rule needs an exception for P2SH scripts: the test
can only be done after (and not before) the second stage evaluation.
Otherwise it would re
On Tue, Nov 4, 2014 at 5:38 AM, Mike Hearn wrote:
> This is another problem that only exists because of the desire to soft fork.
> If "script 2.0" is a hard fork upgrade, you no longer need weird hacks like
> scripts-which-are-not-scripts.
I agree.
I also agree that the desire for softforks somet
On Tue, Nov 4, 2014 at 11:56 AM, Jeff Garzik wrote:
> On Tue, Nov 4, 2014 at 8:13 PM, Peter Todd wrote:
>> On another topic, I'm skeptical of the choice of nVersion==3 - we'll
>> likely end up doing more block.nVersion increases in the future, and
>> there's no reason to think they'll have anythi
the optional rules only to strict v2, and not higher or lower.
On Tue, Nov 4, 2014 at 12:07 PM, Peter Todd wrote:
> On Tue, Nov 04, 2014 at 12:00:43PM -0800, Pieter Wuille wrote:
>> On Tue, Nov 4, 2014 at 11:56 AM, Jeff Garzik wrote:
>> > On Tue, Nov 4, 2014 at 8:13 PM, Peter Tod
On Thu, Nov 6, 2014 at 2:38 AM, Peter Todd wrote:
> However the implementation of the STRICTENC flag simply makes pubkey
> formats it doesn't recognize act as through the signature was invalid,
> rather than failing the transaction. Similar to the invalid due to too
> many sigops DoS attack I foun
On Thu, Nov 6, 2014 at 2:47 AM, Pieter Wuille wrote:
>> I suggest we either change STRICTENC to simply fail unrecognized pubkeys
>> immediately - similar to how non-standard signatures are treated - or
>> fail the script if the pubkey is non-standard and signature verifi
On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner wrote:
>
> On 11/16/2014 02:04 PM, Jorge Timón wrote:
>> I remember people asking in #bitcoin-dev "Does anyone know any use
>> case for greater sizes OP_RETURNs?" and me answering "I do not know of
>> any use cases that require bigger sizes".
>
> For re
On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon
wrote:
>> My main concern with OP_RETURN is that it seems to encourage people to use
>> the blockchain as a convenient transport channel
>
> The number one user of the blockchain as a storage and transport mechanism
> is Counterparty, and limiting
On Mon, Nov 17, 2014 at 1:31 PM, Chris Pacia wrote:
> If users wishes to use stealth addresses with out of band communication, the
> benefits of HD would largely be lost and they would be back to making
> regular backups -- this time after every transaction rather than every 100.
That is inevita
On Mon, Dec 15, 2014 at 1:47 PM, Peter Todd wrote:
> BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a few
> days ago and found a fairly large design change that makes merging it
> currently
> impossible. Pull-req #4890², specifically commit c7829ea7, changed the
> EvalSc
Hello everyone,
We've been aware of the risk of depending on OpenSSL for consensus
rules for a while, and were trying to get rid of this as part of BIP
62 (malleability protection), which was however postponed due to
unforeseen complexities. The recent evens (see the thread titled
"OpenSSL 1.0.0p
On Tue, Jan 20, 2015 at 11:45 PM, Rusty Russell wrote:
> // Null bytes at the start of R are not allowed, unless it would otherwise be
> // interpreted as a negative number.
> if (lenS > 1 && (sig[lenR + 6] == 0x00) && !(sig[lenR + 7] & 0x80))
> return false;
>
> You mean "null bytes at th
On Wed, Jan 21, 2015 at 2:29 PM, Douglas Roark wrote:
> Nice paper, Pieter. I do have a bit of feedback.
Thanks for the comments. I hope I have clarified the text a bit accordingly.
> 1)The first sentence of "Deployment" has a typo. "We reuse the
> double-threshold switchover mechanism from BIP
On Wed, Jan 21, 2015 at 3:37 PM, Gavin Andresen wrote:
> DERSIG BIP looks great to me, just a few nit-picky changes suggested:
>
> You mention the "DER standard" : should link to
> http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf (or
> whatever is best reference for DER).
>
> "t
On Wed, Jan 21, 2015 at 11:18 PM, Matt Whitlock wrote:
> To be more in the C++ spirit, I would suggest changing the (const
> std::vector &sig, size_t &off) parameters to
> (std::vector::const_iterator &itr, std::vector char>::const_iterator end).
I agree that is more in the spirit of C++, but p
On Wed, Jan 21, 2015 at 8:32 PM, Rusty Russell wrote:
> One weirdness is the restriction on maximum total length, rather than a
> 32 byte (33 with 0-prepad) limit on signatures themselves.
Glad that you point this out; I believe that's a weakness with more
impact now that this function is used fo
On Thu, Jan 22, 2015 at 6:41 PM, Zooko Wilcox-OHearn
wrote:
> * Should the bipstrictder give a rationale or link to why accept the
> 0-length sig as correctly-encoded-but-invalid? I guess the rationale
> is an efficiency issue as described in the log entry for
> https://github.com/sipa/bitcoin/com
On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille wrote:
> I therefore propose a softfork to make non-DER signatures illegal
> (they've been non-standard since v0.8.0). A draft BIP text can be
> found on:
>
> https://gist.github.com/sipa/5d12c343746dad376c80
I'd like to
Hashes are always computed by reserializing data structures, never by
hashing wire data directly. This has been the case in every version of the
reference client's code that I know of.
This even meant that for example a block of 99 bytes with non-shortest
length for the transaction count could
On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell wrote:
> So I think we should just go ahead with R/S length upper bounds as
> both IsStandard and in STRICTDER.
I would like to fix this at some point in any case.
If we want to do that, we must at least have signatures with too-long
R or S values
On Tue, Feb 3, 2015 at 4:00 AM, Wladimir wrote:
>> One way to do that is to just - right now - add a patch to 0.10 to
>> make those non-standard. This requires another validation flag, with a
>> bunch of switching logic.
>>
>> The much simpler alternative is just adding this to BIP66's DERSIG
>> r
On Tue, Feb 3, 2015 at 10:15 AM, Pieter Wuille wrote:
>>> The much simpler alternative is just adding this to BIP66's DERSIG
>>> right now, which is a one-line change that's obviously softforking. Is
>>> anyone opposed to doing so at this stage?
I'
On Mon, Jan 26, 2015 at 10:35 AM, Gregory Maxwell wrote:
>> I'd like to request a BIP number for this.
>
> Sure. BIP0066.
Four implementations exist now:
* for master: https://github.com/bitcoin/bitcoin/pull/5713 (merged)
* for 0.10.0: https://github.com/bitcoin/bitcoin/pull/5714 (merged,
and inc
Hello everyone,
Bitcoin Core's `setgenerate` RPC call has had a special meaning for
-regtest (namely instantaneously mining a number of blocks, instead of
starting a background CPU miner).
We're planning to deprecate that overloaded behaviour, and replace it with
a separate RPC call `generate`. I
On Apr 16, 2015 1:46 AM, "s7r" wrote:
> but for transaction versions? In simple terms, if > 75% from all the
> transactions in the latest 1000 blocks are version 'n', mark all
> previous transaction versions as non-standard and if > 95% from all the
> transactions in the latest 1000 blocks are ver
> Anyone can alter the txid - more details needed. The number of altered
> txids in practice is not so high in order to make us believe anyone can
> do it easily. It is obvious that all current bitcoin transactions are
> malleable, but not by anyone and not that easy. At least I like to think
so.
As softforks almost certainly require backports to older releases and other
software anyway, I don't think they should necessarily be bound to Bitcoin
Core major releases. If they don't require large code changes, we can
easily do them in minor releases too.
On Apr 28, 2015 12:51 PM, "Peter Todd"
On Thu, May 7, 2015 at 12:12 AM, Matt Corallo
wrote:
> Recently there has been a flurry of posts by Gavin at
> http://gavinandresen.svbtle.com/ which advocate strongly for increasing
> the maximum block size. However, there hasnt been any discussion on this
> mailing list in several years as far
I would not modify my node if the change introduced a perpetual 100 BTC
subsidy per block, even if 99% of miners went along with it.
A hardfork is safe when 100% of (economically relevant) users upgrade. If
miners don't upgrade at that point, they just lose money.
This is why a hashrate-triggered
On May 7, 2015 3:08 PM, "Roy Badami" wrote:
>
> On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote:
> > I would not modify my node if the change introduced a perpetual 100 BTC
> > subsidy per block, even if 99% of miners went along with it.
>
> Surely
So, there are several ideas about how to reduce the size of blocks being
sent on the network:
* Matt Corallo's relay network, which internally works by remembering the
last 5000 (i believe?) transactions sent by the peer, and allowing the peer
to backreference those rather than retransmit them insi
It's a very complex trade-off, which is hard to optimize for all use cases.
Using more UTXOs requires larger transactions, and thus more fees in
general. In addition, it results in more linkage between coins/addresses
used, so lower privacy.
The only way you can guarantee an economical reason to k
Miners do not care about the age of a UTXO entry, apart for two exceptions.
It is also economically irrelevant.
* There is a free transaction policy, which sets a small portion of block
space aside for transactions which do not pay sufficient fee. This is
mostly an altruistic way of encouraging Bit
I have no strong opinion, but a slight preference for separate opcodes.
Reason: given the current progress, they'll likely be deployed
independently, and maybe the end result is not something that cleanly fits
the current CLTV argument structure.
---
Normalized transaction ids are only effectively non-malleable when all
inputs they refer to are also non-malleable (or you can have malleability
in 2nd level dependencies), so I do not believe it makes sense to allow
mixed usage of the txids at all. They do not provide the actual benefit of
guarant
On Wed, May 13, 2015 at 11:04 AM, Christian Decker <
decker.christ...@gmail.com> wrote:
> If the inputs to my transaction have been long confirmed I can be
> reasonably safe in assuming that the transaction hash does not change
> anymore. It's true that I have to be careful not to build on top of
On Wed, May 13, 2015 at 12:14 PM, Christian Decker <
decker.christ...@gmail.com> wrote:
>
> On Wed, May 13, 2015 at 8:40 PM Pieter Wuille
> wrote:
>
>> On Wed, May 13, 2015 at 11:04 AM, Christian Decker <
>> decker.christ...@gmail.com> wrote:
>>
>>
On Wed, May 13, 2015 at 1:27 PM, Tier Nolan wrote:
> After more thought, I think I came up with a clearer description of the
> recursive version.
>
> The simple definition is that the hash for the new signature opcode should
> simply assume that the normalized txid system was used since the
> beg
On Wed, May 13, 2015 at 1:32 PM, Tier Nolan wrote:
>
> On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille
> wrote:
>
>>
>> This was what I was suggesting all along, sorry if I wasn't clear.
>>
>> That's great. So, basically the multi-level refund probl
On Wed, May 13, 2015 at 5:48 PM, Aaron Voisine wrote:
> We have $3billion plus of value in this system to defend. The safe,
> conservative course is to increase the block size. Miners already have an
> incentive to find ways to encourage higher fees and we can help them with
> standard recommend
On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine wrote:
> Conservative is a relative term. Dropping transactions in a way that is
> unpredictable to the sender sounds incredibly drastic to me. I'm suggesting
> increasing the blocksize, drastic as it is, is the more conservative choice.
>
Transacti
It's just a mempool policy rule.
Allowing the contents of blocks to change (other than by mining a competing
chain) would be pretty much the largest possible change to Bitcoin's
design
--
__
Hello everyone,
here is a proposal for how to coordinate future soft-forking consensus
changes: https://gist.github.com/sipa/bf69659f43e763540550
It supports multiple parallel changes, as well as changes that get
permanently rejected without obstructing the rollout of others.
Feel free to commen
> until we have size-independent new block propagation
I don't really believe that is possible. I'll argue why below. To be clear,
this is not an argument against increasing the block size, only against
using the assumption of size-independent propagation.
There are several significant improvemen
On May 28, 2015 10:42 AM, "Raystonn ." wrote:
>
> I agree that developers should avoid imposing economic policy. It is
dangerous for Bitcoin and the core developers themselves to become such a
central point of attack for those wishing to disrupt Bitcoin.
I could not agree more that developers sh
Thanks for all the comments.
I plan to address the feedback and work on an implementation next week.
On Tue, May 26, 2015 at 6:48 PM, Pieter Wuille
wrote:
> Hello everyone,
>
> here is a proposal for how to coordinate future soft-forking consensus
> changes: https://gist.git
What do you gain by making PoPs actually valid transactions? You could for
example change the signature hashing algorithm (prepend a constant string,
or add a second hashing step) for signing, rendering the signatures in a
PoP unusable for actual transaction, while still committing to the same
actu
On Sat, Jun 6, 2015 at 5:05 PM, Kalle Rosenbaum wrote:
> > What do you gain by making PoPs actually valid transactions? You could
> for
> > example change the signature hashing algorithm (prepend a constant
> string,
> > or add a second hashing step) for signing, rendering the signatures in a
> P
On Sat, Jun 6, 2015 at 5:18 PM, Luke Dashjr wrote:
> I also agree with Pieter, that this should *not* be so cleanly compatible
> with Bitcoin transactions. If you wish to share code, perhaps using an
> invalid opcode rather than OP_RETURN would be appropriate.
Using an invalid opcode would mere
Hello all,
I've created a simulator for Bitcoin mining which goes a bit further than
the one Gavin used for his blog post a while ago. The main difference is
support for links with different latency and bandwidth, because of the
clustered configuration described below. In addition, it supports dif
I'm merely proving the existence of the effect.
On Jun 12, 2015 8:24 PM, "Mike Hearn" wrote:
> 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
If there is a benefit in producing larger more-fee blocks if they propagate
slowly, then there is also a benefit in including high-fee transactions
that are unlikely to propagate quickly through optimized relay protocols
(for example: very recent transactions, or out-of-band receoved ones). This
ef
On Fri, Jun 12, 2015 at 10:37 AM, Tier Nolan wrote:
> Once the 75% threshold is reached, miners who haven't updated are at risk
> of mining on invalid blocks.
>
Note that we've been above the 75% threshold since june 7th (before Peter's
main was sent).
--
Pieter
---
On Wed, May 20, 2015 at 4:55 AM, Andrew wrote:
> Hi
>
> I briefly mentioned something about this on the bitcoin-dev IRC room. In
> general, it seems experts (like sipa i.e. Pieter) are against using
> sidechains as a way of scaling. As I only have a high level understanding
> of the Bitcoin proto
thing. You cannot use PoP
> without a transaction to prove.
>
> So, yes, it's just a proof of access to certain coins that you no longer
> have.
>
> Maybe I don't understand you correctly?
>
> /Kalle
>
> 2015-06-15 11:27 GMT+02:00 Pieter Wuille :
> > No
On Mon, Jun 15, 2015 at 11:27 AM, Mike Hearn wrote:
> I persevered for several months to add a very small "API" I needed for my
> app to Bitcoin Core, and it was in the end a waste of time. There are no
> actionable items left for the getutxo patch, regardless, I had to fork
> Bitcoin to get it o
On Mon, Jun 15, 2015 at 12:36 PM, Mike Hearn wrote:
>
> 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
ogress will likely
> be slow, but if I believe in something, I will keep working on it. I'm
> still seeking more criticism of my proposal, because you know, I don't want
> to waste my time if there's something fundamentally wrong with it.
>
> Cheers
>
> On Sun,
On Mon, Jun 15, 2015 at 9:45 PM, Adam Weiss wrote:
> ps. I think SF will let project admins download mbox archives of the list,
> the new admins should be able to import them to keep archive consistency in
> one place.
>
That seems to be right. I just downloaded the entire archive of this list
(
On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum wrote:
> 2015-06-15 12:00 GMT+02:00 Pieter Wuille :
> I'm not sure if we will be able to support PoP with CoinJoin. Maybe
> someone with more insight into CoinJoin have some input?
>
Not really. The problem is that you ass
9:22 PM, "Kalle Rosenbaum" wrote:
> Thank you for your comments Pieter! Please find my answers below.
>
> 2015-06-16 16:31 GMT+02:00 Pieter Wuille :
> > On Mon, Jun 15, 2015 at 1:59 PM, Kalle Rosenbaum
> wrote:
> >>
> >> 2015-06-15 12:00 GMT+02:00 Pieter Wuil
ms to have held particular private keys in the past.
On Jun 16, 2015 9:41 PM, "Kalle Rosenbaum" wrote:
> 2015-06-16 21:25 GMT+02:00 Pieter Wuille :
> > You can't avoid sharing the token, and you can't avoid sharing the
> private
> > keys used for signin
On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan
wrote:
> Like in any open source project there is lots of decision making ability
> for code changes. I'd say look at the changelog for e.g. 0.11
> https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log,
> or fol
On Thu, Jun 18, 2015 at 3:31 PM, Mike Hearn wrote:
> 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% agre
Hello all,
I've seen ideas around hard fork proposals that involve a block version
vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
believe this is a bad idea, independent of what the hard fork itself is.
Ultimately, the purpose of a hard fork is asking the whole community to
On Sat, Jun 20, 2015 at 7:26 PM, David Vorick
wrote:
> I see it as unreasonable to expect all nodes to upgrade during a hardfork.
> If you are intentionally waiting for that to happen, it's possible for an
> extreme minority of nodes to hold the rest of the network hostage by simply
> refusing to
Hello all,
as some of you may know, a vulnerability has been found in how the
Bitcoin reference client deals with duplicate transactions. Exploiting
it is rather complex, requires some hash power, and has no financial
benefit for the attacker. Still, it's a security hole, and we'd like
to fix this
On Tue, Feb 28, 2012 at 18:12, Brautigam Róbert
wrote:
>> A simple way to fix this, is adding an extra protocol rule[1]:
>>
>> Do not allow blocks to contain a transaction whose hash is equal to
>> that of a former transaction which has not yet been completely spent.
>
> I don't know whether I
On Tue, Feb 28, 2012 at 01:23:01PM -0500, Luke-Jr wrote:
> Has it been verified to make even rocconor's complicated transaction-based
> version impossible?
Yes, he tried it on testnet against a patched node.
> > The purpose of this mail is asking for support for adding this rule to
> > the proto
On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote:
> Could you spell out the attack explicitly? Presumably there aren't a
> lot of people with the "malice energy" to perform the attack but not
> to figure it out for themselves. I, however, have the "niceness
> energy" to think ab
On Wed, Feb 29, 2012 at 11:00:42PM +, Ben Reeves wrote:
> I'm not sure. What if they use a coinbase of a block that has already matured?
Indeed; duplicate an old coinbase, fork chain without dupe, and spend the old
coinbase.
The 100-blocks maturity will not help against is.
I'm not sure how
On Thu, Mar 01, 2012 at 01:09:02PM +, Ben Reeves wrote:
> One more thing to add. The implementation in the reference patch fixes
> the blockchain forking issue however by still allowing spent coinbases
> to be disconnected patched clients are still vulnerable to blockchain
> corruption. While n
1 - 100 of 276 matches
Mail list logo
