On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd 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 more clearly
correct
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
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 af
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/06/2014 05:26 PM, Peter Todd wrote:> 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 problems to worry about.
>
> Flag days are really rar
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 p
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 solvin
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 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 hav
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 fork
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 th
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 cons
-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. No
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 d
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, etc.
On Thu, 6 Nov 2014 05:45:09 -0500
Peter Todd 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:
> >
> > 010001140de229e08fda25cbc16ded2618cdacce49fcb18c0b6ccdace00040909adae400
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 d
On Thu, Nov 06, 2014 at 02:47:29AM -0800, Pieter Wuille wrote:
> 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 transac
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 verification
>> succeeds.
>
> Sou
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 06, 2014 at 05:38:20AM -0500, Peter Todd wrote:
> So right now git head will accept the following invalid transaction into
> the mempool:
>
> 010001140de229e08fda25cbc16ded2618cdacce49fcb18c0b6ccdace00040909adae49000493046022100f7828d81c849c5448ba5ba4ef55df6b4d0ba3ae3f1a59c
So right now git head will accept the following invalid transaction into
the mempool:
010001140de229e08fda25cbc16ded2618cdacce49fcb18c0b6ccdace00040909adae49000493046022100f7828d81c849c5448ba5ba4ef55df6b4d0ba3ae3f1a59cff3291880c2c8e524f022100d2f5bc9dc2f0674eded31023cb47e61a596e10f8f1dd
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
t
22 matches
Mail list logo