The driver for SegWit seems to be purely LN This is an rbtc talking point-- it has no basis in reality. Segwit is largely orthogonal to lightning, and proposed long after it. The reason people keep claiming it is because segwit is above reproach and lightning is less well understood and easier to FUD. Hmm, I suspect actually a lot of people think that because on the Segwit FAQ, here: https://bitcoincore.org/en/2016/01/26/segwit-benefits/ it says: Who benefits?
...
...
The Lightning Network
...
Sure the lightning network benefits from segwit, but it is not the only reason (if a reason at all) that segwit exists. If you look at the rest of the document, there are a whole lot more benefits than just LN. The rbtc taking point is that segwit is only for lightning, but it most certainly is not. Since GMaxwells ignore system doesn't seem to be functioning, I may address that when I have more time but in the meantime.... I have no idea what "rbtc" is. Searches yield mainly bible groups, so I've really no idea what is being referenced. The linked document by tertius993 gives 4 benefits. 1. Wallet authors tracking spent bitcoins According to GMaxwell no one cares, apparently. 2. Anyone spending unconfirmed transactions This was never a good idea and has always been stated that 6 confirmations is the bare minimum and use zero at your own risk. It is an obvious area for improvement but segwit just offloads the risk to a third party like any side-chain as was intended in the original design. 3. The Lightning Network Of course. 4. Anyone using the block chain This is just a sales pitch. At best it is a corollary of #1 without explicit definition. #1 & #4, if we take these as read, are saying that having an immutable txID has benefits (IMO, malleable TxID was a bug). #3 was a design decision and the usual retort to things like that from the eminent legendaries is "go make your own alt-coin". None of them are peculiar to SegWit but #3 requires it. |
|
|
|
|
Can't we add callbacks or events to the core (like On_Receive etc) so that we can create our own filters and stream them to our applications?
|
|
|
|
|
Security is a trade-off between complexity and convenience. Binary arguments about security mean that your data might never get stolen but no-one uses the software - just ask PGP.
My opinion is that brain wallets aren't the most secure but they are secure enough for many non technical users. If it is a commercial service that is being offered then there are other measures to mitigate the risk of loss like insurance-an admission that it can occur and allow compensation according to risk probability.
|
|
|
|
This has been done in Bitcoin,
Are you referring to // Negative numbers are not allowed for R.
if (sig[4] & 0x80) return false;
.......
// Negative numbers are not allowed for S.
if (sig[lenR + 6] & 0x80) return false;
I would have gone for |r| and |s| personally so no explicit rejection would be required. I wasn't sure that N-s was negative for all values of N, though. However. If you are happy the solution then I am happy that both DER encoding and ECDSA malleability are already addressed and not usable as a "malleability fix" argument for SegWit. > LN will be the only side-chain
LN is not a sidechain. The fact that you say this suggests you know very basically exactly zero about LN. You might want to educate yourself before offering an opinion on it.
I beg to differ. It would be a side-chain if the changes weren't being implemented. I do indeed know nothing about LN. I don't care how it uses SegWit in a similar way that I don't care how coloured coins use Bitcoin- I am only interested in bitcoin and its SegWit solution. The driver for SegWit seems to be purely LN so that is political rather than technical driver and that worries me. Are you going to go as far as saying LN is Bitcoin 2.0? > The point is that malleability is an edge case symptom that can be solved without adding a lot more complexity
This is wrong on two counts: 1, no it cannot be solved in a different way without adding a lot more complexity, and 2, segwit, at least in general terms, is the architecturally correct and simple solution to the problem. See the bip62 doc that you were already linked to for details on the first point.
1. I disagree. I have already outlined (albeit vaguely) several solutions. You want a txID not fixed to a signature. This isn't rocket science. 2. It is the architecturally correct solution for outsourcing the txID generation-that's it. If you are going to do that, then make it a plugin module then it doesn't need to be in Bitcoin at all and anyone can use their own, including legacy (maybe a default module). It is a poor solution just for malleability and a straight-jacket for txID generation. Bitcoin's existing design for this is just wrong (or at the very least, not the best one): the signatures authorizing the transaction are included inside the final txid hash, which is being used as a transaction identifier; but it doesn't identify the transaction. The authorising portion (signatures) should be outside the hashed data/transaction as they are not part of the semantic content of the transaction, they are only an authorisation of that semantic content.
I agree entirely. We only disagree that SegWit is the optimal solution. This has been done in Bitcoin,
Not just done in Bitcoin, but we came up with that improvement; and ripple borrowed it long after-- including the code for it. I put him on ignore after that post: There is nothing worse to deal with in this subforum than a chest-thumping altcoin promoter bragging about an altcoin being superior on the basis of code or techniques they coped from Bitcoin Core. Ad hominem response that adds nothing and addresses nothing. I expect better. |
|
|
|
Segwit started as an element in elements alpha. It allows for safe chaining of pre-signed transactions, which is important for payment channels and lightning network. The version in elements just changed how we defined txids, which we can't do in bitcoin. It's hard to imagine doing hard-forks in bitcoin just for this. Non-security hard-forks are going to be very hard to get consensus on.
As deployed, there's this key insight that you deploy a type of extension block and you can enforce inside of this extension some new rules. Some things that look like hard-forks turn into soft-forks. So we can sneak in confidential transactions as a soft-fork. So you have the base block and then you commit to something, and in this other block you reveal the real data that shows you own this bitcoin. As a highly desired extension, it kind of fits this model. Source. (My emphasis)I knew there was more to this than a "malleability fix". It's one of the largest changes to bitcoin ever. It has touched nearly all areas of the bitcoin code base, like p2p, wallet, consensus, every layer. OK. So the whole codebase has been modified to account for this one side-chain, the reason being that if affords confidentiality for LN and to no-one else. For this reason alone it is cancer. Now. It is certainly desirable to fix malleability and even allow side-chains to use the BC for their own back end systems. The proper way would be to allow others to plug-in a module at run-time so that anyone could create their own plugin module and distribute it with their wallet software. Hell. You could even support an unlimited number of "variants" from Bitcoin Core. LN could then have created a specific plugin for their wallets. As it happens, I've wanted the reference software to go down the plugin path for quite some time (the address creation, hash used, the mining method etc) but it is clear that is just a pipe-dream. It seems to me that should this go live, then LN will be the only side-chain worth using with guarantees of confidentiality and everyone else has to wash all their clothes in public. Is this the case? |
|
|
|
This isn't the only source of malleability. The abandoned BIP62 lists ways in which a Bitcoin transaction is malleable: - Non-DER encoded ECDSA signatures
- Non-push operations in scriptSig
- Push operations in scriptSig of non-standard size type
- Zero-padded number pushes
- Inherent ECDSA signature malleability
- Superfluous scriptSig operations
- Inputs ignored by scripts
- Sighash flags based masking
Of course. I have already said it was an "umbrella term" to which amacilin picked one and I specifically gave him a solution to that. I also mentioned hashing the final stack which would fix: - Superfluous scriptSig operations
- Inputs ignored by scripts
- Sighash flags based masking
- Non-push operations in scriptSig
The DER encoding is a consensus issue since OpenSSL accepts BER and DER (DER being a subset of BER). Pre-checking before passing to OpenSSL is trivial. The point is that malleability is an edge case symptom that can be solved without adding a lot more complexity. There is a lot more to this SegWit proposal than we are being told. |
|
|
|
Of course. "Malleability" is an umbrella term First of all, ecdsa malleablity is the abliity to change the signature itself for the same data without invalidating it by the person who knows the secret or by the "middle-man" Sure, because distinguishing between σ = (r,s) and σ'= (r,N − s) is just too hard for bitcoin, eh?  Ripple uses (r,s) < (r,N − s)? (r,s):(r,N − s) |
|
|
|
This seems far from "impossible". MD5 is not malleable, but ECDSA is. MD5 is hash-function, but ECDSA is signing You need to re-read the post. Of course. "Malleability" is an umbrella term for multiple issues that affect corner cases. For example. The script is hashed then signed causing a different hash if the instructions are changed but, never the less, yield the same result. The solution to this aspect, I believe, is to hash the final stack instead of the current method. |
|
|
|
That message cannot include the signature itself because the signature does not exist yet. Including the signature changes the message, thus changing the signature. Thus it is impossible for a signature to sign itself as doing so will inherently change the signature.
OK. Lets consider a trivial example/case..... Let our message be a terse one of: Where "Text" is expected to be an ASCII string and "Sig" is expected to be an MD5 hash of the message represented in hex. 1: We create a message {Sig: 00000000000000000000000000000000,Text:"A text Message"}2. We now find the MD5 of the entire message which gives us C9D4C59A1FEBA4D1BFE1ECE1EE7269B0. (I've included the brackets and quotes just because of copy and paste) 3. We insert the code back into the message and send - yielding {Sig: C9D4C59A1FEBA4D1BFE1ECE1EE7269B0,Text:"A text Message"}To check the sig we simply replace the sig field with zeros as before, calculate the MD5, and check against the original value in the sig field. This seems far from "impossible". |
|
|
|
I keep seeing the main justification for SegWit being that it solved the sighash problem, where it ends with a hand-wave of "The signature script contains the secp256k1 signature, which can’t sign itself"
Can someone explain to me why it can't sign itself? (preferably with an example)
Once the signature is created, if you were to include it in the message and sign it again, you would have a different signature. Having the signature in the message always changes the resulting signature so it can never sign itself. Exactly. So one can create a signed hash if the definition is as you describe - a two step process. This argument is also used for "scriptSig" - "While signing the whole scriptSig would be impossible - the signature would be signing itself" . Other signing protocols do exactly this by signing messages with a "placeholder" field and then inserting the hash afterwards. |
|
|
|
|
I keep seeing the main justification for SegWit being that it solved the sighash problem, where it ends with a hand-wave of "The signature script contains the secp256k1 signature, which can’t sign itself"
Can someone explain to me why it can't sign itself? (preferably with an example)
|
|
|
|
mysql is slow in terms of read performance
Why not use leveldb as used by core. It has very good read speeds. Also you don't require concurrent writes. Only need to write a block that comes in every 10 minutes. Most of the times are reads. I doubt any other RDBMS can match the performance of leveldb
Because LevelDB is not ACID compliant and prone (read, renowned for) corrupting the DB. This is why we are being told to back up the chain, make copies etc. Bitcoin should be using an ACID compliant DB and the only one that gets close to the performance of a Key/Value DB for sequential access is SQLite. Plus, one has other niceties like live backup and in memory attached DBs. |
|
|
|
SegWit and LN are the best proposals so far that I have heard that can help towards achieving these goals.
Any side-chain can do that and it wouldn't need to modify the bitcoin protocol. So. As a maleability "fix" it's a bit of a sledgehammer to crack a nut with a rather large cost in data storage and distribution. The question is then; why is the tail wagging the dog? |
|
|
|
People who are concerned about "blockchain bloat" really don't understand the technical details of bitcoin. They try to run Bitcoin Core without pruning and then complain that they've run out of disk space. They complain that it won't be possible for enough people to run a "FULL" node.
The fact that pruning exists at all is an admission that block chain size matters. We do indeed complain that it is not possible to run a full node on average systems. Pruning doesn't solve the problem, it just kicks it down the road. Note that they are at least partly correct. As I mentioned, you'll always need some nodes to store the entire history.
You need the network to store the entire history - preferably with redundancy. It is not necessary for all nodes to keep all blocks. The current system is the trivial solution, not the only solution.
The bigger issue with larger block sizes isn't the size of the blockchain, it's the size of the individual blocks themselves. Before a miner can reliably build a new block on top of a recently solved block in the chain, they need to verify that the recently solved block is valid. This means they have to take the time to download the entire block, and verify the block header and every transaction in the block.
Oh. Boo hoo. Those poor miners starving on the streets might have to do a little more work to maximise their profits. The difficulty will adjust to any more work required or they will just throw more hardware at it. This is a non-argument since they are just doing what miners do. Maybe more importantly, the miners will have to switch from maximising coin collection to maximising fees at some point anyway. This is a bait and switch from full nodes to miners (not the same thing at all) in an attempt to bolster the argument.
Those miners or pools with slower internet connections or slower processors will be at a significant disadvantage over those with extremely high speed connections and high end processors. This disadvantage could result in the higher end miners and pools getting a head start on the next block and solving more blocks than the disadvantaged miners and pools. Eventually the loss of revenue could result in mining power consolidating in just the few miners or pools with access to the fastest possible internet connections and newest processors.
Oh You mean those not in data-centers? This is the argument against centralisation for the current mining regime regardless of distribution mechanisms.
It also may become very difficult for those on very slow connections to download and verify a single block before the next block is solved. As such, even lightweight wallets and pruning nodes would continuously fall farther and farther behind on synchronization and never be able to catch up.
Complete speculation. Even an Arduino could process a block in less than 10 minutes.
The unanswered question is how big is too big when it comes to blocks? Right now we are operating with 1 MB. Is 2 MB too big? How about 10 MB? 100 MB? 1 GB? 1 TB? Who gets to choose, and how do we get EVERYONE to agree on that choice?
No maximum limit. The trade-off between amount of fees (bigger blocks, more fees collected) and the competition to be first on the block chain (hashing efficiency and transmission) will yield an optimum block size depending on the miners' capabilities - no fixed block size! Of course. This destroys the fake scarcity introduced by the economists since all transactions can be catered for. |
|
|
|
|
I propose a minimum block size of 1MB with an unbounded maximum.
|
|
|
|
I believe it's time to speak honestly about Segwit, which I do not support, for different reasons. No troll. Flame away. Kano is a legit developer of mining software who has also raised valid concerns about the code.
Kano raised invalid concerns, just like the rest of your concerns, not valid. It seems like a huge number of people are saying: " I don't understand the point of fixing signature malleability, or why quadratic sighash scaling is an issue, so, why?" This is incredibly arrogant, and ignorant. And I don't normally listen to anything that people say who are too arrogant to fix their own ignorance. Do you? This post is the epitome of arrogance and the irony is spectacular. Maybe achow101 should take you aside and teach you how to play nice with us remedial kids. Kano raised concerns. You can allay or confirm those concerns or just not answer. I would prefer the former but would be just as happy with the latter. |
|
|
|
That certainly is a surprise to me (thanks for the link and I deleted my own post to avoid any further confusion). Thinking about it more I guess it makes sense that in order to do a "rollback" it would need to be able to restore deleted data (as the size of a transaction could be huge it has to write all the recovery information and keep that at least until the commit has been completed and all final tx data has been flushed to disk).
But can you force rollbacks to occur after a successful commit (and especially after a checkpoint)?
Certainly I'm not familiar with any standard SQL commands for doing such a thing (and I wouldn't count nested transactions if supported as really being a solution) so I still don't see how you could use a traditional RDMBS to achieve a blockchain "re-org" (which is the main point that I was perhaps poorly trying to make).
Assuming that most RDBMS engines do work the same way regarding logging then perhaps it would at least be potentially possible to add some method of tagging the DB state at a certain "block height" and therefore later be able to "rewind" the DB back to the state it was at that specified tag (although I don't think that there is any such standard method).
Rollback is a bit of a red herring for an immutable block chain. Just store everything, good or bad, and adjust the query. SQLite also has the ability to treat multiple, separate database files as a single database at run-time (max 64). One could create separate DB files for working DB and historical but I don't even see the need for that. BTW. SQLite can insert 1,000,000 records in under 10 secs and wipes the floor with My/MSSQL and Postgres in terms of performance. What it doesn't have is authentication so the others are a better choice for web servers. |
|
|
|
If, instead of a counter, the hash was calculated on a varying number of transactions (1 then 2 then 3 and so on) then this is not the case. Scaling up the hash alone yields the same hash if the transaction list is constant and in order to calculate the hash for each (1,2,3...) transaction lists would require a huge amount of resources which the ASIC is unlikely to have. This method would be ASIC resistant.
Thinking a little more about this. It would actually solve the block size issue. So. Instead of an incrementing counter being used to generate a new hash of the transactions on each round. The counter is removed and the order or number of transactions is changed. Although a minimum block size of 1MB could be retained for spam protection, miners would be free to use an unlimited block size. In reality there would be an optimum based on the technology used, the fees and the method (reorg/add). It could also be argued, that miners are incentivised to use larger than 1MB blocks to gain more fees (higher tx throughput) and the spam could become valuable, in the absence of larger paying transactions, to generate their hashes. The minimum 1MB block could no longer be required except for a guaranteed minimum throughput. Miners could become ravenous for any transaction including those that are zero fee. Of course. This would require a hard-fork and obviate all current ASIC miners  |
|
|
|
i386sx is not Application Specific Integrated Circuit compared with Intel Core i5
But Intel Core i5 is Application Specific Integrated Circuit compared to i386sx
If it can be programmed then it is not "Application Specific". It is not a relative term at all. FPGAs blur the boundary slightly but are still not considered ASICs. FPGAs are often used to prototype ASIC designs. |
|
|
|
So the nuisance of syncing the whole chain, which only increases in time, is the incentive not to turn it off?
Interesting, because I think that is one of the reasons why average users just use SPVs instead.
So what's the incentive for others, that currently don't run it, to turn it on in the first place?
One wouldn't have to synch the whole chain. Only back to the old checkpoint (which is already verified back to the genesis block from the initial start). The incentive is that the on-disk size is less than 1GB regardless of total chain size. |
|
|
|
|
Show Posts
