Nostr notes by

📅 Original date posted:2017-04-06 📝 Original ...

2023-06-07T17:59:19Z

In reply to nevent1q…5z58
_________________________

📅 Original date posted:2017-04-06
📝 Original message:Ethically, this situation has some similarities to the DAO fork. We have an entity who closely examined the code, found an unintended characteristic of that code, and made use of that characteristic in order to gain tens of millions of dollars. Now that developers are aware of it, they want to modify the code in order to negate as much of the gains as possible.

There are differences, too, of course: the DAO attacker was explicitly malicious and stole Ether from others, whereas Bitmain is just optimizing their hardware better than anyone else and better than some of us think they should be allowed to.

In both cases, developers are proposing that the developers and a majority of users collude to reduce the wealth of a single entity by altering the blockchain rules.

In the case of the DAO fork, users were stealing back stolen funds, but that justification doesn't apply in this case. On the other hand, in this case we're talking about causing someone a loss by reducing the value of hardware investments rather than forcibly taking back their coins, which is less direct and maybe more justifiable.

While I don't like patented mining algorithms, I also don't like the idea of playing Calvin Ball on the blockchain. Rule changes should not be employed as a means of disempowering and empoverishing particular entities without very good reason. Whether patenting a mining optimization qualifies as good reason is questionable.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170405/fe7677aa/attachment-0001.sig>;

📅 Original date posted:2017-04-05 📝 Original message:Just ...

2023-06-07T17:59:16Z

In reply to nevent1q…yl0d
_________________________

📅 Original date posted:2017-04-05
📝 Original message:Just checking to see if I understand this optimization correctly. In order to find merkle roots in which the rightmost 32 bits are identical (i.e. partial hash collisions), we want to compute as many merkle root hashes as quickly as possible. The fastest way to do this is to take the top level of the Merkle tree, and to collect a set of left branches and right branches which can be independently manipulated. While the left branch can easily be manipulated by changing the extranonce in the coinbase transaction, the right branch would need to be modified by changing one of the transactions in the right branch or by changing the number of transactions in the right branch. Correct so far?

With the stratum mining protocol, the server (the pool) includes enough information for the coinbase transaction to be modified by stratum client (the miner), but it does not include any information about the right side of the merkle tree except for the top-level hash. Stratum also does not allow the client to supply any modifications to the merkle tree (including the right side) back to the stratum server. This means that any implementation of this final optimization would need to be using a protocol other than stratum, like getblocktemplate, correct?

I think it would be helpful for the discussion to know if this optimization were currently being used or not, and if so, how widely.

All of the consumer-grade hardware that I have seen defaults to stratum-only operation, and I have not seen or heard of any hardware available that can run more efficiently using getblocktemplate. As the current pool infrastructure uses stratum exclusively, this optimization would require significant retooling among pools, and probably a redesign of their core algorithms to help discover and share these partial collisions more frequently. It's possible that some large private farms have deployed a special system for solo mining that uses this optimization, of course, but it's also possible that there's a teapot in space somewhere between the orbit of Earth and Mars.

Do you know of any ways to perform this optimization via stratum? If not, do you have any evidence that this optimization is actually being used by private solo mining farms? Or is this discussion purely about preventing this optimization from being used in the future?

-jtoomim

> On Apr 5, 2017, at 2:37 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> An obvious way to generate different candidates is to grind the
> coinbase extra-nonce but for non-empty blocks each attempt will
> require 13 or so additional sha2 runs which is very inefficient.
>
> This inefficiency can be avoided by computing a sqrt number of
> candidates of the left side of the hash tree (e.g. using extra
> nonce grinding) then an additional sqrt number of candidates of
> the right side of the tree using transaction permutation or
> substitution of a small number of transactions. All combinations
> of the left and right side are then combined with only a single
> hashing operation virtually eliminating all tree related
> overhead.
>
> With this final optimization finding a 4-way collision with a
> moderate amount of memory requires ~2^24 hashing operations
> instead of the >2^28 operations that would be require for
> extra-nonce grinding which would substantially erode the
> benefit of the attack.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170405/591656bf/attachment.sig>;

📅 Original date posted:2016-02-07 📝 Original message:On Feb ...

2023-06-07T17:48:45Z

In reply to nevent1q…za70
_________________________

📅 Original date posted:2016-02-07
📝 Original message:On Feb 7, 2016, at 9:24 AM, jl2012 at xbt.hk wrote:

> You are making a very naïve assumption that miners are just looking for profit for the next second. Instead, they would try to optimize their short term and long term ROI. It is also well known that some miners would mine at a loss, even not for ideological reasons, if they believe that their action is beneficial to the network and will provide long term ROI. It happened after the last halving in 2012. Without any immediate price appreciation, the hashing rate decreased by only less than 10%
>

In 2012, revenue dropped by about 50% instantaneously. That does not mean that profitability became negative.

The difficulty at the time of the halving was about 3M. The exchange rate was about $12. A common miner at the time was the Radeon 6970, which performed about 350 Mh/s on 200 W for about 1.75 Mh/J. A computer with 4 6970s would use about 1 kW of power, once AC/DC losses and CPU overhead are taken into account. This 1 kW rig would have earned about $0.22/kWh before the halving, and $0.11/kWh after the halving. Since it's not hard to find electricity cheaper than $0.11/kWh, the hashrate didn't drop much.

It's a common misconception that the mining hashrate increases until an equilibrium is reached, and nobody is making a profit any longer. However, this is not true. The hashrate stops increasing when the expected operating profit over a reasonable time frame is no longer greater than the hardware cost, not when the operating profit approaches zero. For example, an S7 right now costs a little over $1000. If I don't expect to earn more than $1000 in operating profit over the next year or two with an S7, then I won't buy one.

Right now, an S7 earns about $190/month and costs about $60/month to operate, for a profit of $120/month. After the halving, revenue would drop to $95/month (or less, depending on difficulty and exchange rate), leaving profit at about $35/month. The $120/month profit is good enough motivation to buy hardware now, and the $35/month would be good enough motivation to keep running hardware after the halving.

I know in advance when the halvings are coming. There's going to be one in about 5 months, for example. I'm going to stop buying miners before the halving even if they're very profitable for a month because I don't want to be stuck with hardware that won't reach 100% return on investment (ROI).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/cc038b30/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/cc038b30/attachment-0001.sig>;

📅 Original date posted:2016-02-07 📝 Original message:On Feb ...

2023-06-07T17:48:44Z

In reply to nevent1q…9vst
_________________________

📅 Original date posted:2016-02-07
📝 Original message:On Feb 7, 2016, at 7:19 AM, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> The stated reasoning for 75% versus 95% is "because it gives "veto power"
> to a single big solo miner or mining pool". But if a 20% miner wants to
> "veto" the upgrade, with a 75% threshold, they could instead simply use
> their hashpower to vote for an upgrade, but then not mine anything on
> the new chain. At that point there'd be as little as 55% mining the new
> 2MB chain with 45% of hashpower remaining on the old chain. That'd be 18
> minute blocks versus 22 minute blocks, which doesn't seem like much of
> a difference in practice, and at that point hashpower could plausibly
> end up switching almost entirely back to the original consensus rules
> prior to the grace period ending.

Keep in mind that within a single difficulty adjustment period, the difficulty of mining a block on either chain will be identical. Even if the value of a 1MB branch coin is $100 and the hashrate on the 1 MB branch is 100 PH/s, and the value of a 2 MB branch coin is $101 and the hashrate on the 2 MB branch is 1000 PH/s, the rational thing for a miner to do (for the first adjustment period) is to mine on the 2 MB branch, because the miner would earn 1% more on that branch.

So you're assuming that 25% of the hashrate chooses to remain on the minority version during the grace period, and that 20% chooses to switch back to the minority side. The fork happens. One branch has 1 MB blocks every 22 minutes, and the other branch has 2 MB blocks every 18 minutes. The first branch cannot handle the pre-fork transaction volume, as it only has 45% of the capacity that it had pre-fork. The second one can, as it has 111% of the pre-fork capacity. This makes the 1 MB branch much less usable than the 2 MB branch, which in turn causes the market value of newly minted coins on that branch to fall, which in turn causes miners to switch to the more profitable 2MB branch. This exacerbates the usability difference, which exacerbates the price difference, etc. Having two competing chains with equal hashrate using the same PoW function and nearly equal features is not a stable state. Positive feedback loops exist to make the vast majority of the users and the hashrate join one side.

Basically, any miners who stick to the minority branch are going to lose a lot of money.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/d2b9d665/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160207/d2b9d665/attachment-0001.sig>;

📅 Original date posted:2015-12-25 📝 Original message:On Dec ...

2023-06-07T17:47:04Z

In reply to nevent1q…kzcd
_________________________

📅 Original date posted:2015-12-25
📝 Original message:On Dec 25, 2015, at 3:15 AM, Ittay via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> Treating the pool block withholding attack as a weapon has bad connotations, and I don't think anyone directly condones such an attack.

