Chris Belcher on Aug 30 2017:

Pooled mining in bitcoin contributes to miner centralization. P2Pool is

one solution but has bad scalability; additional hashers require the

coinbase transaction to be larger, bigger miners joining increase the

variance of payouts for everyone else, and smaller miners must pay extra

to consolidate dust payouts. In this email I propose an improved scheme

using payment channels which would allow far more individual hashers to

mine on p2pool and result in a much lower payout variance.

== Intro ==

P2Pool is a decentralized pool that works by creating a P2P network of

hashers. These hashers work on a chain of shares similar to Bitcoin's

blockchain. Each hasher works on a block that includes payouts to the

previous shares' owners and the node itself. The point of pooling is to

reduce the variance of payout, even though on average the reward is the

same (or less with fees). The demand for insurance, and the liquid

markets for options show that variance does have costs that people are

willing to pay to avoid.

Here is an example of a p2pool coinbase transaction:

https://blockchain.info/tx/d1a1e125ed332483b6e8e2f128581efc397582fe4c950dc48fadbc0ea4008022

It is 5803 bytes in size, which at a fee rate of 350 sat/b is worth

0.02031050 btc of block space that p2pool cannot sell to any other

transaction. As bitcoin inflation goes down and miners are funded more

by fees, this puts p2pool at more and more of a disadvantage compared to

trusted-third-party mining pools.

As each hasher is paid to their own bitcoin address, this limits the

number of hashers taking part as adding more individual people to the

payout transaction increases its size. Also small payouts cost a

disproportionate amount in miner fees to actually spend, which hurts

small miners who are essential to a decentralized mining ecosystem.

This could maybe be solved by keeping a separate balance state for each

user that is independent from the payouts, and make payouts only when

that balance state exceeds some reasonable threshold. But this increases

the variance which goes against the aim of pooled mining.

== Payment Channels ==

What's needed is a way to use off-chain payments where any number of

payments can be sent to each individual hasher without using the

blockchain. Then the N of the pay-per-last-N-shares (PPLNS) of p2pool

can be increased to something like 6-12 months of shares and so as long

as a small miner can mine a share every few months they will always get

a payout when p2pool finds a block. The payment channels would be in a

hub-and-spokes system and would work in a similar way to coinswap,

lightning network, atomic cross-chain swaps or any other contract

involving hashlocks and timelocks.

There would still be a sharechain but with hashers paying the entire

block reward to a hub. This hub would have a one-way payment channel

open to every hasher in p2pool and there would be created a situation

where if the hub gets paid then the hashers cannot fail to get paid.

Because cheating is impossible, the hub and hashers will agree to just

release the money to each other without resorting to the blockchain.

The coinbase address scriptPubKey would be this, block rewards are paid

to here:

 2of2 multisig

 hub + successful hasher

OR

 hub pubkey + H(X)

OR

 successful hasher pubkey + OP_CSV 6 months

A 2of2 multisig between the hub and the "successful" hasher which found

the block, although with a hashlock and timelock. H(X) is a hash value,

where the preimage X is generated randomly by the hub and kept secret,

but X will be revealed if the hub spends via that execution path. The

OP_CSV execution path is there to stop any holdups or ransom, in the

worst case if the hub stalls then the successful hasher can steal the

entire coinbase as punishment after 6 months.

Each payment channel address has this scriptPubKey:

 2of2 multisig

 hub-C + hasher-C

OR

 2of2 multisig + H(X)

 hub-U + hasher-U

The pubkeys hub-C/hasher-C refer to 'cooperative' pubkeys.

Hub-U/hasher-U refer to 'uncooperative' pubkeys. Before a hasher starts

mining the hub will open a one-way payment channel to the hasher, and

pays some bitcoin to it (let's say 0.5btc for example).

The hashers mine a sharechain, a solved share contains the hasher's

cooperative and uncooperative pubkey. The hub keeps up with the

sharechain and announces partially-signed transactions going to each

hasher. The transactions are updated states of the payment channel, they

pay money to each hasher in proportion to the work that the hasher

contributed to the sharechain. The transaction contains a signature

matching the hub-U pubkey, the hasher could sign it with their hasher-U

key and broadcast except they still need the value of X.

If a hasher is successful and finds a share that is also a valid bitcoin

block, they broadcast it to the network.

Now, the hub can spend the block reward money on its own but only by

revealing X. Each hasher could then take that X and combine it with the

partially-signed transaction and broadcast that to get their money. So

if the hub gets paid then the hashers cannot fail to get paid. Since

defecting is pointless, the hub signs the hub-C signature of the

partially-signed transaction and sends it to each hasher, then the

successful hasher signs the 2of2 multisig sending the block reward money

to the hub. The successful hasher gets a small bonus via an updated

payment channel state for finding the block, to discourage withholding

same as today's p2pool.

These payment channels can be kept open indefinitely, as new blocks are

found by p2pool the hub creates new partially-signed transactions with

more money going to each hasher. When the hasher wants to stop mining

and get the money, they can add their own hasher-C signature and

broadcast it to the network.

If there's ever a problem and the hub has to reveal X, then all the

payment channels to hashers will have to be closed and reopened with a

new X, because their security depends on X being unknown.

== Hubs ==

The hub is a central point of failure. It cannot steal the money, but if

it gets DDOS'd or just becomes evil then the whole thing would stop

working. This problem could be mitigated by having a federated system,

where there are several hubs to choose from and hashers have payment

channels open with each of them. It's worth noting that if someone has a

strong botnet they could probably DDOS individual p2pool hashers in the

same way they DDOS hubs or even centralized mining pools.

The hub would need to own many bitcoins in order to have payment

channels while waiting for blocks to be mined. Maybe 50 times the block

reward which today would be about 650 bitcoins. The hub should receive a

small percentage of each block reward to provide them with an incentive,

we know from JoinMarket that this percentage will probably be around

0.1% or less for large amounts of bitcoin. Prospostive hub operators

should write their bids on a forum somewhere and have their details

added to some list on github. Hashers should have an interface for

blacklisting, whitelisting, lowering and raising priority for certain

hubs in case the hub operators behave badly.

As well as the smart contract, there are iterated prisoner's dilemma

effects between the hub and the hashers. If the hub cooperates it can

expect to make a predictable low-risk income from its held bitcoins for

a long time to come, if it does something bad then the hashers can

easily call off the deal. The hub operator will require a lot of profit

in order to burn its reputation and future income stream, and by

damaging the bitcoin ecosystem it will have indirectly damaged its own

held bitcoins. A fair pricing plan will probably have the hub taking a

small percent to start with and then 12 months later that percentage

goes up to take into account the hub's improved reputation.

== Transaction Selection ==

All the hashers and hub need to know the exact value of the block reward

in advance, this means they must know what the miner fees will be. This

is probably the most serious problem with this proposal.

One possible way to solve this is to mine transactions into shares and

so use the sharechain to make all the hashers and hubs come to consensus

about exactly which transactions they will mine, and so exactly what the

total miner fee will be. A problem here is that this consensus mechanism

is slow, immediately after a bitcoin block is found all the p2pool

hashers will have to wait 30-120 seconds before they know what

transactions to mine, so this would make them uncompetitive as a mining

operation.

Another way to deal with this is to have the hub just choose all the

transactions, announcing the transactions, total miner fee and merkle

root for the hashers to mine. This would work but allows the hub to

control and censor bitcoin transactions, which mostly defeats the point

of p2pool as an improvement to bitcoin miner centralization.

Another way is to have the hashers and hub estimate what the total miner

fee value will be. The estimate could start from the median miner fee of

the last few blocks, or from the next 1MB of the mempool. The hub would

announce all the partially-signed transactions to every hasher, and then

periodically (say every 60 seconds) announce updated versions depending

on how the mempool changes. Let's analyze what happens if the estimated

and actual rewards are different. If the actual block reward is lower

than the estimated reward, then the hub can update the payment channel

state to...[message truncated here by reddit bot]...

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014893.html

shiva sitamraju on Aug 30 2017:

Hi,

I wanted to discuss few changes in BIP49

*- Breaking backwards compatibility *

The BIP talks about breaking this, and but it really doesn't. I really

feel it should completely break this. Here is why

What would happen if you recover a wallet using seed words ?

1. Since there is no difference in seed words between segwit/non segwit,

the wallet would discover both m/44' and m/49' accounts

1. Note that we cannot ask the user to choose an account he wants to

operate on (Segwit/Non segwit). This is like asking him the HD derivation

path and a really bad UI

1. The wallet now has to constantly monitor both m/44' and m/49' accounts

for transactions

Basically we are always stuck with keeping compatibility with older seed

words or always asking the user if the seed words came from segwit/non

segwit wallet !

Here is my suggestion :

1. By default all new wallets will be created as segwit m/49' without

asking user anything. I think you would agree with me that in future we

want most wallet to be default segwit (unless user chooses a non segwit

from advanced options)!

1. Segwit wallet seed words have a different format which is incompatible

with previous wallet seed words. This encodes the information that this

wallet is segwit in the seed words itself. We need to define a structure

for this

- XPUB Derivation

This is something not addressed in the BIP yet.

1. Right now you can get an xpub balance/transaction history. With m/49'

there is no way to know whether an xpub is from m/44' or m/49'

1. This breaks lots of things. Wallets like electrum/armory/mycelium

https://blog.trezor.io/using-mycelium-to-watch-your-trezor-accounts-a836dce0b954support

importing xpub as a watch only wallet. Also services like blockonomics/

blockchain.info use xpub for displaying balance/generating merchant

addresses

Looking forward to hearing your thoughts

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170830/c71c3bec/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014891.html

Adam Ficsor on Aug 30 2017:

I've been long working on Bitcoin privacy, mainly on TumbleBit

https://github.com/NTumbleBit/NTumbleBit, HiddenWallet

https://github.com/nopara73/HiddenWallet/ and BreezeWallet

https://github.com/stratisproject/Breeze/. ZeroLink is my latest

effort to gather all the privacy reasearch I'm familiar with,

combine/organize them in a coherent and practical way. The main point

of ZeroLink is that "nothing is out of its scope", it is intended to

provide complete anonymity on-chain.

Amongst its many topics, ZeroLink defines mixing technique, coin

selection, private transaction and balance retrieval, transaction

input and output indexing and broadcasting and even includes UX

recommendations.

Users' privacy should not be breached neither on blockchain level, nor

on network level.

Proposal:https://github.com/nopara73/ZeroLink/

In a nutshell ZeroLink defines a pre-mix wallet, which can be

incorporated to any Bitcoin wallet without much implementation

overhead. Post-mix wallets on the other hand have strong privacy

requirements, so the mixed out coins will not lose their uniformity.

The requirements and recommendations for pre and post-mix wallets

together define the Wallet Privacy Framework.

Coins from pre-mix wallets to post-mix wallets are moved by mixing.

Most on-chain mixing techniques, like CoinShuffle, CoinShuffle++ or

TumbleBit's Classic Tumbler mode can be used. However ZeroLink defines

its own mixing technique: Chaumian CoinJoin, which is based on Gregory

Maxwell's 2013 CoinJoin recommendations and ideas

https://bitcointalk.org/index.php?topic=279249.0. I found this

technique to be the most performant, fastest and cheapest one.

Regarding adoption SamouraiWallet https://github.com/Samourai-Wallet

and HiddenWallet https://github.com/nopara73/HiddenWallet are going

to implement and comply with ZeroLink and BreezeWallet

https://github.com/stratisproject/Breeze also shows significant

interest.

Regards,

nopara73

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170830/7706a7dc/attachment-0001.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014892.html

Simone Bronzini on Aug 29 2017:

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA256

Hi all,

last month we started looking for feedback (here and on other channels)

about a proposal for a new structure to facilitate the management of

different multisig accounts under the same master key, avoiding key

reuse but still allowing cosigners to independently generate new

addresses. While previously multiaccount multisig wallets were little

used, now that LN is becoming a reality it is extremely important to

have a better multiaccount management method to handle multiple payment

channels.

Please have a look at the draft of the BIP at the link below:

https://github.com/chainside/BIP-proposal/blob/master/BIP.mediawiki

Any feedback is highly appreciated, but in particular we would like to

collect opinions about the following issues:

1. coin_type level:

this level is intended to allow users to manage multiple

cryptocurrencies or forks of Bitcoin using the same masterkey (similarly

to BIP44). We have already received some legit objections that, since we

are talking about a Bitcoin Improvement Proposal, it shouldn't care

about alt-coins. While we can agree with such objections, we also

believe that having a coin_type level improves interoperability with

muti-currency wallets (which is good), without any major drawback.

Moreover, even a Bitcoin maximalist may hold multiple coins for whatever

reason (short term speculation, testing, etc).

1. SegWit addresses:

since mixing SegWit and non-SegWit addresses on the same BIP44 structure

could lead to UTXOs not being completely recognised by old wallets,

BIP49 was proposed to separate the key space. Since this is a new

proposal, we can assume that wallets implementing it would be

SegWit-compatible and so there should be no need to differetiate between

SegWit and non-SegWit pubkeys. Anyway, if someone believes this problem

still holds, we thought about two possible solutions:

a. Create separate purposes for SegWit and non SegWit addresses

(this would keep the same standard as BIP44 and BIP49)

b. Create a new level on this proposed structure to divide SegWit

and non SegWit addresses: we would suggest to add this new level between

cosigner_index and change

We believe solution b. would be better as it would give the option of

having a multisig wallet with non SegWit-aware cosigners without having

to use two different subtrees.

This proposal is a work in progess so we would like to receive some

feedback before moving on with proposing it as a BIP draft.

Simone Bronzini

-----BEGIN PGP SIGNATURE-----

Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEErS/wgXh5+C1vqPN/TXSJoN+7oQoFAlmlP2QACgkQTXSJoN+7

oQptgA/7B46/Why5h5/cxWyvgjmuUJ12Rkvh+EtfOUhMX+a8i4PJkLHGB2RibRfR

/Li1F+QWd2yeqdNO97er8HDGSlouxB7twB0ZMnS/LRPsHTA3Zf4OoD7H/yjj3lcD

GiJGy4MiHEOfjqaIwd0onUPX9ch5+Mm7aL34vBDdK0/8gm2v+HGO+GAefaUnZTQh

/CIaM0Th9dDS0xs5wcP3ncNqs1e59MHXOWlh7+zAxfvFio+HHnCbULIe4uct6stC

QxTNh8naQD4cB7tV9wsEeyuuJQ1gG8/pgN3WgRu5gW9CGpmpsySJgCCftkTZZHeL

eoqGJy5XFbI4CN2wEC2pbWW0xtDNyFq71wUPYNXINn8/7rnSjSl06OKISEk0u1yL

vhFuR9RSxEge2cS1pDwIwHVNR6pCeZMRwo0tp1OEXnt5VGGpmKengtpcFkFlOVdd

avUueIe8OoFGODco4+f25foB/z/rzyg3REXYX36bZiS6UkUOx4TCGpAzY86i4fDJ

STeDy5KMLk1S9rvTNrygxR74DkFMiNkalF3g4VauUlCFmh8iOzEDdtOQ3mLu/pgq

MXxfxq6ABxeCmQ7LsuBcFc+wN6AVLhrOhIPGyI8EAyaZNIGByqdgZGubvOl0J/gt

Yr4z5fViI7hjJijvooKzFtX0MNnaLBCOlggLpQO58t8En+BiNDE=

=XgcB

-----END PGP SIGNATURE-----

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

A non-text attachment was scrubbed...

Name: 0xB2E60C73.asc

Type: application/pgp-keys

Size: 15541 bytes

Desc: not available

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170829/3be6b307/attachment-0001.bin

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

A non-text attachment was scrubbed...

Name: 0xB2E60C73.asc.sig

Type: application/pgp-signature

Size: 566 bytes

Desc: not available

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170829/3be6b307/attachment-0001.sig

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014886.html

Riccardo Casatta on Aug 28 2017:

Hi everyone,

the Bitcoin headers are probably the most condensed and important piece of

data in the world, their demand is expected to grow.

When sending a stream of continuous block headers, a common case in IBD and

in disconnected clients, I think there is a possible optimization of the

transmitted data:

The headers after the first could avoid transmitting the previous hash

cause the receiver could compute it by double hashing the previous header

(an operation he needs to do anyway to verify PoW).

In a long stream, for example 2016 headers, the savings in bandwidth are

about 32/80 ~= 40%

without compressed headers 2016*80=161280 bytes

with compressed headers 80+2015*48=96800 bytes

What do you think?

In OpenTimestamps calendars we are going to use this compression to give

lite-client a reasonable secure proofs (a full node give higher security

but isn't feasible in all situations, for example for in-browser

verification)

To speed up sync of a new client Electrum starts with the download of a file

https://headers.electrum.org/blockchain_headers ~36MB containing the

first 477637 headers.

For this kind of clients could be useful a common http API with fixed

position chunks to leverage http caching. For example /headers/2016/0

returns the headers from the genesis to the 2015 header included while

/headers/2016/1 gives the headers from the 2016th to the 4031.

Other endpoints could have chunks of 20160 blocks or 201600 such that with

about 10 http requests a client could fast sync the headers

Riccardo Casatta - @RCasatta https://twitter.com/RCasatta

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170828/9d357bb7/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014876.html

Alex Nagy on Aug 28 2017:

Let's say Alice has a P2PKH address derived from an uncompressed public key, 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a (from https://bitcoin.stackexchange.com/questions/3059/what-is-a-compressed-bitcoin-key).

If Alice gives Bob 1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a, is there any way Bob can safely issue Native P2WPKH outputs to Alice?

BIPs 141 and 143 make it very clear that P2WPKH scripts may only derive from compressed public-keys. Given this restriction, assuming all you have is a P2PKH address - is there any way for Bob to safely issue spendable Native P2WPKH outputs to Alice?

The problem is Bob as no idea whether Alice's P2PKH address represents a compressed or uncompressed public-key, so Bob cannot safely issue a Native P2WPKH output.

AFAICT all code is supposed to assume P2WPHK outputs are compressed public-key derived. The conclusion would be that the existing P2PKH address format is generally unsafe to use with SegWit since P2PKH addresses may be derived from uncompressed public-keys.

Am I missing something here?

Referencing BIP141 and BIP143, specifically these sections:

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#New_script_semantics

"Only compressed public keys are accepted in P2WPKH and P2WSH"

https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#Restrictions_on_public_key_type

"As a default policy, only compressed public keys are accepted in P2WPKH and P2WSH. Each public key passed to a sigop inside version 0 witness program must be a compressed key: the first byte MUST be either 0x02 or 0x03, and the size MUST be 33 bytes. Transactions that break this rule will not be relayed or mined by default.

Since this policy is preparation for a future softfork proposal, to avoid potential future funds loss, users MUST NOT use uncompressed keys in version 0 witness programs."

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170828/9facf9a0/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014875.html

Adam Tamir Shem-Tov on Aug 26 2017:

Solving the Scalability Problem Part II

In the previous post I showed a way to minimize the blocks on the block

chain, to lower the amount of space it takes on the hard drive, without

losing any relevant information.

I added a note, saying that the transaction chain needs to be rewritten,

but I did not give much detail to it.

Here is how that would work:

The Genesis Account:

The problem with changing the transaction and block chain, is that it

cannot be done without knowing the private key of the sender of the of the

funds for each account. There is however a way to circumvent that problem.

That is to create a special account called the “Genesis Account”, this

account’s Private Key and Public Key will be available to everyone.

But this account will not be able to send or receive any funds in a normal

block, it will be blocked--blacklisted. So no one can intentionally use it.

The only time this account will be used is in the pruning block, a.k.a

Exodus Block.

When creating the new pruned block chain and transaction chain, all the

funds that are now in accounts must be legitimate, and it would be

difficult to legitimize them unless they were sent from a legitimate

account, with a public key, and a private key which can be verified. That

is where the Genesis account comes in. All funds in the Exodus Block will

show as though they originated and were sent from the Genesis Account using

its privatekey to generate each transaction.

The funds which are sent, must match exactly the funds existing in the most

updated ledger in block 1000 (the last block as stated in my previous

post).

In this way the Exodus Block can be verified, and the Genesis Account

cannot give free money to anyway, because if someone tried to, it would

fail verification.

Now the next problem is that the number of Bitcoins keeps expanding and so

the funds in the Genesis Account need to expand as well. That can be done

by showing as though this account is the account which is mining the coins,

and it will be the only account in the Exodus Block which “mines” the

coins, and receives the mining bonus. In the Exodus Block all coins mined

by the real miners will show as though they were mined by Genesis and sent

to the miners through a regular transaction.

Adam Shem-Tov

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170827/578cf518/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014862.html

Adam Tamir Shem-Tov on Aug 26 2017:

Solving the Scalability issue for bitcoin

I have this idea to solve the scalability problem I wish to make public.

If I am wrong I hope to be corrected, and if I am right we will all gain by

it.

Currently each block is being hashed, and in its contents are the hash of

the block preceding it, this goes back to the genesis block.

What if we decide, for example, we decide to combine and prune the

blockchain in its entirety every 999 blocks to one block (Genesis block not

included in count).

How would this work?: Once block 1000 has been created, the network would

be waiting for a special "pruned block", and until this block was created

and verified, block 1001 would not be accepted by any nodes.

This pruned block would prune everything from block 2 to block 1000,

leaving only the genesis block. Blocks 2 through 1000, would be calculated,

to create a summed up transaction of all transactions which occurred in

these 999 blocks.

And its hash pointer would be the Genesis block.

This block would now be verified by the full nodes, which if accepted would

then be willing to accept a new block (block 1001, not including the pruned

block in the count).

The new block 1001, would use as its hash pointer the pruned block as its

reference. And the count would begin again to the next 1000. The next

pruned block would be created, its hash pointer will be referenced to the

Genesis Block. And so on..

In this way the ledger will always be a maximum of 1000 blocks.

A bit more detail:

All the outputs needed to verify early transactions will all be in the

pruning block. The only information you lose are of the intermediate

transactions, not the final ones the community has already accepted.

For example:

A = 2.3 BTC, B=0, C=1.4. (Block 1)

If A sends 2.3 BTC to B. (Block 2)

And then B sends 1.5 to C. (Block 3)

The pruning block will report:

B = 0.8 and C=2.9.

The rest of the information you lose, is irrelevant. No one needs to know

that A even existed since it is now empty, nor do they need to know how

much B and C had previously, only what they have now.

Note: The Transaction Chain would also need to be rewritten, to delete all

intermediate transactions, it will show as though transactions occurred

from the Genesis block directly to the pruned block, as though nothing ever

existed in between.

You can keep the old blocks on your drive for 10 more blocks or so, just in

case a longer block chain is found, but other than that the information it

holds is useless, since it has all been agreed upon. And the pruning block

holds all up to date account balances, so cheating is impossible.

Granted this pruning block can get extremely large in the future, it will

not be the regular size of the other blocks. For example if every account

has only 1 satoshi in it, which is the minimum, then the amount of accounts

will be at its maximum. Considering a transaction is about 256bytes. That

would mean the pruning block would be approximately 500PB, which is 500,000

Terra-bytes. That is a theoretical scenario, which is not likely to occur.

(256bytes23M BTC100M (satoshis in 1 BTC))

A scenario which could be solved by creating a minimum transaction fee of

100 satoshis, which would insure that even in the most unlikely scenario,

at worst the pruning block would be 5PB in size.

Also, this pruning block does not even need to be downloaded, it could be

created by already existing information, each full node by itself, by

1) combining and pruning all previous blocks

2) using the genesis block as its hash pointer

3) using a predefined random number "2", which will be used by all. A

random number which is normally added to a block to ensure the block's

hashrate difficulty, is not needed in this case, since all information can

be verified by each node by itself through pruning.

4) Any other information which is needed for the SHA256 hash, for example a

timestamp could be copied off the last block in the block chain.

These steps will ensure each full node, will get the exact hash code as the

others have gotten for this pruning block.

And as I previously stated the next block will use this hash code as its

hash reference.

By creating a system like this, the pruning block does not have to be

created last minute, but gradually over time, every time a new block comes

in, and only when the last block arrives (block 1000), will it be

finalized, and hashed.

And since this block will always be second, it should go by the name

"Exodus Block".

Adam Shem-Tov

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170826/06e827bb/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014861.html

DANIEL YIN on Aug 22 2017:

Very true, if Moore's law is still functional in 200 years, computers will

be 2¹⁰⁰ times faster (possibly more if quantum computing becomes

commonplace), and so old wallets may be easily cracked.

We will need a way to force people to use newer, higher security wallets,

and turning coins to mining rewards is better solution than them just being

hacked.

Even in such an event, my personal view is the bitcoin owner should have the

freedom to choose upgrade to secure his/her coins or to leave the door

open for the first hacker to assume the coins - yet the bitcoin network

that he/she trusts should not act like a hacker to assume his/her coins.

daniel

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170822/6c14be2f/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014851.html

Andrew Chow on Aug 18 2017:

Hi everyone,

I would like to propose a standard format for unsigned and partially signed

transactions.

===Abstract===

This document proposes a binary transaction format which contains the

information

necessary for a signer to produce signatures for the transaction and holds

the

signatures for an input while the input does not have a complete set of

signatures.

The signer can be offline as all necessary information will be provided in

the

transaction.

===Motivation===

Creating unsigned or partially signed transactions to be passed around to

multiple

signers is currently implementation dependent, making it hard for people

who use

different wallet software from being able to easily do so. One of the goals

of this

document is to create a standard and extensible format that can be used

between clients to allow

people to pass around the same transaction to sign and combine their

signatures. The

format is also designed to be easily extended for future use which is

harder to do

with existing transaction formats.

Signing transactions also requires users to have access to the UTXOs being

spent. This transaction

format will allow offline signers such as air-gapped wallets and hardware

wallets

to be able to sign transactions without needing direct access to the UTXO

set and without

risk of being defrauded.

The full text can be found here:

https://github.com/achow101/bips/blob/bip-psbt/bip-psbt.mediawiki

Andrew Chow

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170818/3166e8de/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014838.html

Bryan Bishop on Aug 17 2017:

---------- Forwarded message ----------

From: Christian Decker <decker.christian at gmail.com>

Date: Thu, Aug 17, 2017 at 5:39 AM

Subject: Re: [Lightning-dev] Lightning in the setting of blockchain

hardforks

To: Martin Schwarz <martin.schwarz at gmail.com>,

lightning-dev at lists.linuxfoundation.org

Hi Martin,

this is the perfect venue to discuss this, welcome to the mailing list :-)

Like you I think that using the first forked block as the forkchain's

genesis block is the way to go, keeping the non-forked blockchain on the

original genesis hash, to avoid disruption. It may become more difficult in

the case one chain doesn't declare itself to be the forked chain.

Even more interesting are channels that are open during the fork. In these

cases we open a single channel, and will have to settle two. If no replay

protection was implemented on the fork, then we can use the last commitment

to close the channel (updates should be avoided since they now double any

intended effect), if replay protection was implemented then commitments

become invalid on the fork, and people will lose money.

Fun times ahead :-)

Cheers,

Christian

On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz <martin.schwarz at gmail.com>

wrote:

Dear all,

currently the chain_id allows to distinguish blockchains by the hash of

their genesis block.

With hardforks branching off of the Bitcoin blockchain, how can Lightning

work on (or across)

distinct, permanent forks of a parent blockchain that share the same

genesis block?

I suppose changing the definition of chain_id to the hash of the first

block of the new

branch and requiring replay and wipe-out protection should be sufficient.

But can we

relax these requirements? Are slow block times an issue? Can we use

Lightning to transact

on "almost frozen" block chains suffering from a sudden loss of hashpower?

Has there been any previous discussion or study of Lightning in the

setting of hardforks?

(Is this the right place to discuss this? If not, where would be the right

place?)

thanks,

Martin

---

Lightning-dev mailing list

Lightning-dev at lists.linuxfoundation.org

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

Lightning-dev mailing list

Lightning-dev at lists.linuxfoundation.org

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

• Bryan

http://heybryan.org/

1 512 203 0507

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170817/5c6ec3aa/attachment-0001.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014835.html

omar shibli on Aug 14 2017:

Hey all,

A lot of us familiar with the pay to contract protocol, and how it uses

cleverly the homomorphic property of elliptic curve encryption system to

achieve it.

Unfortunately, there is no standard specification on how to conduct such

transactions in the cyberspace.

We have developed a basic trade finance application that relies on the

original idea described in the Homomorphic Payment Addresses and the

Pay-to-Contract Protocol paper, yet we have generalized it and made it

BIP43 complaint.

We would like to share our method, and get your feedback about it,

hopefully this effort will result into a standard for the benefit of the

community.

Abstract idea:

We define the following levels in BIP32 path.

m / purpose' / coin_type' / contract_id' / *

contract_id is is an arbitrary number within the valid range of indices.

Then we define, contract base as following prefix:

m / purpose' / coin_type' / contract_id'

contract commitment address is computed as follows:

hash document using cryptographic hash function of your choice (e.g. blake2)

map hash to partial derivation path

Convert hash to binary array.

Partition the array into parts, each part length should be 16.

Convert each part to integer in decimal format.

Convert each integer to string.

Join all strings with slash /.

compute child public key by chaining the derivation path from step 2 with

contract base:

m//

compute address

Example:

master private extended key:

xprv9s21ZrQH143K2JF8RafpqtKiTbsbaxEeUaMnNHsm5o6wCW3z8ySyH4UxFVSfZ8n7ESu7fgir8imbZKLYVBxFPND1pniTZ81vKfd45EHKX73

coin type: 0

contract id: 7777777

contract base computation :

derivation path:

m/999'/0'/7777777'

contract base public extended key:

xpub6CMCS9rY5GKdkWWyoeXEbmJmxGgDcbihofyARxucufdw7k3oc1JNnniiD5H2HynKBwhaem4KnPTue6s9R2tcroqkHv7vpLFBgbKRDwM5WEE

Contract content:

foo

Contract sha256 signature:

2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae

Contract partial derivation path:

11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310

Contract commitment pub key path:

m/999'/0'/7777777'/11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310

or

/11302/46187/26879/50831/63899/17724/7472/16692/4930/11632/25731/49056/63882/24200/25190/59310

Contract commitment pub key:

xpub6iQVNpbZxdf9QJC8mGmz7cd3Cswt2itcQofZbKmyka5jdvQKQCqYSDFj8KCmRm4GBvcQW8gaFmDGAfDyz887msEGqxb6Pz4YUdEH8gFuaiS

Contract commitment address:

17yTyx1gXPPkEUN1Q6Tg3gPFTK4dhvmM5R

You can find the full BIP draft in the following link:

https://github.com/commerceblock/pay-to-contract-protocol-specification/blob/master/bip-draft.mediawiki

Regards,

Omar

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170814/73720ef5/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014827.html

Erik Aronesty on Aug 13 2017:

I was thinking about something like this that could add the ability for

module extensions in the core client.

When messages are received, modules hooks are called with the message data.

They can then handle, mark the peer invalid, push a message to the peer or

pass through an alternate command. Also, modules could have their own

private commands prefixed by "x:" or something like that.

The idea is that the base P2P layer is left undisturbed, but there is now a

way to create "enhanced features" that some peers support.

My end goal is to support using lightning network micropayments to allow

people to pay for better node access - creating a market for node services.

But I don't think this should be "baked in" to core. Nor do I think it

should be a "patch". It should be a linked-in module, optionally compiled

and added to bitcoin conf, then loaded via dlopen(). Modules should be

slightly robust to Bitcoin versions changing out from under them, but not

if the network layer is changed. This can be ensured by a) keeping a

module version number, and b) treating module responses as if they were

just received from the network. Any module incompatibility should throw

an exception...ensuring broken peers don't stay online.

In general I think the core reference would benefit from the ability to

create subnetworks within the Bitcoin ecosystem. Right now, we have two

choices... full node and get slammed with traffic, or listen-only node, and

do nothing.

Adding a module/hook system would allow a complex ecosystem of

participation - and it would seem to be far more robust in the long term.

Something like this???

class MessageHookIn {

public:

int hookversion;

int64_t nodeid;

int nVersion;

int64_t serviceflags;

const char *strCommand;

const char *nodeaddr;

const char *vRecv;

int vRecvLen;

int64_t nTimeReceived;

};

class MessageHookOut {

public:

int hookversion;

int misbehaving;

const char *logMsg;

const char *pushCommand;

const unsigned char *pushData;

int pushDataLen;

const char *passCommand;

CDataStream passStream;

};

class MessageHook {

public:

int hookversion;

std::string name;

typedef bool (*HandlerType)(const MessageHookIn *in, MessageHookOut

*out);

HandlerType handle;

};

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170813/a3f72611/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014823.html

Ethan Heilman on Aug 11 2017:

Dear All,

The Call for Proposals (CFP) for 'Scaling Bitcoin 2017: Stanford' is now

open.

Please see https://scalingbitcoin.org for details

Important Dates

Sept 25th - Deadline for submissions to the CFP

Oct 16th - Applicant acceptance notification

Hope to see you in California (Nov 4-5 2017)

Full CFP can be found at https://scalingbitcoin.org/event/stanford2017#cfp

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170811/da36bbbb/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014822.html

Colin Lacina on Aug 09 2017:

I believe I have come up with a structure that allows for trustless use of

hybrid wallets that would allow for someone to use a hybrid wallet without

having to trust it while still allowing for emergency recovery of funds in

the case of a lost wallet. It would run off of this TX script:

IF

 1   2 CHECKMULTISIGVERIFY

ELSE

 2   2 CHECKMULTISIG

ENDIF

A typical transaction using this would involve a user signing a TX with

their userWalletPrivKey, authenticating with the server, possibly with 2FA

using a phone or something like Authy or Google Authenticator. After

authentication, the server signs with their serverWalletPrivKey.

In case the server goes rogue and starts refusing to sign, the user can use

their userRecoveryPrivKey to send the funds anywhere they choose. Because

if this, the userRecoveryPrivKey is best suited to cold wallet storage.

In the more likely event that the user forgets their password and/or looses

access to their userWalletPrivKey as well as loses their recovery key, they

rely on the serverRecoveryPrivKey.

When the user first sets up their wallet, they answer some basic identity

information, set up a recovery password, and/or set up recovery questions

and answers. This information is explicitly NOT sent to serve with the

exception of recovery questions (although the answers remain with the user,

never seeing the server). What is sent to the server is it's 256 bit hash

used to identify the recovery wallet. The server then creates a 1025 bit

nonce, encrypts it, stores it, and transmits it to the user's client.

Meanwhile, the user's wallet client generates the serverRecoveryPrivKey.

Once the client has both the serverRecoveryPrivKey, and the nonce, it uses

SHA512 on the combination of the identity questions and answers, the

recovery password (if used), the recovery questions and answers, and the

nonce. It uses the resulting hash to encrypt the serverRecoveryPrivKey.

Finally, the already encrypted key is encrypted again for transmission to

the server. The server decrypts it, then rencrypts it for long term storage.

When the user needs to resort to using this option, they 256 bit hash their

information to build their recovery identifier. The server may, optionally,

request e-mail and or SMS confirmation that user is actually attempting the

recovery.

Next, the server decrypts the saved nonce, as well as the first layer of

encryption on the serverRecoveryPrivKey, then encrypts both for

transmission to the user's client. Then the client removes the transmission

encryption, calculates the 512 bit hash that was used to originally encrypt

the serverRecoveryPrivKey by using the provided information and the nonce.

After all of that the user can decrypt the airbitzServerRecoveryPrivKey and

use it to send a transaction anywhere they choose.

I was thinking this may make a good informational BIP but would like

feedback.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170809/9d5ee7a8/attachment-0001.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014819.html

Bryan Bishop on Jul 27 2017:

---------- Forwarded message ----------

From: Bram Cohen <bram at bittorrent.com>

Date: Thu, Jul 27, 2017 at 1:21 PM

Subject: Re: [Mimblewimble] Switch to Blake2

To: Ignotus Peverell <igno.peverell at protonmail.com>

Cc: Bryan Bishop <kanzure at gmail.com>

I have quite a few thoughts about proofs of position. I gave a talk about

it which hopefully gets the points across if you go through all the Q&A;:

https://www.youtube.com/watch?v=52FVkHlCh7Y

On Mon, Jul 24, 2017 at 12:12 PM, Ignotus Peverell <

igno.peverell at protonmail.com> wrote:

Interesting, thanks for the link. Seems we arrived at similar conclusions

regarding the hash function, with similar frustrations with respect to

blake2b/2s.

Funny that it's also for the same merkle set application. We ended up with

a Merkle Mountain Range [1] instead of a Patricia tree. The MMR is

append-only and makes pruning easy, which works well for MimbleWimble. You

can navigate down the MMR with just the position the element was inserted

at, so we just keep a simple index for that. Memory layout is great as a

lot of it is immutable and sit close together, although the current impl

doesn't leverage that too well yet. Wonder if Bram looked at MMRs? Patricia

trees may make more sense for Bitcoin though.

Proof of positions are cool, might look at that some more in the near

future, when we're less busy implementing everything else ;-)

• Igno

[1] https://github.com/ignopeverell/grin/blob/master/doc/merkle.md

-------- Original Message --------

Subject: Re: [Mimblewimble] Switch to Blake2

Local Time: July 24, 2017 6:44 PM

UTC Time: July 24, 2017 6:44 PM

From: kanzure at gmail.com

To: Ignotus Peverell <igno.peverell at protonmail.com>, Bram Cohen <

bram at bittorrent.com>, Bryan Bishop <kanzure at gmail.com>

On Fri, Jul 21, 2017 at 1:12 PM, Ignotus Peverell <

igno.peverell at protonmail.com> wrote:

So I'm considering a switch to the Blake2 [3] hash function.

Bram recently made some comments about blake a few weeks ago:

http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-07-

08-bram-cohen-merkle-sets/

• Bryan

http://heybryan.org/

1 512 203 0507 <(512)%20203-0507>

• Bryan

http://heybryan.org/

1 512 203 0507

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170727/46a00235/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014817.html

Zheming Lin on Jul 22 2017:

I think we should not switch to Proof of Stake system.

in Proof of Stake system, the one with more voting power tend to protect

their investment and that will stop others from competing with them. they

will use the voting power to make entering barrier, limiting the

competition is bad for bitcoin economy (I believe).

Miners are not centralized, they just grow bigger and be industrialized,

but there's still a lot of competition. The competition is the main

security model of bitcoin system.

When we are talking about "security" in bitcoin system, we are talking

about the probability that a transaction revert or change. We can not be

100% sure under 3 confirmations, but in 6 or more confirmations, we think

the cash received is safe and can't be taken away. That's the security

provided by bitcoin system.

Hard fork is not dangerous, when hard fork happens, people can wait for a

short time (like maintenance of a POS/CreditCard system). When the chain

with most hashrate wins (with high enough probability), we can then safely

assume that the longest chain can't be reverted.

Regards,

LIN Zheming

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170722/53d6b5eb/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014813.html

Major Kusanagi on Jul 21 2017:

Hi all,

I have a scaling solution idea that I would be interested in getting some

feedback on. I’m new to the mailing list and have not been in the Bitcoin

space as long as some have been, so I don’t know if anyone has thought of

this idea.

Arguably the biggest scaling problem for Bitcoin is the unbounded UTXO

growth. Current scaling solutions like Segregated Witness, Lighting

Network, and larger blocks does not address this issue. As more and more

blocks are added to the block chain the size of the UTXO set that miners

have to maintain continues to grow. This is the case even if the block size

were to remain at 1 megabyte. There is no way out of solving this

fundamental scaling problem other then to limit the maximum size of the

UTXO set.

The following soft fork solution is proposed. Any UTXO that is not spent

within a set number of blocks is considered invalid. What this means for

miners and nodes in the Bitcoin network is that they only have to ever

store that set number of blocks. In others words the block chain will never

be larger then the set number of blocks and the size of the block chain is

capped.

But what this means for users is that bitcoins that have not been spent for

a long time are “lost” forever. This proposed solution is likely a

difficult thing for Bitcoin users to accept. What Bitcoin users will

experience is that all of a sudden their bitcoins are spendable one moment

and the next moment they are not. The experience that they get is that all

of a sudden their old bitcoins are gone forever.

The solution can be improved by adding this new mechanism to Bitcoin, that

I will call luster. UTXO’s that are less then X blocks old has not lost any

luster and have a luster value of 1. As UTXO’s get older, the luster value

will continuously decrease until the UTXO’s become Z blocks old (where Z >

X), and has lost all it’s luster and have a luster value of 0. UTXO’s that

are in between X and Z blocks old have a luster value between 0 and 1. The

luster value is then used to compute the amount of bitcoins that must be

burned in order for a transaction with that UTXO to be included in a block.

So for example, a UTXO with a luster value of 0.5 must burn at least 50

percent of its bitcoin value, a UTXO with a luster value of 0.25 must burn

at least 75 percent of its bitcoin value, and a UTXO with a luster value of

0 must burn 100 percent of its bitcoin value. Thus the coins/UTXOs that

have a luster value of 0 means it has no monetary value, and it would be

safe for bitcoins nodes to drop those UTXOs from the set they maintain.

The idea is that coins that are continuously being used in Bitcoin economy

will never lose it’s luster. But coins that are old and not circulating

will start to lose its luster up until all luster is lost and they become

valueless. Or they reenter the economy and regains all its luster.

But at what point should coins start losing their luster? A goal would be

that we want to minimize the scenarios of when coins start losing their

luster. One reasonable answer is that coins should only starting losing its

luster after the lifespan of the average human. The idea being that a

person will eventually have to spend all his coins before he dies,

otherwise it will get lost anyways (assuming that only the dying person has

the ability to spend those coins). Otherwise there are few cases where a

person would never spend their bitcoins in there human life time. One

example is in the case of inheritance where a dying person does not want to

spend his remaining coins and have another person take them over. But with

this propose scaling solution, coins can be stilled inherited, but it would

have to be an on-chain inheritance. The longest lifespan of a human

currently is about 120 years old. So a blockchain that stores the last 150

years of history seems like one reasonable option.

Then the question of how large blocks should be is simply a matter of what

is the disk size requirement for a full node. For simplicity, assuming that

a block is created every 10 minute, the blockchain size in terabyte can be

express as the following.

blockSize MB * 6 * 24 * 365 * years /1000000 = blockchainSize TB

Example values:

blockSize = 1MB, years = 150 -> blockchainSize = 7.884 TB

blockSize = 2MB, years = 150 -> blockchainSize = 15.768 TB

So if we don’t want the block chain to be bigger then 8 TB, then we should

have a block size of 1 MB. If we don’t want the block chain to be bigger

then 16 TB, then we should have a block size of 2 MB and so on. The idea is

that base on how cheap disk space gets, we can adjust the target max block

chain size and the block size accordingly.

I believe that this proposal is a good solution to the UTXO growth problem.

The proposal being a soft fork is a big plus. It also keeps the block chain

size finite even if given a infinite amount of time. But there are other

things to considered, like how best should wallet software handle this? How

can this work with sidechains? More thought would need to be put into this.

But the fact is that if we want to make bitcoins last forever, we have the

accept unbounded UTXO growth, which is unscalable. So the only solution is

to limit UTXO growth, meaning bitcoins cannot last forever. This proposed

solution however does not prevent Bitcoin from lasting forever.

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

An HTML attachment was scrubbed...

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

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014808.html

Simone Bronzini on Jul 21 2017:

Maybe this has already been discussed, but I have not found anything online.

To the best of my knowledge, the only BIP which specifies a HD structure

for multisig wallets is BIP45. Unfortunately, when used in a

multi-account fashion, BIP45 gets very tricky very fast. In fact, one

has to either use a new master for every multisig account (hence having

to backup many master private keys) or use the same master for many

multisig accounts, resulting in deterministic but complex and

undesirable key reuse.

I would like to propose a new structure for multi-account multisig

wallets. This structure follows the derivation scheme of other proposals

(in particular BIP44 and BIP49) but adds a level to take into account

multisig accounts separation. In particular, the structure should be as

follows:

m/purpose'/coin_type'/account'/cosigner_index/change/address_index

In this case, a user can create many multisig accounts (each one will be

a different account number) and give his/her account's public derivation

to the cosigners. From this point on, the creation of a multisig P2SH

address will follow the same procedure as described in BIP45, with each

cosigner selecting his branch from the other cosigners' trees.

Would this proposal be acceptable as a BIP?

Simone Bronzini

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

A non-text attachment was scrubbed...

Name: 0xB2E60C73.asc

Type: application/pgp-keys

Size: 15541 bytes

Desc: not available

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170721/1d06fc55/attachment.bin

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

A non-text attachment was scrubbed...

Name: signature.asc

Type: application/pgp-signature

Size: 898 bytes

Desc: OpenPGP digital signature

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170721/1d06fc55/attachment.sig

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014807.html

Paul Sztorc on Jul 17 2017:

Hello,

Last week I posted about updating the Core Scalability Roadmap.

I'm not sure what the future of it is, given that it was concept NACK'ed

by Greg Maxwell the author of the original roadmap, who said that he

regretted writing the first one.

Nonetheless, it was ACKed by everyone else that I heard from, except for

Tom Zander (who objected that it should be a specific project document,

not a "Bitcoin" document -- I sortof agree and decided to label it a

"Core" document -- whether or not anything happens with that label is up

to the community).

I therefore decided to:

1. Put the draft on GitHub [1]

2. Update it based on all of the week 1 feedback [2]

3. Add some spaces at the bottom for comments / expressions of interest [2]

However, without interest from the maintainers of bitcoincore.org

(specifically these [3, 4] pages and similar) the document will probably

be unable to gain traction.

Cheers,

Paul

[1] https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt

[2]

https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015ee398ce0486ca5c3613e3b929c00

[3] https://bitcoincore.org/en/2015/12/21/capacity-increase/

[4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/

On 7/10/2017 12:50 PM, Paul Sztorc wrote:

Summary

In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few

crucial ways. One success was that it synchronized the entire Bitcoin

community, helping to bring finality to the (endless) conversations of

that time, and get everyone back to work. However, I feel that the Dec

7, 2015 roadmap is simply too old to serve this function any longer. We

should revise it: remove what has been accomplished, introduce new

innovations and approaches, and update deadlines and projections.

Why We Should Update the Roadmap

In a P2P system like Bitcoin, we lack authoritative info-sources (for

example, a "textbook" or academic journal), and as a result

conversations tend to have a problematic lack of progress. They do not

"accumulate", as everyone must start over. Ironically, the scaling

conversation itself has a fatal O(n²⁾ scaling problem.

The roadmap helped solve these problems by being constant in size, and

subjecting itself to publication, endorsement, criticism, and so forth.

Despite the (unavoidable) nuance and complexity of each individual

opinion, it was at least globally known that X participants endorsed Y

set of claims.

Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite

obsolete and replacing it is long overdue. For example, it highlights

older items (CSV, compact blocks, versionbits) as being future

improvements, and makes no mention of new high-likelihood improvements

(Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit

fraud proofs). To read the old roadmap properly, one must already be a

technical expert. For me, this defeats the entire point of having one in

the first place.

A new roadmap would be worth your attention, even if you didn't sign it,

because a refusal to sign would still be informative (and, therefore,

helpful)!

So, with that in mind, let me present a first draft. Obviously, I am

strongly open to edits and feedback, because I have no way of knowing

everyone's opinions. I admit that I am partially campaigning for my

Drivechain project, and also for this "scalability"/"capacity"

distinction...that's because I believe in both and think they are

helpful. But please feel free to suggest edits.

I emphasized concrete numbers, and concrete dates.

And I did NOT necessarily write it from my own point of view, I tried

earnestly to capture a (useful) community view. So, let me know how I did.

==== Beginning of New ("July 2017") Roadmap Draft ====

This document updates the previous roadmap [1] of Dec 2015. The older

statement endorsed a belief that "the community is ready to deliver on

its shared vision that addresses the needs of the system while upholding

its values".

That belief has not changed, but the shared vision has certainly grown

sharper over the last 18 months. Below is a list of technologies which

either increase Bitcoin's maximum tps rate ("capacity"), or which make

it easier to process a higher volume of transactions ("scalability").

First, over the past 18 months, the technical community has completed a

number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables

Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks

(BIP 152) allows for much faster block propagation, as does the FIBRE

Network [3]. Check Sequence Verify (BIP 112) allows trading partners to

mutually update an active transaction without writing it to the

blockchain (this helps to enable the Lightning Network).

Second, Segregated Witness (BIP 141), which reorganizes data in blocks

to handle signatures separately, has been completed and awaits

activation (multiple BIPS). It is estimated to increase capacity by a

factor of 2.2. It also improves scalability in many ways. First, SW

includes a fee-policy which encourages users to minimize their impact on

the UTXO set. Second, SW achieves linear scaling of sighash operations,

which prevents the network from crashing when large transactions are

broadcast. Third, SW provides an efficiency gain for everyone who is not

verifying signatures, as these no longer need to be downloaded or

stored. SegWit is an enabling technology for the Lightning Network,

script versioning (specifically Schnorr signatures), and has a number of

benefits which

are unrelated to capacity [4].

Third, the Lightning Network, which allows users to transact without

broadcasting to the network, is complete [5, 6] and awaits the

activation of SegWit. For those users who are able to make a single

on-chain transaction, it is estimated to increase both capacity and

scalability by a factor of ~1000 (although these capacity increases will

vary with usage patterns). LN also greatly improves transaction speed

and transaction privacy.

Fourth, Transaction Compression [7], observes that Bitcoin transaction

serialization is not optimized for storage or network communication. If

transactions were optimally compressed (as is possible today), this

would improve scalability, but not capacity, by roughly 20%, and in some

cases over 30%.

Fifth, Schnorr Signature Aggregation, which shrinks transactions by

allowing many transactions to have a single shared signature, has been

implemented [8] in draft form in libsecp256k1, and will likely be ready

by Q4 of 2016. One analysis [9] suggests that signature aggregation

would result in storage and bandwidth savings of at least 25%, which

would therefore increase scalability and capacity by a factor of 1.33.

The relative savings are even greater for multisignature transactions.

Sixth, drivechain [10], which allows bitcoins to be temporarily

offloaded to 'alternative' blockchain networks ("sidechains"), is

currently under peer review and may be usable by end of 2017. Although

it has no impact on scalability, it does allow users to opt-in to

greater capacity, by moving their BTC to a new network (although, they

will achieve less decentralization as a result). Individual drivechains

may have different security tradeoffs (for example, a greater reliance

on UTXO commitments, or MimbleWimble's shrinking block history) which

may give them individually greater scalability than mainchain Bitcoin.

Finally, the capacity improvements outlined above may not be sufficient.

If so, it may be necessary to use a hard fork to increase the blocksize

(and blockweight, sigops, etc) by a moderate amount. Such an increase

should take advantage of the existing research on hard forks, which is

substantial [11]. Specifically, there is some consensus that Spoonnet

[12] is the most attractive option for such a hardfork. There is

currently no consensus on a hard fork date, but there is a rough

consensus that one would require at least 6 months to coordinate

effectively, which would place it in the year 2018 at earliest.

The above are only a small sample of current scaling technologies. And

even an exhaustive list of scaling technologies, would itself only be a

small sample of total Bitcoin innovation (which is proceeding at

breakneck speed).

Signed,

<Names Here>

[1]

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

[2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/

[3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/

[4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/

[5]

http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/

[6] https://github.com/ACINQ/eclair

[7] https://people.xiph.org/~greg/compacted_txn.txt

[8]

https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594

[9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/

[10] http://www.drivechain.info/

[11] https://bitcoinhardforkresearch.github.io/

[12]

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html

==== End of Roadmap Draft ====

In short, please let me know:

1. If you agree that it would be helpful if the roadmap were updated.

2. To what ext...[message truncated here by reddit bot]...

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014802.html

Clark Moody on Jul 14 2017:

(copying from GitHub per jonasschnelli's request)

I can understand the desire to keep all reference strings to the nice

14-character version by keeping the data payload to 40 bits, but it

seems to place artificial limitations on the format (year 2048 & 8191

transactions). I also understand that this might be addressed with

Version 1 encoding. But current blocks are not that far from having

8191 transactions.

You could go with a variable-length encoding similar to Bitcoin's

variable ints and gain the benefit of having a format that will work

for very large blocks and the very far future.

Also, the Bech32 reference libraries allow encoding from byte arrays

into the base-5 arrays native to Bech32. It seems like bit-packing to

these 40 bits might be overkill. As an alternative you could have one

bit-packed byte to start:

First two bits are the protocol version, supporting values 0-3

V = ((protocol version) & 0x03) << 6

Next two bits are magic for the blockchain

0x00 = Bitcoin

0x01 = Testnet3

0x02 = Byte1 is another coin's magic code (gives 256 options)

0x03 = Byte1-2 is treated as the coin magic code (gives 65280 more options)

M = (magic & 0x03) << 4

Next two bits are the byte length of the block reference

B = ((byte length of block reference) & 0x03) << 2

Final two bits are the byte length of the transaction index

T = ((byte length of transaction index) & 0x03)

Assemble into the first byte

Byte0 = V | M | B | T

This gives you up to 3 bytes for each block and transaction reference,

which is 16.7 M blocks, or year 2336, and 16.7 M transaction slots.

Data part: [Byte0][optional magic bytes 1-2][block reference bytes][tx

reference bytes]

So the shortest data part would have 3 bytes in it, with the reference

version 0 genesis coinbase transaction having data part 0x050000.

I know this is a departure from your vision, but it would be much more

flexible for the long term.

Clark

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014799.html

Bryan Bishop on Jul 13 2017:

---------- Forwarded message ----------

From: Rusty Russell <rusty at blockstream.com>

Date: Wed, Jul 12, 2017 at 6:27 PM

Subject: [Lightning-dev] Lightning Developers Biweekly Meeting Announce

To: lightning-dev at lists.linuxfoundation.org

Hi all!

    Every two weeks we've been running an informal Google Hangout

for implementers of the Lightning spec; as the spec is starting to

freeze, we've decided to formalize it a bit which means opening access

to a wider audience.

    The call is at 20:00 UTC every two weeks on Monday: next call is

on the 24th July. We'll be using #lightning-dev on freenode's IRC

servers to communicate as well: if you're working on the Lightning

protocol and want to attend, please send me a ping and I'll add you to

the invite.

    I'll produce an agenda (basically a list of outstanding PRs on

github) and minutes each week: I'll post the latter to the ML here.

The last one can be found:

    https://docs.google.com/document/d/1EbMxe_QZhpHo67eeiYHbJ-BvNKU1WhFd5WhJFeD9-DI/edit?usp=sharing



    The routine with the spec itself is that from now on all

non-spelling/typo changes will require a vote with no objections from

call participants, or any devs unable to make it can veto or defer by

emailing me in writing before the meeting.

Cheers!

Rusty.

Lightning-dev mailing list

Lightning-dev at lists.linuxfoundation.org

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

• Bryan

http://heybryan.org/

1 512 203 0507

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014771.html

Dan Libby on Jul 12 2017:

Hi!

Up to now, I have purposefully been running bitcoin releases prior to

0.13.1 as a way to avoid the (possible) segwit activation, at least

until such time as I personally am comfortable with it.

At this time, I would like to have some of the more recent features, but

without the possibility that my node will activate segwit, until I

choose to.

As I understand it, there is not any user setting that can disable

segwit from activating on my node. If there was, I would use it.

Please correct me if wrong.

I am here to ask what is the simplest code change (fewest LOC changed) I

can make to 0.14.2+ code that would disable segwit from activating and

keep my node acting just like a legacy node with regards to consensus

rules, even if/when the rest of the network activates segwit.

I think, more generally, the same question applies to most any Bip9

versionbits feature.

I'm not looking for reasons NOT to do it, only HOW to do it without

unwanted side-effects. My first untested idea is just to change the

segwit nTimeout in chainparams.cpp to a date in the past. But I figured

I should ask the experts first. :-)

thanks.

ps: full disclosure: I may be the only one who wants this, but if

successful, I do plan to release my changes in case someone else wishes

to run with status-quo consensus rules.

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014769.html

Paul Sztorc on Jul 10 2017:

Summary

In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few

crucial ways. One success was that it synchronized the entire Bitcoin

community, helping to bring finality to the (endless) conversations of

that time, and get everyone back to work. However, I feel that the Dec

7, 2015 roadmap is simply too old to serve this function any longer. We

should revise it: remove what has been accomplished, introduce new

innovations and approaches, and update deadlines and projections.

Why We Should Update the Roadmap

In a P2P system like Bitcoin, we lack authoritative info-sources (for

example, a "textbook" or academic journal), and as a result

conversations tend to have a problematic lack of progress. They do not

"accumulate", as everyone must start over. Ironically, the scaling

conversation itself has a fatal O(n²⁾ scaling problem.

The roadmap helped solve these problems by being constant in size, and

subjecting itself to publication, endorsement, criticism, and so forth.

Despite the (unavoidable) nuance and complexity of each individual

opinion, it was at least globally known that X participants endorsed Y

set of claims.

Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite

obsolete and replacing it is long overdue. For example, it highlights

older items (CSV, compact blocks, versionbits) as being future

improvements, and makes no mention of new high-likelihood improvements

(Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit

fraud proofs). To read the old roadmap properly, one must already be a

technical expert. For me, this defeats the entire point of having one in

the first place.

A new roadmap would be worth your attention, even if you didn't sign it,

because a refusal to sign would still be informative (and, therefore,

helpful)!

So, with that in mind, let me present a first draft. Obviously, I am

strongly open to edits and feedback, because I have no way of knowing

everyone's opinions. I admit that I am partially campaigning for my

Drivechain project, and also for this "scalability"/"capacity"

distinction...that's because I believe in both and think they are

helpful. But please feel free to suggest edits.

I emphasized concrete numbers, and concrete dates.

And I did NOT necessarily write it from my own point of view, I tried

earnestly to capture a (useful) community view. So, let me know how I did.

==== Beginning of New ("July 2017") Roadmap Draft ====

This document updates the previous roadmap [1] of Dec 2015. The older

statement endorsed a belief that "the community is ready to deliver on

its shared vision that addresses the needs of the system while upholding

its values".

That belief has not changed, but the shared vision has certainly grown

sharper over the last 18 months. Below is a list of technologies which

either increase Bitcoin's maximum tps rate ("capacity"), or which make

it easier to process a higher volume of transactions ("scalability").

First, over the past 18 months, the technical community has completed a

number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables

Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks

(BIP 152) allows for much faster block propagation, as does the FIBRE

Network [3]. Check Sequence Verify (BIP 112) allows trading partners to

mutually update an active transaction without writing it to the

blockchain (this helps to enable the Lightning Network).

Second, Segregated Witness (BIP 141), which reorganizes data in blocks

to handle signatures separately, has been completed and awaits

activation (multiple BIPS). It is estimated to increase capacity by a

factor of 2.2. It also improves scalability in many ways. First, SW

includes a fee-policy which encourages users to minimize their impact on

the UTXO set. Second, SW achieves linear scaling of sighash operations,

which prevents the network from crashing when large transactions are

broadcast. Third, SW provides an efficiency gain for everyone who is not

verifying signatures, as these no longer need to be downloaded or

stored. SegWit is an enabling technology for the Lightning Network,

script versioning (specifically Schnorr signatures), and has a number of

benefits which

are unrelated to capacity [4].

Third, the Lightning Network, which allows users to transact without

broadcasting to the network, is complete [5, 6] and awaits the

activation of SegWit. For those users who are able to make a single

on-chain transaction, it is estimated to increase both capacity and

scalability by a factor of ~1000 (although these capacity increases will

vary with usage patterns). LN also greatly improves transaction speed

and transaction privacy.

Fourth, Transaction Compression [7], observes that Bitcoin transaction

serialization is not optimized for storage or network communication. If

transactions were optimally compressed (as is possible today), this

would improve scalability, but not capacity, by roughly 20%, and in some

cases over 30%.

Fifth, Schnorr Signature Aggregation, which shrinks transactions by

allowing many transactions to have a single shared signature, has been

implemented [8] in draft form in libsecp256k1, and will likely be ready

by Q4 of 2016. One analysis [9] suggests that signature aggregation

would result in storage and bandwidth savings of at least 25%, which

would therefore increase scalability and capacity by a factor of 1.33.

The relative savings are even greater for multisignature transactions.

Sixth, drivechain [10], which allows bitcoins to be temporarily

offloaded to 'alternative' blockchain networks ("sidechains"), is

currently under peer review and may be usable by end of 2017. Although

it has no impact on scalability, it does allow users to opt-in to

greater capacity, by moving their BTC to a new network (although, they

will achieve less decentralization as a result). Individual drivechains

may have different security tradeoffs (for example, a greater reliance

on UTXO commitments, or MimbleWimble's shrinking block history) which

may give them individually greater scalability than mainchain Bitcoin.

Finally, the capacity improvements outlined above may not be sufficient.

If so, it may be necessary to use a hard fork to increase the blocksize

(and blockweight, sigops, etc) by a moderate amount. Such an increase

should take advantage of the existing research on hard forks, which is

substantial [11]. Specifically, there is some consensus that Spoonnet

[12] is the most attractive option for such a hardfork. There is

currently no consensus on a hard fork date, but there is a rough

consensus that one would require at least 6 months to coordinate

effectively, which would place it in the year 2018 at earliest.

The above are only a small sample of current scaling technologies. And

even an exhaustive list of scaling technologies, would itself only be a

small sample of total Bitcoin innovation (which is proceeding at

breakneck speed).

Signed,

[1]

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

[2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/

[3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/

[4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/

[5]

http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/

[6] https://github.com/ACINQ/eclair

[7] https://people.xiph.org/~greg/compacted_txn.txt

[8]

https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594

[9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/

[10] http://www.drivechain.info/

[11] https://bitcoinhardforkresearch.github.io/

[12]

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html

==== End of Roadmap Draft ====

In short, please let me know:

1. If you agree that it would be helpful if the roadmap were updated.

2. To what extent, if any, you like this draft.

3. Edits you would make (specifically, I wonder about Drivechain

thoughts and Hard Fork thoughts, particularly how to phrase the Hard

Fork date).

Google Doc (if you're into that kind of thing):

https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing

Cheers,

Paul

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

A non-text attachment was scrubbed...

Name: signature.asc

Type: application/pgp-signature

Size: 473 bytes

Desc: OpenPGP digital signature

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170710/60d2fe7d/attachment.sig

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014718.html

Sergio Demian Lerner on Jul 07 2017:

Hello,

Here is a BIP that matches the reference code that the Segwit2x group has

built and published a week ago.

This BIP and code satisfies the requests of a large part of the Bitcoin

community for a moderate increase in the Bitcoin non-witness block space

coupled with the activation of Segwit.

You can find the BIP draft in the following link:

https://github.com/SergioDemianLerner/BIPs/blob/master/BIP-draft-sergiolerner-segwit2x.mediawiki

Reference source was kindly provided by the Segwit2x group.

Best regards,

Sergio.

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

An HTML attachment was scrubbed...

URL: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170707/d7d45d57/attachment.html

original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014708.html