Nostr notes by Hampus Sjöberg [ARCHIVE]

📅 Original date posted:2019-08-13 📝 Original message: While ...

2023-06-09T12:55:53Z

In reply to nevent1q…peye
_________________________

📅 Original date posted:2019-08-13
📝 Original message:
While I do agree that this is a problem that we needs to be addressed
somehow, I don't agree on your proposal because I don't think we should
connect two end-users this way. It won't work out in the long run because
if you connect say mobile wallets this way, one mobile could be offline,
which locks the funds for the other part.

Another approach could be that wallets start using the already existing
fallback tag (`f`) on BOLT11 invoices, where you can embed a Bitcoin
address.
This way, the sender could send the funds on-chain should it fail to send
over Lightning.
This however requires the sender to have off-chain funds available which is
probably not the case. What could be done here is a splice out or a
submarine swap, but they are not well established yet unfortunately.

Another way is to set up a "temporary" custodian channel if the receiver
doesn't have enough inbound capacity.
How it would work is that you have a third party custodian (i.e the wallet
provider) receives the money on your behalf. The next time you want to send
something, this channel takes top priority.
This way the on-boarding process is pretty much solved, if you are OK with
some trust.

What do you think?

Cheers
Hampus

Den mån 12 aug. 2019 kl 05:43 skrev Ecurrencyhodler Blockchains <
ecurrencyhodler at gmail.com>:

> Hi. I'd like to propose a way for instant inbound liquidity to be
> automated via invoices and would appreciate your feedback. It's similar to
> Thor's instant channel but this proposal would only be valuable if it
> becomes a standard across all lightning implementations and wallets. It
> won't work if it's limited to just one Lightning wallet.
>
> *Proposal:* Automated Inbound Liquidity With Invoices
>
> *For Who:* Full Lightning Network nodes
>
> *Problem:* Waiting for inbound liquidity as channel establishes when you
> first come online and want to receive a LN payment.
>
> *Solution: *Embedding the node uri of the invoice creator, along with
> amount to be routed.
>
> *Scenario: *
>
> 1. Bob wants to send me 100,000 sats.
> 2. My node just came online and has 0 inbound liquidity.
> 3. I create an invoice for 100,000 sats. My LN node recognizes I have
> 0 inbound liquidity so my wallet also embeds my URI in the invoice.
> 4. Bob’s wallet sees an invoice + uri. Maybe even tries to route.
> When it doesn’t see anything, it auto opens a channel + pushes 100,000 sat
> payment.
> 5. I now own and can spend 100,000 sats instantly.
>
> *Considerations:*
>
> - This auto establishing of channels and pushing payments isn’t for
> all LN nodes. Just routing nodes.
> - Bob doesn’t need to be the one to establish the channel. He can
> push the information down the line until a node dedicated to routing is
> found. The routing node can then be the one to establish the channel with
> me.
> - Certain specifics need to be flushed out such as the size of Bob’s
> channel. Right now I think Bob can manually set the size of the channels
> to be established on his end. Should be smaller channels at first. If the
> person gets paid again, just establish another channel towards the same
> node if there isn't enough capacity.
> - Routing nodes who provide this service can charge a premium.
> - Bob, as a liquidity provider, won't cheat against himself so I can
> make LN payments instantly.
> - The beauty behind this proposal is that I can receive a payment
> instantly, I can send payments instantly, and that it hides everything from
> me as an end user.
> - Can possibly be extended to neutrino LN wallets if they are public.
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190813/7f534589/attachment.html>;

📅 Original date posted:2022-04-25 📝 Original message:Hi ...

2023-06-07T23:07:58Z

In reply to nevent1q…yx9p
_________________________

📅 Original date posted:2022-04-25
📝 Original message:Hi pushd.
Would you mind clarifying what you mean by BIP118 being a premature idea?
SIGHASH_ANYPREVOUT, or SIGHASH_NOINPUT, as it was called back then, was
first proposed in the original Lightning Network whitepaper back in 2015.
It has been discussed on and off for many years now. I would not call it a
premature idea.

Now, the revised "Taprooted" version called ANYPREVOUT is a couple of years
old, so going with the NOINPUT version could be a safer bet (though that's
a bit ridiculous in my opinion).

Regarding that you do not find use-cases interesting. That's all fine I
suppose, but in the Lightning Network scene, I think it's fair to say that
there's widespread enthusiasm in getting a working eltoo solution, which
necessitates something like NOINPUT/ANYPREVOUT.
And even if eltoo wouldn't happen, enabling spacechains, covenants and
blind statechains seem like sufficient use-cases to me.

Cheers
Hampus

