> 3. Instead of using a OP_NOPx, I suggest you using an unused code such as
> 0xba. OP_NOPx should be reserved for some simple "VERIFY"-type codes that
> does not write to the stack.
>
> Ok. I'm not sure, but if everyone agrees to it, I will. Also Segwit
> versioning allows to create ne
Responding between lines...
On Mon, Oct 24, 2016 at 2:37 PM, Johnson Lau wrote:
> Some comments and questions
>
> 1. In the BIP you mentioned scriptSig 3 times, but I don't think you are
> really talking about scriptSig. Especially, segwit has aborted the use of
> scriptSig to fix malleability.
Some comments and questions
1. In the BIP you mentioned scriptSig 3 times, but I don't think you are really
talking about scriptSig. Especially, segwit has aborted the use of scriptSig to
fix malleability. From the context I guess you mean redeemScript (see BIP141)
2. It seems that 51% of miner
If someone uses OP_EQUALVERIFY after OP_COUNT_ACKS then the transaction
probably won't be able to be included at a different height.
On Oct 2, 2016 19:16, "Sergio Demian Lerner"
wrote:
> It can be included at another block at a differnt height. It can be
> included anytime during the liveness pe
On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> But I would argue that in this scenario, the only way it
>> would become invalid is the equivalent of a double-spend... and therefore
>> it
>> may be acceptable in relation to this
> I don't know if it's possible to implement decentralised sidechains without
> "breaking" this rule.
>
I haven't really been following the sidechain developements, but my
understanding was that redemption from a side chain would be two phase.
The person unpegging the funds provides a proof that t
> But I would argue that in this scenario, the only way it
> would become invalid is the equivalent of a double-spend... and therefore
> it
> may be acceptable in relation to this argument.
>
The values returned by OP_COUNT_ACKS vary in their exact value depending on
which block this transaction e
On Sunday, October 02, 2016 5:18:08 PM Andrew Johnson via bitcoin-dev wrote:
> Is this particular proposal encumbered by a licensing type, patent, or
> pending patent which would preclude it from being used in the bitcoin
> project? If not, you're wildly off topic.
I think that's the concern: we
If I understand this BIP correctly, the values pushed onto the stack by the
OP_COUNT_ACKS operation depends on the ack and nack counts relative to the
block that this happens to be included in.
This isn't going to be acceptable. The validity of a transaction should
always be monotone in the sense
On Sun, Oct 02, 2016 at 02:26:18PM -0300, Sergio Demian Lerner wrote:
> I'm not a lawyer, and my knowledge on patents is limited. I guess RSK WILL
> endorse DPL or will make the required actions to make sure the things
> developed by RSK remain free and open. This was not a priority until now,
> bu
The purpose of this list is highly technical discussion, not political
disagreements.
Is this particular proposal encumbered by a licensing type, patent, or
pending patent which would preclude it from being used in the bitcoin
project? If not, you're wildly off topic.
On Oct 2, 2016 12:11 PM, "P
I'm not a lawyer, and my knowledge on patents is limited. I guess RSK WILL
endorse DPL or will make the required actions to make sure the things
developed by RSK remain free and open. This was not a priority until now,
but coding was. For me, coding always is the priority.
I will discuss prioritiz
On Sun, Oct 02, 2016 at 12:18:08PM -0500, Andrew Johnson wrote:
> The purpose of this list is highly technical discussion, not political
> disagreements.
>
> Is this particular proposal encumbered by a licensing type, patent, or
> pending patent which would preclude it from being used in the bitco
On Sun, Oct 02, 2016 at 02:00:01PM -0300, Sergio Demian Lerner wrote:
> Peter, are you really going to try to down vote a decent free and
> open-source proposal that benefits all the Bitcoin community including
> you and your future children because a personal attack to me without any
> logic or ba
Peter, are you really going to try to down vote a decent free and
open-source proposal that benefits all the Bitcoin community including
you and your future children because a personal attack to me without any
logic or basis?
Is that the way you collaborate to improving Bitcoin?
I just can't beli
On Sun, Oct 02, 2016 at 12:49:08PM -0300, Sergio Demian Lerner via bitcoin-dev
wrote:
I think your history of patenting(1) Bitcoin consensus relevant technology is
sufficient by itself to be extremely dubious of any proposals coming from you
or your colleagues; patents on Bitcoin consensus techno
Since ScalingBitcoin is close, I think this is a good moment to publish our
proposal on drivechains. This BIP proposed the drivechain we'd like to use
in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it implemented
in Bitcoin. Until that happens, we're using a federated approach.
I'm sur
17 matches
Mail list logo
