Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

[Jeremy via bitcoin-dev]

Zac -- this is kind of offtopic for this thread, which is primarily to do
with making software/standards that supports existing practices in the
bitcoin community rather than new standards/formats for a similar task.

I think there have been some other related posts recently where it might be
more topical?

Sorry for any confusion,

Jeremy
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

[Zac Greenwood via bitcoin-dev]

> 1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I
>   think) for OP_RETURN versus 40 bytes for a BIP141 payload.
>   Maximizing payload size better amortizes the overhead cost of the
>   containing transaction and the output's nValue field.

In order to reduce the footprint of data stored on-chain, could it perhaps
be beneficial to introduce some non-transaction data structure in order to
facilitate storing data on-chain such that it maximizes payload size
vs. on-chain size, while at the same time ensuring that using such data
structure is (almost) as expensive in use per payload-byte as the
next-cheapest alternative (which now is using OP_RETURN) with
help of weight units?

Zac


On Sun, Apr 25, 2021 at 12:01 AM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Sat, Apr 24, 2021 at 01:05:25PM -0700, Jeremy wrote:
> > I meant the type itself is too wide, not the length of the value. As in
> > Script can represent things we know nothing about.
>
> I guess I still don't understand your concern, then.  If script can
> represent things we know nothing about, then script commitments such as
> P2SH, P2WSH, and P2TR also represent things we know nothing about.  All
> you know is what container format they used.  For P2PK, bare multisig,
> OP_RETURN, and other direct uses of scriptPubKey, that container format
> is "bare" (or whatever you want to call it).
>
> > Btw: According to... Oh wait... You?
> >
> https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-size-of-a-scriptsig-scriptpubkey
> > the max size is 10k bytes.
>
> I'm not sure what I knew at the time I wrote that answer, but the 10,000
> byte limit is only applied when EvalScript is run, which only happens
> when the output is being spent.  I've appended to this email a
> demonstration of creating a 11,000 byte OP_RETURN on regtest (I tried
> 999,000 bytes but ran into problems with bash's maximum command line
> length limit).  I've updated the answer to hopefully make it more
> correct.
>
> > Is it possible/easy to, say, using bech32m make an inappropriate message
> in
> > the address? You'd have to write the message, then see what it decodes to
> > without checking, and then re encode? I guess this is worse than hex?
>
> If someone wants to abuse bech32m, I suspect they'll do it the same way
> people have abused base58check[1], by using the address format's
> alphabet directly.  E.g., you compose your message using only
> the characters qpzry9x8gf2tvdw0s3jn54khce6mua7l and then append
> the appropriate checksum.
>
> [1]
> https://en.bitcoin.it/wiki/P2SH%C2%B2#The_problem:_storing_data_in_hashes
>
> > But it seems this is a general thing... If you wanted an inappropriate
> > message you could therefore just use bech32m addressed outputs.
>
> Yes, and people have done that with base58check.  IsStandard OP_RETURN
> attempts to minimize that abuse by being cheaper in two ways:
>
> 1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I
>think) for OP_RETURN versus 40 bytes for a BIP141 payload.
>Maximizing payload size better amortizes the overhead cost of the
>containing transaction and the output's nValue field.
>
> 2. Exemption from the dust limit.  If you use a currently defined
>address type, the nValue needs to pay at least a few thousand nBTC
>(few hundred satoshis), about $0.15 USD minimum at $50k USD/BTC.  For
>OP_RETURN, the nValue can be 0, so there's no additional cost beyond
>normal transaction relay fees.
>
> Although someone creating an OP_RETURN up to ~1 MB with miner support
> can bypass the dust limit, the efficiency advantage remains no matter
> what.
>
> > One of the nice things is that the current psbt interface uses a blind
> > union type whereby the entires in an array are either [address, amount]
> or
> > ["data", hex]. Having an address type would allow more uniform handling,
> > which is convenient for strongly typed RPC bindings (e.g. rust bitcoin
> uses
> > a hashmap of address to amount so without a patch you can't create op
> > returns).
>
> I don't particularly care how the data in PSBTs are structured.  My mild
> opposition was to adding code to the wallet that exposes everyday users
> to OP_RETURN addresses.
>
> > I would much prefer to not have to do this in a custom way, as opposed
> > to a way which is defined in a standard manner across all software
> > (after all, that's the point of standards).
>
> I'm currently +0.1 on the idea of an address format of OP_RETURN, but I
> want to make sure this isn't underwhelmingly motivated or will lead to a
> resurgence of block chain graffiti.
>
> -Dave
>
> ## Creating an 11,000 byte OP_RETURN
>
> $ bitcoind -daemon -regtest -acceptnonstdtxn
> Bitcoin Core starting
>
> $ bitcoin-cli -regtest -generate 101
> {
>   "address": "bcrt1qh9uka5z040vx2rc3ltz3tpwmq4y2mt0eufux9r",
>   "blocks": [
> [...]
> }
>
> $ bitcoin-cli -regtest send '[{"data": "'$( dd if=/dev/zero 

Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

[Jeremy via bitcoin-dev]

I guess in the interest of being clear; I don't particularly want a
OP_RETURN address either, they're just annoying to program around, and they
exist historically, as well as perhaps in the future.

Maybe people will start using the annex space to add any metadata required?
E.g. stealth addresses. I kinda hope not, but probably will be proposed as
a SF since it's much cheaper (witness + no amount) and per-input vs. per-tx.

It's interesting that they can be created with any length... i guess any
script can be an op return if you make it long enough...
--
@JeremyRubin 



On Sat, Apr 24, 2021 at 3:00 PM David A. Harding  wrote:

> On Sat, Apr 24, 2021 at 01:05:25PM -0700, Jeremy wrote:
> > I meant the type itself is too wide, not the length of the value. As in
> > Script can represent things we know nothing about.
>
> I guess I still don't understand your concern, then.  If script can
> represent things we know nothing about, then script commitments such as
> P2SH, P2WSH, and P2TR also represent things we know nothing about.  All
> you know is what container format they used.  For P2PK, bare multisig,
> OP_RETURN, and other direct uses of scriptPubKey, that container format
> is "bare" (or whatever you want to call it).
>
> > Btw: According to... Oh wait... You?
> >
> https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-size-of-a-scriptsig-scriptpubkey
> > the max size is 10k bytes.
>
> I'm not sure what I knew at the time I wrote that answer, but the 10,000
> byte limit is only applied when EvalScript is run, which only happens
> when the output is being spent.  I've appended to this email a
> demonstration of creating a 11,000 byte OP_RETURN on regtest (I tried
> 999,000 bytes but ran into problems with bash's maximum command line
> length limit).  I've updated the answer to hopefully make it more
> correct.
>
> > Is it possible/easy to, say, using bech32m make an inappropriate message
> in
> > the address? You'd have to write the message, then see what it decodes to
> > without checking, and then re encode? I guess this is worse than hex?
>
> If someone wants to abuse bech32m, I suspect they'll do it the same way
> people have abused base58check[1], by using the address format's
> alphabet directly.  E.g., you compose your message using only
> the characters qpzry9x8gf2tvdw0s3jn54khce6mua7l and then append
> the appropriate checksum.
>
> [1]
> https://en.bitcoin.it/wiki/P2SH%C2%B2#The_problem:_storing_data_in_hashes
>
> > But it seems this is a general thing... If you wanted an inappropriate
> > message you could therefore just use bech32m addressed outputs.
>
> Yes, and people have done that with base58check.  IsStandard OP_RETURN
> attempts to minimize that abuse by being cheaper in two ways:
>
> 1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I
>think) for OP_RETURN versus 40 bytes for a BIP141 payload.
>Maximizing payload size better amortizes the overhead cost of the
>containing transaction and the output's nValue field.
>
> 2. Exemption from the dust limit.  If you use a currently defined
>address type, the nValue needs to pay at least a few thousand nBTC
>(few hundred satoshis), about $0.15 USD minimum at $50k USD/BTC.  For
>OP_RETURN, the nValue can be 0, so there's no additional cost beyond
>normal transaction relay fees.
>
> Although someone creating an OP_RETURN up to ~1 MB with miner support
> can bypass the dust limit, the efficiency advantage remains no matter
> what.
>
> > One of the nice things is that the current psbt interface uses a blind
> > union type whereby the entires in an array are either [address, amount]
> or
> > ["data", hex]. Having an address type would allow more uniform handling,
> > which is convenient for strongly typed RPC bindings (e.g. rust bitcoin
> uses
> > a hashmap of address to amount so without a patch you can't create op
> > returns).
>
> I don't particularly care how the data in PSBTs are structured.  My mild
> opposition was to adding code to the wallet that exposes everyday users
> to OP_RETURN addresses.
>
> > I would much prefer to not have to do this in a custom way, as opposed
> > to a way which is defined in a standard manner across all software
> > (after all, that's the point of standards).
>
> I'm currently +0.1 on the idea of an address format of OP_RETURN, but I
> want to make sure this isn't underwhelmingly motivated or will lead to a
> resurgence of block chain graffiti.
>
> -Dave
>
> ## Creating an 11,000 byte OP_RETURN
>
> $ bitcoind -daemon -regtest -acceptnonstdtxn
> Bitcoin Core starting
>
> $ bitcoin-cli -regtest -generate 101
> {
>   "address": "bcrt1qh9uka5z040vx2rc3ltz3tpwmq4y2mt0eufux9r",
>   "blocks": [
> [...]
> }
>
> $ bitcoin-cli -regtest send '[{"data": "'$( dd if=/dev/zero bs=1000
> count=11 | xxd -g0 -p | tr -d '\n' )'"}]'
> 11+0 records in
> 11+0 records out
> 11000 bytes (11 kB, 11 KiB) copied, 

Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

[David A. Harding via bitcoin-dev]

On Sat, Apr 24, 2021 at 01:05:25PM -0700, Jeremy wrote:
> I meant the type itself is too wide, not the length of the value. As in
> Script can represent things we know nothing about. 

I guess I still don't understand your concern, then.  If script can
represent things we know nothing about, then script commitments such as
P2SH, P2WSH, and P2TR also represent things we know nothing about.  All
you know is what container format they used.  For P2PK, bare multisig,
OP_RETURN, and other direct uses of scriptPubKey, that container format
is "bare" (or whatever you want to call it).

> Btw: According to... Oh wait... You?
> https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-size-of-a-scriptsig-scriptpubkey
> the max size is 10k bytes.

I'm not sure what I knew at the time I wrote that answer, but the 10,000
byte limit is only applied when EvalScript is run, which only happens
when the output is being spent.  I've appended to this email a
demonstration of creating a 11,000 byte OP_RETURN on regtest (I tried
999,000 bytes but ran into problems with bash's maximum command line
length limit).  I've updated the answer to hopefully make it more
correct.

> Is it possible/easy to, say, using bech32m make an inappropriate message in
> the address? You'd have to write the message, then see what it decodes to
> without checking, and then re encode? I guess this is worse than hex?

If someone wants to abuse bech32m, I suspect they'll do it the same way
people have abused base58check[1], by using the address format's
alphabet directly.  E.g., you compose your message using only
the characters qpzry9x8gf2tvdw0s3jn54khce6mua7l and then append
the appropriate checksum.

[1] https://en.bitcoin.it/wiki/P2SH%C2%B2#The_problem:_storing_data_in_hashes

> But it seems this is a general thing... If you wanted an inappropriate
> message you could therefore just use bech32m addressed outputs.

Yes, and people have done that with base58check.  IsStandard OP_RETURN
attempts to minimize that abuse by being cheaper in two ways:

1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I
   think) for OP_RETURN versus 40 bytes for a BIP141 payload.
   Maximizing payload size better amortizes the overhead cost of the
   containing transaction and the output's nValue field.

2. Exemption from the dust limit.  If you use a currently defined
   address type, the nValue needs to pay at least a few thousand nBTC
   (few hundred satoshis), about $0.15 USD minimum at $50k USD/BTC.  For
   OP_RETURN, the nValue can be 0, so there's no additional cost beyond
   normal transaction relay fees.

Although someone creating an OP_RETURN up to ~1 MB with miner support
can bypass the dust limit, the efficiency advantage remains no matter
what.

> One of the nice things is that the current psbt interface uses a blind
> union type whereby the entires in an array are either [address, amount] or
> ["data", hex]. Having an address type would allow more uniform handling,
> which is convenient for strongly typed RPC bindings (e.g. rust bitcoin uses
> a hashmap of address to amount so without a patch you can't create op
> returns).

I don't particularly care how the data in PSBTs are structured.  My mild
opposition was to adding code to the wallet that exposes everyday users
to OP_RETURN addresses.

> I would much prefer to not have to do this in a custom way, as opposed
> to a way which is defined in a standard manner across all software
> (after all, that's the point of standards).

I'm currently +0.1 on the idea of an address format of OP_RETURN, but I
want to make sure this isn't underwhelmingly motivated or will lead to a
resurgence of block chain graffiti.

-Dave

## Creating an 11,000 byte OP_RETURN

$ bitcoind -daemon -regtest -acceptnonstdtxn
Bitcoin Core starting

$ bitcoin-cli -regtest -generate 101
{
  "address": "bcrt1qh9uka5z040vx2rc3ltz3tpwmq4y2mt0eufux9r",
  "blocks": [
[...]
}

$ bitcoin-cli -regtest send '[{"data": "'$( dd if=/dev/zero bs=1000 count=11 | 
xxd -g0 -p | tr -d '\n' )'"}]'
11+0 records in
11+0 records out
11000 bytes (11 kB, 11 KiB) copied, 0.000161428 s, 68.1 MB/s
{
  "txid": "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51",
  "complete": true
}

$ bitcoin-cli -regtest getrawmempool
[
  "ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51"
]

$ bitcoin-cli -regtest -generate 1
{
  "address": "bcrt1qlzjd90tkfkr09m867zxhte9rqd3t03wc5py5zh",
  "blocks": [
"2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b"
  ]
}

$bitcoin-cli -regtest getblock 
2986e9588c5bd26a629020b1ce8014d1f4ac9ac19106d216d3abb3a314c5604b 2 | jq 
.tx[1].txid
"ef3d396c7d21914a2c308031c9ba1857694fc33df71f5a349b409ab3406dab51"


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Pre-BIP] Motivating Address type for OP_RETURN

[Jeremy via bitcoin-dev]

Inline responses

On Fri, Apr 23, 2021, 11:18 AM David A. Harding  wrote:

> On Tue, Apr 20, 2021 at 08:46:07AM -0700, Jeremy via bitcoin-dev wrote:
>
>
>
>
>
> * > Script is technically "too wide" a type as what I really want is to >
> only return coins with known output types. I don't understand this
> concern.  If script is too wide a type, then OP_RETURN being a scriptPubKey
> of arbitrary length up to almost a million bytes is also going to be too
> wide, right?*
>


I meant the type itself is too wide, not the length of the value. As in
Script can represent things we know nothing about. There's a bit of leaky
abstraction since the values self describe the type they are. For addresses
it's just representations IMO for the standard output types one might
expect from standard software.

Btw: According to... Oh wait... You?
https://bitcoin.stackexchange.com/questions/35878/is-there-a-maximum-size-of-a-scriptsig-scriptpubkey
the max size is 10k bytes. Still probably too big for an address, but I'd
be ok with making op_return addresses only defined for a small size (e.g.
128 bytes?)



>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * > 1) Should it be human readable & checksummed or encoded? It should
> absolutely not be human readable in the sense of being meaningful to
> humans.  We've seen in the past that tools and sites that display OP_RETURN
> data as ASCII encourage people to put text in the block chain that is
> offensive and illegal.  This puts people running nodes at risk of social
> and legal intervention.  Bitcoin's premissionless nature means we can't
> stop people from creating such problems, but we can lower the risk by
> having our tools default to meaningless representations of OP_RETURN data.
> The best advice I've seen is to display OP_RETURN data in hex.  It's still
> possible to say things like "dead beef" with that, but significant abuse is
> hard.  This will, of course, make even 80 byte OP_RETURN "addresses" very
> long.*
>

Is it possible/easy to, say, using bech32m make an inappropriate message in
the address? You'd have to write the message, then see what it decodes to
without checking, and then re encode? I guess this is worse than hex?

But it seems this is a general thing... If you wanted an inappropriate
message you could therefore just use bech32m addressed outputs.


> >
>
>
>
> * 2) Should it have a fixed length of max 40-80 bytes or should we support
> > arbitrary length strings? If it doesn't support the fell range,
> somebody's just going to complain later and there will have to be a v2
> address.*
>

So 10,000 bytes? Or do we care to represent outputs that would be consensus
invalid?



>
>
>
>
>
>
>
>
>
>
>
> * > 3) Should it be possible (i.e., from core) to pay into such an
> OP_RETURN or > should we categorize OP_RETURNS as a non-payable address
> type (and just use > it for parsing blockdata) I don't think including
> arbitrary data in the block chain is something that's currently useful for
> typical end users, and applications that want to use OP_RETURN with Bitcoin
> Core can already call create(psbt|rawtransaction) with the `data` field, so
> I'd be mildly opposed in including such a feature in Bitcoin Core's
> wallet.  If at least a few other wallets add the feature to pay OP_RETURN
> "addresses" and it seems popular, then I'm wrong and so I would probably
> then change my position.*
>

One of the nice things is that the current psbt interface uses a blind
union type whereby the entires in an array are either [address, amount] or
["data", hex]. Having an address type would allow more uniform handling,
which is convenient for strongly typed RPC bindings (e.g. rust bitcoin uses
a hashmap of address to amount so without a patch you can't create op
returns).


>
>
>
>
>
> * Regarding "parsing block data", I don't think there's any need to change
> Bitcoin Core's current representation of OP_RETURN outputs (which is just
> showing the hex-encoded script in RPC output).  For any program needing
> OP_RETURN output, hex format is going to be a the next best thing to
> getting it in raw binary.  Any other address format is going to be equal or
> more work*.
>

Thats a fair point. I'm mostly thinking about this in the context of
strongly typed languages/frameworks where you'll get an address object or
enum out, rather than something *stringly* typed. But yes in terms of
stringy languages I don't think any changes are needed.

*Additionally, as mentioned in the other thread about OP_RETURN this*
*week, increasing transaction fees should increasingly push uses of*
*OP_RETURN off the network or into more efficient constructions, so it*
*doesn't seem warranted to me to spend a lot of time trying to optimize*
*how we use it when we'll be using it less and less over time.*


Hmm. I agree it should get priced out over time. However there are some
uses for this kind of stuff. E.g. stealth addresses, or a single instance
of open time stamps.

The main reason I think they merit some sort of std 

Re: [bitcoin-dev] 7z block compression, 18%

[Greg Maxwell via bitcoin-dev]

https://bitcointalk.org/index.php?topic=5303978.msg55946632#msg55946632

Blockstream satellite codebase includes an alternative serialization
that works a single transaction at a time and saves ~20%.  This avoids
violating layering, preserves single txn access, is compatible with
transaction relay.   (and if you wanted could also be fed to a
multiple txn at a time compressor for additional savings).  This
format makes intelligent use of the entirety of the transaction
format, not just amount encodings but even optimizing predictable
hashes (e.g. for p2sh embedded segwit) -- achieving savings that *no*
generic compressor could ever achieve.

Most of the savings from generic compressors comes from repeated
pubkeys and addresses, so it's highly variable, depends on address
reuse, and will likely be diminished by taproot (due to shrinking
multisig) and very much reduced by signature aggregation in the
future.

If you're thinking about use across networks generic compression
interfaces like zlib have had a pretty disappointing security track
record.


If you search the list archive and bitcoin-core github you'll find
many prior discussions of using generic compressors.



On Sat, Apr 24, 2021 at 6:12 PM NITSOPOULOS KONSTANTINOS via
bitcoin-dev  wrote:
>
> Hi, I can compress new blocks by up to 18% using the 7z file type. I use 
> wxHexEditor to dump a block's raw hex onto my disk, and then compress that 
> with 7-Zip. I'd like to see 7z built into Bitcoin Core, for block compression 
> (storage & propagation). The entire blockchain could be under 290GB if it's 
> converted into a 7z archive-chain ("7z-chain"). I can compress some recent 
> example blocks (hex -> less hex) if anyone wants. A future BIP could try 
> increase the block Weight Units limit by up to 21% if 7z blocks are smaller & 
> quick.
>
> Programming compression seems too difficult for me, so I'm hoping somebody 
> else does it!
>
> Eventually I think transactions can be compressed by replacing addresses (& 
> public keys) and coins, wherever possible, with just their own unique 
> sequential index. TX amounts can also be compressed if they contain only a 
> decimal digit or two, e.g. .1000 XBT. A TX of 0.1 XBT between two 
> existing addresses could be somehow compressed to half or maybe a quarter of 
> its current size!
>
> -Tinos
> ___
> 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] 7z block compression, 18%

