Gold collapsing. Bitcoin UP.

[satoshis_sockpuppet]

You balked at the chance to add even a teeny bit more functionality in OP_CDS(V), and now BCH is getting better equipped every day, and is going to eat your lunch. I won't feel the least bit sorry for any of you as BCH (and the rest of cryptocurrency) leaves BSV behind.

I don't think that OP_CDS or any new opcode is that important for the success of any cryptocurrency. It is a nice addition to BCH but BCH devs (including BU) tend to forget why the BCH/BTC split did happen (Peter R. seems to be the only prominent BCH person who didn't). It's about unlimited P2P cash for the world.

We don't need new opcodes (also no "reactivated" opcodes) and the fight with Ethereum is uninteresting. Apart from "preconsensus" the only interesting development apart from higher transaction limits happens outside of the protocol.

Imo the BCH players should acknowledge that the main competition might become BSV, not BTC and not Ethereum. And prosecution of all 'false-thinkers' in the BCH-camp won't win this fight.

 

[trinoxol]

OP_CDS is increasing the power of transaction scripts a lot. It can be used to obtain the current transaction as bytes. This means that an output script can inspect the transaction and apply arbitrary rules. This capability is what allows to create, for example, a smart contract that enforces the rules of chess between two players and pays to the winner.

 

[satoshis_sockpuppet]

@trinoxol
I know, don't get me wrong I think it is very nice to have.

But we all know that if BTC went with Bip101 we wouldn't be lamenting about a missing OP-Code because the chances would be high that Bitcoin would have become a real success.

 

[torusJKL]

OP_CDS is increasing the power of transaction scripts a lot. It can be used to obtain the current transaction as bytes. This means that an output script can inspect the transaction and apply arbitrary rules. This capability is what allows to create, for example, a smart contract that enforces the rules of chess between two players and pays to the winner.

It will be interesting to see what can be one in Script without OP_CDS.

 

[shilch]

OP_CDS is increasing the power of transaction scripts a lot. It can be used to obtain the current transaction as bytes. This means that an output script can inspect the transaction and apply arbitrary rules. This capability is what allows to create, for example, a smart contract that enforces the rules of chess between two players and pays to the winner.

Right, but that could be implemented in script right now as well. I never tried but probably it wouldn't even require that many instructions considering that BSV has reenabled big numbers. Or there's a completely different way to do it which no one has thought of before.

Of course, one can always argue that having one single opcode is much easier. But then you are at a point where the protocol gets changed again, where decisions need to be made on which complex script gets a dedicated opcode and which not. Right now we see Tobias Ruck on BCH lobbying in his OP_REVERSEBYTES into the protocol although it can be done in a super simple script.

 

[trinoxol]

Chess cannot be done on BSV because once a player is able to spend the TXO (by making a move) he can just take the money. There is no way to place a restriction on where an output can be spent.

A script could validate, that a valid move is input according to the chess rules. But after a single move the money is gone.

I have laid this down in this thread in detail. BSV cannot enforce arbitrary contracts on-chain.

 

[shilch]

Yes, it can. There is just no single opcode to do this. But it could be done using a sequence of opcodes.

 

[trinoxol]

@shilch OK, I make a valid move and take all the money into my wallet. What then?

Of course, a BSV script can compute any function. Nobody disputes this. With a computer science background, it is a trivial fact. But you can't make a chess game with that.

 

[cypherblock]

There are multiple queues for tx validation. Txs enter queues based on how familiar/safe a tx template looks to miners... A new tx type will end up in the slower queue and will never be in front of a payment or any other type of tx that is known to be fast to process and makes up the vast majority....

Well that's the mining side. What about block validation once a block is received? For extending the chain, does BSV use first seen block or first verified block?

 

[cypherdoc]

why is this site still up? watch out:

https://www.electronbsv.io/

 

[shilch]

@shilch OK, I make a valid move and take all the money into my wallet. What then?

Of course, a BSV script can compute any function. Nobody disputes this. With a computer science background, it is a trivial fact. But you can't make a chess game with that.

You would do it the same way as with OP_CDS: The scriptPubKey requires the spending transaction to be pushed to the stack. Then, inside script, you calculate the sighash and check it against the signature provided. Then you do an OP_CHECKSIGVERIFY to ensure that the provided signature really is a valid one.
On the stack you are now left with the spending transaction. It could actually be a different transaction but only if one found a collision (which is very very very unlikely). On that spending transaction you can put more constraints like where the output amounts should go.

 

[Otaci]

Yes, what shilch said.

The point is to have a universal script language and the capability to use it.

 

[trinoxol]

@shilch That's true! Awesome.

I guess the bignum support enables manual ECDSA signature computations.

@Otaci, you should patent that

 

[shadders]

OP_CDS is increasing the power of transaction scripts a lot. It can be used to obtain the current transaction as bytes. This means that an output script can inspect the transaction and apply arbitrary rules. This capability is what allows to create, for example, a smart contract that enforces the rules of chess between two players and pays to the winner.

This can be done with native bitcoin as well. OP_CDS is not required.
[doublepost=1580985136][/doublepost]

Chess cannot be done on BSV because once a player is able to spend the TXO (by making a move) he can just take the money. There is no way to place a restriction on where an output can be spent.

A script could validate, that a valid move is input according to the chess rules. But after a single move the money is gone.

I have laid this down in this thread in detail. BSV cannot enforce arbitrary contracts on-chain.

Yes it can, you just haven't figured out how yet...
[doublepost=1580985317][/doublepost]

@shilch That's true! Awesome.

I guess the bignum support enables manual ECDSA signature computations.

@Otaci, you should patent that

We did.. 3 years ago...

 

[bsdtar]

Then, inside script, you calculate the sighash and check it against the signature provided.

You do make it sound simple ("and check it"). Have you seriously tried doing EC point multiplication in script? Bignum math is just a tiny tiny... tiny operation in comparison.

 

[cypherdoc]

the best thing about this case and everything CSW has said about the Tulip Trust, is that this idiot Ira will never be able to get his hands on any of its bitcoin because every indication is that it's an irrevocable non grantor trust, ie, CSW can't just give half away based on some court decision even if you believe Ira deserves it (I don't) . and that all the equivocation done by CSW can actually be shown to be true; "I own it but I don't own it. I control it but I don't control it". all true at the same time. Ira could go broke trying to pierce an impenetrable shield out of pure greed.

https://modernconsensus.com/people/judge-to-wright-reveal-tulip-trust-iii-contents-by-valentines-day/amp/#click=https://t.co/5HRV6zCH9y

 

[Norway]

OP_CDS is increasing the power of transaction scripts a lot. It can be used to obtain the current transaction as bytes. This means that an output script can inspect the transaction and apply arbitrary rules. This capability is what allows to create, for example, a smart contract that enforces the rules of chess between two players and pays to the winner.

OP_CDS was sold to BU members by @theZerg as something that would make new usecases for bitcoin possible. @theZerg highlighted betting with an oracle as a clear new usecase.

I voted "Yes" on this proposal because I thought @theZerg's claim was true.

I later did my homework and discovered that it was completely false. With help from Thomas Bakketun, we made a script demonstrating that you could indeed have this usecase without changing the protocol with OP_CDS.

Here is the article:
https://www.yours.org/content/betting-using-bitcoin-cash-smart-contracts-f4367d93a6dd

 

[Otaci]

This may be an example of the technique. I haven't finished digging through it yet.

https://twitter.com/sinoTrinity/status/1225323514632138753

One thing I will say, that code needs some optimization, I shouldn't imagine that's too hard of a job though. Probably on the "to-do" list.

 

[shilch]

You do make it sound simple ("and check it"). Have you seriously tried doing EC point multiplication in script? Bignum math is just a tiny tiny... tiny operation in comparison.

I just spend a bit of time trying it: Basically implementing the formulas from Wikipedia.

Following points I should mention:

• I haven't tested it at all, this just for having a look at how large (or small) a script would be
• To reuse script parts, I defined MACROs
• The multiplicative inverse is missing because I'm not very familiar with the extended Euclidian algorithm
• The script could probably be reduced in size by 50% by using the stack much more efficiently (a good script compiler should have clever stack management)
• Disclaimer: Don't use the scripts on mainnet. As I said, it's not tested; and even if it works there might be ways to exploit it.

Altstack: n

GET_ORDER:
OP_FROMALTSTACK ; n (from altstack)
OP_DUP          ; n n
OP_TOALTSTACK   ; n

ADD_MODULO:  ; a b
OP_ADD       ; (a+b)
GET_ORDER    ; (a+b) n
OP_MOD       ; (a+b mod n)

SUB_MODULO:  ; a b
OP_SUB       ; (a-b)
GET_ORDER    ; (a-b) n
OP_ADD       ; (a-b + n)
GET_ORDER    ; (a-b + n) n
OP_MOD       ; (a-b mod n)

MUL_MODULO   ; a b
OP_MUL       ; (a*b)
GET_ORDER    ; (a*b) n
OP_MOD       ; (a*b mod n)

DUP_POINT    ; x y
OP_2DUP      ; x y x y

SWAP_POINT   ; xp yp xq yq
OP_2SWAP     ; xq yq xp yp

OVER_POINT   ; xp yp xq yq
OP_2OVER     ; xp yp xq yq xp yp

2DUP_POINT   ; xp yp xq yq
OVER_POINT   ; xp yp xq yq xp yp
OVER_POINT   ; xp yp xq yq xp yp xq yq

DROP_POINT      ; x y
OP_DROP OP_DROP ;

POINT_NEGATION:  ; x y
OP_0             ; x y 0
OP_SWAP          ; x 0 y
SUB_MODULO       ; x (-y mod n)

IS_POINT_AT_INF:       ; x y
OP_NOTIF OP_0 OP_ENDIF ; x (0 or y)
OP_SWAP                ; (0 or y) x
OP_NOTIF OP_0 OP_ENDIF ; (0 or y) (0 or x)
OP_OR                  ; (0 or 1), 0 if (x == 0 and y == 0)
OP_INVERT              ; 1 if (x == 0 and y == 0)
                       ; 1 if point at infinity

POINT_ADDITION_SLOPE:   ; xp yp xq yq
OP_ROT                  ; xp xq yq yp
SUB_MODULO              ; xp xq (yq-yp mod n)
OP_SWAP                 ; xp (yq-yp mod n) xq
OP_ROT                  ; (yq-yp mod n) xq xp
SUB_MODULO              ; (yq-yp mod n) (xq-xp mod n)
MULTIPLICATIVE_INVERSE  ; (yq-yp mod n) (xq-xp mod n)^(-1)
MUL_MODULO              ; (yq-yp mod n)/(xq-xp mod n)
                        ; slope

POINT_DOUBLING_SLOPE:  ; x y
OP_SWAP                ; y x
OP_DUP                 ; y x x
MUL_MODULO             ; y (x^2 mod n)
OP_3 MUL_MODULO        ; y (3 * x^2 mod n)
OP_SWAP                ; (3 * x^2 mod n) y
OP_DUP ADD_MODULO      ; (3 * x^2 mod n) (2 * y mod n)
MULTIPLICATIVE_INVERSE ; (3 * x^2 mod n) (2 * y mod n)^(-1)
MUL_MODULO             ; (3 * x^2 mod n)/(2 * y mod n)
                       ; slope

APPLY_SLOPE:      ; xp yp xq yq slope
OP_DUP            ; xp yp xq yq slope slope
OP_DUP MUL_MODULO ; xp yp xq yq slope (slope^2 mod n)
OP_5 OP_ROLL      ; yp xq yq slope (slope^2 mod n) xp
OP_4 OP_ROLL      ; yp yq slope (slope^2 mod n) xp xq
OP_OVER           ; yp yq slope (slope^2 mod n) xp xq xp
ADD_MODULO        ; yp yq slope (slope^2 mod n) xp (xq+xp mod n)
OP_ROT OP_SWAP    ; yp yq slope xp (slope^2 mod n) (xp+xq mod n)
SUB_MODULO        ; yp yq slope xp (slope^2 - xp - xq mod n)
                  ; yp yq slope xp xr
OP_DUP            ; yp yq slope xp xr xr
OP_ROT OP_SWAP    ; yp yq slope xr xp xr
SUB_MODULO        ; yp yq slope xr (xp - xr mod n)
OP_ROT            ; yp yq xr (xp - xr mod n) slope
MUL_MODULO        ; yp yq xr (slope * (xp - xr) mod n)
OP_3 OP_OVER      ; yq xr (slope * (xp - xr) mod n) yp
SUB_MODULO        ; yq xr ((slope * (xp - xr)) - yp mod n)
                  ; yq xr yr
OP_ROT OP_DROP    ; xr yr

POINT_ADDITION:      ; xp yp xq yq
DUP_POINT            ; xp yp xq yq xq yq
IS_POINT_AT_INF      ; xp yp xq yq (rhs = point at infinity?)
OP_IF
  OP_DROP OP_DROP    ; xp yp
OP_ELSE
  OVER_POINT         ; xp yp xq yq xp yp
  IS_POINT_AT_INF    ; xp yp xq yq (lhs = point at infinity?)
  OP_IF
    OP_ROT OP_DROP   ; xp xq yq
    OP_ROT OP_DROP   ; xq yq
  OP_ELSE
    2DUP_POINT           ; xp yp xq yq xp yp xq yq
    POINT_ADDITION_SLOPE ; xp yp xq yq slope
    APPLY_SLOPE          ; xr yr
  OP_ENDIF
OP_ENDIF

POINT_DOUBLING:      ; x y
DUP_POINT            ; x y x y
DUP_POINT            ; x y x y x y
POINT_DOUBLING_SLOPE ; x y x y slope
APPLY_SLOPE          ; xr yr

DOUBLE_ADD:  ; xq yq xn yn k
OP_2         ; xq yq xn yn k 2
OP_MOD       ; xq yq xn yn (k odd?)
OP_IF            ; xq yq xn yn
  SWAP_POINT     ; xn yn xq yq
  OVER_POINT     ; xn yn xq yq xn yn
  POINT_ADDITION ; xn yn xq_new yq_new
  SWAP_POINT     ; xq_new yq_new xn yn
OP_ENDIF
POINT_DOUBLING   ; xq_new yq_new xn_new yn_new

DOUBLE_ADD_SHIFT:  ; xq yq xn yn k
OP_DUP             ; xq yq xn yn k (k is >= 0?)
OP_IF              ; xq yq xn yn k
  OP_0             ; xq yq xn yn k 0
  OP_2ROT          ; xn yn k 0 xq yq
  OP_2ROT          ; k 0 xq yq xn yn
  OP_5 OP_PICK     ; k 0 xq yq xn yn k
  DOUBLE_ADD       ; k 0 xq_new yq_new xn_new yn_new
  OP_4 OP_ROLL     ; k xq_new yq_new xn_new yn_new 0
  OP_DROP          ; k xq_new yq_new xn_new yn_new
  OP_4 OP_ROLL     ; xq_new yq_new xn_new yn_new k
OP_ENDIF
OP_2 OP_DIV        ; rshift by 1 (maybe OP_RSHIFT does the job as well?)

2DOUBLE_ADD_SHIFT: DOUBLE_ADD_SHIFT DOUBLE_ADD_SHIFT
4DOUBLE_ADD_SHIFT: 2DOUBLE_ADD_SHIFT 2DOUBLE_ADD_SHIFT
8DOUBLE_ADD_SHIFT: 4DOUBLE_ADD_SHIFT 4DOUBLE_ADD_SHIFT
16DOUBLE_ADD_SHIFT: 8DOUBLE_ADD_SHIFT 8DOUBLE_ADD_SHIFT
32DOUBLE_ADD_SHIFT: 16DOUBLE_ADD_SHIFT 16DOUBLE_ADD_SHIFT

POINT_MULTIPLICATION:  ; x y k
OP_0 OP_0 OP_0         ; x y k 0 0 0
OP_2ROT                ; k 0 0 0 x y
OP_2 OP_ROLL OP_DROP   ; k 0 0 x y
OP_4 OP_ROLL           ; 0 0 x y k
32DOUBLE_ADD_SHIFT     ; xq_last yq_last xn_last yn_last (k, should equal 0 at this point)
OP_DROP                ; xq_last yq_last xn_last yn_last
DROP_POINT             ; xq_last yq_last

MULTIPLICATIVE_INVERSE:  ; TODO

Edit: Actually, I already see quite some mistakes. But it still helps estimating the size of such script.

 

[Norway]

It's smaller than a twetch