https://bitco.in/forum/threads/buip037-hardfork-segwit.1591/
Off-chain tx and on-chain tx will compete each other with the same freedom to scale
Topic: So who the hell is still supporting BU? - page 27. (Read 29824 times)
If you are a supporter of LN, you can be sure that you will have it even with BU
https://bitco.in/forum/threads/buip037-hardfork-segwit.1591/
Off-chain tx and on-chain tx will compete each other with the same freedom to scale
https://bitco.in/forum/threads/buip037-hardfork-segwit.1591/
Off-chain tx and on-chain tx will compete each other with the same freedom to scale
I am not an entrepreneur, I told you. I just have a few good ideas that's all.
even if you do say so yourself, lol
If you really believed your ideas were any good, you would be interested in testing them. So what's your real motivation?
you dont relay after sigining.. its already in a smart contract.. thats what "contract" is.. 2 party agreement.
im sure later there may be more 'smart' clauses they will add. but for now post-confirm maturty after settlement (cltv) and chargebacks (csv revokes) are what they are aiming for
Yes what I meant was programmable transaction, through not fully Turing Complete, to avoid malwares.
So for example: Alice sends Bob 1 BTC, but only if Bob already sent out Litecoin to him.
So your create a conditional transaction, that will use some API system to checkup the Litecoin blockchain.
So the TX would be the following (pseudocode):
Code:
If ( MyLTCAddress1.last_transaction.output = 247 && MyLTCAddress1.last_transaction.sender = BobsLTCAddress )
BitcoinBlockchain.Send( 1 BTC , BobsBTCAddress)
else
wait (CurrentBlock + 100)
else
expire()
BitcoinBlockchain.Send( 1 BTC , BobsBTCAddress)
else
wait (CurrentBlock + 100)
else
expire()
So Alice signs this transaction, and broadcasts it, but this is a smart contract that only sends out the money if the conditions are met.
Now this still needs a 3rd party API system to lookup data, and I assume Blockstream could fill out this gap, to get an income source by providing these kinds of API services.
But I don't see how can they control the entire payment system, that would be too outrageous.
You talk so much, as if you actually have something useful to contribute to this topic. Do something, instead of talking. You're no better than the rest of the loudmouths on the forum: endless talk about how much Bitcoin needs your oh-so special ideas.
My prediction: like them, you'll still be doing nothing but talk, years and years later
I am not an entrepreneur, I told you. I just have a few good ideas that's all.
By using the difficulty retarged window, because if miners are mining on the minority chain, they are losing money.
So people are incentivized to stay on the majority chain. Therefore if 90% of miners and nodes agree to a hardfork, they do it, and then the 10% minority will be forced to join them,otherwise they will lose money through mining.
This prevents a chain split like Ethereum VS ETH Classic, because ETH has a 1 min retarget, while BTC has 2 weeks.
So people are incentivized to stay on the majority chain. Therefore if 90% of miners and nodes agree to a hardfork, they do it, and then the 10% minority will be forced to join them,otherwise they will lose money through mining.
This prevents a chain split like Ethereum VS ETH Classic, because ETH has a 1 min retarget, while BTC has 2 weeks.
Right, so do it.
You talk so much, as if you actually have something useful to contribute to this topic. Do something, instead of talking. You're no better than the rest of the loudmouths on the forum: endless talk about how much Bitcoin needs your oh-so special ideas.
My prediction: like them, you'll still be doing nothing but talk, years and years later
Ok let's suppose it is like you say it is.
LN would still be voluntary, and even if it becomes like a payment processor, why can't people move money freely on the blockchain without a 3rd party's permission.
LN would still be voluntary, and even if it becomes like a payment processor, why can't people move money freely on the blockchain without a 3rd party's permission.
voluntary is the utopia/hope. but with onchain tx fee war, the over promotion of LN's utility. halting onchain blocksize. etc etc.. you can see they are aiming for it to be less than voluntary.
EG
if you had to choose between permissionless tx that cost $1 a time and still took an hour
vs
first permissionless tx that cost $1 and still took an hour, but then every 'payment' for 2 weeks was only 5cents and took as fast as both can agree to it (seconds).
would you see the psychological motive of less than voluntary
especially now that they are trying to make LN's locktime become extendable without settling, to keep people locked in.
i would accept LN as a side service.. i see it has a niche for some utility but onchain scaling needs to be sorted.
i dont see LN being useful to everyone
but all blockstream care about is LN as they need a revenue generator to repay the $90m
so looks like onchain scaling is on hold until LN has fully grabbed users funds to charge them fee's
Because a transaction is always consentual. You sign that TX, that is consent, and after that by publishing it it becomes a real transaction.
bitcoin legacy (old normal) transactions, dont need consent(permission) you make it, you sign it you send it
LN is consentual(permissioned) you need someone elses consent/permission/signature/authorisation/agreement.
EG like a bank. you can pay anyone in the world. and you dont need the end recipients permission (not 3rd party)
but you do need banks authorisation/agreement/permission(2nd party)
But what if the transaction doesn't get relayed after signing, instead it get's put into a smart contract system, that will automatically trigger itself after certain conditions are met.
you dont relay after sigining.. its already in a smart contract.. thats what "contract" is.. 2 party agreement.im sure later there may be more 'smart' clauses they will add. but for now post-confirm maturty after settlement (cltv) and chargebacks (csv revokes) are what they are aiming for
Why can't it work like that? It's still consentual, because the money cant move without the signature, and what happens to the money after signing is just up to the smart contract.
exactly
Where does that say it requires a retarget? It should't.
Well I suppose they have 2 weeks to uppgrade, until the difficulty retarget is changed, because the minority of miners will mine invalid blocks.
Where does that say it requires a retarget? It should't.He's confused (whooooosh, lol)
He thinks that the 2016 blocks used to assess the difficulty re-targeting is the same 2016 blocks that evaluate fork signalling. Which is indicative of the rest of his attention to detail: there is no rationale for using the re-targeting window as a fixed timeframe within which forks are decided. That wouldn't make the slightest bit of sense: it's a rolling 2016 block window, irrespective of the difficulty retargetting window.
Nowhere, that is just How I envision a consensus hardfork to happen.
By using the difficulty retarged window, because if miners are mining on the minority chain, they are losing money.
So people are incentivized to stay on the majority chain. Therefore if 90% of miners and nodes agree to a hardfork, they do it, and then the 10% minority will be forced to join them,otherwise they will lose money through mining.
This prevents a chain split like Ethereum VS ETH Classic, because ETH has a 1 min retarget, while BTC has 2 weeks.
Wrong. Let's evaluate:
1) You don't need 51% of nodes for a hard fork.
2) You can fork without any kind of support, i.e. we call those altcoins.
3) You could also split off with this kind of code with any % of hashrate as long as you change the right parameters.
You need that much to legitimize the hardfork, but it would still be volatile.
So above 80% would be considered more safe, maybe 95% as segwit requires.
Deploying and testing custom software takes time. If anything, 'a fast upgrade' would potentially cause huge financial losses.
You are misinterpreting my words.
I have said that it will take months to test and debug the software.
I only said that after the software is clean, then we begin the deployment phase, and in that time window, there will be 2 weeks for people to activate:
Quote
But I guess they will have the code deployed in the software, that will activate at an agreed date. So they will have months to test the software for bugs, and 2 weeks to signal the hardfork.
So up to 6 months of testing and debugging, then 1-2 months to wait for people to download the software, and then 2 weeks to deploy it and activate the hardfork (after a difficulty retarget).
A pretty conservative uppgrading roadmap.
Well I suppose they have 2 weeks to uppgrade, until the difficulty retarget is changed, because the minority of miners will mine invalid blocks.
Where does that say it requires a retarget? It should't.He's confused (whooooosh, lol)
He thinks that the 2016 blocks used to assess the difficulty re-targeting is the same 2016 blocks that evaluate fork signalling. Which is indicative of the rest of his attention to detail: there is no rationale for using the re-targeting window as a fixed timeframe within which forks are decided. That wouldn't make the slightest bit of sense: it's a rolling 2016 block window, irrespective of the difficulty retargetting window.
Well I suppose they have 2 weeks to uppgrade, until the difficulty retarget is changed, because the minority of miners will mine invalid blocks.
Where does that say it requires a retarget? It should't.The hardfork can only happen with 51% of nodes and miners, so they all most uppgrade in this period of time. But possibly an even higher consensus (90-95%) to make it smooth.
Wrong. Let's evaluate:1) You don't need 51% of nodes for a hard fork.
2) You can fork without any kind of support, i.e. we call those altcoins.
3) You could also split off with this kind of code with any % of hashrate as long as you change the right parameters.
It think it could work, but it does require a consensus. You can't just do it with a small percent of people.
Yes you can, but that would not be Bitcoin.If the upgrade happens fast then the financial losses are minimal.
Deploying and testing custom software takes time. If anything, 'a fast upgrade' would potentially cause huge financial losses.I agree, but he was also the guy who had the guts to build Bitcoin, so maybe he made a lot of mistakes in his design, this one I think he got it right.
Considering the knowledge that you've presented through several threads, you should not be making such conclusions on your own. Oh, really? Could you tell me what happens when 1/4, 1/3, 1/2 of the miners are only on the 'updated version' with that code? What happens if only a minority of the nodes have updated?
Well I suppose they have 2 weeks to uppgrade, until the difficulty retarget is changed, because the minority of miners will mine invalid blocks.
The hardfork can only happen with 51% of nodes and miners, so they all most uppgrade in this period of time. But possibly an even higher consensus (90-95%) to make it smooth.
But I guess they will have the code deployed in the software, that will activate at an agreed date. So they will have months to test the software for bugs, and 2 weeks to signal the hardfork.
It think it could work, but it does require a consensus. You can't just do it with a small percent of people.
If the upgrade happens fast then the financial losses are minimal. If the upgrade doesn't happen then bitcoin cant evolve ,and a lot more potential money can be lost (ex. a high fee can scare away a lot of remittances, which is a huge loss to the network)
Satoshi was a visionary, but a lot has been learned in the recent years about blockchain technology in general. This is not a safe way to deploy a hard fork. The centralized alert system is about to be retired as well.
I agree, but he was also the guy who had the guts to build Bitcoin, so maybe he made a lot of mistakes in his design, this one I think he got it right.
I dont know maybe satoshi has a more simple answer than thousands of lines of code:
Oh, really? Could you tell me what happens when 1/4, 1/3, 1/2 of the miners are only on the 'updated version' with that code? What happens if only a minority of the nodes have updated? Satoshi was a visionary, but a lot has been learned in the recent years about blockchain technology in general. This is not a safe way to deploy a hard fork. The centralized alert system is about to be retired as well.
And you've got zero qualifications to make that claim, because you don't read or write code.
That is not entirely true , I know a little bit of C++ and Python.
But yes I am not a good programmer, and I cant make sense of the BTC code, it's way above my knowledge.
However I can do google searches ,and I can read websites, reddit posts, and forum opinions, I am qualified for that.
And based on my research, I have found that Segwit as a softfork is like a bandage.
It would be more elegant to add it as a hardfork, or perhaps just add a 4 mb block increase, because segwit also has a 4 mb weight , that does get relayed on the internet, its just that it doesnt get included in the blockchain.
So maybe the cleaning up of the signature space is a good improvement, and other fixes that it does is good too, but it's still kind of an unelegant way to do it.
I am an amateur in programming, but even I know that something that takes thousands of lines of code to write ,is not necessarily the most efficient way to do it.
I dont know maybe satoshi has a more simple answer than thousands of lines of code:
WTF are you talking about, in this thread I am debating with franky1 about LN, and I said above that BU devs are amateurs, but that doesn't mean that Core devs do their job perfectly.
It is you who is nagging me on both threads, here is your answer:
https://bitcointalksearch.org/topic/m.17699990
It is you who is nagging me on both threads, here is your answer:
https://bitcointalksearch.org/topic/m.17699990
Here's what I'm talking about. In this thread, you said:
I am not satisfied with Core's "hacks & patches" roadmap, of just putting a bandage over a problem.
And you've got zero qualifications to make that claim, because you don't read or write code.
google is your friend.
lightning network HUBs
Ok let's suppose it is like you say it is.
LN would still be voluntary, and even if it becomes like a payment processor, why can't people move money freely on the blockchain without a 3rd party's permission.
Because a transaction is always consentual. You sign that TX, that is consent, and after that by publishing it it becomes a real transaction.
But what if the transaction doesn't get relayed after signing, instead it get's put into a smart contract system, that will automatically trigger itself after certain conditions are met.
Like ethereum's smart contract system.
Why can't it work like that? It's still consentual, because the money cant move without the signature, and what happens to the money after signing is just up to the smart contract.
It doesnt specify any custodian or fiduciary role of any trusted 3rd party, like a bank or payment processor.
google is your friend.
lightning network HUBs
that paragraph quote is just talking about A<->B
the prelim understanding from late 2015.
then they went on to talk about hops in january 2016
https://lightning.network/lightning-network-summary.pdf
Quote
By embedding the payment conditional upon knowledge of a secure cryptographic hash, payments can be made
across a network of channels
across a network of channels
this is where they started talking about a-b-c-d-e
but they soon realise.. although A only talks to B...
B talks both to A and C
in january 2016 they realised B was actually a custodian (mini hub) between A and C
and they started theorising.
what if B also had a connection to D
what if B also had a connection to E
https://lightning.network/lightning-network-paper.pdf
Quote
page 48
Building a routing table will become necessary for large operators
(e.g. BGP, Cjdns). Eventually, with optimizations, the network will look a
lot like the correspondent banking network, or Tier-1 ISPs. Similar to how
packets still reach their destination on your home network connection, not
all participants need to have a full routing table. The core Tier-1 routes
can be online all the time —while nodes at the edges, such as average users,
would be connected intermittently.
Node discovery can occur along the edges by pre-selecting and offering
partial routes to well-known nodes
Building a routing table will become necessary for large operators
(e.g. BGP, Cjdns). Eventually, with optimizations, the network will look a
lot like the correspondent banking network, or Tier-1 ISPs. Similar to how
packets still reach their destination on your home network connection, not
all participants need to have a full routing table. The core Tier-1 routes
can be online all the time —while nodes at the edges, such as average users,
would be connected intermittently.
Node discovery can occur along the edges by pre-selecting and offering
partial routes to well-known nodes
by summer 2016 they continued the idea of 'hub-and-spoke'
again google is your friend
I am not satisfied with Core's "hacks & patches" roadmap, of just putting a bandage over a problem.
Evidence?
Are you doing that thing where you repeat-repeat-repeat a lie, hoping that it will magically come true? I have posted answer here, why are you quoting me on 2 threads the same question:
Why are you posting the same unsubstantiated claims in 2 different threads? You must be really confident in that assertion, but not confident enough to learn how to read or write software code?
How can you tell that Segwit is a "hack" if you can't read or write code?
WTF are you talking about, in this thread I am debating with franky1 about LN, and I said above that BU devs are amateurs, but that doesn't mean that Core devs do their job perfectly.
It is you who is nagging me on both threads, here is your answer:
https://bitcointalksearch.org/topic/m.17699990
I am not satisfied with Core's "hacks & patches" roadmap, of just putting a bandage over a problem.
Evidence?
Are you doing that thing where you repeat-repeat-repeat a lie, hoping that it will magically come true? I have posted answer here, why are you quoting me on 2 threads the same question:
Why are you posting the same unsubstantiated claims in 2 different threads? You must be really confident in that assertion, but not confident enough to learn how to read or write software code?
How can you tell that Segwit is a "hack" if you can't read or write code?
I am not satisfied with Core's "hacks & patches" roadmap, of just putting a bandage over a problem.
Evidence?
Are you doing that thing where you repeat-repeat-repeat a lie, hoping that it will magically come true? I have posted answer here, why are you quoting me on 2 threads the same question:
https://bitcointalksearch.org/topic/m.17699808
LN uses mutisigs..
its not the legacy way of you make a transaction, you sign and you send..
its a joint party thing. like a joint bank account. requiring 2 signatures.
you cant move it without someone else.. = their permission required
its not the legacy way of you make a transaction, you sign and you send..
its a joint party thing. like a joint bank account. requiring 2 signatures.
you cant move it without someone else.. = their permission required
That sounds pretty shitty to me. Any sources for this?
https://lightning.network/
Quote
Bidirectional Payment Channels. Two participants create a ledger entry on the blockchain which requires both participants to sign off on any spending of funds. Both parties create transactions which refund the ledger entry to their individual allocation, but do not broadcast them to the blockchain. They can update their individual allocations for the ledger entry by creating many transactions spending from the current ledger entry output.
Maybe my english is not 100% good, but where in this text does it mention that LN will be a permissioned system.
It just says that 2 participants will do TX between themselves and the funds will be locked by a smart contract.
It doesnt specify any custodian or fiduciary role of any trusted 3rd party, like a bank or payment processor.
It could be automated with existing smart contract systems.
LN uses mutisigs..
its not the legacy way of you make a transaction, you sign and you send..
its a joint party thing. like a joint bank account. requiring 2 signatures.
you cant move it without someone else.. = their permission required
its not the legacy way of you make a transaction, you sign and you send..
its a joint party thing. like a joint bank account. requiring 2 signatures.
you cant move it without someone else.. = their permission required
That sounds pretty shitty to me. Any sources for this?
https://lightning.network/
Quote
Bidirectional Payment Channels. Two participants create a ledger entry on the blockchain which requires both participants to sign off on any spending of funds. Both parties create transactions which refund the ledger entry to their individual allocation, but do not broadcast them to the blockchain. They can update their individual allocations for the ledger entry by creating many transactions spending from the current ledger entry output.
I am not satisfied with Core's "hacks & patches" roadmap, of just putting a bandage over a problem.
Evidence?
Are you doing that thing where you repeat-repeat-repeat a lie, hoping that it will magically come true? LN uses mutisigs..
its not the legacy way of you make a transaction, you sign and you send..
its a joint party thing. like a joint bank account. requiring 2 signatures.
you cant move it without someone else.. = their permission required
That sounds pretty shitty to me. Any sources for this?
(Because maybe you are just exxagerating it)
now blocktream becomes the hub and gets all the fee's to repay back the $90m investment. which they are getting desperate need to release ln before investors make demand..
That would be a shitty move ,but there is no concrete evidence yet that this would be the case.
I would support a Bitcoin Software that does fix the code for real, not just with fake hacks and patches.
Bitcoin Unlimited is a joke, with amateur devs, nobody takes them seriously. If they want to be taken seriously, get some expert developers there, with deep cryptographic, programming and network engineering knowledge and talent.
I am not satisfied with Core's "hacks & patches" roadmap, of just putting a bandage over a problem.
I would like if the BTC code gest fixed for real, with no bloats, and no bugs. But BU won't do this, because they are just amateurs.
So we don't have any good chocie.
Jump to: