Yes.

Of course, no problem with this.

Update: I'll pick whoever gives the cheaper quote but all cards on the table, I'm willing to accept to pay up to 10% fee on all my transactions.

Yes. If you can get a bitpay Visa debit card or any virtual card, I'm willing to pay for that.

I need a virtual card issued so that I can pay with Bitcoin for online services, such as Github, Digital Ocean, Trello, Slack etc.

Volume is about $300/mo currently but will increase as the team expands. I only bother you twice: for loading the card for the new month and for asking to upload the statement for the past month.

Please state your % fee and issuance fee.

I need a virtual card issued so that I can pay with Bitcoin for online services, such as Github, Digital Ocean, Trello, Slack etc. I'm willing to pay up to 10% on each transaction + issuance fee.

Volume is about $300/mo currently but will increase as the team expands. I only bother you twice: for loading the card for the new month and for asking to upload the statement for the past month.

Only trusted forum members with enough forum history, please.

You do know that many innovations in Bitcoin were rolled out this way, right? P2SH is treated by non-P2SH-aware nodes just as a hash preimage lock. OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY for non-aware nodes are just no-ops.

This conversation is more suitable for a LN-specific thread and for people who know more about LN low-level security constraints than me, but I'll just point out that the deadline for closing the channel is not one block, it is whatever period of blocks you put in the funding transaction's timelock. If you see the main layer become more congested, you do it earlier at a safe distance from the deadline. You could, for example, have a rule of opening channels for two weeks, but always closing and reopening the channel 24 hours before it expires. That said, I agree with you, in the process of maturing, LN has a lot of things to take care of, including this one.

You kinda answered this question yourself:


My personal estimate is that it will take several years for LN to mature, but we need bigger blocks right now. This solution would provide time for LN developers (or sidechains, or whatever) to do their thing, and we would enjoy 5-10 MB blocks until that time.

So what's your alternative? 500 GB blocks every 10 minutes? If you read my paper, you'd see I'm for a reasonable increase, not extreme.

Traditional banking systems are custodian systems, where they are kings and can do whatever they want: run off with your money, or shut down your account at any time for any reason, or tell you to come get your money Monday through Friday from 2pm to 4pm. They don't have this power with LN, at no point your funds are at risk. You can close the channel back to the blockchain if you don't like how the counterparty behaves. I can't vouch for how effective it can ultimately be, we'll see, but it's a neat concept nevertheless.

I think I've highlighted this enough times in the paper, but I'd like to point out an important point again: you can limit superspace blocks, by saying in the protocol the block is invalid if its size exceeds, let's say 10 MB. Increase from 1 MB to 2 MB in SegWit did not really affect decentralization so far, neither would 10 MB. 128 MB blocks definitely would.

Also, it doesn't mean that every block will be 10 MB from now on, only in the "rush hour".

Where did I get 10 MB number? Nowhere, it's just an example. We can set it to whatever limit the community deems reasonable. The point is that we can impose it. But now we ourselves will be able to decide what the block limit should be in today's circumstances, not 2010's Satoshi when he initially put 1 MB, looking at 2-3 KB blocks as they were back then.

I think they will quickly reconsider when the next bull run happens, the network gets congested again, and the fees soar. Many people will adopt new things only when they absolutely have to, at the last moment, when they feel the pain and see the solution that eases it.

You can provide, alternatively, a Segwit P2SH address to those legacy clients, the net result will be just the same. With a text underneath a bech32 address: "If your software doesn't understand this, use this address instead: 3........ Oh, and by the way, consider upgrading your software to the latest version."
Or you can just provide only the P2SH address. Even if you use P2SH addresses alone, you still use SegWit.

