On 11/01/2015 07:30 PM, Tier Nolan via bitcoin-dev wrote:
> If at least one year's notice was given, then people aren't going to
> lose their money, since they have notice.
So after realizing that I misread substantial portions of this thread
due to a lack of attention to detail I'd like to point
On Monday, November 02, 2015 4:27:50 AM jl2...@xbt.hk wrote:
> Currently, a tx maybe included in a block only if its locktime (x) is
> smaller than the timestamp of a block (y)
>
> BIP113 says that a tx maybe included in a block only if x is smaller
> than the median-time-past (z)
>
> It is alrea
Currently, a tx maybe included in a block only if its locktime (x) is
smaller than the timestamp of a block (y)
BIP113 says that a tx maybe included in a block only if x is smaller
than the median-time-past (z)
It is already a consensus rule that y > z. Therefore, if x < z, x < y
The new rul
I guess by "locked transaction" you must mean a P2SH output?
If so, that's a rather bizarre use of terms since outputs and
transactions are very different things.
0xEAD9E623.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
___
On Mon, Nov 2, 2015 at 12:23 AM, Justus Ranvier via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Are there actually any OP_CAT scripts currently in the utxo set?
>
A locked transaction could pay to an OP_CAT script with the private key
being lost.
Even if it is only in theory, i
On Monday, November 02, 2015 12:23:27 AM Justus Ranvier via bitcoin-dev wrote:
> It's a lot easier to justify the position: "nobody has the right to
> change the meaning of someone else's outputs", than it is to justify,
> "some small group of people gets to decide what's standard and what
> isn't,
On 11/01/2015 05:46 PM, Tier Nolan via bitcoin-dev wrote:
> An OP_CAT script that requires TBs of RAM to validate crosses the
> threshold of reasonableness.
Are there actually any OP_CAT scripts currently in the utxo set?
It's one thing to have a theoretical scripting ability that gets removed
b
On Sun, Nov 1, 2015 at 5:28 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I think it is very important to make it clear that non-standard txs and
> non-standard scripts may become invalid in the future
>
There can be unavoidable situations which cause locked coins b
BIP 113 makes things valid which currently are not (any transaction with a
locktime between the median time past, and the block nTime). Therefore it is a
hardfork. Yet the current BIP describes and deploys it as a softfork.
Furthermore, Bitcoin Core one week ago merged #6566 adding BIP 113 logic
My answer is simply "No", you don't have to maintain backward
compatibility for non-standard tx.
The same question applies to P2SH. Before the deployment of BIP16, one
could have created a time-locked tx with one of the output was in the
form of HASH160 EQUAL. The , however, is not a hash of
On 10/30/2015 10:43 PM, Rusty Russell via bitcoin-dev wrote:
> By that benchmark, we should aim for "reasonable certainty". A
> transaction which would never have been generated by any known software
> is the minimum bar. Adding "...which would have to be deliberately
> stupid with many redundant
11 matches
Mail list logo
