Gold collapsing. Bitcoin UP.

[Richy_T]

first move your BTC

But fees...

 

[Jonathan Vaage]

@79b79aa8

1. I share my Paycode ID in my Twitter Bio for everyone to see.
2. You paste the code into your wallet to send me a payment, which also adds me to your list of contacts.
3. I get notified of your on-chain payment when it's broadcast on the network and I see that it's from you (whatever label you choose for your own paycode ID).
4. I then have everything I need to send you an encrypted message or a payment back (even on a different supported blockchain). No additional communication or coordination is required.
5. The payment history between us is conveniently captured in a conversation thread for each of us, but there's no way for a third-party to figure out which addresses we've received payments on, even if they have both of our paycodes.

This could really be a game changer for customer-merchant interactions.

 

[Richy_T]

will realize they can't change it for dollars and will flock to bitcoin [...], skyrocketing their value.

Right. But this is exactly what happened at the end of 2013 and look what happened immediately after.

 

[adamstgbit]

@79b79aa8

1. I share my Paycode ID in my Twitter Bio for everyone to see.
2. You paste the code into your wallet to send me a payment, which also adds me to your list of contacts.
3. I get notified of your on-chain payment when it's broadcast on the network and I see that it's from you (whatever label you choose for your own paycode ID).
4. I then have everything I need to send you an encrypted message or a payment back (even on a different supported blockchain). No additional communication or coordination is required.
5. The payment history between us is conveniently captured in a conversation thread for each of us, but there's no way for a third-party to figure out which addresses we've received payments on, even if they have both of our paycodes.

This could really be a game changer for customer-merchant interactions.

these individual payments are private and forever recored onchain.
but once the channel is closed then we can probably easily see that " after it was all said and done Alice paid Bob 0.25BTC amount", right? or is the final receiving address ( once channel is closed ) also private?

 

[Jonathan Vaage]

@adamstgbit

There's no need to 'close' a BIP47 payment channel. This has nothing to do with the Lightning Network. Perhaps I need to use another metaphor. Payment Tunnel could work.

The sender is able to derive a near infinite series of deposit addresses to send to using a Diffie-Helman shared secret. The one-time notification transaction contains the sender's own paycode, which allows the recipient to derive the same sequence of addresses (and private keys) to watch for payments. If the recipient ever loses his wallet, he can restore everything from the seed by re-deriving the same deterministic sequences based on the paycodes attached to transactions sent to the designated notification address.

Hopefully the diagrams help explain how it works behind the scenes. In practice, it just works.

 

[adamstgbit]

@Jonathan Vaage

I'm not very interested in understanding how the magic works, i'm more trying to understand what the magic does what the limitations are, and what the product feels like.

In practice, it just works.

this I understand.

i should really just go try the product out for myself. it sounds gr8.

 

[AdrianX]

"semantics matter." a Bitcoin is 1 BCT + 1 BCH (only investors and speculates need bet on the ratio.)

 

[go1111111]

I think simply increasing the blocksize limit higher and higher as needed, is a bad idea. the first clue that it is a bad idea, is the fact that it relies on central planing, planing to limit it to 1MB forever or planing to keep blocksize as an effectively infinite resource, same bullshit, same type of "central planning", which has nothing to do with a free market.

But if BCH succeeds, it will show the central planning by Core didn't really work out for them. So central planning by BCH devs should be expected to not work out. So you don't need to worry about having a series of block size limits leading to central planning. This is especially true after the fear of HFs that Core encourages gets lower and lower with each successful fork.

At best, EC saves some forking hassle. Even if it worked, EC doesn't fundamentally change the power dynamics. Those are always determined by the market.

IMO, pushing Bitcoin Unlimited pushing EC was a mistake and would be a mistake now. It takes the focus away from more important talking points: market consensus, user choice, and on-chain scaling. We need to keep driving those virtues home until either BCH takes over or until Core adopts them.

With EC, in addition to those things you're also asking users to evaluate "Do you trust your money to this fairly complicated algorithm, which is very different than what we're used to, which you probably don't understand, and which at best just automates a manual process?"
[doublepost=1511046713][/doublepost]

I think exactly the opposite: when the theter scam explodes people will realize they can't change it for dollars and will flock to bitcoin and other coins, skyrocketing their value.

I don't think so -- if the tether scam explodes, tethers will be worth almost nothing, so when people try to move their tether wealth into Bitcoin, they won't be moving much in.

On the other hand, let's say you had $100k worth of tether and $100k worth of Bitcoin. The tether scam explodes and now you have $1k worth of tether and still $100k worth of Bitcoin. Presumably there was a reason why you were holding $100k in a USD-like asset. Now you have almost nothing in such an asset, so you want to rebalance. So you sell some of your Bitcoin, driving down the price.

Tether is basically just monetary inflation, which is expected to drive up prices. When "dollars" are more plentiful, the more of them you need to buy anything else.

 

