Re: [bitcoin-dev] Civ Kit: A Peer-to-Peer Electronic Market System

>In traditional finance, front-running is defined as "entering into an equity trade, options or future contracts with advance knowledge of a block transaction that will influence the price of the underlying security to capitlize on the trade" [0]. In Bitcoin/Civkit parlance, a front-running could b

[bitcoin-dev] Release of bitcoin-s 1.9.1

Today we are executed to release 1.9.1 of bitcoin-s. Bitcoin-s is a set of bitcoin libraries written in Scala. We adhere to the Discreet Log Contract specification . For more information please see bitcoin-s.org or read the release notes for the 1.9

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

FWIW, the initial use case that I hinted at in the OP is for lightning. The problem this company has is they offer an inbound liquidity service, but it is common after a user purchases liquidity, the channel goes unused. This is bad for the company as their liquidity is tied up in unproductive ch

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

>On the other hand, the above, where the oracle determines *when* the fund can be spent, can also be implemented by a simple 2-of-3, and called an "escrow". I think something that is underappreciated by protocol developers is the fact that multisig requires interactiveness at settlement time. The

Re: [bitcoin-dev] Recurring bitcoin/LN payments using DLCs

Hey ZmnSCPxj, I thought about this for a few days and I think you are right. In the case of recurring payments this is identical to nLocktime. When doing recurring payments with this scheme, you probably want to rate limit subsequent UTXOs _with_ nlocktimes to make sure a malicious Netflix can't w

[bitcoin-dev] Recurring bitcoin/LN payments using DLCs

DLCs are typically thought to be used for betting. Alice & Bob want to speculate on an event, and have bitcoin payouts rewarded to them if they bet correctly. The oracle determines what event occurred and produces attestations representing that outcome. Recently I had a conversation with a friend

[bitcoin-dev] Bitcoin-s 1.8 released with DLCs negotiation via Tor

Hi all, We released 1.8 today of bitcoin-s. This includes support for opening DLCs over tor. This makes the UX much simpler to enter into a DLC with your counterparty. As part of this release, we wrote two detailed examples of entering into 1. A wallet election example

[bitcoin-dev] Bitcoin-s v0.4.0 release

Hi all, We just released v0.4.0 of bitcoin-s. Major features include - Wallet overhaul to support all common script types - Sqlite and postgres database support for all projects - Improved robustness of the neutrino node - BIP340 Schnorr Signatures implemented in Java (Bouncy Castle) - Wallet re

[bitcoin-dev] Bitcoin-s v0.3.0 release

Hi all We just released v0.3.0 of bitcoin-s. Bitcoin-s is a loosely coupled set of cryptocurrency libraries for the JVM. They work well together, but also can be used independently. This project's goal is NOT to be a full node implementation, rather a set of scalable cryptocurrency libraries that

[bitcoin-dev] [Annoucement] Discreet Log Contract Protocol Specification

Hi all, Suredbits and Crypto Garage have begun to work on a specification for using discreet log contracts in a safe, private and interoperable way. We are writing to the mailing list to inform and solicit feedback for the protocol specification so that we can -

Re: [bitcoin-dev] [Lightning-dev] Continuing the discussion about noinput / anyprevout

> I don't find too compelling the potential problem of a 'bad wallet designer', whether lazy or dogmatic, misusing noinput. I think there are simpler ways to cut corners and there will always be plenty of good wallet options people can choose. In my original post, the business that I am talking ab

Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

I do have some concerns about SIGHASH_NOINPUT, mainly that it does introduce another footgun into the bitcoin protocol with address reuse. It's common practice for bitcoin businesses to re-use addresses. Many exchanges [1] reuse addresses for cold storage with very large sums of money that is store

Re: [bitcoin-dev] Disallow insecure use of SIGHASH_SINGLE

Do you have any thoughts on expanding this to SIGHASH_NONE? Perhaps someone else on the dev list can enlighten me, but is there a current use case for SIGHASH_NONE that would suffer from it being non standard? -Chris On Thu, May 31, 2018 at 1:53 PM, Johnson Lau via bitcoin-dev < bitcoin-dev@list

Re: [bitcoin-dev] Two Drivechain BIPs

>As far as I can tell there is no opportunity cost to casting a malicious vote, no repercussions, and no collective action barrier that needs to be overcome. There is another interesting analysis on BMM and drivechains from /u/almkglor on reddit

Re: [bitcoin-dev] Sidechains: Mainstake

>For each sidechain ID, for each mainchain block, at most one sidechain block header may be published. In addition, the sidechain block header published on the mainchain blocks may only be published by the stake lottery winner from the end of the previous block. What happens if the stake winner di

Re: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)

Hi ZmnSCPxj, However, a lockbox on one chain is a WT on the other > chain. We can create a free lockbox on Ess, then use that lockbox as > a WT on Tee, inflating TeeCoin. I'm not sure if I follow what you are saying here. What do you mean by 'free lockbox'? I was assuming that I created an arbi

Re: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)

Hi ZmnSCPxj, Basically, in case of a sidechain fork, the mainchain considers the longest > chain to be valid if it is longer by the SPV proof required length. In the > above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E) > longer than the other sidechain fork that ended at d. >

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

rule of only one h* per sidechain per > block, sidechains need just a merkle tree path, but they don't necessarily > know where it is. They must store extra [?] data to help them find the > data's location? > > > On 7/12/2017 2:02 PM, Chris Stewart via bitcoin-dev wrote:

Re: [bitcoin-dev] Updating the Scaling Roadmap

Hi Greg, The safest way to ensure everyone's protection to make sure *no one can do anything*. Then we will ALL be safe ;). >If so, please leave, you are compromising Bitcoin's security. Ok, let's calm down. >If I design a car that has a button that randomly causes the brakes to give out if pre

Re: [bitcoin-dev] Updating the Scaling Roadmap

Hi Greg, >Here, you admit that the security of the sidechains allows miners to steal bitcoins, something they cannot do currently. If I put my coins in an anyone can spend output, a miner will take them. They can do this today. I suggest you try it if you don't believe me :-). You have to be more

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

Hi Russell/ZmnSCPxj, I think you guys are right. The only problem I can see with it is replaceability of the bribe transaction. If the 'Bribe' is the fee on the transaction it isn't clear to me what the best way to replace/remove it is. If we have the amount in the output (instead of the fee) we

Re: [bitcoin-dev] Updating the Scaling Roadmap

Concept ACK. I think you are overstating the readiness of drivechains though. I think the optimistic estimate for drivechains to be ready for bitcoin core is a year out from today. More likely the date should be early 2018. Still a lot of work to be done! :-) Also I don't know if I would put a ha

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

Hi ZmnSCPxj, In my scheme, if you read carefully through the pseudocode, a block list > node is valid only if its block is valid. > It seems this is a contradiction against the "blind" part of blind merge mining. How can a bitcoin blockchain node enforce this without tracking the sidechain? Bas

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

>I don't understand this part. In my scheme, a sidechain cannot reorganize unless the mainchain reorganizes, since the consensus loop only cares about matching the current block; it ignores splits and does not consider them valid. Maybe I am misunderstanding you, but isn't this a flaw not a featu

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

Hi Russell, >I haven't really been following the drivechain discussion; I have found the documentation about how drivechains are supposed to work scattered and difficult to follow. So, without advocating for or against this proposal, I'd also suggest that adding an opcode is not the best way to im

[bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

BIP: Layer: Consensus (Soft fork) Title: OP_BRIBEVERIFY Author: Chris Stewart Status: Draft Type: Standards Track Created: 2017-06-27 ==Abstract== This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin scripting system that allows for a user to bribe a miner to includ

Re: [bitcoin-dev] Drivechain -- Request for Discussion

> > Since the sidechain has the sidechain BMM headers that they want the LD > (bribe) data for, I think that they could specifically request LD data > relevant only to that sidechain by providing a list of hashes to the > mainchain, and the mainchain can return a list of boolean values telling > th

Re: [bitcoin-dev] Drivechain -- Request for Discussion

>OP_RETURN I think it is redundant here to have the , we can implicitly assume what the sidechain_id is since we have a fixed set of drivechains. I.e. mining reward is index 0, mimblewimble sidechain is index 1, etc. CryptAxe has specific indexes defined already in his implementation: https://gi

Re: [bitcoin-dev] I do not support the BIP 148 UASF

>Regarding this last point I was under the impression that if Segwit did not activate by November then core was going to move on, is that no longer the case, does the core team plan on trying to activate Segwit in some other way? Since block size seems to be the controversial issue, AFAIK we *coul

Re: [bitcoin-dev] I do not support the BIP 148 UASF

>Criticizing 148 without suggesting a specific alternative leaves the community in disarray. I really disagree with this sentiment, you don't need to provide alternatives to criticize a technical proposal. I don't like this "active segwit at all costs" theme that has been going around the communit

Re: [bitcoin-dev] Requirement for pseudonymous BIP submissions

gard. > > Simple, yet effective. I would actually even go a step further and say > that all BIPs should be done this way as a matter of procedure, I can't > think of a downside. > > > On Sat, Mar 18, 2017 at 10:46 AM Chris Stewart via bitcoin-dev < > bitcoin-dev@list

[bitcoin-dev] Requirement for pseudonymous BIP submissions

As everyone in the Bitcoin space knows, there is a massive scaling debate going on. One side wants to increase the block size via segwit, while the other side wants to increase via hard fork. I have strong opinions on the topic but I won’t discuss them here. The point of the matter is we are seeing