Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Jeff Garzik
On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com wrote:

 2) BIP100 has direct economic consequences…and particularly for miners. It
 lends itself to much greater corruptibility.


What is the alternative?  Have a Chief Scientist or Technical Advisory
Board choose what is a proper fee, what is a proper level of
decentralization, a proper growth factor?


-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Jeff Garzik
On Sun, Jun 14, 2015 at 12:55 AM, Chun Wang 1240...@gmail.com wrote:

 To tell you the truth. It is only because most miners are not located
 in the West. If Slush, Eligius and BTC Guild still on top 3, the core
 developers, including brain-dead Mike Hearn, would be very happy to do
 BIP100 just like they did BIP34 and BIP66. Shame on you!


BIP 100 requires a hard fork to engage.  Users proactively opt-in.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Jeff Garzik
The choice is very real and on-point.  What should the block size limit
be?  Why?

There is a large consensus that it needs increasing.  To what?  By what
factor?

The size limit literally defines the fee market, the whole damn thing.  If
software high priests choose a size limit of 300k, space is scarce, fees
are bid high.  If software high priests choose a size limit of 32mb, space
is plentiful, fees are near zero.  Market actors take their signals
accordingly.  Some business models boom, some business models fail, as a
direct result of changing this unintentionally-added speedbump.  Different
users value adoption, decentralization etc. differently.

The size limit is an economic policy lever that needs to be transitioned
-away- from software and software developers, to the free market.

A simple, e.g. hard fork to 2MB or 4MB does not fix higher level governance
problems associated with actors lobbying developers, even if a cloistered
and vetted Technical Advisory Board as has been proposed.







On Sun, Jun 14, 2015 at 1:20 AM, Eric Lombrozo elombr...@gmail.com wrote:

 I definitely think we need some voting system for metaconsensus…but if
 we’re going to seriously consider this we should look at the problem much
 more generally. Using false choices doesn’t really help, though ;)

 - Eric Lombrozo


 On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote:

 On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com
 wrote:

 2) BIP100 has direct economic consequences…and particularly for miners.
 It lends itself to much greater corruptibility.


 What is the alternative?  Have a Chief Scientist or Technical Advisory
 Board choose what is a proper fee, what is a proper level of
 decentralization, a proper growth factor?





-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Eric Lombrozo
I definitely think we need some voting system for metaconsensus…but if we’re 
going to seriously consider this we should look at the problem much more 
generally. Using false choices doesn’t really help, though ;)

- Eric Lombrozo


 On Jun 13, 2015, at 10:13 PM, Jeff Garzik jgar...@bitpay.com wrote:
 
 On Sun, Jun 14, 2015 at 1:08 AM, Eric Lombrozo elombr...@gmail.com 
 mailto:elombr...@gmail.com wrote:
 2) BIP100 has direct economic consequences…and particularly for miners. It 
 lends itself to much greater corruptibility.
 
 
 What is the alternative?  Have a Chief Scientist or Technical Advisory Board 
 choose what is a proper fee, what is a proper level of decentralization, a 
 proper growth factor?



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Aaron Voisine

 Yes, it does bother (some) people to see the consensus based system
 because of the difficulties that can be associated with implementing
 it.  But that's the way it is.  If you don't like consensus based
 systems (or decentralized, distributed systems) this is probably the
 wrong space for you.


If consensus must be reached to make any changes, that just means that
changes of anything more than trivial consequence simply can't be made.
Extreme bias toward the status-quo will only work if external factors
affecting the network also remain static.

Aaron Voisine
co-founder and CEO
breadwallet.com
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Eric Lombrozo
Chun,

With all due respect, there are a couple major differences between BIP34 and 
BIP66 on the one hand and BIP100 on the other.

1) BIP34 and BIP66 are soft forks. Miners choosing to switch to them will not 
seriously impact validation rules for non-mining users that do not make the 
switch. With BIP66, the worst that can happen to them is noncompliant 
transactions will no longer be accepted by the network…but even nodes that do 
not switch over will continue to remain synched with the network.

2) BIP100 has direct economic consequences…and particularly for miners. It 
lends itself to much greater corruptibility.

- Eric Lombrozo

 On Jun 13, 2015, at 9:55 PM, Chun Wang 1240...@gmail.com wrote:
 
 To tell you the truth. It is only because most miners are not located
 in the West. If Slush, Eligius and BTC Guild still on top 3, the core
 developers, including brain-dead Mike Hearn, would be very happy to do
 BIP100 just like they did BIP34 and BIP66. Shame on you!
 
 On Sun, Jun 14, 2015 at 6:20 AM, Danny Thorpe danny.tho...@gmail.com wrote:
 Please forgive my ignorance, but why should Bitcoin users have a say in
 block size limits?  It's the miners and Bitcoin node operators that bear the
 burden of managing large blocks, no?
 
 Users voting on network parameters sounds like neighbors voting on how deep
 my swimming pool should be.
 
 Thanks,
 -Danny
 
 On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd p...@petertodd.org wrote:
 
 Jeff Garzik recently proposed that the upper blocksize limit be removed
 entirely, with a soft limit being enforced via miner vote, recorded by
 hashing power.
 
 This mechanism within the protocol for users to have any influence over
 the miner vote. We can add that back by providing a way for transactions
 themselves to set a flag determining whether or not they can be included
 in a block casting a specific vote.
 
 We can simplify Garzik's vote to say that one of the nVersion bits
 either votes for the blocksize to be increased, or decreased, by some
 fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
 nVersion bit in transactions themselves, also voting for an increase or
 decrease. Transactions may only be included in blocks with an
 indentical vote, thus providing miners with a monetary incentive via
 fees to vote according to user wishes.
 
 Of course, to cast a don't care vote we can either define an
 additional bit, or sign the transaction with both versions. Equally we
 can even have different versions with different fees, broadcast via a
 mechanism such as replace-by-fee.
 
 
 See also John Dillon's proposal for proof-of-stake blocksize voting:
 
 
 https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
 
 --
 'peter'[:-1]@petertodd.org
 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
 
 
 --
 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 
 
 --
 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 
 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Jeff Garzik
Miner voting, while imperfect, is the least-worst of various solutions
which inject market input into the system.  It is is known quantity, field
tested, and must be sustained, in public, over a time span of months.  As
this thread shows, stakeholder and direct user voting is nigh impossible to
get right.

Choosing block size is fundamentally a central bank directive shaping the
fee market.  Whatever actor or algorithm or natural equilibrium picks the
block size, that choice will dictate the level of competition for fees, the
level of scarcity of an economically scarce resource.  Picking the block
size advantages some businesses over others, some business models over
others.  Software (and software devs) should not be the ones picking that
limit.

Checks-and-balances are also important.  BIP 100 notably includes two steps
at which user input is visibly and actively injected:   1) hard fork to
enable, and 2) a second hard fork if the system is to scale beyond 32MB.
The network users (not miners) twice approve the system.  Further, one must
remember all the basic miner incentives that do align with users, notably
that of maintaining the value of bitcoin tokens as their primary income
stream.


















On Sun, Jun 14, 2015 at 12:16 AM, Stephen stephencalebmo...@gmail.com
wrote:

 While this idea is theoretically interesting because it involves many
 stakeholders, rather than just miners, I think in practice this would not
 work very well. Users don't want to worry about this kind of technicality,
 they just want to be able to make a transaction and have it be processed.

 In addition, while this gives stakeholders some weight with the fees they
 supply, these fees are marginal compared to the block size subsidy. If this
 proposal were actually implemented, I think miners would vote for whatever
 they think is best, and users would not contradict them with their votes to
 ensure a fast confirmation time. Users are incentivized to be in agreement
 with miners because the miners provide them with the confirmations they
 need, but fees do not provide a great incentive for miners to be in
 agreement with users, and likely won't for some time.

 Best,
 Stephen




  On Jun 12, 2015, at 2:11 PM, Peter Todd p...@petertodd.org wrote:
 
  Jeff Garzik recently proposed that the upper blocksize limit be removed
  entirely, with a soft limit being enforced via miner vote, recorded by
  hashing power.
 
  This mechanism within the protocol for users to have any influence over
  the miner vote. We can add that back by providing a way for transactions
  themselves to set a flag determining whether or not they can be included
  in a block casting a specific vote.
 
  We can simplify Garzik's vote to say that one of the nVersion bits
  either votes for the blocksize to be increased, or decreased, by some
  fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
  nVersion bit in transactions themselves, also voting for an increase or
  decrease. Transactions may only be included in blocks with an
  indentical vote, thus providing miners with a monetary incentive via
  fees to vote according to user wishes.
 
  Of course, to cast a don't care vote we can either define an
  additional bit, or sign the transaction with both versions. Equally we
  can even have different versions with different fees, broadcast via a
  mechanism such as replace-by-fee.
 
 
  See also John Dillon's proposal for proof-of-stake blocksize voting:
 
 
 https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
 
  --
  'peter'[:-1]@petertodd.org
  127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
 
 --
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development


 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Miners: You'll (very likely) need to upgrade your Bitcoin Core node soon to support BIP66

2015-06-13 Thread Pieter Wuille
On Fri, Jun 12, 2015 at 10:37 AM, Tier Nolan tier.no...@gmail.com wrote:

 Once the 75% threshold is reached, miners who haven't updated are at risk
 of mining on invalid blocks.


Note that we've been above the 75% threshold since june 7th (before Peter's
main was sent).

-- 
Pieter
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Scaling Bitcoin with Subchains

2015-06-13 Thread Pieter Wuille
On Wed, May 20, 2015 at 4:55 AM, Andrew onelinepr...@gmail.com wrote:

 Hi

 I briefly mentioned something about this on the bitcoin-dev IRC room. In
 general, it seems experts (like sipa i.e. Pieter) are against using
 sidechains as a way of scaling. As I only have a high level understanding
 of the Bitcoin protocol, I cannot be sure if what I want to do is actually
 defined as a side chain, but let me just propose it, and please let me know
 whether it can work, and if not why not (I'm not scared of digging into
 more technical resources in order to fully understand). I do have a good
 academic/practical background for Bitcoin, and I'm ready to contribute code
 if needed (one of my contributions includes a paper wallet creator written
 in C).


In your proposal, transactions go to a chain based the addresses involved.
We can reasonably assume that different people's wallet will tend to be
distributed uniformly over several sidechains to hold their transactions
(if they're not, there is no scaling benefit anyway...). That means that
for an average transaction, you will need a cross-chain transfer in order
to get the money to the recipient (as their wallet will usually be
associated to a chain that is different from your own). Either you use an
atomic swap (which actually means you end up briefly with coins in the
destination chain, and require multiple transactions and a medium delay),
or you use the 2way peg transfer mechanism (which is very slow, and reduces
the security the recipient has to SPV).

Whatever you do, the result will be that most transactions are:
* Slower (a bit, or a lot, depending on what mechanism you use).
* More complex, with more failure modes.
* Require more and larger transactions (causing a total net extra load on
all verifiers together).

And either:
* Less secure (because you rely on a third party to do an atomic swap with,
or because of the 2 way peg transfer mechanism which has SPV security)
* Doesn't offer any scaling benefit (because the recipient needs to fully
validate both his own and the receiver chain).

In short, you have not added any scaling at all, or reduced the security of
the system significantly, as well as made it significantly less convenient
to use.

So no, sidechains are not a direct means for solving any of the scaling
problems Bitcoin has. What they offer is a mechanism for easier
experimentation, so that new technology can be built and tested without
needing to introduce a new currency first (with the related speculative and
network effect problems). That experimentation could eventually lead us to
discover mechanisms for better scaling, or for more scalability/security
tradeoffs (see for example the Witness Segregation that Elements Alpha has).

-- 
Pieter
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] The timechain: an idea to solve TX malleability in smart contract protocols with minimal involvement and without requiring a fork.

2015-06-13 Thread Matthew Roberts
I've been tossing around an idea in my head that involves time-locked
encryption [0] and I wondered what the devs here think about it. In a
nutshell: the timechain is a serial chain of time-lock encrypted GPG keys
at N minute intervals (meaning that it requires N minutes to decrypt a
single link / key in the chain and each link must be fully decrypted before
decryption can start on the next link.) For those not aware of how
time-lock encryption works it goes something like this:

1. Choose some random, unique text - this is the initialisation vector or
IV.

2. Hash that text - output.

3. Hash the output - output.

4. Hash the output - output.

5. ...

6. Process is repeated for N minutes.

7. Result is then used to generate encryption keys and the public key can
be used to time-lock encrypt an arbitrary number of plaintexts.

8. All intermediary results are discarded -- only the pub key is kept and
giving out the IV forces an individual to have to repeat the same amount of
work used to generate the encryption key.

What's interesting about this is that the keys can be generated in parallel
and then stitched together to form a single serial chain of keys. So
potentially, if a person had access to a GPU cluster then they could
generate a years worth of keys in only 5 minutes. Now imagine if one were
to stitch these keys together into a chain of keys at five minute intervals
(a structure I refer to as the timechain): you could use this structure
to encrypt ECDSA keys which could then be used in multi-signature contract
schemes as a 100% decentralized, trustless way to execute refunds in
contract protocols.

Unexpected benefit: time-lock encryption can be used to build unbreakable
DACs.

Peter Todd has already done work on using Bitcoin to incentivize the
decryption process of time-lock encryption [1] but what he may not be aware
of is how important this process is for the construction of DACs.

Imagine a true peer-to-peer cryptocurrency exchange [2] that time-lock
encrypts a chain of ECDSA keys using the timechain and then sets up
contracts to pay a small portion of their fees into the ECDSA keys.
Essentially the exchange has created a DAC that pays its participants to
decrypt itself. This is the incentive for the decryption. The reason for
the incentive is that another chain of keys can be generate at 5 minute
intervals which can be used in contract protocols in place of nTimeLocked
refund transactions (which are vulnerable to transaction malleability.)

Sample contract using the timechain:

3 of 4 multi-sig: Owner, Owner, Recipient, Timelock

Pay N coins to recipient sequentially (micropayment channel) before [time /
date], otherwise fall back on timelock decrypted refund key to give full
leverage back to owner. This is how smart contracts would work using the
timechain for refunds (instead of nTimeLock TXs.)

Using the DAC, it might also be possible to force participants to reveal
their solutions to the decryption of the timechain (otherwise the first
person who starts on the chain would receive all the fees which isn't very
fair.) One way to do this would be to use the public key for the fee ECDSA
key as the IV used to generate the next key on the chain. To spend the fees
would therefore require revealing the public key if the fees were paid to a
pay-to-pub-key-hash transaction.

A further precaution would be to generate the pay to fee transaction in
such a way that the amount needed to be redeemed before a certain
time-frame otherwise another transaction would burn the coins. (I haven't
worked out the full details for this yet but similar schemes have been used
successfully, for example in BitHalo [3] and the Lightning Network [4]
offers another potential solution.) Perhaps a custom blockchain or
sidechain could be used to award coins for successful (and timely
solutions) but this is a subject for future work.

In conclusion: I have described a simple way to solve the TX malleability
problem in smart contract protocols without requiring a fork or relying on
a third-party escrow services to hold keys. My solution doesn't require any
trust beyond the initial need for the timechain to be generated in a secure
environment and the solution remains secure so long as participants stick
to using future keys in the chain regardless of how far along the
decryption is.

Critique / flaws

Obviously the biggest flaw here is that the integrity of a timechain can't
be known before-hand but if a timechain were to be generated securely by a
reputable party, the biggest benefit of using it is that it basically runs
itself: it does not require any third-party to manage its functionality and
the entity which originally generated it can completely disappear without
interrupting service. This could, for instance - allow companies to create
entirely secure and reliable systems that couldn't be hacked as the
behaviour of a timechain is deterministic. I think this is a huge
improvement over existing systems which require 

Re: [Bitcoin-development] Proposed alternatives to the 20MB step

2015-06-13 Thread odinn
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



On 06/02/2015 04:03 AM, Mike Hearn wrote:
(...)
 
 If you really believe that decentralisation is, itself, the end,
 then why not go use an ASIC resistant alt coin with no SPV or web
 wallets which resembles Bitcoin at the end of 2009? That'd be a
 whole lot more decentralised than what you have now.
 
 The *percentage* of the community that mines is totally
 irrelevant, it's the absolute number of (independent) people that
 matters.
 
 
 So usage does matter, then? You'd rather have a coin that has
 power concentrated in a far smaller elite, proportionally, but has
 overall more usage? If there are say, 5000 full nodes today, and in
 ten years there are 6000, and they all run in vast datacenters and
 are owned by large companies, you'll feel like Bitcoin is more
 decentralised than ever?   (n.b. I do not think this situation will
 ever happen, it's just an example).
 

Something you said about power concentrated, made me think I should
post this here:

https://twitter.com/adam3us/status/608920099609817088

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVe8gvAAoJEGxwq/inSG8CcykH/0d+WuPnzFWooCRJR+FwaI4w
Ad0z5GSLfYKGnmMMbbqkLsIA2GsfRAvivrsfZYd4slF5C7HEDGa3J/NC72U46dk6
qVm07UNBO3V+loLJtStIQQkg3tVGWjXeiySf4E4b8wlaZiBMS9WW0sAOWUJiGMDQ
jKNRpjXobkQGd8C+VJXDpgtmiY60bS4l6j7bbYv+mU6LxhLwCVCqjRJSEN08BH4E
AOwJg1qlORHPnrepfeJrB6TVxeHuLjCjWodXQ0jHbNchVQw7zc81gKrD40BJTzyO
TTtGPu3JUkcHtx7MVLbIdYNVElqxMS5Li+j9j3h+m9eGSaNgOOl3+8VGJexKPKI=
=j5Fh
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] The timechain: an idea to solve TX malleability in smart contract protocols without requiring a fork.

2015-06-13 Thread Matthew Roberts
I've been tossing around an idea in my head that involves time-locked
encryption [0] and I wondered what the devs here think about it. In a
nutshell: the timechain is a serial chain of time-lock encrypted GPG keys
at N minute intervals (meaning that it requires N minutes to decrypt a
single link / key in the chain and each link must be fully decrypted before
decryption can start on the next link.) For those not aware of how
time-lock encryption works it goes something like this:

1. Choose some random, unique text - this is the initialisation vector or
IV.

2. Hash that text - output.

3. Hash the output - output.

4. Hash the output - output.

5. ...

6. Process is repeated for N minutes.

7. Result is then used to generate encryption keys and the public key can
be used to time-lock encrypt an arbitrary number of plaintexts.

8. All intermediary results are discarded -- only the pub key is kept and
giving out the IV forces an individual to have to repeat the same amount of
work used to generate the encryption key.

What's interesting about this is that the keys can be generated in parallel
and then stitched together to form a single serial chain of keys. So
potentially, if a person had access to a GPU cluster then they could
generate a years worth of work in only 5 minutes. Now imagine if one were
to stitch these keys together into a chain of keys at five minute intervals
(a structure I refer to as the timechain): you could use this structure
to encrypt ECDSA keys which could then be used in multi-signature contract
schemes as a 100% decentralized, trustless way to execute refunds in
contract protocols.

Unexpected benefit: time-lock encryption can be used to build unbreakable
DACs.

Peter Todd has already done work on using Bitcoin to incentivize the
decryption process of time-lock encryption [1] but what he may not be aware
of is how important this process is for the construction of DACs.

Imagine a true peer-to-peer cryptocurrency exchange [2] that time-lock
encrypts a chain of ECDSA keys using the timechain and then sets up
contracts to pay a small portion of their fees into the ECDSA keys.
Essentially the exchange has created a DAC that pays its participants to
decrypt itself. This is the incentive for the decryption. The reason for
the incentive is that another chain of keys can be generate at 5 minute
intervals which can be used in contract protocols in place of nTimeLocked
refund transactions (which are vulnerable to transaction malleability.)

Sample contract using the timechain:

3 of 4 multi-sig: Owner, Owner, Recipient, Timelock

Pay N coins to recipient sequentially (micropayment channel) before [time /
date], otherwise fall back on timelock decrypted refund key to give full
leverage back to owner. This is how smart contracts would work using the
timechain for refunds (instead of nTimeLock TXs.)

Using the DAC, it might also be possible to force participants to reveal
their solutions to the decryption of the timechain (otherwise the first
person who starts on the chain would receive all the fees which isn't very
fair.) One way to do this would be to use the public key for the fee ECDSA
key as the IV used to generate the next key on the chain. To spend the fees
would therefore require revealing the public key if the fees were paid to a
pay-to-pub-key-hash transaction.

A further precaution would be to generate the pay to fee transaction in
such a way that the amount needs to be redeemed otherwise another
transaction would burn the coins. (I haven't worked out the full details
for this but similar schemes have been used successfully, for example in
BitHalo [3]. The Lightning Network [4] offers another potential solution.)
Perhaps a custom blockchain or sidechain could also be used to award coins
for successful (and timely solutions) but this is a subject for future work.

In conclusion: I have described a simple way to solve the TX malleability
problem in smart contract protocols without requiring a fork or relying on
a third-party escrow scheme to manage coins. My solution doesn't require
any trust beyond the initial need for the timechain to be generated in a
secure cluster and the solution remains secure so long as participants
stick to using future keys in the chain regardless of how far along
decryption is.

What do you think of the idea so far?

Obviously the biggest flaw here is that the integrity of a timechain can't
be known before-hand but if a timechain were to be generated securely by a
reputable party, the biggest benefit of using it is that it basically runs
itself: it does not require any third-party to manage its functionality and
the entity which originally generated it can completely disappear without
interrupting service. This could, for instance - allow companies to create
entirely secure and reliable systems that couldn't be hacked as the
behaviour of a timechain is deterministic. I think this is a huge
improvement over existing systems which require third-parties to be

Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism

2015-06-13 Thread Nathan Wilcox
On Thu, Jun 11, 2015 at 12:55 PM, Aaron Voisine vois...@gmail.com wrote:

  A Header-PoW-verifying client could still be given all transactions in
 a recent block, from which it can see the in-band fees directly.

 You don't know the fees paid by any given transaction unless you also have
 all it's inputs. Transaction inputs do not include an amount. You could
 however get the average fee-per-kb paid by all transactions in a block by
 looking at the coinbase transaction, subtracting the block reward, and
 dividing by the size of block minus the header.


Excellent point and alternative proposal. You're right: to get the specifi
fees, you'd need all transactions in a block, and all TxOuts with
membership proofs. Your alternative seems like a much leaner trade-off for
similar data.



 Aaron Voisine
 co-founder and CEO
 breadwallet.com

 On Thu, Jun 11, 2015 at 11:30 AM, Nathan Wilcox nat...@leastauthority.com
  wrote:

 On Wed, Jun 10, 2015 at 2:03 PM, Peter Todd p...@petertodd.org wrote:

 On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote:
  On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine vois...@gmail.com
 wrote:
 
   It could be done by agreeing on a data format and encoding it in an
   op_return output in the coinbase transaction. If it catches on it
 could
   later be enforced with a soft fork.
  
  
  Sounds plausible, except SPV protocols would need to include this
 coinbase
  txn if it's going to help SPV clients. (Until a softfork is activated,
 SPV
  clients should not rely on this encoding, since until that time the
 results
  can be fabricated by individual miners.)

 Fee stats can always be fabricated by individual miners because fees can
 be paid out-of-band.


 This is a point I hadn't considered carefully before. I don't understand
 the marketplace here or why miners would want to move fees outside of
 explicit inband fees. Implicit in this proposal is that the statistics only
 cover in-band data, because that's the scope of consensus rules, and thus
 the proposal is only as useful as the information of in-band fees is useful.

 I've also noticed a detracting technical argument given a particular
 tradeoff:

 A Header-PoW-verifying client could still be given all transactions in a
 recent block, from which it can see the in-band fees directly.  The
 trade-off is the size of those transactions versus the need to alter any
 consensus rules or do soft forks.

 Notice how this trade-off's costs change with maximum block size.




 --
 'peter'[:-1]@petertodd.org
 1245bd2f5c99379ee76836227ded9c08324894faabc0d27f




 --
 Nathan Wilcox
 Least Authoritarian

 email: nat...@leastauthority.com
 twitter: @least_nathan
 PGP: 11169993 / AAAC 5675 E3F7 514C 67ED  E9C9 3BFE 5263 1116 9993





-- 
Nathan Wilcox
Least Authoritarian

email: nat...@leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED  E9C9 3BFE 5263 1116 9993
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Scaling Bitcoin with Subchains

2015-06-13 Thread Andrew
First of all, I added more info to bitcointalk.org:
https://bitcointalk.org/index.php?topic=1083345.0

On Sat, Jun 13, 2015 at 2:39 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:


 In your proposal, transactions go to a chain based the addresses involved.
 We can reasonably assume that different people's wallet will tend to be
 distributed uniformly over several sidechains to hold their transactions
 (if they're not, there is no scaling benefit anyway...). That means that
 for an average transaction, you will need a cross-chain transfer in order
 to get the money to the recipient (as their wallet will usually be
 associated to a chain that is different from your own). Either you use an
 atomic swap (which actually means you end up briefly with coins in the
 destination chain, and require multiple transactions and a medium delay),
 or you use the 2way peg transfer mechanism (which is very slow, and reduces
 the security the recipient has to SPV).

 Whatever you do, the result will be that most transactions are:
 * Slower (a bit, or a lot, depending on what mechanism you use).
 * More complex, with more failure modes.
 * Require more and larger transactions (causing a total net extra load on
 all verifiers together).

 And either:
 * Less secure (because you rely on a third party to do an atomic swap
 with, or because of the 2 way peg transfer mechanism which has SPV security)
 * Doesn't offer any scaling benefit (because the recipient needs to fully
 validate both his own and the receiver chain).

 In short, you have not added any scaling at all, or reduced the security
 of the system significantly, as well as made it significantly less
 convenient to use.

 So no, sidechains are not a direct means for solving any of the scaling
 problems Bitcoin has. What they offer is a mechanism for easier
 experimentation, so that new technology can be built and tested without
 needing to introduce a new currency first (with the related speculative and
 network effect problems). That experimentation could eventually lead us to
 discover mechanisms for better scaling, or for more scalability/security
 tradeoffs (see for example the Witness Segregation that Elements Alpha has).


Thanks Pieter for your reply. The chain the transaction goes to does not
have to be based on the address (there can be a way for the protocol to
choose), but ya, the address scheme can be a good default. As I said, there
will be an incentive for empty chains to fill up since they will require
less fees (so the scaling benefit isn't dependent on a uniform distribution
of addresses).

The rule I mentioned is that at most 2 different chains can be involved in
one transaction. From a chain to itself is easy. From a parent or
grandparent chain to its child or grandchild chain, is also easy since the
child/grandchild always trusts its parent/grandparent. From a
child/grandchild to parent/grandparent, is also easy (no delay) since the
parent/grandparent will commit to its children (which recursively commit to
their children). As mentioned I am just doing a form of block extensions as
Adam Back described; the chains are not independent. From one chain to
another chain at the same level (sibling chains), the transaction is
recorded on both sibling chains (yes there is some duplication but this is
limited by requiring at most 2 sibling chains participating in a
transaction). They both have to be consistent and this will be ensured by
the miners of their parent chain (those miners will commit to their blocks).

So no, I don't see how it's slower, except that there needs to be some
delay for communication between children/grandchildren and
parents/grandparents, of time O(log n) where n is the number of levels.
Even a small number of levels corresponds to a large transaction volume: n
= 5 corresponds to the equivalent of 625 MB blocks.

Security-wise, it is true that the top level chain will likely have higher
security (more hash power), but at least you can fine tune the fees you pay
according to what level of security is acceptable to you, and as Bitcoin
grows, level 2,3,4 chains can be regarded as almost as secure as the level
1 chain, since there will still be a lot of hash power on them. And anyone
can run a full node on their chains of interest, so there is no SPV level
security here, it is full level security.

Transactions are not significantly different. Miners just have to deal with
child chains, but if there is a scaling benefit, we should not be scared of
complexity. It is probably the simplest way I can think of scaling.

The recipient will validate their own chain fully and will just need the
headers of the relevant parent chains to see whether an output from the
other chain involved in a transaction is really valid. They can also get
the headers of the sibling chain involved in the transaction if they want
to validate the work of the miners on these parent chains. They don't need
the full blocks of the parent and sibling chains involved 

Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Danny Thorpe
Please forgive my ignorance, but why should Bitcoin users have a say in
block size limits?  It's the miners and Bitcoin node operators that bear
the burden of managing large blocks, no?

Users voting on network parameters sounds like neighbors voting on how deep
my swimming pool should be.

Thanks,
-Danny

On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd p...@petertodd.org wrote:

 Jeff Garzik recently proposed that the upper blocksize limit be removed
 entirely, with a soft limit being enforced via miner vote, recorded by
 hashing power.

 This mechanism within the protocol for users to have any influence over
 the miner vote. We can add that back by providing a way for transactions
 themselves to set a flag determining whether or not they can be included
 in a block casting a specific vote.

 We can simplify Garzik's vote to say that one of the nVersion bits
 either votes for the blocksize to be increased, or decreased, by some
 fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
 nVersion bit in transactions themselves, also voting for an increase or
 decrease. Transactions may only be included in blocks with an
 indentical vote, thus providing miners with a monetary incentive via
 fees to vote according to user wishes.

 Of course, to cast a don't care vote we can either define an
 additional bit, or sign the transaction with both versions. Equally we
 can even have different versions with different fees, broadcast via a
 mechanism such as replace-by-fee.


 See also John Dillon's proposal for proof-of-stake blocksize voting:


 https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html

 --
 'peter'[:-1]@petertodd.org
 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778


 --

 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-13 Thread Eric Lombrozo
That’s exactly the problem with Bitcoin - it was supposed to be the case that 
users ARE the miners and node operators…but…alas…

 On Jun 13, 2015, at 3:20 PM, Danny Thorpe danny.tho...@gmail.com wrote:
 
 Please forgive my ignorance, but why should Bitcoin users have a say in block 
 size limits?  It's the miners and Bitcoin node operators that bear the burden 
 of managing large blocks, no?
 
 Users voting on network parameters sounds like neighbors voting on how deep 
 my swimming pool should be.
 
 Thanks,
 -Danny
 
 On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd p...@petertodd.org 
 mailto:p...@petertodd.org wrote:
 Jeff Garzik recently proposed that the upper blocksize limit be removed
 entirely, with a soft limit being enforced via miner vote, recorded by
 hashing power.
 
 This mechanism within the protocol for users to have any influence over
 the miner vote. We can add that back by providing a way for transactions
 themselves to set a flag determining whether or not they can be included
 in a block casting a specific vote.
 
 We can simplify Garzik's vote to say that one of the nVersion bits
 either votes for the blocksize to be increased, or decreased, by some
 fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
 nVersion bit in transactions themselves, also voting for an increase or
 decrease. Transactions may only be included in blocks with an
 indentical vote, thus providing miners with a monetary incentive via
 fees to vote according to user wishes.
 
 Of course, to cast a don't care vote we can either define an
 additional bit, or sign the transaction with both versions. Equally we
 can even have different versions with different fees, broadcast via a
 mechanism such as replace-by-fee.
 
 
 See also John Dillon's proposal for proof-of-stake blocksize voting:
 
 https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
  
 https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
 
 --
 'peter'[:-1]@petertodd.org http://petertodd.org/
 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
 
 --
 
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net 
 mailto:Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 
 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development