Dear all,
I'm currently discovering the Bitcoin's
universe.
I installed bitcoind on my PC and I'm currently testing different
things on testnet.
I just read an article saying
that the risk for Bitcoin in the future is
On Thu, Nov 06, 2014 at 05:38:20AM -0500, Peter Todd wrote:
So right now git head will accept the following invalid transaction into
the mempool:
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
On Thu, Nov 06, 2014 at 02:47:29AM -0800, Pieter Wuille wrote:
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
On Thursday 6. November 2014 10.51.38 Francis GASCHET wrote:
Dear all,
I'm currently discovering the Bitcoin's universe.
I installed bitcoind on my PC and I'm currently testing different things
on testnet. I just read an article saying that the risk for Bitcoin in the
future is the
On Thu, 6 Nov 2014 05:45:09 -0500
Peter Todd p...@petertodd.org wrote:
On Thu, Nov 06, 2014 at 05:38:20AM -0500, Peter Todd wrote:
So right now git head will accept the following invalid transaction
into the mempool:
I sent this yesterday but it is not showing in the archives, so I'm not
sure if I did it correctly. I sent it prior to subscribing, so perhaps that
mucked it up.
nakapay.com
I have developed a system whereby a person requesting Bitcoin can make a
specific request (amount, address, timeframe,
Recently wrote the following for a friend and thought others might learn
from it.
Nope, never heard that term. By bug-for-bug compatibility, do you mean
that, for each version which has a bug, each bug must behave in the *same*
buggy way?
Exactly. tl;dr: if you accept a block as valid due
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
If you are considering running a full node (or think you are running
one), you should read the comments here:
https://www.reddit.com/r/Bitcoin/comments/1scd4z/im_running_a_full_node_and_so_should_you/cdw38ve
Thomas Zander wrote:
On Thursday 6.
Thanks Peter,
Having tried to write a bug-for-bug compatible code with Satoshi, I can only
second that it is rather close to impossible.
The aim of BIP62 is noble, still it does not feel right for me to increase the
complexity of the code with e.g. soft-fork-ready versioning.
Freezing the
Depends, without BIP62 a /lot/ of the even basic contracts that people
want to use today (or wanted to use 18 months ago) are unusable, in
fact, without BIP62, the atomic swaps suggested as important for
sidechains are not secure. While redoing Bitcoin in a hardfork is nice,
its a very long-term
IMO, CHECKLOCKTIMEVERIFY should be included in that list, too.
RE soft fork vs. hard fork: It's about this time at Mike Hearn will
chime in, on the side of hard forks. Hard forks are in a sense much
cleaner, and permit solving problems not otherwise solvable with a
hard fork. However, hard
On 11/06/2014 04:11 PM, Jeff Garzik wrote:
RE soft fork vs. hard fork: It's about this time at Mike Hearn will
chime in, on the side of hard forks. Hard forks are in a sense much
cleaner, and permit solving problems not otherwise solvable with a
hard fork. However, hard forks clearly have
On Thu, Nov 06, 2014 at 10:05:54PM +, Matt Corallo wrote:
Depends, without BIP62 a /lot/ of the even basic contracts that people
want to use today (or wanted to use 18 months ago) are unusable, in
fact, without BIP62, the atomic swaps suggested as important for
sidechains are not secure.
On Thu, Nov 06, 2014 at 11:11:52PM +0100, Jeff Garzik wrote:
IMO, CHECKLOCKTIMEVERIFY should be included in that list, too.
RE soft fork vs. hard fork: It's about this time at Mike Hearn will
chime in, on the side of hard forks. Hard forks are in a sense much
cleaner, and permit solving
On Thu, Nov 06, 2014 at 04:48:54PM -0600, Justus Ranvier wrote:
Why not schedule protocol upgrades every two years for the foreseeable
future?
For the same reason we don't do hard-forking upgrades of basically every
protocol on the planet on a regular basis, even when we don't have
consensus
Added a section Confidence to include tx1 and subsection Deliberate
delay attack
https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md
I found that under concerted attack, if miner excludes any transaction
first seen less than 30 seconds ago, or double-spent less than 30
seconds after
On Thu, Nov 06, 2014 at 05:36:55PM -0600, Justus Ranvier wrote:
This explanation is completely incoherent.
Because Bitcoin has a extra consensus requirements, requirements which
are really rare in engineering, the necessity of fixing bugs is even
greater.
There are two general ways to fix
On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd p...@petertodd.org wrote:
BIP62 does make life easier for wallet authors as they don't have to
deal with malleability - maybe! -
Yes, I agree for most contract purposes CTLV is what you want to be
using, instead of refund transactions beyond being
20 matches
Mail list logo
