The scriptSig when evaluated populates the stack so opcodes can operate
on them. A witness is essentially a list of data elements, quite similar
to the script stack (the witness is passed in as the script stack in fact)
OP_0 when evaluated pushes a _zero length_ value onto the stack, hence
the 00
A schism is just that: miners can't ameliorate a HF transition in the way they
can censor transactions without permission. This is how miners became a
convenient way to activate soft-forks.
So while BIP9 can indicate the later censorship (a soft fork) in a way that
nodes can follow (or not) a
BIP30 actually was given similar treatment after a reasonable amount of
time had passed.
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2392
You are also missing BIP50: 'March 2013 Chain For Post-Mortem', which
neither benefited nor improved bitcoin, but did document an event for
I want to pitch a use-case that might have been ignored in this discussion:
I don't think this protocol is only useful for hardware wallets.
Technically any website that wants to request public keys/signatures and
offload the responsibility for managing keys and signing to the user
would also
Hi all,
Thanks again Jonas for starting this!
I worked on a similar proposal a while back (never posted), approaching
the same problem as if a merchant's website accepted xpubs/public keys,
created multi-signature addresses, and wanted the user to easily sign
offline instead of using some
I wonder if this is possible as a soft fork without using segwit?
Increasing the sigop count for a NOP would be a hard fork, but such a
change would be fine with a new segwit version. It might require specific
support in the altcoin, which might be troublesome..
On 11 Feb 2016 20:05, "Tier Nolan
On 26/01/16 03:30, Toby Padilla via bitcoin-dev wrote:
> There are already valid use cases for OP_RETURN, it only makes sense
> to fully support the feature. The only reason it's not supported now
> is because the Payments protocol came before OP_RETURN.
>
You keep saying OP_RETURN is new, but it
1. Not relaying can cause problems. Gossip networks operate by
propagating new information (like a single new header), and refuse to
relay information if it's obviously invalid.
>From the POV of a full node, which will normally hear about the header
first, there's no point to not telling peers
Who is funding this?
Why not fund Core development?
On 30 Sep 2015 7:37 am, "Richard Olsen via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> All,
>
> We are looking for participants in a Bitcoin related competition: the aim
> is to build a trading platform (initially for foreign
Something very similar was posted not too long ago.
Long and sort of it is, there is no point in saying you priced in GBP, etc,
because it can vary from exchange to exchange.
To be honest, adding more things to consider at checkout time confuses
things; why not just specify the amount of Bitcoin
I think it would be more akin to bip70. I have a similar proposal, largely
already written up around this. I'm very interested in having this for
multi signature wallets.
On 14 Sep 2015 8:06 pm, "Arthur - bitcoin-fr.io via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi,
> I
11 matches
Mail list logo
