Martijn Meijering [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-09 12:45:58

- reply

📅 Original date posted:2016-03-08
📝 Original message:
Now that we almost have SegWit and its soft fork mechanism for upgrading
the scripting system, wouldn't it be a good idea to introduce a new opcode
for signature verification for arbitrary but appropriately
length-restricted messages? Instead of maintaining mirror images of txs and
going through the dance of revealing hash preimages, wouldn't it be easier
to to sign a message that revokes a previous balance (with hash + sequence
number)? Am I overlooking anything? This looks like a simple new opcode
that could substantially simplify the LN protocol.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160308/cdec7da8/attachment-0001.html>

2023-06-09 12:45:58

- reply

2023-06-09 12:45:31

- reply

📅 Original date posted:2015-12-29
📝 Original message:
Never mind, the idea is probably for neighbours of beacon nodes to discover
one of their neighbours has become a beacon and to propagate that
information to their other neighbours, which should not take too much
traffic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151229/d3ad0d77/attachment.html>

2023-06-09 12:45:31

- reply

📅 Original date posted:2015-12-28
📝 Original message:
Is there a summary somewhere of the latest ideas on how nodes should find
routes between themselves or between themselves and beacon nodes? I'm
having a hard time visualising how a node would find routes to beacons
without resorting to a floodfill search, which doesn't look as if it would
scale. Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151228/c6d57c1e/attachment.html>

2023-06-09 12:45:20

- reply

📅 Original date posted:2015-12-07
📝 Original message:
(repost after setting the correct email address)
Andrew Miller wrote:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-December/000365.html
"So, it turns out that a SNARK is overkill for the application in this
thread."
Could you elaborate on this? Are the required messages too large, does
verification take too long, something else? This may be an ignorant
question, but if it's one of the former two, wouldn't an interactive ZK
proof using Yao garbled circuits be enough to get us what we want?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151207/ac95e985/attachment.html>

2023-06-09 12:45:20

- reply

📅 Original date posted:2015-12-06
📝 Original message:
(Repost after subscribing)
Andrew Miller wrote:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-December/000365.html
"So, it turns out that a SNARK is overkill for the application in this
thread."
Could you elaborate on this? Are the required messages too large, does
verification take too long, something else? This may be a an ignorant
question, but if it's one of the former two, wouldn't an interactive ZK
proof using Yao garbled circuits be enough to get us what we want?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151206/6e4bc3b4/attachment.html>

2023-06-07 18:03:05

- reply

📅 Original date posted:2017-06-11
📝 Original message:Jorge Timón wrote:
"My preference would be a bip149 proposal that could be merged and
released now, but some people complain that would require more
testing, because *if you deploy bip149 and then sw gets activated pre
nov15, then you want bip149 nodes to use the old service bit for
segwit*, not the new one (you would use that one if it activates post
nov15, so that pre-bip149 nodes don't get confused)."
(emphasis added)
Why not just make sure BIP 149 will never activate unless BIP 141 has
expired unsuccessfully? If BIP 141 should unexpectly activate, then
BIP 149 nodes would notice and act as pre-SegWit nodes indefinitely,
but remain in consensus with BIP 141 nodes.
It might be slightly less convenient for BIP 149 users to upgrade
again, but then at least we could start deploying BIP 149 sooner.

2023-06-07 17:52:03

- reply

📅 Original date posted:2016-07-26
📝 Original message:- Flags will be mined selfishly, and not published until the advantage
gained from withholding is less than the mining reward. This effect may
kill the decentralization features, since big miners will be the only ones
that can selfish-mine flags. Indeed, collusion would be encouraged... just
ship the flag to the miners you do business with, and no one else. At the
expense of loss of flag revenue, your in-group would gain a massive
advantage in main-chain mining.
---
Is there a reason miners would be more likely to engage in selfish
mining of sync flags than they are now with ordinary blocks?

2023-06-07 17:47:25

- reply

📅 Original date posted:2015-12-30
📝 Original message:That looks very interesting. But is effectively blocking old clients from
seeing transactions really safe? After all, such transactions are still
confirmed on the new chain. A person might try to send a similar
transaction several times, perhaps with increasing fees in an attempt to
get it to confirm and end up paying someone several times.
Maybe we could require the tx version number to be increased as well so
transactions sent from old clients would never confirm? Perhaps your code
already includes this idea, I need to look at it more closely.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151230/6a96deaf/attachment.html>

2023-06-07 17:46:44

- reply

📅 Original date posted:2015-12-17
📝 Original message:Appealing moderator's decision. If my post was off-topic, then so is the
whole thread. As for content-heavy, I made a very specific compromise
proposal that I'd like to bring to the developers attention. If this isn't
the place to do that, then I don't know what is, but I'd be happy to repost
to a different forum if you can suggest one that is more appropriate.
===
It looks as if there has been movement on both sides of this debate and the
outlines of a potential medium term truce are starting to appear. Given the
enormous amount of unrest this whole debate has caused I think it would be
highly desirable if both sides could reach an honourable compromise that's
ready to be deployed next year.
I'd like to make a compromise proposal, made up of of uncontroversial
elements of other proposals.
It is intended to achieve the following goals:
- Discourage a potentially disastrous contentious hard fork and
consequently only activate with overwhelming community support.
- Provide immediate relief on both fees and growth potential once activated.
- Provide immediate reassurance that there won't be radical growth for a
number of years without another hard fork.
- Lock in a temporary modest growth path that goes meaningfully beyond BIP
102 so we have at least a few years worth of certainty for those who want
growth.
- Be no more than a kick-the-can-down-the-road solution and do not rule
anything in or out after an interim period of a number of years.
- One-off activation vote to avoid uncertainty hanging over the market
indefinitely.
- Be as simple as possible to allow for the earliest possible deployment.
- Be as uncontroversial as possible to allow for the earliest possible
deployment.
- Do not grow much beyond 2M for at least a year because of concerns
expressed by miners at Scaling Bitcoin.
- Involve both a hard fork and a soft fork.
- Have continuous, gradual growth instead of big step functions.
It's essentially a combination of a variant of 2-4-8 (necessarily a hard
fork) and a soft fork version of Segregated Witness. The advantage of the
2-4-8 hard fork is that it is very simple and can be coded and merged very
quickly, probably in January. The SW soft fork on the other hand can
probably be activated sooner. Iherefore I'd like to see the hard fork
coded, merged and deployed first, then the soft fork merged and deployed
and then the hard fork activated provided it passes its vote. In this way
SW would be sandwiched between the deployment of an as yet inactive 2-4-8
and its activation.
It does not preclude further hard forks at any time, either before or after
the proposed compromise hard fork, although it is specifically intended to
discourage *contentious* hard forks. Non-contentious hard forks that become
possible in the light of experience gained are only to be welcomed of
course.
The details are as follows:
Hard fork with gradual growth:
- +20kb each difficulty adjustment up to 8M.
- Possibly a one-off jump to 2MB, but probably not given that SW will
likely be activated first.
- 95% activation threshold hard-coded to a period of 1000 blocks before a
one-off, fixed block ("election day").
- One month grace period, with a flag date at a fixed block height
("inauguration day") that will enable the growth mechanism supposing the
threshold was met by election day.
- Pull request ready somewhere in January.
- Merged in Q1.
- Release around May.
- Election day January 1st 2017.
- Inauguration day February 1st 2017.
Soft fork Segregated Witness:
- Deployed as already suggested by the developers, but modified to be aware
of the upcoming hard fork.
- Limited to 1MB for the witness section for the first two years after
deployment to take miner concerns into account and allow time for research
into give weak blocks and IBLT research
- Witness section size set to 1x or 2x the size of the main section of the
block after two years.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151217/633b9c14/attachment-0001.html>