Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

2015-12-12 Thread Mark Friedenbach via bitcoin-dev 
A segwit supporting server would be required to support relaying segwit
transactions, although a non-segwit server could at least inform a wallet
of segwit txns observed, even if it doesn't relay all information necessary
to validate.

Non segwit servers and wallets would continue operations as if nothing had
occurred.
If this means essentially that a soft fork deployment of SegWit will
require SPV wallet servers to change their logic (or risk not being able to
send payments) then it does seem to me that a hard fork to deploy this non
controversial change is not only cleaner (on the data structure side) but
safer in terms of the potential to affect the user experience.


— Regards,


On Sat, Dec 12, 2015 at 1:43 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Dec 11, 2015 at 11:18 AM, Jorge Timón  wrote:
>
>> This is basically what I meant by
>>
>> struct hashRootStruct
>> {
>> uint256 hashMerkleRoot;
>> uint256 hashWitnessesRoot;
>> uint256 hashextendedHeader;
>> }
>>
>> but my design doesn't calculate other_root as it appears in your tree (is
>> not necessary).
>>
>> It is necessary to maintain compatibility with SPV nodes/wallets.
>
> Any code that just checks merkle paths up into the block header would have
> to change if the structure of the merkle tree changed to be three-headed at
> the top.
>
> If it remains a binary tree, then it doesn't need to change at all-- the
> code that produces the merkle paths will just send a path that is one step
> deeper.
>
> Plus, it's just weird to have a merkle tree that isn't a binary tree.
>
> --
> --
> Gavin Andresen
>


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness

2015-12-12 Thread Jorge Timón via bitcoin-dev 
On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback  wrote:
>>If it's voting for something consensus, you will need something special. If
>> it's not consensus (ie external) thw voting doesn't have to hit the chain at
>> all.
>
> I had in mind voting for something that can't be trusted if done externally:
> Perhaps BIPs for instance.  People would somehow "mark" their BTC as being
> "For Proposition X" (as opposed to all other propositions) and the vote
> would be canceled as soon as the BTC is spent again.
>
> Unfortunately, I've spent the past 2 days trying to find a design that would
> allow this (I don't think my original suggestion made sense in the context
> of how transactions work), and I haven't gotten much yet.