[adamstgbit]

*first 20 mins are skipable intro.

looks like he is taking a shot every time he answers a question.

i love the way this guy talks, its slightly confusing at times, not because hes confused, clearly just because not a gr8 public speaker, trying to convey complex stuff. But the Raw not gonna take any shit and tell it how it is without a care in the world about offending poeple. so good.

 

[Mengerian]

I'm not very interested in understanding how the magic works, i'm more trying to understand what the magic does what the limitations are, and what the product feels like.

Hey @adamstgbit Let me try my hand at explaining how it works.

What the Payment Code does, effectively, is it gives a way for the two parties to secretly exchange a long list of addresses with each other.

If you give me your Payment Code, my wallet can combine that with my Payment Code to create a "notification transaction". This "notification transaction" allows you to extract the information needed to generate a long list of receiving addresses. Then, in future, any time you receive a payment to one of those addresses, you know that it comes from me (since no-one else had the information needed to generate the address list).

Similarly, the notification transaction also has the information needed for you to generate another long list of addresses that you can send to, that I can receive coins with. So any time you send a transaction to one of those addresses, I will know it comes from you.

So for you and me, it seems just like sending to and from a single address that we can reply to, like email. But to everyone else on the network, it just looks like a bunch of unrelated transactions to different addresses.

 

[adamstgbit]

But if BCH succeeds, it will show the central planning by Core didn't really work out for them. So central planning by BCH devs should be expected to not work out. So you don't need to worry about having a series of block size limits leading to central planning.

bullshit.
8MB was centrally planned and so will every other increase BCH does in the future, even totally lifting the limit altogether would be central planing.

At best, EC saves some forking hassle

it allows blocksize to move more freely, which is necessary for a balanced fee market to occur
1MB == very high fees
1GB == no fees at all
one is bad because hurts utility
the other is bad because the system can't sustain itself on 0 reward pre block

it is absolutely critical that miners make ALOT of money, security of bitcoin is based on that.
miner need to maximize fee revenue by controlling blocksize, EC lets them do that very neatly.

IMO, pushing Bitcoin Unlimited pushing EC was a mistake and would be a mistake now. It takes the focus away from more important talking points: market consensus, user choice, and on-chain scaling. We need to keep driving those virtues home until either BCH takes over or until Core adopts them.

EC is all about market consensus, user choice, and on-chain scaling.

With EC, in addition to those things you're also asking users to evaluate "Do you trust your money to this fairly complicated algorithm, which is very different than what we're used to, which you probably don't understand, and which at best just automates a manual process?"

without EC blocksize will never be "right"

no limit blocksize == 0 blockreward for processing huge amount of TX == never gana work.

we need a limit, and it needs to be highly dyn.

 

[freetrader]

@go1111111 Core believes it has market consensus, as reflected by the price. Clearly any other claims on consensus have fallen apart by now, but they still have that one.

Regarding the block size limit - EC should be subjected to renewed scrutiny imo as it is an untested mode of operation for the system. That research paper that came out a while back did not get an in-depth rebuttal, so its criticisms against EC may hold some water.

From the point of view of simplicity one would argue in favor of just abolishing the limit altogether.
That makes many people nervous.

Failing that, an adaptive blocksize seems like it could get some support.

In this new era of multiple clients, I don't think we can realistically expect a common algorithm anymore, which becomes effectively some kind of complex form of EC. That may not be a bad thing! It may just make the system as a whole more difficult to attack.

 

[adamstgbit]

In this new era of multiple clients, I don't think we can realistically expect a common algorithm anymore, which becomes effectively some kind of complex form of EC. That may not be a bad thing! It may just make the system as a whole more difficult to attack.

lol, right didn't realize that.

Regarding the block size limit - EC should be subjected to renewed scrutiny imo as it is an untested mode of operation for the system. That research paper that came out a while back did not get an in-depth rebuttal, so its criticisms against EC may hold some water.

maybe BU's EC can be simplified improved and tested more. i think its a worthwhile effort. just because we have to live on a network with nodes that hardcode their limit dosnt mean BU node's have to do the same thing.

From the point of view of simplicity one would argue in favor of just abolishing the limit altogether.

its simply unworkable, because miners need to get paid, and pretty soon in like only ?8 years? fees are going to be extremely important, sure poeple could pay miners out of pocket to secure the network, but sounds like the network inst able to stand on its own 2 feet.

but maybe simply having wallets attach a 1cent fee will be enough to pay for network security in the future.

1 million cents pre block? is that enough?

somehow i'd feel better knowing miners are made to agree on a block-size which maximizes their fee revenue, base on current TX demand.

 

[79b79aa8]

adam you are concern trolling now.

30,000 tx/sec * 60 sec/min = 1,800,000 tx/min
1,800,000 tx/min * 1/10 blocks/min = 18,000,000 tx/block
18,000,000 tx/block * 1/100 USD/tx = $180,000 USD/block

