Search content
Sort by
Showing 20 of 1,194 results by da2ce7
Re: Public Verification of P2WSH Threshold Multi-Signature Addresses
Thankyou, I have updated the GitHub issue with you sugestion 
I agree with @ranochigo idea, it's most practical idea to prove that all 6 keys are accessible. Additionally, mentioning which key will be used and other detail (such as receiving address with it's amount) on both transaction makes it more convincing.
P.S. I would recommend sign message 2 times with different set of keys, but i don't remember if there are any wallet which support such feature.
Would it be possible for you to just create 2 transactions, with one of the parties signing both TXes and the other parties being unique.
I agree with @ranochigo idea, it's most practical idea to prove that all 6 keys are accessible. Additionally, mentioning which key will be used and other detail (such as receiving address with it's amount) on both transaction makes it more convincing.
P.S. I would recommend sign message 2 times with different set of keys, but i don't remember if there are any wallet which support such feature.
Public Verification of P2WSH Threshold Multi-Signature Addresses
Hello BitcoinTalk,
I have been asked to help the Grin community verify their Bitcoin P2WSH Threshold Multi-Signuture Address.
They have a 4 out-of 6 address, however need to prove to the community that they have access to all six keys.
https://github.com/grincc/security/issues/1
The proposed solution was to create a transaction that 'oversigns' with 6 keys, included and include that transaction on the blockchain.
They created a test transaction:
https://blockstream.info/tx/cfbc3792e42a6832825f5b4f9dcb264d7a84662f0365661a05c1db591546bac3?expand
In the process they had all six keys sign the transaction. However when viewed on the blockchain it seems that only four of the six signatures are present.
Maybe this is a bug in electurm? It truncates the unseeded signatures, maybe to save on blockchain space? However this is exacly not what we want in this case.
Overall it would be great to get some feedback on how to properly verify and collate the keys and signatures of multi-signature transactions. Some sort of nice GUI that displays the information clearly would be of great help.
I have been asked to help the Grin community verify their Bitcoin P2WSH Threshold Multi-Signuture Address.
They have a 4 out-of 6 address, however need to prove to the community that they have access to all six keys.
https://github.com/grincc/security/issues/1
The proposed solution was to create a transaction that 'oversigns' with 6 keys, included and include that transaction on the blockchain.
They created a test transaction:
https://blockstream.info/tx/cfbc3792e42a6832825f5b4f9dcb264d7a84662f0365661a05c1db591546bac3?expand
In the process they had all six keys sign the transaction. However when viewed on the blockchain it seems that only four of the six signatures are present.
Maybe this is a bug in electurm? It truncates the unseeded signatures, maybe to save on blockchain space? However this is exacly not what we want in this case.
Overall it would be great to get some feedback on how to properly verify and collate the keys and signatures of multi-signature transactions. Some sort of nice GUI that displays the information clearly would be of great help.
I have made a BIP Proposal, To help protect against transaction replay attacks. Would love to gather some comments.
Code:
BIP: ???
Layer: Consensus (soft fork)
Title: Strong Anti-Replay via Coinbase Transactions
Author: Cameron Garnham
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???
Status: Draft
Type: Standards Track
Created: 2017-03-25
License: BSD-3-Clause
CC0-1.0
==Abstract==
This document specifies a soft fork that enables users to make transactions with a strong expectation that such transactions cannot be replayed on a different chain.
Important Note: In the case that an adversary hard-fork, the strong guarantee of non-replayabilty via this BIP may not be supported.
==Definitions==
==Motivation==
In the case of a chain split, it is important to protect users from, potentially significant, loss of funds from transaction replay attacks.
==Specification==
Upon activation of the soft-fork (activation methodology undefined in this proposal), the following new rules become activated on the Bitcoin Network.
New anti-replay OpCode. Take an unused NoOp and redefine it as OP_ANTI_REPLAY.
The script must only have the form:
scriptPubKey: (empty)
scriptSig: OP_ANTI_REPLAY
OP_ANTI_REPLAY has the following specification:
OP_ANTI_REPLAY outputs must only be created in a coinbase transaction.
OP_ANTI_REPLAY coinbase outputs must only have the value of 1 Satoshi.
Transaction must not included more than 1 OP_ANTI_REPLAY input.
If a OP_ANTI_REPLAY input is included in a transaction, the transaction must also be marked as Opt-In-RBF (BIP 125).
The Bitcoin Network should maintain a total of exactly 100 000 OP_ANTI_REPLAY outputs, with the exception of the the first 99 blocks after activation of this soft fork.
Upon activation of this soft fork. Every blocks coinbase transaction will be required to create exactly 1000 new OP_ANTI_REPLAY outputs, up to the total of 100 000.
If a OP_ANTI_REPLAY is spent in a block, a corresponding new OP_ANTI_REPLAY must be included in the same block.
It is recommend the miners account the size of a OP_ANTI_REPLAY transaction as: transactions size + size of a OP_ANTI_REPLAY output in coinbase.
In the case of an chain split after this BIP has activated, miners should recycle all the OP_ANTI_REPLAY outputs via spending and recreating them in new blocks. Renewing the protection to the new chain.
=== Reference implementation ===
To-Be-Implemented
==Backwards Compatibility==
This deployment is compatible with all existing bitcoin software.
Upon activation, all deployed Bitcoin Full Nodes will enforce the anti-replay projections for Bitcoin Users. (Only upgraded nodes will enforce the other OP_ANTI_REPLAY requirements).
==Rationale==
The only know way of guaranteeing that a transaction cannot be replayed is to include an input that cannot exist, by-definition, on the alternative chain. Coinbase transactions are the only transaction type that is know to exhibit this property strongly.
This BIP makes it convenient for wallets to automate the inclusion of new coinbase inputs into transactions that spend potentially repayable transactions. Everything in this BIP could be done manually by close cooperation between the users and miners, however the author thinks that it is preferable to have it well-defined and enforced.
On Opt-In-RBF enforcement: In the case of conflicting spends of OP_ANTI_REPLAY outputs, the higher-fee transaction should take priority. Wallets may select a random OP_ANTI_REPLAY, then check if the competing transaction has a sufficiently low fee to be replaced.
It is expected that every OP_ANTI_REPLAY output will be in the memory pools waiting to be spend; users must compete for this resource.
==Future Questions==
SegWit Compatibility?
==References==
Opt-In-RBF: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.
Mailing List Post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013777.html
UASF is a wonderful tool in today's bitcoin political environment, I have no reason to believe it is unsafe and will not work as specified.
I prefer the Flag Day approach, precisely because of the toxic political environment you're referring to (or at least I'm calling it toxic). But it's arguably UASF in a different guise, although "user activated" is a little of a misnomer for Flag Day activation.
Any sane UASF will use a flag-day for the activation.
Re: Post your SegWit questions here - open discussion - big week for Bitcoin!
SegWit doesn't look like is going to get activated any time soon, some Chinese miners have gone the BU way and possibly more will switch, but I hope not.
What other options are there for SegWit to be activated? Can the way to activate it be changed at this stage? Or what other possible way is there?
There's UASF, but most of the developers and miners don't think that UASF is safe. As of now, there are no other plans to get segwit activated. I think that it is possible for the timeout date to be pushed back once we get close to it, but so far no proposal for that has been made yet. I highly doubt that the activation threshold will be lowered.What other options are there for SegWit to be activated? Can the way to activate it be changed at this stage? Or what other possible way is there?
UASF isn't as safe as when you you have a coperative miner upgrade. However we don't have coperative miners (or at lest don't have a majorty or coperative miners). UASF becomes very reasonable in this unfortunalte state; as it removes controll from the miners hands.
Of course it is better to do a miner-based upgrade, however this option, in this politcal enviroment, is not reasonable.
Two days ago, a Friday, a full day's work below was the last update: https://github.com/epochtalk/epochtalk/commit/1a34230c77bfe43a9960bd5a1785a9a4dca12277
I'm not a coder, so I haven't a clue if the above needs more commas or cowbells.
Quote
// get lastActive for this user
request.db.users.getLastActive(userId)
.then(function(lastActive) {
- console.log(lastActive);
// if no lastActive, then just update
if (!lastActive) { return true; }
request.db.users.getLastActive(userId)
.then(function(lastActive) {
- console.log(lastActive);
// if no lastActive, then just update
if (!lastActive) { return true; }
I'm not a coder, so I haven't a clue if the above needs more commas or cowbells.
I can undersand that you are not a coder; as a coder would notice that the Epochtalk forum software has been split up into modules and most of the development no-longer happens in the core module.
Please see:
https://github.com/epochtalk/
Re: Reponse to Roger Ver's "Time to End the Block-Size Blockade" essay
@AliceGored
I must admit that going through your history it is clear that you are far, far, more technically and intellectually competent than either Roger, or your average large-blocker.
It would be wise for others to take care when responding to you.
Not that I necessarily agree with what you say.
I must admit that going through your history it is clear that you are far, far, more technically and intellectually competent than either Roger, or your average large-blocker.
It would be wise for others to take care when responding to you.
Not that I necessarily agree with what you say.
Re: Reponse to Roger Ver's "Time to End the Block-Size Blockade" essay
A couple notes of correction and encouragement to start, you misspelled the title of your post, response=yes, responce=no. Also, try "does" instead of "dose". I understand that english is not everyone's first language, so let's look at the arguments and leave the grammatical competence for now.
Thank-you for your well-written response; I've updated the title in correction.
Now we get to the heart of the matter. You say that miners would include any non-zero fee transaction just because they can. This is where the philosophical difference comes to a head. Some feel that without a production quota on blocksize, set by a priesthood of Core devs, miners would simply bloat blocks to infinity. They would willingly destroy the independent node network, simply because they're dumb? or they only care about this week's profits?
Others find this argument ridiculous, and counter to the very "core" principles that govern Bitcoin: Where free market incentives, and CPU consensus, rule the system... not centrally ordained software ministers.
Miners are uniquely placed [and designated by satoshi via the consensus mechanism] to best determine the size of their own blocks because they are directly beholden to the market, unlike devs with ambiguously disclosed stock options in VC startups.
Others find this argument ridiculous, and counter to the very "core" principles that govern Bitcoin: Where free market incentives, and CPU consensus, rule the system... not centrally ordained software ministers.
Miners are uniquely placed [and designated by satoshi via the consensus mechanism] to best determine the size of their own blocks because they are directly beholden to the market, unlike devs with ambiguously disclosed stock options in VC startups.
This is a very interesting view on the matter; one that wasn't at-all represented in Roger's essay.
When the mining is centralized, or quite a small group running it; it is easy for the miners to voluntary set their own limit via cartel. Hopefully, mining doesn't remain so centralized and it will gradually become reasonable for new entrants to join the mining market once the mining hardware efficiency has hit hard technical limits.
Requiring the use of a cartel to set block size limits, (that are applicable to the mining cartel), locks in the mining and node structure we have now. As there is a strong competitive advantage for centralizing and having large blocks.
As a user of Bitcoin, I quite like that my node enforces the blocksize limit; I would be very upset for this consensus power to be taken away from me and given to the miners (cartel).
Of course, this is a huge detour from the status quo, the burden of evidence is on the proponents who wish to make such a change.
I suppose this is the point where you should produce a chart where blocks were constantly at 1MB for the last 6 years... because free globally replicated storage. The reality would probably be more like what we've experienced so far... a steady rise in the use of Bitcoin, and a commensurate increase in blocksize. Not an immediate jump to the new max.
Again with the argument that miners bloat to infinity without a central authority stopping them... all records of blocksize statistics refute this position.
Again with the argument that miners bloat to infinity without a central authority stopping them... all records of blocksize statistics refute this position.
Thank you for this piece of correction. I really should have said minimum relay fee-paying transactions; not non-zero fee transactions.
You can see in the average blocksize charts (for example, when looking when Bitcoin had the 'stress test') that virtually every minimum relay fee-paying transaction has been included by the miners (until recently when blocks finally became full).
The core of my argument still stands, the seen behaviour that miners have been including all transactions that have complied with the minimum-fee-policy that Bitcoin Core has set. I dont see any reason why this should stop at 2mb or 100mb. The miners generally just use the default policy that Bitcoin Core sets; One would expect the miners to get greedier for fees when fees become a larger % of their revenue.
- Miners do face a supply curve, and a propagation cost to larger blocks. The distinction of fee paying/spam is non-functional, as zero fee transactions are already ignored by miners and most nodes. Median fees are 8 cents or more, up from 2 cents a couple months ago, a 400% increase.
- He doesn't have to. It's obvious to an honest observer that 8 cents for the smallest tx possible is already greatly diminishing potential use cases. Blockstream says this is fine. Because (not currently available) payment contracts in LN will handle all that.
- It's not really up to Roger, or the most influential developers, to determine the dynamics of a fee market. It would and will exist with miners facing the free market and subsequently setting their own production levels. Beware the dangers of a centrally planned economy.
I could mirror your petulant conclusion, but, meh.
1. What!? What does that mean? The fee curve in bitcoin is flat. That means that there is very little price discovery for fees; and that most people don't even care about the required fees. (seen by people often overpaying a huge amount for no gain).
The reason that the fee-curve is flat; is that the minimum relay and inclusion policies do not allow it to be developed at the lower fee ranges.
If there was very strong demand, and therefore competition, for the block space, what you would see is many levels of fees. Say. 8c, 10c, 15c, 30c. That would all have different expected functionally (average confirmation time).
Yet, now there is really just two levels: (minimum relay), and 8c, immediately confirm.
This, economically, suggests that blocks are not saturated (for real-fee paying users), and that there is very little economic pressure for more transactions to be included.
2. What!? Again. This is a half-truth. Yes, there are economic use-cases that are placed outside the market from 8c fees. But that says nothing for the economic importance of such transactions. Well, it at least says that the said economic use-cases are not economically significant enough to competitively pay 8c transaction fees.
Using the blockchain for storage is a potential use case if the fees were insanely low; but thankfully they are not.
3. It is up to the person promoting the change to explain why this change doesnt upset the status quo. It is completely fair to expect a understanding of how blocks are going to be paid for by fees; if the block-size is very large.
It is also reasonable to expect that the blocksize (2MB) that Roger is promoting is the thin edge of the wedge; as he has promoted bigger blocks before on many occasions. The question of the long-term viability of Bitcoin under huge blocks is implicitly at hand.
Reponse to Roger Ver's "Time to End the Block-Size Blockade" essay
Hello, many here know of Roger's essay published on the reputable website of the Foundation for Economic Education:
https://fee.org/articles/time-to-end-the-block-size-blockade/
I wrote a considered response to Roger's essay, however, unfortunately, I have not had any response, either from Roger; or from the community at-large. Hence I'm kindly asking for some commentary / responses from the people here on this forum. In particular, are there any part of my post that are wrong, invalid, or misleading?
Original Reddit Post Here
https://fee.org/articles/time-to-end-the-block-size-blockade/
I wrote a considered response to Roger's essay, however, unfortunately, I have not had any response, either from Roger; or from the community at-large. Hence I'm kindly asking for some commentary / responses from the people here on this forum. In particular, are there any part of my post that are wrong, invalid, or misleading?
Original Reddit Post Here
Quote
There are many issues with this essay; really I was quite disappointed with Roger. The primary one being intellectual dishonesty from the use of a bad analogy. While this in itself doesnt invalidate Rogers other claims, it doses put the other claims in poor light.
Firstly, to address the fundamental issue with the Starbucks analogy: Bitcoin isnt like Starbucks Corporation; while there is only one Bitcoin Blockchain, there are tens of thousands of Starbucks stores.
To respond to increases in demand Starbucks can just open more stores (that operate more-or-less independently). However, with Bitcoin, we cannot just add more nodes to respond to an increase in demand; as every (full) node must carry the entire burden of the network.
Roger dose correctly state:
However, his statement is intellectually dishonest as he doesnt analyze what the marginal cost actually is. Where in reality, the marginal cost of including a transaction in a not-full block is virtually zero. Meaning that it doesnt matter what size blocks you have, they will constantly be full. (with exception to miners who have differing policies, but the economically rational miner will include transactions that have any fee above zero).
As we continue Roger doesnt analyse the problems and benefits of blocks being full, instead, based upon his Starbucks fallacy, he just assumes that full blocks are bad. There are two main arguments of why full blocks isnt the evil that Roger plays it to be:
Yet neither of these arguments are addressed in Rogers essay.
Thus we come to the core contention of Rogers essay: (I paraphrase) If we increase the blocksize, blocks will meet capacity again. This is namely false, as it is completely reasonable to expect that blocks of any size to be full.
Roger dose a good job of arguing how is it is possible to increase the blocksize. He completely fails to put it into a well-reasoned context of why we need to rise the blocksize limit.
The marginal cost of getting into the full blocks that are on the network now (with the 1MB limit), is only 8 cents (US). see: https://bitcoinfees.21.co/
Overall this essay is an embarrassment, and anti-intellectual. I can only assume that Roger didnt put this essay out to rigours peer-review before publishing it.
Firstly, to address the fundamental issue with the Starbucks analogy: Bitcoin isnt like Starbucks Corporation; while there is only one Bitcoin Blockchain, there are tens of thousands of Starbucks stores.
To respond to increases in demand Starbucks can just open more stores (that operate more-or-less independently). However, with Bitcoin, we cannot just add more nodes to respond to an increase in demand; as every (full) node must carry the entire burden of the network.
Roger dose correctly state:
Quote
Any time a Bitcoin user is willing to pay a fee that is larger than the marginal cost of including the transaction in a block, it makes economic sense for a miner to include it.
However, his statement is intellectually dishonest as he doesnt analyze what the marginal cost actually is. Where in reality, the marginal cost of including a transaction in a not-full block is virtually zero. Meaning that it doesnt matter what size blocks you have, they will constantly be full. (with exception to miners who have differing policies, but the economically rational miner will include transactions that have any fee above zero).
As we continue Roger doesnt analyse the problems and benefits of blocks being full, instead, based upon his Starbucks fallacy, he just assumes that full blocks are bad. There are two main arguments of why full blocks isnt the evil that Roger plays it to be:
- It is economically unavoidable. (The marginal cost of creating and including transactions is virtually zero).
- Without full blocks there isnt any fee-pressure. Where fees are increasingly important to the long-term health of the network. As the subsidy runs down, this should be compensated by an increase in transaction fees.
Yet neither of these arguments are addressed in Rogers essay.
Thus we come to the core contention of Rogers essay: (I paraphrase) If we increase the blocksize, blocks will meet capacity again. This is namely false, as it is completely reasonable to expect that blocks of any size to be full.
Roger dose a good job of arguing how is it is possible to increase the blocksize. He completely fails to put it into a well-reasoned context of why we need to rise the blocksize limit.
The marginal cost of getting into the full blocks that are on the network now (with the 1MB limit), is only 8 cents (US). see: https://bitcoinfees.21.co/
- Roger dose not address that there is virtually no fee-curve meaning: There are only really two types of transactions on the network: spam and fee paying. (edit: in that to outbid the spam, you only need to increase your fee from 4 cents to 8 cents; suggesting there isn't a strong demand for extra block-space from real fee-paying users.)
- Roger also doesnt address the economic implications of these 8 cent fees on the network. He doesnt address at what point do fees become so large that it does have significant economic implications.
- Roger doesnt address any argument of what point we should start considering a fee market important to the future of Bitcoin (with miners being paid by fees).
Overall this essay is an embarrassment, and anti-intellectual. I can only assume that Roger didnt put this essay out to rigours peer-review before publishing it.
For example:
archival of:
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/
would be quite nice, it is full of all sorts of juicy posts.
archival of:
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/
would be quite nice, it is full of all sorts of juicy posts.
https://archive.is/5XCLT
The last archive is from 13 Sep 2015 02:57:12 UTC
If you try archiving now you get:
https://archive.is/JdGDe
For example:
archival of:
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/
would be quite nice, it is full of all sorts of juicy posts.
archival of:
https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/
would be quite nice, it is full of all sorts of juicy posts.
I think the solution here is simply not using knock-off sites...
Agreed, however there is lots of content on that site that should be kept for future evidence. - It would be great if somebody did a dump of the entire forum.
I was trying to archive some posts on the other "Bitcoin Forum" and quickly found out that is explicitly an disallowed action.
https://bitco.in/robots.txt
What is more interesting is that the owners of the "bitco.in forum" have taken the time to explicitly block the archival site: https://archive.is/
For a site that claims:
https://bitco.in/robots.txt
Code:
User-agent: ia_archiver
Disallow: /
User-agent: *
Disallow: /designertest/
Disallow: /forum/attachments/
Disallow: /forum/forums/*/?direction
Disallow: /forum/forums/*/?order
Disallow: /forum/help/
Disallow: /forum/login/
Disallow: /forum/lost-password/
Disallow: /forum/members/
Disallow: /forum/misc/
Disallow: /forum/online/
Disallow: /forum/posts/
Disallow: /forum/register/
Disallow: /forum/search/
Disallow: /
User-agent: *
Disallow: /designertest/
Disallow: /forum/attachments/
Disallow: /forum/forums/*/?direction
Disallow: /forum/forums/*/?order
Disallow: /forum/help/
Disallow: /forum/login/
Disallow: /forum/lost-password/
Disallow: /forum/members/
Disallow: /forum/misc/
Disallow: /forum/online/
Disallow: /forum/posts/
Disallow: /forum/register/
Disallow: /forum/search/
What is more interesting is that the owners of the "bitco.in forum" have taken the time to explicitly block the archival site: https://archive.is/
For a site that claims:
Quote
Welcome to Bitcoin Forum.
No censorship. No BS.
No censorship. No BS.
Re: Estranged Core Developer Gavin Andresen Finally Makes Sensible 2MB BIP Proposal!
Well Well. What do we have here?
This thread has been a lulzy!
In Summary:
Über Evil Blockstream Core have done *something* evil; and Gavin (and his Super-Hero sidekicks) has swept in with is multi-aborted fetus of blocksize increases to save the day!
The problem is that this (dead, rotten, stinking) blocksize increase fetus is starting to get so fowl that even places like Reddit are starting to get a unsavoury taste in their mouths when it is presented as a viable option; yet again.
---
The mailing list on the other hand...
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012369.html
Well. Lets just say that if this was a game of football; nobody is watching it for the contest anymore.
This thread has been a lulzy!
In Summary:
Über Evil Blockstream Core have done *something* evil; and Gavin (and his Super-Hero sidekicks) has swept in with is multi-aborted fetus of blocksize increases to save the day!
The problem is that this (dead, rotten, stinking) blocksize increase fetus is starting to get so fowl that even places like Reddit are starting to get a unsavoury taste in their mouths when it is presented as a viable option; yet again.
---
The mailing list on the other hand...
Quote from: Gavin Andresen
[...]
Responding to "28 days is not long enough" :
[...]
Responding to "28 days is not long enough" :
[...]
Quote from: Bryan Bishop
[...]
With respect, the question should not be "is 28 days enough time for anyone
to roll out new binaries", it's instead a question of "how long does it
take someone to agree to upgrade to these new incompatible rules".
If Bitcoin users don't want to upgrade to incompatible rules right now, why
would they agree when 10% of the hashpower is setting some flag in a block?
Why would they change their minds at 20%? 90%? I am not saying here that
hard-forks should never be attempted, although we need as an ecosystem to
develop much more rigor and a more data-driven approach, and while that
might be hard to define exactly, as was once said by regulators, I know it
when I see it. Companies in the financial sector give a year or more
before deprecating old APIs even after the new one has been up and running
concurrently and well proven, and would not shut off their old one in order
to get adoption of the new one.
Are we OK with some percent of the Bitcoin ecosystem not agreeing with the
existing rules? What would that mean? Are you willing to maintain two
separate networks, and if not, would you please document this in your BIP?
Deprecation timeline and emergency procedures?? Should we include
rationalizations for not using a new address prefix? In the event of a
partial hard-fork where two chains exist, wouldn't it make more sense to
have the new chain use a new address prefix? Using a new address prefix
could conceivably serve to minimize the impact of what almost looks like an
intentionally constructed y2k-bug type of event for the ecosystem.
[...]
With respect, the question should not be "is 28 days enough time for anyone
to roll out new binaries", it's instead a question of "how long does it
take someone to agree to upgrade to these new incompatible rules".
If Bitcoin users don't want to upgrade to incompatible rules right now, why
would they agree when 10% of the hashpower is setting some flag in a block?
Why would they change their minds at 20%? 90%? I am not saying here that
hard-forks should never be attempted, although we need as an ecosystem to
develop much more rigor and a more data-driven approach, and while that
might be hard to define exactly, as was once said by regulators, I know it
when I see it. Companies in the financial sector give a year or more
before deprecating old APIs even after the new one has been up and running
concurrently and well proven, and would not shut off their old one in order
to get adoption of the new one.
Are we OK with some percent of the Bitcoin ecosystem not agreeing with the
existing rules? What would that mean? Are you willing to maintain two
separate networks, and if not, would you please document this in your BIP?
Deprecation timeline and emergency procedures?? Should we include
rationalizations for not using a new address prefix? In the event of a
partial hard-fork where two chains exist, wouldn't it make more sense to
have the new chain use a new address prefix? Using a new address prefix
could conceivably serve to minimize the impact of what almost looks like an
intentionally constructed y2k-bug type of event for the ecosystem.
[...]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012369.html
Well. Lets just say that if this was a game of football; nobody is watching it for the contest anymore.
Oooo Exciting! I hope it looks fancy
Also I hope some things that are little annoyances about this forum are fixed.
I hope that it is at-least as readable as this forum. The default theme for SMF (that Bitcoin Talk Uses) is very clean clear. Using borders and different shading between posts is nice on the eyes.
Re: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud)
@brg444
https://bitcoin.org/en/bitcoin-core/capacity-increases
I think that this topic is officially over.
Now may be a good time to close this thread, but what a fun ride it has been!
https://bitcoin.org/en/bitcoin-core/capacity-increases
I think that this topic is officially over.
Now may be a good time to close this thread, but what a fun ride it has been!