On Sat, Jun 20, 2015 at 7:26 PM, David Vorick david.vor...@gmail.com
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
held particular private keys in the past.
On Jun 16, 2015 9:41 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote:
2015-06-16 21:25 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com:
You can't avoid sharing the token, and you can't avoid sharing the
private
keys used for signing either
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 pieter.wui...@gmail.com:
Now that you have removed the outputs, I don't think it's even a intent
On Fri, Jun 12, 2015 at 10:37 AM, Tier Nolan tier.no...@gmail.com 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 onelinepr...@gmail.com 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
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
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
I'm merely proving the existence of the effect.
On Jun 12, 2015 8:24 PM, Mike Hearn m...@plan99.net 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
On Sat, Jun 6, 2015 at 5:05 PM, Kalle Rosenbaum ka...@rosenbaum.se 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
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
On Sat, Jun 6, 2015 at 5:18 PM, Luke Dashjr l...@dashjr.org 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
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 pieter.wui...@gmail.com
wrote:
Hello everyone,
here is a proposal for how to coordinate future soft-forking consensus
changes: https
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
On May 28, 2015 10:42 AM, Raystonn . rayst...@hotmail.com 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
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
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
--
On Wed, May 13, 2015 at 1:27 PM, Tier Nolan tier.no...@gmail.com 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
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 pieter.wui...@gmail.com
wrote:
On Wed, May 13, 2015 at 11:04 AM, Christian Decker
decker.christ...@gmail.com wrote:
If the inputs to my transaction have
On Wed, May 13, 2015 at 5:48 PM, Aaron Voisine vois...@gmail.com 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
On Wed, May 13, 2015 at 1:32 PM, Tier Nolan tier.no...@gmail.com wrote:
On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
This was what I was suggesting all along, sorry if I wasn't clear.
That's great. So, basically the multi-level refund problem is solved
On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine vois...@gmail.com 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
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
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.
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
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
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
On May 7, 2015 3:08 PM, Roy Badami r...@gnomon.org.uk 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, in that scenario Bitcoin
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
On Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me
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
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.
On Apr 16, 2015 1:46 AM, s7r s...@sky-ip.org 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
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`.
On Mon, Jan 26, 2015 at 10:35 AM, Gregory Maxwell gmaxw...@gmail.com 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
On Tue, Feb 3, 2015 at 4:00 AM, Wladimir laa...@gmail.com 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
On Tue, Feb 3, 2015 at 10:15 AM, Pieter Wuille pieter.wui...@gmail.com 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'm retracting this proposed change
On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell gmaxw...@gmail.com 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
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
On Thu, Jan 22, 2015 at 6:41 PM, Zooko Wilcox-OHearn
zo...@leastauthority.com 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
On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille pieter.wui...@gmail.com 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
On Wed, Jan 21, 2015 at 8:32 PM, Rusty Russell ru...@rustcorp.com.au 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
On Tue, Jan 20, 2015 at 11:45 PM, Rusty Russell ru...@rustcorp.com.au 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
On Wed, Jan 21, 2015 at 3:37 PM, Gavin Andresen gavinandre...@gmail.com 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
On Wed, Jan 21, 2015 at 2:29 PM, Douglas Roark d...@bitcoinarmory.com 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
On Wed, Jan 21, 2015 at 11:18 PM, Matt Whitlock b...@mattwhitlock.name wrote:
To be more in the C++ spirit, I would suggest changing the (const
std::vectorunsigned char sig, size_t off) parameters to
(std::vectorunsigned char::const_iterator itr, std::vectorunsigned
char::const_iterator
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 Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner etothe...@gmail.com 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.
On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon
flavien.char...@coinprism.com 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
On Mon, Nov 17, 2014 at 1:31 PM, Chris Pacia ctpa...@gmail.com 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.
On Thu, Nov 6, 2014 at 2:38 AM, Peter Todd p...@petertodd.org 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
On Thu, Nov 6, 2014 at 2:47 AM, Pieter Wuille pieter.wui...@gmail.com 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 verification
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
On Tue, Nov 4, 2014 at 5:38 AM, Mike Hearn m...@plan99.net 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
On Tue, Nov 4, 2014 at 11:56 AM, Jeff Garzik jgar...@bitpay.com wrote:
On Tue, Nov 4, 2014 at 8:13 PM, Peter Todd p...@petertodd.org 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
the optional rules only to strict v2, and not higher or lower.
On Tue, Nov 4, 2014 at 12:07 PM, Peter Todd p...@petertodd.org 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 jgar...@bitpay.com wrote:
On Tue, Nov 4, 2014 at 8:13
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,
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
On Fri, Sep 12, 2014 at 6:35 PM, Pieter Wuille pieter.wui...@gmail.com 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
On Mon, Sep 8, 2014 at 1:31 AM, Pieter Wuille pieter.wui...@gmail.com 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 Wed, Sep 3, 2014 at 6:34 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
On Mon, Sep 1, 2014 at 10:48 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
Not related to this change but the definition of rule 4 may not be
sufficiently specific-- without a definition someone could reasonably
reach
On Mon, Sep 1, 2014 at 10:48 PM, Gregory Maxwell gmaxw...@gmail.com 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
On Sat, Aug 23, 2014 at 8:17 AM, Troy Benjegerdes ho...@hozed.org 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
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,
On Sun, Aug 10, 2014 at 4:07 PM, Bob McElrath bob_bitc...@mcelrath.org 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
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 laa...@gmail.com wrote:
The version message helpfully tells me my own IP address but
On Jul 18, 2014 4:56 PM, Wladimir laa...@gmail.com wrote:
On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn m...@plan99.net 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
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
On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn m...@plan99.net 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
On Fri, Jul 18, 2014 at 5:45 PM, Pieter Wuille pieter.wui...@gmail.com 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.
--
Pieter
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
binary
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 r...@i-rme.es wrote:
Alice does not intercept the
On Thu, Jun 5, 2014 at 7:43 PM, Richard Moore m...@ricmoo.com 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
On Fri, May 30, 2014 at 5:40 PM, Andreas Schildbach
andr...@schildbach.de 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
On May 14, 2014 1:42 PM, Jameson Lopp jameson.l...@gmail.com 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
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 p...@petertodd.org 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
On Tue, May 6, 2014 at 5:12 AM, odinn.cyberguerri...@riseup.net 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
On Sat, Apr 26, 2014 at 2:24 PM, Pavol Rusnak st...@gk2.sk wrote:
On 04/26/2014 12:48 PM, Tier Nolan wrote:
Maybe the solution is to have a defined way to import an unknown wallet?
That is nonsense. There is no way how to import the wallet if you don't
know its structure.
I agree. Especially
On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin thoma...@gmx.de wrote:
Why do clients need to use the features in BIP 64? If Electrum doesn't want
to
use accounts, [...]
To clarify:
Electrum plans to have bip32 accounts; Multibit will not, afaik.
To clarify:
BIP64 has a much stricter
On Wed, Apr 23, 2014 at 5:34 PM, Kevin kevinsisco61...@gmail.com wrote:
I have some questions:
1. How can we work towards solving the double-spending problem?
We have this awesome technology that solves the double-spending
problem. It's called a blockchain. Of course, it only works when
On Tue, Apr 8, 2014 at 5:41 PM, slush sl...@centrum.cz wrote:
I've discussed the solution of Litecoin seed in BIP32 HMAC with Litecoin
devs already, and after long discussion we've concluded that it is generally
bad idea.
When changing Bitcoin seed constant to something different, same
That's the point. BIP64 specifies such a structure, and you have to scan
all that it defines.
If you want to write wallet software that does not have the complexity to
deal with just one account, it is not BIP64 compliant. It could try to
define its own purpose system, with a hierarchy without
On Wed, Apr 23, 2014 at 10:43 PM, Pavol Rusnak st...@gk2.sk wrote:
On 04/23/2014 10:41 PM, Luke-Jr wrote:
I don't see how. The user knows he has money in different subwallets. As long
as he has a way to specify which subwallet he is accessing in
single-subwallet
clients, there shouldn't be a
On Wed, Apr 23, 2014 at 11:33 PM, Pavol Rusnak st...@gk2.sk wrote:
On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
Hopefully it would be clarified as only a MUST NOT do so silently...
I have funds split across two wallets and it WONT LET ME SPEND THEM
sounds like a terrible user experience. :)
I told him specifically to bring it here (on a pull request for
Bitcoin Core), as there is no point in making such convention changes
to just one client.
I wasn't aware of any discussion about the bits proposal here before.
On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer ta...@bitsofproof.com
On Apr 21, 2014 3:37 AM, Un Ix slashdevn...@hotmail.com wrote:
Something tells me this would be reduced to a single syllable in common
usage I.e. bit.
What units will be called colloquially is not something developers will
determine. It will vary, depend on language and culture, and is not
On Wed, Apr 16, 2014 at 5:12 PM, Kevin kevinsisco61...@gmail.com wrote:
I think we should get to the bottom of this. Should we assume that xp is
not secure enough?
Yes.
What is this warning?
Windows XP is no longer maintained. Don't use such a system for
protecting your money.
Who is
On Wed, Apr 16, 2014 at 11:39 PM, Mark Friedenbach m...@monetize.io wrote:
On 04/16/2014 02:29 PM, Kevin wrote:
Okay, so how about an autoupdate function which pulls a work around off
the server? Sooner or later, the vulnerabilities must be faced.
NO. Bitcoin Core will never have an
The first input seems to be already spent by another transaction
(which looks very similar).
0.9 should report a more detailed reason for rejection, by the way.
On Tue, Apr 15, 2014 at 5:05 PM, Mike Hearn m...@plan99.net wrote:
Check debug.log to find out the reason it was rejected.
On Thu, Apr 10, 2014 at 6:47 PM, Brian Hoffman brianchoff...@gmail.com wrote:
Looks like only about ~30% disk space savings so I see your point. Is there
a critical reason why blocks couldn't be formed into superblocks that are
chained together and nodes could serve a specific superblock, which
On Thu, Apr 10, 2014 at 8:19 PM, Paul Rabahy prab...@gmail.com wrote:
Please let me know if I have missed something.
A 51% attack can make you believe you were paid, while you weren't.
Full node security right now validates everything - there is no way
you can ever be made to believe something
On Thu, Apr 10, 2014 at 10:12 PM, Tier Nolan tier.no...@gmail.com wrote:
On Thu, Apr 10, 2014 at 7:32 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
If you trust hashrate for determining which UTXO set is valid, a 51%
attack becomes worse in that you can be made to believe a version
I see the cause of our disagreement now.
You actually want to share a single BIP32 tree across different
currency types, but do it in a way that guarantees that they never use
the same keys.
I would have expected that different chains would use independent
chains, and have serializations encode
On Mon, Apr 7, 2014 at 2:19 PM, Jameson Lopp jameson.l...@gmail.com wrote:
I'm glad to see that I'm not the only one concerned about the consistent
dropping of nodes. Though I think that the fundamental question should be:
how many nodes do we really need? Obviously more is better, but it's
Hi all,
I understand this is a controversial proposal, but bear with me please.
I believe we cannot accept the current subsidy schedule anymore, so I
wrote a small draft BIP with a proposal to turn Bitcoin into a
limited-supply currency. Dogecoin has already shown how easy such
changes are, so I
On Tue, Apr 1, 2014 at 10:00 PM, Peter Todd p...@petertodd.org wrote:
On Tue, Apr 01, 2014 at 09:00:07PM +0200, Pieter Wuille wrote:
The text can be found here: https://gist.github.com/sipa/9920696
What's interesting about this bug is we could also fix the problem - the
economic shock
On Tue, Apr 1, 2014 at 9:04 PM, Matt Whitlock b...@mattwhitlock.name wrote:
The creation date in your BIP header has the wrong format. It should be
01-04-2014, per BIP 1.
Thanks - fixed!
--
Pieter
--
On Tue, Apr 1, 2014 at 11:47 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
But owing to a rather large bribe (or at least not less large than any
other offered by competing parties) I hereby assign BIP 42
Just chiming in...
I'm not opposed to a more generic default key tree, but we need to
standardize this soon I believe. There are already existing code bases
that implement BIP32 wallets (and more are popping up...); just using
a separate one will result in lots of incompibilities.
That said, I'm
On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak st...@gk2.sk wrote:
Cointype in path is for separation purposes, not for identification.
I don't understand what that gains you.
--
Pieter
--
1 - 100 of 196 matches
Mail list logo