[Pavol Rusnak via bitcoin-dev]

If block compression is going to be considered, zstd provides better
properties than the competition.
Especially for the decompression. [1]

[1] https://github.com/facebook/zstd

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
Co-founder and CTO, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] 7z block compression, 18%

[NITSOPOULOS KONSTANTINOS via bitcoin-dev]

Hi, I can compress new blocks by up to 18% using the 7z file type. I use wxHexEditor to dump a block's raw hex onto my disk, and then compress that with 7-Zip. I'd like to see 7z built into Bitcoin Core, for block compression (storage & propagation). The entire blockchain could be under 290GB if it's converted into a 7z archive-chain ("7z-chain"). I can compress some recent example blocks (hex -> less hex) if anyone wants. A future BIP could try increase the block Weight Units limit by up to 21% if 7z blocks are smaller & quick.

 

Programming compression seems too difficult for me, so I'm hoping somebody else does it!

 

Eventually I think transactions can be compressed by replacing addresses (& public keys) and coins, wherever possible, with just their own unique sequential index. TX amounts can also be compressed if they contain only a decimal digit or two, e.g. .1000 XBT. A TX of 0.1 XBT between two existing addresses could be somehow compressed to half or maybe a quarter of its current size!

 

-Tinos
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm

[Matt Corallo via bitcoin-dev]

