PHP/BCH Trading Pair on Coins.ph (February 21)
https://coindar.org/en/event/bitcoin-cash-bch-phpbch-trading-pair-on-coinsph-4564
Topic: [ANN] Bitcoin Cash - Pro on-chain scaling - Cheaper fees - page 259. (Read 704531 times)
Hello I have 0.8 BCH available at the moment and I’m selling for 800$. Contact me if you are interested in buy. Thanks
It is traded in many exchanges. Why do not you sell there.The question should be why are they wanting to sell below market rate sounds highly suspicious
Hello I have 0.8 BCH available at the moment and I’m selling for 800$. Contact me if you are interested in buy. Thanks
It is traded in many exchanges. Why do not you sell there.
Hello I have 0.8 BCH available at the moment and I’m selling for 800$. Contact me if you are interested in buy. Thanks
Tough you kinda have to wonder why it is that demand for Bitcoin transactions has dropped below a third-million a day. While lower fees are attractive, the fact that this is due to lack of demand seems worrisome.
It should be worrisome, because if BTC crashes, everything else goes with it. Traders understand these things because we know how to read price action. The BCH guys who have been bashing BTC better hope BTC becomes bullish again. Otherwise, it's over for crypto as we know it. That's not to say crypto will become useless, but rather that it won't be profitable to invest in. And if the money stops flowing in, what do you think will happen to the exchanges? Take a wild guess!
Tough you kinda have to wonder why it is that demand for Bitcoin transactions has dropped below a third-million a day. While lower fees are attractive, the fact that this is due to lack of demand seems worrisome.
Like always you cannot use tx count as a metric to judge usage
This is like using your car tachometer to judge it's speed
Tough you kinda have to wonder why it is that demand for Bitcoin transactions has dropped below a third-million a day. While lower fees are attractive, the fact that this is due to lack of demand seems worrisome.
Would you ever come back to a bank or fintech that once ripped you over?
There are very good averages out there for all sorts of different businesses how long it takes to get over a lost reputation event to win back lost business and you can hire expensive consultants and analysts that might speed that up a bit.
Banking and finance sector takes longest...
Tough you kinda have to wonder why it is that demand for Bitcoin transactions has dropped below a third-million a day. While lower fees are attractive, the fact that this is due to lack of demand seems worrisome.
Today I sent a few BTC and paid only $0.23 for it. The transaction came in a few minutes I did not even have time to finish my coffee)) It seems to me that because of these improvements of the original bitcoin network, BCH can lose its popularity. Roger Ver is loosing the battle atm...
$0.23? You overpaid.
I made a 5 satoshi/byte tx ($0.1) few days ago and it went through almost instantly.
Depends on the inputs I sent 1BTC a few days ago for 2sat/B and that cost me $0.13
Today I sent a few BTC and paid only $0.23 for it. The transaction came in a few minutes I did not even have time to finish my coffee)) It seems to me that because of these improvements of the original bitcoin network, BCH can lose its popularity. Roger Ver is loosing the battle atm...
$0.23? You overpaid.
I made a 5 satoshi/byte tx ($0.1) few days ago and it went through almost instantly.
I believe Roger has something up his ass.
Operation Dragon Slayer will happen but it will fail.
I am keeping some Beetcoin Cash just to dump when Roger pumps his shitcoin to fucking uranus.
Operation Dragon Slayer will happen but it will fail.
I am keeping some Beetcoin Cash just to dump when Roger pumps his shitcoin to fucking uranus.
Today I sent a few BTC and paid only $0.23 for it. The transaction came in a few minutes I did not even have time to finish my coffee)) It seems to me that because of these improvements of the original bitcoin network, BCH can lose its popularity. Roger Ver is loosing the battle atm...
Bcash epic fale ~ .05 here we go :-D weee
Good that you do not decide that - it's how it works - relax and see...
Good thing - you can see how decentral dev & idea competing works in real live.
It's about to improve Bitcoin Cash into Smart Contracts and Colored Coins / asset pegging, but not to f_ck all up like ETH...
BTC is still busy with 'txs' ...
Cmon run your little BTC-LN-SW RASPISS nodes and be happy for ppl still wanna do some txs
It's about to improve Bitcoin Cash into Smart Contracts and Colored Coins / asset pegging, but not to f_ck all up like ETH...
BTC is still busy with 'txs' ...
Cmon run your little BTC-LN-SW RASPISS nodes and be happy for ppl still wanna do some txs
It's actually quite the opposite they are arguing because Bitcoin cash is becoming too centralised it was supposed to have competing development teams but in reality ABC dictating the development with over 95% of all clients and it's something they wanted to get away from
Nope - you spread fake news. There was also not really much to do yet - and ABC had the lead an some important stuff.
BU is very strong as well.
XT needs to keep up a bit
nChain is still very present.
Lots of other individuals have a speak (bitcoinj,..)
The outcome is relevant and I see a good discussion style as it should be.
One such thread
https://np.reddit.com/r/btc/comments/7z112c/the_community_needs_to_distance_itself_from/
There are many like this with lots of disagreements this is not what you want
Nice post from silverjustice here
But further, if you want specific advantages for some of these, then I recommend you check out the below from the scaling Bitcoin conference:
opcodes are very useful, such as in for example with CAT you can do tree signatures even if you have a very complicated multisig design using CAT you could reduce that size to log(n) size. It would be much more compact. Or with XOR we could do some kind of deterministic random number generator by combining secret values from different parties so that nobody could cheat. They could combine and generate a new random number. If people think-- ... we could use LEFT to make weaker hash. These opcodes were re-enabled in sidechain elements project. It's a sidechain from Bitcoin Core. We can reintroduce these functions to bitcoin.
The other problem are the ... numeric operations which were disabled by Satoshi. There's another problem. Which is that the range of values accepted by script is limited and confused because the CScript.. is processed at ..... bit integers internally. But to these opcodes it's only 32 bits at most. So it's quite confusing. The other problem is that we have this.. it requires 251 encode or calculate or manipulate this number. So we need at least 52 bits. But right now it is only 32 bits. So the proposal is to expand the valid input range to 7 bytes which would allow 56 bits. And it limits the maximum size to 7 bytes so we could have the same size for inputs and outputs. For these operations, we could re-enable them within these safe limits. It would be safe for us to have these functions again.
The other problem is that we currently cannot commit to additional scripts. In the original design of bitcoin, we could have script operations inside of the signature. But the problem is that the signature is not covered by the signature itself. So any script in the scriptSig is modifiable by any third party in the network. For example, if we tried to do a CHECKSIG operation in the signature, people could simply replace it with an OP_0 and invalidate the transaction. This is a bypass of the.. signature check in the scriptSig. But actually this function is really useful, for example, we can do... delegation, people could add additional scripts to a new UTXO without first spending it. So people could do something like let's say to let their son spend their coin within a year if it is not first spent otherwise.. and also, people, talk about replay protection. So we have some ohter new opcode like pushing the blockhash to the stack, with this function we could have replay protection to make sure the transaction is valid only in a specified blockchain.
So the proposal is that in the future the CHECKSIG should have the ability to sign additional script and to execute these scripts. And finally the other problem is that the script has limited access to different parts of the transaction. There is only one type of operation that allowed to investigate different parts of the transaction, which is CHECKSIG and CHECKMULTISIG. But it is very limited. There are sighash limitations here... there are only 6 types of sighash. The advantage of doing this is that it's very compact and could use only one byte to indicate which component to sign. But the problem is that it's inflexible. The meaning of this sighash is set at the beginning and you can't change it. You need a new witness version to have another checksig. And the other problem is that the sighash can be complex and people might make mistakes so Satoshi made this mistake in the sighash design such as the well-known bug in validation time and also the SIGHASH_SINGLE bug. It's not easy to prevent.
The proposal is that we might have the next generation of sighash (sighashv2) to expand to two bytes, allow it to cover different parts of the transaction and allow people to choose which components they would like to sign. This would allow more flexibility and hopefully not overly complicated. But still this is probably not enough for more flexible design.
Another proposal is OP_PUSHTXDATA which pushes the value of different components of a transaction to the stack. It's easy to implement, for example, we could just push the scriptpubkey of the second output to the stack, okay. So it is actually easier to implement. We could do something more than just... because we have sighash, we could check where something is equal to the specified value. But if we could push the value, like the value of an output to the stack, then we could use other operations like more than or less than and then we could do something like checking whether the value of output x must be at least y bitcoin, which is a fixed value.
There are some other useful functions like MAST which would allow for more compact scripts by hiding the other unexecuted branches. There's also aggregation that would allow n-of-n multisig to be reduced to a single signature and so on. In the elements project, they implemented CHECKSIGFROMSTACK where they don't check the transaction structure but instead they verify a message on the stack. So it could be some message like not bitcoin maybe, perhaps cross-chain swap, or another bitcoin UTXO. And also we might have some elliptic curve point addition and operations which are also useful in lightning network design.
Here are some related works in progress. If you are interested in this topic, I would like to encourage you to join our discussions because it's a very active topic. jl2012 bip114 MAST, maaku's MBV, luke-jr or version-1 witness program, Simplicity, etc.
so you have your script template the amount value and there is a block impactor beause we have the sha chain whih allows you to hae the hashes.. we can hae that errortate constant beause you need the HTLC chashes, to properly reoke the prior states and if you an't do that then you can't onstruct the redeem script. Right now it ineeds a signature for eery state, you need all the HTLCs, it needs the netowrk erification state, and there's another cool thing you can do with which is like trap door erification and you can include it in the transaction itself and there can be a alsue where there is some margin for it.. Which make sit powerful, and then you can make it more private with these constructs. We only have a few minutes left, we can cover this.
One furthe rthing is that in the transformation, we have privacy issue because we need to keep going forward, we need to have hte private state, so there's a history of this in the ages in the past, the current one used replications, which was one of the cool things about lightning. We used to have deckman signatures we had a sequence value of like 30 days, we did an update, we had to switch sides then we make it 29 then 27 etc. You can only broadcast the most recent state because otherwise the other party can transact the other transaction. If you start with 30 days then you can only do about 30 bidirectiona lswitches. Then there was cdecker's payment channels where you have a root tree and every time you need to- you had two payment channels, you had to rebalance htem and then it's on your part of the channel you can reset the channel state. You can do 30 this way, you have another tree, you can do it that way, and then there's a new version of it in the indefinite lifetime... by keeping the transaction in CSV, the drawback on that paproahc because you have al arge validation tree, in the worst cas eyou have 8 or 10 on the tree, and then you nee dfor the prior state and then you do the 12 per day, and every time you have to make a state, you have to revoke the preimage from the prior state, this is cool because if they ever broadcast the entire state, eahc one has the caluse so that you can draw the entire money in the event o f a violation. There are some limitations for doing more complex verifications and you have this log(n) state that you have to deal with ehen you deal with that.
We're going to do the key power on the stack to limit key verifications on this main contract. this is all composable. You can do discreet log contracts. You can now check signtures on arbitrary messages. You can sign a message nad then we can enforce structure on the messages themselves. Right now you need to have sequene numbers. So each state we are going to increment the sequence numbers. So you give me a siequence number on that state. On the touputs we have a commitment ot the sequence number and the value r. So people on chain will know that how many places we did in that itself. The ool part about this is that because we have a seq number then I have the one if it's highest neough. Then I am opening that commitment to say this is state 5 and I present to you a new signed ommitment and open that as well, that's in a validation state. The cool things is that you only need one of those m. So we have to some auxiliary state, and each time I have a new state I an drop the old state. I have a signed commitment to revoke the prior state. This is a ibg deal beause the state is much smaller. Currently we require you to fwe use a state mahcine on state 2, and it also has implications for verifications and watch tower
So on lightning, there's this technique itself- it's timelocks CSV value and if you can't react within that value then you can't go to court and enforce judgement on this attacker. So the watchtower is a requirement, you delegate the state watching to the watchtower. They know which channels you're watching. You send some initial points, like a script template. For every one you send the signautre and the verification state. They can use the verification stat ethat collapses into a log(n) tree, you can basically use state where you send half the txids, you can decrypt this in... some time.
https://www.reddit.com/r/btc/comments/7z49at/whats_the_fng_benefit_of_the_reactivated_op_codes/duld80p/
Quote
But further, if you want specific advantages for some of these, then I recommend you check out the below from the scaling Bitcoin conference:
opcodes are very useful, such as in for example with CAT you can do tree signatures even if you have a very complicated multisig design using CAT you could reduce that size to log(n) size. It would be much more compact. Or with XOR we could do some kind of deterministic random number generator by combining secret values from different parties so that nobody could cheat. They could combine and generate a new random number. If people think-- ... we could use LEFT to make weaker hash. These opcodes were re-enabled in sidechain elements project. It's a sidechain from Bitcoin Core. We can reintroduce these functions to bitcoin.
The other problem are the ... numeric operations which were disabled by Satoshi. There's another problem. Which is that the range of values accepted by script is limited and confused because the CScript.. is processed at ..... bit integers internally. But to these opcodes it's only 32 bits at most. So it's quite confusing. The other problem is that we have this.. it requires 251 encode or calculate or manipulate this number. So we need at least 52 bits. But right now it is only 32 bits. So the proposal is to expand the valid input range to 7 bytes which would allow 56 bits. And it limits the maximum size to 7 bytes so we could have the same size for inputs and outputs. For these operations, we could re-enable them within these safe limits. It would be safe for us to have these functions again.
The other problem is that we currently cannot commit to additional scripts. In the original design of bitcoin, we could have script operations inside of the signature. But the problem is that the signature is not covered by the signature itself. So any script in the scriptSig is modifiable by any third party in the network. For example, if we tried to do a CHECKSIG operation in the signature, people could simply replace it with an OP_0 and invalidate the transaction. This is a bypass of the.. signature check in the scriptSig. But actually this function is really useful, for example, we can do... delegation, people could add additional scripts to a new UTXO without first spending it. So people could do something like let's say to let their son spend their coin within a year if it is not first spent otherwise.. and also, people, talk about replay protection. So we have some ohter new opcode like pushing the blockhash to the stack, with this function we could have replay protection to make sure the transaction is valid only in a specified blockchain.
So the proposal is that in the future the CHECKSIG should have the ability to sign additional script and to execute these scripts. And finally the other problem is that the script has limited access to different parts of the transaction. There is only one type of operation that allowed to investigate different parts of the transaction, which is CHECKSIG and CHECKMULTISIG. But it is very limited. There are sighash limitations here... there are only 6 types of sighash. The advantage of doing this is that it's very compact and could use only one byte to indicate which component to sign. But the problem is that it's inflexible. The meaning of this sighash is set at the beginning and you can't change it. You need a new witness version to have another checksig. And the other problem is that the sighash can be complex and people might make mistakes so Satoshi made this mistake in the sighash design such as the well-known bug in validation time and also the SIGHASH_SINGLE bug. It's not easy to prevent.
The proposal is that we might have the next generation of sighash (sighashv2) to expand to two bytes, allow it to cover different parts of the transaction and allow people to choose which components they would like to sign. This would allow more flexibility and hopefully not overly complicated. But still this is probably not enough for more flexible design.
Another proposal is OP_PUSHTXDATA which pushes the value of different components of a transaction to the stack. It's easy to implement, for example, we could just push the scriptpubkey of the second output to the stack, okay. So it is actually easier to implement. We could do something more than just... because we have sighash, we could check where something is equal to the specified value. But if we could push the value, like the value of an output to the stack, then we could use other operations like more than or less than and then we could do something like checking whether the value of output x must be at least y bitcoin, which is a fixed value.
There are some other useful functions like MAST which would allow for more compact scripts by hiding the other unexecuted branches. There's also aggregation that would allow n-of-n multisig to be reduced to a single signature and so on. In the elements project, they implemented CHECKSIGFROMSTACK where they don't check the transaction structure but instead they verify a message on the stack. So it could be some message like not bitcoin maybe, perhaps cross-chain swap, or another bitcoin UTXO. And also we might have some elliptic curve point addition and operations which are also useful in lightning network design.
Here are some related works in progress. If you are interested in this topic, I would like to encourage you to join our discussions because it's a very active topic. jl2012 bip114 MAST, maaku's MBV, luke-jr or version-1 witness program, Simplicity, etc.
so you have your script template the amount value and there is a block impactor beause we have the sha chain whih allows you to hae the hashes.. we can hae that errortate constant beause you need the HTLC chashes, to properly reoke the prior states and if you an't do that then you can't onstruct the redeem script. Right now it ineeds a signature for eery state, you need all the HTLCs, it needs the netowrk erification state, and there's another cool thing you can do with which is like trap door erification and you can include it in the transaction itself and there can be a alsue where there is some margin for it.. Which make sit powerful, and then you can make it more private with these constructs. We only have a few minutes left, we can cover this.
One furthe rthing is that in the transformation, we have privacy issue because we need to keep going forward, we need to have hte private state, so there's a history of this in the ages in the past, the current one used replications, which was one of the cool things about lightning. We used to have deckman signatures we had a sequence value of like 30 days, we did an update, we had to switch sides then we make it 29 then 27 etc. You can only broadcast the most recent state because otherwise the other party can transact the other transaction. If you start with 30 days then you can only do about 30 bidirectiona lswitches. Then there was cdecker's payment channels where you have a root tree and every time you need to- you had two payment channels, you had to rebalance htem and then it's on your part of the channel you can reset the channel state. You can do 30 this way, you have another tree, you can do it that way, and then there's a new version of it in the indefinite lifetime... by keeping the transaction in CSV, the drawback on that paproahc because you have al arge validation tree, in the worst cas eyou have 8 or 10 on the tree, and then you nee dfor the prior state and then you do the 12 per day, and every time you have to make a state, you have to revoke the preimage from the prior state, this is cool because if they ever broadcast the entire state, eahc one has the caluse so that you can draw the entire money in the event o f a violation. There are some limitations for doing more complex verifications and you have this log(n) state that you have to deal with ehen you deal with that.
We're going to do the key power on the stack to limit key verifications on this main contract. this is all composable. You can do discreet log contracts. You can now check signtures on arbitrary messages. You can sign a message nad then we can enforce structure on the messages themselves. Right now you need to have sequene numbers. So each state we are going to increment the sequence numbers. So you give me a siequence number on that state. On the touputs we have a commitment ot the sequence number and the value r. So people on chain will know that how many places we did in that itself. The ool part about this is that because we have a seq number then I have the one if it's highest neough. Then I am opening that commitment to say this is state 5 and I present to you a new signed ommitment and open that as well, that's in a validation state. The cool things is that you only need one of those m. So we have to some auxiliary state, and each time I have a new state I an drop the old state. I have a signed commitment to revoke the prior state. This is a ibg deal beause the state is much smaller. Currently we require you to fwe use a state mahcine on state 2, and it also has implications for verifications and watch tower
So on lightning, there's this technique itself- it's timelocks CSV value and if you can't react within that value then you can't go to court and enforce judgement on this attacker. So the watchtower is a requirement, you delegate the state watching to the watchtower. They know which channels you're watching. You send some initial points, like a script template. For every one you send the signautre and the verification state. They can use the verification stat ethat collapses into a log(n) tree, you can basically use state where you send half the txids, you can decrypt this in... some time.
https://www.reddit.com/r/btc/comments/7z49at/whats_the_fng_benefit_of_the_reactivated_op_codes/duld80p/
Good thing - you can see how decentral dev & idea competing works in real live.
It's about to improve Bitcoin Cash into Smart Contracts and Colored Coins / asset pegging, but not to f_ck all up like ETH...
BTC is still busy with 'txs' ...
Cmon run your little BTC-LN-SW RASPISS nodes and be happy for ppl still wanna do some txs
It's about to improve Bitcoin Cash into Smart Contracts and Colored Coins / asset pegging, but not to f_ck all up like ETH...
BTC is still busy with 'txs' ...
Cmon run your little BTC-LN-SW RASPISS nodes and be happy for ppl still wanna do some txs
Well BTC has more then 10X the TX amount of Bcash
https://bitinfocharts.com/bitcoin/'
https://bitinfocharts.com/bitcoin%20cash/
Good thing - you can see how decentral dev & idea competing works in real live.
It's about to improve Bitcoin Cash into Smart Contracts and Colored Coins / asset pegging, but not to f_ck all up like ETH...
BTC is still busy with 'txs' ...
Cmon run your little BTC-LN-SW RASPISS nodes and be happy for ppl still wanna do some txs
It's about to improve Bitcoin Cash into Smart Contracts and Colored Coins / asset pegging, but not to f_ck all up like ETH...
BTC is still busy with 'txs' ...
Cmon run your little BTC-LN-SW RASPISS nodes and be happy for ppl still wanna do some txs
It's actually quite the opposite they are arguing because Bitcoin cash is becoming too centralised it was supposed to have competing development teams but in reality ABC dictating the development with over 95% of all clients and it's something they wanted to get away from
Nope - you spread fake news. There was also not really much to do yet - and ABC had the lead an some important stuff.
BU is very strong as well.
XT needs to keep up a bit
nChain is still very present.
Lots of other individuals have a speak (bitcoinj,..)
The outcome is relevant and I see a good discussion style as it should be.
Good thing - you can see how decentral dev & idea competing works in real live.
It's about to improve Bitcoin Cash into Smart Contracts and Colored Coins / asset pegging, but not to f_ck all up like ETH...
BTC is still busy with 'txs' ...
Cmon run your little BTC-LN-SW RASPISS nodes and be happy for ppl still wanna do some txs
It's about to improve Bitcoin Cash into Smart Contracts and Colored Coins / asset pegging, but not to f_ck all up like ETH...
BTC is still busy with 'txs' ...
Cmon run your little BTC-LN-SW RASPISS nodes and be happy for ppl still wanna do some txs
It's actually quite the opposite they are arguing because Bitcoin cash is becoming too centralised it was supposed to have competing development teams but in reality ABC dictating the development with over 95% of all clients and it's something they wanted to get away from
Good thing - you can see how decentral dev & idea competing works in real live.
It's about to improve Bitcoin Cash into Smart Contracts and Colored Coins / asset pegging, but not to f_ck all up like ETH...
BTC is still busy with 'txs' ...
Cmon run your little BTC-LN-SW RASPISS nodes and be happy for ppl still wanna do some txs
It's about to improve Bitcoin Cash into Smart Contracts and Colored Coins / asset pegging, but not to f_ck all up like ETH...
BTC is still busy with 'txs' ...
Cmon run your little BTC-LN-SW RASPISS nodes and be happy for ppl still wanna do some txs
Jump to: