Gold collapsing. Bitcoin UP.

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
BTW, paper I'm talking about (I think -- I didn't reread; I read it a LONG time ago) is: https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf

Obviously in a trustless network any "process" (node) is expected to be "faulty".

I didn't watch the video but to play devil's advocate here for a moment he may be meaning that he convinced himself that the paper applies to bitcoin.
 

sickpig

Active Member
Aug 28, 2015
926
2,541
@awemany you are right. there are more urgent issues to work on, e.g. add micro payment channels to Bitcoin p2p network.

nevertheless in the particular case we have also to take into account that the current tool used for the task, lib OpenSSL, is a continue source of security/stability risks.

edit: grammar
 
Last edited:
  • Like
Reactions: awemany

rocks

Active Member
Sep 24, 2015
586
2,284
there you go. this why i concluded back in the old BCT thread that as much as i rail on SC's & LN that i shouldn't worry about it so much. b/c i don't think there will be a demand for it. the reason i do rail is b/c they're being used as an excuse to block bigger blocks and growth on MC and acting as a major diversion. we really don't have that luxury of time wasted.

Dryja, Poon, & now Sztorc all admit their ideas are dependent on keeping blocks fixed at 1MB in their respective podcast and blog posts.
Regarding LN usability, the thing that confuses me about the core dev's stance is doesn't LN itself require easy, fast and low cost access to add transactions to the main chain?

The way LN works (please correct me if I'm wrong here) is a payer sends transactions to a receiver, but the receive simply holds onto those transactions until they are ready. The classic example they have used is paying for a video service in 1 minute increments. The payer continually sends a new transaction every 1 minute, and the receiver every minute receives a new transaction that represents the value of the full session.

When the LN transaction is complete, the receiver then sends the highest paying transaction they received to the main chain to claim their funds. HOWEVER, the receiver must confirm this LN payment to the main chain prior to the timelock on the entry transaction expiring. After the timelock expires, the original payer could double spend against the LN transactions and re-claim the funds sent.

For this to work the LN receiver needs to be able to add their transaction to the main chain. If the main chain is too full, and it takes longer periods of time to confirm transactions in a block, then the LN receiver is at risk of missing their time window and losing the payment. In a constrained fee market environment, LN only becomes attractive if people open very long payment lockup windows and use LN for the vast majority of their payments. Otherwise LN users still need to confirm in the main chain periodically in a fast & low cost manner.

So a transaction fee market breaks LN also, unless the whole point is to move the vast majority of users off chain....
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994

albin

Active Member
Nov 8, 2015
931
4,008
@sickpig

From what I am led to understand, then main significance of libsecp256k1 is to avoid potential consensus-breaking bugs that could happen as a result of OpenSSL dependency.
[doublepost=1448480813][/doublepost]
Regarding LN usability, the thing that confuses me about the core dev's stance is doesn't LN itself require easy, fast and low cost access to add transactions to the main chain?
This. Unless we're willing to go down the rabbithole of convoluted gmax workarounds like freezing timelocks, you can't have Lightning unless you're sure that the necessary transactions can be confirmed within a sufficient time. A successful Lightning Network would increase the incentive to tx spam Bitcoin on a level that we can't even comprehend yet

This is absolute anathema to /r/bitcoin... but.... I kind of think that maybe the Lightning concept would be way better as an overlay on a permissioned system..
 
  • Like
Reactions: rocks

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
Regarding LN usability, the thing that confuses me about the core dev's stance is doesn't LN itself require easy, fast and low cost access to add transactions to the main chain?

The way LN works (please correct me if I'm wrong here) is a payer sends transactions to a receiver, but the receive simply holds onto those transactions until they are ready. The classic example they have used is paying for a video service in 1 minute increments. The payer continually sends a new transaction every 1 minute, and the receiver every minute receives a new transaction that represents the value of the full session.

When the LN transaction is complete, the receiver then sends the highest paying transaction they received to the main chain to claim their funds. HOWEVER, the receiver must confirm this LN payment to the main chain prior to the timelock on the entry transaction expiring. After the timelock expires, the original payer could double spend against the LN transactions and re-claim the funds sent.

For this to work the LN receiver needs to be able to add their transaction to the main chain. If the main chain is too full, and it takes longer periods of time to confirm transactions in a block, then the LN receiver is at risk of missing their time window and losing the payment. In a constrained fee market environment, LN only becomes attractive if people open very long payment lockup windows and use LN for the vast majority of their payments. Otherwise LN users still need to confirm in the main chain periodically in a fast & low cost manner.

So a transaction fee market breaks LN also, unless the whole point is to move the vast majority of users off chain....
that's how i understand it too.

maybe this is why i keep hearing how LN eventually needs 130MB blocks at least to function properly. in that case, why not just open up blocksize with BU, dev LN, and see who wins?

i'm quite sure after listening to Sztorc, Dryja, & Poon that they see their ideas benefiting from or being dependent on the 1MB cap.
 

rocks

Active Member
Sep 24, 2015
586
2,284
@sickpig
This. Unless we're willing to go down the rabbithole of convoluted gmax workarounds like freezing timelocks, you can't have Lightning unless you're sure that the necessary transactions can be confirmed within a sufficient time. A successful Lightning Network would increase the incentive to tx spam Bitcoin on a level that we can't even comprehend yet
That could means that LN is exposed to spam attacks in a manner normal transactions are not.

For example if LN was used for a high value payment and the LN receiver only has one day to confirm the transaction, then the LN sender can be motivated to spam the network filling blocks until the nlocktime expires. As has been shown with the spam tests, an attacker for <$1000 can generate enough fee paying transactions to clog the network for a few days.

The reason this is not common, is there is no financial incentive to spam today, the spammer is simply burning money. But an LN motivated race creates a new incentive to spam the network. The LN receiver (if I am understanding this correctly) can not increase fees on the LN transaction in order to give it priority. The LN payer sets the fee in the LN transaction, and after the LN receiver receives and accepts a transaction the LN payer could use spam to make the fee they included too low.

The only real solution to this is to reduce the effectiveness of spam attacks on LN by, wait for it, increasing block sizes. Large block sizes significantly increase the cost of a spam attack, negating it's effectiveness.

Now that I think about it, this is probably why the BS devs are pushing "replace fee" functionality. Replace by fee damages zero-confirm transactions, but enables an LN receiver to increase the fee paid if they need a quick confirmation during a spam attack.

If this line of thinking is accurate, then the BS devs are working to break zero-confirm transactions in order to solve a flaw in LN. That is horrible.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994
@rocks

we've known for a while that *several* soft forks to Bitcoin are required to enable LN, not to mention SC's. i've been just as upset about these as you should be.
 
  • Like
Reactions: steffen

albin

Active Member
Nov 8, 2015
931
4,008
Can you up the fee on the initial anchor transaction at all in the first place? The only thing I can think of is immediately spending under CPFP.
 

rocks

Active Member
Sep 24, 2015
586
2,284
@rocks

we've known for a while that *several* soft forks to Bitcoin are required to enable LN, not to mention SC's. i've been just as upset about these as you should be.
There are soft forks that extend functionality for people interested, and then there are direct attempts to reduce core aspects of Bitcoin. Breaking zero-confirm transactions is in the later camp. I don't see that as a soft fork, but Peter and other devs have been arguing for various forms of it.

It made no sense to me why they were moving in this direction. I figured we just saw Bitcoin differently, but I didn't understand how that could be for something so fundamental. Now it maybe makes some sense, but it shows a willingness to damage bitcoin to improve LN. That is very different from adding soft forks that some may use and some may not.
 
Last edited:

awemany

Well-Known Member
Aug 19, 2015
1,387
5,054
There are soft forks that extent functionality for people interested, and then there are direct attempts to reduce core aspects of Bitcoin.
Yes, we should make absolutely make sure that they do not include any changes that might impact scalability of Bitcoin in the medium term.

That would be a way to ossify and steer Bitcoin into their desired direction which would be practically impossible to undo. And I fear it could be implemented with 'soft forks'.

Greg and Adam have the Machiavellian attitude and the incentive to pull this off, so I am actually waiting for them to sneak something in like that.
 

rocks

Active Member
Sep 24, 2015
586
2,284
Can you up the fee on the initial anchor transaction at all in the first place? The only thing I can think of is immediately spending under CPFP.
For a while they were talking about letting the network accept new transactions with higher fees, replace existing transactions in the mempool. This would completely break zero-confirm transaction confidence, which is quite high today. Peter's arguments were essentially that since zero-confirm guarantees are not 100%, why have them at all. To say this did not go over well is an understatement.

But even if the network was changed to allow this, it still wouldn't help the case I originally laid out above. The LN sender is the one who would need to create a new replacement transaction with a higher fee, but the LN sender would be the attacker here and is not motivated to provide the LN receiver with a new higher fee transaction to speed confirmation.

An LN receiver can use CPFP to mitigate the spamming attack I laid out above, which probably explains why there is a move now to include this functionality in miner calculations.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,994

albin

Active Member
Nov 8, 2015
931
4,008
CPFP definitely seems like something a profit maximizing miner is going to implement themselves anyway as a policy, simply to make rational decisions about tx inclusion vis-a-vis fee density.

RBF rubs me the wrong way at this point, because while it's simply a policy rule that any miner could implement, barring grotesque UX schemes based on functioning persistently at Qmax, it seems unsettling to make something akin to an attack such a priority to actually be a feature of the reference client.
 

Inca

Moderator
Staff member
Aug 28, 2015
517
1,679
When Todd or Core devs start pushing to remove functionality from bitcoin and worsen the user experience you know something isn't ringing true.

Removing zeroconf - at best perfectionist strategy, at worst an attack on bitcoin functionality. Introducing a fee market whilst keeping the blockwidth of the network capped is at best misguided, at worst a direct attack on the economics of the bitcoin ecosystem.

Literally everytime I hear these clowns come out with a new 'feature' that is great for bitcoin it actually worsens the value proposition and attraction of bitcoin as a scarce private money for the world to use over the internet.

Gavin coming back as lead dev and a quick fork to XT is the best thing that could happen to the ecosystem by a long way. The self anointed bitcoin experts dithering and prevaricating in charge of the project now can continue to endlessly debate minutiae but what the project needs is firm leadership and decision making - not airy fairy inaction by committee.

We have a saying in surgery - 'two surgeons, three opinions' - something the Core developers know all about..
 

Peter R

Well-Known Member
Aug 28, 2015
1,398
5,595
CPFP definitely seems like something a profit maximizing miner is going to implement themselves anyway as a policy, simply to make rational decisions about tx inclusion vis-a-vis fee density.

RBF rubs me the wrong way at this point, because while it's simply a policy rule that any miner could implement, barring grotesque UX schemes based on functioning persistently at Qmax, it seems unsettling to make something akin to an attack such a priority to actually be a feature of the reference client.
I've never understood the benefit of replace-by-fees (RBF) if child-pays-for-parent (CPFP) is available. People argue that CPFP only allows the receiver to speed up the TX but this is not true: in (nearly) all cases, the TX would have a change-to-self output. The user would just re-spend this change output back to himself with a high fee.

The only thing I can see that RBF does that CPFP doesn't is RBF makes double-spending 0-conf TXs easier. But intentionally making 0-conf less secure seems pure crazy to me!
 
  • Like
Reactions: awemany and albin

theZerg

Moderator
Staff member
Aug 28, 2015
1,012
2,327
A new block type hit testnet today!!! Version 40000007 means that it supports BIP65 AND large blocks. Bitcoin Unlimited!

Date: 2015-11-25 17:00:31 Size: 998471 NumTx: 544 Ver: 40000007 Hash: 0000000084bad326ea82b6f9540047c56d85fa4233715118fde8012682f7b9dd

Date: 2015-11-25 16:40:26 Size: 134690 NumTx: 38 Ver: 20000007
Hash: 00000000000001bd64c5b5e92e1d006dd14e373704265a9e2b038719492fb769

Date: 2015-11-25 16:39:56 Size: 1075517 NumTx: 497 Ver: 20000007 Hash: 0000000000000099a8e172e3218d92346b3c01f465907610ad24e60382d18e1a

Date: 2015-11-25 16:27:38 Size: 377521 NumTx: 474 Ver: 40000007
Hash: 0000000039463648547d35493b217bf2c527c9e3243e0b6627b4defde53a4756

Date: 2015-11-25 16:07:21 Size: 375612 NumTx: 481 Ver: 40000007
Hash: 000000002862b965432bc9598d634e98d3c0a38a67c962015d2479d4a3e49229


Note that the txn size is < 1MB. I had the mining max set to 1MB but the excessive block size set to 16MB... I'll raise the mining max tonight and see what I can generate.