Gold collapsing. Bitcoin UP.

[rocks]

@Richy_T yes that is how the transaction gets executed after it is built and posted.

I am asking how do Alice and Bob build the transaction in the first place, since they both need to contribute towards it but need to do so independently and securely from each other. i.e. How do two separate people independently sign their spendable outputs into the same transaction?

 

[cypherdoc]

Have been reading up more on OP_DATASIGVERIFY and BUIP078 and it is not clear to me how two parties can securely build a transaction. BUIP078 enables a transaction that pays one of two or more parties based on some Oracle's input. A simple example is: "if 'oracle data states X' then 'pay to Alice' else 'pay to Bob'".

What I am struggling to understand is how can Alice and Bob build this transaction between themselves without relying on a trusted 3rd party?

A common example for how I think BUIP078 would be used is: 1) Alice pays 1 BTC into the transaction by signing 1 BTC worth of spendable output, 2) Bob pays 1 BTC into the transaction by signing 1 BTC of spendable outputs, 3) The winner gets 2 BTC.

Since both Alice and Bob need to spend into this transaction, they need to be able to do so securely in a manner where they sign the complete transaction. But how do they do this independently and without access to the other's coins?

Without the ability to do so they would have to trust a 3rd party exchange, by for example both paying 1 BTC to a 3rd party who then generates the above transaction from a single output. This workflow is not ideal.

Does anyone know how Alice and Bob could create the above transaction without an intermediary? This seems to require the ability for Alice to first build her part of the transaction with: 1) her output is spent and signed, 2) the conditional transaction's structure and rules signed and 3) her winning address signed. Then Bob would take that and add: 1) his matching output spent and signed, 2) his winning address signed. The combination would then become a fixed transaction sent to the P2P network.

Is this possible? If not then how do Alice and Bob create such a transaction without trusting a 3rd party to do so?

This is how Armory builds multisig lock boxes - - >email :

https://www.bitcoinarmory.com/tutorials/armory-advanced-features/lockbox/spend-lockbox/

 

[rocks]

@cypherdoc thanks for the links, but multi-sig lockboxes are a different scenario from what I am asking about.

With multi-sig multiple people contribute their public keys to create a new address that can receive funds and which requires m-of-n signatories to spend. Once all people provide their public key details a new multi-sig receiving address is created. However in this process at no point are any Bitcoins spent. Yes spending from the multi-sig address requires multiple signatories, but spending is a secure process because security was built into the multi-sig address itself at the time the address was created and before any coins were sent to it.

The conditional transaction scenario I outlined is very different. Here multiple participants need to spend Bitcoins into a new transaction in order to create the transaction itself. In the example I gave Alice spends 1 BTC into the transaction and then Bob spends another 1 BTC into the transaction, and the winner gets 2 BTC sent to where they specified on their side of the IF THEN ELSE statement.

The problem here is someone has to spend their coins first and trust that the other finishes building the transaction honestly. Either Alice has to spend 1 BTC into an incomplete transaction with Bob then finishing it, or vise versa. This exposes the person going first.

If this can't be done then you have to rely on a trusted 3rd party where Alice and Bob first send 1 BTC each to the trusted 3rd party and that trusted 3rd party then creates the conditional transaction and publishes that to the P2P network. I am trying to avoid requiring a trusted 3rd party and instead allow Alice and Bob to build a conditional transaction directly with each other.

Does that make sense?

 

[cypherdoc]

i wasn't meaning to say this was THE template to accomplish what you want to do. it was more that this lockbox is constructed through email techniques and apparently is working right now on mainnet. so that's one point. the other point is that it seems to me that perhaps a similar sequence of building a lockbox, funding it, and then spending from it COULD be used to accomplish what you want to do. like maybe constructing a 3 of 3 p2sh multisig lockbox, then funding it with 1 BTC each from Alice and Bob, who also then sign their portions of the lockbox, and then having the oracle be the 3rd potential sig hidden behind a redeem script that is time dependent on the outcome of an event; like maybe the temp being below 30 degrees on a particular date. the data behind the redeem script could be an if, then type of statement which decides where the coins go. the problem with this is that the info is relatively simple and potentially brute forced, altho it's nearly impossible to distinguish just what exactly p2sh tx's are doing, with the participants (Alice & Bob) being the only one's who know it's true purpose. the redeem script is merely a hash afterall. the point is that if the 3rd sig could be constructed to be oracle dependent, then it could accomplish what you want. anyways, it's just an idea that probably has holes so maybe you could elaborate.
[doublepost=1521526292,1521525144][/doublepost]not sure if this was posted already but this is really a good video once again from Rick regarding OP GROUP. i agree with it's main thrust:
[doublepost=1521526942][/doublepost]why is it that over and over we see that even lawmakers see that BTC has problems, esp as money, yet core devs and their trolls cannot?:

Bitcoin itself has technical and economic limitations that hinder its use as a medium of exchange. Transaction processing time and fees on the Bitcoin network keep increasing and render Bitcoin uneconomical for common purchases.

https://dailyhodl.com/2018/03/19/us-congress-releases-extraordinary-report-praising-cryptocurrency-and-blockchain-technology/

 

[cypherdoc]

What an asshole:

 

[79b79aa8]

@rocks why couldn't it be something simple along the lines of:

IF (A signs AND B signs) THEN prepare two 2-of-out-3 transactions with one signature filled in: tx1 in case A wins, tx2 in case B wins.

When the facts come in via the Oracle, a second sig gets generated which triggers either tx1 or tx2. The other tx never gets completed.

 

[majamalu]

The Blockstream phenomenon is not unique to Bitcoinland.

Taleb is spot on:

The Business of Intervention

Some rules. People who have always operated without skin in the game (or without their skin in the right game) seek the complicated, centralized, and avoid the simple like the pest. Practitioners on the other hand have opposite instincts, looking for the simplest heuristics.

People who are bred, selected, and compensated to find complicated solutions do not have an incentive to implement simplified ones

And it gets more complicated as the remedy has itself a skin in the game problem

This is particularly acute in the meta-problem when the solution is about solving this very problem

In other words, Many problems in society come from the interventionism of people who sell complicated solutions because that’s what their position and training invites them to do. There is absolutely no gain for someone in such a position to propose something simple: you are rewarded for perception not results. They pay no price for the side effects that grow nonlinearly with such complications.

Whole article

 

[Zarathustra]

Yes, and Joseph Tainter goes one step further than Nassim Taleb. Society means problem solving by investing in additional complexity, which always leads to collapse sooner or later, because of the diminishing return on additional investment in additional complexity.The invention of the society itself is the problem.

https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-1073#post-49110

 

[Richy_T]

So where would one start if one wanted to work on a BIP type thing for merchant-initiated payment requests? I figure BUIP wouldn't be right as this wouldn't be a BU thing.

 

[freetrader]

@Richy_T : I don't see anything wrong with doing it as a BUIP first (these don't have to be voted on immediately, they can mature), but alternatives could be:

• just write it up in BIP- or BUIP-like style and publish in a repo of your own (it's what BitPay and others have done for their proposals recently)
  
• make it a BIP if it's agnostic to the BTC / BCH split, post it to bitcoin-dev and bitcoin-ml for discussion
  
• write it up in whatever format and publish it on bitcoin-ml (Cash mailing list) if you don't care about involving the BTC crowd

 

[Richy_T]

I'll give it a go. It should be fairly crypto-agnostic. I'm sure extra input will be good as there are likely aspects I haven't considered yet.

Actually, the more I think about it, the more it starts to look like RSS.

 

[lunar]

Snowden laying down some wisdom, and bashing Core's slow pace of evolution.

[doublepost=1521764576][/doublepost]Satoshi's Vision Conference livestream for those of you not lucky enough to attend.
Very best of luck If you're presenting.

 

[rocks]

i wasn't meaning to say this was THE template to accomplish what you want to do. it was more that this lockbox is constructed through email techniques and apparently is working right now on mainnet. so that's one point. the other point is that it seems to me that perhaps a similar sequence of building a lockbox, funding it, and then spending from it COULD be used to accomplish what you want to do. like maybe constructing a 3 of 3 p2sh multisig lockbox, then funding it with 1 BTC each from Alice and Bob, who also then sign their portions of the lockbox,

Yes, the model where Alice and Bob communicate directly with one another, share public keys, and use knowledge of both public keys to build a transaction (be it a multi-sig lock box or conditional transaction) works perfectly fine for building the output side. However these models require Alice and Bob to communicate directly with one another, which requires them to both be online, communicate directly, etc.

If Alice and Bob do not have to communicate with each other at all, that opens up some very interesting new use cases, which I think could be killer apps. The output side might be solved by relying on the Oracle to help complete payments between the two, but that has downsides in adding trust on the Oracle and there are new legal implications if the Oracle is directly involved in Alice's and Bob's transaction.

However the real problem is how do Alice and Bob independently fund the same conditional transaction with their own inputs without relying on a 3rd party.

The original Bitcoin had multiple signature types, including SIGHASH_ANYONECANPAY, this mode only signed the current input and the specified outputs, which effectively meant different parties could independently fund the same transaction without having to trust anyone else. It was not used since there was no practical usage for it with standard transactions, but the signature mode was still there.

The combination of conditional transactions plus ANYONECANPAY creates some new interesting use cases. However it looks that Bitcoin Cash as part of the BUIP-HF replay protection might have depricated ANYONECANPAY as a useful signature mode. Below are the relevant links and what I think they mean.

Does anyone from BU know if this is correct or if my interpretation is wrong and standard ANYONECANPAY is still available. Thanks!

Original Bitcoin
https://bitcoin.org/en/developer-guide#signature-hash-types

SIGHASH_ALL|SIGHASH_ANYONECANPAY signs all of the outputs but only this one input, and it also allows anyone to add or remove other inputs, so anyone can contribute additional satoshis but they cannot change how many satoshis are sent nor where they go.

https://en.bitcoin.it/wiki/OP_CHECKSIG#Procedure_for_Hashtype_SIGHASH_ANYONECANPAY

Think of this as "Let other people add inputs to this transaction, I don't care where the rest of the bitcoins come from."

SegWit Coin
However it looks that BIP 143 altered the behavior of SIGHASH_ANYONECANPAY as part of the SegWit changes, and instead made it so none of the inputs were protected by the signature. Effectively using this signature mode for segwit, which is a hard fork but the HF was possible because the signature mode was not used currently.

https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki

hashPrevouts:
If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all input outpoints;
Otherwise, hashPrevouts is a uint256 of 0x0000......0000.

Bitcoin Cash
Unfortunately, it looks that Bitcoin Cash, as part of the BUIP-HF replay protection changes, also used the new BIP 143 signature digest method and in the process lost the use of ANYONECANPAY for Bitcoin Cash.

https://github.com/Bitcoin-ABC/bitcoin-abc/blob/master/doc/abc/replay-protected-sighash.md

hashPrevouts
If the ANYONECANPAY flag is not set, hashPrevouts is the double SHA256 of the serialization of all input outpoints;
Otherwise, hashPrevouts is a uint256 of 0x0000......0000.

Is my understanding above accurate? Or am I reading too much into this and ANYONECANPAY is still functional in Bitcoin Cash?

 

[MarkBLundeberg]

@rocks I happened to be looking in detail at this recently, and my understanding is that ANYONECANPAY still maintains full functionality. The changes were only made to fix the quadratic hashing problem and don't change the functionality. (in bitcoin cash, all post-fork transactions are 100% free of the problem -- nice!)

If we look at the Implementation section of the bitcoin-ABC link (which matches bitcoin-ABC's code AFAICT), we see:

Normal inputs (ANYONECANPAY unset) have the input included *twice* in the signed hash -- once in hashPrevouts, and once more in the body of the signed data.

ANYONECANPAY inputs have the input included only once in the signed hash -- hashPrevouts gets replaced by 0000..00 but the input data still appears in the body of the signed data.

 

[rocks]

@MarkBLundeberg Ah, I see that now. Thank you very much for the explanation. My first interpretation was this was lost when hashPrevouts were zero'ed for ANYONECANPAY and this had something to do with transferring signatures off chain for segwit. Missed that input data is still included in the signed packet.

Anyway, that's why I asked, thanks again!

 

[cypherdoc]

Hey Andrew @theZerg, what's wrong with the vision of BCH becoming the next free standing world reserve currency, much like the dollar? Where everything is priced in BCH as the unit of account but with assets like stocks and bonds still held in trust with third party institutions?

Is it that it's a flawed system or that it just can't work?

 

[yrral86]

@cypherdoc

Why not allow ownership of assets to be tracked on the blockchain? They can still be priced in BCH. I'd rather be able to do p2p atomic swaps and get dividends paid directly to my wallet instead of allowing a brokerage to own my shares and promise to let me have any potential gains. I have to trust the company, but why force me to trust a 3rd party when we can build the technology to make it unnecessary?

That said, I could see that being a second wave of innovation that might be best delayed until we are at least approaching world reserve status. Why would people accept the BCH blockchain as the official ledger for such transactions before it is the official ledger for currency transactions?

 

[cypherdoc]

>Why not allow ownership of assets to be tracked on the blockchain? They can still be priced in BCH. I'd rather be able to do p2p atomic swaps and get dividends paid directly to my wallet instead of allowing a brokerage to own my shares and promise to let me have any potential gains. I have to trust the company, but why force me to trust a 3rd party when we can build the technology to make it unnecessary?

b/c the power of Sound Money means you can trust the financial incentives that will drive those brokerages to be honest with your assets; just like it drives miners to be honest in timestamping tx's as outlined in the WP 18x. IOW, there are no bailouts and those brokerages will have every reason/incentive to want to do a good/honest job to be paid in BCH just like i did when you subbed to my newsletter while paying me in BTC.

and if not, you can still sue them.

 

[cypherdoc]

OMG, unbelievable: https://twitter.com/protoncoin

 

[freetrader]

If that's not a scam, then it's surely an instance of

https://ask.metafilter.com/236079/Now-you-have-n-problems

Then again, I wish them much luck with their ICO, hopefully that can convert into more great services from ProtonMail.