so at 1c per transaction, assuming visa-level throughput, you have more than 10x today's BCH block reward.

it is certainly possible. we are talking about decades into the future, when the number of global blockchain transactions will be orders of magnitude higher than those done by people who pay with plastic today.

 

[Peter R]

Regarding the block size limit - EC should be subjected to renewed scrutiny imo as it is an untested mode of operation for the system. That research paper that came out a while back did not get an in-depth rebuttal, so its criticisms against EC may hold some water.

I don't know if we'll be able to have sane discussion as a community until the block size limit war is further behind us, so I don't really see much point in making an in-depth public rebuttal, but, for readers here, a few of my thoughts:

That paper mostly echoed the results that we already knew: for example, that miners are indeed incentivized to converge upon a common block size limit, and to change that limit in lock-step. I do appreciate the authors attempt at formalizing this result.

The authors then showed that if miners behaved badly that forks could result with BU. Of course, we already knew that too. The way the paper was written, though, made it appear possible to prevent the miners from behaving badly by having a "hard limit defined at the protocol level" -- as though the "protocol" exists independently of the blockchain as some absolute higher-order truth.

OK, sure, if you assume that a God-governed protocol limit exists, is well known, is respected, and can be adjusted, then...yeah....that's better than BU. But in the real world no one has control over the protocol [1], and so now you're back to emergence consensus. The only way to know if a block will be accepted into the most-work chain is to mine it find out!

[1] Incidentally, in further dialog I had with one of the authors, it became clear that he indeed did view the "protocol" as some higher-order truth that existed on a different plane that Nakamoto consensus.

 

[Epilido]

miner need to maximize fee revenue by controlling blocksize, EC lets them do that very neatly.

Miners can already do this by limiting the smallest fee they will accept into a block. This would give a base fee for a transaction and would be dynamic. The miners change fees based on what there marginal cost to mine is plus profit. If the profit is too high some other miner will come and sweep the slightly lower fees.

 

[majamalu]

↑ This!

Isn't that the way Bitcoin used to work before we hit the 1MB limit?

 

[adamstgbit]

adam you are concern trolling now.

30,000 tx/sec * 60 sec/min = 1,800,000 tx/min
1,800,000 tx/min * 1/10 blocks/min = 18,000,000 tx/block
18,000,000 tx/block * 1/100 USD/tx = $180,000 USD/block

so at 1c per transaction, assuming visa-level throughput, you have more than 10x today's BCH block reward.

it is certainly possible. we are talking about decades into the future, when the number of global blockchain transactions will be orders of magnitude higher than those done by people who pay with plastic today.

maybe i am "concern trolling" oh well... lets continue

if it cost is ~90K / 10mins to 51% the network, this seems just fine, for a block that is moving say 3million dollars of value, but 3billion dollars? of value being "secured" by 90K$ worth of POW
thats starting to sound funny...

 

[jbreher]

i would like BCH even more, if Bitcoin Unlimited becomes the most popular implementation of BCH.​

I was using BU before swapping to ABC immediately before the fork. I'm on record as desirous of reducing deadalnix' ability to force autocratic decisions upon BCH, by bailing on ABC. Given my previous good experience in using BU, I'd like to go back to that.

Couple wrinkles:

1) Can I simply deinstall ABC and install latest BU? Will the block data and indexing still be valid?

2) I left ABC up and running through the DAA fork, and probably a couple days since. Does this complicate the above?

 

[adamstgbit]

Miners can already do this by limiting the smallest fee they will accept into a block. This would give a base fee for a transaction and would be dynamic. The miners change fees based on what there marginal cost to mine is plus profit. If the profit is too high some other miner will come and sweep the slightly lower fees.

the only problem i see with this approach is that it requires all miners to agree to all not include TX that have < 5sat/byte fee. the minute one miner starts grabbing these low-fee TX he becomes more profitable, and then all miners need to do the same to compete, "strategy of the commons" i think is the problem here. i think at best this could work to enforce a 1sat fee minimum, which might actually be good enough IF the network has very high through put.

with the blocksize limit Via EC,miners dont need to all agree on a specific limit, they just need to make sure the blocks they generate respect the limits of at least 51% of the network ( realistically at least 75% ) so as long as SOME miners understand that offering limitless blockspace is less profitable ( which leads to a less incentive to mine&secure the blockchain ) then a reasonable blocksize limit will be enforced. no "strategy of the commons", only a free and open network all voting on which blocksize they feel benefits them the most, and that is NOT a limitless blocksize nor is it a hard limit that ends up destroying utility as we see with BTC today.

it could be that user wont mind setting a nice fee when sending large amounts, if users start to see TX fees a "optional tip" that they LIKE to do, the "fee market" thing might be completely unnecessary, ya this rant i'm going on and on about might just be "concerned trolling."