Keep tuned trolls. Things are built in the meantime. Pssshhh Wrong forum to keep you all happy. But thx a lot for your will to follow.  Give it up Bcash is dying it's on life support You had a good run but it's time to say goodbye Okok, but lets agree on if Bitcoin Cash is the real Bitcoin, it simply cannot die. Esp if only hand full trolls wish so.  But Bitcoin cash is not the real Bitcoin it's a alt fork just like every other Bitcoin alt fork controlled by a few and disliked by the masses Its an Bitcoin White Paper impl as any other Bitcoin instance is (like Netscape was the first big internet browser impl ...). And the bigger community decides in the end what to use and what to BE the real and best Bitcoin. This is how a decentralized system works. Glad trolls do nothing here, despite showing PoFear = best escorting to the final consensus and winner. Troll harder! |
|
|
|
Keep tuned trolls. Things are built in the meantime. Pssshhh Wrong forum to keep you all happy. But thx a lot for your will to follow. Give it up Bcash is dying it's on life support You had a good run but it's time to say goodbye Okok, but lets agree on if Bitcoin Cash is the real Bitcoin, it simply cannot die. Esp if only hand full trolls wish so, or some core supporters want all hashrate should switch over to BCH |
|
|
|
Keep tuned trolls. Things are built in the meantime. Pssshhh Wrong forum to keep you all happy. But thx a lot for your will to follow. |
|
|
|
But Bitcoin Core does not care. They will run this out till November, no issue. They see BTC as a 'store of value' not a currency. So they really don't care if the block size increases or not. Thus it is more of an issue to the miners.Segwit & LN are the Power Grab, if that fails then BTC Core fails.
But if the seg witness and lighting 'do work' even modestly as bitcoin core hopes...I can see this drag'ing out for another 4-5 years...with the end being you use BCH or LTC for transactions and BTC as a store of value...both camps would then make enough on each horse to flog.....stalemate...it has already gone on far longer than I thought it could so pretty much figure that this is the new normal They have worked very well in terms of losing mostly all transactional / business clients, supporters and such reputation and market share as well. If this down trend for BTC and the uptrend for BCH holds for the next few years.... See what cobra and lukejnr are trying to do, next split of community. |
|
|
|
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... |
|
|
|
|
Good that you do not decide that - it's how it works - relax and see...
|
|
|
|
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/ |
|
|
|
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 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 |
|
|
|
|
Open Source is Open.
You can copy, use what you want and compete
Bitcoin is decentralized, not only in use, but also in ideas, blogs and implementations / versions - everybody needs to think of himself.
|
|
|
|
Zero-confirmation transactions are much more reliable on BCH. So for transactions less than $1000 or so, it is very safe to consider the transaction completed within 2 or 3 seconds.
I know devs are working to make them much more safe. So I d trust amounts < 100€ yet. |
|
|
|
The Ecosystem Building Around Bitcoin Cash Is Very Healthy
Counterparty Cash Announces ERC20 Competitor with Edge Wallet Support for TokensOn February 18 news.Bitcoin.com spoke with the creator of the Counterparty Cash (XCPC) protocol, a project that aims to add tokenized assets to the BCH network. Julian Smith tells us that the Counterparty Cash Association (CCA) based in Zug, Switzerland has formed a partnership with the cryptocurrency wallet provider Edge (formally Airbitz). This means that all assets and tokens based off of the XCPC protocol will work natively with Edge Mobile. Further, the blockchain logistics startup Blockfreight, Bitcoin Cash Parity, and Bitcoin ABC implementations will also support the Counterparty Cash infrastructure.
https://news.bitcoin.com/counterparty-cash-announces-erc20-competitor-with-edge-wallet-support-for-tokens/ |
|
|
|
Too much good news for Bitcoin Cash are always triggering the fear of BTC or LTC bagholders. We can see it triggered very often last time, easy to count by fear posts. Its like a clownish escort for the king coming home. Luv that! |
|
|
|
Proof of Fear is digital and cannot be bartered away. |
|
|
|
God. I watched about 5 minutes of that until I threw up in my mouth. I like how he pretends to start off by objectively explaining what the LN is, but immediately jumps to biased negatives against it... talk about an agenda  I would have expected better from the BCash CEO if they cannot stop lightning, lightning will stop them. we can expect some bitter fighting. they have funds, they have paid troll armies, they are desperate and they are fucked. unfortunately they haven't realized the last part. No, nobody wants stop anyting. This is pointing to things that need fixing. |
|
|
|
Asking for and finally integrating is real work. Some ppl really DO things to make it happen. |
|
|
|
That video has already been pulled apart it's garbage and it's just full of lies but keep spreading it make you look all the more foolish .. by your little mob post here? Sure ... you solved the routing issue and all the others things in a minute |
|
|
|
|
Show Posts