What is preventing the BIP maintainership role from moving to a bot? It does seem like a bot should be able to do a fine 
job given the explicit criteria (though ignoring obvious spam is often nice, its by no means a requirement).


Given recent events where humans haveacted like humans, it seems a move to 
a bot may be warranted.

Matt

On 4/24/21 00:42, Greg Maxwell via bitcoin-dev wrote:

I am opposed to the addition of Kalle Alm at this time.

Those who believe that adding him will resolve the situation with
Luke-jr's inappropriate behavior re: PR1104 are mistaken.



27e59ffd51ee5a95d0e0faff70e045faca10b00015e90abc1c8de48b1dfff40c
___
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] Proposed BIP editor: Kalle Alm

[nopara73 via bitcoin-dev]

ACK adding Kalle

On Fri, Apr 23, 2021 at 5:51 PM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi Luke,
>
> For the records and the subscribers of this list not following
> #bitcoin-core-dev, this mail follows a discussion which did happen during
> yesterday irc meetings.
> Logs here : http://gnusha.org/bitcoin-core-dev/2021-04-22.log
>
> I'll reiterate my opinion expressed during the meeting. If this proposal
> to extend the bip editorship membership doesn't satisfy parties involved or
> anyone in the community, I'm strongly opposed to have the matter sliced by
> admins of the Bitcoin github org. I believe that defect or uncertainty in
> the BIP Process shouldn't be solved by GH janitorial roles and I think
> their roles don't bestow to intervene in case of loopholes. Further, you
> have far more contributors involved in the BIP Process rather than only
> Bitcoin Core ones. FWIW, such precedent merits would be quite similar to
> lobby directly GH staff...
>
> Unless we harm Bitcoin users by not acting, I think we should always be
> respectful of procedural forms. And in the lack of such forms, stay patient
> until a solution satisfy everyone.
>
> I would recommend the BIP editorship, once extended or not, to move in its
> own repository in the future.
>
> Cheers,
> Antoine
>
>
>
>
> Le jeu. 22 avr. 2021 à 22:09, Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> a écrit :
>
>> Unless there are objections, I intend to add Kalle Alm as a BIP editor to
>> assist in merging PRs into the bips git repo.
>>
>> Since there is no explicit process to adding BIP editors, IMO it should
>> be
>> fine to use BIP 2's Process BIP progression:
>>
>> > A process BIP may change status from Draft to Active when it achieves
>> > rough consensus on the mailing list. Such a proposal is said to have
>> > rough consensus if it has been open to discussion on the development
>> > mailing list for at least one month, and no person maintains any
>> > unaddressed substantiated objections to it.
>>
>> A Process BIP could be opened for each new editor, but IMO that is
>> unnecessary. If anyone feels there is a need for a new Process BIP, we
>> can go
>> that route, but there is prior precedent for BIP editors appointing new
>> BIP
>> editors, so I think this should be fine.
>>
>> Please speak up soon if you disagree.
>>
>> Luke
>> ___
>> 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
>


-- 
Best,
Ádám
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Additional BIPs related to other proposals

[Christopher Gilliard via bitcoin-dev]

I have created three additional BIPs that are associated with my recent
proposals. They can be found here:

https://github.com/cgilliard/bips/blob/notification/bip-.mediawiki

and here:

https://github.com/cgilliard/bips/blob/moderation/bip-.mediawiki

and here:

https://github.com/cgilliard/bips/blob/wot/bip-.mediawiki

Please reply with any feedback, questions, or comments.

Regards,
Chris
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Proposed BIP editor: Kalle Alm

[Greg Maxwell via bitcoin-dev]

I am opposed to the addition of Kalle Alm at this time.

Those who believe that adding him will resolve the situation with
Luke-jr's inappropriate behavior re: PR1104 are mistaken.



27e59ffd51ee5a95d0e0faff70e045faca10b00015e90abc1c8de48b1dfff40c
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev