Gold collapsing. Bitcoin UP.

[adamstgbit]

gambling of any kind has always been pretty popular with BTC.

bitcoiners are inherently risk takers.

 

[Norway]

@adamstgbit
I bet you are wrong!

 

[Richy_T]

Is this the bit where both of you talk yourselves up to betting each other 90BTC, some third party sets up an escrow address and then nothing ever gets sent there? BTDT (as the escrow)

 

[Norway]

@Richy_T
I would lose the bet by entering it

 

[Richy_T]

@Norway since when has that stopped anyone? (From blustering, anyway )

 

[awemany]

@Richy_T : I think an important potential danger is that with any kind of new system (e.g. SegWit) incentivizing off-chain use, the time-locked contracts create an incentive to perpetuate that system so can have an extremely lasting long-term impact on Bitcoin.

Also, as I just argued on reddit, maybe Satoshi's way to implement everything was also meant as a trade-off in regards to how easy and nice off-chain vs on-chain transactions are, by having the network security and miner reward in mind?

Thus the Core propaganda of 'SegWit just fixes things and makes awesome things possible' might be well-received by those technical minded (left and right leaning ones ) and those favoring to 'streamline things and make them more efficient'. But might it be actually dangerously touching trade-offs that are in place for a reason?

Now I like off-chain use as well and I think there are fundamental reasons why LN will be not as much in-demand as on-chain Bitcoin will be. So I am severely doubting my own argument here, but I still think this is an angle that should be explored much further before we go the route of SegWit or FlexTrans or whatever activation. Especially miners should be careful about what all this might do to their fees long term!

Small blockers should ponder about this as well IMO, as this is touching potentially much more complex trade-offs than the max blocksize limit could ever do.

 

[Christoph Bergmann]

Thank you! Now I have some books to read,

 

[Tomothy]

I have issues understanding how off chain transactions will support mining in the future. It seems like a bad trade. Once the block reward is gone, mining will depend on fee revenue. Miners won't get fee revenue from off chain transactions. Miners will shut down due to lack of fees, network gets weaker. This just seems like common sense to me. Off chain scaling sure as heck seems like a miner poison pill; which is great, if your alterior motive is to eliminate mining in the future...

There is an AMA now from Sundays meeting with core in china. This is quite aggrivating as they say they represent core and are members of core except they don't represent core because core isn't a legal entity... that's some fancy double talk right there imo. I recognize this is true, except core sure as hell seems like a cabal and they act as a partnership, so maybe there isn't a legal entity, but as they act in concert, all would be responsible for the acts of another.

regardless, link enclosed. nothing new or earth shattering, just a lot of fancy dancing and footwork

http://news.8btc.com/core-ama-after-the-meet-up-in-shanghai

 

[Richy_T]

I am fine with off-chain transactions. They don't support miners and are in competition with them but Bitcoin offers what Bitcoin offers and if it's not on chain, it's not really Bitcoin and if you use it, you are compromising on something

What is concerning is that people who apparently want to provide these off-chain solutions and are thus intending to be in competition with miners have found a strong lever of power to pull in the form of the block size limit. Imagine if Target owned the company that delivers Walmart's goods and restricted deliveries to one truck per month. I can't understand why miners tolerate it.

@awemany I'm still not quite understanding the mechanism by which the locked coins are threatened.

 

[Mengerian]

Nice appearance on The Crypto Show by @Rogerver and @Justus Ranvier. Discussing Bitcoin Unlimited, Bitcoin.com pool, scaling, etc.

 

[Norway]

@Mengerian
Looking forward to listening to this. Cup of coffee ready. Starting right now!

 

[solex]

Anyone wondering how Bitcoin's huge network effect can be bled away to alt-coins will see the risk in here:


Artifically high BTC txn fees puts oxygen into this process.

 

[freetrader]

This been posted yet?

 

[awemany]

@awemany I'm still not quite understanding the mechanism by which the locked coins are threatened.

If you phase out an/the old transaction format (to avoid O(n^2) hashing issues, for example), I can imagine scenarios where you'd invalidate off-chain transactions still pending and using that old format. For example the 'user discipling himself by signing a timelocked transaction to himself but throwing the original privkey away', that was an example jonny1000 gave on reddit.

But, as Tom Zander rightly pointed out, the user threw away the key in this scenario, so there's that.

Whether phasing out old formats should be done at all is a good question. Maybe it is best to keep the code around and active (with some reasonableness: I think restricting old transactions to a sane size must be OK).

In any case that's also my uneasiness with allowing/proposing more off-chain use now, and with such a package (SegWit), with all the riders attached and so forth, in these controversial times. Because there might be trade-offs involved for miners and their revenue, and it is hard to imagine all the various ways the balance between off- and on-chain transactions might shift if some things get simpler or even possible. And with off-chain long-term time locking, going back on something there might be almost impossible.

Again, I absolutely do like off-chain use as well (and like to keep the functionality that Satoshi put in in any case!), I just think there might be a trade-off here, and I think miners should be fully 100% knowledgeable on what they are doing if they think SegWit is a great idea. To be honest, if Samson Mow's demeanor is an indication, I think BTCC is an example of falling short of that.

On the other hand, Haiyang's 'back seat' comment makes me think he pondered about that for a while, but I (and I guess others as well) still absolutely like to know more thoughts of the miners on this possible dilemma.

If there's a way to get more off-chain functionality in a way that would allow backtracking and thus allow for mistakes, that would be great.

One thing that would help IMO would be a general agreement to limit off-chain contracts and
other timelocked transactions to less than one year of duration.

 

[albin]

What do you guys think is reasonable time frame for IOUs to be redeemable on Bitcoin?

I think realistically we're going to have to carry support for the exact parameters of the current 1mb blocks indefinitely into the future, because there is no way to know anything whatsoever about what kind of tx's might be out there, until one day we discover that the utxo set does not contain any current-type transaction outputs at all (which overwhelmingly likely will never happen short of breaking current ECDSA, because of abandoned coins).

I think this is one major symptom of the colossal failure of the Core project to collaborate on any kind of consensus protocol spec, because unless we have an explicit agreement about what behaviors are intended to be supported, bad actors can lawyer this bullshit forever.

 

[Justus Ranvier]

Whether phasing out old formats should be done at all is a good question. Maybe it is best to keep the code around and active (with some reasonableness: I think restricting old transactions to a sane size must be OK).

It's safe to restrict old format transactions to 1 MB, since any hypothetical signed and unbroadcast transactions larger than 1MB are and always have been invalid.

If we want Bitcoin to be useful and trusted as money, the one thing we should never do is change the conditions needed to spend a utxo after it's been created.

It's fine to phase out the existing transaction format over time, but only as long as it's done in a way that doesn't effectively confiscate anyone's coins.

 

[awemany]

@albin:
Generall agreed, especially on the lack of spec part. With a caveat: I personally think saying 'off chain >100kiB sized old-style txn' are OK to phase out if there's ever a new transaction format implemented. (Hey Core that is just a soft fork! ;-) ) (edit, see below)

I now wonder, in 'small blocker style', whether transactions larger than 1MB should be supported soon? (In the BU-style of emergent consensus way with me disagreeing, though )

Are there realistic scenarios where a large set of huge off-chain transactions could cause problems down the road? Are there realistic scenarios where they should be supported?

EDIT: @Justus, good points, I tend to agree it is is probably best to support all old stuff that we have now and not distinguish 100kB/1MB. But maybe that should make us wary of allowing large transactions? Big blocker that I am, EB1000/AD0 is good for me, but on the txn size, I probably like a 1MB cap for the near future...

What's your take on the danger of potential ossification due to further, complex, time-locked stuff in a hypothetical SegWit activation scenario?

 

[Justus Ranvier]

I now wonder, in 'small blocker style', whether transactions larger than 1MB should be supported soon? (In the BU-style of emergent consensus way with me disagreeing, though )

Are there realistic scenarios where a large set of huge off-chain transactions could cause problems down the road? Are there realistic scenarios where they should be supported?

The current transaction/script format has corner cases where the amount of time needed to validate a transaction increases greater than linearly with the size of the transaction.

Parallel validation, however, limits the ability of an attacker to exploit this behavior. Parallel validation should be done, and is not a consensus rule change.

What's your take on the danger of potential ossification due to further, complex, time-locked stuff in a hypothetical SegWit activation scenario?

New transaction formats which fix the txid malleability and non-linear validation time are a good thing.

They could even be made mandatory without confiscating coins via a multi-stage roll out:

The first step is that new format transactions are permitted alongside old format transaction.

Then a block height is chosen at which all transactions must be in the new format, except for transactions containing at least one old format input which existed prior to the chosen block height.

This allows the UTXO set to be cleaned up over time without rendering any coins unspendable.

 

[Richy_T]

Whether phasing out old formats should be done at all is a good question. Maybe it is best to keep the code around and active (with some reasonableness: I think restricting old transactions to a sane size must be OK).

Well, presumably you would phase out those transactions *going forward* but the locked coins would be done in a transaction already recorded in the blockchain, no? Just because you wouldnt allow that type of transaction going forward doesn't mean you can't honor existing ones. Is someone supposed to be abusing n^2 by setting up transactions that will be executed months and years into the future? (hint, they're not even doing it with transactions to be executed immediately)

 

[Norway]