I directly condone the use of block withholding attacks whenever pools get large enough to perform selfish mining attacks. Selfish mining and large, centralized pools also have bad connotations.

It's an attack against pools, not just large pools. Solo miners are immune. As such, the presence or use of block withholding attacks makes Bitcoin more similar to Satoshi's original vision. One of the issues with mining centralization via pools is that miners have a direct financial incentive to stay relatively small, but pools do not. Investing in mining is a zero-sum game, where each miner gains revenue by making investments at the expense of existing miners. This also means that miners take revenue from themselves when they upgrade their hashrate. If a miner already has 1/5 of the network hashrate, then the marginal revenue for that miner of adding 1 TH/s is only 4/5 of the marginal revenue for a miner with 0% of the network and who adds 1 TH/s. The bigger you get, the smaller your incentive to get bigger.

This incentive applies to miners, but it does not apply to pools. Pools have an incentive to get as big as possible (except for social backlash and altruistic punishment issues). Pools are the problem. I think we should be looking for ways of making pooled mining less profitable than solo mining or p2pool-style mining. Block withholding attacks are one such tool, and maybe the only usable tool we'll get. If we have to choose between making bitcoin viable long-term and avoiding things with bad connotations, it might be better to let our hands get a little bit dirty.

I don't intend to perform any such attacks myself. I like to keep my hat a nice shiny white. However, if anyone else were to perform such an attack, I would condone it.

P.S.: Sorry, pool operators. I have nothing against you personally. I just think pools are dangerous, and I wish they didn't exist.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151225/590e0d31/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151225/590e0d31/attachment.sig>;

📅 Original date posted:2015-12-29 📝 Original ...

2023-06-07T17:46:59Z

In reply to nevent1q…ecjh
_________________________

📅 Original date posted:2015-12-29
📝 Original message:Ultimately, a self-interested miner will chose to build on the block that leaves the most transaction fees up for grabs. (This usually means the smallest block.) It's an interesting question whether the default behavior for Core should be the rational behavior (build on the "smallest" block in terms of fees) or some other supposedly altruistic behavior (most BTCDD). This also applies to the decision of the "same time" threshold -- a selfish miner will not care if the blocks arrived at about the same time or not.

I currently do not have a strong opinion on what that behavior should be, although if the blocksize limit were increased substantially, I may prefer the selfish behavior because it ends up also being fail-safe (punishes selfish mining using large blocks or fee-stealing attempts).

On Dec 29, 2015, at 10:59 AM, Dave Scotese via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> There have been no decent objections to altering the block-selection mechanism (when two block solutions appear at nearly the same time) as described at
>
> http://bitcoin.stackexchange.com/questions/39226
>
> Key components are:
> Compute BitcoinDaysDestroyed using only transactions that have been in your mempool for some time as oBTCDD ("old BTCDD").
> Use "nearly the same time" to mean separated in time by your guess of the average duration of block propagation times.
> When two block solutions come in at nearly the same time, build on the one that has the most oBTCDD, rather than the one that came in first.
> The goal of this change is to reduce the profitability of withholding block solutions by severely reducing the chances that a block solved a while ago can orphan one solved recently. "Came in first" seems more easily gamed than "most oBTCDD". As I wrote there, "old coins is always a dwindling resource and global nodes willing to help cheat is probably a growing one."
>
> I will write a BIP if anyone agrees it's a good idea.
>
>
> On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Far more concerning is network propagation effects between large and
> small miners. For that class of issues, if you are in an environemnt
> where selfish mining is possible - a fairly flat, easily DoS/sybil
> attacked network topology - the profitability difference between small
> and large miners even *without* attacks going on is a hugely worrying
> problem. OTOH, if you're blocksize is small enough that propagation time
> is negligable to profitability, then selfish mining attacks with <30%
> hashing power aren't much of a concern - they'll be naturally defeated
> by anti-DoS/anti-sybil measures.
>
> Let's agree that one factor in mining profitability is bandwidth/network reliability/stability. Why focus on that vs electricity contracts or vertically integrated chip manufacturers? Surely, sufficient network bandwidth is a more broadly available commodity than <$0.02/kwh electricity, for example. I'm not sure that your stranded hydroelectric miner is any more desirable than thousands of dorm room miners with access to 10gbit university connections and free electricity.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> --
> I like to provide some work at no charge to prove my value. Do you need a techie?
> I own Litmocracy and Meme Racing (in alpha).
> I'm the webmaster for The Voluntaryist which now accepts Bitcoin.
> I also code for The Dollar Vigilante.
> "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151229/a62c256a/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151229/a62c256a/attachment-0001.sig>;

