Currently no, but maybe I'll do something for keybase, but I don't have an invite (I've been on the queue for a while now)
I have an invite I can give. PM me your email if you want it. |
|
|
|
From the point of view of old clients, segwit adds one coinbase output that contains the root hash of the Merkle tree that commits to the witness transaction ids. It uses 47 extra bytes per block, so technically, yes, it "wastes precious blockchain space". The blockchain on-disk can be pruned though (implemented as an experimental feature in Bitcoin Core 0.11, and with nearly full functionality in 0.12), so calling it "permanently" is not very accurate. If you're talking about storage space used by segwit-compatible full nodes, well, obviously it will use more space, because it increases block capacity - that capacity has to go somewhere. However: - The extra space used by witnesses is more prunable than normal block space, as it's not needed by non-validating clients.
- Has less effect on bandwidth, as light clients don't need the witness data.
- Has no effect on the UTXO set, so does not contribute to database growth and/or churn.
- Enables script versions, which will make the introduction of Schnorr signatures much easier later on, which are more space efficient than what we have now (even for simple single-key outputs/inputs).
How are the witnesses serialized and sent with blocks? Also, is there (or will there be) a full technical write up of the changes of segwit so that wallet developers can change write changes accordingly? Preferably before the ogival release of segwit? |
|
|
|
No. That is with the git, a VCS not specific to bitcoin. We are taking about segwit here which is a bitcoin consensus specific thing. |
|
|
|
|
So, I'm on mobile right now so I can't give as detailed of a response. I will edit this with my full response later in half a day when I get back to my computer to give you a full response. This is just the gist of what I want to day.
I'm not sure about the space reducing part. Was that actually mentioned anywhere? I don't think I said that it would reduce the space used. It is essentially a 2Mb block size limit increase but with the added benefit of making transaction malleability impossible.
About the txid thing, you are incorrect. Reread all the BIPs carefully and multiple times. It can take a couple reads to fully comprehend and understand what is happening. Also keep in mind that there will probably be changes when segwit is actually released. The changes will only be omissions of what was specified e.g.I don't think they will include the new address type.
With the addresses, the witness program is nested in a p2sh address so it will be 3xxxxx. These should all be able to be spent to under the current system. You as the sender don't need to know the whether the address is segwit or not, but the receiver will need to in order to properly spend from it.
|
|
|
|
OK, so you agree that if segwit achieves the activation level, all nodes will have to update and download the 2MB of data, which contains 300kb+ of wtxids that otherwise wouldnt be needed in a straight 2MB hardfork.
I don't know, so I can't agree or disagree. I couldn't find anything about how that would be serialized. I do agree that upgraded nodes would have to download all of the witness data though, whether they include the wtxids, I cannot say. so it is a total fail from a "increasing tx capacity without requiring a hardfork" point of view. Let us not quibble if it technically is a softfork or hardfork, the reality is users will have to update or not be able to spend. it looks like a hardfork, walks like a hardfork, quacks like a hardfork.
I still say that it is a soft fork, albeit not entirely a soft fork but not a hard fork either. Let's agree to disagree. It sounds like it is possible to make it less of a problem, but it will be possible for segwit to be used to make unspendable payments to old nodes, so this creates an attack vector where the attacker simply sends to thousands of users some small amount of unspendable segwit wtxids. Once users get the bitcoins, they wont care about whether it is softfork or whatever, they will want to spend the bitcoins.
No, that is not possible. An old node would not know about the new witness program and how that works in an p2sh output. It would only know of p2pkh outputs that are meant for it, even if the witness program is just a p2pkh but segwit spendable only. The old node wouldn't know that it received such a payment so this attack wouldn't work. So, in the case where segwit is adopted, then all the nodes must update and get the full 2MB blocks that are bloated with needless wtxids. Now I just briefly looked at segwit details for the first time today, so maybe there is some super magic negative knowlege antimatter spacetime warping data compression that allows the segwit to actually save blockchain space. but calling the witness data not the blockchain since it is separate, again it becomes the type of stuff politicians do and not what technical guys should be doing. So if you are a politico, then fine, but I had always seen your posts as from an objective technical guy and was totally shocked at what you wrote. I am assuming the witness data is treated the same as the normal blockchain data, so it is in the same category and thus the statement that segwit is a total fail for increasing tx capacity without hardfork is fully justifed
Now that I think about it, I don't think the wtxids are included and that the witness data is included in a separate structure. If the witness data is requested, then I think (don't quote me on this) that it is just appended to its respective transaction in the block when it is sent. The wtxids are probably generated on the fly just like regular txids are generated on the fly as well. So in fact, it would be a 2 Mb increase but the "official" size of the block cuts out all of that witness data. If the block were to be requested normally as it is now, the witness data would not be included and the size of the block would be at most 1 Mb. Since segwit was started to fix malleability, maybe it should stick to that and not try to solve a problem it cannot solve. Officially claiming that it solves this is damaging to bitcoin's technical credibility and the other coins will take FULL advantage of this.
I do agree that it should not have been marketed as a scalability solution but rather that it is for transaction malleability with a side effect of some scalability. |
|
|
|
Are you trying to claim that having the entire existing installed base not being able to validate the wtxids they get is acceptable? And that not being able to spend it, is acceptable? The customer support issues it is guaranteed to cost, is acceptable? That the lost reputation for backward compatibility and reliability, is acceptable?
fixing malleability, great!
But to be able to spend the wtxids dont you need to get the extra witness data? Is that data part of the segwit blockchain? If it is part of the segwit blockchain, isnt there the wtxid for each txid that wouldnt otherwise be needed?
What am I missing?
Segwit defines a new address type, but I don't think that will actually be implemented. Rather it will be using the witness program in p2sh addresses instead. A non-upgraded node will not have such addresses, they will still be using p2pkh addresses like we do now. If a segwit transaction were to be made which spent from a segwit output to an old p2pkh output, an old node would still be able to spend from it. The transaction would validate because the node sees it as an anyonecanspend input and the output is just like any p2pkh output in use right now. There is no need for the witness data to spend, it just cannot know whether the transaction it spends from was legitimate or not. Then it can still spend the p2pkh output normally as it does now. To spend any received wtxid, you need to update to segwit chain, which is increased in size and includes the wtxid's for EVERY segwit tx, not just the merkle root. And this wtxid wouldnt be needed if we just hardforked to 2MB. So segwit as a space saver, actually loses space. Segwit as a softfork might be technically true, but it forces everyone to update to a sole sourced wallet or not be able to spend the coins received. And when they update, the wtxids are sitting there in their blockchain that wouldnt have been needed otherwise.
Well they aren't actually in the blockchain as we know it. It would essentially be like a secondary blockchain of all of the witness data. Either way, yes upgraded nodes would have to download 2 Mb of data. So, for fixing malleability and other things, great. no problems with that. but to claim it is increasing tx capacity without a hardfork is disingenuous at best. Most people would like to be able to spend the bitcoins they get. If you can agree with that, then you must agree that they will need to load the segwit blockchain, which is bloated with wtxids that would not be needed in a simple 2MB hardfork
I know you must have some sort of marching orders to follow the party line, but please, let us not make silly claims like "wallets still function perfectly fine with the old system. They can still receive segwit transactions, they just can't spend from them" I dont want you to lose your credibility
Sorry, I actually spoke incorrectly there. I forgot about the whole address thing. |
|
|
|
considering the obstacles it faces, I will not implement segwit support into initial iguana versions. If a bunch of users end up with unspendable funds, then I guess I will be forced to massively complicate the blockchain handling.
does anybody know the BIP that defines the new network message(s)? I assume each block would need a getsegwitdata equivalent so existing nodes just do the existing getdata and the segwit softforks (ha ha) do the additional call, process the new data format, update the internal dataset, validate the signatures and enable spending. Seems like a LOT of work to get a 60% increased capacity.
I would advise that you actually read all of the BIPs. The one you are looking for is BIP 143: https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki. Since this is basically a hardfork (let us not kid ourselves that creating INCOMPATIBLE bitcoins is in any way backward compatible!!), and it requires the additional data, then just hardfork 2MB.
That would not require wtxid wasting precious space in the blockchain.
How does the wtxid waste space? The only place it ends up in the blockchain is in the coinbase transaction as the witness root hash where the wtxids are hashed together. The logic used to justify wtxid permanently using up space that otherwise wouldnt be needed is that it allows a softfork. But this is a fake softfork, as existing nodes wont be able to validate or spend any segwit payments it gets. HOW ON EARTH IS THAT BACKWARD COMPATIBLE?? which is the industry's understanding of softfork behavior (I know technically that is not what softfork is, I speak of what users are thinking)
It is a soft fork because after the upgrade old nodes and wallets still function perfectly fine with the old system. They can still receive segwit transactions, they just can't spend from them. They can still receive and spend from traditional transactions which will still be valid under the new rules So, if segwit gets 75%, then it forces all the nodes to update. How is that not a hardfork?
No. It simply means that the new rules can go into effect and are now considered valid. No one is being forced to upgrade and you can still function fine without upgrading for a while. The logic is segwit allows 60% increase in capacity without a hardfork, but this premise is wrong. It is effectively a hardfork, actually I think it is worse. If it was a hardfork, then users who know about such things will understand that they have to update. Saying it is a softfork will make users think they dont have to upgrade. Then they find out that they cant spend the bitcoins they got. So we end up with two incompatible bitcoins. this is not a good plan at all
No. It will not fork the blockchain. All of the blocks produced after the fork are still valid under the old rules. This is part of what makes it a soft fork. It doesn't fork the blockchain like a hard fork does. Let us call a hardfork a hardfork. segwit is a hardfork from the most important aspect that is it NOT BACKWARD COMPATIBLE with existing wallets and independent cores.
OK, so that then means that segwit is WASTING precious blockchain space and not avoid a hardfork. It makes no sense to me that a defacto hardfork that breaks ALL EXISTING wallets and also requires all independent cores to make significant changes, testing, field updates, customer support, and it is all to permanently waste space with the redundant wtxids that would not be needed if we just hardforked 2MB
Please tell me there is some sanity here. There is no logical justification for segwit and plenty of risk factors of creating the impression that bitcoin is broken, and if you dont consider the existing installed base not being able to validate or spend bitcoins as not broken, then something about how you evaluate brokenness is broken.
Segwit is needed for its solution to the transaction malleability problem. It makes transaction malleability impossible to occur now since the txids now contain only data that is already signed. If everyone were to upgrade to segwit, it would indeed be a very good thing for Bitcoin. It also solves the O(n^2) hashing problem. Additionally, you can still use Bitcoin as it is now after the fork. A lot of people seem to forget that. Lastly, I will say that marketing segwit as a scalability solution was probably a bad idea. Its original intent was to solve the transaction malleability problem and a side effect was that the block space was effectively doubled. People use the 60% - 80% figure because the assumption is that people won't upgrade to segwit and make use of its advantages. Otherwise it would be the same as a block size doubling. |
|
|
|
it's not very advanced so what would you like to use it for? all ideas welcome i''ll try to implement some ideas
i plan to run it and monitor bitco.in forum because the classic guys are there
I think it would be a good idea to run it here on some users here who shill for a certain scaling solution (e.g. classic, core, xt; analyze all of them!). Also it could be useful for determining the shills of scam sites in the marketplace. |
|
|
|
Hm, that is strange. Can you provide the debug.log? Do you think you can reproduce this error (on testnet or regtest because it is easier to find blocks there)? |
|
|
|
|
Is this open source?
I think it would be a great idea to run such a program on the posts of some users on this forum.
|
|
|
|
it was a bug actually. in relation to the way the database was programmed.
I'm not sure about that, but since I don't feel like digging through historical code, I'll let this drop. the "empty blocks" are not standard 10 minute average blocks, nor is it the intention to leave them empty. but luck gets in the way... let me explain..
I understand how empty blocks work and how spv mining works. I advise that you take a look through this thread: https://bitcointalk.org/index.php?topic=1085800.0 and this one: https://bitcointalk.org/index.php?topic=1389977.0 more recently. the only thing that stops then starting to fill the new block with appropriate data... is that occassionally in that 1-2 minute period of validating the previous block.. they luckily get a new solutionfor the current block(currently empty)
go check it out. look at the empty block and look at the time since the previous block. it wont be 8-12 minutes it will be 0-2 minutes..
I have seen several blocks that are empty that are found on the normal ten minute interval. There have also been several blocks that were not empty that were found within the first two minutes. lol so adam back puts in some code. and sipa allows it.. thats basically explaining rigged elections.
its kind of funny how you say blockstream has no control. yet blockstream have pushed away bitcoinJ, pushed away alot of other implementations and want everyone to follow the blockstream roadmap..
also to point out
you think that the $55million only goes to Sipa
And then the other core committers (and a lot of other people who follow Core development, me included) see that sipa committed some code that goes against what the Bitcoin Core plan for scaling is or it bypassed the standard procedures for committing a change. Then sipa loses his commit privilege and that commit is reverted. ok now your counteracting yourself by saying that bitcoin-core devs are paid by blockstream, you also using plurals which means deep down you know there is more then one blockstreamer in bitcoin-core..
Not the one's with commit access. Yes, there are developers who work on Bitcoin Core and contribute heavily to it that also work at blockstream. Those people are also the ones who founded the company. Their changes must go through the peer review process and and then must be committed by one of the other committers, which is usually Wladimir (mostly him) or Jonas Schnelli (for wallet and gui stuff sometimes) who does it and those two aren't paid by Blockstream (nor are the other committers, Cory Fields, Luke-Jr, Gavin Andresen, or Jeff Garzik). If one of the blockstream developers created a PR which hurt Bitcoin and only benefited blockstream and that somehow got committed (it was NACK'd or was not ACK'd or was not reviewed by others), then obviously something is up and with the nature of git, we know exactly who did what and can act accordingly. Fun fact, Gavin Andresen and Jeff Garzik have commit access yet they support Bitcoin Classic. Also, the debate among the technical developer community is much much less toxic, more reasonable, and the consequences (both positive and negative) of the solutions are understood by the developers. |
|
|
|
a historic scenario that shows there was no big doomsday then so there are no doomsdays now:
in 2013 miners finally got passed a bug that allowed them to start making blocks bigger than 500k. and guess what. they instantly didnt make 0.99mb blocks continuously that very same day.
it took 2 years to grow that large. slowly and naturally without asking anyone for expanding restraints. there was no power struggle acting out an oliver twist scene ("please sir can i have some more")
It wasn't a bug. Rather there was a soft limit that many mining clients had from the beginning. Originally it was 250 Kb, then it was bumped to 500 Kb, then to 750 Kb, and then removed entirely. I believe this was an antispam measure that did not require forks to raise. It was just a choice of the miners to use that limit, it wasn't consensus enforced. current situation:
we are starting to bottleneck again and its time to expand. remember increasing the capacity is about POTENTIAL growth. not a doomsday about instant doubling of bloat. let call this a "buffer" because people cant seem to grasp that capacity is about what is capable within a cap, (potential) .. rather than the bloat doomsday of what will happen when the code is activated.
Although we may be seeing a little bottleneck today, it isn't as severe as some people make it seem (except when there are spam attacks happening) and there is in fact a fairly simple solution that solves that right now: get the pools who mine empty blocks (blocks that contain no transactions except the coinbase), especially antpool in particular, to stop mining empty blocks. Or at least leave those pools for ones that do not mine empty blocks. There was an analysis done during the last spam attack that found that if just antpool had mined blocks with 1500 transactions instead of empty blocks, the entirety of the backlog would have been cleared. It is simple really. Blockstream built a thing we don't need. They want to charge you money to use this thing. But you don't need it. So, they want to cripple the blockchain - so that you do need it. They got the core developers on salary. Those guys won't listen to reason, they listen to their boss, who pays their salary.
Get it?
The bottom line is clear: the core developers have a clear conflict of interest and they severely damaged the decision process. As such, they should no longer be allowed to be custodians of the code. They should be replaced.
This is the kind of FUD that is trying to be avoided. Blockstream does not control Bitcoin Core development. Of the people who have commit access to Bitcoin Core, only one of them works at blockstream, sipa (Pieter Wuille). 1 out of 7 people who can push commits to the project works at Blockstream, I wouldn't call that control, especially since the others with commit access can revoke sipa's if they find that he does something that hurts the project. Now many of the people who work on Bitcoin Core do work at blockstream but they can only create pull requests so their changes can only be merged if one of the 7 committers commit it. This is certainly not control of the project; they can't get their changes through unless someone else commits it for them, and those others do not work at blockstream. Another thing you need to remember is that Bitcoin Core came before blockstream was founded. Developing Bitcoin Core doesn't pay the bills, it doesn't put food on the table. The people who founded blockstream are those who worked on Bitcoin Core and needed income so that they could still be alive. The people who founded blockstream are some of Bitcoin Core's primary code writers, and they don't have a boss since they are the founders. They are the bosses, so there is no one higher up saying that they must do something to Bitcoin Core. |
|
|
|
|
Have you tried running Bitcoin Core with the -salvagewallet option to see if it can recover the corrupted some keys so that you can spend from them? If you try that, make sure you keep a backup of your wallet.dat file somewhere as I think it will destroy the corrupted wallet once it attempts a salvage.
|
|
|
|
|
SITE BACK UP. SHOULD WORK NOW. ALL PREVIOUS TOKENS ARE NOW INVALID.
|
|
|
|
Mine says "Please wait. You are number 25 in the queue". I waited for about 10 minutes and seem like its not moving. why does it have to put us on queue?
It looks like there is a bug in my code that is crashing the main calculation thread. I will take the server down for a few hours while I figure this out. SERVER GOING DOWN FOR MAINTENANCE |
|
|
|
I think I did not explained myself properly.
I'm thinking about different blockchain implementations.
Imagine that I'm creating a private specialized network that will process complex contracts.
Would there be any way that I could store contratcs outside the blockchain and just reference them in the transactions?
Of course. You can do anything with your own blockchain but such a thing doesn't exist in the bitcoin blockchain. |
|
|
|
About item 4, it still looks suboptimal to me. Imagine that I have a firm where in order to spend the payment from customers I also have to get the signatures from at least 1 of 2 other partners. My script would look like: 2 <My PubKey> <Partner 1's PubKey> <Partner 2's PubKey> 3 OP_CHECKMULTISIG So, for every incoming payments that I'd like to spend, my scriptSig would have to be bloated with the script above plus 2 signatures <sig1> <sig2>. Imagine that I'll have thousands of these transactions, this would be bloating the blockchain, probably decreasing the processing capabilities of the network. I was wondering: is there any way of mantaining these scripts as "accounts" in "script wallets" and not storing it inside the blockchain? When there is need for validation, I could simply retrieve this script form the "wallet" and check the transaction. How would it be possible? It's all the same, both will still end up in the blockchain one way or another. The difference is that with bare multisig, nodes will have to maintain that extra data in a UTXO database instead of not at all in a database when it is in the blockchain. |
|
|
|
when you say "receive" but not spend, it is received and unverifiable and unspendable, right?
In essence, yes. is it just me, or does it seem like calling this a softfork might be technically accurate, the market confusion and incompatibility it will cause is pretty much like a hardfork
Yeah, pretty much. Although it still allows for the old type transactions so old wallets will still work. IIRC segwit was originally proposed as a hard fork. |
|
|
|
wow, that's a LOT of changes... practically speaking, will segwit tx work for sending to an old wallet or do both sides need to run it for it to be spendable. it seems that would be the case. if so, doesnt that create a lot of problems along the lines of "i sent you this txid, but you need this wtxid to be able to spend it, oh and the new updated wallet that supports segwit that isnt available yet from your vendor" The txid of a segwit transaction will be the same segwit or not since the signatures are not part of the transaction. Unupgraded users will be able to receive but not spend from validate segwit transactions fully. They can spend from segwit transactions because the output will still have to be a p2pkh output to non-upgraded wallets. Edit: Fix error where I said that segwit txs could not be spent from. |
|
|
|
|
Show Posts
