1 2018-02-14 05:57:49 <stoopkid> hi, is there any mechanism for trustless exchange between omni assets and btc that only uses standard btc transaction features?
 2 2018-02-14 06:05:09 <Dizzle> stoopkid: I doubt it
 3 2018-02-14 06:05:17 <Dizzle> but don't actually know
 4 2018-02-14 06:05:23 <windsok> I think Omni has a DEX http://omniexplorer.info/dex.aspx
 5 2018-02-14 06:06:46 <Dizzle> windsok: yea, but I think that's implemented in the Omni layer instead of the Bitcoin contracts alone
 6 2018-02-14 06:07:03 <windsok> but all Omni transactions are bitcoin transactions
 7 2018-02-14 06:09:45 <windsok> http://omniexplorer.info/lookuptx.aspx?txid=6dcd8eedf2f01480833ecbeb7998c09d38faf708b8f9fe0af525165c3eafd094
 8 2018-02-14 06:09:47 <windsok> vs
 9 2018-02-14 06:09:55 <windsok> https://btc.com/6dcd8eedf2f01480833ecbeb7998c09d38faf708b8f9fe0af525165c3eafd094
10 2018-02-14 06:10:06 <windsok> uses OP_RETURN
11 2018-02-14 06:11:24 <stoopkid> how does the distributed exchange work i'm having trouble finding concrete technical info
12 2018-02-14 06:14:20 <windsok> I'm pretty sure it's the same or very similar to how counterparty works. They might have better docs https://counterparty.io/docs/
13 2018-02-14 06:14:56 <windsok> Note that the way both omni and counterparty are implemented does not really scale.
14 2018-02-14 06:14:59 <gmaxwell> Today on the internets: people investing in altcoins by people too inept to setup their own p2p network. :P
15 2018-02-14 06:17:33 <stoopkid> windsok: what i was originally thinking was that you should just be able to use a 2-of-2 multisig address between the counterparties with presigned "refund" tx's before they send their assets there to make sure they can still pull them out in case the exchange fails to go through
16 2018-02-14 06:18:40 <stoopkid> since it's just on the btc blockchain it should basically be like exchanging bitcoins for bitcoins, unless there happen to be any peculiar details of the omni protocol that get in the way of that
17 2018-02-14 06:19:21 <stoopkid> ideally it would be a scriptless script (to w/e extent omni could allow it) to minimize potential points of failure since i'm not really a security expert
18 2018-02-14 09:08:48 <RainMan28> hey gmaxwell, saw your comment on reddit regarding bitpay and BIP70. Do you think their payment protocol is a bad idea?
19 2018-02-14 09:15:54 <stoopkid> anybody have any references on what goes in the data for omni class C tx's?
20 2018-02-14 09:18:10 <gmaxwell> RainMan28: well I've seen several people with long lists of complaints and shortcomings in BIP70, and pretty much none of them appear to be addresses except the send on one side thing. And at least in my brief glance at what they posted, they didn't answer the criticial questions that caused bip70 to have the always broadcast to the network design: things like how do you handle the case where the far
21 2018-02-14 09:18:16 <gmaxwell> side never sends to the network, or how do you distinguish a cancellation vs a new payment.
22 2018-02-14 09:18:19 <gmaxwell> though I didn't look at it carefully.
23 2018-02-14 09:18:38 <gmaxwell> I also don't bother wasting my time on any bitcoin protocols that don't want to write a bip and take public comment, -- waste of time.
24 2018-02-14 09:20:01 <RainMan28> ah gotcha
25 2018-02-14 09:20:15 <gmaxwell> maybe it turns out fine, --- would be hard to be that much worse than BIP70 IMO. :)
26 2018-02-14 09:21:35 <RainMan28> Oh yeah, I definitely empathize with them having a need for it when the fees were really high. Having an ATM network, we experienced a lot of the same issues they were experiencing when customers would try to sell their BTC for cash. Sending the wrong amounts and then requiring refunds, and losing $30 in sending and $30 in getting a refund, etc, etc
27 2018-02-14 09:22:06 <gmaxwell> yes, indeed, though BIP70 just didn't do anything helpful there.
28 2018-02-14 09:22:46 <RainMan28> BIP70 was more about how to make a direct payment to their node vs having it be broadcast across the network?
29 2018-02-14 09:23:07 <gmaxwell> That is why they said they forced BIP70 but bip70 doesn't do that.
30 2018-02-14 09:23:07 <RainMan28> there are so many BIPs lately, it is hard to keep up
31 2018-02-14 09:23:28 <gmaxwell> Every BIP70 implementation that I'm aware of sends to the network.
32 2018-02-14 09:24:15 <gmaxwell> (There was a big argument between gavin and sipa when it was proposed, sipa and others wanting it to be specified to not send to the network;  but to do that you have to address how a bunch of corner cases are handled and gavin didn't want to deal with that.)
33 2018-02-14 09:24:40 <RainMan28> oh very interesting
34 2018-02-14 09:25:22 <gmaxwell> like what happens if the txn is never sent to the network? when do you return the txouts to the wallet?  What if the far side rejects it? How do you know this and know when you make a replacement to be sure to conflict the original?
35 2018-02-14 09:25:49 <gmaxwell> If the reason they'd reject it is fees, they probably should be able to communicate a minimum feerate in the request or you might loop forever. :P
36 2018-02-14 09:34:35 <RainMan28> oh those are good points
37 2018-02-14 09:38:14 <Megumiin> Bitpay did relent and they now offer a non-payment protocol payment flow
38 2018-02-14 09:39:04 <Megumiin> But it looks like it might be limited to non-javascript enabled browsers
39 2018-02-14 09:40:06 <gmaxwell> Megumiin: oh thats great to hear, (first statement)
40 2018-02-14 10:15:36 <stoopkid> hello, can anybody provide a reference on the data structure used in omni class C transactions?
41 2018-02-14 10:40:30 <wumpus> Megumiin: awesome news? how do they limit it to non-javascript-enabled browsers?
42 2018-02-14 10:40:53 <Megumiin> <noscript> tags most likely
43 2018-02-14 10:41:04 <wumpus> in that case, blocking javascript for just the bitpay site will work
44 2018-02-14 10:41:54 <Megumiin> not exactly userfriendly
45 2018-02-14 10:42:17 <wumpus> but better for privacy, I guess
46 2018-02-14 10:42:21 <gmaxwell> someone could publish a browser extension. :P
47 2018-02-14 10:42:27 <Megumiin> I assume they only added it because of their tor issues
48 2018-02-14 10:42:53 <Megumiin> can confirm it's noscript
49 2018-02-14 10:43:55 <wumpus> ah yes, instead of fixing the fetching of payment requests over tor
50 2018-02-14 10:44:03 <gmaxwell> pay-bitpay-bits
51 2018-02-14 10:45:16 <wumpus> not that the only problem was over tor, bitcoin wallet for android had trouble using/paying the payment requests from bitpay even over plainnet
52 2018-02-14 10:45:44 <Megumiin> but this doesn't change that for them
53 2018-02-14 10:45:47 <Megumiin> since they still run js
54 2018-02-14 10:45:59 <wumpus> right
55 2018-02-14 10:46:34 <wumpus> discoverability is an issue too - who thinks of disabling js, when they have a payment issue
56 2018-02-14 10:47:13 <wumpus> at least I would never have discovered that if it wasn't said here
57 2018-02-14 13:01:11 <wumpus> I thought I was going to be able try it out, but the VPS provider has moved to coingate instead of bitpay
58 2018-02-14 13:41:34 <wumpus> maybe next time I order pizza, if takeaway is still with bitpay
59 2018-02-14 13:43:15 <Megumiin> better order fast before bitpay bleeds all customers to alternatives
60 2018-02-14 13:48:59 <wumpus> heh
61 2018-02-14 22:51:57 <Azelphur> So, trying to use bitcoinds rpc interface to generate an address, bitcoin-cli help seems to have no mention of getnewaddress (or anything like it), the docs say they exist, but on my installation, they don't. Has this functionality been removed? starting to wonder if the ArchLinux package has been messed with, or something.
62 2018-02-14 23:43:48 <Azelphur> Figured it out, archlinux systemd script starts bitcoind with -disablewallet
63 2018-02-14 23:56:27 <mlz> lol