📅 Original date posted:2015-12-18 📝 Original message:On Dec ...

2023-06-07T17:46:45Z

In reply to nevent1q…z23u
_________________________

📅 Original date posted:2015-12-18
📝 Original message:On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> 1) The risk of an old full node wallet accepting a transaction that is
> invalid to the new rules.
>
> The receiver wallet chooses what address/script to accept coins on.
> They'll upgrade to the new softfork rules before creating an address
> that depends on the softfork's features.
>
> So, not a problem.

Mallory wants to defraud Bob with a 1 BTC payment for some beer. Bob runs the old rules. Bob creates a p2pkh address for Mallory to use. Mallory takes 1 BTC, and creates an invalid SegWit transaction that Bob cannot properly validate and that pays into one of Mallory's wallets. Mallory then immediately spends the unconfirmed transaction into Bob's address. Bob sees what appears to be a valid transaction chain which is not actually valid.

Clueless Carol is one of the 4.9% of miners who forgot to upgrade her mining node. Carol sees that Mallory included an enormous fee in his transactions, so Carol makes sure to include both transactions in her block.

Mallory gets free beer.

Anything I'm missing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/4389e72a/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151218/4389e72a/attachment-0001.sig>;

📅 Original date posted:2015-12-08 📝 Original message:On Dec ...

2023-06-07T17:45:48Z

In reply to nevent1q…2et9
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Dec 9, 2015, at 8:09 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Tue, Dec 8, 2015 at 11:48 PM, Jonathan Toomim <j at toom.im> wrote:
>
> By contrast it does not reduce the safety factor for the UTXO set at
> all; which most hold as a much greater concern in general;

I don't agree that "most" hold UTXO as a much greater concern in general. I think that it's a concern that has been addressed less, which means it is a more unsolved concern. But it is not currently a bottleneck on block size. Miners can afford way more RAM than 1 GB, and non-mining full nodes don't need to store the UTXO in memory.I think that at the moment, block propagation time is the bottleneck, not UTXO size. It confuses me that SigWit is being pushed as a short-term fix to the capacity issue when it does not address the short-term bottleneck at all.

> and that
> isn't something you can say for a block size increase.

True.

I'd really like to see a grand unified cost metric that includes UTXO expansion. In the mean time, I think miners can use a bit more RAM.

> With respect to witness safety factor; it's only needed in the case of
> strategic or malicious behavior by miners-- both concerns which
> several people promoting large block size increases have not only
> disregarded but portrayed as unrealistic fear-mongering. Are you
> concerned about it?

Some. Much less than e.g. Peter Todd, for example, but when other people see something as a concern that I don't, I try to pay attention to it. I expect Peter wouldn't like the safety factor issue, and I'm surprised he didn't bring it up.

Even if I didn't care about adversarial conditions, it would still interest me to pay attention to the safety factor for political reasons, as it would make subsequent blocksize increases much more difficult. Conspiracy theorists might have a field day with that one...

> In any case-- the other improvements described in
> my post give me reason to believe that risks created by that
> possibility will be addressable.

I'll take a look and try to see which of the worst-case concerns can and cannot be addressed by those improvements.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/c3a9894f/attachment.sig>;

📅 Original date posted:2015-12-08 📝 Original message:On Dec ...

2023-06-07T17:45:47Z

In reply to nevent1q…nxa5
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Dec 8, 2015, at 6:02 AM, Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> The particular proposal amounts to a 4MB blocksize increase at worst.

I understood that SegWit would allow about 1.75 MB of data in the average case while also allowing up to 4 MB of data in the worst case. This means that the mining and block distribution network would need a larger safety factor to deal with worst-case situations, right? If you want to make sure that nothing goes wrong when everything is at its worst, you need to size your network pipes to handle 4 MB in a timely (DoS-resistant) fashion, but you'd normally only be able to use 1.75 MB of it. It seems to me that it would be safer to use a 3 MB limit, and that way you'd also be able to use 3 MB of actual transactions.

As an accounting trick to bypass the 1 MB limit, SegWit sounds like it might make things less well accounted for.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/a0eca647/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/a0eca647/attachment.sig>;

📅 Original date posted:2015-12-14 📝 Original message:This ...

2023-06-07T17:45:46Z

In reply to nevent1q…03k3
_________________________

📅 Original date posted:2015-12-14
📝 Original message:This means that a server supporting SW might only hear of the tx data and not get the signature data for some transactions, depending on how the relay rules worked (e.g. if the SW peers had higher minrelaytxfee settings than the legacy peers). This would complicate fast block relay code like IBLTs, since we now have to check to see that the recipient has both the tx data and the witness/sig data.

The same issue might happen with block relay if we do SW as a soft fork. A SW node might see a block inv from a legacy node first, and might start downloading the block from that node. This block would then be marked as in-flight, and the witness data might not get downloaded. This shouldn't be too hard to fix by creating an inv for the witness data as a separate object, so that a node could download the block from e.g. Peer 1 and the segwit data from Peer 2.

Of course, the code would be simpler if we did this as a hard fork and we could rely on everyone on the segwit fork supporting the segwit data. Although maybe we want to write the interfaces in a way that supports some nodes not downloading the segwit data anyway, just because not every node will want that data.

I haven't had time to read sipa's code yet. I apologize for talking out of a position of ignorance. For anyone who has, do you feel like sharing how it deals with these network relay issues?

By the way, since this thread is really about SegWit and not about any other mechanism for increasing Bitcoin capacity, perhaps we should rename it accordingly?

On Dec 12, 2015, at 11:18 PM, Mark Friedenbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> A segwit supporting server would be required to support relaying segwit transactions, although a non-segwit server could at least inform a wallet of segwit txns observed, even if it doesn't relay all information necessary to validate.
>
> Non segwit servers and wallets would continue operations as if nothing had occurred.
>
> If this means essentially that a soft fork deployment of SegWit will require SPV wallet servers to change their logic (or risk not being able to send payments) then it does seem to me that a hard fork to deploy this non controversial change is not only cleaner (on the data structure side) but safer in terms of the potential to affect the user experience.
>
>
> — Regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151214/b6bcb6cb/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151214/b6bcb6cb/attachment.sig>;

📅 Original date posted:2015-12-08 📝 Original message:On Dec ...

2023-06-07T17:45:40Z

In reply to nevent1q…f7cx
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Dec 9, 2015, at 7:50 AM, Jorge Timón <jtimon at jtimon.cc> wrote:

> I don't undesrtand. SPV nodes won't think they are validating transactions with the new version unless they adapt to the new format. They will be simply unable to receive payments using the new format if it is a softfork (although as said I agree with making it a hardfork on the simpler design and smaller fraud proofs grounds alone).
>
Okay, I might just not understand how a sigwit payment would look to current software yet. I'll add learning about that to my to-do list...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/b3c8f971/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/b3c8f971/attachment.sig>;

📅 Original date posted:2015-12-08 📝 Original message:Agree. ...

2023-06-07T17:45:39Z

In reply to nevent1q…5l4w
_________________________

📅 Original date posted:2015-12-08
📝 Original message:Agree. This data does not belong in the coinbase. That space is for miners to use, not devs.

I also think that a hard fork is better for SegWit, as it reduces the size of fraud proofs considerably, makes the whole design more elegant and less kludgey, and is safer for clients who do not upgrade in a timely fashion. I don't like the idea that SegWit would invalidate the security assumptions of non-upgraded clients (including SPV wallets). I think that for these clients, no data is better than invalid data. Better to force them to upgrade by cutting them off the network than to let them think they're validating transactions when they're not.

On Dec 8, 2015, at 11:55 PM, Justus Ranvier via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

> If such a change is going to be deployed via a soft fork instead of a
> hard fork, then the coinbase is the worst place to put the segwitness
> merkle root.
>
> Instead, put it in the first output of the generation transaction as an
> OP_RETURN script.
>
> This is a better pattern because coinbase space is limited while output
> space is not. The next time there's a good reason to tie another merkle
> tree to a block, that proposal can be designated for the second output
> of the generation transaction.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/a4037777/attachment.sig>;

📅 Original date posted:2015-12-08 📝 Original message:On Dec ...

2023-06-07T17:45:39Z

In reply to nevent1q…juat
_________________________

📅 Original date posted:2015-12-08
📝 Original message:On Dec 9, 2015, at 7:48 AM, Luke Dashjr <luke at dashjr.org> wrote:

> How about we pursue the SegWit softfork, and at the same time* work on a
> hardfork which will simplify the proofs and reduce the kludgeyness of merge-
> mining in general? Then, if the hardfork is ready before the softfork, they
> can both go together, but if not, we aren't stuck delaying the improvements of
> SegWit until the hardfork is completed.

So that all our code that parses the blockchain needs to be able to find the sigwit data in both places? That doesn't really sound like an improvement to me. Why not just do it as a hard fork? They're really not that hard to do.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/96a8d6a7/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151209/96a8d6a7/attachment.sig>;