Well, as said, if it's for consensus, you will need to adapt the
system in a special way anyway, but I still don't see why turing
completeness is required.
This type of idea is not new. Since miners can censor votes (and
that's undetectable for consensus), several solutions have been
proposed, time lock the votes, for example.

>>But each scriptSig is only executed once with its corresponding
>> scriptPubKey. Are you proposing we change that?
>
> Sorry, I didn't understand Bitcoin's transaction model well enough when I
> first made the proposal.  If Turing Pseudo-Completeness is possible with
> Bitcoin, then I understand now that it could not require you to execute a
> script more than once.  My current thought is that recursion can be
> accomplished via checking if the next output's scriptPubKey is identical in
> every way to the current scriptPubKey.  Unfortunately, a lot more is needed
> than just recursion in order to do on-chain BTC voting the way I have in
> mind.  I'll keep working on this.

What you call "recursion" seems similar to what we usually call "covenants", see

https://bitcointalk.org/index.php?topic=278122.0

Although the thread says "an amusingly bad idea", I think it's
actually a great idea and there's some use cases that are very hard to
support without covenants.
Again, no Turing completeness required for this.

> On Fri, Dec 11, 2015 at 10:36 AM, Jorge Timón  wrote:
>>
>>
>> On Dec 10, 2015 7:36 AM, "Luke Durback"  wrote:
>> >
>> > Tomorrow, I'll work on writing a way to do voting on proposals with BTC
>> > used as voting shares (This will be difficult as I do not know FORTH).  
>> > That
>> > seems like a fairly simple, useful example that will require loops and
>> > reused functions.  I'll add a fee that goes to the creator.
>>
>> If it's voting for something consensus, you will need something special.
>> If it's not consensus (ie external) thw voting doesn't have to hit the chain
>> at all.
>> I don't see how "loops and reused functions" are needed in the scripting
>> language for this use case, but I'm probably missing some details. Please,
>> the more concrete you make your example, the easiest it will be for me to
>> understand.
>>
>> > IMO, if you write a complicated system of scripts that's used
>> > frequently, it makes sense to charge a fee for its usage.
>>
>> But each scriptSig is only executed once with its corresponding
>> scriptPubKey. Are you proposing we change that?
>>
>> >  A decentralized exchange between colored coins, for instance might take
>> > a small fee on each trade.
>>
>> I've been researching the topic of decentralized exchange from before the
>> term "colored coins" was first used (now there's multiple designs and
>> implementations); contributed to and reviewed many designs: none of them
>> (colored coins or not) required turing completeness.
>> I'm sorry, but what you are saying here is too vague for me to concretely
>> be able to refute the low level "needs" you claim your use cases to have.
>>
>> > On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev"
>> >  wrote:
>> > > This, combined with the ability to make new transactions arbitrarily
>> > > would allow a function to pay its creator.
>> >
>> > I don't understand what you mean by "a function" in this context, I
>> > assume you mean a scriptSig, but then "paying its creator" doesn't make 
>> > much
>> > sense to me .
>> >
>> > Could you provide some high level examples of the use cases you would
>> > like to support with this?
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

2015-12-12 Thread Vincent Truong via bitcoin-dev 
Dormant threshold is way too low. There's many news articles about people
forgetting that they used to mine bitcoins and then suddenly remembered.
This will continue to happen for much longer than 8 years as people
rediscover bitcoin when it goes further mainstream. You can't expect them
to have run a node/kept their utxo before they were aware of this change
and then realise miners have discarded their utxo. Oops?

Since we can't predict when mainstream will happen, you instead need a
threshold where the key holder is likely dead. That should be like 80 years
or 120 years, so 4.2m to 6.3m confirmations.

Next paragraph is off topic:

IMO it would be even better for these dormant & dead key holder's utxos to
also re-enter the economy as miner fees; let 1 dormant utxo to be mined per
block. It would need a hard fork. But then maybe people would stop being so
stupid with burning bitcoins/sending it to 1BitcoinEater, or mining a
million bitcoins from day 1 and leaving it, if they know it'll eventually
go into another miner's pockets. This could be used to fund cheap
transactions forever, and miners would be incentivised to hold copies of
these dormant utxos since it could become theirs one day. But this would be
even more controversial than just expiring them as we are in no short
supply of people who believe in Bitcoin's deflationary, fossil fuel
(burnable) economy, rather than a cyclical economy that better resembles
how we treat lost gold today...
On Dec 13, 2015 10:29 AM, "gb via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The general concept has merit and the basic outline here seems sound
> enough. I have harboured a notion for having "archived UTXO" for some
> time, this is essentially it. The retrieval from archive cost is on the
> UTXO holder not the entire storage network, which is then only bearing
> full 'instant' retrieval costs for N blocks.
>
> On Sat, 2015-12-12 at 15:09 -0500, jl2012--- via bitcoin-dev wrote:
> > It is a common practice in commercial banks that a dormant account might
> > be confiscated. Confiscating or deleting dormant UTXOs might be too
> > controversial, but allowing the UTXOs set growing without any limit
> > might not be a sustainable option. People lose their private keys.
> > People do stupid things like sending bitcoin to 1BitcoinEater. We
> > shouldn’t be obliged to store everything permanently. This is my
> > proposal:
> >
> > Dormant UTXOs are those UTXOs with 42 confirmations. In every block
> > X after 42, it will commit to a hash for all UTXOs generated in
> > block X-42. The UTXOs are first serialized into the form:
> > txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated.
> > After some confirmations, nodes may safely delete the UTXO records of
> > block X permanently.
> >
> > If a user is trying to redeem a dormant UTXO, in addition the signature,
> > they have to provide the scriptPubKey, height (X), and UTXO value as
> > part of the witness. They also need to provide the Merkle path to the
> > dormant UTXO commitment.
> >
> > To confirm this tx, the miner will calculate a new Merkle hash for the
> > block X, with the hash of the spent UTXO replaced by 1, and commit the
> > hash to the current block. All full nodes will keep an index of latest
> > dormant UTXO commitments so double spending is not possible. (a
> > "meta-UTXO set")
> >
> > If all dormant UTXOs under a Merkle branch are spent, hash of the branch
> > will become 1. If all dormant UTXOs in a block are spent, the record for
> > this block could be forgotten. Full nodes do not need to remember which
> > particular UTXO is spent or not, since any person trying to redeem a
> > dormant UTXO has to provide such information.
> >
> > It becomes the responsibility of dormant coin holders to scan the
> > blockchain for the current status of the UTXO commitment for their coin.
> > They may also need to pay extra fee for the increased tx size.
> >
> > This is a softfork if there is no hash collision but this is a
> > fundamental assumption in Bitcoin anyway. The proposal also works
> > without segregated witness, just by replacing "witness" with "scriptSig"
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

2015-12-12 Thread Gregory Maxwell via bitcoin-dev 
On Sun, Dec 13, 2015 at 1:00 AM, Vincent Truong via bitcoin-dev
 wrote:
> have run a node/kept their utxo before they were aware of this change and
> then realise miners have discarded their utxo. Oops?

I believe you have misunderstood jl2012's post.  His post does not
cause the outputs to become discarded. They are still spendable,
but the transactions must carry a membership proof to spend them.
They don't have to have stored the data themselves, but they must
get it from somewhere-- including archive nodes that serve this
purpose rather than having every full node carry all that data forever.

Please be conservative with the send button. The list loses its
utility if every moderately complex idea is hit with reflexive
opposition by people who don't understand it.

Peter Todd has proposed something fairly similar with "STXO
commitments". The primary argument against this kind of approach that
I'm aware of is that the membership proofs get pretty big, and if too
aggressive this trades bandwidth for storage, and storage is usually
the cheaper resource. Though at least the membership proofs could be
omitted when transmitting to a node which has signaled that it has
kept the historical data anyways.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness

2015-12-12 Thread Emin Gün Sirer via bitcoin-dev 
.,
,
/.
, /,

,.
   / ,
..
,,,  . // .,  .

_. ...  ..   ._.

,_


,



,
,
  , , ... _  _.

,.

.  ,.,_.
.,,  ..
,

,,

._

.  .

_
.
,
, ,,   /..,,

/ ,

. .

_
.,. _.. ,
,

.. _
   ..

,.,, _
, _
,
///
. ,

   / . ,.
  ,
,.,
. ,
, .,   ,. ._ ,  ,,,//

,,
.

,

,
  . . ,

, //  .
,  ,
/

  _,.

, . ,, .

..
  /,/ .
.


  .   .,,_//
,,
.,  .

.  /_. ,
/
.
  /
.._
.
,, / .
   . _ ,
,  ,
/ ,_ .,
, ,,, ..  ,
  ,

  /.,.
  /. /
. ,/  ,

. .   /,
/,
._
   ,/.
_
.,
,//
, .,,, , ,, ,
,

,.   ,.,.  .

,  .,.  .,   ,
/   _
.
/
  ,.,. ,
,._


,,

, _ _ ,

,
. ,,   ,  _


_..,

  ,
// ,
__ /
!;"$'''. b
__

On Sat, Dec 12, 2015, 3:01 PM Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Dec 11, 2015 at 10:45 PM, Luke Durback 
> wrote:
> >>If it's voting for something consensus, you will need something special.
> If
> >> it's not consensus (ie external) thw voting doesn't have to hit the
> chain at
> >> all.
> >
> > I had in mind voting for something that can't be trusted if done
> externally:
> > Perhaps BIPs for instance.  People would somehow "mark" their BTC as
> being
> > "For Proposition X" (as opposed to all other propositions) and the vote
> > would be canceled as soon as the BTC is spent again.
> >
> > Unfortunately, I've spent the past 2 days trying to find a design that
> would
> > allow this (I don't think my original suggestion made sense in the
> context
> > of how transactions work), and I haven't gotten much yet.
>
> Well, as said, if it's for consensus, you will need to adapt the
> system in a special way anyway, but I still don't see why turing
> completeness is required.
> This type of idea is not new. Since miners can censor votes (and
> that's undetectable for consensus), several solutions have been
> proposed, time lock the votes, for example.
>
> >>But each scriptSig is only executed once with its corresponding
> >> scriptPubKey. Are you proposing we change that?
> >
> > Sorry, I didn't understand Bitcoin's transaction model well enough when I
> > first made the proposal.  If Turing Pseudo-Completeness is possible with
> > Bitcoin, then I understand now that it could not require you to execute a
> > script more than once.  My current thought is that recursion can be
> > accomplished via checking if the next output's scriptPubKey is identical
> in
> > every way to the current scriptPubKey.  Unfortunately, a lot more is
> needed
> > than just recursion in order to do on-chain BTC voting the way I have in
> > mind.  I'll keep working on this.
>
> What you call "recursion" seems similar to what we usually call
> "covenants", see
>
> https://bitcointalk.org/index.php?topic=278122.0
>
> Although the thread says "an amusingly bad idea", I think it's
> actually a great idea and there's some use cases that are very hard to
> support without covenants.
> Again, no Turing completeness required for this.
>
> > On Fri, Dec 11, 2015 at 10:36 AM, Jorge Timón  wrote:
> >>
> >>
> >> On Dec 10, 2015 7:36 AM, "Luke Durback"  wrote:
> >> >
> >> > Tomorrow, I'll work on writing a way to do voting on proposals with
> BTC
> >> > used as voting shares (This will be difficult as I do not know
> FORTH).  That
> >> > seems like a fairly simple, useful example that will require loops and
> >> > reused functions.  I'll add a fee that goes to the creator.
> >>
> >> If it's voting for something consensus, you will need something special.
> >> If it's not consensus (ie external) thw voting doesn't have to hit the
> chain
> >> at all.
> >> I don't see how "loops and reused functions" are needed in the scripting
> >> language for this use case, but I'm probably missing some details.
> Please,
> >> the more concrete you make your example, the easiest it will be for me
> to
> >> understand.
> >>
> >> > IMO, if you write a complicated system of scripts that's used
> >> > frequently, it makes sense to charge a fee for its usage.
> >>
> >> But each scriptSig is only executed once with its corresponding
> >> scriptPubKey. Are you proposing we change that?
> >>
> >> >  A decentralized exchange between colored coins, for instance might
> take
> >> > a small fee on each trade.
> >>
> >> I've been researching the topic of decentralized exchange from before
> the
> >> term "colored coins" was first used (now there's multiple designs and
> >> implementations); contributed to and reviewed many designs: none of them
> >> (colored coins or not) required turing completeness.
> >> I'm sorry, but what you are saying here is too vague for me to
> concretely
> >> be able to refute the low level "needs" you claim your use cases to
> have.
> >>
> >> > On Dec 10, 2015 10:10 AM, "Luke Durback via bitcoin-dev"
> >> >  wrote:
> >> > > This, combined with the ability to make new transactions arbitrarily
> >> > > would allow a function to pay its creator.
> >> >
> >> >

[bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

2015-12-12 Thread jl2012--- via bitcoin-dev 
It is a common practice in commercial banks that a dormant account might 
be confiscated. Confiscating or deleting dormant UTXOs might be too 
controversial, but allowing the UTXOs set growing without any limit 
might not be a sustainable option. People lose their private keys. 
People do stupid things like sending bitcoin to 1BitcoinEater. We 
shouldn’t be obliged to store everything permanently. This is my 
proposal:


Dormant UTXOs are those UTXOs with 42 confirmations. In every block 
X after 42, it will commit to a hash for all UTXOs generated in 
block X-42. The UTXOs are first serialized into the form: 
txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated. 
After some confirmations, nodes may safely delete the UTXO records of 
block X permanently.


If a user is trying to redeem a dormant UTXO, in addition the signature, 
they have to provide the scriptPubKey, height (X), and UTXO value as 
part of the witness. They also need to provide the Merkle path to the 
dormant UTXO commitment.


To confirm this tx, the miner will calculate a new Merkle hash for the 
block X, with the hash of the spent UTXO replaced by 1, and commit the 
hash to the current block. All full nodes will keep an index of latest 
dormant UTXO commitments so double spending is not possible. (a 
"meta-UTXO set")


If all dormant UTXOs under a Merkle branch are spent, hash of the branch 
will become 1. If all dormant UTXOs in a block are spent, the record for 
this block could be forgotten. Full nodes do not need to remember which 
particular UTXO is spent or not, since any person trying to redeem a 
dormant UTXO has to provide such information.


It becomes the responsibility of dormant coin holders to scan the 
blockchain for the current status of the UTXO commitment for their coin. 
They may also need to pay extra fee for the increased tx size.


This is a softfork if there is no hash collision but this is a 
fundamental assumption in Bitcoin anyway. The proposal also works 
without segregated witness, just by replacing "witness" with "scriptSig"


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

2015-12-12 Thread gb via bitcoin-dev 
The general concept has merit and the basic outline here seems sound
enough. I have harboured a notion for having "archived UTXO" for some
time, this is essentially it. The retrieval from archive cost is on the
UTXO holder not the entire storage network, which is then only bearing
full 'instant' retrieval costs for N blocks.

On Sat, 2015-12-12 at 15:09 -0500, jl2012--- via bitcoin-dev wrote:
> It is a common practice in commercial banks that a dormant account might 
> be confiscated. Confiscating or deleting dormant UTXOs might be too 
> controversial, but allowing the UTXOs set growing without any limit 
> might not be a sustainable option. People lose their private keys. 
> People do stupid things like sending bitcoin to 1BitcoinEater. We 
> shouldn’t be obliged to store everything permanently. This is my 
> proposal:
> 
> Dormant UTXOs are those UTXOs with 42 confirmations. In every block 
> X after 42, it will commit to a hash for all UTXOs generated in 
> block X-42. The UTXOs are first serialized into the form: 
> txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated. 
> After some confirmations, nodes may safely delete the UTXO records of 
> block X permanently.
> 
> If a user is trying to redeem a dormant UTXO, in addition the signature, 
> they have to provide the scriptPubKey, height (X), and UTXO value as 
> part of the witness. They also need to provide the Merkle path to the 
> dormant UTXO commitment.
> 
> To confirm this tx, the miner will calculate a new Merkle hash for the 
> block X, with the hash of the spent UTXO replaced by 1, and commit the 
> hash to the current block. All full nodes will keep an index of latest 
> dormant UTXO commitments so double spending is not possible. (a 
> "meta-UTXO set")
> 
> If all dormant UTXOs under a Merkle branch are spent, hash of the branch 
> will become 1. If all dormant UTXOs in a block are spent, the record for 
> this block could be forgotten. Full nodes do not need to remember which 
> particular UTXO is spent or not, since any person trying to redeem a 
> dormant UTXO has to provide such information.
> 
> It becomes the responsibility of dormant coin holders to scan the 
> blockchain for the current status of the UTXO commitment for their coin. 
> They may also need to pay extra fee for the increased tx size.
> 
> This is a softfork if there is no hash collision but this is a 
> fundamental assumption in Bitcoin anyway. The proposal also works 
> without segregated witness, just by replacing "witness" with "scriptSig"
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev