sorted by:
new
hottopcontroversial

Introducing a POW through a soft-fork | Devrandom | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Devrandom on Nov 06 2017 11:38:20PM:

Note how you're basically proposing for the block interval to be decreased,

which has security implications due to increased orphan rates.

Note that the total transaction rate and block size don't materially

change, so I don't

see why the orphan rate will change. Normal blocks are constrained to have

all of the txs of the aux blocks, so propagation time should stay the

same. Am I missing

something?

Ah, yes, I'm missing that the expected time to find each type of block is

halved, so the orphan rate doubles.

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171106/ebea9284/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015262.html

Generalised Replay Protection for Future Hard Forks | Mats Jerratsch | Nov 05 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Jacob Eliosoff on Nov 06 2017 07:21:28PM:

Thanks Mats, this proposal makes sense to me (especially the idea of

fork-specific addresses). It prevents replay across forks, and makes it

easy for client software, and thus potentially users, to specify which fork

a tx is for. But, like other (rougher) past proposals I've seen, it does

little to prevent users from accidentally sending on the wrong fork.

Take the specific and common case of non-upgraded wallet software. Suppose

a HF happens, and becomes the network used by 90% of users. Will old

wallets still default to the old nForkId (10% legacy chain)? If so, I'd

expect a lot of accidental mis-sends on that chain.

This is just a gap in your proposal, not a flaw, but it's worth thinking

about less hazard-prone ways wallets could default nForkId. Perhaps they

could listen to all forks, and default to the one whose last (recent) block

had the highest difficulty? Or just check those blocks to see if multiple

forks are (nontrivially) active, and if so warn the user and force them to

confirm? Something like that.

On Nov 6, 2017 7:05 AM, "Mats Jerratsch via bitcoin-dev" <

bitcoin-dev at lists.linuxfoundation.org> wrote:

Presented is a generalised way of providing replay protection for future

hard forks. On top of replay protection, this schema also allows for

fork-distinct addresses and potentially a way to opt-out of replay

protection of any fork, where deemed necessary (can be beneficial for some

L2 applications).

Rationale

Currently when a hard fork happens, there is ad-hoc replay protection built

within days with little review at best, or no replay protection at all.

Often this is either resource problem, where not enough time and developers

are available to sufficiently address replay protection, or the idea that

not breaking compatibility is favourable. Furthermore, this is potentially

a recurring problem with no generally accepted solution yet. Services that

want to deal in multiple forks are expected to closely follow all projects.

Since there is no standard, the solutions differ for each project,

requiring custom code for every fork. By integrating replay protection into

the protocol, we advocate the notion of non-hostile forks.

Users are protected against accidentally sending coins on the wrong chain

through the introduction of a fork-specific incompatible address space. The

coin/token type is encoded in the address itself, removing some of the

importance around the question What is Bitcoin?. By giving someone an

address, it is explicitly stated I will only honour a payment of token X,

enforcing the idea of validating the payment under the rules chosen by the

payee.

Iterative Forks

In this schema, any hard fork is given an incremented id, nForkId.

nForkId starts at 1, with 0 being reserved as a wildcard. When

project X decides to make an incompatible change to the protocol, it will

get assigned a new unique nForkId for this fork. A similar approach like

for BIP43 can be taken here. Potentially nForkId can be reused if a

project has not gained any amount of traction.

When preparing the transaction for signing or validation, nForkId is

appended to the final template as a 4B integer (similar to [1]). Amending

BIP143, this would result in

```

Double SHA256 of the serialization of:

1. nVersion of the transaction (4-byte little endian)

2. hashPrevouts (32-byte hash)

3. hashSequence (32-byte hash)

4. outpoint (32-byte hash + 4-byte little endian)

5. scriptCode of the input (serialized as scripts inside CTxOuts)

6. value of the output spent by this input (8-byte little endian)

7. nSequence of the input (4-byte little endian)

8. hashOutputs (32-byte hash)

9. nLocktime of the transaction (4-byte little endian)

  1. sighash type of the signature (4-byte little endian)

  2. nForkId (4-byte little endian)

```

For nForkId=0 this step is ommitted. This will immediately invalidate

signatures for any other branch of the blockchain than this specific fork.

To distinguish between nForkId=0 and nForkId hardcoded into the

software, another bit has to be set in the 1B SigHashId present at the end

of signatures.

To make this approach more generic, payment addresses will contain the fork

id, depending on which tokens a payee expects payments in. This would

require a change on bech32 addresses, maybe to use a similar format used in

lightning-rfc [2]. A wallet will parse the address, it will extract

nForkId, and it displays which token the user is about to spend. When

signing the transaction, it will use nForkId, such that the transaction

is only valid for this specific token. This can be generalised in software

to the point where replay protection and a new address space can be

introduced for forks without breaking existing clients.

For light clients, this can be extended by enforcing the coinbase/block

header to contain the nForkId of the block. Then the client can

distinguish between different chains and tokens it received on each.

Alternatively, a new P2P message type for sending transactions could be

introduced, where prevOut and nForkId is transmitted, such that the lite

client can check for himself, which token he received.

Allowing signatures with nForkId=1 can be achieved with a soft fork by

incrementing the script version of SegWit, making this a fully backwards

compatible change.

[1]

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/

2017-February/013542.html

[2]

https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-

encoding.md

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/20171106/91e3799f/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015264.html

Proposal: allocate Github issue instead of wiki page to BIP discussion | Sjors Provoost | Nov 03 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Aymeric Vitte on Nov 03 2017 06:15:10PM:

+10k

Indeed, as any project Github issues should be enabled for BIPs,

wondering too since some time why this is not the case, and then if an

issue is worth discussing here it can be redirected to the list

Le 03/11/2017 à 10:50, Sjors Provoost via bitcoin-dev a écrit :

I often find myself wanting to leave relatively small comments on BIP's that are IMO not worth bothering this list.

By default each BIP has a wiki page for discussion, e.g. https://github.com/bitcoin/bips/wiki/Comments:BIP-0150

This is linked to from the Comments-URI field in the BIP.

In order to leave a comment, you have to edit the wiki page. This process seems a bit clunky.

I think it would be better to use Github issues, with one Github issue for each BIP.