It is important to have the same definitions in mind when discussing things like centralization. In Bitcoin, decentralization means censorship-resistance (due to many parties involved that take random turns producing the blocks), impossibility to do any action to bring down the whole network (in centralized systems, this would be chopping off the head), and custodial decentralization (no need to trust someone that they won't steal your funds, because they can't). You would have the same in LN: censorship-resistance (if 10 routes don't want to do business with you, you route through 11th), can't bring down the whole network (you bring down big hubs, and the little ones take their place), and custodial decentralization (you still don't trust anybody other than the math, hubs are not custodians of your funds). What's left is perceived centralization, however, cause such a network would tend to center around hubs with the biggest liquidity and connections, so it would look like hub-and-spoke topology.

It's a bit offtopic here though.

Very different. One is a hard fork resulting in a network split, the other one is a soft fork, not affecting legacy software in the slightest. That's the whole point.

Congrats on reaching the "over 1000 posts" mark! 

You can hardly find 100% consensus about anything these days, but I think there is a need. Every day I see topics here with people complaining about the block size and freaking out about the thought that full block incident could happen again on the next bull run.

I also remember conversations happening pre-SegWit, some people were also saying there's no need to increase the block size any further than 1mb and therefore no need for SegWit, and it got rolled out anyway, as a compromise solution. Likewise, there is no harm in rolling out superspace/extension blocks, and it would actually be a better compromise solution. All I'm saying, if we're doing this anyway, why not go all the way?

How optimistic are you about when layer 2 solutions will become usable? I am working on one implementation of LN, and I see some questions, like routing and liquidity, are still in the air. This does not diminish the existing efforts of developers, of course, we've come a long way, but we're still somewhere in the middle.

Of course, and I did mention that. However, SegWit was sold to the community mostly as the backward-compatible block increase solution, and that aspect of it caught the most attention.

Indeed, several people have pointed out to me that this idea has already been out there for some time, only it's been called "extension blocks", albeit not defined with as much detail. Started to read the discussions on it, seems very similar. Gonna continue reading to give them proper credit, but also to figure out why this proposal hasn't been greenlighted and what arguments could be used to showcase the benefit of its activation. I see it started in pre-SegWit era, maybe this time will be different because we have seen a successful SegWit activation, which is highly similar to the proposal in question, in the way SegWit was deployed.

Superspace: Scaling Bitcoin Beyond SegWit

Steve Kallisteiros
August 25, 2018

Abstract. SegWit, or Segregated Witness, a soft fork successfully activated mid-2017 on Bitcoin blockchain, provided among other benefits a backward-compatible increase to the block size limit, all while not introducing consensus breaking changes to Bitcoin protocol and not resulting in a hard fork network partitioning. The potential space increase is estimated at being close to 2 MB total for practical purposes. In this paper, the author argues that it is possible, using the same mechanism, increase the block size further up to any agreed-upon limit, while still providing the same security guarantees SegWit does.

Complete paper: https://files.zazzylabs.com/LNx2ud/superspace.pdf

===

Keep in mind, it's only the first draft. I would really appreciate your feedback.

Right, you beat me to it; by summarizing you probably meant something like this:


Anyway, this is really really fun. LN seems to be going places.

Hmm, now I have a question. If all transactions eventually need to be settled on the blockchain anyway, how does it affect the fees and the scalability? Usually, LN is positioned as a way to send a lot more transactions than the current blockchain capacity, and send them cheaper. And I kinda understood why, but now with the introduction of HTLCs I'm not that certain anymore:

1. Fees: I thought that one can save on fees by sending several payments to the same hub that will distribute the payments further. Since it's all happening inside the channel, it will be registered as one big transaction to this hub rather than several. But my understanding is that HTLC requires a separate transaction output, does it not? The end result would be a transaction with one input and a lot of outputs with hash locks. And since it's different hash/preimage for each LN payment, it would require a separate spending transaction per each payment, right? Then the fees must add to the same amount anyway?

2. Scalability: I thought more scalability can be achieved by transacting off-chain, but if, when closing the channels, we must broadcast the same amount of on-chain transactions to spending funds from off-chain hash-locked outputs, won't it choke the blockchain all the same when we attempt to close the channels this way?

Sorry if the questions are invalid, I've learned about the use of HTLCs in LN just now, so I'm pretty much saying things off the top of my head at this point. But maybe someone already knows the answer.

Upd: actually, having thought about it, something like this would be neat: if someone sends me the correct preimage, I'll just replace my puzzle output of this amount with a simple output giving him the funds, since I know he can take them anyway, since he knows the preimage. But this would clean up the outputs and consolidate them, so that when the channel closes, it's just one clean transaction signed by me and him without any hash puzzles.

You can wait until the channels close (they eventually will, and maybe even faster than their expiration date), and then you'll see your transaction broadcasted on the blockchain, since it's the only way for them to get your funds.
Or in the case of "pay-per-minute streaming content", you stop streaming to them and ban the peer if they don't send the micropayment in time.

Ah, that's spot on! Haven't noticed this part. Very cool.

Figured out the solution: to subvert the attack, each node must make sure that the channel towards the sender side expires later than the one towards the recipient side. Since the channels in question are opened on both sides of that node, it always knows the exact transaction scripts and is always able to verify this condition.

Hopefully, this is already included in the emerging LN standards.

Thanks for helping me figure out how it all works.

Understood this part, using HTLCs is a brilliant idea. Just can't figure out this one edge case in my head:


What if Bob doesn't share the secret right away, but waits until Alice's channel with me expires (our channel with him is set up for a longer period of time), I take away all the funds in the channel with Alice (she can't do anything, because she doesn't know R), and then Bob publishes tx with R when it's too late for her but not too late for him, thus he also takes away funds from Alice in his channel? We've successfully defrauded Alice, haven't we?

Also very clever, thanks for the reference, doesn't address this case though, if I understood correctly.
In 'Broken channel' paragraph there's an assumption that the secret has been voluntarily given up by the last participant.
In 'Rerouting', it is assumed that the immediate neighbor cooperates and creates a negating transaction, rebalancing the channels.

Oh, that's smart, I get it now. And I've read bob123's link, same thing. Thank you folks, just what I needed.

Now the only concern is that if Alice-Bob channel expires earlier than Bob-Charlie's, Charlie can maliciously withhold the preimage until A-B channel expires (and Bob can't take Alice's funds, because he can't provide the correct preimage to form the unlocking script, and Alice takes them all because the timelock expired), while Charlie publishes the preimage in time after that to grab Bob's payment; but that 1) requires conspiracy between Alice and Charlie, and 2) we can probably check this condition somehow, by requiring access to and validating all channels in the chain.

Upd: Actually, can we do 2)? I know we're deep into the woods at this point, but I would appreciate if anybody shares their ideas on how this attack can be mitigated.