Re: [bitcoin-dev] CHECKSEQUENCEVERIFY - We need more usecases to motivate the change
Hi Peter, On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote: > So we need to make the case for two main things: > > 1) We have applications that need a relative (instead of absolute CLTV) Lightning network needs RCLTV for bidireciontal payment channels without an explicit expiration date. Without a relative locktime, there is an economic tradeoff between longer channel expiry dates due to lower fees, and the time-value delay for non-cooperation. Due to this tradeoff, there is a risk that people may create channels with entities which they believe will be around in the future and act in a particular way. In other words, it is possible that people will attach reputation as part of their decision-making for channel creation. > 2) Additionally to RCLTV, we need to implement this via nSequence > > However I don't think we've done a good job showing why we need to > implement this feature via nSequence. BIP68 describes the new nSequence > semantics, and gives the rational for them as being a > "Consensus-enforced tx replacement" mechanism, with a bidirectional > payment channel as an example of this in action. However, the > bidirectional payment channel concept itself can be easily implemented > with CLTV alone. There is a small drawback in that the initial > transaction could be delayed, reducing the overall time the channel > exists, but the protocol already assumes that transactions can be > reliably confirmed within a day - significantly less than the proposed > 30 days duration of the channel. That example alone I don't think > justifies a fairly complex soft-fork that limits future upgrades; we > need more justification. The examples (including for Lightning Network) in BIP 112 provides a rationale for using a relative locktime which cannot be achieved using CLTV/hard-nLocktime alone. Without BIP 112, I agree the example in BIP 68 can also be done with nLocktime, but I think they sort of go together? However, there are some advantages to using some kind of relative locktime field such as nSequence over purely a script opcode. This is especially useful if one presumes some kind of long-term malleability fix which does not include directly signing the TXID of the parent transaction. It allows one to update dependent spending transactions after-the-fact; after transactions are signed. If there are unbroadcasted 2-of-2 multisig output transactions, where Tx1 is confirmed on-chain and off-chain Tx2 spends from Tx1, they can elect to spend Tx3a from the output of Tx2. Tx3a can have an nSequence value which requires a minimum of 100 block confirmations of Tx2 to elapse before Tx3a can be broadcast. As neither Tx2 or Tx3a have yet broadcast, they can elect to double-spend Tx2 with a new transaction with a lower nSequence value, e.g. Tx3b. This is important, as Tx2 will *always* be spendable so creating new revocation rules is useful for Tx2. I think Mark had once described the general idea is to have a similar separation of the opcode and the actual validation of block height in the codebase as nLockTime/OP_CLTV, as having pure validation in the script which may make things a bit ugly. > So, what else can the community come up with? nSequence itself exists > because of a failed feature that turned out to not work as intended; > it'd be a shame to make that kind of mistake again, so let's get our > semantics and use-cases in the BIPs and documented before we deploy. I agree. There may be some impact for future changes in Bitcoin, wrt BIP 68. For BIP 112, I think the impact could be minimal, but there may be future interpretations of nSequence. In particular, in the long term there may be some kind of need for some kind of "timestop" bit (to define whether to count relative blockheight or timestopped blockheight), which already consumes unreserved space. To account for more than one upgrade, the next future upgrade after BIP 68 may be implemented by taking the unused most significant bit in nSequence as defined in BIP 68 in combination with using up a version field bit. jl1202 had previously suggested doing this for BIP 68 itself: e7b394187fd96bd77a1c49f7c9b7a...@xbt.hk http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011358.html As-is, the only actual tradeoff made by BIP 68 is reducing range by half. I think BIP 68 works as-is or with burning an nVersion bit today, as it should allow for future (necessary) upgrades. -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness
As Segregated Witness will be merged soon as a solution for transaction malleability, especially with multi-party adversarial signatures, there may be an additional use case/functionality which is helpful for Lightning Network and possibly other Bitcoin use cases. This requires a new SIGHASH flag inside Segregated Witness which does not sign the input txid/index. Segwit is very helpful in resolving malleability in pretty much every case which matters. It is especially helpful in having solid and safe defaults for standard Bitcoin payments; it's very difficult to mess up if you are writing code in conjunction with the Bitcoin RPC API. However, it is very useful for LN if there is a certain level of outsourcibility for transactions without this 3rd party taking on onerous costs. In LN, there is a dispute resolution period established to prevent the counterparty from attesting an incorrect channel state (represented by broadcasting a timelocked transaction). In other words, if someone in a channel broadcasts an incorrect state, the output can be redeemed by a 3rd party (but this 3rd party is not a custodian, since the output goes to the other party in the channel). Ideally, a 3rd-party can be handed a transaction which can encompass all prior states in a compact way. For currently-designed Segregated Witness transactions, this requires storing all previous signatures, which can become very costly if individuals to thousands of channel state updates per day. This is very possible, as fees are near-zero, the value in atomizing all payments to many transactions becomes viable (reducing transaction/information costs). If individuals are doing tens of thousands of transactions per day, and one presumes something like 70-bytes of data per Commitment state in the channel, it quickly becomes infeasible to watch on behalf of many channels without material costs. This is especially necessary because it is highly desirable to make keeping track of these channels be very cheap, as it allows for more participants to be watching on one's behalf (reducing the chance of a 3rd party fail to watch). Further, it may reduce the need to notify the 3rd party for every single channel Commitment state, instead only providing the most recent one should provide sufficient information for all prior states (since the signature will apply for any type of transaction), making the only updated information the revocation secret/preimage. Without this SIGHASH flag, every single state would need to be contacted and updated with 3rd parties. With this SIGHASH flag, one could instead delegate outsourcing when one's client goes offline with a single message several hundred bytes in size, encompassing all prior states. Of course, while running a 24/7 full-node is encouraged, I suspect many people will not want to do so at the current time, and it needs to be functional for those who elect to be connected intermittently. This requires outsourcing or watching on one's behalf. This would be achieved using a SIGHASH flag, termed SIGHASH_NOINPUT. It does not include as part of the signature, the outpoint being spent (txid and index), nor the amount. It however, would include the spent outpoint's script as part of the signature. Note that this is just a SIGHASH flag, and the outpoints are still being included as part of the txins (if they are mutated, the new txids can be updated by the wallet without resigning). This allows for a signature to apply to anything with that pubkey (therefore pubkeys with this flag should not be reused). For safety, this only applies in SegWit transactions, as segwit provides a sufficient malleability solution, there is no incentive to improperly use this sighash flag as a roundabout way to resolve malleability. This helps with 3rd-party outsourcing for watching the blockchain, as one can provide a signature (and the most recent hash-chain of revocation preimages), which encompasses penalty transactions for all prior states. Functionally, this allows for opt-in wildcard inputs, but wallets which do not require these transactions do not need to be concerned with this flag; since they will never be signing with this flag, they do not need to be concerned with address re-use. I'm interested in input and in the level of receptiveness to this. If there is interest, I'll write up a draft BIP in the next couple days. -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness
Hi Greg, On Fri, Feb 26, 2016 at 01:32:34AM +, Gregory Maxwell wrote: > I think to be successful we must be absolutely ruthless about changes > that go in there beyond the absolute minimum needed for the safe > deployment of segwit... so I think this should probably be constructed > as a new segwit script type, and not a base feature. Absolutely, I'd certainly be interested in this being the first proof/example for the script upgrade mechanisms if it's not ideal for this to be implemented as part of Segregated Witness itself. > The reason for this is that if hardware wallets are forced to continue > transferring input transactions to check fees or to use > without-inputs, they may choose the latter and leave the users > needlessly exposed to replay attacks. Yes, I think it's necessary to include the fees as part of the signature, which will also allow for wallets to not require downloading the input transactions. However, it's necessary to not include the input amount itself, as they may differ. SegWit itself is very nice in that it prevents improperly designed wallets and services using the bitcoin RPC from making mistakes, you can resolve malleability without compromises -- I also think any proposed SIGHASH should ensure some measure of safety from design error/shortcuts. > The fact that without input commitments transactions are replayable is > highly surprising to many developers... Personally, I'd even go so far > as to name the flag SIGHASH_REPLAY_VULNERABLE. :) That's a good point, choosing a scary name is probably very helpful. Thanks, I'll clarify with a specific BIP soon. -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness
Hi Bryan, On Thu, Feb 25, 2016 at 07:34:24PM -0600, Bryan Bishop wrote: > Well if you are bothering to draft up a BIP about that SIGHASH flag, > then perhaps also consider some other SIGHASH flag types as well while > you are at it? I'll take a look at those proposals when drafting the BIP. I think for LN, there is a single clean way to achieve outsourcability, but may be compatible with other arrangements. I'm somewhat averse to proposing too much flexibility before there's clear use-cases, though. However, if others do have uses/examples for other sighash flags, I'd be very interested while drafting this BIP! > FWIW there was some concern about replay using SIGHAHS_NOINPUT or something: > http://gnusha.org/bitcoin-wizards/2015-04-07.log Yeah, I think the nice thing about SegWit is that you resolve malleability without worrying about replay attacks in the event of key reuse. That's why I think it's only safe to do this new sighash type inside segwit itself -- if you only wanted protection against malleability you'd use segwit, and not touch this new sighash type (you'd only use the new sighash flag if you actually need its features). -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF malleability in P2WSH
I agree this is an interesting area of transaction malleability to still consider in the future, and minimization of these areas of malleability with regards to its impact on the p2p network should be easy to resolve and (hopefully) well-understood by script writers in the future. On Tue, Aug 16, 2016 at 12:43:32PM -0700, Peter Todd via bitcoin-dev wrote: > Having said that, a better approach may be a separate CHECKBOOLVERIFY opcode > that fails unless the top item on the stack is a minimally encoded true or > false value, to allow script writers to opt into this behavior; it's not > always > ideal. I think the biggest value of the proposed BIP behavior is that the cost is lower for "doing it right" to create script enforcement of OP_TRUE or OP_FALSE. It is already possible to enforce with 2 bytes pushing OP_TRUE and then OP_EQUAL. Creating an "OP_CHECKBOOLVERIFY" definitely achieves the same result, but at a 1-byte (insetad of 2-byte) cost to "do it right", so there is the same incentive to save on the byte and push potential DoS costs onto the network -- whereas enforcing OP_TRUE byte in OP_IF would create costs for those who want to evaluate pushdata, so that has to be explicitly opt-in from an optimization/convenience standpoint. -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
On Wed, Apr 05, 2017 at 11:37:22AM -0400, Greg Sanders via bitcoin-dev wrote: > I'd appreciate the authors chiming in, but I read the PASDA differently: > > 1) If a transaction is mined with a certain bit set, it reserves 700 bytes > for that particular block. > 2) In that space, 2 transactions may happen: > a) First, a transaction penalizing the "parent" transaction for fraud by > spending the funds immediately > b) Second, a "free rider" transaction that penalizes fraud within a ~2 week > window > > This means during systematic flooding of closing transactions by > Goldfinger, vigilant watchers of their channels can immediately punish the > fraud in the same block using (a), and if they are unable to, need to find > space within two weeks in (b). > > This is really in the LN weeds however, so I'll refrain from evaluating the > efficacy of such a solution. Yes, that is correct. I haven't had a chance to review Laolu's summary yet, haven't had a chance to talk to him today since I was away from the keyboard for most of the day, would have been unable to review things. Section "b" above only allows for free riding on the first output of a transaction with the bit set within the past 2016 blocks. It does not allow free riding on outputs without that bit set in the transaction. Additionally, the presumption is that the attacker fills up the mempool with incorrect prior commitment transactions. The attack scenario is Mallory asks everyone to open a channel with her. Mallory only has 1 BTC. With sufficiently low tx fees, Mallory can use that one bitcoin to open many ~1 BTC channels. All of those channels had a prior state which Mallory had ~1 BTC, and a current state where she has none. She broadcasts these thousands of prior states where she has ~1 BTC. The presumption is the penalty transaction in many cases has a very small fee, since it is already covered by the commitment. This mitigates systemic goldfinger attacks since it is unlikely they can get enough transactions in. Additionally the transactions waiting on the mempool allows for many to be notified and fill up the first reserved space. The attacker would likely be attempting to fill up the mempool (longer block times help here with security!!!). It is presumed that there is some small amount in reserve so there is some fee reward covered for enforcing the penalty. This construction allows for the amount in reserve to be significantly smaller and much more resilient against even the largest of goldfinger attacks. (This isn't a full mitigation, as there are certain conditions related to miner-attacker coordination with high hashpower. Attacker-Miner coordination is presumed to be out-of-scope, especially in relation to 51% attacks, since it's sort of a moot point, if they have the funds to mount this attack so that it's profitable, it gets pretty close for them to have a very significant hashpower anyway.) I'll add a clarification to the specification on github soon. The intent of this is to reduce the cost of setting up LN channels with funds in reserve, with minimal code changes. Future changes which could be desired if this is usable would be use additional tx flag bits to select how many outputs in a transaction apply to enable a large payment of funds pending in-flight. -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function
Hi Greg, On Wed, Apr 05, 2017 at 09:37:45PM +, Gregory Maxwell via bitcoin-dev wrote: > Reverse engineering of a particular mining chip has demonstrated > conclusively that ASICBOOST has been implemented > in hardware. > > On that basis, I offer the following BIP draft for discussion. > This proposal does not prevent the attack in general, but only > inhibits covert forms of it which are incompatible with > improvements to the Bitcoin protocol. > > I hope that even those of us who would strongly prefer that > ASICBOOST be blocked completely can come together to support > a protective measure that separates concerns by inhibiting > the covert use of it that potentially blocks protocol improvements. > > [...] > > ==New consensus rule== > > Beginning block X and until block Y the coinbase transaction of > each block MUST either contain a BIP-141 segwit commitment or a > correct WTXID commitment with ID 0xaa21a9ef. > > (See BIP-141 "Commitment structure" for details) > > Existing segwit using miners are automatically compatible with > this proposal. Non-segwit miners can become compatible by simply > including an additional output matching a default commitment > value returned as part of getblocktemplate. > > Miners SHOULD NOT automatically discontinue the commitment > at the expiration height. Decentralized systems without patent encumbrance is an important topic for me. We'd be very interested in adding this into extension blocks. Claims like these merit serious attention. If you can provide any kind of proof or documentation of this (doesn't need to be conclusive, just something), I will provide my word and promise publicly here and now that I will personally see to it that a commitment which solves this (albeit possibly using a slightly different format to make it compatible) is added into the Extension Blocks spec. If there is evidence, my support and authorship of the Extension Block specification is contingent upon resolving this issue. We have added an issue here: https://github.com/tothemoon-org/extension-blocks/issues/6 I'm interested in a more detailed explanation on how the Merle tree structure works so we can add it to the spec, I didn't follow exactly the new consensus rule and its mechanism in those several lines. We will begin making a pull request adding it into our specification, but more clarity on how to do it on its own would be helpful. We will also consider the code exposure change to adding in SegWit on the Canonical/1MB chain if it is more elegant to implement. Packaging this into our proposal would not only be important, but helpful to the end goals of this proposal as it becomes a standard soft-fork consensus rule which has greater guarantees around enforcibility than user-actication. Further, can you provide clarity and confirmation into why this commitment wasn't required as part of SegWit? -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function
#bitcoin@freenode: 00:04gmaxwell| lol poon pretending that he isn't complicit in all this stuff. Are you *fucking* serious? Is this how you resolve all problems? I'm taking you seriously and having second thoughts and want to make public commitments to do the right thing without any evidence and you come out and say *this*? On Thu, Apr 06, 2017 at 12:17:17AM +, Gregory Maxwell via bitcoin-dev wrote: > On Wed, Apr 5, 2017 at 11:05 PM, theymos via bitcoin-dev > wrote: > > This seems to be a serious security problem. Would it be possible to have > > a flag-day softfork included in Bitcoin Core as soon as 0.14.1? I think > > that a trigger > > 3-6 months from release should be sufficient for enough of the economy to > > upgrade, > > given the severity of the issue. > > Not 0.14.1 because that is in RC already and will hopefully be out in a week. > > I think the speed of adoption depends a lot of the level of support > from the community. I don't believe there are any technical hurdles to > implementing this relatively quickly (and I specifically propose using > the users choice of the segwit commitment or a modified form in order > to lower the technical complexity and risk). > > > BIP 141 says that the the commitment is optional if there are no SegWit > > transactions in > > the block, so will today's SegWit-ready miners always produce it even when > > optional > > according to BIP 141, as required by this softfork? > > This is the default behavior as of 0.13.2, but I haven't gone out to > measure this which is why the backwards compatibility section of the > BIP isn't written yet. > > > While I'm posting, I've had a dozen off-list emails that presented me > with some FAQ: > > Many people asked what other protocol upgrades beyond segwit could run > into the same incompatibility. > > Many proposed improvements to Bitcoin require additional > transaction-dependent commitment data. > > Examples include: > > (1) Segwit. > (2) UTXO commitments. (non-delayed, at least) > (3) Committed Bloom filters > (4) Committed address indexes > (5) STXO commitments (non-delayed). > (6) Weak blocks > (7) Most kinds of fraud proofs > -- to state a few. > > Unfortunately, putting *any* commitment to data dependent on the right > hand side of the hash tree in the left hand side (e.g. coinbase) means > a massive increase in the computation required for covert boosting, > because it means you can't use the left+right side combinations to > eliminate most of the hashing. > > It's plausible, in fact, that this extra computation could completely > nullify the ASICBOOST advantage-- though this depends a lot on the > fine details of the implementation. > > This proposal does not itself propose nullifying ASICBOOST entirely, > it proposes severely handicapping the covert form of it, and > eliminating the differential advantage for boosting miners related to > the use of transaction-dependent commitments. > > Basically there are two completely separate concerns: that boosting > can produce a monopoly advantage which could be severely harmful to > the ecosystem, and that the efficient implementation of _covert_ > boosting can severely harm many useful protocol improvements. My > proposal only addresses the second concern, by (I believe) completely > leveling the playing field so that opposing commitments will not break > boosting any worse, and by making covert boosting less appealing in > general. > > Use of the segwit-style commitment even in non-segwit blocks is sufficient > because the segwit commitment commits to all transactions (except > the coinbase) and not just segwit ones. > (It was designed this way so that lite clients that needed witness > data could work with just one tree). > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function
Ahh, sorry all for this public message. :( On Wed, Apr 05, 2017 at 05:39:00PM -0700, Joseph Poon wrote: > #bitcoin@freenode: > 00:04gmaxwell| lol poon pretending that he isn't complicit in all this > stuff. > > Are you *fucking* serious? Is this how you resolve all problems? I'm > taking you seriously and having second thoughts and want to make public > commitments to do the right thing without any evidence and you come out > and say *this*? -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function
On Thu, Apr 06, 2017 at 01:32:03AM +, Gregory Maxwell wrote: > On Thu, Apr 6, 2017 at 12:39 AM, Joseph Poon wrote: > > #bitcoin@freenode: > > 00:04gmaxwell| lol poon pretending that he isn't complicit in all this > > stuff. > > > > Are you *fucking* serious? Is this how you resolve all problems? I'm > > taking you seriously and having second thoughts and want to make public > > commitments to do the right thing without any evidence and you come out > > and say *this*? Apologies to the list. > I apologize for the glib talk on chat and I hope you understand that > the tone in such venues is significantly informal; and that my remark > was a causal one among friends which was not intended in a spirit as > seriously as you've taken it. You're still presuming ill-will. I'm seriously offended. I'm not upset with the glib talk, I'm upset that you think I have ill will. > That said, two days ago you participated in a highly unusual > announcement of a protocol change that-- rather than being sent for > community review in any plausible venue for that purpose-- was > announced as a done deal in embargoed media announcements. This > proposed protocol change seemed custom tailored to preserve covert > boosting, and incorporated direct support for lightning -- and the > leading competing theory was that a large miner opposed segwit > specifically because they wanted to block lightning. Moreover, I have > heard reports I consider reliable that this work was funded by the > miner in question. We specifically told you guys privately and publicly when asked that it was simply to be able to do it in 2 weeks. Check out the code, it was much faster to do it that way. The spec wasn't complete and I have personal biases against doing it on the main-chain since it would benefit things if there was smart contract proections on the main chain as well, which I figured would be more controversial. I never said anything about public commitments to transactions. In fact, I'm pretty good at figuring things out and tend to cargo-cult things (since culture is the genetic memory is civlizations), if I saw BIP141/SegWit required a commitment instead of it being optional, I would've probably thought about it. Why wasn't this required as part of SegWit? BIP141 is still vulnerable. Why did you pull this out just now? I'm totally blindsided here, hence my earlier reply of wanting to resolve it in the Extension Block proposal. > In the time since, when people asked for revisions to the proposal to > not block segwit they received responses from the Bcoin account on > twitter that "there would be no amendments", and I was sent leaked > chatlogs of you making considerably hostile statements, claiming that > if your extension block proposal is "a litmus test for corruption", > and claimed (before AFAIK anyone had had a chance to comment on it) > that the Bitcoin project contributors opposed it for "nonsense > reasons". I never participated in that, and the specific announcement here indicates that changes will be happening. The intention was to get it out as a draft and *working* demo code. https://medium.com/purse-essays/ready-for-liftoff-a5533f4de0b6 That was specifically after Core developers accused me of publicly acting in poor form without any understanding of the situation. I was especially annoyed because all of you are acting with similar secrecy, even worse, there is specific organization by Core which the public is not aware of. Think about it from my perspective, you all blocked me out intentionally for months and then accuse me of going to journalists for a couple hours before? I'm seriously hurt. > It is with this in mind that when you tried to pull me into an off the > record conversation that I responded stating: > > "[...] I am disinclined to communicate with you except in email where I can > get third party transferable proof of our communication. I'm > concerned that you may now be involved in a conspiracy which I do not > want to be implicated in myself. > > It is my estimation that, for that above reason, it would be in my > best interest to not communicate with you at all. But in all your > prior interactions you appeared to have integrity and sense, so out of > respect for that history I'm willing to communicate with you, but only > in public or in email where my end is on gmail." Nice you cut out the beginning which explains on *why* I didn't reply: "with an embargoed press release in Forbes. That's how you roll now, right? :-/" Why didn't you include your entire message? That was in reply to my initial message reaching out to you and Adam Back: "Hi, would you like a phone call tomorrow? I am in Thailand right now, I understand if what I did is upsetting, my goal was not to upset you. I deeply respect you both technically, but I do believe what I am doing is right. If you could find a way, I would be extremely grateful if we could chat sometime." Replying with a beginning like that with th
Re: [bitcoin-dev] What Lightning Is
Hi Gavin, On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev wrote: > I'd love to see somebody write up a higher-level description of what the > user experience is like, what communication happens underneath, and what > new pieces of infrastructure need to get built to make it all work. I'm writing a (hopefully more accessible) summary on Lightning currently. It might not go into too much detail with infrastructure, but is a bit more UX focused. > A customer starts with eleven on-chain bitcoin. They want to pay for a nice > cup of tea. Walk me through what happens before/during/after the > transaction, assuming I have a lightning-enabled wallet on my iPhone and > the tea shop has a lightning-enabled cash register. > > Assume neither the customer nor the tea shop are technically sophisticated > -- assume the customer is using an SPV wallet and the tea shop is using a > service similar to Bitpay. It's a bit of a tangent, but I see it as necessary that all Lightning services/wallets support on-chain payments for a multitude of reasons, including usability and long-term security/fungibility. For that reason, the UX flow for payment after channels are established should not be significantly different than Payment Protocol based payment flows (with the only exception being a possible additional fee dialog box/alert when the fees will be higher than expected/on-chain). -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] What Lightning Is
Hi Hector, On Sun, Aug 09, 2015 at 09:48:41PM +0100, Hector Chu via bitcoin-dev wrote: > Is the Lightning system limited in the number of hops there can be in > the payment channel? I am looking at the initial Lightning slides > presented in February and it looks like the locktime decrements by > 1-day along each hop. So the more hops there are the longer my > bitcoins are potentially locked up for? The hops are limited to the time-value which the sender wishes to pay and the minimum acceptable timeout between each hop. It should be relatively cheap if you game it out, though (I don't forsee me opening a 1 BTC channel and being able to make $5 per month...) 1-day is used as a convenience. However, the time between hops should be somewhat long, as the intermediate steps can be extended further when you want to offload the HTLCs to others who have a channel open with both counterparties. E.g. Alice sends a payment to Dave through Bob and Carol. Bob has a channel with Carol and has an HTLC with it, but that channel seems to be used a lot. Erin has a relationship to both Bob and Carol, she can offload the payment so that the payment actually goes to A->B->E->C->D. B<->C is now completely clear. > > On Aug 9, 2015 1:15 PM, "Hector Chu" wrote: > >> In the Lightning network it is assumed that the balances can always > >> be settled on the blockchain if any of the parties along the > >> channel has a problem. What if the fee on the settlement > >> transactions is not high enough to enter the blockchain? You can't > >> do replace-by-fee after the fact. Do the fees always have to assume > >> worst case scenarios on the Bitcoin fee market? How do you send coins if you wanted to send funds below the current IsStandard value? It should be no different. If your wallet can't send funds below the IsStandard value on-chain today, then I don't think it should be able to to in the future, right? If you send funds *at* the minimum IsStandard value today, you're probably paying really high fees, this is a problem that exists today. -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Off-chain transactions and miner fees
Hi, On Mon, Aug 10, 2015 at 12:20:36AM +0200, info--- via bitcoin-dev wrote: > Off-chain transactions, whether it's Lightning or something else, > potentially extract fees, which may otherwise be paid to miners, if the > transactions were actually on-chain. > > In this context, wouldn't it be contradictory, maybe even harmful, to > aim for an environment, where some/many/most transactions are off-chain? I think the fee market's long-term implications for mining rewards is very important as well! However, opening and closing channels will not be infrequent to the point that it will never happen with Lightning. Individuals that fill up their channel will need to accommodate accumulation (as well as those that do a lot of disbursement). These fund flows are not too rare, and huge payments (think the equivalent to wire transfers today) will probably be still on-chain. I think the payment size of micropayments to credit cards are Lightning-scale, what people use today for wire transfers (e.g. buying a house) will be on-chain. What Lightning does is it mitigates the advantages that doing an end-run around bitcoin entirely via centralized systems provides to a sufficient level, e.g. everyone transacting on Coinbase. Having everything on centralized services will have significantly lower on-chain transactions than Lightning and is one of the more viable alternative off-chain payments. Fundamentally, without off-chain transactions, there's a paradox within a viable fee market. If you presume that fees should be relatively competitive (i.e. not asymptotically close to zero), that implies that higher-value transactions *will* be prioritized over low-value transactions, as high-value transactions are willing to pay higher fees. Wire transfers are cheap when it's a million-dollar wire. In my view, different transaction values is the much larger risk for on-chain transaction fee markets, with high-value transactions crowding out low-value transactions on-chain. With lightning, it significantly mitigates this problem by aggregating the low-value transactions off-chain. -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] trust
Hi Benjamin, On Sat, Aug 08, 2015 at 02:01:58PM +0200, Benjamin via bitcoin-dev wrote: > How do you know who is who online? If a node is not online, then the payment can be cancelled and re-routed. > If Alice and Bob want to transact and haven't exchanged keys before > they need public-key infrastructure out-of-band to identify > themselves. Which means they are using SSL and Certificate authorities > and trust them. Lightning doesn't solve the key exchange problem (perhaps something like Namecoin will help in the future). Bitcoin faces this problem today. How do you know the bitcoin address belongs to the recipient without trusting CAs? What if, in the case of the majority of bitcoin payments today, the bitcoin address was not signed and the recipient claimed to have never received their funds? There should be signed proof of payment in every transaction for this reason. > If you have non-cooperative hubs they could flood the network and make > it unusable. And why should hubs cooperate? There are no incentives in > the system. There are some incentives towards keeping the system functional via fees. If you attempt to flood the system, you'll likely be paying some fees -- someone running a node will not interpret it as an attack, as they're getting some money (probabably substantially higher as they will increase fees to ensure network availability). I agree that it's very important to think through varius attack models. -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
Very cool! This will certainly help make Lightning Network testable on the main-chain and permit channels to remain open indefinitely. I'm looking forward to it. On Thu, Aug 13, 2015 at 12:06:44PM +0100, Btc Drak via bitcoin-dev wrote: > // Note that unlike CHECKLOCKTIMEVERIFY we do not need to > // accept 5-byte bignums since any value greater than or > // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected > // anyway. This limitation just happens to coincide with > // CScriptNum's default 4-byte limit with an explicit sign > // bit. I haven't tested the details of this, but is there another bit available for use in the future for the relative blockheight? I strongly believe that Lightning needs mitigations for a systemic supervillan attack which attemps to flood the network with transactions, which can hypothetically be mitigated with something like a timestop bit (as originally suggested by gmaxwell). Summary: If a block is flagged as timestopped (whether automatically or by vote or other mechanism), then an auxillary blockheigh is frozen and does not increment. This auxillary blockheight is only used for accounting in timestopped height computation (and isn't used for anything else). So as the real blockheight increments, the auxillary blockheight can sometimes stop and stay the same. If a transaction has a timestop bit enabled, then the transaction's OP_CSV relative height is dependent upon the auxillary height, not the real block height. This allows for a large backlog of transactions which must occur before a particular (relative) block height to enter into the blockchain. I'm not sure if it's out of scope, but it could make sense to consider the possibility for additional state(s) with relative height computation today. Ideally, there'd be some kind of "version" byte which can be recontextualized into something later, but I don't know how that could cleanly fit into the data structure/code. -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Incentives to run full nodes
Hi Chris, I don't speak for Peter, but here's my opinion on the matter anyway. On Mon, Aug 17, 2015 at 05:44:56PM -0400, Chris Pacia via bitcoin-dev wrote: > Can you explain how the spv node fails against an attacker with a > non-trivial amount of hash power where a full node doesn't? To attack an > spv wallet that is waiting for 6 or 10 confirmations, you would not only > need to Sybil them but also summon a massive amount of hashing power to > create a chain of headers (while forgoing the opportunity to mine valid > blocks with that hash power). > > But could someone with that much hash power not Sybil a full node and give > them a chain for valid blocks (but on an orphan fork)? The failure model > doesn't seem specific to spv to me. With SPV, it is possible to create a transaction that spends from non-existent coins. With sufficient hashpower, you can construct an SPV proof which sends 1,000 bitcoin to the victim. The attack is "overloadable" in the sense that the attacker is never out of money (they never needed to have 1,000 BTC in the first place). Whereas if the victim is running a full node, the attacker must be signing and spending real outputs in their control, there is a possibility in a re-org that the victim will eventually get their money if it gets re-orged back. On a more fundamental level, the SPV attack isn't on re-orging real/live transactions, it's an attack on *how much money you currently have*. If the client is using SPV, they never had the money in the first place when attacked, irrespective of re-orgs. It is possible to attack thousands of people at once (everyone gets 1,000 bitcoin in false transactions) with a fraction of the hashpower (lie in wait until you get a sufficiently long chain of blocks). If you wished to attack a full-node, it requires you orphaning a chain of valid blocks *live*, meaning you have to send real coins in a real transaction to the victim first. With SPV validation, you only need to construct a chain of invalid blocks off the current blockheight *whenever*. This means you can attack with substantially less hashpower; you don't need 51% of the hashpower to attack SPV wallets. It may be economically unviable to attack a single victim with a full node within a very short timeframe, but it can be economically viable to attack thousands of victims doing SPV validation in a long timeframe. Note I'm not arguing that SPV should be compeletely avoided, I don't have a solid opinion on that (and some threats can definitely be mitigated in various ways, and I certainly like/appreciate the convenience of SPV), but the current SPV security model is definitely weaker than running a full node (if you're handling a lot of money, you should be running a full node), are these issues not well-known by all in the bitcoin community? -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [BIP-draft] CHECKSEQUENCEVERIFY - An opcode for relative locktime
On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev wrote: > If anyone feels strongly about this, please speak up. > > On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > I repeated my nit on https://github.com/bitcoin/bips/pull/179 I am also indifferent, but also dislike technical debt. It should maybe be noted for those who wish to do/write-code-for mempool transaction selection (irrespective of one's opinion on it) that lower is better, since transactions with shorter relative locks are transactions with "higher priority". -- Joseph Poon ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