On Fri, Apr 22, 2022 at 9:32 PM pushd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of (or before doing) BIP119.
>
>
> NACK for the below reasons:
>
> - Premature idea
> - I do not find use cases interesting
> - We are still in research phase of implementing covenants in bitcoin and
> looking for the best proposal
> - Taproot soft fork was recently activated and its too soon
> - Not enough documentation available
> - Could not find any pull request in core for BIP 118 that can be reviewed
> - Not enough tools available for testing
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
>
> ------- Original Message -------
> On Friday, April 22nd, 2022 at 5:30 PM,
> bitcoin-dev-request at lists.linuxfoundation.org wrote:
>
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
> Today's Topics:
>
> 1. ANYPREVOUT in place of CTV (darosior)
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 22 Apr 2022 11:11:41 +0000
> From: darosior darosior at protonmail.com
>
> To: Bitcoin Protocol Discussion
> bitcoin-dev at lists.linuxfoundation.org
>
> Subject: [bitcoin-dev] ANYPREVOUT in place of CTV
> Message-ID:
>
> p3P0m2_aNXd-4oYhFjCKJyI8zQXahmZed6bv7lnj9M9HbP9gMqMtJr-pP7XRAPs-rn_fJuGu1cv9ero5i8f0cvyZrMXYPzPx17CxJ2ZSvRk=@protonmail.com
>
> Content-Type: text/plain; charset=utf-8
>
> I would like to know people's sentiment about doing (a very slightly
> tweaked version of) BIP118 in place of
> (or before doing) BIP119.
>
> SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for
> over 6 years. It presents proven and
> implemented usecases, that are demanded and (please someone correct me if
> i'm wrong) more widely accepted than
> CTV's.
>
> SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made
> optional [0], can emulate CTV just fine.
> Sure then you can't have bare or Segwit v0 CTV, and it's a bit more
> expensive to use. But we can consider CTV
> an optimization of APO-AS covenants.
>
> CTV advocates have been presenting vaults as the flagship usecase.
> Although as someone who've been trying to
> implement practical vaults for the past 2 years i doubt CTV is necessary
> nor sufficient for this (but still
> useful!), using APO-AS covers it. And it's not a couple dozen more virtual
> bytes that are going to matter for
> a potential vault user.
>
> If after some time all of us who are currently dubious about CTV's stated
> usecases are proven wrong by onchain
> usage of a less efficient construction to achieve the same goal, we could
> roll-out CTV as an optimization. In
> the meantime others will have been able to deploy new applications
> leveraging ANYPREVOUT (Eltoo, blind
> statechains, etc..[1]).
>
> Given the interest in, and demand for, both simple covenants and better
> offchain protocols it seems to me that
> BIP118 is a soft fork candidate that could benefit more (if not most of)
> Bitcoin users.
> Actually i'd also be interested in knowing if people would oppose the
> APO-AS part of BIP118, since it enables
> CTV's features, for the same reason they'd oppose BIP119.
>
> [0] That is, to not commit to the other inputs of the transaction (via
> sha_sequences and maybe also
> sha_amounts). Cf
> https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signature-message
> .
>
> [1] https://anyprevout.xyz/ "Use Cases" section
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 83, Issue 40
> *******************************************
>
> _______________________________________________
> 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/20220425/ee7678ee/attachment.html>;

📅 Original date posted:2019-11-11 📝 Original message:> ...

2023-06-07T18:21:34Z

In reply to nevent1q…fzx8
_________________________

📅 Original date posted:2019-11-11
📝 Original message:> It ISN'T low right now...

I agree, but I don't think it's a good idea to softfork it to lower than 4M
WU though, and I don't think we need to;
hopefully when exchanges start using Lightning or Liquid, avg blocksize
will go down.

> Extension blocks are not softforks, and are unreasonably convoluted for
no
real gain. When the time comes, the block size should be increased only
using
a hardfork.

It depends on how you define soft and hardforks, I suspect you don't see
extension blocks as a softforks because old nodes won't maintain a correct
UTXO set.
I think an extension block is a softfork because old nodes will still be
able to follow the mainchain.

I don't know if a blocksize increase hardfork will get consensus as the
idea has been ruined by all malicious hijack attempts we've seen over the
years.

Hampus

Den mån 11 nov. 2019 kl 17:47 skrev Luke Dashjr <luke at dashjr.org>:

> On Monday 11 November 2019 16:08:43 Hampus Sjöberg via bitcoin-dev wrote:
> > I am advocating to keep the blocksize low right now,
>
> It ISN'T low right now...
>
> > but I don't leave out
> > in increasing it in the future when we have a need for it, preferably via
> > an extension block (softfork).
>
> Extension blocks are not softforks, and are unreasonably convoluted for no
> real gain. When the time comes, the block size should be increased only
> using
> a hardfork.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191111/606aa93f/attachment.html>;

📅 Original date posted:2019-11-11 📝 Original message:> ...

2023-06-07T18:21:33Z

In reply to nevent1q…78zc
_________________________

📅 Original date posted:2019-11-11
📝 Original message:> 1. We have Lightning and SegWit so thankfully we do not need to deal with
blocksizes anymore really.

Regardless of the current proposal in this email thread, just because we
have Lightning doesn't mean we don't ever have to increase the blocksize
again.
Even with Lightning there would be too many channel open and closes to be
able to handle million users without transaction fees going through the
roof.
I am advocating to keep the blocksize low right now, but I don't leave out
in increasing it in the future when we have a need for it, preferably via
an extension block (softfork).

Hampus

Den fre 8 nov. 2019 kl 15:44 skrev Emil Engler via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> NACK!
> 1. We have Lightning and SegWit so thankfully we do not need to deal with
> blocksizes anymore really.
> 2. What if a reorg happens? Then it could generate huge problems at the
> validation.
>
> Correct me if I understood it wrong please.
>
> Greetings,
> Emil Engler
>
> Trevor Groves via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> schrieb am Fr. 8. Nov. 2019 um 15:26:
>
>> Dynamic MaxBlockSize - 3 Byte Solution
>> "DMBS"
>>
>> If
>> (Last TOTAL Block Trans fees) > (AVG (Last 100 Blocks Trans Fees))
>> AND
>> current MaxBlockSize => 0.99 MB
>> AND
>> MaxBlockSize has not changed in 10 Blocks
>> ** see error catch below
>> Then
>> ON (Current Block # + 9) Set MaxBlockSize = (MaxBlockSize x 1.1)
>> ELSE
>> AT (Current Block # + 9) Set MaxBlockSize = (MaxBlockSize / 1.1)
>> ELSEIF
>> (current MaxBlockSize =< 0.99 or current MaxBlockSize > 6553.5 MB)
>> Null (no action taken)
>> **where 9 above represents the ActivateONBlock (software side) Variable
>> -------------
>> We add this 3 Byte Variable Factor to the white space in the Current
>> Block.
>>
>> eg. this 3 byte HEX 19000A
>> the first bit "1" can be 1,2 or 0
>> 1 = increase future block (9 blocks ahead)
>> 2 decrease future block (9 blocks ahead)
>> 0 No Action (rules evaluate to null)
>> **where 9 above represents the ActivateONBlock (software side) Variable
>> --------------
>> The Second bit is a Global Variable "9" represents a countdown to the set
>> value action, placed to synchronize network forward changes in "x" blocks.
>> software lowers value if evaluates to True a second time and so on.
>> ("Count down" if you will)
>> the last 2 bytes represent the globally accepted "MaxBlockSize"
>> Variable, and is distributed within each block moving forward in this
>> rightmost (2 byte) factor. In this case above,
>> The variable portion "000A" (32 Bit value) represents decimal value 10
>> being 1.0 MB block.
>> the decimal place is Always Assumed, and must be hard coded
>> Because this presents a theoretical Max limit of "FFFF" or 6553.5 MB,
>> We would
>> have to add a last rule "only as a error catch"
>> ** AND IF MaxBlockSize < 6553.5
>> ---
>> Increasing and decreasing
>> On Every Block mined or distributed, the software can run the above rule
>> set, Change the Variable and Distribute the next block " In Synchronized
>> fashion". The above rules when combined evaluate to a YES or NO, This
>> translates to a market reflection of increased system pressure or decreased
>> market pressure. I think we can agree, at peak periods the system chokes
>> itself off with fees and this is always only temporarily. So we can have
>> the block, analyse system demand dynamically, and adjust on a globally
>> agreed rule dynamically by market driven demand.
>> Considering the ruleset above also Decreases the Block ONLY if its
>> greater than 0.99mb this brings size back to a competitive state /and size
>> once market demand pressures subside, yet achieves the smallest market
>> feasible block size while also maintaining all current rule sets.
>> An attacker would have to affect all block fees over the last 16 hours
>> worth of transactions to affect a 10% max block size increase but then only
>> after waiting 1.5 hours, so long as nothing has changed in the last 1.5
>> hours and only for a limited amount of time. This approach also limits
>> bloat. This safety block window of 9 blocks provides a look forward and
>> look behind value, in turn provides the network time to synchronize.
>> 10 block sync window. This, by design, also limits changes to one
>> change every 3 hours (20 blocks), if there is a market pressure "STATE"
>> occurring.
>> My Question to the community is. Will our current Block accommodate the 3
>> Byte
>> Variable, Is solving the Scaling issue worth using the 3 Bytes of space?
>> I believe it is.
>> --
>> Software, Will need to Evaluate MaxBlockSize Variable, and
>> ActivateONBlock Variable from the most recent distributed blocks DMBS 3
>> byte value.
>> Run the rules , get the answer set the now known MaxBlockSize Var and
>> Propegate the "DMBS" value.
>>
>> As capacity limits are breached, I think the majority agree "we need to
>> agree".
>>
>> MaxBlockSize would provide a suitable middle ground and address concerns
>> in a dynamic fashion, without compromising or changing existing
>> security.
>> Examples reflected in the blockchain 19000A rules has evaluates to
>> true, increase expected in 9 blocks.1.0mb increases to 1.1mb
>> if true for 9 more blocks MaxBlockSize Var becomes 18000A..
>> 17000A..,16000A ..and so on if still true at 10000A var written becomes
>> 00000B when read from left to right, 0-no change, in 0 blocks current "
>> DMBS" value 000B or 1.1MB and stays that way 00000B until MaxBlockSize
>> evaluates to "True" under a market pressure/ relief situation.
>> I hope this makes sense, I would appreciate some feedback.
>> TG
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> 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/20191111/01e64494/attachment.html>;

📅 Original date posted:2019-04-26 📝 Original ...

2023-06-07T18:17:49Z

In reply to nevent1q…gvnf
_________________________

📅 Original date posted:2019-04-26
📝 Original message:Bitcoin is a consensus critical system.
We have already had consensus problems between Bitcoin Core-versions,
rewriting everything in another language would expose us to even greater
risks, and moving to a language like Python I see no benefit whatsoever.

Best
Hampus

Den tis 23 apr. 2019 kl 16:47 skrev Ahmer Regos via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> I'm proposing re-writing bitcoin codebase in Python for improving pre and
> post merging abilities, faster operations and better understandability.
> Python is a fast language with C support, it is good with hashing things,
> it has a good syntax and everyone can read / understand it unlike C++.
>
> I am willing the coordinate the transformation operation and i believe it
> would be really good the get rid of C++.
>
> - Ahmer Regos from Regain Beaches.
> _______________________________________________
> 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/20190426/e356187c/attachment.html>;

📅 Original date posted:2019-02-14 📝 Original message:Hi ...

2023-06-07T18:16:27Z

In reply to nevent1q…swkh
_________________________

📅 Original date posted:2019-02-14
📝 Original message:Hi ZmnSCPxj.

> There is a position that fullnodes must be able to get a view of the UTXO
set, and extension blocks (which are invisible to pre-extension-block
fullnodes) means that fullnodes no longer have an accurate view of the UTXO
set.
> SegWit still provides pre-SegWit fullnodes with a view of the UTXO set,
although pre-SegWit fullnodes could be convinced that a particular UTXO is
anyone-can-spend even though they are no longer anyone-can-spend.
> Under this point-of-view, then, extension block is "not" soft fork.

There's a way to do CT without an extension block and while still
maintaining a correct UTXO set for old nodes. Perhaps it is similar what
you meant with this comment (I believe you don't need to do a hardfork
though)

> Then it becomes impossible to move from confidential to public
transactions with a value more than this counter, thus preventing inflation
even if a future QC breach allows confidential transaction value
commitments to be opened to any value.
> (do note that a non-extension-block approach is a definite hardfork)

Anyway, the method goes like this:

Funds that go in to CT-mode are placed in a consensus/miner controlled
reserve pool. To go out from CT back to normal, funds are then transferred
back to the user from this pool.
CT transactions seen from a non-upgraded node will be a transaction with 0
sat outputs. The actual rangeproof commitment could be placed in the script
output or perhaps somewhere else.

To enter CT-mode, you'll need to make a commitment. The transaction
contains two outputs, one to the reserve pool containing the funds that can
only be reclaimed when you go back to normal and one CT-output that you can
start doing CT transactions from.
I believe this could be made seamlessly with just a new bech32 address
specifically for CT. Sending to a CT address could be done as easily as
sending to a P2SH. In other words, it doesn't have to be two steps to send
to someone over at CT space.

> It is "evil" soft fork since older nodes are forced to upgrade as their
intended functionality becomes impossible.
> In this point-of-view, it is no better than a hard fork, which at least
is very noisy about how older fullnode versions will simply stop working.

Regarding normal extension blocks, I think it is definitely better than a
hardfork since there's no way to be derailed from the network, even though
you do not understand the rules fully.

Sidenote, I think Trey Del Bonis is right regarding the terminology here,
evil softforks/soft hardforks usually mean that you abandon the old chain
to force all nodes to upgrade (https://petertodd.org/2016/forced-soft-forks
).

Best
Hampus

Den tis 12 feb. 2019 kl 13:49 skrev ZmnSCPxj via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> Good morning Kenshiro,
>
> > - Soft fork: old nodes see CT transactions as "sendtoany" transactions
>
> There is a position that fullnodes must be able to get a view of the UTXO
> set, and extension blocks (which are invisible to pre-extension-block
> fullnodes) means that fullnodes no longer have an accurate view of the UTXO
> set.
> SegWit still provides pre-SegWit fullnodes with a view of the UTXO set,
> although pre-SegWit fullnodes could be convinced that a particular UTXO is
> anyone-can-spend even though they are no longer anyone-can-spend.
>
> Under this point-of-view, then, extension block is "not" soft fork.
> It is "evil" soft fork since older nodes are forced to upgrade as their
> intended functionality becomes impossible.
> In this point-of-view, it is no better than a hard fork, which at least is
> very noisy about how older fullnode versions will simply stop working.
>
> > - Safe: if there is a software bug in CT it's impossible to create new
> coins because the coins move from normal block to normal block as public
> transactions
>
> I think more relevant here is the issue of a future quantum computing
> breach of the algorithms used to implement confidentiality.
>
> I believe this is also achievable with a non-extension-block approach by
> implementing a globally-verified publicly-visible counter of the total
> amount in all confidential transaction outputs.
> Then it becomes impossible to move from confidential to public
> transactions with a value more than this counter, thus preventing inflation
> even if a future QC breach allows confidential transaction value
> commitments to be opened to any value.
>
> (do note that a non-extension-block approach is a definite hardfork)
>
> > - Capacity increase: the CT signature is stored in the extension block,
> so CT transactions increase the maximum number of transactions per block
>
> This is not an unalloyed positive: block size increase, even via extension
> block, translates to greater network capacity usage globally on all
> fullnodes.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20190214/a82b2025/attachment.html>;

📅 Original date posted:2017-12-19 📝 Original message:Most ...

2023-06-07T18:08:02Z

In reply to nevent1q…4sfc
_________________________

📅 Original date posted:2017-12-19
📝 Original message:Most solutions only work with a single Bitcoin address (terrible for
privacy, and also potentially a security risk) or xpubkey (also terrible
for privacy).

I think the best solution here is some kind of store-and-forward server,
where you trade a little bit of privacy (to the server, that is), but get
the convenience of using (for example) an email address as the account.
I like for example BIP75 for this, and I hope the community can work
towards a solution like this. This could potentially work good with LN as
well. https://github.com/bitcoin/bips/blob/master/bip-0075.mediawiki

Hampus

2017-12-19 10:05 GMT+01:00 Damian Williamson via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> There is no reason it should not be easily possible to develop a Bitcoin
> wallet that has an integrated name to address mapping feature. It might be
> a good idea for a software product, it could even be based on Bitcoin Core.
> There is no specific reason that people wanting that sort of feature could
> not use it. In fact, you could map names, strings, email addresses, it
> could be very flexible.
>
>
> Relying on an additional service like DNS which is flexible enough to
> handle the job, does introduce an additional availability risk. There is no
> additional privacy risk provided each mapped name or address is only used
> once to send/receive one payment unless you directly use something
> personally identifiable like an email address which could be used to map
> bitcoin addresses to an individual. Personally, I am not concerned about
> privacy so much but can understand that some highly value their privacy.
>
>
> If you get it right it will be a service better than namecoin transacting
> in Bitcoin. If you think that is valuable, go for it.
>
>
> Regards,
>
> Damian Williamson
>
>
> ------------------------------
> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org <
> bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Sjors
> Provoost via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Monday, 18 December 2017 10:26 PM
> *To:* Douglas Roark; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet
> addresses?
>
> Have you thought about combining this with BIP-47? You could associate
> payment codes with email via DNS.
>
> It would be nice if there was a way to get rid of the announcement
> transaction in BIP-47 and establish a shared secret out of bound. That
> would simplify things, at the cost of an additional burden of storing more
> than an HD seed to recover a wallet that received funds this way.
>
> Perhaps the sender can email to the recipient the information they need to
> retrieve the funds. The (first) transaction could have a time locked refund
> in it, in case the payment code is stale.
>
> Sjors
>
> > Op 1 dec. 2017, om 04:08 heeft Douglas Roark via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> het volgende geschreven:
> >
> > On 2017/11/30 14:20, mandar mulherkar via bitcoin-dev wrote:
> >> I was wondering in terms of mass adoption, instead of long wallet
> >> addresses, maybe there should be a DNS-like decentralized mapping
> >> service to provide a user at crypto address?
> >
> > A few years ago, I was part of an effort with Armory and Verisign to
> > make something similar to what you're describing.
> > https://tools.ietf.org/html/draft-wiley-paymentassoc-00 is where you can
> > find the one and only official draft. I worked on a follow-up with some
> > changes and some nice appendices, explaining some nice tricks one could
> > use to make payment management flexible. For various reasons, it never
> > got published. I think it's an interesting draft that could be turned
> > into something useful. Among other things, it was able to leverage BIP32
> > and allow payment requests to be generated that automatically pointed
> > payees to the correct branch. DNSSEC may have some issues but, AFAIK,
> > it's as the easiest way to bootstrap identity to a common, reasonably
> > secure standard.
> >
> > --
> > ---
> > Douglas Roark
> > Cryptocurrency, network security, travel, and art.
> > https://onename.com/droark
> > joroark at vt.edu
> > PGP key ID: 26623924
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> 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/20171219/cbaee39b/attachment-0001.html>;

📅 Original date posted:2017-11-03 📝 Original message:Thank ...

2023-06-07T18:07:29Z

In reply to nevent1q…llcz
_________________________

📅 Original date posted:2017-11-03
📝 Original message:Thank you for your answer, Russel.

When a code path takes advantage of a jet, does the Simplicity code still
need to be publicly available/visible in the blockchain? I imagine that for
big algorithms (say for example EDCA verification/SHA256 hashing etc), it
would take up a lot of space in the blockchain.
Is there any way to mitigate this?

I guess in a softfork for a jet, the Simplicity code for a jet could be
defined as "consensus", instead of needed to be provided within every
script output.
When the Simplicity interpretor encounters an expression that has a jet, it
would run the C/Assembly code instead of interpreting the Simplicity code.
By formal verification we would be sure they match.

Greetings
Hampus

2017-11-03 2:10 GMT+01:00 Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> Hi Jose,
>
> Jets are briefly discussed in section 3.4 of https://blockstream.com/
> simplicity.pdf
>
> The idea is that we can recognize some set of popular Simplicity
> expressions, and when the Simplicity interpreter encounters one of these
> expressions it can skip over the Simplicity interpreter and instead
> directly evaluate the function using specialized C or assembly code.
>
> For example, when the Simplicity interpreter encounters the Simplicity
> expression for ECDSA verification, it might directly call into libsecp
> rather than continuing the ECDSA verification using interpreted Simplicity.
>
> HTH.
>
>
> On Nov 2, 2017 18:35, "JOSE FEMENIAS CAÑUELO via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi,
>
> I am trying to follow this Simplicity proposal and I am seeing all over
> references to ‘jets’, but I haven’t been able to find any good reference to
> it.
> Can anyone give me a brief explanation and or a link pointing to this
> feature?
> Thanks
>
> On 31 Oct 2017, at 22:01, bitcoin-dev-request at lists.linuxfoundation.org
> wrote:
>
> The plan is that discounted jets will be explicitly labeled as jets in the
> commitment. If you can provide a Merkle path from the root to a node that
> is an explicit jet, but that jet isn't among the finite number of known
> discounted jets,
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> 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/20171103/e9a5e8b1/attachment-0001.html>;

📅 Original date posted:2017-09-07 📝 Original ...

2023-06-07T18:05:25Z

In reply to nevent1q…l9nd
_________________________

📅 Original date posted:2017-09-07
📝 Original message:Forbidding 0 satoshi outputs (I wasn't actually aware that it was possible,
is 0 satoshi inputs also allowed?) would complicate a divisibility increase
softfork (I'm working on an idea for >= 1 satoshi transactions, but now it
seems like < 1 satoshi transactions would work too).

I don't think it's a good idea to deploy this softfork.

Hampus

2017-09-07 5:41 GMT+02:00 CryptAxe via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> After reading
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2016-January/012194.html
> I see that Adam is correct. Unfortunately this SF would make Felix's
> confidential transactions
> more complicated. The blinding and unblinding transactions would have to
> be created with
> minimal output values, and this will need to be considered when checking
> that the fee is equal
> to the total amount of input. (it would now be SUM(inputs) -
> SUM(minimalOutputs))
>
> Blinding transaction:
> Ins:
> All non-confidential inputs are valid
> Outs:
> - 0..N: (new confidential outputs)
> amount: 0
> scriptPubkey: OP_2 <0x{32-byte-hash-value}>
> witnessOut: <0x{petersen-commitment}> <0x{range-proof}>
> - last:
> amount: 0
> scriptPubkey: OP_RETURN OP_2 {blinding-fee-amount}
> Fee: Sum of the all inputs value
>
>
> However, looking at the format of the blinding transaction, and how the
> GCTXO is added to the UTXO set
> by miners, it seems that a change to the blinding scriptPubKey could
> allow for the use of 0 value
> outputs. Even with the SF proposed by this email thread.
>
> OP_RETURN could be added to the scriptPubKey during blinding. The amount
> and scriptPubKey destination of
> unblinded funds is part of the witness and the outputs of an unblinded
> transaction are unspendable, so
> why not also make them unspendable in the blind transaction? As far as I
> can tell those outputs don't need to
> be spendable, they are really just encoding data. It doesn't seem like
> anything besides the confidential base
> transaction and the fee output from the blind transaction need to be in
> the UTXO set.
>
> Is it still possible to add this data to the witness if the scriptPubKey
> is unspendable? :
>
> witnessOut: <0x{petersen-commitment}> <0x{range-proof}>
>
> I think I'm missing something obvious, someone point out why this is
> stupid please :)
>
> On 09/06/2017 06:29 PM, Adam Back wrote:
> > The pattern used by Felix Weiss' BIP for Confidential Transactions
> > depends on or is tidier with 0-value outputs.
> >
> > Adam
> >
> >
> > On 7 September 2017 at 00:54, CryptAxe via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> As long as an unspendable outputs (OP_RETURN outputs for example) with
> >> amount=0 are still allowed I don't see it being an issue for anything.
> >>
> >> On Sep 5, 2017 2:52 PM, "Jorge Timón via bitcoin-dev"
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>> This is not a priority, not very important either.
> >>> Right now it is possible to create 0-value outputs that are spendable
> >>> and thus stay in the utxo (potentially forever). Requiring at least 1
> >>> satoshi per output doesn't really do much against a spam attack to the
> >>> utxo, but I think it would be slightly better than the current
> >>> situation.
> >>>
> >>> Is there any reason or use case to keep allowing spendable outputs
> >>> with null amounts in them?
> >>>
> >>> If not, I'm happy to create a BIP with its code, this should be simple.
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev at lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
>
> _______________________________________________
> 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/20170907/52539276/attachment.html>;

📅 Original date posted:2017-07-13 📝 Original message:In ...

2023-06-07T18:04:36Z

In reply to nevent1q…7cm5
_________________________

📅 Original date posted:2017-07-13
📝 Original message:In softforks, I would argue that 100% of all nodes and miners need to
upgrade to the new rules.
This makes sure that trying to incorrectly spend an "AnyOneCanSpend" will
result in a hardfork, instead of a temporary (or permanent) chainsplit.

With drivechains, it seems like the current plan is to only let the nodes
that are interested in the drivechain validate the other chain, and not
necessarily 100% of the network.
I guess this could be any percentage of the network, which could lead to a
temporary/permanent chainsplit depending on how many percentage of the
miners are also validating the other chain (am I missing something here?).

I have no way to evaluate if this is an okay trade-off.
It seems like major disruption could very likely happen if say only 5% of
all fullnodes validate the drivechain.

To be fully secure, it seems like 100% of all nodes should also have a
fullnode for the drivechain as well...
This is one of the reasons I don't advocate sidechains/drivechains as a
scaling solution, it looks like it would have to the same outcome as a
blocksize increase on the mainchain, but with more complexity.
I think sidechains/drivechains could be useful for other things though.

Thanks for all your work so far Paul.
Hampus

2017-07-13 4:58 GMT+02:00 Paul Sztorc via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> I will repeat that Drivechain can sometimes be confusing because it is
> different things to different people.
>
> Here is my attempt to break it down into different modes:
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is
> running, say, 0.13). However, they experience the effects of the new rules
> which miners add (as per the soft fork[s] to add drivechain functionality
> and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin
> software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides
> to also become a full node of one or more sidechains, but who ever actually
> uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes,
> and actively moves money to and from these.
>
> Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he
> equivocates on the team "steal", using it to mean two different things: [a]
> spending an invalid transaction, and [b] a withdrawal that would not match
> the report given by a sidechain node.
>
> The two are quite different, see my comments below:
>
>
> On 7/12/2017 9:15 PM, Tao Effect wrote:
>
> FYI that document is nearly two years old, and although it is still
> overwhelmingly accurate, new optimizations allow us (I think) to push the
> waiting period to several weeks and the total ACK counting period up to
> several months.
>
> What does that have to do with my question? The counting period, if I
> understood correctly, is something miners do, not full nodes.
>
>
> Greg quoted a passage that contained an older parameter estimate of "a few
> days", and I thought it would be helpful and informative if I clarified
> that the parameter estimate had been updated to a new (more secure) value.
>
> In point of fact, he is wrong, because nodes do the counting. When miners
> find a block, they can choose to move the counter up, down, or not at all.
> But nodes do the counting.
>
>
> Also, if the document is old and/or outdated, do you happen to have a link
> to a more update-to-date version of the spec? It would be helpful for
> review.
>
>
> As I stated above, the document is mostly accurate. There is no other more
> up to date version.
>
>
> Because if a node doesn't have the sidechain's information, it will just
> assume every withdrawal is valid. This is comparable to someone who still
> hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
>
> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as
> "Yes" without substantiating why you did so.
>
>
>
> Above, Greg omitted his original question. For reference, it was:
>
> The Drivechain spec seems to claim that its use of anyone-can-pay is the same as P2SH
>
>
> The answer is that both DC and P2SH use transactions which are 'always
> valid' to some group of people (un-upgraded users) but which are sometimes
> invalid to new users. So the only difference would be for [DC#0] vs other
> versions, but this difference is trivial as miners will censor invalid txns.
>
> It is your classic soft fork situation.
>
>
> Again, from the perspective of a mainchain user, every withdrawal is valid.
>
> And that is not how P2SH works.
>
>
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one
> calculated by sidechain nodes.
>
> The first case is exactly equal to P2SH. Just as old nodes accept every
> P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
>
> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would
> also accept any WT^ *that followed the Drivechain rules*, even if they did
> not like the outcome (because the outcome in question was arbitrarily
> designated as a "theft" of funds -- again, see the second case in the list
> above). In this way, it is exactly similar to P2SH because nodes will
> accept *any* p2sh txn **that follows the p2sh rules**, even if they don't
> "like" the specific script contained within (for example, because it is a
> theft of "their" BitFinex funds, or a donation to a political candidate
> they dislike, etc).
>
>
> [DC#2] and [DC#3] would certainly have an interest in understanding what
> is going on, but that has absolutely nothing whatsoever to do with Bitcoin
> Core and so is off-topic for this mailing list.
>
> How is that an answer to my question?
>
>
> Greg is, of course, not entitled to an answer to irrelevant questions --
> just as he would not be entitled to an answer if he asked for my favorite
> color or my home address. And such answers would needlessly consume the
> mailing list's scarce time.
>
>
> What does "[DC#2] and [DC#3] would certainly have an interest in
> understanding what is going on" mean?
>
>
> It is clear to me that, if we are not clear on the basics first, we cannot
> hope to tackle anything intermediate. We will come back to this after
> clearing up soft fork part.
>
>
> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period.
>
>
> In DC, all upgraded nodes will reject invalid DC transactions, period.
>
>
> What exactly would [DC#2] and [DC#3] nodes do when faced with an invalid
> WT^ transaction — invalid in the sense that it contains funds which miners
> are stealing?
>
>
> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1]
> nodes do. This is what I mean by "every withdrawal is valid".
>
>
> Again, in P2SH miners cannot steal funds, because all full nodes have a
> fully automatic enforcement policy.
>
>
> In DC, miners cannot steal funds, because all full nodes have a fully
> automatic enforcement policy.
>
> However, DC *allows* users to choose to place some of their BTC at the
> relative mercy of the miners in creative ways, if they wish (as does P2SH
> -- someone could write a script which donates funds to miners, and then
> fund it... "paying" to that script). This is another example of conflating
> [DC#1] and [DC#3].
>
> Paul
>
>
>
>
> On Jul 12, 2017, at 5:26 PM, Paul Sztorc <truthcoin at gmail.com> wrote:
>
> The confusion below stems from his conflation of several different ideas.
>
> I will try to explicitly clarify a distinction between several types of
> user (or, "modes" of use if you prefer):
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is
> running, say, 0.13). However, they experience the effects of the new rules
> which miners add (as per the soft fork[s] to add drivechain functionality
> and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoin
> software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides
> to also become a full node of one or more sidechains, but who ever actually
> uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes,
> and actively moves money to and from these.
>
>
> On 7/12/2017 6:43 PM, Tao Effect wrote:
>
>
> I am now looking closer again at step number 4 in the Drivechain
> specification [2]:
>
> 4. Everyone waits for a period of, say, 3 days. This gives everyone an
> opportunity to make sure the same WT^ is in both the Bitcoin coinbase and
> the Sidechain header. If they’re different, everyone has plenty of time to
> contact each other, figure out what is going on, and restart the process
> until its right.
>
> It seems to me that where our disagreement lies is in this point.
> The Drivechain spec seems to claim that its use of anyone-can-pay is the
> same as P2SH (and in later emails you reference SegWit as well). Is this
> really true?
>
> FYI that document is nearly two years old, and although it is still
> overwhelmingly accurate, new optimizations allow us (I think) to push the
> waiting period to several weeks and the total ACK counting period up to
> several months.
>
> [DC#0] Yes
> [DC#1] Yes
> [DC#2] Yes
> [DC#3] Yes
>
> Because if a node doesn't have the sidechain's information, it will just
> assume every withdrawal is valid. This is comparable to someone who still
> hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
> (And this is the main advantage of DC over extension blocks).
>
>
> 2. Per the question in [1], it's my understanding that P2SH transactions
> contain all of the information within themselves for full nodes to act as a
> check on miners mishandling the anyone-can-spend nature of P2SH
> transactions. However, that does not seem to be the case with WT^
> transactions.
>
> [DC#0] They do.
> [DC#1] They do.
> [DC#2] They do.
> [DC#3] They do.
>
> Again, from the perspective of a mainchain user, every withdrawal is valid.
>
>
> In P2SH txns, there is no need for anyone to, as the Drivechain spec says,
> "to contact each other, figure out what is going on". Everything just
> automatically works.
>
> There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].
>
> [DC#2] and [DC#3] would certainly have an interest in understanding what
> is going on, but that has absolutely nothing whatsoever to do with Bitcoin
> Core and so is off-topic for this mailing list.
>
>
> If the security of WT^ transactions could be brought up to actually be in
> line with the security of P2SH and SegWit transactions, then I would have
> far less to object to.
>
> Somehow I doubt it.
>
>
> Paul
>
>
>
>
> _______________________________________________
> 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/20170713/e9634ea7/attachment-0001.html>;

📅 Original date posted:2017-07-14 📝 Original message:> ...

2023-06-07T18:04:27Z

In reply to nevent1q…hc85
_________________________

📅 Original date posted:2017-07-14
📝 Original message:> sounds good, though I'm unclear on how exactly to achieve (2) given that
any party I have ever transacted with (or otherwise knows an address of
mine) can send me coins at any time. So it seems the only possible way
to be certain is to run a node that has never published an address to a
3rd party. Is that accurate?

Yes, as soon as you receive new Bitcoins, there's a chance that they have
been in a SegWit transaction at some point.
I'm not sure if you can see the chain of transactions for an address in
bitcoin-cli, but if that is possible, you should be able to double check
the transaction types.

> Another thing that could be done is to modify my own node so that it
actually rejects such tx, but then I have modified consensus rules
myself, thus defeating the goal of remaining with status-quo rules, and
anyway the rest of the network would accept the tx. I guess the benefit
is that I could be certain of the remaining funds I have.

Hmm yes, if you reject a such transaction, you'll hardfork the network.
If you ignore it in your wallet, you'll be safe, but you'll lose those
bitcoins ofc.
It's a difficult situation.

> I suppose that it would be possible without modifying any rule to
construct a "certain balance" and an "uncertain balance".

Should be possible.

> Hampus, thanks for the explanation!

You're welcome!
I personally very much like and want SegWit, but I respect people that
wants to maintain the status quo, it's what will make Bitcoin strong in the
long run.

Cheers
Hampus

2017-07-14 1:20 GMT+02:00 Dan Libby via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> Hampus, thanks for the explanation!
>
> On 07/13/2017 03:50 PM, Hampus Sjöberg wrote:
>
> > Yes.
> > So you have two choices to be fully secure:
> > 1. Validate using the new rules of the network (in other words, run a
> > SegWit node)
> > 2. Avoid any chain of transaction that contains a SegWit transaction
>
> sounds good, though I'm unclear on how exactly to achieve (2) given that
> any party I have ever transacted with (or otherwise knows an address of
> mine) can send me coins at any time. So it seems the only possible way
> to be certain is to run a node that has never published an address to a
> 3rd party. Is that accurate?
>
> Another thing that could be done is to modify my own node so that it
> actually rejects such tx, but then I have modified consensus rules
> myself, thus defeating the goal of remaining with status-quo rules, and
> anyway the rest of the network would accept the tx. I guess the benefit
> is that I could be certain of the remaining funds I have.
>
> I suppose that it would be possible without modifying any rule to
> construct a "certain balance" and an "uncertain balance".
>
> I don't intend to do such modifications! just grasping for understanding.
>
>
> > See
> > https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_
> compatibility
> > So the witness program is encoded in a new format that old nodes do not
> > understand.
> > This means that for old nodes, a number >0 will be put on the stack.
> > When the script is done, it will be evaluated to true (because of >0)
> > and be counted as a valid spend.
> >
> > https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also
> > explains the new witness program more in detail (I left out some details
> > in my explanation).
>
> I read the relevant parts, thanks!
> _______________________________________________
> 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/20170714/817caf42/attachment-0001.html>;

📅 Original date posted:2017-07-13 📝 Original message:> I ...

2023-06-07T18:04:27Z

In reply to nevent1q…t42p
_________________________

📅 Original date posted:2017-07-13
📝 Original message:> I would like to understand it a bit better, as I think it applies
equally to any pre-segwit node, yes? So let's say I am running 0.13.0
and someone sends me bitcoins to a P2PKH address, but that person
previously received them to a P2WPKH address.

Yes, this applies to all non-SegWit nodes.

> If I understand correctly, my node will accept the incoming tx inputs
but obviously will not perform any segwit related validation, thus those
inputs are not fully validated.

Yes.
So you have two choices to be fully secure:
1. Validate using the new rules of the network (in other words, run a
SegWit node)
2. Avoid any chain of transaction that contains a SegWit transaction

> I don't yet understand how my node
thinks they are valid at all given that it does not understand P2WPKH
address format, so either it doesn't need to, or P2WPKH is somehow
already valid.

So how softforks often work is that you make the transaction appear to be
always spendable for old nodes, regardless if it really was spendable or
not. This will make sure it is a softfork, the update is backwards
compatible.
If it would be the other way around, if new rules that the node doesn't
understand would always be invalid, it would be hardfork, which is what
we're trying to avoid in the first place.

> so if
someone can point me towards a document that explains it I'd be happy to
read that.

See
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_compatibility
So the witness program is encoded in a new format that old nodes do not
understand.
This means that for old nodes, a number >0 will be put on the stack. When
the script is done, it will be evaluated to true (because of >0) and be
counted as a valid spend.

https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also
explains the new witness program more in detail (I left out some details in
my explanation).

Cheers
Hampus

2017-07-13 23:58 GMT+02:00 Dan Libby via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> On 07/13/2017 09:35 AM, Jameson Lopp wrote:
> >
> >
> > On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org
> > <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
> >
> > On 07/13/2017 06:39 AM, Hampus Sjöberg via bitcoin-dev wrote:
> > >> I believe that a good reason not to wish your node to be segwit
> > > compliant is to avoid having to deal with the extra bandwidth that
> > > segwit could require. Running a 0.14.2 node means being ok with
> >1MB
> > > blocks, in case segwit is activated and widely used. Users not
> > > interested in segwit transactions may prefer to keep the cost of
> their
> > > node lower.
> > >
> > > If the majority of the network decides to deploy SegWit, it would
> be in
> > > your best interest to validate the SegWit transactions, because you
> > > might will be downgraded to near-SPV node validation.
> > > It would be okay to still run a "non-SegWit" node if there's no
> SegWit
> > > transactions in the chain of transactions for your bitcoins,
> otherwise
> > > you cannot fully verify the the ownership of your bitcoins.
> > > I'm not sure the practicality of this in the long run, but it
> makes a
> > > case for having an up-to-date non-SegWit node, although I think
> it's a
> > > bit of a stretch.
> >
> > Right. Well, if I never upgrade to segwit, then there seems little
> > (zero?) risk of having any segwit tx in my tx chain.
> >
> >
> > If you mean you wish to avoid receiving UTXOs that have value that was
> > at one point previously encumbered by a SegWit output then no, you can't
> > avoid that. No more than you can currently avoid receiving BTC that were
> > at one point in time encumbered by a P2SH output.
>
> fair enough. This actually wasn't an area I'd considered much before
> Hampus brought it up.
>
> I would like to understand it a bit better, as I think it applies
> equally to any pre-segwit node, yes? So let's say I am running 0.13.0
> and someone sends me bitcoins to a P2PKH address, but that person
> previously received them to a P2WPKH address.
>
> If I understand correctly, my node will accept the incoming tx inputs
> but obviously will not perform any segwit related validation, thus those
> inputs are not fully validated. I don't yet understand how my node
> thinks they are valid at all given that it does not understand P2WPKH
> address format, so either it doesn't need to, or P2WPKH is somehow
> already valid. I know this has all been discussed in the past, so if
> someone can point me towards a document that explains it I'd be happy to
> read that.
>
> thanks!
> _______________________________________________
> 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/20170714/6adac594/attachment-0001.html>;

📅 Original date posted:2017-07-13 📝 Original message:> I ...

2023-06-07T18:04:26Z

In reply to nevent1q…mn0u
_________________________

📅 Original date posted:2017-07-13
📝 Original message:> I believe that a good reason not to wish your node to be segwit compliant
is to avoid having to deal with the extra bandwidth that segwit could
require. Running a 0.14.2 node means being ok with >1MB blocks, in case
segwit is activated and widely used. Users not interested in segwit
transactions may prefer to keep the cost of their node lower.

If the majority of the network decides to deploy SegWit, it would be in
your best interest to validate the SegWit transactions, because you might
will be downgraded to near-SPV node validation.
It would be okay to still run a "non-SegWit" node if there's no SegWit
transactions in the chain of transactions for your bitcoins, otherwise you
cannot fully verify the the ownership of your bitcoins.
I'm not sure the practicality of this in the long run, but it makes a case
for having an up-to-date non-SegWit node, although I think it's a bit of a
stretch.

Greetings
Hampus

2017-07-13 15:11 GMT+02:00 Federico Tenga via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> On 13 July 2017 at 03:04, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> Can you explain why you wish to do this? It should have absolutely no
>> adverse impact on you-- if you don't use segwit, you don't use it-- it
>> may be the case that there is some confusion about the implications
>> that I could clear up for you... or suggest alternatives that might
>> achieve your goals.
>>
>
> I believe that a good reason not to wish your node to be segwit compliant
> is to avoid having to deal with the extra bandwidth that segwit could
> require. Running a 0.14.2 node means being ok with >1MB blocks, in case
> segwit is activated and widely used. Users not interested in segwit
> transactions may prefer to keep the cost of their node lower.
>
> _______________________________________________
> 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/20170713/17df3337/attachment.html>;

📅 Original date posted:2017-07-05 📝 Original ...

2023-06-07T18:03:58Z

In reply to nevent1q…tgxs
_________________________

📅 Original date posted:2017-07-05
📝 Original message:>From the PR change:

> Miners must continue setting the bit in LOCKED_IN phase so uptake is
visible and acknowledged. Blocks without the applicable bit set are invalid
during this period

Luke, it seems like the amendments to BIP8 make it drastically different to
how it first was designed to work.
It now looks more akin to BIP148, which was AFAICT not how BIP8 was
originally intended to work.
Perhaps this should be made into its own BIP instead, or make it so it's
possible to decide how the LOCKED_IN state should work when designing the
softfork.

Hampus

2017-07-05 6:10 GMT+02:00 Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> It's not pointless: it's a wake-up call for miners asleep "at the wheel",
> to
> ensure they upgrade in time. Not having a mandatory signal turned out to
> be a
> serious bug in BIP 9, and one which is fixed in BIP 148 (and remains a
> problem
> for BIP 149 as-is). Additionally, it makes the activation decisive and
> unambiguous: once the lock-in period is complete, there remains no
> question as
> to what the correct protocol rules are.
>
> It also enables deploying softforks as a MASF, and only upgrading them to
> UASF
> on an as-needed basis.
>
> Luke
>
>
> On Wednesday 05 July 2017 4:00:38 AM shaolinfry wrote:
> > Luke,
> > I previously explored an extra state to require signalling before
> > activation in an earlier draft of BIP8, but the overall impression I got
> > was that gratuitous orphaning was undesirable, so I dropped it. I
> > understand the motivation behind it (to ensure miners are upgraded), but
> > it's also rather pointless when miners can just fake signal. A properly
> > constructed soft fork is generally such that miners have to deliberately
> > do something invalid - they cannot be tricked into it... and miners can
> > always chose to do something invalid anyway.
> >
> > > -------- Original Message --------
> > > From: luke at dashjr.org
> > > To: bitcoin-dev at lists.linuxfoundation.org, shaolinfry
> > > <shaolinfry at protonmail.ch> I"ve already opened a PR almost 2 weeks ago
> > > to do this and fix the other issues BIP 9 has.
> > > https://github.com/bitcoin/bips/pull/550
> > > It just needs your ACK to merge.
> > >
> > > On Wednesday 05 July 2017 1:30:26 AM shaolinfry via bitcoin-dev wrote:
> > >> Some people have criticized BIP9"s blocktime based thresholds arguing
> > >> they are confusing (the first retarget after threshold). It is also
> > >> vulnerable to miners fiddling with timestamps in a way that could
> > >> prevent or delay activation - for example by only advancing the block
> > >> timestamp by 1 second you would never meet the threshold (although
> this
> > >> would come a the penalty of hiking the difficulty dramatically). On
> the
> > >> other hand, the exact date of a height based thresholds is hard to
> > >> predict a long time in advance due to difficulty fluctuations.
> However,
> > >> there is certainty at a given block height and it"s easy to monitor.
> If
> > >> there is sufficient interest, I would be happy to amend BIP8 to be
> > >> height based. I originally omitted height based thresholds in the
> > >> interests of simplicity of review - but now that the proposal has been
> > >> widely reviewed it would be a trivial amendment.
> _______________________________________________
> 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/20170705/31aaca40/attachment-0001.html>;

📅 Original date posted:2017-06-20 📝 Original message:> I ...

2023-06-07T18:03:33Z

In reply to nevent1q…r749
_________________________

📅 Original date posted:2017-06-20
📝 Original message:> I think it would be useful for there to exist a useful and trivial
> patch against current (0.14.2) software to engage in the BIP91-like
> orphaning, like people have provided for BIP148-- but right now I
> don't see any specification of the behavior so it's unclear to me
> _exactly_ what it would need to implement to be consistent.

I agree.
This is the latest code regarding BIP91 that got merged,
https://github.com/btc1/bitcoin/pull/21/files so that should be the spec we
need to follow (also the old BIP91 PR:
https://github.com/btc1/bitcoin/pull/17/files).
Perhaps James Hilliard could give input here though.

2017-06-21 0:34 GMT+02:00 Gregory Maxwell <greg at xiph.org>:

> On Tue, Jun 20, 2017 at 10:15 PM, Hampus Sjöberg
> <hampus.sjoberg at gmail.com> wrote:
> > Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
> > BIP148) node, because they wouldn't have the new consensus rule of
> requiring
> > all blocks to signal for segwit.
>
> All versions of Bitcoin Core since 0.13.1 signal segwit, 0.14.1+ even
> when downstream mining software doesn't support it.
>
> I think it would be useful for there to exist a useful and trivial
> patch against current (0.14.2) software to engage in the BIP91-like
> orphaning, like people have provided for BIP148-- but right now I
> don't see any specification of the behavior so it's unclear to me
> _exactly_ what it would need to implement to be consistent.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170621/d51a368b/attachment.html>;

📅 Original date posted:2017-06-20 📝 Original message:I ...

2023-06-07T18:03:26Z

In reply to nevent1q…vqmj
_________________________

📅 Original date posted:2017-06-20
📝 Original message:I don't think it's a huge deal if the miners need to run a non-Core node
once the BIP91 deployment of Segwit2x happens. The shift will most likely
be temporary.

I agree that the "-bip148"-option should be merged, though.

2017-06-20 17:44 GMT+02:00 Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> Are we going to merge BIP91 or a -BIP148 option to core for inclusion in
> the next release or so?
>
> Because a large percentage of miners are indifferent, right now miners
> have to choose between BIP148 and Segwit2x if they want to activate Segwit.
>
>
> Should we be forcing miners to choose to run non-core code in order to
> activate a popular feature?
>
> - Erik
>
> _______________________________________________
> 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/20170620/dcdeace9/attachment.html>;

📅 Original date posted:2017-06-20 📝 Original message:> ...

2023-06-07T18:03:26Z

In reply to nevent1q…2ndm
_________________________

📅 Original date posted:2017-06-20
📝 Original message:> Ironically, it looks like most of the segwit2x signaling miners are
> faking it (because they're not signaling segwit which it requires).
> It'll be unfortunate if some aren't faking it and start orphaning
> their own blocks because they are failing to signal segwit.

Well, they're doing some kind of "pre-signaling" in the coinbase at the
moment, because the segwit2x project is still in alpha-phase according to
the timeline. They're just showing commitment.
I'm sure they will begin signaling on version bit 4/BIP91 as well as
actually running a segwit2x node when the time comes.

> As far as prevent a chain split goes, all those things
> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
> don't think that holds.

Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
BIP148) node, because they wouldn't have the new consensus rule of
requiring all blocks to signal for segwit.
I don't believe there would be any long lasting chainsplit though (because
of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks if we get
unlucky.

Hampus

2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Because a large percentage of miners are indifferent, right now miners
> have
> > to choose between BIP148 and Segwit2x if they want to activate Segwit.
>
> Miners can simply continuing signaling segwit, which will leave them
> at least soft-fork compatible with BIP148 and BIP91 (and god knows
> what "segwit2x" is since they keep changing the actual definition and
> do not have a specification; but last I saw the near-term behavior the
> same as BIP91 but with a radically reduced activation window, so the
> story would be the same there in the near term).
>
> Ironically, it looks like most of the segwit2x signaling miners are
> faking it (because they're not signaling segwit which it requires).
> It'll be unfortunate if some aren't faking it and start orphaning
> their own blocks because they are failing to signal segwit.
>
> I don't think the rejection of segwit2x from Bitcoin's developers
> could be any more resolute than what we've already seen:
> https://en.bitcoin.it/wiki/Segwit_support
>
> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I think it is very naïve to assume that any shift would be temporary.
> > We have a hard enough time getting miners to proactively upgrade to
> > recent versions of the reference bitcoin daemon. If miners interpret
> > the situation as being forced to run non-reference software in order
> > to prevent a chain split because a lack of support from Bitcoin Core,
> > that could be a one-way street.
>
> I think this is somewhat naive and sounds a lot like the repeat of the
> previously debunked "XT" and "Classic" hysteria.
>
> There is a reason that segwit2x is pretty much unanimously rejected by
> the technical community. And just like with XT/Classic/Unlimited
> you'll continue to see a strong correlation with people who are
> unwilling and unable to keep updating the software at an acceptable
> level of quality-- esp. because the very founding on their fork is
> predicated on discarding those properties.
>
> If miners want to go off and create an altcoin-- welp, thats something
> they can always do, and nothing about that will force anyone to go
> along with it.
>
> As far as prevent a chain split goes, all those things
> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
> don't think that holds.
> _______________________________________________
> 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/20170621/0d0761cf/attachment.html>;

📅 Original date posted:2017-05-22 📝 Original ...

2023-06-07T18:01:22Z

In reply to nevent1q…vnzk
_________________________

📅 Original date posted:2017-05-22
📝 Original message:I'm really happy to see people trying to cooperate to get SegWit activated.
But I'm really unsure about the technicalities about Silbert's proposal.

If we're going to do a hardfork, it makes most sense to assist Johnson in
his spoonnet/forcenet proposals.
Just doing a simple 2MB without fixing anything else is very uninteresting,
and a hardfork without addressing replay protection seems really
unprofessional to me.
And proposing a hardfork in 4 months in the future, is completely insane.
You cannot expect a 100% of all nodes in P2P network to upgrade in 4 months.

I think it's much better to activate BIP141 ASAP, and then hardfork to 2MB
September 2018, or 2019 (together with forcenet/spoonnet).
And if not, BIP148 is gaining momentum once again so that sounds much more
interesting.

Hampus

2017-05-22 8:12 GMT+02:00 shaolinfry via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> Someone sent me a copy of the Barry Silbert agreement, an agreement forged
> between a select number of participants https://pastebin.com/VuCYteJh
>
> Participants agree to immediately activate Segwit, however, under a
> different activation proposal. Since I have spent the last few months
> researching various activation strategies of the current BIP141 deployment,
> as well as redeployment, I feel I am quite well placed to comment on the
> technicalities.
>
> To be clear, the proposal as far as I can see does not activate BIP141,
> but is a completely new deployment which would be incompatible with the
> BIP141 deployment. I'm not sure how that can be considered "immediate"
> activation. Surely immediate activation would just be for miners to start
> signalling and segwit would be activated in 4-5 weeks. The proposal seems
> to require a lower 80% threshold, I assume because they were unable to
> convince 95% of the hashpower to go trigger activation.
>
> There are a few options to activating segwit now, the first being for 95%
> of hashrate to signal. The second is for the community to deploy BIP148
> UASF which will force miners to signal segwit. Being a UASF it is date
> triggered. The third option is a redeployment of segwit on a new bit, but
> requires waiting for the existing deployment to time out, because all the
> p2p messages and service bits related to segwit must be replaced too (which
> is what BIP149 does).
>
> A fourth option, first suggested to me by James Hilliard, was to make
> BIP148 miner triggered (MASF) with a lower threshold, above 50%. I coded
> this up a few weeks ago https://github.com/bitcoin/
> bitcoin/compare/master...shaolinfry:segsignal but didnt get around to
> posting to the ML yet. This effectively lowers the threshold from 95% to
> 65% as coded, or could be upped to 80% or whatever was preferable.
>
> I think this removes the primary risk of BIP148 causing the creation of
> two chains, and gives an improved chance to get segwit activated quickly
> (assuming a majority of miners wish to go this route). But hash a primary
> disadvantage of still leaving the activation in the hands of miners. If it
> doesn't work out, then BIP149 can then be used as proposed, but it'll be
> even safer because we'll have futher guaged support.
>
> References:
>
> SEGSIGNAL: https://github.com/bitcoin/bitcoin/compare/master...
> shaolinfry:segsignal
> BIP148: https://github.com/bitcoin/bips/blob/master/bip-0148.mediawiki
> BIP149: https://github.com/bitcoin/bips/blob/master/bip-0149.mediawiki
>
> I think the Barry Silbert agreement is very ill considered, and clearly
> lacking peer review from the technical community. Suggestions of a HF in 4
> months are completely unrealistic and without technical merits. But more
> importantly, closed door agreements between selected participants is not
> how to garner consensus to change a $30bn decentralized system. The purpose
> of my email is to try and assist in the "immediate activation of segwit"
> which only requires hashrate to participate; and to provide some techincal
> input since I have done a great deal of research and development into the
> topic.
>
> Given the history we've already passed the point where we should be
> expecting miners to cooperate in lowering their own fee income with a
> capacity increase; but we should be open to all reasonable options in the
> interest in moving things forward in a safe and collaborative way.
>
> _______________________________________________
> 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/20170522/e17e2ba4/attachment.html>;

📅 Original date posted:2017-05-19 📝 Original ...

2023-06-07T18:01:19Z

In reply to nevent1q…7t37
_________________________

📅 Original date posted:2017-05-19
📝 Original message:AFAICT, re-enabling these old OP-codes would require a hardfork.

If we had SegWit enabled, we could via a soft fork allocate new OP-codes
for the same functionality (by introducing a new version of Script).
I believe the Elements alpha project has been experimenting with
re-enabling old OP-codes: https://elementsproject.org/elements/opcodes/

2017-05-19 8:07 GMT+02:00 Mark Boldyrev via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> Back in 2010, there was a bug found in Core which allowed
> denial-of-service attacks due to the software crashing on some machines
> while executing a script - see CVE-2010-537.
> I believe the removed ("disabled") opcodes should be re-introduced along
> with a standardized behavior definition.
> For example, when execution of an opcode results in an arithmetic error,
> such as OP_DIV with a zero divisor, the script should exit and fail.
> The string splice opcodes should also check their arguments for
> correctness, etc.
>
> These opcodes would enhance the flexibility of scripts and allow
> sophisticated native smart contracts to be created.
>
> _______________________________________________
> 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/20170519/9dd5d326/attachment.html>;

📅 Original date posted:2017-05-23 📝 Original message:> ...

2023-06-07T18:00:41Z

In reply to nevent1q…4q0z
_________________________

📅 Original date posted:2017-05-23
📝 Original message:> Who are we protecting users from, themselves? Are you protecting core?
from what? I am somewhat genuinely befuddled by those who can't even allow
a user config switch to be set.

Indeed. It seems silly. If you're activating the switch, you're most likely
fully aware of what you're doing.
I also saw some very harsh rhetoric being used against BIP148, which seems
unjustified as we have no idea yet how it all will play out. We can only
guess.

Hampus

2017-05-23 6:03 GMT+02:00 Steven Pine via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> I'm glad some discussion has been moved back here.
>
> Correct me if I am wrong, but currently core developers are arguing over
> whether or not to allow an optional configuration switch which defaults off
> but signals and enforces BIP148 when used. Who are we protecting users
> from, themselves? Are you protecting core? from what? I am somewhat
> genuinely befuddled by those who can't even allow a user config switch to
> be set.
>
> I guess I find it all incredibly silly, but perhaps I suffer from some
> basic confusion.
>
>
>
> On Mon, May 22, 2017 at 3:23 PM, Suhas Daftuar via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I also do not support the BIP 148 UASF, and I'd like to add to the points
>> that Greg has already raised in this thread.
>>
>> BIP 148 would introduce a new consensus rule that softforks out
>> non-segwit signalling blocks in some time period. I reject this consensus
>> rule as both arbitrary and needlessly disruptive. Bitcoin's primary
>> purpose is to reach consensus on the state of a shared ledger, and even
>> though I think the Bitcoin network ought to adopt segwit, I don't think
>> that concern trumps the goal of not splitting the network.
>>
>> Many BIP 148 advocates seem to start with the assumption that segwit
>> already has a lot of support, and suggest that BIP 148 does as well.
>> However I don't think it's fair or correct to separate the activation
>> proposal for segwit from the rest of the segwit proposal. The deployment
>> parameters for segwit are consensus-critical; assuming that some other
>> deployment has consensus because it would result in the rest of the segwit
>> proposal activating is an unjustified leap.
>>
>> Even if there were no feasible alternate segwit deployment method
>> available to us, I would hesitate to recommend that the network adopt a
>> potentially consensus-splitting approach, even though I firmly believe that
>> the ideas behind segwit are fundamentally good ones. But fortunately that
>> is not the situation we are in; we have substantially less disruptive
>> methods available to us to activate it, even if the current BIP 9
>> deployment were to fail -- such as another BIP 9 deployment in the future,
>> or perhaps a BIP 149 deployment.
>>
>> If we do pursue a "user-activated" deployment of segwit, I'd recommend
>> that we do so in a more careful way than BIP 148 or 149 currently suggest,
>> which as I understand would otherwise make very few changes to the current
>> implementation. However, due to the BIP 9 activation assumption, the
>> Bitcoin Core 0.13.1 - 0.14.0 segwit implementation largely lumps together
>> the idea that miners would both enforce the rules and mine segwit blocks.
>> However, we can separate these concerns, as we started to do in the Bitcoin
>> Core 0.14.1 release, where mining segwit blocks is not required in order to
>> generally mine or signal for segwit in the software. And we can go further
>> still: without too much work, we could make further improvements to
>> accommodate miners who, for whatever reason, don't want to upgrade their
>> systems, such as by improving block relay from pre-segwit peers [1], or
>> optimizing transaction selection for miners who are willing to enforce the
>> segwit rules but haven't upgraded their systems to mine segwit blocks [2].
>>
>> If we would seek to activate a soft-fork with less clear miner signaling
>> (such as BIP 149), then I think such improvements are warranted to minimize
>> network disruption. In general, we should not seek to censor hashpower on
>> the network unless we have a very important reason for doing so. While the
>> issues here are nuanced, if I were to evaluate the BIP 148 soft-fork
>> proposal on the spectrum of "censorship attack on Bitcoin" to "benign
>> protocol upgrade", BIP 148 strikes me as closer to the former than the
>> latter. There is simply no need here to orphan these non-signalling blocks
>> that could otherwise be used to secure the network.
>>
>> To go further: I think BIP 148 is ill-conceived even for achieving its
>> own presumed goals -- the motivation for adding a consensus rule that
>> applies to the version bits on blocks is surely for the effect such bits
>> have on older software, such as Bitcoin Core releases 0.13.1 and later.
>> Yet in trying to bring those implementations along as segwit-enforcing
>> software, BIP 148 would risk forking from such clients in the short term!
>> If one really cared about maintaining consensus with older, segwit-enabled
>> software, it would make far more sense to seek segwit activation in a way
>> that didn't fork from them (such as BIP 149, or a new BIP 9 deployment
>> after this one times out). And if one doesn't care about such consensus,
>> then it'd be far simpler to just set (e.g.) August 1 as the flag day
>> activation of segwit, and not play these contortionist games with block
>> version bits, which carry no useful or intrinsic meaning. Either of these
>> two approaches should have the advantage of reduced fork risk, compared
>> with BIP 148.
>>
>> Of course, everyone is free to run the software of their choosing. I
>> write this to both generally convey my opposition to a careless proposal,
>> which I believe represents a way of thinking that is detrimental to
>> Bitcoin's long run success, and specifically explain why I oppose inclusion
>> of this proposal in the Bitcoin Core implementation [3]. The Bitcoin Core
>> project hasn't been, and shouldn't be, careless in deploying consensus
>> changes. Instead, I think the Bitcoin Core project ought to stand up for
>> the best practices that our community has learned about how to deploy such
>> changes (specifically for minimizing chain-split risk when deploying a soft
>> fork!), and I think we should all avoid adoption or encouragement of
>> practices that would depart from the high standards we are capable of
>> achieving.
>>
>>
>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-
>> dev/2017-March/013811.html
>> [2] https://github.com/bitcoin/bitcoin/pull/9955
>> [3] https://github.com/bitcoin/bitcoin/pull/10428#issuecomment-303098925
>>
>>
>> --Suhas Daftuar
>>
>>
>> On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> I do not support the BIP148 UASF for some of the same reasons that I
>>> do support segwit: Bitcoin is valuable in part because it has high
>>> security and stability, segwit was carefully designed to support and
>>> amplify that engineering integrity that people can count on now and
>>> into the future.
>>>
>>> I do not feel the the approach proposed in BIP148 really measures up
>>> to the standard set by segwit itself, or the existing best practices
>>> in protocol development in this community.
>>>
>>> The primary flaw in BIP148 is that by forcing the activation of the
>>> existing (non-UASF segwit) nodes it almost guarantees at a minor level
>>> of disruption.
>>>
>>> Segwit was carefully engineered so that older unmodified miners could
>>> continue operating _completely_ without interruption after segwit
>>> activates.
>>>
>>> Older nodes will not include segwit spends, and so their blocks will
>>> not be invalid even if they do not have segwit support. They can
>>> upgrade to it on their own schedule. The only risk non-participating
>>> miners take after segwit activation is that if someone else mines an
>>> invalid block they would extend it, a risk many miners already
>>> frequently take with spy-mining.
>>>
>>> I do not think it is a horrible proposal: it is better engineered than
>>> many things that many altcoins do, but just not up to our normal
>>> standards. I respect the motivations of the authors of BIP 148. If
>>> your goal is the fastest possible segwit activation then it is very
>>> useful to exploit the >80% of existing nodes that already support the
>>> original version of segwit.
>>>
>>> But the fastest support should not be our goal, as a community-- there
>>> is always some reckless altcoin or centralized system that can support
>>> something faster than we can-- trying to match that would only erode
>>> our distinguishing value in being well engineered and stable.
>>>
>>> "First do no harm." We should use the least disruptive mechanisms
>>> available, and the BIP148 proposal does not meet that test. To hear
>>> some people-- non-developers on reddit and such-- a few even see the
>>> forced orphaning of 148 as a virtue, that it's punitive for
>>> misbehaving miners. I could not not disagree with that perspective any
>>> more strongly.
>>>
>>> Of course, I do not oppose the general concept of a UASF but
>>> _generally_ a soft-fork (of any kind) does not need to risk disruption
>>> of mining, just as segwit's activation does not. UASF are the
>>> original kind of soft-fork and were the only kind of fork practiced by
>>> Satoshi. P2SH was activated based on a date, and all prior ones were
>>> based on times or heights. We introduced miner based activation as
>>> part of a process of making Bitcoin more stable in the common case
>>> where the ecosystem is all in harmony. It's kind of weird to see UASF
>>> portrayed as something new.
>>>
>>> It's important the users not be at the mercy of any one part of the
>>> ecosystem to the extent that we can avoid it-- be it developers,
>>> exchanges, chat forums, or mining hardware makers. Ultimately the
>>> rules of Bitcoin work because they're enforced by the users
>>> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
>>> something people can count on: the rules aren't easy to just change.
>>>
>>> There have been some other UASF proposals that avoid the forced
>>> disruption-- by just defining a new witness bit and allowing
>>> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
>>> think they are vastly superior. They would be slower to deploy, but I
>>> do not think that is a flaw.
>>>
>>> We should have patience. Bitcoin is a system that should last for all
>>> ages and power mankind for a long time-- ten years from now a couple
>>> years of dispute will seem like nothing. But the reputation we earn
>>> for stability and integrity, for being a system of money people can
>>> count on will mean everything.
>>>
>>> If these discussions come up, they'll come up in the form of reminding
>>> people that Bitcoin isn't easily changed at a whim, even when the
>>> whims are obviously good, and how that protects it from being managed
>>> like all the competing systems of money that the world used to use
>>> were managed. :)
>>>
>>> So have patience, don't take short cuts. Segwit is a good improvement
>>> and we should respect it by knowing that it's good enough to wait for,
>>> and for however its activated to be done the best way we know how.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
> --
> Steven Pine
> (510) 517-7075
>
> _______________________________________________
> 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/20170523/0a7c89a0/attachment-0001.html>;

📅 Original date posted:2017-03-24 📝 Original message:> ...

2023-06-07T17:57:46Z

In reply to nevent1q…3z3k
_________________________

📅 Original date posted:2017-03-24
📝 Original message:> For example would be something like this:
> If block = (empty OR <%75 of mempool) THEN discard
> This threshold just an example

I don't think this is a good idea, mempool is different from node to node
and is not a part of the consensus.

Hampus

2017-03-24 18:29 GMT+01:00 Nick ODell via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> Two concerns:
>
> 1) This makes block validity depend on things that aren't in the
> blockchain. If you and I have different minrelaytxfee's, we will have
> different mempool sizes. Your node will discard a block, but my node will
> think it is valid, and our nodes will not come to consensus.
>
> 2) This is trivially bypassed. A miner can take some coins they own
> already, and create a zero-value transaction that has a scriptPubKey of
> OP_1. (i.e. anyone-can-spend.) Then, they create another transaction
> spending the first transaction, with an empty scriptSig, and the same
> scriptPubKey. They do this over and over until they fill up the block.
>
> The last OP_1 output can be left for the next miner. Since the above
> algorithm is deterministic, a merkle tree containing every transaction
> except the coinbase can be precomputed. The 'malicious' miners do not need
> to store this fake block.
>
> On Fri, Mar 24, 2017 at 10:03 AM, CANNON via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>
>> When the original white paper was written the idea was that nodes
>> would be miners at same time. That the distribution of mining power
>> being mostly on par with the distribution of nodes if I understand
>> correctly. The problem we face now I fear, is the mining power
>> becoming centralized. Even if every bitcoin node invested a $1000
>> into mining power and mined at a loss, it still would not even
>> make a dent in hash distribution. Currently there are around 6000
>> known nodes. If each node invested $1000 for say 10 ths of hashing
>> power. At current hashrate of around 3,674,473,142 GH/s this would
>> only make up %16 of hash power. This is out of balance as while
>> nodes are distributed mining power is becoming very centralized
>> due to the creation of monopolization of ASICs. The problem we
>> are facing is a small group of a couple people whom control a
>> large amount and growing of hash power. At time of this writing
>> it has quickly risen to 39% and at current rate will soon become
>> 50% of hashing power that is controlled by a small group of a few
>> people. Their intentions are too hijack the bitcoin network to a
>> cryptocurrency that suits their dangerous agenda. Dangerous because
>> their plan would centralize power of consensus as I understand it,
>> to themselves the miners. Dangerous also because the code base of
>> the attempting subverters is buggy, insecure, and reckless from a
>> technological standpoint. Even though they only have very minute
>> amount of nodes compared to legitimate bitcion nodes, the danger
>> is that they are very quickly taking over in mining power. While
>> it is true that nodes will not accept invalid blocks that would be
>> attempted to be pushed by the conspirators, they are threatening to
>> attack the valid (or in their words, "minority chain") by dedicating
>> some mining power soley to attacking the valid chain by mining empty
>> blocks and orphaning the valid chain. So even though the majority
>> of nodes would be enforcing what blocks are valid and as a result
>> block the non-compliant longer chain, the conspiring miner can simply
>> (as they are currently threatening to) make the valid chain unuseable
>> by mining empty blocks.
>>
>> If a malicious miner with half or majority control passes invalid
>> blocks, the worst case scenario is a hardfork coin split in which
>> the non-compliant chain becomes an alt. However the problem is that
>> this malicious miner is very recently threatening to not just simply
>> fork, but to kill the valid chain to force economic activity to the
>> adversary controlled chain. If we can simply defend against attacks
>> to the valid chain, we can prevent the valid chain from dying.
>>
>> While empty or near empty blocks would generally be protected by
>> the incentive of miners to make money. The threat is there if the
>> malicious miner with majority control is willing to lose out on
>> these transaction fees and block reward if their intention is to
>> suppress it to force the majority onto their chain.
>>
>> Proposal for potential solution Update nodes to ignore empty blocks,
>> so this way mined empty blocks cannot be used to DOS attack the
>> blockchain. But what about defense from say, blocks that are
>> not empty but intentionally only have a couple transactions
>> in it? Possible to have nodes not only ignore empty blocks,
>> but also blocks that are abnormally small compared to number of
>> valid transactions in mempool?
>>
>> For example would be something like this:
>> If block = (empty OR <%75 of mempool) THEN discard
>> This threshold just an example.
>>
>> What would be any potentials risks
>> and attacks resulting from both having such new rulesets and not
>> doing anything?
>>
>> Lets assume that the first problem of blocking empty or near empty
>> blocks has been mitigated with the above proposed solution. How
>> likely and possible would it be for a malicious miner with lots of
>> mining power to orphan the chain after so many blocks even with
>> non empty blocks? Is there a need to mitigate this?
>> If so is it possible?
>>
>> Time is running short I fear. There needs to be discussion on various
>> attacks and how they can be guarded against along with various
>> other contingency plans.
>>
>> - --
>> Cannon
>> PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
>> Email: cannon at cannon-ciota.info
>>
>> NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
>> BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
>> If this matters to you, use PGP.
>> -----BEGIN PGP SIGNATURE-----
>>
>> iQIcBAEBCgAGBQJY1UH/AAoJEAYDai9lH2mw2QYQALDLBxjdO5WTG7VXfuAE476p
>> D3o1MMGw23tb+DFUO5WV6aFqfy3VSxbVXz6UuWbj6kHgp3ys6qxg5TX0Dy8tKSZM
>> V28kovuS/pfen4gTxw1FCNff7YVW1R8QX+cSYxSD5EoEaTbpIPgi8zMusDxUVZk2
>> WG3ItoyvkLvoNIYGDcU3gR3UkjDS5lOPiHu5BKSj1dEiibOXhr8JEBCznfUSyxCG
>> TjVRJaUPlwCU06nad8jAZiDrsW3l866iNkBKaMzMavYuMLvCGIdRkbf54B2ZlIT/
>> S/owusxqeIdQpydi/3ydnrqyeWo3znMnn+oOvdvfYEHKLts6gar3Zv8cZ40yYSIE
>> z7C7GQFIo5TYDUNOk+2VE7NNtdX39Wj3gJql/305miaIt0qMsf1D30ODjePwyxUQ
>> LQ96ZeF1K/0RSTN5TFvLjV9ZmaaN/tFm3kx0PunptJaZT8d9EgMeHREjCF4di04A
>> 6Dp3Qeug41X/zdIc2AM387QnPwmGB1TpfrY9qgvcrIe26T6An2V5LHwVmslCX3ui
>> DYAl0o5ODQqnnakF1FIrr1blMVqm7FqDPQc1I5TfzQuxX2+x+5zdrciPC2HUMCMQ
>> jMujge5IdGL3kjEwjt+M6kqLu0/T0fhdUetb2DWrRJUcEVoIaiUL7qLJC+4KMR3d
>> Gu3oWoE1ld+BC6At28AD
>> =SSuj
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> 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/20170324/0a8b7125/attachment-0001.html>;

📅 Original date posted:2016-12-10 📝 Original message:> ...

2023-06-07T17:54:46Z

In reply to nevent1q…ergv
_________________________

📅 Original date posted:2016-12-10
📝 Original message:> While disk space requirements might not be a big problem, block
propagation time is

Is block propagation time really still a problem? Compact blocks and FIBRE
should help here.

> Bitcoin, because its fundamental design, can scale by using offchain
solutions.

I agree.
However, I believe that on-chain scaling will be needed regardless of which
off-chain solution gains popularity.

2016-12-10 11:44 GMT+01:00 s7r via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> t. khan via bitcoin-dev wrote:
> > BIP Proposal - Managing Bitcoin’s block size the same way we do
> > difficulty (aka Block75)
> >
> > The every two-week adjustment of difficulty has proven to be a
> > reasonably effective and predictable way of managing how quickly blocks
> > are mined. Bitcoin needs a reasonably effective and predictable way of
> > managing the maximum block size.
> >
> > It’s clear at this point that human beings should not be involved in the
> > determination of max block size, just as they’re not involved in
> > deciding the difficulty.
> >
> > Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or
> > passing the decision to miners/pool operators, the max block size should
> > be adjusted every two weeks (2016 blocks) using a system similar to how
> > difficulty is calculated.
> >
> > Put another way: let’s stop thinking about what the max block size
> > should be and start thinking about how full we want the average block to
> > be regardless of size. Over the last year, we’ve had averages of 75% or
> > higher, so aiming for 75% full seems reasonable, hence naming this
> > concept ‘Block75’.
> >
> > The target capacity over 2016 blocks would be 75%. If the last 2016
> > blocks are more than 75% full, add the difference to the max block size.
> > Like this:
> >
> > MAX_BLOCK_BASE_SIZE = 1000000
> > TARGET_CAPACITY = 750000
> > AVERAGE_OVER_CAP = average block size of last 2016 blocks minus
> > TARGET_CAPACITY
> >
> > To check if a block is valid, ≤ (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)
> >
> > For example, if the last 2016 blocks are 85% full (average block is 850
> > KB), add 10% to the max block size. The new max block size would be
> > 1,100 KB until the next 2016 blocks are mined, then reset and
> > recalculate. The 1,000,000 byte limit that exists currently would
> > remain, but would effectively be the minimum max block size.
> >
> > Another two weeks goes by, the last 2016 blocks are again 85% full, but
> > now that means they average 935 KB out of the 1,100 KB max block size.
> > This is 93.5% of the 1,000,000 byte limit, so 18.5% would be added to
> > that to make the new max block size of 1,185 KB.
> >
> > Another two weeks passes. This time, the average block is 1,050 KB. The
> > new max block size is calculated to 1,300 KB (as blocks were 105% full,
> > minus the 75% capacity target, so 30% added to max block size).
> >
> > Repeat every 2016 blocks, forever.
> >
> > If Block75 had been applied at the difficulty adjustment on November
> > 18th, the max block size would have been 1,080KB, as the average block
> > during that period was 83% full, so 8% is added to the 1,000KB limit.
> > The current size, after the December 2nd adjustment would be 1,150K.
> >
> > Block75 would allow the max block size to grow (or shrink) in response
> > to transaction volume, and does so predictably, reasonably quickly, and
> > in a method that prevents wild swings in block size or transaction fees.
> > It attempts to keep blocks at 75% total capacity over each two week
> > period, the same way difficulty tries to keep blocks mined every ten
> > minutes. It also keeps blocks as small as possible.
> >
> > Thoughts?
> >
> > -t.k.
> >
>
> I like the idea. It is good wrt growing the max. block size
> automatically without human action, but the main problem (or question)
> is not how to grow this number, it is what number can the network
> handle, considering both miners and users. While disk space requirements
> might not be a big problem, block propagation time is. The time required
> for a block to propagate in the network (or at least to all the miners)
> is directly dependent of its size. If blocks take too much time to
> propagate in the network, the orphan rate will increase in unpredictable
> ways. For example if the internet speed in China is worse than in
> Europe, and miners in China have more than 50% of the hashing power,
> blocks mined by European miners might get orphaned.
>
> The system as described can also be gamed, by filling the network with
> transactions. Miners have the monetary interest to include as many
> transactions as possible in a block in order to collect the fees.
> Regardless how you think about it, there has to be a maximum block size
> that the network will allow as a consensus rule. Increasing it
> dynamically based on transaction volume will reach a point where the
> number got big enough that it broke things. Bitcoin, because its
> fundamental design, can scale by using offchain solutions.
>
>
> _______________________________________________
> 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/20161210/0eae6a60/attachment.html>;

📅 Original date posted:2016-12-04 📝 Original message:> ...

2023-06-07T17:54:41Z

In reply to nevent1q…m32k
_________________________

📅 Original date posted:2016-12-04
📝 Original message:> Also how about making timestamp 8 bytes? 2106 is coming up soon :)

AFAICT this was fixed in this commit:
https://github.com/jl2012/bitcoin/commit/fa80b48bb4237b110ceffe11edc14c8130672cd2#diff-499d7ee7998a27095063ed7b4dd7c119R200

2016-12-04 21:00 GMT+01:00 adiabat via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:

> Interesting stuff! I have some comments, mostly about the header.
>
> The header of forcenet is mostly described in Luke’s BIP, but I have made
>> some amendments as I implemented it. The format is (size in parentheses;
>> little endian):
>>
>> Height (4), BIP9 signalling field (4), hardfork signalling field (3),
>> merge-mining hard fork signalling field (1), prev hash (32), timestamp (4),
>> nonce1 (4), nonce2 (4), nonce3 (compactSize + variable), Hash TMR (32),
>> Hash WMR (32), total tx size (8) , total tx weight (8), total sigops (8),
>> number of tx (4), merkle branches leading to header C (compactSize + 32 bit
>> hashes)
>>
>
> First, I'd really rather not have variable length fields in the header.
> It's so much nicer to just have a fixed size.
>
> Is having both TMR and WMR really needed? As segwit would be required
> with this header type, and the WMR covers a superset of the data that the
> TMR does, couldn't you get rid of the TMR? The only disadvantage I can see
> is that light clients may want a merkle proof of a transaction without
> having to download the witnesses for that transaction. This seems pretty
> minor, especially as once they're convinced of block inclusion they can
> discard the witness data, and also the tradeoff is that light clients will
> have to download and store and extra 32 bytes per block, likely offsetting
> any savings from omitting witness data.
>
> The other question is that there's a bit that's redundant: height is also
> committed to in the coinbase tx via bip 34 (speaking of which, if there's a
> hard-fork, how about reverting bip 34 and committing to the height with
> coinbase tx nlocktime instead?)
>
> Total size / weight / number of txs also feels pretty redundant. Not a
> lot of space but it's hard to come up with a use for them. Number of tx
> could be useful if you want to send all the leaves of a merkle tree, but
> you could also do that by committing to the depth of the merkle tree in the
> header, which is 1 byte.
>
> Also how about making timestamp 8 bytes? 2106 is coming up soon :)
>
> Maybe this is too nit-picky; maybe it's better to put lots of stuff in for
> testing the forcenet and then take out all the stuff that wasn't used or
> had issues as it progresses.
>
> Thanks and looking forward to trying out forcenet!
>
> -Tadge
>
> _______________________________________________
> 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/20161204/77223c7c/attachment.html>;