Emil Engler [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-06-07 to 2019-11-08
💬 Posted a total of 13 messages
📚 Participated in the following categories: bitcoin-dev, Meta, BIP-able idea
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:21:32

- reply

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

2023-06-07 18:21:15

- reply

📅 Original date posted:2019-10-17
📝 Original message:Hi, I need a co-author for this BIP:
https://github.com/bitcoin/bips/pull/856
See the reasons mentioned by Marco Falke
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191017/94c19d3c/attachment-0001.bin>

2023-06-07 18:21:10

- reply

📅 Original date posted:2019-10-17
📝 Original message:As the idea got positive feedback, I've written the BIP.
The draft is available here:
https://github.com/bitcoin/bips/pull/856
Am 17.10.19 um 15:23 schrieb Marco Falke via bitcoin-dev:
> I also like the "bitcoin invoice address" term by Chris. Invoice is a
> common term and easily translatable into other languages.
>
> Marco
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191017/0b2934c5/attachment-0001.bin>

2023-06-07 18:21:09

- reply

📅 Original date posted:2019-10-11
📝 Original message:> This may not be the most practical information, but there actually did exist an almost perfect analogy for Bitcoin addresses from the ancient world: From wikipedia https://en.wikipedia.org/wiki/Bulla_(seal)
I personally do not like the term bulla, it might be a perfect analogy
but I personally don't believe that this term is well known. Tbh I
didn't knew what a 'bulla' was before.
> I propose Funding Codes.
I'm neutral on this. With code I associate something that is slightly
more permanent like a code to unlock your mobile phone or a code to
unlock your bike if you know what I mean. These kind of codes change
sometimes but not as often as a bitcoin address (should).
I also agree that Payment Tokens might confuse with other currencies and
block chain.
>
> - Invoices are problematic because they imply that they hold bitcoins and they specify an amount. However addresses don't specify any amounts while they themselves can be included inside a real invoice. I think it is wrong to imply that the "thing" we are sending money to is temporary, because it isn't. Lightning channels can stay open forever until closed but money doesn't stay in an invoice for any amount of time.
What is with 'Bitcoin Invoice Address'?
This is the best of both worlds because it implies the temporary factor
with 'invoice' and the way that you send something to something.
Also, this is more a personal opinion but I thunk that 'funding' implies
more to donate to something. I think this could lead to misunderstandings.
To summarize it up, here are the following suggested terms:
* Invoice ID
* Payment Token
* Bitcoin invoice (address)
* Bitcoin invoice (path)
* Bulla
* Funding code
Greetings,
Emil Engler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191011/5cac5674/attachment-0001.bin>

2023-06-07 18:21:08

- reply

📅 Original date posted:2019-10-10
📝 Original message:* Sorry if this mail was sent multiple times, my E-Mail client went crazy *
Thanks for all your feedback.
I came to the decision to write a BIP for this, even if it might not be
implemented by many wallets, a standardization is never wrong and this
would be the first step in the correct direction for better on-chain
privacy.
However currently we still need a good term for the 'address' replacement.
The current suggestions are:
* Invoice ID
* Payment Token
* Bitcoin invoice (address)
* Bitcoin invoice (path)
Because of the LN term invoice I really like the term 'Bitcoin Invoice'
by Chris Belcher.
So how do find a consensus about these terms?
Greetings
Emil Engler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191010/5b380c47/attachment.bin>

2023-06-07 18:21:08

- reply

📅 Original date posted:2019-10-06
📝 Original message:> But a pubkey is not a Base58 string, and fundamentally different from an
> address. An address identifies the recipient and the purpose of the payment;
> a pubkey does not. The pubkey remains with the UTXO; an address does not.
I don't know much about this topic in Bitcoin so far, but I meant the
address :)
> That problem would require using a different term than "address" to address.
I meant this the whole time, sorry for misunderstandings.
> A BIP is unlikely to do the job (though it may help).
Why? They are specifications and implementations need them (even if some
do not implement everything).
Also BIP 21 would need an alternative/separate parameter with the new term.
> Neither the address nor pubkey are a password...
In Germany at least (where I live), you need to provide a 'Password'
(the german translation of thin word of course) in the purpose of the
transaction if you pay with a bank transfer. They are used as IDs but I
agree, ID is definitely a better suffix.
> Some possible alternative terms would be "invoice id", "payment token", etc.
ACK
Greetings, Emil Engler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191006/5c829744/attachment.bin>

2023-06-07 18:21:07

- reply

📅 Original date posted:2019-10-05
📝 Original message:Hello dear mailing list subscribers.
Before I'll explain my idea here, I need to define a term first
'address':
When I use the terms address, pubkey, etc., I mean the same: The Base58
string
Ok now let's get into it:
As you should know, sending bitcoins to an address more than once is a
very bad approach.
In my opinion the problem why so many people are still doing this is
because of the term 'address' which is used in lots of wallets,
implementations, BIP 21 and so on. It is a design issue.
With the term 'address' most people identify things that are fixed and
don't change really often (e.g postal address, IP address [depends on
provider], Domain, E-Mail address, ...).
Because of this most people compare bitcoin addresses with e-mail
addresses and use this address to send the recipient money multiple times.
My suggestion would be to change the term address in wallets, the URI
scheme and so on to something of the following options by a
Informational/Process BIP:
* Payment Password
* Transaction Password
* ...
The guideline for the term should indicate that it is:
* temporary
* Something that identifies the recipient
I've chosen 'password' because they can be used as a pseudonym to
identify a person.
This is already used in stuff like bank transfers where something like
the transaction id should be used as the purpose or at universities
there are student numbers.
The first is probably a better example because student numbers aren't
temporary.
What do you think? Should I write a BIP for this or use another term?
Feedback is most welcome :)
Greetings,
Emil Engler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191005/6875962d/attachment-0001.bin>

2023-06-07 18:20:31

- reply

📅 Original date posted:2019-09-13
📝 Original message:Hello, I'm thinking about writing a BIP about resetting the testnet on
regular/scheduled basis
The idea works like this:
* Every 210000 block is being used as the genesis of a completely new chain.
* The old one gets forgotten
* No chain can be longer than 210000 blocks
The problems are:
* How to get this working with testnet3? Only a hardfork probably.
* Is it that easy to change the chain while Bitcoin Core is running?
Probably the blocks need to be appended to the cureent one. After a
restart it would get patched
* Could the the chain derive into multiple once at every reset? (Planned
attacks)
What do you think about the idea?
Greetings,
Emil Engler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190914/26a11cd7/attachment.bin>

2023-06-07 18:19:53

- reply

📅 Original date posted:2019-08-01
📝 Original message:In the last #bitcoin-core-dev IRC meeting, the mailing list moderation
was slightly discussed. It was decided to do this discussion mainly on
this mailing list (which makes sense).
The current situation is that the moderation is slow and takes around
>24h for a E-Mail to be on the mailing list.
Jonas Schnelli proposed: "I propose that we add more moderators to
shorten the moderation lag which has been between >24h, thus makes
debates cumbersome"
Beside this I had the idea of people who already contributed n e-mails
to the mailing list don't need an approval for any e-mail anymore (Where
n is the number of previous e-mails). Does this exists already?
Greetings,
Emil Engler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190801/a78795b7/attachment.bin>

2023-06-07 18:18:41

- reply

📅 Original date posted:2019-06-09
📝 Original message:But using the testnet means that you actually need to deal with resets.
There were 2 resets in the past but the last was in 2011.
Am 09.06.19 um 16:55 schrieb Tim Menapace:
> >I don't get why the testnet shouldn't be >resetted just because there is
> >a (probably better) alternative for it. The >testnet is still a thing and
> >is also used.
>
> Like Bryan said, lot of miners test here. E.g. new firmware versions,
> hardware prototypes and operation services. Difficulty will be on
> current levels in a short period of time.

2023-06-07 18:18:40

- reply

📅 Original date posted:2019-06-17
📝 Original message:Indeed a large testnet blockchain has advantages too.
But because it is the testnet and the testnet coins have no value, the
blockchain could be 'spammed' after a reset for some days/weeks until it
has a certain size.
Could this be realistic solution ?
Am 16.06.19 um 22:25 schrieb Peter Todd:
> On Sat, Jun 08, 2019 at 05:01:50PM +0200, Emil Engler via bitcoin-dev wrote:
>> I don't get why the testnet shouldn't be resetted just because there is a
>> (probably better) alternative for it. The testnet is still a thing and is
>> also used.
>
> Remember that the size of testnet itself is an important test; I've argued in
> that past that we should consider making testnet *larger* than mainnet. There's
> good arguments against that too, but I personally think the current size is a
> reasonable compromise.
>
> Of course, I personally tend to do all my testing on either internal regtest
> nodes, or directly on mainnet. But the fact that works for me is specific to
> the exact type of development I do and may not be applicable to you.
>
--
https://www.emilengler.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 3147 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190617/80546911/attachment.bin>

2023-06-07 18:18:39

- reply

📅 Original date posted:2019-06-07
📝 Original message:Hello, I tried myself with some Bitcoin development. For this I used of
course the Bitcoin testnet. However it took me one hour to sync the
blockchain with around 1538358 blocks. In my opinion that is too much
for a testnet. Especially the blockchain size with around 26GB is so
much. Would it be possible to reset the testnet with a new genesis block
? And if so, can we setup a fixed cycle for resetting the testnet (For
example every second 1st of January) ?
Greetings,
Emil Engler

2023-06-07 18:18:39

- reply

📅 Original date posted:2019-06-08
📝 Original message:I don't get why the testnet shouldn't be resetted just because there is
a (probably better) alternative for it. The testnet is still a thing and
is also used.
Am 08.06.19 um 16:21 schrieb Bryan Bishop:
> Be greeted Emil,
>
> On Sat, Jun 8, 2019 at 9:21 AM Emil Engler via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
> Hello, I tried myself with some Bitcoin development. For this I used of
> course the Bitcoin testnet. However it took me one hour to sync the
> blockchain with around 1538358 blocks. In my opinion that is too much
> for a testnet. Especially the blockchain size with around 26GB is so
> much. Would it be possible to reset the testnet with a new genesis
> block
> ? And if so, can we setup a fixed cycle for resetting the testnet (For
> example every second 1st of January) ?
>
>
> At the moment, I somewhat doubt this is likely to happen. Signet
> provides an alternative for configuring multiple separate private and
> public testing networks. If you would like to get involved, check out
> the recent discussion on the topic recorded here:
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-signet/
>
> - Bryan
> http://heybryan.org/