mitchellh

I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I've typed up this response so many times that I've decided to just put it in a gist so I can reference it whenever it comes up again.

I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:

RobinLinus

Some Day Peg

A two-way peg bridging BTC to other chains. It works similar to a perpetual one-way peg; however, instead of burning the BTC they are locked up until a particular time in 20 years. Until then, the community has to figure out how to do peg-outs with, e.g., some sort of OP_ZKP_VERIFY or Simplicity.

We simply pretend that OP_NOP10 is OP_ZKP_VERIFY and let users lock BTC in the following script:

<program_hash> OP_NOP10
 OP_CLTV OP_2DROP

delta1

merge notes for elements 24

please comment with

• bitcoin PR / merged-master commit hash
• notes about conflicts/resolution or things to keep track of

dergigi

Moved to nostr-resources.com

Marc-B-Reynolds

click for range breakdown

checking on [3f800000,40000000] [1.000000e+00,2.000000e+00]

func	e	max ULP	CR	FR	2 ULP	> 2 ULP	CR%	FR%	2 ULP%	> 2 ULP%
vrsqrte_f32	--	4947968	103	225	216	8388065	0.001228	0.002682	0.002575	99.993515
FRSR_Mon0	--	564177	3	8	6	8388592	0.000036	0.000095	0.000072	99.999797
FRSR_Deg0	--	403258	0	0	0	8388609	0.000000	0.000000	0.000000	100.000000
FRSR_Mon1	--	14751	230	464	466	8387449	0.002742	0.005531	0.005555	99.986172

aileftech

$ grep -P "^[ABCDEFabcdefOoIi]{6,6}$" /usr/share/dict/words | tr 'OoIi' '0011' | tr '[:lower:]' '[:upper:]' | awk '{print "#" $0}' 
#ACAD1A
#B0BB1E
#DEBB1E
#AB1DED
#ACAC1A
#ACCEDE
#AC1D1C
#BAB1ED
#BA0BAB

mraaroncruz

Working webserver

Mix.install([
  {:plug_cowboy, "> 0.0.0"},
  {:jason, "> 0.0.0"},
  {:httpoison, "> 0.0.0"}
])

RubenSomsen

Silent Payments

Receive private payments from anyone on a single static address without requiring any interaction or extra on-chain overhead.

Update: This now has a BIP and WIP implementation

Overview

The recipient generates a so-called silent payment address and makes it publicly known. The sender then takes a public key from one of their chosen inputs for the payment, and uses it to derive a shared secret that is then used to tweak the silent payment address. The recipient detects the payment by scanning every transaction in the blockchain.

tevador

JAMTIS

This document describes a new addressing scheme for Monero.

Chapters 1-2 are intended for general audience.

Chapters 3-7 contain technical specifications.

Table of Contents

hebasto

Building Bitcoin Core with GUI on Alpine Linux

System

$ cat /etc/alpine-release
3.13.5

Bitcoin Core repository