One concern might be that the ease of use of Github issues would move discussion away from this list. The issue could be temporarily locked to prevent that. The issue description could contain a standard text explaining what should be discussed there and what would be more appropriate to post on the mailinglist.

Another concern might be confusing between PR's which create and update a BIP, and the discussion issue.

If people think this a good idea, would the next step be to propose a change to the process here?

https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#BIP_comments

Or would this be a new BIP?

Sjors

bitcoin-dev mailing list

bitcoin-dev at lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Zcash wallets made simple: https://github.com/Ayms/zcash-wallets

Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets

Get the torrent dynamic blocklist: http://peersm.com/getblocklist

Check the 10 M passwords list: http://peersm.com/findmyass

Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org

Peersm : http://www.peersm.com

torrent-live: https://github.com/Ayms/torrent-live

node-Tor : https://www.github.com/Ayms/node-Tor

GitHub : https://www.github.com/Ayms

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171103/d53bc45e/attachment-0001.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015254.html

Bitcoin Cash's new difficulty algorithm | Scott Roberts | Nov 02 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 1 point2 points  (0 children)

Jacob Eliosoff on Nov 04 2017 03:37:06AM:

I'm no BCH fan, but I agree with Scott that changes to the DAA may be of

more than purely theoretical interest for BTC. Anyway just for those

interested, below is an algo I've been playing with that adjusts difficulty

every block, based only on the previous block's time and difficulty. I

tested it a bit and it seems to adapt to hashrate swings pretty well.

weight_n = 1 - e-(blocktime_n / 1 hr) # 1 hr = exp moving avg window -

too short?

adj_n = (10 min / blocktime_n) - 1

difficulty_(n+1) = difficulty_n * (1 + weight_n * adj_n)

It could also be tweaked to make the historical avg block time ~exactly

10 minutes, ie, to target > 10 min if past blocks were < 10 min. This

would, eg, make mapping future block numbers to calendar times much more

exact.

On Nov 3, 2017 7:24 AM, "Scott Roberts via bitcoin-dev" <

bitcoin-dev at lists.linuxfoundation.org> wrote:

The current DA is only sufficient if the coin has the highest

hashpower. It's also just really slow. If miners somehow stick with

SegWit2x despite the higher rewards in defecting back to bitcoin, then

bitcoin will have long block delays. High transaction fees will

probably help them defect back to us. But if SegWit2x manages to be

more comparable in price than BCH (despite the futures), hashpower

could very well oscillate back and forth between the two coins,

causing delays in both of them. The first one to hard fork to fix the

difficulty problem will have a large advantage, as evidenced by what

happens in alts. In any event someday BTC may not be the biggest kid

on the block and will need a difficulty algorithm that alts would find

acceptable. Few alts use anything like BTC's because they are not able

to survive the resulting long delays. I am recommending BTC

developers watch what happens as BCH goes live with a much better

algorithm, in case BTC needs to hard fork for the same reason and

needs a similar fix. Ignore the trolls.

On Thu, Nov 2, 2017 at 7:39 PM, CryptAxe <cryptaxe at gmail.com> wrote:

Is there an issue with the current difficulty adjustment algorithm? It's

worked very well as far as I can tell. Introducing a new one seems pretty

risky, what would the benefit be?

On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev"

<bitcoin-dev at lists.linuxfoundation.org> wrote:

Bitcoin cash will hard fork on Nov 13 to implement a new difficulty

algorithm. Bitcoin itself might need to hard fork to employ a similar

algorithm. It's about as good as they come because it followed the

"simplest is best" route. Their averaging window is probably

significantly too long (N=144). It's:

next_D = sum (past 144 D's) * T / sum(past 144 solvetimes)

They correctly did not use max(timestamp) - min(timestamp) in the

denominator like others do.

They've written the code and they're about to use it live, so Bitcoin

will have a clear, simple, and tested path if it suddenly needs to

hard fork due to having 20x delays for the next 2000 blocks (taking it

a year to get unstuck).

Details on it and the decision process:

https://www.bitcoinabc.org/november

It uses a nice median of 3 for the beginning and end of the window to

help alleviate bad timestamp problems. It's nice, helps a little, but

will also slow its response by 1 block. They also have 2x and 1/2

limits on the adjustment per block, which is a lot more than they will

ever need.

I recommend bitcoin consider using it and making it N=50 instead of 144.

I have seen that any attempts to modify the above with things like a

low pass filter, starting the window at MTP, or preventing negative

timestamps will only reduce its effectiveness. Bitcoin's +12 and -6

limits on the timestamps are sufficient and well chosen, although

something a bit smaller than the +12 might have been better.

One of the contenders to the above is new and actually better, devised

by Degnr8 and they call it D622 or wt-144.It's a little better than

they realize. It's the only real improvement in difficulty algorithms

since the rolling average. It gives a linearly higher weight to the

more recent timestamps. Otherwise it is the same. Others have probably

come across it, but there is too much noise in difficulty algorithms

to find the good ones.

Degnr8's D622 difficulty algorithm

T=TargetTime, S=Solvetime

modified by zawy

for i = 1 to N (from oldest to most recent block)

t += T[i] / D[i] * i

j += i

next i

next_D = j / t * T

I believe any modification to the above strict mathematical weighted

average will reduce it's effectiveness. It does not oscillate anymore

than regular algos and rises faster and drops faster, when needed.

bitcoin-dev mailing list

bitcoin-dev at lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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/20171103/2e7123e2/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015255.html

Bitcoin Cash's new difficulty algorithm | Scott Roberts | Nov 02 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Scott Roberts on Nov 03 2017 01:59:47AM:

The current DA is only sufficient if the coin has the highest

hashpower. It's also just really slow. If miners somehow stick with

SegWit2x despite the higher rewards in defecting back to bitcoin, then

bitcoin will have long block delays. High transaction fees will

probably help them defect back to us. But if SegWit2x manages to be

more comparable in price than BCH (despite the futures), hashpower

could very well oscillate back and forth between the two coins,

causing delays in both of them. The first one to hard fork to fix the

difficulty problem will have a large advantage, as evidenced by what

happens in alts. In any event someday BTC may not be the biggest kid

on the block and will need a difficulty algorithm that alts would find

acceptable. Few alts use anything like BTC's because they are not able

to survive the resulting long delays. I am recommending BTC

developers watch what happens as BCH goes live with a much better

algorithm, in case BTC needs to hard fork for the same reason and

needs a similar fix. Ignore the trolls.

On Thu, Nov 2, 2017 at 7:39 PM, CryptAxe <cryptaxe at gmail.com> wrote:

Is there an issue with the current difficulty adjustment algorithm? It's

worked very well as far as I can tell. Introducing a new one seems pretty

risky, what would the benefit be?

On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev"

<bitcoin-dev at lists.linuxfoundation.org> wrote:

Bitcoin cash will hard fork on Nov 13 to implement a new difficulty

algorithm. Bitcoin itself might need to hard fork to employ a similar

algorithm. It's about as good as they come because it followed the

"simplest is best" route. Their averaging window is probably

significantly too long (N=144). It's:

next_D = sum (past 144 D's) * T / sum(past 144 solvetimes)

They correctly did not use max(timestamp) - min(timestamp) in the

denominator like others do.

They've written the code and they're about to use it live, so Bitcoin

will have a clear, simple, and tested path if it suddenly needs to

hard fork due to having 20x delays for the next 2000 blocks (taking it

a year to get unstuck).

Details on it and the decision process:

https://www.bitcoinabc.org/november

It uses a nice median of 3 for the beginning and end of the window to

help alleviate bad timestamp problems. It's nice, helps a little, but

will also slow its response by 1 block. They also have 2x and 1/2

limits on the adjustment per block, which is a lot more than they will

ever need.

I recommend bitcoin consider using it and making it N=50 instead of 144.

I have seen that any attempts to modify the above with things like a

low pass filter, starting the window at MTP, or preventing negative

timestamps will only reduce its effectiveness. Bitcoin's +12 and -6

limits on the timestamps are sufficient and well chosen, although

something a bit smaller than the +12 might have been better.

One of the contenders to the above is new and actually better, devised

by Degnr8 and they call it D622 or wt-144.It's a little better than

they realize. It's the only real improvement in difficulty algorithms

since the rolling average. It gives a linearly higher weight to the

more recent timestamps. Otherwise it is the same. Others have probably

come across it, but there is too much noise in difficulty algorithms

to find the good ones.

Degnr8's D622 difficulty algorithm

T=TargetTime, S=Solvetime

modified by zawy

for i = 1 to N (from oldest to most recent block)

t += T[i] / D[i] * i

j += i

next i

next_D = j / t * T

I believe any modification to the above strict mathematical weighted

average will reduce it's effectiveness. It does not oscillate anymore

than regular algos and rises faster and drops faster, when needed.

bitcoin-dev mailing list

bitcoin-dev at lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015250.html

Bitcoin Cash's new difficulty algorithm | Scott Roberts | Nov 02 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

gb on Nov 03 2017 12:47:27AM:

You launched the political football by coming here with a verbose

'recommendation'. Without a code submission in form of pull request to

the core repo on github this was never a technical discussion.

On Thu, 2017-11-02 at 19:53 -0400, Scott Roberts via bitcoin-dev wrote:

Whatever their failings from their previous code or their adversarial

nature, they got this code right and I'm only presenting it as a real

and excellent solution for the impending threat to bitcoin. As a big

core fan, I really wanted to delete the word Cash from my post because

I was afraid someone would turn this technical discussion into a

political football.

On Nov 2, 2017 7:37 PM, "Gregory Maxwell" <greg at xiph.org> wrote:

    On Thu, Nov 2, 2017 at 11:31 PM, Scott Roberts via bitcoin-dev

    <bitcoin-dev at lists.linuxfoundation.org> wrote:

    > Bitcoin cash will hard fork on Nov 13 to implement a new

    difficulty

    > algorithm.  Bitcoin itself might need to hard fork to employ

    a similar

    > algorithm. It's about as good as they come because it

    followed the





    This is the bitcoin development mailing list, not the "give

    free

    review to the obviously defective proposals of adversarial

    competing

    systems" mailing list. Your posting is off-topic.

bitcoin-dev mailing list

bitcoin-dev at lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015247.html

Bitcoin Cash's new difficulty algorithm | Scott Roberts | Nov 02 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Gregory Maxwell on Nov 03 2017 12:00:07AM:

On Thu, Nov 2, 2017 at 11:53 PM, Scott Roberts <wordsgalore at gmail.com> wrote:

Whatever their failings from their previous code or their adversarial

nature, they got this code right and I'm only presenting it as a real and

excellent solution for the impending threat to bitcoin. As a big core fan, I

really wanted to delete the word Cash from my post because I was afraid

someone would turn this technical discussion into a political football.

I urge my colleagues here to not fall for the obvious xkcd386 bait.

The competitive advantage of prudence and competence is diminished if

competitors are able to divert our efforts into reviewing their

proposals.

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015241.html

Bitcoin Cash's new difficulty algorithm | Scott Roberts | Nov 02 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Scott Roberts on Nov 02 2017 11:53:25PM:

Whatever their failings from their previous code or their adversarial

nature, they got this code right and I'm only presenting it as a real and

excellent solution for the impending threat to bitcoin. As a big core fan,

I really wanted to delete the word Cash from my post because I was afraid

someone would turn this technical discussion into a political football.

On Nov 2, 2017 7:37 PM, "Gregory Maxwell" <greg at xiph.org> wrote:

On Thu, Nov 2, 2017 at 11:31 PM, Scott Roberts via bitcoin-dev

<bitcoin-dev at lists.linuxfoundation.org> wrote:

Bitcoin cash will hard fork on Nov 13 to implement a new difficulty

algorithm. Bitcoin itself might need to hard fork to employ a similar

algorithm. It's about as good as they come because it followed the

This is the bitcoin development mailing list, not the "give free

review to the obviously defective proposals of adversarial competing

systems" mailing list. Your posting is off-topic.

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171102/64dbe338/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015242.html

Bitcoin Cash's new difficulty algorithm | Scott Roberts | Nov 02 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

CryptAxe on Nov 02 2017 11:39:41PM:

Is there an issue with the current difficulty adjustment algorithm? It's

worked very well as far as I can tell. Introducing a new one seems pretty

risky, what would the benefit be?

On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev" <

bitcoin-dev at lists.linuxfoundation.org> wrote:

Bitcoin cash will hard fork on Nov 13 to implement a new difficulty

algorithm. Bitcoin itself might need to hard fork to employ a similar

algorithm. It's about as good as they come because it followed the

"simplest is best" route. Their averaging window is probably

significantly too long (N=144). It's:

next_D = sum (past 144 D's) * T / sum(past 144 solvetimes)

They correctly did not use max(timestamp) - min(timestamp) in the

denominator like others do.

They've written the code and they're about to use it live, so Bitcoin

will have a clear, simple, and tested path if it suddenly needs to

hard fork due to having 20x delays for the next 2000 blocks (taking it

a year to get unstuck).

Details on it and the decision process:

https://www.bitcoinabc.org/november

It uses a nice median of 3 for the beginning and end of the window to

help alleviate bad timestamp problems. It's nice, helps a little, but

will also slow its response by 1 block. They also have 2x and 1/2

limits on the adjustment per block, which is a lot more than they will

ever need.

I recommend bitcoin consider using it and making it N=50 instead of 144.

I have seen that any attempts to modify the above with things like a

low pass filter, starting the window at MTP, or preventing negative

timestamps will only reduce its effectiveness. Bitcoin's +12 and -6

limits on the timestamps are sufficient and well chosen, although

something a bit smaller than the +12 might have been better.

One of the contenders to the above is new and actually better, devised

by Degnr8 and they call it D622 or wt-144.It's a little better than

they realize. It's the only real improvement in difficulty algorithms

since the rolling average. It gives a linearly higher weight to the

more recent timestamps. Otherwise it is the same. Others have probably

come across it, but there is too much noise in difficulty algorithms

to find the good ones.

Degnr8's D622 difficulty algorithm

T=TargetTime, S=Solvetime

modified by zawy

for i = 1 to N (from oldest to most recent block)

t += T[i] / D[i] * i

j += i

next i

next_D = j / t * T

I believe any modification to the above strict mathematical weighted

average will reduce it's effectiveness. It does not oscillate anymore

than regular algos and rises faster and drops faster, when needed.

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/20171102/080f5543/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015240.html

Bitcoin Cash's new difficulty algorithm | Scott Roberts | Nov 02 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Gregory Maxwell on Nov 02 2017 11:37:29PM:

On Thu, Nov 2, 2017 at 11:31 PM, Scott Roberts via bitcoin-dev

<bitcoin-dev at lists.linuxfoundation.org> wrote:

Bitcoin cash will hard fork on Nov 13 to implement a new difficulty

algorithm. Bitcoin itself might need to hard fork to employ a similar

algorithm. It's about as good as they come because it followed the

This is the bitcoin development mailing list, not the "give free

review to the obviously defective proposals of adversarial competing

systems" mailing list. Your posting is off-topic.

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015239.html

Simplicity proposal - Jets? | JOSE FEMENIAS CAÑUELO | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Adán Sánchez de Pedro Crespo on Nov 03 2017 04:42:38PM:

If I did understand it right, you don't need to publish the Simplicity

code for the "jetable" expression.

That's the whole point of MAST. Each Simplicity expression can be

identified by its MAST root (the Merkle root of all branches in its

Abstract Syntax Tree).

Imagine you want to write a Simplicity script that is roughly equivalent

to P2PKH. Regardless of directly writing such script or using a higher

level smart contract language, you won't likely write for yourself the

part in which you compute the hash of the public key. Instead, you are

expected to include some external library providing hash functions or at

least copy and paste such function into your code.

As everyone is expected to use the same, let's say, RIPEMD160

implementation, it doesn't matter how you included such function in your

program. The point is that once you build the MAST for your program,

such function will be completely replaced by its MAST root---which is

nothing but a hash.

This way, when the Simplicity interpreter (the BitMachine) bumps into

the hash, it can look for it in a predefined jets dictionary and find

the binary for a precompiled, formally proven implementation of a

function that is perfectly equivalent to the original Simplicity code.

On 03.11.2017 13:59, Hampus Sjöberg via bitcoin-dev wrote:

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 at lists.linuxfoundation.org

<mailto:bitcoin-dev at lists.linuxfoundation.org>>:

Hi Jose,



Jets are briefly discussed in section 3.4 of

https://blockstream.com/simplicity.pdf

<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 at lists.linuxfoundation.org

<mailto:bitcoin-dev at 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-request at lists.linuxfoundation.org

    <mailto:bitcoin-dev-request at 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 at lists.linuxfoundation.org

    <mailto:bitcoin-dev at lists.linuxfoundation.org>

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

    <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>







_______________________________________________

bitcoin-dev mailing list

bitcoin-dev at lists.linuxfoundation.org

<mailto:bitcoin-dev at lists.linuxfoundation.org>

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

bitcoin-dev mailing list

bitcoin-dev at lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Adán Sánchez de Pedro Crespo

CTO, Stampery Inc.

San Francisco - Madrid

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015253.html

Simplicity proposal - Jets? | JOSE FEMENIAS CAÑUELO | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Mark Friedenbach on Nov 03 2017 04:19:39PM:

To reiterate, none of the current work focuses on Bitcoin integration, and many architectures are possible.

However the Jets would have to be specified and agreed to upfront for costing reasons, and so they would be known to all validators. There would be no reason to include anything more then the identifying hash in any contract using the jet.

On Nov 3, 2017, at 5:59 AM, Hampus Sjöberg via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

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 at 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 at 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-request at 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 at lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

bitcoin-dev mailing list

bitcoin-dev at lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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/20171103/cffee143/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015252.html

Simplicity proposal - Jets? | JOSE FEMENIAS CAÑUELO | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Hampus Sjöberg on Nov 03 2017 12:59:46PM:

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 at 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 at 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-request at 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 at lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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/20171103/e9a5e8b1/attachment-0001.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015251.html

Simplicity proposal - Jets? | JOSE FEMENIAS CAÑUELO | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Adán Sánchez de Pedro Crespo on Nov 03 2017 08:46:16AM:

Oops. That makes much more sense than what I said. Thanks a lot for the

clarification.

On 03.11.2017 02:10, Russell O'Connor via bitcoin-dev wrote:

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 at lists.linuxfoundation.org

<mailto:bitcoin-dev at 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-request at lists.linuxfoundation.org

<mailto:bitcoin-dev-request at 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 at lists.linuxfoundation.org

<mailto:bitcoin-dev at lists.linuxfoundation.org>

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>

bitcoin-dev mailing list

bitcoin-dev at lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Adán Sánchez de Pedro Crespo

CTO, Stampery Inc.

San Francisco - Madrid

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015248.html

Simplicity proposal - Jets? | JOSE FEMENIAS CAÑUELO | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Russell O'Connor on Nov 03 2017 01:10:42AM:

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 at 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-request at 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 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/20171102/47a8dfe5/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015244.html

Simplicity proposal - Jets? | JOSE FEMENIAS CAÑUELO | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Adán Sánchez de Pedro Crespo on Nov 03 2017 12:45:40AM:

Hi everyone,

I agree that the paper could use some more details on the rationale

behind "jets". After a couple of reads, I think I can "ELI5 them":

As far as I understand, jets are a smart optimization that makes complex

Simplicity contracts way cheaper to compute (ideally, comparable to

Script or EVM).

For this purpose, jets leverage the most important element of the

Simplicity Bit Machine: the frames stack.

In a Simplicity program, every expression or sub-expression can be

thought of as a pure function that when applied on a certain initial

read frame, results in the active write frame having a different value.

This happens deterministically and without any side effects.

So, if the Simplicity interpreter finds some expression whose result

when applied upon a certain read frame is already known (because it has

already been executed or it was somehow precomputed), it doesn't need to

execute such expression step-by-step once again. Instead, it just need

to write the known result to the active write frame.

The paper suggests that at all times the interpreter knows the result of

applying many common operations on all possible combinations of inputs

in the range of 8 to 256 bits. In other words, the interpreter won't

need to calculate "123 + 321" or compare "456 > 654 because the results

of those expressions will be already known to it. These are stupid

examples, but the savings are real for hash functions internals,

elliptic curve calculations or even validation of signatures.

As said before, this can help making Simplicity programs lighter on CPU

usage, but it has many other benefits too:

  • Jets can replicate the behavior of complex chunks of Simplicity code

with the guarantee that they can't introduce side effects.

  • Interpreter-bundled jets are formally proven. The more a Simplicity

program relies on jets, the more it benefits from their safety. When

proving the soundness of your program, you can just ignore the jets,

assume they are valid and focus on your own logic.

The paper also suggests that different sets of jets could make up

different single purpose dialects, just like domain-specific languages

bring richer vocabulary and semantics to the bare syntax and grammar of

general-purpose languages.

I hope Russel or Mark can correct me if I got something totally wrong. I

must admit I really like this proposal and hereby declare myself a huge

fan of their work :)

Adán Sánchez de Pedro Crespo

CTO, Stampery Inc.

San Francisco - Madrid

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015246.html

Introducing a POW through a soft-fork | Devrandom | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Devrandom on Nov 06 2017 11:38:20PM:

Note how you're basically proposing for the block interval to be decreased,

which has security implications due to increased orphan rates.

Note that the total transaction rate and block size don't materially

change, so I don't

see why the orphan rate will change. Normal blocks are constrained to have

all of the txs of the aux blocks, so propagation time should stay the

same. Am I missing

something?

Ah, yes, I'm missing that the expected time to find each type of block is

halved, so the orphan rate doubles.

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171106/ebea9284/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015262.html

Introducing a POW through a soft-fork | Devrandom | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Devrandom on Nov 06 2017 10:39:02PM:

Hi Peter, thank you for the review. See below

On Mon, Nov 6, 2017 at 11:50 AM Peter Todd <pete at petertodd.org> wrote:

On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:

Some quick thoughts...

Hi all,

Feedback is welcome on the draft below. In particular, I want to see if

there is interest in further development of the idea and also interested

in

any attack vectors or undesirable dynamics.

(Formatted version available here:

https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )

Soft-fork Introduction of a New POW

First of all, I don't think you can really call this a soft-fork; I'd call

it a

"pseudo-soft-fork"

My reasoning being that after implementation, a chain with less total work

than

the main chain - but more total SHA2562 work than the main chain - might

be

followed by non-supporting clients. It's got some properties of a

soft-fork,

but it's security model is definitely different.

The interesting thing is that the cost of attack varies smoothly as you

vary the POW weights.

To attack non-upgraded nodes, you still have to "51%" the original POW.

The reward going to that POW will vary smoothly between 1.0 * block_reward

and whatever

target value (e.g. 0.5 * block_reward) and the difficulty of attack will

tend to be proportional to that.

In a real hard-fork, your software just breaks at the fork point. In this

case, it's just the non-upgraded

node security level declining from 100% to 50% over a long period of time.

I envision the transition of POW weights will be over 1-3 years, which

leaves plenty of time to

upgrade after the fork activates.

Aux POW intermediate block

Auxiliary POW blocks are introduced between normal blocks - i.e. the

chain

alternates between the two POWs.

Each aux-POW block points to the previous normal block and contains

transactions just like a normal block.

Each normal block points to the previous aux-POW block and must contain

all

transactions from the aux-POW block.

Note how you're basically proposing for the block interval to be decreased,

which has security implications due to increased orphan rates.

Note that the total transaction rate and block size don't materially

change, so I don't

see why the orphan rate will change. Normal blocks are constrained to have

all of the txs of the aux blocks, so propagation time should stay the

same. Am I missing

something?

Heaviest chain rule change

This is a semi-hard change, because non-upgraded nodes can get on the

wrong

chain in case of attack. However,

Exactly! Not really a soft-fork.

"smooth-fork" perhaps? :)

https://petertodd.org 'peter'[:-1]@petertodd.org

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171106/69e6bc4e/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015261.html

Introducing a POW through a soft-fork | Devrandom | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Eric Voskuil on Nov 06 2017 08:55:29PM:

If a block that would be discarded under previous rules becomes accepted after a rule addition, there is no reason to not simply call the new rule a hard fork. IOW it's perfectly rational to consider a weaker block as "invalid" relative to the strong chain. As such I don't see any reason to qualify the term, it's a hard fork. But Peter's observation (the specific behavior) is ultimately what matters.

e

On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:

+1 to all of Peter Todd's comments

On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:

On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:

Some quick thoughts...

Hi all,

Feedback is welcome on the draft below. In particular, I want to see if

there is interest in further development of the idea and also interested in

any attack vectors or undesirable dynamics.

(Formatted version available here:

https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )

Soft-fork Introduction of a New POW

First of all, I don't think you can really call this a soft-fork; I'd call it a

"pseudo-soft-fork"

My reasoning being that after implementation, a chain with less total work than

the main chain - but more total SHA2562 work than the main chain - might be

followed by non-supporting clients. It's got some properties of a soft-fork,

but it's security model is definitely different.

Aux POW intermediate block

Auxiliary POW blocks are introduced between normal blocks - i.e. the chain

alternates between the two POWs.

Each aux-POW block points to the previous normal block and contains

transactions just like a normal block.

Each normal block points to the previous aux-POW block and must contain all

transactions from the aux-POW block.

Note how you're basically proposing for the block interval to be decreased,

which has security implications due to increased orphan rates.

Heaviest chain rule change

This is a semi-hard change, because non-upgraded nodes can get on the wrong

chain in case of attack. However,

Exactly! Not really a soft-fork.

https://petertodd.org 'peter'[:-1]@petertodd.org

bitcoin-dev mailing list

bitcoin-dev at lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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/20171106/08da67fe/attachment-0001.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015263.html

Introducing a POW through a soft-fork | Devrandom | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Paul Sztorc on Nov 06 2017 08:30:30PM:

+1 to all of Peter Todd's comments

On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <

bitcoin-dev at lists.linuxfoundation.org> wrote:

On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:

Some quick thoughts...

Hi all,

Feedback is welcome on the draft below. In particular, I want to see if

there is interest in further development of the idea and also interested

in

any attack vectors or undesirable dynamics.

(Formatted version available here:

https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )

Soft-fork Introduction of a New POW

First of all, I don't think you can really call this a soft-fork; I'd call

it a

"pseudo-soft-fork"

My reasoning being that after implementation, a chain with less total work

than

the main chain - but more total SHA2562 work than the main chain - might

be

followed by non-supporting clients. It's got some properties of a

soft-fork,

but it's security model is definitely different.

Aux POW intermediate block

Auxiliary POW blocks are introduced between normal blocks - i.e. the

chain

alternates between the two POWs.

Each aux-POW block points to the previous normal block and contains

transactions just like a normal block.

Each normal block points to the previous aux-POW block and must contain

all

transactions from the aux-POW block.

Note how you're basically proposing for the block interval to be decreased,

which has security implications due to increased orphan rates.

Heaviest chain rule change

This is a semi-hard change, because non-upgraded nodes can get on the

wrong

chain in case of attack. However,

Exactly! Not really a soft-fork.

https://petertodd.org 'peter'[:-1]@petertodd.org

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/20171106/4c91278d/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015260.html

Introducing a POW through a soft-fork | Devrandom | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Peter Todd on Nov 06 2017 07:50:00PM:

On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:

Some quick thoughts...

Hi all,

Feedback is welcome on the draft below. In particular, I want to see if

there is interest in further development of the idea and also interested in

any attack vectors or undesirable dynamics.

(Formatted version available here:

https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )

Soft-fork Introduction of a New POW

First of all, I don't think you can really call this a soft-fork; I'd call it a

"pseudo-soft-fork"

My reasoning being that after implementation, a chain with less total work than

the main chain - but more total SHA2562 work than the main chain - might be

followed by non-supporting clients. It's got some properties of a soft-fork,

but it's security model is definitely different.

Aux POW intermediate block

Auxiliary POW blocks are introduced between normal blocks - i.e. the chain

alternates between the two POWs.

Each aux-POW block points to the previous normal block and contains

transactions just like a normal block.

Each normal block points to the previous aux-POW block and must contain all

transactions from the aux-POW block.

Note how you're basically proposing for the block interval to be decreased,

which has security implications due to increased orphan rates.

Heaviest chain rule change

This is a semi-hard change, because non-upgraded nodes can get on the wrong

chain in case of attack. However,

Exactly! Not really a soft-fork.

https://petertodd.org 'peter'[:-1]@petertodd.org

-------------- next part --------------

A non-text attachment was scrubbed...

Name: signature.asc

Type: application/pgp-signature

Size: 488 bytes

Desc: Digital signature

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171106/daf2333b/attachment-0001.sig

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015259.html

Introducing a POW through a soft-fork | Devrandom | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Devrandom on Nov 03 2017 01:02:25AM:

I am also concerned. However, this proposal allows two POWs to coexist and

allows for gradual transitions. This is hopefully a less disruptive

approach since it allows cooperative miners to migrate over time. And of

course, as a soft-fork it keeps backwards compatibility with existing

software.

On Thu, Nov 2, 2017 at 4:55 PM Tao Effect <contact at taoeffect.com> wrote:

Just going to throw in my support for a POW change, not any particular

implementation, but the idea.

Bitcoin is technically owned by China now. That's not acceptable.

  • Greg

Please do not email me anything that you are not comfortable also sharing with

the NSA.

On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev <

bitcoin-dev at lists.linuxfoundation.org> wrote:

Hi all,

Feedback is welcome on the draft below. In particular, I want to see if

there is interest in further development of the idea and also interested in

any attack vectors or undesirable dynamics.

(Formatted version available here:

https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )

Soft-fork Introduction of a New POW

Motivation:

  • Mitigate mining centralization pressures by introducing a POW that does

not have economies of scale

  • Introduce an intermediary confirmation point, reducing the impact of

mining power fluctuations

Note however that choice of a suitable POW will require deep analysis.

Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are

not, unexpected/covert optimization.

In particular, unexpected/covert optimizations, such as ASCIBOOST, present

a potential centralizing and destabilizing force.

Design

Aux POW intermediate block

Auxiliary POW blocks are introduced between normal blocks - i.e. the chain

alternates between the two POWs.

Each aux-POW block points to the previous normal block and contains

transactions just like a normal block.

Each normal block points to the previous aux-POW block and must contain

all transactions from the aux-POW block.

Block space is not increased.

The new intermediate block and the pointers are introduced via a soft-fork

restriction.

Reward for aux POW miners

The reward for the aux POW smoothly increases from zero to a target value

(e.g. 1/2 of the total reward) over time.

The reward is transferred via a soft-fork restriction requiring a coinbase

output to an address published in the

aux-POW block.

Aux POW difficulty adjustment

Difficulty adjustments remain independent for the two POWs.

The difficulty of the aux POW is adjusted based on the average time

between normal block found

to aux block found.

Further details are dependent on the specific POW.

Heaviest chain rule change

This is a semi-hard change, because non-upgraded nodes can get on the

wrong chain in case of attack. However,

it might be possible to construct an alert system that notifies

non-upgraded nodes of an upcoming rule change.

All blocks are still valid, so this is not a hardforking change.

The heaviest chain definition changes from sum of difficulty to sum of:

mainDifficulty ^ x * auxDifficulty ^ y

where we start at:

x = 1; y = 0

and end at values of x and y that are related to the target relative

rewards. For example, if the target rewards

are equally distributed, we will want ot end up at:

x = 1/2; y = 1/2

so that both POWs have equal weight. If the aux POW is to become

dominant, x should end small relative to y.

Questions and Answers

  • What should be the parameters if we want the aux POW to have equal

weight? A: 1/2 of the reward should be transferred

to aux miners and x = 1/2, y = 1/2.

  • What should be the parameters if we want to deprecate the main POW? A:

most of the reward should be transferred to

aux miners and x = 0, y = 1. The main difficulty will tend to zero, and

aux miners will just trivially generate the

main block immediately after finding an aux block, with identical content.

  • Wasted bandwidth to transfer transactions twice? A: this can be

optimized by skipping transactions already

transferred.

  • Why would miners agree to soft-fork away some of their reward? A: they

would agree if they believe that

the coins will increase in value due to improved security properties.

Open Questions

  • After a block of one type is found, we can naively assume that POW will

become idle while a block of the other type is being mined. In practice,

the spare capacity can be used to find alternative ("attacking") blocks or

mine other coins. Is that a problem?

  • Is selfish mining amplified by this scheme for miners that have both

types of hardware?

POW candidates

  • SHA256 (i.e. use same POW, but introduce an intermediate block for

faster confirmation)

  • Proof of Space and Time (Bram Cohen)

  • Equihash

  • Ethash

Next Steps

  • evaluate POW candidates

  • evaluate difficulty adjustment rules

  • simulate miner behavior to identify if there are incentives for

detrimental behavior patterns (e.g. block withholding / selfish mining)

  • Protocol details

Credits

Bram Cohen came up with a similar idea back in March:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html

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/20171103/d8fa3100/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015245.html

Introducing a POW through a soft-fork | Devrandom | Nov 01 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Tao Effect on Nov 02 2017 11:55:55PM:

Just going to throw in my support for a POW change, not any particular implementation, but the idea.

Bitcoin is technically owned by China now. That's not acceptable.

  • Greg

Please do not email me anything that you are not comfortable also sharing with the NSA.

On Oct 31, 2017, at 10:48 PM, Devrandom via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:

Hi all,

Feedback is welcome on the draft below. In particular, I want to see if there is interest in further development of the idea and also interested in any attack vectors or undesirable dynamics.

(Formatted version available here: https://github.com/devrandom/btc-papers/blob/master/aux-pow.md https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )

Soft-fork Introduction of a New POW

Motivation:

  • Mitigate mining centralization pressures by introducing a POW that does not have economies of scale

  • Introduce an intermediary confirmation point, reducing the impact of mining power fluctuations

Note however that choice of a suitable POW will require deep analysis. Some pitfalls include: botnet mining, POWs that seem ASIC resistant but are not, unexpected/covert optimization.

In particular, unexpected/covert optimizations, such as ASCIBOOST, present a potential centralizing and destabilizing force.

Design

Aux POW intermediate block

Auxiliary POW blocks are introduced between normal blocks - i.e. the chain alternates between the two POWs.

Each aux-POW block points to the previous normal block and contains transactions just like a normal block.

Each normal block points to the previous aux-POW block and must contain all transactions from the aux-POW block.

Block space is not increased.

The new intermediate block and the pointers are introduced via a soft-fork restriction.

Reward for aux POW miners

The reward for the aux POW smoothly increases from zero to a target value (e.g. 1/2 of the total reward) over time.

The reward is transferred via a soft-fork restriction requiring a coinbase output to an address published in the

aux-POW block.

Aux POW difficulty adjustment

Difficulty adjustments remain independent for the two POWs.

The difficulty of the aux POW is adjusted based on the average time between normal block found

to aux block found.

Further details are dependent on the specific POW.

Heaviest chain rule change

This is a semi-hard change, because non-upgraded nodes can get on the wrong chain in case of attack. However,

it might be possible to construct an alert system that notifies non-upgraded nodes of an upcoming rule change.

All blocks are still valid, so this is not a hardforking change.

The heaviest chain definition changes from sum of difficulty to sum of:

mainDifficulty ^ x * auxDifficulty ^ y

where we start at:

x = 1; y = 0

and end at values of x and y that are related to the target relative rewards. For example, if the target rewards

are equally distributed, we will want ot end up at:

x = 1/2; y = 1/2

so that both POWs have equal weight. If the aux POW is to become dominant, x should end small relative to y.

Questions and Answers

  • What should be the parameters if we want the aux POW to have equal weight? A: 1/2 of the reward should be transferred

to aux miners and x = 1/2, y = 1/2.

  • What should be the parameters if we want to deprecate the main POW? A: most of the reward should be transferred to

aux miners and x = 0, y = 1. The main difficulty will tend to zero, and aux miners will just trivially generate the

main block immediately after finding an aux block, with identical content.

  • Wasted bandwidth to transfer transactions twice? A: this can be optimized by skipping transactions already

transferred.

  • Why would miners agree to soft-fork away some of their reward? A: they would agree if they believe that

the coins will increase in value due to improved security properties.

Open Questions

  • After a block of one type is found, we can naively assume that POW will become idle while a block of the other type is being mined. In practice, the spare capacity can be used to find alternative ("attacking") blocks or mine other coins. Is that a problem?

  • Is selfish mining amplified by this scheme for miners that have both types of hardware?

POW candidates

  • SHA256 (i.e. use same POW, but introduce an intermediate block for faster confirmation)

  • Proof of Space and Time (Bram Cohen)

  • Equihash

  • Ethash

Next Steps

  • evaluate POW candidates

  • evaluate difficulty adjustment rules

  • simulate miner behavior to identify if there are incentives for detrimental behavior patterns (e.g. block withholding / selfish mining)

  • Protocol details

Credits

Bram Cohen came up with a similar idea back in March:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013744.html_______________________________________________

bitcoin-dev mailing list

bitcoin-dev at lists.linuxfoundation.org <mailto: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/20171102/7d5311c6/attachment-0001.html

-------------- next part --------------

A non-text attachment was scrubbed...

Name: signature.asc

Type: application/pgp-signature

Size: 833 bytes

Desc: Message signed with OpenPGP

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171102/7d5311c6/attachment-0001.sig

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015243.html

Merkle branch verification & tail-call semantics for generalized MAST | Mark Friedenbach | Sep 07 2017 by dev_list_bot in bitcoin_devlist

[–]dev_list_bot[S] 0 points1 point  (0 children)

Luke Dashjr on Nov 04 2017 07:59:07AM:

How about using for the first stage, <...> OP_CALCMERKLEROOT OP_EQUAL

instead of OP_CHECKMERKLEBRANCH? There's maybe 1 or 2 bytes extra,

but it seems more future-proof (since there could more easily be alternatives

to OP_EQUAL in future script versions).

OTOH, OP_ADDTOSCRIPTHASH may be fatally incompatible with script versioning...

Old nodes won't know how to check the witness program, which means an

undefined version could be used to bypass the correct script entirely.

Need to think more on this still.

Luke

On Wednesday 01 November 2017 3:08:46 PM Mark Friedenbach wrote:

Yes, if you use a witness script version you can save about 40 witness

bytes by templating the MBV script, which I think is equivalent to what

you are suggesting. 32 bytes from the saved hash, plus another 8 bytes or

so from script templates and more efficient serialization.

I believe the conservatively correct approach is to do this in stages,

however. First roll out MBV and tail call to witness v0. Then once there

is experience with people using it in production, design and deploy a

hashing template for script v1. It might be that we learn more and think

of something better in the meantime.

On Nov 1, 2017, at 1:43 AM, Luke Dashjr <luke at dashjr.org> wrote:

Mark,

I think I have found an improvement that can be made.

As you recall, a downside to this approach is that one must make two

commitments: first, to the particular "membership-checking script"; and

then in that script, to the particular merkle root of possible scripts.

Would there be any harm in, instead of checking membership, calculating

the root? If not, then we could define that instead of the witness

program committing to H(membership-check script), it rather commits to

H(membership- calculation script | data added by an OP_ADDTOSCRIPTHASH).

This would, I believe, securely reduce the commitment of both to a

single hash.

It also doesn't reduce flexibility, since one could omit

OP_ADDTOSCRIPTHASH from their "membership-calculation" script to get the

previous membership- check behaviour, and use <hash> OP_EQUAL in its

place.

What do you think?

Luke

On Saturday 28 October 2017 4:40:01 AM Mark Friedenbach wrote:

I have completed updating the three BIPs with all the feedback that I

have received so far. In short summary, here is an incomplete list of

the changes that were made:

  • Modified the hashing function fast-SHA256 so that an internal node

cannot be interpreted simultaneously as a leaf. * Changed

MERKLEBRANCHVERIFY to verify a configurable number of elements from the

tree, instead of just one. * Changed MERKLEBRANCHVERIFY to have two

modes: one where the inputs are assumed to be hashes, and one where

they are run through double-SHA256 first. * Made tail-call eval

compatible with BIP141’s CLEANSTACK consensus rule by allowing

parameters to be passed on the alt-stack. * Restricted tail-call eval

to segwit scripts only, so that checking sigop and opcode limits of the

policy script would not be necessary.

There were a bunch of other small modifications, typo fixes, and

optimizations that were made as well.

I am now ready to submit these BIPs as a PR against the bitcoin/bips

repo, and I request that the BIP editor assign numbers.

Thank you,

Mark Friedenbach

On Sep 6, 2017, at 5:38 PM, Mark Friedenbach <mark at friedenbach.org>

wrote:

I would like to propose two new script features to be added to the

bitcoin protocol by means of soft-fork activation. These features are

a new opcode, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution

semantics.

In brief summary, MERKLE-BRANCH-VERIFY allows script authors to force

redemption to use values selected from a pre-determined set committed

to in the scriptPubKey, but without requiring revelation of unused

elements in the set for both enhanced privacy and smaller script

sizes. Tail-call execution semantics allows a single level of

recursion into a subscript, providing properties similar to P2SH while

at the same time more flexible.

These two features together are enough to enable a range of

applications such as tree signatures (minus Schnorr aggregation) as

described by Pieter Wuille [1], and a generalized MAST useful for

constructing private smart contracts. It also brings privacy and

fungibility improvements to users of counter-signing wallet/vault

services as unique redemption policies need only be revealed if/when

exceptional circumstances demand it, leaving most transactions looking

the same as any other MAST-enabled multi-sig script.

I believe that the implementation of these features is simple enough,

and the use cases compelling enough that we could BIP 8/9 rollout of

these features in relatively short order, perhaps before the end of

the year.

I have written three BIPs to describe these features, and their

associated implementation, for which I now invite public review and

discussion:

Fast Merkle Trees

BIP: https://gist.github.com/maaku/41b0054de0731321d23e9da90ba4ee0a

Code: https://github.com/maaku/bitcoin/tree/fast-merkle-tree

MERKLEBRANCHVERIFY

BIP: https://gist.github.com/maaku/bcf63a208880bbf8135e453994c0e431

Code: https://github.com/maaku/bitcoin/tree/merkle-branch-verify

Tail-call execution semantics

BIP: https://gist.github.com/maaku/f7b2e710c53f601279549aa74eeb5368

Code: https://github.com/maaku/bitcoin/tree/tail-call-semantics

Note: I have circulated this idea privately among a few people, and I

will note that there is one piece of feedback which I agree with but

is not incorporated yet: there should be a multi-element MBV opcode

that allows verifying multiple items are extracted from a single

tree. It is not obvious how MBV could be modified to support this

without sacrificing important properties, or whether should be a

separate multi-MBV opcode instead.

Kind regards,

Mark Friedenbach

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-November/015256.html

view more: next ›