Re: [bitcoin-dev] ANYPREVOUT in place of CTV
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@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-requ...@lists.linuxfoundation.org wrote: > > Send bitcoin-dev mailing list submissions to > bitcoin-dev@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-requ...@lists.linuxfoundation.org > > You can reach the person managing the list at > bitcoin-dev-ow...@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 + > From: darosior daros...@protonmail.com > > To: Bitcoin Protocol Discussion > bitcoin-dev@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 > > ___
Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution
> 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 : > 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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution
> 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@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
> 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 HEX19000A
>> the first bit "1" can be 1,2 or 0
>> 1 = increase future block (9 blocks ahead)
>> 2 decrease future block (9 blocks ahead)
>> 0No 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 "" 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 dynam
Re: [bitcoin-dev] Improving Pre and Post Merging Abilities With Rewriting Core In Python
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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Implementing Confidential Transactions in extension blocks
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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinf
Re: [bitcoin-dev] A DNS-like decentralized mapping for wallet addresses?
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@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-boun...@lists.linuxfoundation.org < > bitcoin-dev-boun...@lists.linuxfoundation.org> on behalf of Sjors > Provoost via bitcoin-dev > *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@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@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 > > joro...@vt.edu > > PGP key ID: 26623924 > > > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Simplicity proposal - Jets?
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@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@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-requ...@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0
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@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
> > 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"
> >> 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@lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >> ___
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] how to disable segwit in my build?
> 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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] how to disable segwit in my build?
> 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@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 > > > <mailto:bitcoin-dev@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 ca
Re: [bitcoin-dev] how to disable segwit in my build?
> 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@lists.linuxfoundation.org>: > On 13 July 2017 at 03:04, Gregory Maxwell via bitcoin-dev < > bitcoin-dev@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Drivechain RfD -- Follow Up
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@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 acc
Re: [bitcoin-dev] Height based vs block time based thresholds
>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@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: l...@dashjr.org > > > To: bitcoin-dev@lists.linuxfoundation.org, shaolinfry > > > 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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated
> 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 : > On Tue, Jun 20, 2017 at 10:15 PM, Hampus Sjöberg > 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. > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated
> 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@lists.linuxfoundation.org>: > On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev > 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 > 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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Miners forced to run non-core code in order to get segwit activated
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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] I do not support the BIP 148 UASF
> 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@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@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 t
Re: [bitcoin-dev] Barry Silbert segwit agreement
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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] A proposal to reintroduce the disabled script opcodes
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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?
> 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@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@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
Re: [bitcoin-dev] BIP - 'Block75' - New algorithm
> It gives miners complete control over the limit. They can make blocks of any size (within the current limit), thus triggering the conditions by which your proposal would raise the limit further. There might be a long term incentive to keep increasing the blocksize, to further centralize the network (and kick smaller miners out), but it comes with the cost of losing out on transaction fees. Miners have always needed to plan for the short term, I see no rational scenario where miners would spam their blocks with their own transactions (or low fee transactions) to keep increasing the blocksize limit. Hampus ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)
> 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@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 = 100 > > TARGET_CAPACITY = 75 > > 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 usin
Re: [bitcoin-dev] Forcenet: an experimental network with a new header format
> 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@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
