Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Mark Friedenbach]

What retail needs is escrowed microchannel hubs (what lightning provides,
for example), which enable untrusted instant payments. Not reliance on
single-signer zeroconf transactions that can never be made safe.

On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson 
wrote:

> I have some experience here. If you are seriously suggesting these
> measures, you might as well kill retail transactions altogether.
>
> In practice, if a retail place starts to accept bitcoin they have a
> similar situation as with cash, only that the fraud potential is much
> lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
> and the fraud frequency is also much lower.
>
> 0-conf concerns were never a problem in practice. except for 2-way atms
> i have never heard of a problem that was caused by double spends.
> while adding these measures is generally positive, requiring them means
> excluding 99.9% of the potential users. so you might as well not do it.
>
> RBF as implemented by F2Pool just flat out lowers Bitcoins utility
> value. So it's a bad thing.
>
> for any online or automated system, waiting for a handful of
> confirmations was always recommended practice.
>
> Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
> > Retail POS merchants probably should not be accepting vanilla Bitcoin
> > payments, as Bitcoin alone does not (and cannot) guarantee the
> > irreversibility of a transaction until it has been buried several
> > blocks deep in the chain. Retail merchants should be requiring a
> > co-signature from a mutually trusted co-signer that vows never to sign
> > a double-spend.
>
>
>
> --
>
> ___
> 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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Mark Friedenbach]

On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik  wrote:

>
> The whole point is getting out in front of the need, to prevent
> significant negative impact to users when blocks are consistently full.
>
> To do that, you need to (a) plan forward, in order to (b) set a hard fork
> date in the future.
>

Or alternatively, fix the reasons why users would have negative experiences
with full blocks, chiefly:

  * Get safe forms of replace-by-fee and child-pays-for-parent finished and
in 0.12.
  * Develop cross-platform libraries for managing micropayment channels,
and get wallet authors to adopt
  * Use fidelity bonds, solvency proofs, and other tricks to minimize the
risk of already deployed off-chain solutions as an interim measure until:
  * Deploy soft-fork changes for truly scalable solutions like Lightning
Network.

Not raising the block size limit does not mean doing nothing to solve the
problem.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Mark Friedenbach]

Matt, I for one do not think that the block size limit should be raised at
this time. Matt Corallo also started the public conversation over this
issue on the mailing list by stating that he was not in favor of acting now
to raise the block size limit. I find it a reasonable position to take that
even if you feel the block size limit should be raised at some time in the
future, there are reasons why now is not the best time to do it.

On Thu, Jun 18, 2015 at 2:42 PM, Matt Whitlock 
wrote:

> On Thursday, 18 June 2015, at 8:31 pm, Ross Nicoll wrote:
> > I may disagree with Mike & Gavin on timescale, but I do believe there's
> > a likelihood inaction will kill Bitcoin
>
> An honest question: who is proposing inaction? I haven't seen anyone in
> this whole, agonizing debate arguing that 1MB blocks are adequate. The
> debate has been about *how* to increase the block-size limit and whether to
> take action ASAP (at the risk of fracturing Bitcoin) or to delay action for
> further debate (at the risk of overloading Bitcoin). Even those who are
> arguing for further debate are not arguing for *inaction*.
>
>
> --
> ___
> 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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Mark Friedenbach]

On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn  wrote:

> The first issue is how are decisions made in Bitcoin Core? I struggle to
> explain this to others because I don't understand it myself. Is it a vote
> of people with commit access? Is it a 100% agreement of "core developers"
> and if so, who are these people? Is it "whoever reverts the change last"?
> Could I write down in a document a precise description of how decisions are
> made? No, and that's been a fairly frustrating problem for a long time.
>

There is a quote from United States Supreme Court Justice Potter Stewart to
describe his threshold test for obscenity which is relevant here: "I know
it when I see it."

It is hard certainly, and perhaps even impossible to write down a system of
rules that is used to resolve every dispute among core developers. But that
doesn't mean it isn't obvious to all the participants what is going on. If
a contentious change is proposed, and if after sufficient debate there are
still members of the technical community with reasoned, comprehensible
objections who are not merely being obstinate in the views -- a neutral
observer would agree that their concerns have not been met -- then there is
a lack of consensus.

If there was some sort of formal process however, the system wouldn't work.
Rules can be gamed, and if you add rules to a process then that process can
be gamed. Instead we all have a reasonable understanding of what "technical
consensus" is, and we all know it when we see it. Where we do not see it,
we do not proceed.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Mark Friedenbach]

Given that we have had more than two weeks of public discussion, code is
available and reviewed, and several community identified issues resolved, I
would like to formally request a BIP number be assigned for this work. Will
the BIP editor be so kind as to do so to allow the BIP consensus process to
proceed?

Thank you,
Mark Friedenbach

On Mon, Jun 1, 2015 at 6:49 PM, Mark Friedenbach 
wrote:

> I have written a reference implementation and BIP draft for a soft-fork
> change to the consensus-enforced behaviour of sequence numbers for the
> purpose of supporting transaction replacement via per-input relative
> lock-times. This proposal was previously discussed on the mailing list in
> the following thread:
>
> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>
> In short summary, this proposal seeks to enable safe transaction
> replacement by re-purposing the nSequence field of a transaction input to
> be a consensus-enforced relative lock-time.
>
> The advantages of this approach is that it makes use of the full range of
> the 32-bit sequence number which until now has rarely been used for
> anything other than a boolean control over absolute nLockTime, and it does
> so in a way that is semantically compatible with the originally envisioned
> use of sequence numbers for fast mempool transaction replacement.
>
> The disadvantages are that external constraints often prevent the full
> range of sequence numbers from being used when interpreted as a relative
> lock-time, and re-purposing nSequence as a relative lock-time precludes its
> use in other contexts. The latter point has been partially addressed by
> having the relative lock-time semantics be enforced only if the
> most-significant bit of nSequence is set. This preserves 31 bits for
> alternative use when relative lock-times are not required.
>
> The BIP draft can be found at the following gist:
>
> https://gist.github.com/maaku/be15629fe64618b14f5a
>
> The reference implementation is available at the following git repository:
>
> https://github.com/maaku/bitcoin/tree/sequencenumbers
>
> I request that the BIP editor please assign a BIP number for this work.
>
> Sincerely,
> Mark Friedenbach
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Mark Friedenbach]

On Mon, Jun 15, 2015 at 5:08 PM, Aaron Voisine  wrote:

> Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core
> maintainers simply refuse to lift the 1Mb limit? No one wants to go that
> route. An alternate hard-fork proposal like BIP100 that gets consensus, or
> a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or
> hell even some major changes to the non-consunsus code to make it
> adequately handle the situation when blocks fill up, and allow wallet
> software to continue working with a send-and-forget use pattern, any of
> these would be enough to avoid the need for an XT only hard-fork.
>
> So far BIP100 is the only one that seems to actually be getting any sort
> of momentum toward consensus, and it was proposed... 2 days ago? When the
> XT fork was proposed as a last resort, it was when the opponents were (to
> my understanding) suggesting we just let blocks fill up, and hopefully
> things would just work out on their own.
>

We are not reaching consensus about any proposal, Garzik's or otherwise.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

[Mark Friedenbach]

There's another important use case which you mentioned Greg, that also
requires special exemption: compact commitments via mid-state compression.

The use case is an OP_RETURN output sorted last, whose last N bytes are a
commitment of some kind. A proof of the commitment can then use mid state
compression to elide the beginning of the transaction.

How do you make a special exemption for this category of outputs? I can't
think of a very clean way of doing so that doesn't require an ugly
advertising of sort-order exemptions.

The fact that we have two different existing use cases which conflict with
soft-fork enforcement, I'm quiet concerned that there are either other
things we aren't thinking of or haven't invented yet which would be
affected.

On Sun, Jun 14, 2015 at 7:33 PM, Gregory Maxwell  wrote:

> On Mon, Jun 15, 2015 at 2:29 AM, Rusty Russell 
> wrote:
> > The softfork argument I find the most compelling, though it's tempting
> > to argue that every ordering use (including SIGHASH_SINGLE) is likely
> > a mistake.
>
> Oh.
>
> Hm.
>
> It is the case that the generalized sighash flag design I was thinking
> about was actually completely neutral about ordering, and yet still
> replaced SINGLE.
>
> I need to think a bit on that.
>
>
> --
> ___
> 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

[Mark Friedenbach]

Peter it's not clear to me that your described protocol is free of miner
influence over the vote, by artificially generating transactions which they
claim in their own blocks, or conforming incentives among voters by opting
to be with the (slight) majority in order to minimize fees.

Wouldn't it in fact be simpler to use the dynamic block size adjustment
algorithm presented to the list a few weeks back, where the miner opts for
a larger block by sacrificing fees? In that way the users "vote" for larger
blocks by including sufficient fees to offset subsidy, but as it is an
economic incentives miners gain nothing by inflating the fees in their own
blocks.

On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd  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] [RFC] Canonical input and output ordering in transactions

[Mark Friedenbach]

Certainly, but I would drop discussion of IsStandard or consensus rules.
On Jun 6, 2015 1:24 AM, "Wladimir J. van der Laan"  wrote:

> On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote:
> > Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
> > assurance contracts among other things. Sometimes the ordering is set by
> > the signing logic itself...
>
> But in that case (unconstrained) randomization can't be used either. This
> is posed as an alternative to randomization. So in that regard, the
> proposal still makes sense.
> I think this move to verifyable, deterministic methods where possible is
> good.
>
> Wladimir
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

[Mark Friedenbach]

Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
assurance contracts among other things. Sometimes the ordering is set by
the signing logic itself...
On Jun 5, 2015 9:43 PM, "Rusty Russell"  wrote:

> Title: Canonical Input and Output Ordering
> Author: Rusty Russell 
> Discussions-To: "Bitcoin Dev" 
> Status: Draft
> Type: Standards Track
> Created: 2015-06-06
>
> Abstract
>
> This BIP provides a canonical ordering of inputs and outputs when
> creating transactions.
>
> Motivation
>
> Most bitcoin wallet implementations randomize the outputs of
> transactions they create to avoid trivial linkage analysis (especially
> change outputs), however implementations have made mistakes in this area
> in the past.
>
> Using a canonical ordering has the same effect, but is simpler, more
> obvious if incorrect, and can eventually be enforced by IsStandard() and
> even a soft-fork to enforce it.
>
> Specification
>
> Inputs should be ordered like so:
> index (lower value first)
> txid (little endian order, lower byte first)
>
> Outputs should be ordered like so:
> amount (lower value first)
> script (starting from first byte, lower byte first, shorter wins)
>
> Rationale
>
> Any single wallet is already free to implement this, but if other
> wallets do not it would reduce privacy by making those transactions
> stand out.  Thus a BIP is appropriate, especially if this were to
> become an IsStandard() rule once widely adopted.
>
> Because integers are fast to compare, they're sorted first, before the
> lexographical ordering.
>
> The other input fields do not influence the sort order, as any valid
> transactions cannot have two inputs with the same index and txid.
>
> Reference Implementation
>
> https://github.com/rustyrussell/bitcoin/tree/bip-in-out-ordering
>
>
> --
> ___
> 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] Tough questions for Peter Todd, Chief Scientist {Mastercoin | Counterparty | Coinkite | Darkwallet | Viacoin}

[Mark Friedenbach]

Why is this your business or the business of anyone on this list? Take it
somewhere else.

On Thu, Jun 4, 2015 at 2:52 PM, Sven Berg  wrote:

> 1) Hours/week have you devoted to each project out of a 40hr work week
>
> 2) Upfront and ongoing fees for use of your name
>
> 3) Break down total amounts for each project
>
> 4) Start dates of contracts for each project
>
> 5) End dates (if applicable)
>
> 6) Current and past holdings of altcoins/appcoins (including liquidation
> dates)
>
> 7) Describe return on investment to investors related to your activities
> during employment
> (other than marketing/price pump)
>
> 8) Describe your involvement with Initial Coin Offers (ICO) of
> applicable
>
> 9) Explain rational for pursuit of ICO fund sources rather than
> community/established
> businesses (Lighthouse, legit startups, etc.)
>
> --
> Berg Investigations LLC.
>
>
> --
> ___
> 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] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Mark Friedenbach]

Oh it is far worse than that. There is nothing preventing those coins from
being spent somewhere else, so actually an expiry would enable coin theft
in a reorg -- you make your spends expire right after they hit the chain
the first time, and then if there is a reorg the spend and subsequent
transactions are invalidated. This is an exploitable means of theft.

For this reason it is very important to male sure that once a transaction
makes it on the chain, it cannot be invalidated by means of a reorg.
On Jun 2, 2015 6:11 AM, "Adam Back"  wrote:

> That would also introduce the anomaly of a script that was once valid
> becoming later invalid, when nothing varies other than time.  That is
> not super compatible with the current model of reprocessing
> transactions in later blocks if the block they were first in gets
> reorged.
>
> (Not a huge flexibility loss as you can implement "not after" by
> making it the previous holders responsibility to spend a "not before"
> back to themselves.)
>
> Adam
>
> On 2 June 2015 at 13:52, Stephen  wrote:
> > Do you think it would be useful to have an inverted version of both CSV
> and
> > CLTV? To verify if an output is spent before a specific time. CLTV and
> CSV
> > could be implemented by taking two stack arguments, an integer for the
> > comparison and TRUE/FALSE.
> >
> > Now that I think about this more, the problem is that, for example, just
> > having a lock time of less than some value doesn't actually mean it has
> to
> > be spent before that script value, so this might not work. Likely any
> > implementations of such a feature would have to provide the script
> execution
> > environment with access to information that it doesn't have now, which is
> > what we are trying to avoid.
> >
> > Best,
> > Stephen
> >
> >
> >
> > On Jun 2, 2015, at 12:16 AM, Mark Friedenbach 
> wrote:
> >
> > You are correct! I am maintaining a 'checksequenceverify' branch in my
> git
> > repository as well, an OP_RCLTV using sequence numbers:
> >
> > https://github.com/maaku/bitcoin/tree/checksequenceverify
> >
> > Most of the interesting use cases for relative lock-time require an RCLTV
> > opcode. What is interesting about this architecture is that it possible
> to
> > cleanly separate the relative lock-time (sequence numbers) from the RCLTV
> > opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation.
> Like
> > CLTV, the CSV opcode only checks transaction data and requires no
> contextual
> > knowledge about block headers, a weakness of the other RCLTV proposals
> that
> > violate the clean separation between libscript and libconsensus. In a
> > similar way, this BIP proposal only touches the transaction validation
> logic
> > without any impact to script.
> >
> > I would like to propose an additional BIP covering the
> CHECKSEQUENCEVERIFY
> > opcode and its enabling applications. But, well, one thing at a time.
> >
> > On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <
> stephencalebmo...@gmail.com>
> > wrote:
> >>
> >> Hi Mark,
> >>
> >> Overall, I like this idea in every way except for one: unless I am
> missing
> >> something, we may still need an OP_RCLTV even with this being
> implemented.
> >>
> >> In use cases such as micropayment channels where the funds are locked up
> >> by multiple parties, the enforcement of the relative locktime can be
> done by
> >> the first-signing party. So, while your solution would probably work in
> >> cases like this, where multiple signing parties are involved, there may
> be
> >> other, seen or unforeseen, use cases that require putting the relative
> >> locktime right into the spending contract (the scriptPubKey itself).
> When
> >> there is only one signer, there's nothing that enforces using an
> nSequence
> >> and nVersion=2 that would prevent spending the output until a certain
> time.
> >>
> >> I hope this is received as constructive criticism, I do think this is an
> >> innovative idea. In my view, though, it seems to be less fully-featured
> than
> >> just repurposing an OP_NOP to create OP_RCLTV. The benefits are
> obviously
> >> that it saves transaction space by repurposing unused space, and would
> >> likely work for most cases where an OP_RCLTV would be needed.
> >>
> >> Best,
> >> Stephen
> >>
> >> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach 
> >> wrote:
> >>>
> >>> I 

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Mark Friedenbach]

You are correct! I am maintaining a 'checksequenceverify' branch in my git
repository as well, an OP_RCLTV using sequence numbers:

https://github.com/maaku/bitcoin/tree/checksequenceverify

Most of the interesting use cases for relative lock-time require an RCLTV
opcode. What is interesting about this architecture is that it possible to
cleanly separate the relative lock-time (sequence numbers) from the RCLTV
opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like
CLTV, the CSV opcode only checks transaction data and requires no
contextual knowledge about block headers, a weakness of the other RCLTV
proposals that violate the clean separation between libscript and
libconsensus. In a similar way, this BIP proposal only touches the
transaction validation logic without any impact to script.

I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY
opcode and its enabling applications. But, well, one thing at a time.

On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse 
wrote:

> Hi Mark,
>
> Overall, I like this idea in every way except for one: unless I am missing
> something, we may still need an OP_RCLTV even with this being
> implemented.
>
> In use cases such as micropayment channels where the funds are locked up
> by multiple parties, the enforcement of the relative locktime can be done
> by the first-signing party. So, while your solution would probably work in
> cases like this, where multiple signing parties are involved, there may be
> other, seen or unforeseen, use cases that require putting the relative
> locktime right into the spending contract (the scriptPubKey itself). When
> there is only one signer, there's nothing that enforces using an nSequence
> and nVersion=2 that would prevent spending the output until a certain time.
>
> I hope this is received as constructive criticism, I do think this is an
> innovative idea. In my view, though, it seems to be less fully-featured
> than just repurposing an OP_NOP to create OP_RCLTV. The benefits are
> obviously that it saves transaction space by repurposing unused space, and
> would likely work for most cases where an OP_RCLTV would be needed.
>
> Best,
> Stephen
>
> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach 
> wrote:
>
>> I have written a reference implementation and BIP draft for a soft-fork
>> change to the consensus-enforced behaviour of sequence numbers for the
>> purpose of supporting transaction replacement via per-input relative
>> lock-times. This proposal was previously discussed on the mailing list in
>> the following thread:
>>
>> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>>
>> In short summary, this proposal seeks to enable safe transaction
>> replacement by re-purposing the nSequence field of a transaction input to
>> be a consensus-enforced relative lock-time.
>>
>> The advantages of this approach is that it makes use of the full range of
>> the 32-bit sequence number which until now has rarely been used for
>> anything other than a boolean control over absolute nLockTime, and it does
>> so in a way that is semantically compatible with the originally envisioned
>> use of sequence numbers for fast mempool transaction replacement.
>>
>> The disadvantages are that external constraints often prevent the full
>> range of sequence numbers from being used when interpreted as a relative
>> lock-time, and re-purposing nSequence as a relative lock-time precludes its
>> use in other contexts. The latter point has been partially addressed by
>> having the relative lock-time semantics be enforced only if the
>> most-significant bit of nSequence is set. This preserves 31 bits for
>> alternative use when relative lock-times are not required.
>>
>> The BIP draft can be found at the following gist:
>>
>> https://gist.github.com/maaku/be15629fe64618b14f5a
>>
>> The reference implementation is available at the following git repository:
>>
>> https://github.com/maaku/bitcoin/tree/sequencenumbers
>>
>> I request that the BIP editor please assign a BIP number for this work.
>>
>> Sincerely,
>> Mark Friedenbach
>>
>>
>> --
>>
>> ___
>> 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] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

[Mark Friedenbach]

I have written a reference implementation and BIP draft for a soft-fork
change to the consensus-enforced behaviour of sequence numbers for the
purpose of supporting transaction replacement via per-input relative
lock-times. This proposal was previously discussed on the mailing list in
the following thread:

http://sourceforge.net/p/bitcoin/mailman/message/34146752/

In short summary, this proposal seeks to enable safe transaction
replacement by re-purposing the nSequence field of a transaction input to
be a consensus-enforced relative lock-time.

The advantages of this approach is that it makes use of the full range of
the 32-bit sequence number which until now has rarely been used for
anything other than a boolean control over absolute nLockTime, and it does
so in a way that is semantically compatible with the originally envisioned
use of sequence numbers for fast mempool transaction replacement.

The disadvantages are that external constraints often prevent the full
range of sequence numbers from being used when interpreted as a relative
lock-time, and re-purposing nSequence as a relative lock-time precludes its
use in other contexts. The latter point has been partially addressed by
having the relative lock-time semantics be enforced only if the
most-significant bit of nSequence is set. This preserves 31 bits for
alternative use when relative lock-times are not required.

The BIP draft can be found at the following gist:

https://gist.github.com/maaku/be15629fe64618b14f5a

The reference implementation is available at the following git repository:

https://github.com/maaku/bitcoin/tree/sequencenumbers

I request that the BIP editor please assign a BIP number for this work.

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

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Mark Friedenbach]

Oh ok you mean a semantic difference for the purpose of explaining. It
doesn't actually change the code.

Regarding saving more bits, there really isn't much room if you consider
time-based relative locktimes and long-lived channels on the order of a
year or more.

On Thu, May 28, 2015 at 8:18 AM, Tier Nolan  wrote:

> On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach 
> wrote:
>
>> Why 3? Do we have a version 2?
>>
> I meant whatever the next version is, so you are right, it's version 2.
>
>> As for doing it in serialization, that would alter the txid making it a
>> hard fork change.
>>
> The change is backwards compatible (since there is no restrictions on
> sequence numbers).   This makes it a soft fork.
>
> That doesn't change the fact that you are changing what a field in the
> transaction represents.
>
> You could say that the sequence number is no longer encoded in the
> serialization, it is assumed to be 0x for all version 2+
> transactions and the relative locktime is a whole new field that is the
> same size (and position).
>
> I think keeping some of the bytes for other uses is a good idea.  The
> entire top 2 bytes could be ignored when working out relative locktime
> verify.  That leaves them fully free to be set to anything.
>
> It could be that if the MSB of the bottom 2 bytes is set, then that
> activates the rule and the top 2 bytes are ignored.
>
> Are there any use-cases which need a RLTV of more than 8191 blocks delay
> (that can't be covered by the absolute version)?
>
>
> --
>
> ___
> 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] Consensus-enforced transaction replacement via sequence numbers

[Mark Friedenbach]

Why 3? Do we have a version 2?

As for doing it in serialization, that would alter the txid making it a
hard fork change.
On May 28, 2015 03:30, "Tier Nolan"  wrote:

> Can you update it so that it only applies to transactions with version
> number 3 and higher.  Changing the meaning of a field is exactly what the
> version numbers are for.
>
> You could even decode version 3 transactions like that.
>
> Version 3 transactions have a sequence number of 0x and the
> sequence number field is re-purposed for relative lock time.
>
> This means that legacy transactions that have already been signed but have
> a locktime in the future will still be able to enter the blockchain
> (without having to wait significantly longer than expected).
>
> On Thu, May 28, 2015 at 10:56 AM, Mark Friedenbach 
> wrote:
>
>> I have no problem with modifying the proposal to have the most
>> significant bit signal use of the nSequence field as a relative lock-time.
>> That leaves a full 31 bits for experimentation when relative lock-time is
>> not in use. I have adjusted the code appropriately:
>>
>> https://github.com/maaku/bitcoin/tree/sequencenumbers
>>
>> On Wed, May 27, 2015 at 10:39 AM, Mike Hearn  wrote:
>>
>>> Mike, this proposal was purposefully constructed to maintain as well as
>>>> possible the semantics of Satoshi's original construction. Higher sequence
>>>> numbers -- chronologically later transactions -- are able to hit the chain
>>>> earlier, and therefore it can be reasonably argued will be selected by
>>>> miners before the later transactions mature. Did I fail in some way to
>>>> capture that original intent?
>>>>
>>>
>>> Right, but the original protocol allowed for e.g. millions of revisions
>>> of the transaction, hence for high frequency trading (that's actually how
>>> Satoshi originally explained it to me - as a way to do HFT - back then the
>>> channel concept didn't exist).
>>>
>>> As you point out, with a careful construction of channels you should
>>> only need to bump the sequence number when the channel reverses direction.
>>> If your app only needs to do that rarely, it's a fine approach.And your
>>> proposal does sounds better than sequence numbers being useless like at the
>>> moment. I'm just wondering if we can get back to the original somehow or at
>>> least leave a path open to it, as it seems to be a superset of all other
>>> proposals, features-wise.
>>>
>>
>>
>>
>> --
>>
>> ___
>> 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

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Mark Friedenbach]

I have no problem with modifying the proposal to have the most significant
bit signal use of the nSequence field as a relative lock-time. That leaves
a full 31 bits for experimentation when relative lock-time is not in use. I
have adjusted the code appropriately:

https://github.com/maaku/bitcoin/tree/sequencenumbers

On Wed, May 27, 2015 at 10:39 AM, Mike Hearn  wrote:

> Mike, this proposal was purposefully constructed to maintain as well as
>> possible the semantics of Satoshi's original construction. Higher sequence
>> numbers -- chronologically later transactions -- are able to hit the chain
>> earlier, and therefore it can be reasonably argued will be selected by
>> miners before the later transactions mature. Did I fail in some way to
>> capture that original intent?
>>
>
> Right, but the original protocol allowed for e.g. millions of revisions of
> the transaction, hence for high frequency trading (that's actually how
> Satoshi originally explained it to me - as a way to do HFT - back then the
> channel concept didn't exist).
>
> As you point out, with a careful construction of channels you should only
> need to bump the sequence number when the channel reverses direction. If
> your app only needs to do that rarely, it's a fine approach.And your
> proposal does sounds better than sequence numbers being useless like at the
> moment. I'm just wondering if we can get back to the original somehow or at
> least leave a path open to it, as it seems to be a superset of all other
> proposals, features-wise.
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Mark Friedenbach]

On Wed, May 27, 2015 at 3:11 AM, Mike Hearn  wrote:

>
> As I believe out of all proposed protocols Satoshi's is still the most
> powerful, I would suggest that any change to the semantics on nSequence be
> gated by a high bit or something, so the original meaning remains available
> if/when resource scheduling and update flood damping are implemented. That
> way people can try it out and if miners are breaking things too frequently
> by ignoring the chronological ordering people can abandon protocols that
> rely on it, and if they aren't they can proceed and benefit from the
> greater flexibility.
>
>
Mike, this proposal was purposefully constructed to maintain as well as
possible the semantics of Satoshi's original construction. Higher sequence
numbers -- chronologically later transactions -- are able to hit the chain
earlier, and therefore it can be reasonably argued will be selected by
miners before the later transactions mature. Did I fail in some way to
capture that original intent?
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

[Mark Friedenbach]

Sequence numbers appear to have been originally intended as a mechanism for
transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel. The idea is that a participant
can sign successive versions of a transaction, each time incrementing the
sequence field by some amount. Relay nodes perform transaction replacement
according to some policy rule making use of the sequence numbers, e.g.
requiring sequence numbers in a replacement to be monotonically increasing.

As it happens, this cannot be made safe in the bitcoin protocol as deployed
today, as there is no enforcement of the rule that miners include the most
recent transaction in their blocks. As such, any protocol relying on a
transaction replacement policy can be defeated by miners choosing not to
follow that policy, which they may even be incentivised to do so (if older
transactions provide higher fee per byte, for example). Transaction
replacement is presently disabled in Bitcoin Core.

These shortcomings can be fixed in an elegant way by giving sequence
numbers new consensus-enforced semantics as a relative lock-time: if a
sequence number is non-final (MAX_INT), its bitwise inverse is interpreted
as either a relative height or time delta which is added to the height or
median time of the block containing the output being spent to form a
per-input lock-time. The lock-time of each input constructed in this manor,
plus the nLockTime of the transaction itself if any input is non-final must
be satisfied for a transaction to be valid.

For example, a transaction with an txin.nSequence set to 0xff9b [==
~(uint32_t)100] is prevented by consensus rule from being selected for
inclusion in a block until the 100th block following the one including the
parent transaction referenced by that input.

In this way one may construct, for example, a bidirectional micropayment
channel where each change of direction increments sequence numbers to make
the transaction become valid prior to any of the previously exchanged
transactions.

This also enables the discussed relative-form of CHECKLOCKTIMEVERIFY to be
implemented in the same way: by checking transaction data only and not
requiring contextual information like the block height or timestamp.

An example implementation of this concept, as a policy change to the
mempool processing of Bitcoin Core is available on github:

https://github.com/maaku/bitcoin/tree/sequencenumbers
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

[Mark Friedenbach]

Please let's at least have some civility and decorum on this list.

On Tue, May 26, 2015 at 1:30 PM,  wrote:

> You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks
> and you have big banks as clients. Shit like replace-by-fee and leading
> the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out.
>
> Peter Todd - 8930511 Canada Ltd.
> 1214-1423 Mississauga Valley Blvd.
> Mississauga ON L5A 4A5
> Canada
>
>
> https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511
>
> On 2015-05-26 00:10, Peter Todd wrote:
> > On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
> >> CPFP also solves it just fine.
> >
> > CPFP is a significantly more expensive way of paying fees than RBF,
> > particularly for the use-case of defragmenting outputs, with cost
> > savings ranging from 30% to 90%
> >
> >
> > Case 1: CPFP vs. RBF for increasing the fee on a single tx
> > --
> >
> > Creating an spending a P2PKH output uses 34 bytes of txout, and 148
> > bytes of txin, 182 bytes total.
> >
> > Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
> > Alice. This results in a 1in/2out transaction t1 that's 226 bytes in
> > size.
> > I forget to click on the "priority fee" option, so it goes out with the
> > minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
> > creating a new transaction t2 that's 192 bytes in size. I want to pay
> > 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
> > transaction fees.
> >
> > On the other hand, had I use RBF, my wallet would have simply
> > rebroadcast t1 with the change address decreased. The rules require you
> > to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the
> > new
> > fee level, or 218uBTC of fees in total.
> >
> > Cost savings: 48%
> >
> >
> > Case 2: Paying multiple recipients in succession
> > 
> >
> > Suppose that after I pay Alice, I also decide to pay Bob for his hard
> > work demonstrating cryptographic protocols. I need to create a new
> > transaction t2 spending t1's change address. Normally t2 would be
> > another 226 bytes in size, resulting in 226uBTC additional fees.
> >
> > With RBF on the other hand I can simply double-spend t1 with a
> > transaction paying both Alice and Bob. This new transaction is 260
> > bytes
> > in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
> > consumed broadcasting it, resulting in an additional 36uBTC of fees.
> >
> > Cost savings: 84%
> >
> >
> > Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
> > 
> >
> > The above situation gets even worse with multisig. t1 in the multisig
> > case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
> > in fees. With RBF we rewrite t1 with an additional output, resulting in
> > a 399 byte transaction, with just 36uBTC in additional fees.
> >
> > Cost savings: 90%
> >
> >
> > Case 4: Dust defragmentation
> > 
> >
> > My wallet has a two transaction outputs that it wants to combine into
> > one for the purpose of UTXO defragmentation. It broadcasts transaction
> > t1 with two inputs and one output, size 340 bytes, paying zero fees.
> >
> > Prior to the transaction confirming I find I need to spend those funds
> > for a priority transaction at the 1mBTC/KB fee level. This transaction,
> > t2a, has one input and two outputs, 226 bytes in size. However it needs
> > to pay fees for both transactions at once, resulting in a combined
> > total
> > fee of 556uBTC. If this situation happens frequently, defragmenting
> > UTXOs is likely to cost more in additional fees than it saves.
> >
> > With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
> > bytes in size, paying 374uBTC. Even better, if one of the two inputs is
> > sufficiently large to cover my costs I can doublespend t1 with a
> > 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
> >
> > Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
> >   costs you more than you save
> >
> >
> --
> > One dashboard for servers and applications across
> > Physical-Virtual-Cloud
> > Widest out-of-the-box monitoring support with 50+ applications
> > Performance metrics, stats and reports that give you Actionable
> > Insights
> > Deep dive visibility with transaction tracing using APM Insight.
> > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> >
> > ___
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> --
> ___

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

[Mark Friedenbach]

I'm on my phone today so I'm somewhat constrained in my reply, but the key
takeaway is that the proposal is a mechanism for miners to trade subsidy
for the increased fees of a larger block. Necessarily it only makes sense
to do so when the marginal fee per KB exceeds the subsidy fee per KB. It
correspondingly makes sense to use a smaller block size if fees are less
than subsidy, but note that fees are not uniform and as the block shrinks
the marginal fee rate goes up..

Limits on both the relative and absolute amount a miner can trade subsidy
for block size prevent incentive edge cases as well as prevent a sharp
shock to the current fee-poor economy (by disallowing adjustment below 1MB).

Also the identity transform was used only for didactic purposes. I fully
expect there to be other, more interesting functions to use.
On May 10, 2015 3:03 PM, "Thomas Voegtlin"  wrote:

> Le 08/05/2015 22:33, Mark Friedenbach a écrit :
>
> >   * For each block, the miner is allowed to select a different difficulty
> > (nBits) within a certain range, e.g. +/- 25% of the expected difficulty,
> > and this miner-selected difficulty is used for the proof of work check.
> In
> > addition to adjusting the hashcash target, selecting a different
> difficulty
> > also raises or lowers the maximum block size for that block by a function
> > of the difference in difficulty. So increasing the difficulty of the
> block
> > by an additional 25% raises the block limit for that block from 100% of
> the
> > current limit to 125%, and lowering the difficulty by 10% would also
> lower
> > the maximum block size for that block from 100% to 90% of the current
> > limit. For simplicity I will assume a linear identity transform as the
> > function, but a quadratic or other function with compounding marginal
> cost
> > may be preferred.
> >
>
> Sorry but I fail to see how a linear identity transform between block
> size and difficulty would work.
>
> The miner's reward for finding a block is the sum of subsidy and fees:
>
>  R = S + F
>
> The probability that the miner will find a block over a time interval is
> inversely proportional to the difficulty D:
>
>  P = K / D
>
> where K is a constant that depends on the miner's hashrate. The expected
> reward of the miner is:
>
>  E = P * R
>
> Consider that the miner chooses a new difficulty:
>
>  D' = D(1 + x).
>
> With a linear identity transform between block size and difficulty, the
> miner will be allowed to collect fees from a block of size: S'=S(1+x)
>
> In the best case, collected will be proportional to block size:
>
>  F' = F(1+x)
>
> Thus we get:
>
>  E' = P' * R' = K/(D(1+x)) * (S + F(1+x))
>
>  E' = E - x/(1+x) * S * K / D
>
> So with this linear identity transform, increasing block size never
> increases the miners gain. As long as the subsidy exists, the best
> strategy for miners is to reduce block size (i.e. to choose x<0).
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mark Friedenbach]

Micropayment channels are not pie in the sky proposals. They work today on
Bitcoin as it is deployed without any changes. People just need to start
using them.
On May 10, 2015 11:03, "Owen Gunden"  wrote:

> On 05/08/2015 11:36 PM, Gregory Maxwell wrote:
> > Another related point which has been tendered before but seems to have
> > been ignored is that changing how the size limit is computed can help
> > better align incentives and thus reduce risk.  E.g. a major cost to the
> > network is the UTXO impact of transactions, but since the limit is blind
> > to UTXO impact a miner would gain less income if substantially factoring
> > UTXO impact into its fee calculations; and without fee impact users have
> > little reason to optimize their UTXO behavior.
>
> Along the lines of aligning incentives with a diversity of costs to a
> variety of network participants, I am curious about reactions to Justus'
> general approach:
>
>
> http://bitcoinism.liberty.me/2015/02/09/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/
>
> I realize it relies on pie-in-the-sky ideas like micropayment channels,
> but I wonder if it's a worthy long-term ideal direction for this stuff.
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mark Friedenbach]

In a fee-dominated future, replace-by-fee is not an opt-in feature. When
you create a transaction, the wallet presents a range of fees that it
expects you might pay. It then signs copies of the transaction with spaced
fees from this interval and broadcasts the lowest fee first. In the user
interface, the transaction is shown with its transacted amount and the
approved fee range. All of the inputs used are placed on hold until the
transaction gets a confirmation. As time goes by and it looks like the
transaction is not getting accepted, successively higher fee versions are
released. You can opt-out and send a no-fee or base-fee-only transaction,
but that should not be the default.

On the receiving end, local policy controls how much fee should be spent
trying to obtain confirmations before alerting the user, if there are fees
available in the hot wallet to do this. The receiving wallet then adds its
own fees via a spend if it thinks insufficient fees were provided to get a
confirmation. Again, this should all be automated so long as there is a hot
wallet on the receiving end.

Is this more complicated than now, where blocks are not full and clients
generally don't have to worry about their transactions eventually
confirming? Yes, it is significantly more complicated. But such
complication is unavoidable. It is a simple fact that the block size cannot
increase so much as to cover every single use by every single person in the
world, so there is no getting around the reality that we will have to
transition into an economy where at least one side has to pay up for a
transaction to get confirmation, at all. We are going to have to deal with
this issue whether it is now at 1MB or later at 20MB. And frankly, it'll be
much easier to do now.

On Fri, May 8, 2015 at 4:15 PM, Aaron Voisine  wrote:

> That's fair, and we've implemented child-pays-for-parent for spending
> unconfirmed inputs in breadwallet. But what should the behavior be when
> those options aren't understood/implemented/used?
>
> My argument is that the less risky, more conservative default fallback
> behavior should be either non-propagation or delayed confirmation, which is
> generally what we have now, until we hit the block size limit. We still
> have lots of safe, non-controversial, easy to experiment with options to
> add fee pressure, causing users to economize on block space without
> resorting to dropping transactions after a prolonged delay.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach 
> wrote:
>
>> On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine  wrote:
>>
>>> This is a clever way to tie block size to fees.
>>>
>>> I would just like to point out though that it still fundamentally is
>>> using hard block size limits to enforce scarcity. Transactions with below
>>> market fees will hang in limbo for days and fail, instead of failing
>>> immediately by not propagating, or seeing degraded, long confirmation times
>>> followed by eventual success.
>>>
>>
>> There are already solutions to this which are waiting to be deployed as
>> default policy to bitcoind, and need to be implemented in other clients:
>> replace-by-fee and child-pays-for-parent.
>>
>
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mark Friedenbach]

On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine  wrote:

> This is a clever way to tie block size to fees.
>
> I would just like to point out though that it still fundamentally is using
> hard block size limits to enforce scarcity. Transactions with below market
> fees will hang in limbo for days and fail, instead of failing immediately
> by not propagating, or seeing degraded, long confirmation times followed by
> eventual success.
>

There are already solutions to this which are waiting to be deployed as
default policy to bitcoind, and need to be implemented in other clients:
replace-by-fee and child-pays-for-parent.
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase

[Mark Friedenbach]

Transactions don't expire. But if the wallet is online, it can periodically
choose to release an already created transaction with a higher fee. This
requires replace-by-fee to be sufficiently deployed, however.

On Fri, May 8, 2015 at 1:38 PM, Raystonn .  wrote:

> I have a proposal for wallets such as yours.  How about creating all
> transactions with an expiration time starting with a low fee, then
> replacing with new transactions that have a higher fee as time passes.
> Users can pick the fee curve they desire based on the transaction priority
> they want to advertise to the network.  Users set the priority in the
> wallet, and the wallet software translates it to a specific fee curve used
> in the series of expiring transactions.  In this manner, transactions are
> never left hanging for days, and probably not even for hours.
>
> -Raystonn
>  On 8 May 2015 1:17 pm, Aaron Voisine  wrote:
>
> As the author of a popular SPV wallet, I wanted to weigh in, in support of
> the Gavin's 20Mb block proposal.
>
> The best argument I've heard against raising the limit is that we need fee
> pressure.  I agree that fee pressure is the right way to economize on
> scarce resources. Placing hard limits on block size however is an
> incredibly disruptive way to go about this, and will severely negatively
> impact users' experience.
>
> When users pay too low a fee, they should:
>
> 1) See immediate failure as they do now with fees that fail to propagate.
>
> 2) If the fee lower than it should be but not terminal, they should see
> degraded performance, long delays in confirmation, but eventual success.
> This will encourage them to pay higher fees in future.
>
> The worst of all worlds would be to have transactions propagate, hang in
> limbo for days, and then fail. This is the most important scenario to
> avoid. Increasing the 1Mb block size limit I think is the simplest way to
> avoid this least desirable scenario for the immediate future.
>
> We can play around with improved transaction selection for blocks and
> encourage miners to adopt it to discourage low fees and create fee
> pressure. These could involve hybrid priority/fee selection so low fee
> transactions see degraded performance instead of failure. This would be the
> conservative low risk approach.
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
>
>
> --
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Block Size Increase

[Mark Friedenbach]

The problems with that are larger than time being unreliable. It is no
longer reorg-safe as transactions can expire in the course of a reorg and
any transaction built on the now expired transaction is invalidated.

On Fri, May 8, 2015 at 1:51 PM, Raystonn  wrote:

> Replace by fee is what I was referencing.  End-users interpret the old
> transaction as expired.  Hence the nomenclature.  An alternative is a new
> feature that operates in the reverse of time lock, expiring a transaction
> after a specific time.  But time is a bit unreliable in the blockchain
>
--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Mark Friedenbach]

It is my professional opinion that raising the block size by merely
adjusting a constant without any sort of feedback mechanism would be a
dangerous and foolhardy thing to do. We are custodians of a multi-billion
dollar asset, and it falls upon us to weigh the consequences of our own
actions against the combined value of the entire bitcoin ecosystem. Ideally
we would take no action for which we are not absolutely certain of the
ramifications, with the information that can be made available to us. But
of course that is not always possible: there are unknown-unknowns, time
pressures, and known-unknowns where information has too high a marginal
cost. So where certainty is unobtainable, we must instead hedge against
unwanted outcomes.

The proposal to raise the block size now by redefining a constant carries
with it risk associated with infrastructure scaling, centralization
pressures, and delaying the necessary development of a constraint-based fee
economy. It also simply kicks the can down the road in settling these
issues because a larger but realistic hard limit must still exist, meaning
a future hard fork may still be required.

But whatever new hard limit is chosen, there is also a real possibility
that it may be too high. The standard response is that it is a soft-fork
change to impose a lower block size limit, which miners could do with a
minimal amount of coordination. This is however undermined by the
unfortunate reality that so many mining operations are absentee-run
businesses, or run by individuals without a strong background in bitcoin
protocol policy, or with interests which are not well aligned with other
users or holders of bitcoin. We cannot rely on miners being vigilant about
issues that develop, as they develop, or able to respond in the appropriate
fashion that someone with full domain knowledge and an objective
perspective would.

The alternative then is to have some sort of dynamic block size limit
controller, and ideally one which applies a cost to raising the block size
in some way the preserves the decentralization and/or long-term stability
features that we care about. I will now describe one such proposal:

  * For each block, the miner is allowed to select a different difficulty
(nBits) within a certain range, e.g. +/- 25% of the expected difficulty,
and this miner-selected difficulty is used for the proof of work check. In
addition to adjusting the hashcash target, selecting a different difficulty
also raises or lowers the maximum block size for that block by a function
of the difference in difficulty. So increasing the difficulty of the block
by an additional 25% raises the block limit for that block from 100% of the
current limit to 125%, and lowering the difficulty by 10% would also lower
the maximum block size for that block from 100% to 90% of the current
limit. For simplicity I will assume a linear identity transform as the
function, but a quadratic or other function with compounding marginal cost
may be preferred.

  * The default maximum block size limit is then adjusted at regular
intervals. For simplicity I will assume an adjustment at the end of each
2016 block interval, at the same time that difficulty is adjusted, but
there is no reason these have to be aligned. The adjustment algorithm
itself is either the selection of the median, or perhaps some sort of
weighted average that respects the "middle majority." There would of course
be limits on how quickly the block size limit can adjusted in any one
period, just as there are min/max limits on the difficulty adjustment.

  * To prevent perverse mining incentives, the original difficulty without
adjustment is used in the aggregate work calculations for selecting the
most-work chain, and the allowable miner-selected adjustment to difficulty
would have to be tightly constrained.

These rules create an incentive environment where raising the block size
has a real cost associated with it: a more difficult hashcash target for
the same subsidy reward. For rational miners that cost must be
counter-balanced by additional fees provided in the larger block. This
allows block size to increase, but only within the confines of a
self-supporting fee economy.

When the subsidy goes away or is reduced to an insignificant fraction of
the block reward, this incentive structure goes away. Hopefully at that
time we would have sufficient information to soft-fork set a hard block
size maximum. But in the mean time, the block size limit controller
constrains the maximum allowed block size to be within a range supported by
fees on the network, providing an emergency relief valve that we can be
assured will only be used at significant cost.

Mark Friedenbach

* There has over time been various discussions on the bitcointalk forums
about dynamically adjusting block size limits. The true origin of the idea
is unclear at this time (citations would be appreciated!) but a form of it
was implemented in Bytecoin / Monero using subsidy 

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

[Mark Friedenbach]

At this moment anyone can alter the txid. Assume transactions are 100%
malleable.
On Apr 16, 2015 9:13 AM, "s7r"  wrote:

> Hi Pieter,
>
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
>
> The problem I am trying to solve is making all transactions
> non-malleable by default. I guess there is a very good reason why BIP62
> will not touch v1 anyway.
>
> I am trying to build a bitcoin contract which will relay on 3 things:
> - coinjoin / txes with inputs from multiple users which are signed by
> all users after they are merged together (every user is sure his coins
> will not be spent without the other users to spend anything, as per
> agreed contract);
> - pre-signed txes with nLockTime 'n' weeks. These txes will be signed
> before the inputs being spent are broadcasted/confirmed, using the txid
> provided by the user before broadcasting it. Malleability hurts here.
> - P2SH
>
> In simple terms, how malleable transactions really are in the network at
> this moment? Who can alter a txid without invalidating the tx? Just the
> parties who sign it? The miners? Anyone in the network? This is a little
> bit unclear to me.
>
> Another thing I would like to confirm, the 3 pieces of the bitcoin
> protocol mentioned above will be supported in _any_ future transaction
> version or block version, regardless what changes are made or features
> added to bitcoin core? The contract needs to be built and left unchanged
> for a very very long period of time...
>
>
> On 4/16/2015 8:22 AM, Pieter Wuille wrote:
> >
> > On Apr 16, 2015 1:46 AM, "s7r" mailto:s...@sky-ip.org>>
> > wrote:
> >> but for transaction versions? In simple terms, if > 75% from all the
> >> transactions in the latest 1000 blocks are version 'n', mark all
> >> previous transaction versions as non-standard and if > 95% from all the
> >> transactions in the latest 1000 blocks are version 'n' mark all previous
> >> transaction versions as invalid.
> >
> > What problem are you trying to solve?
> >
> > The reason why BIP62 (as specified, it is just a draft) does not make v1
> > transactions invalid is because it is opt-in. The creator of a
> > transaction needs to agree to protect it from malleability, and this
> > subjects him to extra rules in the creation.
> >
> > Forcing v3 transactions would require every piece of wallet software to
> > be changed.
> >
> > --
> > Pieter
> >
>
>
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

[Mark Friedenbach]

Thank you Jorge for the contribution of the Stag Hunt terminology. It is
much better than a politically charged "scorched earth".
On Feb 21, 2015 11:10 AM, "Jorge Timón"  wrote:

> I agree "scorched hearth" is a really bad name for the 0 conf protocol
> based on game theory. I would have preferred "stag hunt" since that's
> basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt)
> but I like the protocol and I think it would be interesting to
> integrate it in the  payment protocol.
> Even if that protocol didn't existed or didn't worked, replace-by-fee
> is purely part of a node's policy, not part of consensus.
> >From the whitepaper, 0 conf transactions being secure by the good will
> of miners was never an assumption, and it is clear to me that the
> system cannot provide those guaranties based on such a weak scheme. I
> believe thinking otherwise is naive.
> As to consider non-standard policies "an attack to bitcoin" because
> "that's not how bitcoin used to work", then I guess minimum relay fee
> policies can also be considered "an attack to bitcoin" on the same
> grounds.
> Lastly, "first-seen-wins" was just a simple policy to bootstrap the
> system, but I expect that most nodes will eventually move to policies
> that are economically rational for miners such as replace-by-fee.
> Not only I disagree this will be "the end of bitcoin" or "will push
> the price of the btc miners are mining down", I believe it will be
> something good for bitcoin.
> Since this is apparently controversial I don't want to push for
> replace-by-fee to become the new standard policy (something that would
> make sense to me). But once the policy code is sufficiently modular as
> to support several policies I would like bitcoin core to have a
> CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no
> policy checks at all).
> One step at a time I guess...
>
>
> On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes  wrote:
> > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote:
> >>
> >>
> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
> >> >
> >> > Most money/payment systems include some method to reverse or undo
> >> > payments made in error. In these systems, the longer settlement
> >> > times you mention below are a feature, not a bug, and give more
> >> > time for a human to react to errors and system failures.
> >> >
> >>
> >> Settlement has to be final somewhere. That is the whole point of it.
> >> Transfer costs in current electronic payment systems are a direct
> >> consequence of their non-finality. That's the point Satoshi was making
> >> in the introduction to the whitepaper: "With the possibility of
> >> reversal, the need for trust spreads".
> >
> > The problem with that statement is I trust a merchant that I went into
> > a store and made a payment with personally more than I trust the firmware
> > on my hard drive [1].
> >
> > The attack surface of devices in your computer is huge. A motivated
> attacker
> > just needs to get an intern into a company that makes some kind of
> component
> > or system that's in your computer, cloud server, hardware wallet, or what
> > have you that has firmware capable of reading your private keys.
> >
> > With the possibility of mass trojaned hardware, if we are going to trust
> > the system, it must somehow allow reversal through a human-in-the-loop.
> >
> >> There is nothing wrong with having reversible mechanisms built on top
> >> of Bitcoin, and indeed it makes sense for most activity to happen at
> >> those higher layers. It's easy to build things that way, but
> >> impossible to build them the other way: you can't build a
> >> non-reversible layer on top of a reversible layer.
> >
> > We built 'reliable' TCP on top of unreliable ethernet networks. My
> experience
> > with networking was if you tried to guarantee message delivery at the
> lowest
> > level, the system got exceedingly complicated, expensive, and brittle.
> >
> > Most applications, in particular paying someone you already trust, are
> quite
> > happy running on reversible systems, and in some cases more reliable and
> > lower risk. (carrying non-reversible cash is generally considered risky)
> >
> > The problem is that if the base currency is assumed to be non-reversible,
> > then it's brittle and becomes 'too big to fail'.
> >
> > Where the blockchain improves on everything else is in transparency. If
> you
> > reverse transactions a lot, it will be obvious from an analysis. I would
> much
> > rather deal with a known, predictable, and relatively continous
> transaction
> > reversal rate (percentage) than have to deal with sudden failures where
> > some anonymous bad actor makes off with a fortune.
> >
> > We already have zero-conf double-spend transaction reversal, why not
> explicitly
> > extend that a little in a way that senders and receivers have a choice to
> > use it, or not?
> >
> >
> > [1]
> http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV2

Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties

[Mark Friedenbach]

There should not be a requirement at this level to ensure validity. That
would too constrain use cases of implementations of your protocol. It is
not difficult to imagine use cases where parties generate chained
transactions on top of unconfimed transactions. Although malleability
currently makes this difficult to do safely in general, it is not
inconceivable that there are circumstances where it would nevertheless be
safe or otherwise desireable.

It is a good security recommendation that clients validate the inputs to a
shuffle they are participating in. What this means depends on the client --
checking the UTXO set for a full node, making some getutxos queries for a
SPV client. But this should remain a recommendation, not a requirement.


On Mon, Aug 11, 2014 at 4:38 AM, Tim Ruffing <
tim.ruff...@mmci.uni-saarland.de> wrote:

> Hmm, you are right. Lightweight clients are an interesting point, we have
> to
> think about a policy for them.
>
> As you said, the worst case is that the tx will not confirm. So the only
> possible attack is DoS. For clients that rely on servers it's reasonable to
> trust their servers not to perform DoS. (Anyway, the servers could do worse
> attacks.)
>
> For SPV-clients (without servers), I'm not sure at the moment. Something
> like
> getUTXO seems to be a possibility. I think even SPV-clients can verify the
> validity of the tx that created the input that is designated for mixing.
> Then
> the only remaining reason why it could be invalid is that the input could
> have
> been spent already otherwise. But in this case, only one honest client with
> full information would suffice: a signed transaction that spends the money
> would convince even SPV-clients that the participant with this inputs
> tries to
> cheat. This transaction could even be provided by lightweight client that
> got
> if from a server; the transaction is signed by the cheating participant
> anyway.
>
> Tim
>
> On Monday 11 August 2014 02:30:16 Chris Pacia wrote:
> > Actually getUTXO would probably work here as well. It isn't authenticated
> > but it should be good enough for this purpose. The worst that would
> happen
> > is the tx doesn't confirm.
> >
> > On Aug 11, 2014 2:25 AM, "Chris Pacia"  wrote:
> > > One issue I do see is the protocol requires participants to check the
> > > inputs submitted by others are valid. Lite clients (at least of the p2p
> > > variety) cannot perform this check.
> > >
> > > You could skip the verification part and if the inputs turn out to be
> > > invalid then you'll find out when it doesn't confirm. This would
> problem
> > > open the protocol up to dos attacks and prevent part of the "blame"
> phase
> > > from working properly.
> > >
> > > Alternatively you can have the participants submit the merkle proof for
> > > the input. This would require inputs to have at least one confirmation,
> > > however.
>
>
> --
>
> ___
> 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] CoinShuffle: decentralized CoinJoin without trusted third parties

[Mark Friedenbach]

On Sat, Aug 9, 2014 at 6:10 AM, Sergio Lerner 
wrote:

>  Hi Tim,
>  It's clear from the paper that the second party in the protocol can
> de-anonymize the first party. So it's seems that dishonest shufflers would
> prefer to be in that position in the queue.
>

That's not clear to me. The 2nd party doesn't know how the 3rd, 4th, 5th,
etc. parties shuffled the outputs, since it doesn't have their decryption
keys.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Mark Friedenbach]

On 08/06/2014 01:20 PM, Peter Todd wrote:
> The general case doesn't require transmission of any merkle data; it
> is derived from the tx data.

How can that possibly be the case? The information is hidden behind the
Merkle root in the transaction. The validator needs to know whether
there is an expiry and what it is. What's it supposed to do, guess?

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Mark Friedenbach]

On 08/06/2014 01:02 PM, Tom Harding wrote:
> With first-eligible-height and last-eligible-height, creator could
> choose a lifetime shorter than the max,  and in addition, lock the whole
> thing until some point in the future.

Note that this would be a massive, *massive* change that would
completely break bitcoin output frangibility. Merchants would have to
start demanding input history back to a certain depth in order to ensure
they are not exposing themselves to undue reorg-expiry risk.

There are useful applications of a consensus-enforced expiry,
particularly within a private (signed block) side chain, and for that
reason it is useful to have a discussion about the merits of an nExpiry
field or BLOCK_HEIGHT / BLOCK_TIME opcode, and methods for achieving
either. However I don't see this ever becoming part of the public
bitcoin network.

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] deterministic transaction expiration

[Mark Friedenbach]

On 08/06/2014 11:42 AM, Peter Todd wrote:
> On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
>  wrote:
>> +1 for the new field, overloading fields with new meaning is
>> definitely not a good idea.
> 
> To add a new field the best way to do it is create a new, parallel,
> tx format where fields are committed by merkle radix tree in an
> extensible and provable way. You'd then commit to that tree with a
> mandatory OP_RETURN output in the last txout, or with a new merkle
> root.
> 
> Changing the tx format itself in a hard-fork is needlessly
> disruptive, and in this case, wastes opportunities for improvement.

I highly doubt that is the best approach.

If this nExpiry field is a consensus rule, then the Merkle tree or the
appropriate paths through needs to be included with the transaction as
part of the network and on-disk data structures, so that proper
validation can be done. This would be both more disruptive and less
efficient than simply adding an nExpiry field to the transaction format,
as we do in Freimarkets.

If the field is pre-consensus (a mempool gentleman's agreement), then it
has no business in the transaction structure at all and should be
packaged in some sort of envelope container.

--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Mining Hashrate Caps

[Mark Friedenbach]

Can someone explain to these guys and the public why promising to limit
yourselves to *only* a 50% chance of successfully double-spending a 6
confirm transaction is still not acceptable?

q=0.4
z=0 P=1
z=1 P=0.828861
z=2 P=0.736403
z=3 P=0.664168
z=4 P=0.603401
z=5 P=0.550625
z=6 P=0.50398
z=7 P=0.462301
z=8 P=0.424782
z=9 P=0.390828
z=10P=0.359976
z=11P=0.331858
z=12P=0.306167
z=13P=0.282649
z=14P=0.261083
z=15P=0.24128
z=16P=0.223076
z=17P=0.206324
z=18P=0.190896
z=19P=0.176676


On 07/17/2014 06:59 AM, Melvin Carvalho wrote:
> I noticed this article today. 
> 
> GHash Commits to 40% Hashrate Cap at Bitcoin Mining Summit
> 
> http://www.coindesk.com/ghash-commits-40-hashrate-cap-bitcoin-mining-summit/
> 
> Here's a quote from Satoshi when the mining arms race began:
> 
> "We should have a gentleman’s agreement to postpone the GPU arms race as
> long as we can for the good of the network. It’s much easer to get new
> users up to speed if they don’t have to worry about GPU drivers and
> compatibility. It’s nice how anyone with just a CPU can compete fairly
> equally right now."
> 
> Maybe outdated now, but I thought it was interesting.
> 
> 
> --
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:

[Mark Friedenbach]

It's not the pool operator's business what software the miner is running
to select transactions for his block, so long as the miner follows the
template and doesn't generate invalid blocks. We already discussed
invalid blocks, and checking the template requires parsing the coinbase
transaction and verifying the merkleroot. The most expensive operations
are the hashes in the merkleroot verification, but you have to do that
in stratum too because of the extranonce, right?

On 06/19/2014 01:55 PM, slush wrote:
> Miner issues are just one thing what came to my mind. What about
> validating transactions? How the pool can be sure that miner is running
> up to date bitcoind which do full validation of transactions? Not
> talking that if every miner takes his own set of transaction, pool need
> to calculate merkle root for every submit, to check its correctness.

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:

[Mark Friedenbach]

Do you need to do full validation? There's an economic cost to mining
invalid blocks, and even if that were acceptable there's really no
reason to perform such an attack. The result would be similar to a block
withholding attack, but unlike block withholding it would be trivially
detectable if/when full validation was performed.

To protect yourself and to detect incorrect mining software you could
stochastically validate a randomly selected sample of shares, as your
hardware requirements allow.

On 06/19/2014 01:26 PM, slush wrote:
> With GBT, simply hashing the block header is not enough, because pool
> cannot rely on anything provided by the client. Its not only about
> things like withdrawal attacks, but more about hidden bugs in various
> miners. It is extremely hard to do full validation for *every* of
> submitted shares.

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:

[Mark Friedenbach]

Sergio, why is preventing mining pools a good thing? The issue is not
mining pools, which provide a needed service in greatly reducing
variance beyond what any proposal like this can do.

The issue is centralized transaction selection policies, which is
entirely orthogonal. And the solution already exists: getblocktemplate.
We just need more or better infrastructure which makes use of this
technology to perform local transaction selection.

If you have a proposal for eliminating hosted mining while keeping
variance-reducing pools, that would be an interesting read.

On 06/19/2014 09:58 AM, Sergio Lerner wrote:
> I propose a setting that prevent mining pools AND reduce payoff variance
> which requires two changes: increasing the block-rate and changing the
> Bitcoin PoW (but still allowing current Bitcoin ASICs to work (as far as
> I know)). The block rate must be increased at least 20 times and block
> must still be near full (e.g. there must be at least 20 more
> transactions/second than there is today)
> 
> BlockPow is kind of PoW that only practically prevents mining pools for
> certain cryptocurrency settings based on concepts similar to parmacoin,
> but in a much simple degree. The idea is that if miners try to join a
> pool, then they incur in overhead of transmitting information and earn
> less than working solo. Let b (the payload) contain a full block. b must
> contain all the transactions and the header, and not only the
> transaction hashes. b should not hide anything. Let h be the block
> header (which contains the previous block hash and the Merkle tree root
> of the transactions). Let d be the difficulty. hash-block-length(b)
> returns the number of blocks processed by the hash function when fed
> with the block b. The target is divided by hash-block-length(b) so that
> the difficulty does not depend on the length of the block. Some other
> function can be used to encourage nodes to add more or less transactions.
> 
> Def: Basic BlockPoW concept
> 
> For each r in the nonce-range: if H ( H( r || b ) || h || r) ) < 2^-d/
> hash-block-length(b) then return r
> 
> return null
> 
> The header (h) is appended to the hashed message to allow SPV clients to
> verify the PoW without requiring the full block to be downloaded. Peers
> can send only (x,r,h) to SPV nodes, where x = H( r || b ), so they can
> verify the PoW. The verification procedure is obvious, and is skipped
> here. r is inserted at the beginning of the message to prevent pool
> administrators from keeping a secret mid-state of the hash function
> secret in order to prevent block stealing and also to force the miner to
> know b in the inner mining loop.
> 
> So now mining requires the knowledge of the block b to be mined, and b
> must be received at each block-chain epoch. This could create an
> incentive not to include any transaction and use an almost empty b,
> because that way the bandwidth requirements is decreased. But this
> incentive should not exists normally, since by including transactions
> the solo miner gets an additional revenue from fees, which is lost if
> the block is empty. Anyway, to prevent this possible incentive we can
> append to b a subset of previous blocks (e.g 100 blocks). The block
> subset to include could be derived from a peudo-random function seeded
> by the previous block hash. Then a node would still need to download
> part or all the block-chain in order to mine.
> 
> Now if the miner wants to be a dumb node and take part of a pool, then
> the current working unsolved block (the template) must be sent each time
> from the pool admin to each miner. If the pool admin hosts 1000 miners,
> then to serve them with fresh block templates he needs 1000 times more
> bandwidth that the miners, making this much more expensive. If miners
> create another network topology to distribute templates, they are
> incurring in the same overhead as being actively part of the
> cryptocurrency network, so they gain nothing.
> 
> For example, in a block-chain with a 5 seconds block-rate, such as in
> NimbleCoin , each block can be as large as 200
> Kbytes (100 tps are allowed). A miner will require the block template to
> be ready as fast as possible, say before 3 seconds, so as not to loose
> more than 60% of the times the transaction fees present in the block
> template. This means that a pool admin serving 1000 clients must have a
> upload bandwidth of at least 60 Mbytes/sec, and load balance servers,
> because all miners will demand the block template at the same time and
> will compete for it.
> 
> The same miner, working solo, will not loose the 60% of block fees. If
> block fees are 10% of block reward, then solo miners earn 6% more than
> pool miners. Also, having a block rate of 5 seconds allows solo miners
> to receive payments more often and so it reduces the payment variance.
> 
> This method to discourage mining pools only work as long as time is
> takes to transmit a block is comparable t

Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees

[Mark Friedenbach]

Not with current script, but there are mechanisms by which you can do a
digital signature where signing two pieces of information reveals the
ECDSA k parameter, thereby allowing anyone to recover the private key
and steal the coins.

Practically speaking, these are not very safe systems to use. For
example, imagine accidentally loading up the same wallet on two machines
or the wallet software crashing after signing and sending the
transaction, and the user recreates & sends on recovery.

It also invalidates reasonably legitimate use cases for repeating
addresses (in the absence of other solutions), and its not really
possible to prevent people from sending multiple coins to the same
address (which could then be stolen).

On 06/17/2014 01:40 PM, Goss, Brian C., M.D. wrote:
> Can two signed transactions using the same output as an input (ie, a
> double spend) be used to trigger a third transaction?
> 
> It would be nice if I could sign a tx that would pay m bitcoins to an
> arbitrary address if and only if someone could present proof that I
> signed more than 1 transaction using the same output. Thus, a
> merchant could trust that I would not attempt a double spend for a
> purchase of n < m bitcoins.
> 
> Can this type of transaction be expressed in Bitcoin's scripting
> language?
> 
> Chaum had a similar feature in Digicash way back when...a double
> spend would let the second merchant compute the identity of the
> double spender and serve as proof of double spending. It didn't
> automate punishment though!
> 
> My apologies if this has been discussed previously.
> 

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Going to tag 0.9.2 final

[Mark Friedenbach]

Not when failure is defined as, e.g., extra text pushing a UI element
down such that the button the user needs to click is no longer visible.
You don't test that except by having a human being run through some
example workflows, which is presumably happening during the release process.

On 06/13/2014 10:58 PM, Un Ix wrote:
> Was joking, but isn't the translation process back-ended with runtime
> tests to ensure that any stray chars etc cause the application to
> fail?
> 
>> On 14/06/2014, at 1:49 pm, "Matt Whitlock" 
>> wrote:
>> 
>>> On Saturday, 14 June 2014, at 1:42 pm, Un Ix wrote: How about a
>>> prize for anyone who can spot any "malicious" strings within next
>>> hour?
>> 
>> I think it's more an issue of accidental breakage than any
>> maliciousness. One character in the wrong place in a language
>> bundle somewhere can make the difference between success and
>> runtime failure, and it may not be immediately apparent when
>> running in unaffected locales. This kind of problem isn't likely to
>> result in data loss (or money loss, where money is data, is in
>> Bitcoin), but it could be enough to necessitate scrapping the whole
>> release, which would look bad and prompt users to question the dev
>> team's quality control process.
> 

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Future Feature Proposal - getgist

[Mark Friedenbach]

The correct approach here is header hash-tree commitments which enable
compact (logarithmic) SPV proofs that elide nearly all intervening
headers since the last checkpoint. You could then query the hash tree
for references to any of the headers you actually need.

See this message for details:

http://sourceforge.net/p/bitcoin/mailman/message/32111357/

On 06/04/2014 12:30 PM, Richard Moore wrote:
> Bitcoin development team,
> 
> I recently started implementing my own Python full-node, and had an
> idea, so I’m prowling through BIP 001 for this proposal, which says to
> e-mail you kind folks to make sure the idea is original (enough) and
> that there aren’t other existing means to accomplish what I was thinking. :)
> 
> The only way to grab all the headers seems to be to serially get one,
> then the next and so on, as you need the last hash of a headers() call
> to the next getheaders(). But we are on a peer-to-peer network,
> potentially able to getheaders() from many peers simultaneously, if we
> only knew the hash to look for.
> 
> What I was thinking is something to the effect of a getgist() command,
> fully backward compatible (any node not understanding it, can silently
> ignore it… Otherwise version or services could be used to announce the
> capability, but that seems like a little overkill). The inputs to
> getgist() would be similar to getheaders(); version, hash_count,
> block_locator_hash, stop_hash and an additional field, segment_count.
> The response would be a normal headers() message, except, not sequential
> block headers… Rather they would be spaced out, preferably
> 2000-block-hash-aligned from the first block hash. So, for example, if
> you have a blockchain with 198,005 blocks, and you passed it the block
> locator of height 0 (the genesis block), and a segment_count of 25, you
> would expect (approximately, the actual algorithm needs to be figured
> out), the block hashes at the following 25 (segment_count) heights:
> 
> 1, 8000, 16000, 24000, 32000, 4, 48000, 56000, 64000, 72000, 8,
> 88000, 96000, 104000, 112000, 12, 128000, 136000, 144000, 152000,
> 16, 168000, 176000, 184000, 192000
> 
> Which can now be spread across 25 different nodes, fetching the block
> headers (albeit, out of order, possibly increasing the complexity of the
> local block chain database) but vastly increasing the speed the whole
> blockchain can have all headers synced.
> 
> I still need to perform some tests to see what type of speed gains there
> are, but I would suspect it should be segment_count times faster.
> 
> Existing methods could be to use checkpoint-ish nodes or bootstrap data
> files, but these begin relying on semi-cetralizenesses.
> 
> Ideas? Suggestions? Concerns? Prior it-ain’t-gonna-works?
> 
> Thanks!
> 
> RicMoo
> 
> 
> .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º>
> 
> Richard Moore ~ Founder
> Genetic Mistakes Software inc.
> phone: (778) 882-6125
> email: ric...@geneticmistakes.com 
> www: http://GeneticMistakes.com 
> 
> 
> 
> --
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their 
> applications. Written by three acclaimed leaders in the field, 
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] bitcoind minor bug in wallet and possible fix

[Mark Friedenbach]

Please make a pull request on github. It'll likely get merged quickly.
On May 29, 2014 5:04 PM, "Toshi Morita"  wrote:

> I ran bitcoind under valgrind and found a place where it references an
> uninitialized variable in some cases:
>
> tm@tm-VirtualBox:~/bitcoind/bitcoin/src$ valgrind ./bitcoind
> ==2337== Memcheck, a memory error detector
> ==2337== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
> ==2337== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
> ==2337== Command: ./bitcoind
> ==2337==
> ==2337== Conditional jump or move depends on uninitialised value(s)
> ==2337==at 0x319176: CWallet::LoadKeyMetadata(CPubKey const&,
> CKeyMetadata const&) (wallet.cpp:110)
> ==2337==by 0x33645A: ReadKeyValue(CWallet*, CDataStream&,
> CDataStream&, CWalletScanState&, std::string&, std::string&)
> (walletdb.cpp:509)
> ==2337==by 0x3374F0: CWalletDB::LoadWallet(CWallet*) (walletdb.cpp:623)
> ==2337==by 0x3218FD: CWallet::LoadWallet(bool&) (wallet.cpp:1485)
> ==2337==by 0x157F16: AppInit2(boost::thread_group&) (init.cpp:958)
> ==2337==by 0x140142: AppInit(int, char**) (bitcoind.cpp:143)
> ==2337==by 0x13649E: main (bitcoind.cpp:180)
> ==2337==
>
> The bug occurs here because nTimeFirstKey is not initialized when the
> wallet is instantiated:
>
> wallet.cpp:63
> if (!nTimeFirstKey || nCreationTime < nTimeFirstKey)
> nTimeFirstKey = nCreationTime;
>
>
> I fixed it in my fork:
>
> diff --git a/src/wallet.h b/src/wallet.h
> index 9607415..b78045f 100644
> --- a/src/wallet.h
> +++ b/src/wallet.h
> @@ -163,6 +163,7 @@ public:
>  nOrderPosNext = 0;
>  nNextResend = 0;
>  nLastResend = 0;
> +nTimeFirstKey = 0;
>  }
>
> If this fix is ok please pull from my GitHub fork; username on GitHub is
> tm314159.
>
> Toshi
>
>
>
> --
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Time is money. Stop wasting it! Get your web API in 5 minutes.
www.restlet.com/download
http://p.sf.net/sfu/restlet___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] PSA: Please sign your git commits

[Mark Friedenbach]

I know the likelihood of this happening is slim, but if these are the
desired features we should consider switching to monotone (monotone.ca)
which has a much more flexible DAG structure and workflow built around
programmable multi-sig signing of commits. We could still maintain the
github account as a two-way repository interface, but acceptance of a
pull request would require some threshold signature sign-off in monotone.

I would seriously suggest anybody on this list exploring monotone if you
haven't already, at least for your personal projects if it is too late
to make that choice for bitcoin. Besides the benefits of using it, we
should be supporting build infrastructure that enables less trusted,
less centralized development.

http://www.monotone.ca/

Mark

On 05/23/2014 12:12 AM, Wladimir wrote:
> On Thu, May 22, 2014 at 8:06 PM, Jeff Garzik  wrote:
>> Related:  Current multi-sig wallet technology being rolled out now,
>> with 2FA and other fancy doodads, is now arguably more secure than my
>> PGP keyring.  My PGP keyring is, to draw an analogy, a non-multisig
>> wallet (set of keys), with all the associated theft/data
>> destruction/backup risks.
>>
>> The more improvements I see in bitcoin wallets, the more antiquated my
>> PGP keyring appears.  Zero concept of multisig.  The PGP keyring
>> compromise process is rarely exercised.  2FA is lacking.  At least
>> offline signing works well. Mostly.
> 
> Would be incredible to have multisig for git commits as well. I don't
> think git supports multiple signers for one commit at this point -
> amending the signature replaces the last one - but it would allow for
> some interesting multi-factor designs in which the damage when a dev's
> computer is compromised would be reduced.
> 
> Sounds like a lot of work to get a good workflow there, though.
> 
> My mail about single-signing commits was already longer than I
> expected when I started writing there. Even though the process is
> really simple.
> 
> Though if anyone's interest is piqued by this, please pick it up.
> 
> Wladimir
> 

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] PSA: Please sign your git commits

[Mark Friedenbach]

On 05/21/2014 10:10 AM, Wladimir wrote:
> On Wed, May 21, 2014 at 6:39 PM, Chris Beams  wrote:
>> I'm personally happy to comply with this for any future commits, but wonder
>> if you've considered the arguments against commit signing [1]? Note
>> especially the reference therein to Linus' original negative opinion on
>> signed commits [2].
> 
> Yes, I've read it. But would his alternative, signing tags, really
> help us more here?

Honest question: what would signed commits do to help us here anyway?
What's the problem being solved?

Unfortunately git places signatures in the history itself, so it's not
like we could use easily use signatures to indicate acceptance after
code review, like we could if we were using monotone for example. Git
just wasn't designed for a commit-signing workflow.

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bug with handing of OP_RETURN?

[Mark Friedenbach]

Is it more complex? The current implementation using template matching
seems more complex than `if script.vch[0] == OP_RETURN &&
script.vch.size() < 42`

On 05/03/2014 12:08 PM, Gregory Maxwell wrote:
> On Sat, May 3, 2014 at 11:55 AM, Mark Friedenbach  wrote:
>> I don't think such a pull request would be accepted. The point was to
>> minimize impact to the block chain. Each extras txout adds 9 bytes
>> minimum, with zero benefit over serializing the data together in a
>> single OP_RETURN.
> 
> In this case it's not a question extra txouts, its a question of
> additional pushes. Assuming you didn't get the push overhead for free,
> the only issue I see with that off the cuff is extra complexity in the
> IsStandard rule... but really, why?  Your application already needs to
> define the meaning of the data— what point is there in making your
> hash commitment less uniform with the rest of the network?
> 

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bug with handing of OP_RETURN?

[Mark Friedenbach]

I don't think such a pull request would be accepted. The point was to
minimize impact to the block chain. Each extras txout adds 9 bytes
minimum, with zero benefit over serializing the data together in a
single OP_RETURN.

On 05/03/2014 11:39 AM, Peter Todd wrote:
> The standard format ended up being exactly:
> 
> OP_RETURN <0 to 40-byte PUSHDATA>
> 
> You've split the data across two PUSHDATA's. The standard should have let the 
> data be split up like that; pull requests accepted.
> 

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

[Mark Friedenbach]

On 04/28/2014 07:32 AM, Sergio Lerner wrote:
> So you agree that:  you need a periodic connection to a honest node, but
> during an attack you may loose that connection. This is the assumption
> we should be working on, and my use case (described in
> http://bitslog.wordpress.com/2014/04/25/smartspv-a-better-simplified-payment-verification-for-smartphones/)
> assumes that.

No, that's sortof tangential. What you are solving is some higher level
application on top of SPV proofs, compact or otherwise. SPV proofs have
many broad applications, such as 2-way pegs where proof-of-work is used
to reach consensus over the most-work side-chain header, and a non-51%
attack is detectable from observed difficulty and interblock times. Do
you need an honest peer to learn about the best chain? Yes. Do you need
to *trust* that you have an honest peer? No, because a non-51% attack
against you is probabilistically detectable with existing tools.

Maybe SmartSPV is useful, maybe not. The application domain is not
something I've been concerned with in the past. But what you describe is
a higher-level protocol that uses block headers to determine which chain
to trust. My simple point from the start has been that you can use
back-link commitments and compact SPV proofs to accomplish what you want
fewer messages, less bandwidth, and equal security. The two proposals
are not in conflict with each other.

--
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.  Get 
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

[Mark Friedenbach]

On 04/27/2014 05:36 AM, Sergio Lerner wrote:
>> Without invoking moon math or assumptions of honest peers and
>> jamming-free networks, the only way to know a chain is valid is to 
>> witness the each and every block. SPV nodes on the other hand,
>> simply trust that the most-work chain is a valid chain, based on
>> economic arguments about the opportunity cost of mining invalid
>> blocks.
> I argue that you cannot talk about "the most-work chain" without 
> actually making an assumption about honest peers.

I should have said "without invoking moon math or interactive protocols
requiring honest peers over jamming-free networks." The interactive
protocol was more the point than the honest peers and jamming-free
network. Yes, without an honest peer and an un-jammed network, you might
never learn about the most-work chain in the first place. But having the
security of the proof not depend on query access to an honest full node
is absolutely necessary for some applications and certainly desirable in
others.

Although strictly speaking what I said may not be 100% true. The single
alternative solution I've seen involves some sort of Fiat–Shamir
transform that could give you a probabilistic proof by including random
additional paths through the block chain chosen based on the combined
hash of the headers. However this is disadvantageous as it massively
increases the proof size and verification time, and you have to include
a lot of data to achieve assurance that more work was required to
generate the fraud than an honest chain.

> If you do not make the assumption, you compute the "economic
> arguments" wrong.

Not necessarily. By requiring connectivity you know that what you are
receiving is built off of the main chain, for example, and you can still
make assumptions about resulting opportunity costs.

> First this is a method that uses NPPs, not SPV proofs. Since the
> method chooses all peers that are synchronized (have the latest
> current block) then going back means only skipping a potential short
> fork (which I suppose has never been more than 3 blocks during normal
> network conditions). You're looking for a common ancestor, not the
> checkpoint. So the linear scan is actually O(1). The exact value can
> be approximated by the sum of the convergent infinite geometrical
> sequence of forking probabilities, which it's about 1.03 without
> considering selfish-mining, and probably less than 2.03 considering
> it.

Unless you're connected to attacker nodes which are wildly divergent
from each other. It's relatively easy to create a massive fake history
of difficulty-1 blocks.

If you assume honest peers things get very easy. But that's not a safe
assumption to be making. With back-link block-history commitments, on
the other hand, an interactive protocol allows you to do a binary search
to find common ancestors, and have trust that the intermediate links
actually exist.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal for extra nonce in block header

[Mark Friedenbach]

I'm not convinced of the necessity of this idea in general, but if it
were to be implemented I would recommend serializing the nVersion field
as a VarInt (Pieter Wuille's multi-byte serialization format) and using
the remaining space of the 4 bytes as your extra nonce.

That would allow serialization of numbers up to 0x1020407f (slightly
over 28 bits) before the 4-byte field is exhausted. For version numbers
less than 0x204080 there will be at least one byte of padding space left
over for extra-nonce usage (two bytes if less than 0x4080, three bytes
if less than 0x80). For version values up to 127, the format is exactly
identical when the padding bytes are zero.

On 04/27/2014 12:07 AM, Timo Hanke wrote:
> I'd like to put the following draft of a BIP up for discussion.
> 
> Timo
> 
> # Abstract
> There are incentives for miners to find cheap, non-standard ways to generate 
> new work, which are not necessarily in the best interest of the protocol.
> In order to reduce these incentives this proposal re-assigns 2 bytes from the 
> version field of the block header to a new extra nonce field. 
> # Copyright
> # Specification
> The block version number field in the block header is reduced in size from 4 
> to 2 bytes. 
> The third and fourth byte in the block header are assigned to the new extra 
> nonce field inside the block header.
> # Motivation
> The motivation of this proposal is to provide miners with a cheap 
> constant-complexity method to create new work that does not require altering 
> the transaction tree.
> 
> Furthermore, the motivation is to protect the version and timestamp fields in 
> the block header from abuse.
> # Rationale
> Traditionally, the extra nonce is part of the coinbase field of the 
> generation transaction, which is always the very first transaction of a block.
> After incrementing the extra nonce the minimum amount of work a miner has to 
> do to re-calculate the block header is a) to hash the coinbase transaction 
> and b) to re-calculate the left-most branch of the merkle tree all the way to 
> the merkle root.
> This is necessary overhead a miner has to do besides hashing the block header 
> itself.
> We shall call the process that leads to a new block header from the same 
> transaction set the _pre-hashing_.
> 
> First it should be noted that the relative cost of pre-hashing in its 
> traditional form depends
> on the block size, which may create an unwanted incentive for miners
> to keep the block size small. However, this is not the main motivation for
> the current proposal.
> 
> While the block header is hashed by ASICs, pre-hashing typically happens on a 
> CPU because of the greater flexibility required.
> Consequently, as ASIC cost per hash performance drops the relative cost of 
> pre-hashing increases.
> 
> This creates an incentive for miners to find cheaper ways to create new work 
> than by means of pre-hashing.
> An example of this currently happening is the on-device rolling of the 
> timestamp into the future.
> These ways of creating new work are unlikely to be in the best interest of 
> the protocol.
> For example, rolling the timestamp faster than the real time is unwanted 
> (more so on faster blockchains).
> 
> The version number in the block header is a possible target for alteration 
> with the goal of cheaply creating new work.
> Currently, blocks with arbitrarily large version numbers get relayed and 
> accepted by the network.
> As this is unwanted behaviour, there should not exist any incentive for a 
> miner to abuse the version number in this way. 
> 
> The solution is to reduce the range of version numbers from 2^32 to 2^16 and 
> to declare the third and forth bytes of the block header as legitimate space 
> for an extra nonce.
> This will reduce the incentive for a miner to abuse the shortened version 
> number by a factor in the order of 2^16. 
> 
> As a side effect, this proposal greatly reduces the bandwidth requirements of 
> a blind pool protocol by only submitting the block header to the miner.
> # Backwards Compatibility
> Old versions of the client will accept blocks of this kind but will throw an 
> alert at the user to upgrade.
> The only code change would be a cast of the version number to a short.
> Besides the upgrade alert, old and new versions of the client can co-exist 
> and there is no need to introduce a new block version number or to phase-out 
> old block versions.
> # Reference Implementation
> # Final implementation
> 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforg

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

[Mark Friedenbach]

I don't think there's an official definition of "SPV proof." I wasn't
trying to make a argument "from definition" (that would be fallacious!).
Rather I suspected that we had different concepts in mind and wanted to
check.

That said, I do think that the definition I gave matches how the term is
used in the Satoshi whitepaper, and the way in which SPV clients like
BitcoinJ work. "Best chain" is typically taken to mean the most-work,
*valid* chain. Without invoking moon math or assumptions of honest peers
and jamming-free networks, the only way to know a chain is valid is to
witness the each and every block. SPV nodes on the other hand, simply
trust that the most-work chain is a valid chain, based on economic
arguments about the opportunity cost of mining invalid blocks. These SPV
nodes use block headers as proofs to determine the most-work block
connected to the genesis block or most recent checkpoint. So yes,
operationally at least this is what the community seems to mean by "SPV
proof".

Now regarding your use case:

> For the remaining peers, the client starts asking for parents blocks 
> until all parents agree (this is the last common parent).

This linear scan of block headers is what I would prefer to avoid. By
using back-links you make it have log(N) space usage.

On 04/26/2014 07:39 PM, Sergio Lerner wrote:
> El 26/04/2014 10:43 p.m., Mark Friedenbach escribió:
>> Sergio,
>> 
>> First of all, let's define what an SPV proof is: it is a succinct 
>> sequence of bits which can be transmitted as part of a 
>> non-interactive protocol that convincingly establishes for a
>> client without access to the block chain that for some block B, B
>> has an ancestor A at some specified height and work distance back,
>> and the cost of creating a false proof is at least as much work as
>> it claims to represent.
> Ok. I was thinking with another definition SPV proof.
> 
> For me a SPV proof is a sequence of bits which can be transmitted as
>  part of a non-interactive protocol that convincingly establishes
> for a client without access to the block chain that a block B is part
> of the best-chain.
> 
> I understand that SPV nodes require SPV proofs as defined in my 
> definition, but I can't realize how to prove that SPV nodes require 
> SPV proofs under your definition. So your definition sounds to me 
> like one possible solution, but not the need.
> 
> Is your definition something well-established in the community?
> 
> 
> 
> 
> --
>
>
> 
Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software Java Based 
> Open Source Intranet - Social, Extensible, Cloud Ready Get Started 
> Now And Turn Your Intranet Into A Collaboration Platform 
> http://p.sf.net/sfu/ExoPlatform 
> ___ Bitcoin-development 
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

[Mark Friedenbach]

Sergio,

First of all, let's define what an SPV proof is: it is a succinct
sequence of bits which can be transmitted as part of a non-interactive
protocol that convincingly establishes for a client without access to
the block chain that for some block B, B has an ancestor A at some
specified height and work distance back, and the cost of creating a
false proof is at least as much work as it claims to represent.

The previous email you quote demonstrates how with additional backlink
commitments this can be done in logarithmic space: using an average of
log(N) headers to construct an SPV proof from block A to block B where N
is the height differential. It can be verified without access to the
block chain or other peers. Note that with back links the cost of
creating a fraudulent SPV proof is the same as 51% attacking bitcoin
itself. The protocol you outlined does not have this property.

Other than that, honestly I'm not really sure what you are trying to
accomplish. An interactive proof is does not meet the above requirements
and is not usable for the driving application of two-way pegs. Maybe you
had some other application in mind? I've looked at your SmartSPV
proposal, but fail to see how it doesn't reduce to simply blind trust in
your view of the network from your peers. SPV proofs on the other hand
put an economic cost to fraud.

On 04/26/2014 06:08 PM, Sergio Lerner wrote:
> I read the post in this threads about Compact SPV proofs via block
> header commitments (archived e-mail in
> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04318.html).
> I was working on the same problem almost at the same time, which is
> something that's becoming very common nowadays..
> 
> The proposal starts with the following claim:
> 
> "In simple payment verification (SPV) proofs it is currently necessary
> that every intervening block header be provided between two blocks in
> order to establish both connectivity and proof of work."
> 
> I think this is false. Let's first assume that at the time of an attack
> we're connected only to the attacker (no honest nodes). An
> non-interactive SPV proof needs to prove that a transaction belongs to
> the best chain because creating a counterfeit proof cost more than the
> amount of money involved in the proof. Suppose that the proof consist at
> least of a block header and a merkle branch to the claimed transaction.
> 
> Do the proof need connectivity with the last checkpoint known by the
> verifier? (here checkpoint is any block known for sure to be in the best
> chain)
> 
> Not much, because connectivity only proves that the proof was not
> pre-computed before the checkpoint. Only if the checkpoint is very near
> (say 10 blocks back) it brings some practical evidence that the attacker
> did not have much time to prepare an attack.
>  
> Do the proof need to know the interleaving proof-of-work?
> 
> Not much. If the distance between blocks is less than 2016 blocks, then
> the difficulty may have change only by a factor of 4. Currently
> difficult adjustments are much lower (I suppose that about 1.1 or so).
> Then one can assume that the proof block target difficulty is almost the
> same as the last known difficulty if the block distance is less than
> 2016. If the distance is more, we just load all the interleaving
> re-target blocks to detect the actual difficulty.
> 
> Do the proof need to have a certain number of  confirmations?
> 
> Yes and no, because this is the only evidence that the prover has either
> spend money in creating the fake block or took a genuine block.
> The cost of creating a fake block can be approximated as the minimum of:
> - The current reward of the block (since currently fees are much lower
> than the reward)
> - The average block fees (when the reward goes to zero)
> - The minimum electricity cost of mining the block.
> 
> As time passes one could assume that the electricity cost of mining will
> approach the other two. 
> 
> But there is the problem of parallel synchronized attacks: if an
> attacker can reuse the same fake SPV proof to attack several victims,
> then the reward for cheating increases proportionally but the cost stays
> the same.
> For instance, if 6 confirmations are required, and each block can hold
> 2000 transactions, the attacker can find 2000 victims and re-use the
> same 6 block chain to "prove" payments to 2000 victims. Also the cost of
> mining 6 blocks can be amortized by mining 7, and attacking in the first
> two 4000 victims, etc...
> 
> Any scheme than relies on non-interactive SPV proofs will fail if
> Bitcoin will scale up-to a point where victims can be easily found and
> synchronized.
> So I think one should assume that at least one peer is honest...
> 
> But if we assume than during the attack least one peer is honest, then
> we could directly ask every peer to give us the blocks of their
> best-chains at the same heights of the presented proof.  No back-links
> are necessary.  If any peer s

Re: [Bitcoin-development] Proof-of-Stake branch?

[Mark Friedenbach]

That makes double-spends trivially easy: sign two blocks, withholding
one. Then at a later point in time reveal the second signed block
(demonstrating your own fraud) and force a reorg.

On 04/26/2014 04:44 PM, Gareth Williams wrote:
> What about using fraud proofs? Your coinbase only matures if nobody publishes 
> proof that you signed a competing block. 
> 
> Then something is at least at stake. When it's your chance to sign a block, 
> attempting to sign and publish more than one at the same height reliably 
> punishes you (you effectively waste your chance and receive no reward.)
> 
> I can't remember who I saw discussing this idea. Might have been Vitalik 
> Buterin?
> 
> On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach  wrote:
>> There's no need to be confrontational. I don't think anyone here
>> objects
>> to the basic concept of proof-of-stake. Some people, myself included,
>> have proposed protocols which involve some sort of proof of stake
>> mechanism, and the idea itself originated as a mechanism for
>> eliminating
>> checkpoints, something which is very much on topic and of concern to
>> many here.
>>
>> The problems come when one tries to *replace* proof-of-work mining with
>> proof-of-stake "mining." You encounter problems related to the fact
>> that
>> with proof-of-stake nothing is actually at stake. You are free to sign
>> as many different forks as you wish, and worse have incentive to do so,
>> because whatever fork does win, you want it to be yours. In the worst
>> case this results in double-spends at will, and in the best case with
>> any of the various proposed protections deployed, it merely reduces to
>> proof-of-work as miners grind blocks until they find one that names
>> them
>> or one of their sock puppets as the signer of the next block.
>>
>> I sincerely doubt you will find a solution to this, as it appears to be
>> a fundamental issue with proof-of-stake, in that it must leverage an
>> existing mechanism for enforced scarcity (e.g. proof-of-work) in order
>> to work in a consensus algorithm. Is there some solution that you have
>> in mind for this?
>>
>> Mark
>>
>> On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
>>> Do it. Someone will scream harm. The loudest voices screaming how it
>> would
>>> be harmful are doing the most harm.
>>>
>>> The only way to know is build it, and test it. If the network breaks,
>> then
>>> it is better we find out sooner rather than later.
>>>
>>> My only suggestion is call it 'bitstake' or something to clearly
>> differentiate
>>> it from Bitcoin. This also might be an interesting application of the
>> side
>>> chains concept Peter Todd has discussed.
>>>
>>> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
>>>> Hello all.
>>>>
>>>> I understand that Proof-of-Stake as a replacement for Proof-of-Work
>> is a prohibited yet disputed change to Bitcoin Core. I would like to
>> create a Bitcoin branch that provides a sandboxed testbed for
>> researching the best PoS implementations. In the years to come, perhaps
>> circumstances might arise, such as shifting of user opinion as to
>> whether PoS should be moved from the prohibited list to the hard-fork
>> list.
>>>> -
>>>>
>>>> A poll I conducted today on bitcointalk,
>> https://bitcointalk.org/index.php?topic=581635.0 with an
>> attention-grabbing title suggests some minority support for Bitcoin
>> Proof-of-Stake. I invite any of you to critically comment on that
>> thread.
>>>>
>>>> "Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full
>> nodes outnumber existing Proof-of-Work full nodes by three-to-one. What
>> is your choice?"
>>>>
>>>> "I do not care or do not know enough." - 5 (16.1%) 
>>>> "I would download and run the existing Proof-of-Work program to
>> fight the change." - 14 (45.2%) 
>>>> "I would download and run the new Proof-of-Stake program to favor
>> the change. " - 12 (38.7%) 
>>>> Total Voters: 31 
>>>> -
>>>>
>>>> Before I branch the source code and learn the proper way of doing
>> things in this community, I ask you simply if creating the branch is
>> harmful? My goal is to develop, test and document PoS, while exploring
>> its vulnerabilities and fixing them in a transparent fashion.
>>>>
>>>> Thanks for taking a bi

Re: [Bitcoin-development] Proof-of-Stake branch?

[Mark Friedenbach]

There's no need to be confrontational. I don't think anyone here objects
to the basic concept of proof-of-stake. Some people, myself included,
have proposed protocols which involve some sort of proof of stake
mechanism, and the idea itself originated as a mechanism for eliminating
checkpoints, something which is very much on topic and of concern to
many here.

The problems come when one tries to *replace* proof-of-work mining with
proof-of-stake "mining." You encounter problems related to the fact that
with proof-of-stake nothing is actually at stake. You are free to sign
as many different forks as you wish, and worse have incentive to do so,
because whatever fork does win, you want it to be yours. In the worst
case this results in double-spends at will, and in the best case with
any of the various proposed protections deployed, it merely reduces to
proof-of-work as miners grind blocks until they find one that names them
or one of their sock puppets as the signer of the next block.

I sincerely doubt you will find a solution to this, as it appears to be
a fundamental issue with proof-of-stake, in that it must leverage an
existing mechanism for enforced scarcity (e.g. proof-of-work) in order
to work in a consensus algorithm. Is there some solution that you have
in mind for this?

Mark

On 04/25/2014 12:33 AM, Troy Benjegerdes wrote:
> Do it. Someone will scream harm. The loudest voices screaming how it would
> be harmful are doing the most harm.
> 
> The only way to know is build it, and test it. If the network breaks, then
> it is better we find out sooner rather than later.
> 
> My only suggestion is call it 'bitstake' or something to clearly differentiate
> it from Bitcoin. This also might be an interesting application of the side
> chains concept Peter Todd has discussed.
> 
> On Thu, Apr 24, 2014 at 04:32:15PM -0700, Stephen Reed wrote:
>> Hello all.
>>
>> I understand that Proof-of-Stake as a replacement for Proof-of-Work is a 
>> prohibited yet disputed change to Bitcoin Core. I would like to create a 
>> Bitcoin branch that provides a sandboxed testbed for researching the best 
>> PoS implementations. In the years to come, perhaps circumstances might 
>> arise, such as shifting of user opinion as to whether PoS should be moved 
>> from the prohibited list to the hard-fork list.
>> -
>>
>> A poll I conducted today on bitcointalk, 
>> https://bitcointalk.org/index.php?topic=581635.0 with an attention-grabbing 
>> title suggests some minority support for Bitcoin Proof-of-Stake. I invite 
>> any of you to critically comment on that thread.
>>
>> "Annual 10% bitcoin dividends can be ours if  Proof-of-Stake full nodes 
>> outnumber existing Proof-of-Work full nodes by three-to-one. What is your 
>> choice?"
>>
>> "I do not care or do not know enough." - 5 (16.1%) 
>> "I would download and run the existing Proof-of-Work program to fight the 
>> change." - 14 (45.2%) 
>> "I would download and run the new Proof-of-Stake program to favor the 
>> change. " - 12 (38.7%) 
>> Total Voters: 31 
>> -
>>
>> Before I branch the source code and learn the proper way of doing things in 
>> this community, I ask you simply if creating the branch is harmful? My goal 
>> is to develop, test and document PoS, while exploring its vulnerabilities 
>> and fixing them in a transparent fashion.
>>
>> Thanks for taking a bit of your time to read this message.
> 
> 
> 
> 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP - Selector Script

[Mark Friedenbach]

I think you're misunderstanding the point. The way you get IsStandard
changed is that you make an application-oriented BIP detailing the use
of some new standard transaction type (say, generalized hash-locked
transactions for atomic swaps). We then discuss that proposal for its
technical merits and reach consensus about the best way to do, for
example, cross-chain atomic swaps. It is then implemented.

So please, focus on some BIP(s) detailing applications of hash-locked
transactions, and we will engage more constructively -- I promise that I
will as cross-chain atomic swaps scratch my itch as well.

On 04/25/2014 01:48 PM, Tier Nolan wrote:
> On Fri, Apr 25, 2014 at 9:26 PM, Luke-Jr  > wrote:
> 
> They define standard for interoperability between
> software. So, if you want nodes to relay these transactions, you need to
> convince them, not merely write a BIP for the transaction format.
> 
> 
> I agree with you in theory, each miner could decide their inclusion
> rules for themselves.
> 
> In practice, if the reference client is updated, then most miners will
> accept those transactions.  In addition, it would eventually propagate
> to alt-coins (or at least the supported ones).
> 
> I could simply submit the changes as a pull request for the reference
> client, but I was hoping that by doing it this way, it would increase
> the odds of it being accepted.
>  
> 
> Defining a BIP for cross-chain trading would be one way to do that.
> 
> 
> I don't think it quite requires the same coordination in the short
> term.  I could write up the sequence as an info BIP.
> 
> The malleability "issue" has been known for years.
> I wouldn't expect any special effort made to fix it...
> 
> 
> It is possible to tweak the protocol so that it still works.  However,
> it means that 3rd parties are required (that could go in the BIP too).
>  
> 
> There is some ongoing discussion of a softfork to basically redo the
> Script
> language entirely, but it will take quite a bit of time and
> development before
> we'll see it in the wild.
> 
> 
> Implementing multi-P2SH gets a lot of the benefits of MAST, in terms of
> efficiency.
>  
> 
> 
> Luke
> 
> P.S. Did the BIP editor assign these numbers? If not, best to keep them
> numberless until assigned, to avoid confusion when people Google the
> real BIP
> 44 and 45...
> 
> 
> Not yet, but that is just my personal repo.  I did email gmaxwell, but
> he said that they can't be assigned until some discussion has happened.
>  
> I take your point that the name appears in the link though, so could
> cause issues with searching.
> 
> 
> 
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> --
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise

[Mark Friedenbach]

On 04/22/2014 09:29 PM, Jan Møller wrote:
>>Of course, this is an especially difficult case, as you must send the
>>double-spend after the original transaction - normally just sending a
>>non-standard tx to Eligius first would suffice. Note how this defeats
>>Andresen's double-spend-relay patch(3) as proposed since the
>>double-spend is a non-standard transaction.
> 
> Why can't you send a non-standard tx to Eligius first in this scenario?​
> Is it because LuckyBit is connected directly to Eligius, and does
> Eligius relay (not only mine) non-standard transactions?
> 

Because you only want to double-spend if you loss the bet. If you tried
to double-spend every bet, there'd be no point :)

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

[Mark Friedenbach]

What I was saying is that while it may or may not make sense to have
separate prefixes for testnet, it makes no sense to have per-alt prefixes.

On 04/22/2014 08:49 AM, Tamas Blummer wrote:
> I use several test chains while testing my software, the official test
> net, a standalone net in house and even chains only created on the fly
> for unit tests. I found no use of distinguishing serialization of keys
> while using any of them.
> 
> If you have some deep insights about why this is needed share it, as I
> am not goint to guess your valuable thoughts.
> 
> Regards,
> 
> Tamas Blummer
> http://bitsofproof.com
> 
> On 22.04.2014, at 17:32, Mark Friedenbach  <mailto:m...@monetize.io>> wrote:
> 
>> Testnet vs mainnet is quite a separate issue than bitcoin vs altcoin.
>> Unfortunately few of the alts ever figured this out.
> 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

[Mark Friedenbach]

Testnet vs mainnet is quite a separate issue than bitcoin vs altcoin.
Unfortunately few of the alts ever figured this out.

On 04/22/2014 01:39 AM, Tamas Blummer wrote:
> Extra encoding for testnet is quite useless complexity in face of many
> alt chains.
> BIPS should be chain agnostic.
> 
> Regards,
> 
> Tamas Blummer
> http://bitsofproof.com

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Economics of information propagation

[Mark Friedenbach]

Yes, it certainly can be improved in this way. You can even extend the
idea to distribute partial proofs of work (block headers + Merkle lists
which represent significant but not sufficient work), and 'prime' your
memory pools with the transactions contained within.

This is, btw, basically what p2pool does, which is why last time I
calculated you get roughly 1% better return from p2pool than a zero-fee
mining pool would get you, specifically because of the lower stale rate.

On 04/21/2014 09:22 AM, Paul Lyon wrote:
> I haven't done the math on this, so it may be a terrible idea. :)
> 
> I've been wondering if block propagation times could also be improved by
> allowing peers to request the list of transaction hashes that make up a
> block, and then making a follow-up request to only download any
> transactions not currently known. I'm not sure what percentage of
> transactions a node will usually already have when it receives a new
> block, but if it's high I figure this could be beneficial.
> 

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Economics of information propagation

[Mark Friedenbach]

That wasn't what I was saying. Right now the primacy of a block is
determined by the time at which the `block` message is received, which
is delays due to both the time it takes to transmit the block data and
the time it takes to validate. Headers-first, on the other hand, has the
option of basing primacy on the time the block header is received, which
is O(1) time to transmit and to SPV-validate. Mining on that block
doesn't actually commence until the full block is received and validated.

To see how this works, take an example: two blocks with a common parent
are found relatively close to each other, block A and block B. A is
found first but is a large block with the maximum block size and many
slow scripts. B is found a few seconds later and is an empty block. In
the current regime it is entirely possible that block B, the later but
smaller block, would get received and processed first by more mining
peers than the larger block A, exactly as described in Jonathan Levin's
email.

With headers-first, however, the cost of propagation of the block header
is the same and we should expect block A to win out over block B nearly
every time. Miners will continue working on the old, known valid parent
block until the contents of block A are received and processed. So the
smaller block B is still found, and since it's data moves across the
network faster, miners even briefly mine on block B. But as soon as they
receive and process the contents of block A, they switch to that.

The earlier, larger block A will only become stale if *two* blocks are
found in the extra time it takes for block A to propagate the network.
That is a substantially different risk, and probably a negligible
concern to most miners.

On 04/20/2014 09:06 PM, Peter Todd wrote:
> That is mistaken: you can't mine on top of just a block header,
> leaving small miners disadvantaged as they are earning no profit
> while they wait for the information to validate the block and update
> their UTXO sets. This results in the same problem as before, as the
> large pools who mine most blocks can validate either instantly - the
> self-mine case - or more quickly than the smaller miners.
> 
> Of course, in reality smaller miners can just mine on top of block
> headers and include no transactions and do no validation, but that is
> extremely harmful to the security of Bitcoin.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Economics of information propagation

[Mark Friedenbach]

As soon as we switch to headers
first - which will be soon - there will be no difference in propagation
time no matter how large the block is. Only 80 bites will be required to
propagate the block header which establishes priority for when the block is
fully validated.
On Apr 20, 2014 6:56 PM, "Jonathan Levin" 
wrote:

> Hi all,
>
> I am a post-graduate economist writing a paper on the incentives of
> mining. Even though this issue has been debated in the forums, I think it
> is important to get a sense of the magnitude of the incentives at play and
> determine what implications this has for the transaction fee market.
>
> As it has been pointed out before the marginal cost for miners does not
> stem from the private cost of the miner validating the signature and
> including it in the list of transactions in the block but rather the
> increased probability that the block will be orphaned as a result of slower
> propagation. Gavin did some back of the envelope worst case calculations
> but these overstated the effect of propagation delay. The reason being the
> 80ms additional time to reach 50% of the network is spread throughout the
> time that it takes to reach 50% of the network. During this time miners are
> notified about the block and treat it as the longest chain and hence are no
> longer mining with the aim to produce a competing block.
>
> I am looking to calculate the change in the curvature of the probability
> mass function that a block hears about my block in any given second as a
> function of the block size. Although there is likely to be significant
> noise here, there seems to be some stable linear relationships with the
> time that it takes to reach different quartiles. Has anyone done this? I
> have used some empirical data that I am happy to share but ideally I would
> like analytical solutions.
>
> Following Peter Todd, I also find the concerning result that propagation
> delays results in increasing returns to higher shares of the hashing power.
> Indeed it may well be in the interest of large pools to publish large
> blocks to increase propagation delays on the network which would increase
> orphan rates particularly for small miners and miners that have not
> invested in sufficient bandwidth / connectivity. If a small miner hears
> about a block after 4.5 seconds on average there is a 0.7% chance that
> there is already a block in circulation.  Large miners can increase the
> time that it takes for small miners to hear about blocks by increasing the
> size of their blocks. For example if the time that it takes for a small
> miner to hear about the block goes to 12 seconds there is a 2 percent
> chance there is already a block in circulation for the small miner. There
> is also a 1.2% chance that there will be a competing block published after
> a small miner propagates in the time that it gets to full propagation. Am I
> getting this right that the probability of a miner’s block being orphaned
> is comprised of the probability that the miner was not the first to find a
> valid block and the probability that given they are first, someone else in
> the absence of hearing about it finds a competing valid block.
>
> One question is: Are orphans probabilistic and only resolved after hearing
> about a new block that lengthens the chain or is there a way to know in
> advance? Is it frowned upon to mine on top of a block that you have just
> found even though it is very likely going to end up an orphan?
>
> Would be happy to share the draft form of the paper and receive any
> feedback.
>
> Finally, at coinometrics we are working on a modified client to capture
> information on network propagation and would invite any suggestions of any
> other useful statistics that would be useful in the development of software.
>
> Best,
>
> Jonathan
>
>
>
>
>
>
>
>
>
>
> On 21 Apr 2014, at 01:16, <
> bitcoin-development-requ...@lists.sourceforge.net> <
> bitcoin-development-requ...@lists.sourceforge.net> wrote:
>
> > Send Bitcoin-development mailing list submissions to
> >   bitcoin-development@lists.sourceforge.net
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >   https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> > or, via email, send a message with subject or body 'help' to
> >   bitcoin-development-requ...@lists.sourceforge.net
> >
> > You can reach the person managing the list at
> >   bitcoin-development-ow...@lists.sourceforge.net
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Bitcoin-development digest..."
> >
> >
> > Today's Topics:
> >
> >   1. Re: "bits": Unit of account (Oliver Egginger)
> >   2. Re: "bits": Unit of account (Christophe Biocca)
> >   3. Re: "bits": Unit of account (Gmail)
> >   4. Re: "bits": Unit of account (Mike Caldwell)
> >   5. Re: "bits": Unit of account (Justin A)
> >
> >
> > --
> >
> > Message: 1

Re: [Bitcoin-development] Timed testing

[Mark Friedenbach]

Not necessarily. Running a private server involves listening to the p2p
network for incoming transactions, performing validation on receipt and
organizing a mempool, performing transaction selection, and relaying
blocks to auditors - none of which is tested in a reindex.

A reindex would give you an optimistic upper bound though, if that's all
you care about.

On 04/17/2014 08:49 AM, Mike Hearn wrote:
> 2) If I wanted to measure validation performance, to get the number of
> peak tps that could be processed without taking block sides or network
> latency into account, how would I do that? Has anybody tried this
> before?
> 
> You can just reindex/replay the chain. It's been done many times. 

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)

[Mark Friedenbach]

On 04/16/2014 02:29 PM, Kevin wrote:
> Okay, so how about an autoupdate function which pulls a work around off 
> the server?  Sooner or later, the vulnerabilities must be faced.

NO. Bitcoin Core will never have an auto-update functionality. That
would be a single point of failure whose compromise could result in the
theft of every last bitcoin held in a Bitcoin Core wallet.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)

[Mark Friedenbach]

We don't support XP. In fact we don't support *any* distribution, but I
will assume you mean "provide a binary which runs on X." Can you find
any reference to Windows XP on the website? I can't.

On 04/16/2014 09:41 AM, Chris Williams wrote:
> It may not be our place to say whether XP is secure or not, but if we say 
> that we support it then we have to run test passes against XP as a platform, 
> and if an XP user reports a bug, then we have to do something to address it.  
> So, it becomes a test and support issue, not a security issue.
> 
> That’s why it doesn’t make sense to support an OS platform that the original 
> vendor (MS) no longer supports themselves.
> 
> On Apr 16, 2014, at 9:35 AM, Mark Friedenbach  wrote:
> 
>> On 04/16/2014 09:27 AM, Kevin wrote:
>>> Should we then add an alert message to wallet installers such as, "Such
>>> and such will not run on windows xp?"
>>
>> It's not really our place to police that ... plus it's perfectly safe to
>> be running Bitcoin Core as a full node on XP. It's just the wallet
>> functionality that people should be careful about. We're talking about
>> such a small intersection of people who are running XP, have systems
>> powerful enough to run Bitcoin Core, and use the wallet functionality.
>>
>> --
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)

[Mark Friedenbach]

On 04/16/2014 09:27 AM, Kevin wrote:
> Should we then add an alert message to wallet installers such as, "Such
> and such will not run on windows xp?"

It's not really our place to police that ... plus it's perfectly safe to
be running Bitcoin Core as a full node on XP. It's just the wallet
functionality that people should be careful about. We're talking about
such a small intersection of people who are running XP, have systems
powerful enough to run Bitcoin Core, and use the wallet functionality.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)

[Mark Friedenbach]

XP is no longer receiving security patches from Microsoft, and hasn't been
for some time. There are known remote exploits that aren't going to be
fixed, ever.
On Apr 16, 2014 8:15 AM, "Kevin"  wrote:

>  On 4/16/2014 4:14 AM, Wladimir wrote:
>
>  Hello,
>
> Today I noticed that even my bank is warning people to not do internet
> banking with Windows XP.
>
> If it is no longer secure enough for online banking it's CERTAINLY not
> secure enough to run a wallet (for a node only it would be ok-ish as they
> have no keys to protect).
>  Any opinions on what to do here? Just warn and allow the user to
> continue? Redirect them to a 'Windows XP is dangerous' message on
> bitcoin.org? (Microsoft uses
> http://windows.microsoft.com/en-us/windows/end-support-help)
>
>  The drawback of dropping XP support completely would be that a lot of
> computers (especially in China and Russia etc) are still running XP, so
> this could cause the network to lose nodes.
>
> If you're maintainer of other wallet software: how are you handling this?
>  Are you going to drop XP support completely? If so, starting from when?
>
> Regards,
>  Wladimir
>
>
>
> --
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book 
> today!http://p.sf.net/sfu/NeoTech
>
>
>
> ___
> Bitcoin-development mailing 
> listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>  I think we should get to the bottom of this.  Should we assume that xp is
> not secure enough?  What is this warning?  Who is issuing this warning?
>
>
> --
> Kevin
>
>
>
> --
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Chain pruning

[Mark Friedenbach]

Checkpoints will go away, eventually.

On 04/10/2014 02:34 PM, Jesus Cea wrote:
> On 10/04/14 18:59, Pieter Wuille wrote:
>> It's important to
>> note that this is a strict reduction in security: we're now trusting
>> that the longest chain (with most proof of work) commits to a valid
>> UTXO set (at some point in the past).
> 
> AFAIK, current bitcoin code code already set blockchain checkpoints from
> time to time. It is a garanteed that a longer chain starting before the
> checkpoint is not going to be accepted suddently. See
> .
> 
> Could be perfectly valid to store only unspend wallets before last
> checkpoint, if during the blockchain download the node did all the checks.
> 
> Would be interesting, of course, to be able to verify "unspend wallet
> accounting" having only that checkpoint data (the merkle tree can do
> that, I guess). So you could detect a data corruption or manipulation in
> your local harddisk.
> 
> 
> 
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment 
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Chain pruning

[Mark Friedenbach]

You took the quote out of context:

"a full node can copy the chain state from someone else, and check that
its hash matches what the block chain commits to. It's important to
note that this is a strict reduction in security: we're now trusting
that the longest chain (with most proof of work) commits to a valid
UTXO set (at some point in the past)."

The described synchronization mechanism would be to determine the
most-work block header (SPV level of security!), and then sync the UTXO
set committed to within that block. This is strictly less security than
building the UTXO set yourself because it is susceptible to a 51% attack
which violates protocol rules.

On 04/10/2014 11:19 AM, Paul Rabahy wrote:
> You say UTXO commitments is "a strict reduction in security". If UTXO
> commitments were rolled in as a soft fork, I do not see any new attacks
> that could happen to a person trusting the committed UTXO + any
> remaining blocks to catch up to the head.
> 
> I would imagine the soft fork to proceed similar to the following.
> 1. Miners begin including UTXO commitments.
> 2. Miners begin rejecting blocks with invalid UTXO commitments.
> 3. Miners begin rejecting blocks with no UTXO commitments.
> 
> To start up a fresh client it would follow the following.
> 1. Sync headers.
> 2. Pick a committed UTXO that is deep enough to not get orphaned.
> 3. Sync blocks from commitment to head.
> 
> I would argue that a client following this methodology is strictly more
> secure than SPV, and I don't see any attacks that make it less secure
> than a full client. It is obviously still susceptible to a 51% attack,
> but so is the traditional block chain. I also do not see any sybil
> attacks that are strengthened by this change because it is not modifying
> the networking code.
> 
> I guess if the soft fork happened, then miners began to not include the
> UTXO commitment anymore, it would lower the overall network hash rate,
> but this would be self-harming to the miners so they have an incentive
> to not do it.
> 
> Please let me know if I have missed something.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Feedback request: colored coins protocol

[Mark Friedenbach]

On 04/10/2014 05:19 AM, Flavien Charlon wrote:
> By the way, padding doesn't solve the issue entirely (issuing 10 billion
> shares sill takes you 100 BTC, even with padding and 1 satoshi = 1
> share), so I am going for the solution where the asset quantity of every
> output is explicitly encoded in the OP_RETURN output. That way, whether
> you are issuing 1 share or 100 trillions, you never need to pay more
> than 540 satoshis.

At this point, I don't think what you are doing is even colored coins
anymore. You might want to look into Counterparty or Mastercoin.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

[Mark Friedenbach]

I've advocated for this in the past, and reasonable counter-arguments I
was presented with are: (1) bittorrent is horribly insecure - it would
be easy to DoS the initial block download if that were the goal, and (2)
there's a reasonable pathway to doing this all in-protocol, so there's
no reason to introduce external dependencies.

On 04/09/2014 01:31 PM, slush wrote:
> Another idea: Integrate torrent download of bootstrap.dat into bitcoind.
> Normal user (especially a beginner) won't learn how to download
> bootstrap separately and import it into bitcoind; he simply give up the
> synchronization once he realize it takes too much time. From my
> experience downloading the bootstrap significantly improves catching the
> blockchain, which may attract some more users to run bitcoind.
> 
> Not sure about C++, but simple torrent client in python is like 30 lines
> of code (using libtorrent).
> 
> Marek
> 
> 
> On Wed, Apr 9, 2014 at 10:12 PM, slush  > wrote:
> 
> I believe there're plenty bitcoind instances running, but they don't
> have configured port forwarding properly.There's uPNP support in
> bitcoind, but it works only on simple setups.
> 
> Maybe there're some not yet considered way how to expose these
> *existing* instances to Internet, to strenghten the network. Maybe
> just self-test indicating the node is not reachable from outside
> (together with short howto like in some torrent clients).
> 
> These days IPv6 is slowly deploying to server environments, but
> maybe there's some simple way how to bundle ipv6 tunnelling into
> bitcoind so any instance will become ipv6-reachable automatically?
> 
> Maybe there're other ideas how to improve current situation without
> needs of reworking the architecture.
> 
> Marek
> 
> 
> On Wed, Apr 9, 2014 at 9:33 PM, Gregory Maxwell  > wrote:
> 
> On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier
> mailto:justusranv...@gmail.com>> wrote:
> > Anyone reading the archives of the list will see about triple the
> > number of people independently confirming the resource usage
> problem
> > than they will see denying it, so I'm not particularly worried.
> 
> The list has open membership, there is no particular
> qualification or
> background required to post here. Optimal use of an information
> source
> requires critical reading and understanding the limitations of the
> medium. Counting comments is usually not a great way to assess
> technical considerations on an open public forum.  Doubly so because
> those comments were not actually talking about the same thing I am
> talking about.
> 
> Existing implementations are inefficient in many known ways (and, no
> doubt, some unknown ones). This list is about developing
> protocol and
> implementations including improving their efficiency.  When talking
> about incentives the costs you need to consider are the costs of the
> best realistic option.  As far as I know there is no doubt from
> anyone
> technically experienced that under the current network rules full
> nodes can be operated with vastly less resources than current
> implementations use, it's just a question of the relatively modest
> implementation improvements.
> 
> When you argue that Bitcoin doesn't have the right incentives (and
> thus something??) I retort that the actual resource
> _requirements_ are
> for the protocol very low. I gave specific example numbers to enable
> correction or clarification if I've said something wrong or
> controversial. Pointing out that existing implementations are
> not that
> currently as efficient as the underlying requirements and that some
> large number of users do not like the efficiency of existing
> implementations doesn't tell me anything I disagree with or didn't
> already know. Whats being discussed around here contributes to
> prioritizing improvements over the existing implementations.
> 
> I hope this clarifies something.
> 
> 
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> 
> 

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

[Mark Friedenbach]

On 04/09/2014 09:09 AM, Tamas Blummer wrote:
> Yes, SPV is a sufficient API to a trusted node to build sophisticated
> features not offered by the core.
> SPV clients of the border router will build their own archive and
> indices based on their interest of the chain therefore the
> border router core does not need to store (and process) anything not
> needed for consensus, its memory
> or disk footprint would be as low as an optimal storage of UTXO.

Storing zero full blocks does nothing to aid the network.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Mark Friedenbach]

On 04/07/2014 12:20 PM, Tamas Blummer wrote:
> Validation has to be sequantial, but that step can be deferred until the
> blocks before a point are loaded and continous.

And how do you find those blocks?

I have a suggestion: have nodes advertise which range of full blocks
they possess, then you can perform synchronization from the adversed ranges!

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Mark Friedenbach]

On 04/07/2014 12:00 PM, Tamas Blummer wrote:
> Once a single transaction in pruned in a block, the block is no longer
> eligible to be served to other nodes. 
> Which transactions are pruned can be rather custom e.g. even depending
> on the wallet(s) of the node,
> therefore I guess it is more handy to return some bitmap of pruned/full
> blocks than ranges.

The point is that the node has decided not to prune transactions from
that block, so that it is capable of returning full blocks within that
range.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Mark Friedenbach]

On 04/07/2014 09:57 AM, Gregory Maxwell wrote:
> That is an implementation issue— mostly one that arises as an indirect
> consequence of not having headers first and the parallel fetch, not a
> requirements issue.

Oh, absolutely. But the question "why are people not running full
nodes?" has to do with the current implementation, not abstract
capabilities of a future version of the bitcoind code base.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Why are we bleeding nodes?

[Mark Friedenbach]

Right now running a full-node on my home DSL connection (<1Mbps) makes
other internet activity periodically unresponsive. I think we've already
hit a point where resource requirements are pushing out casual users,
although of course we can't be certain that accounts for all lost nodes.

On 04/07/2014 08:53 AM, Gregory Maxwell wrote:
> On Mon, Apr 7, 2014 at 8:45 AM, Justus Ranvier  
> wrote:
>> 1. The resource requirements of a full node are moving beyond the
>> capabilities of casual users. This isn't inherently a problem - after
>> all most people don't grow their own food, tailor their own clothes, or
>> keep blacksmith tools handy in to forge their own horseshoes either.
> 
> Right now running a full node consumes about $1 in disk space
> non-reoccurring and costs a couple cents in power per month.
> 
> This isn't to say things are all ducky. But if you're going to say the
> resource requirements are beyond the capabilities of casual users I'm
> afraid I'm going to have to say: citation needed.
> 
> --
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment 
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees_APR
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> .
> 

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Feedback request: colored coins protocol

[Mark Friedenbach]

Flavien, capital is wealth or resources available for the stated purpose
of the company. These bitcoins represent nothing more than a speculative
floor owned by the investors, not the company.

On 04/07/2014 07:00 AM, Flavien Charlon wrote:
> Jorge, they'd have to be. Otherwise, assuming the price of the share
> goes low enough, you could buy a share of the company, melt the gold
> plate, and sell it for a profit. If the gold is part of the capital of
> the company, the cheapest a share can be is the price of the gold on
> which the stock certificate is printed.
> 
> This is why I think the importance of padding with colored coins is
> overblown.
> 
> 
> On Mon, Apr 7, 2014 at 1:12 PM, Jorge Timón  > wrote:
> 
> On 4/7/14, Flavien Charlon  > wrote:
> > Also those 54 BTC (actually 5.4 BTC if the dust is now 540
> satoshis) become
> > part of the capital of the company, and can always be recovered by
> > uncoloring the shares. It's an investment, not an expense, so I
> think it is
> > acceptable.
> 
> This doesn't make much sense to me.
> If you print shares on gold plates instead of paper, is that gold
> "part of the capital of the company"? I don't think so.
> 
> 

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test & Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Feedback request: colored coins protocol

[Mark Friedenbach]

On 04/06/2014 01:59 PM, Flavien Charlon wrote:
> Do you think this is the right approach?

No, I'm afraid it has significant flaws. The two chief flaws are (1)
there is absolutely no reason to include asset tagging information if it
is not validated - that just bloats the block chain, and (2) you
shouldn't be using fixed increments for share sizes either. It's not
future-proof as the minimum output size changes based on the minimum fee
(currently 540 satoshis, not 5,400, and it will float in the near
future). And needing a capital of 54 btc for a million shares is totally
unacceptable.

Flavien, I know that I've seen you on the Bitcoin-X mailing list, where
these issues have been mostly worked out:

https://groups.google.com/forum/#!forum/bitcoinx

Have you seen the padded order-based coloring scheme worked out here?

https://github.com/bitcoinx/colored-coin-tools/wiki/colored_coins_intro

Kind regards,
Mark Friedenbach

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

Re: [Bitcoin-development] Best practices for dust remining

[Mark Friedenbach]

NONE|ANYONECANPAY. This is what dust-be-gone does.
On Mar 29, 2014 12:46 PM, "Justus Ranvier"  wrote:

> Suppose am m-of-n multisig wallet receives a bunch of dust deposits due
> to somebody advertising the Olympics, or any other reason, and the users
> of the wallet don't want the few satoshis involved.
>
> What is the best way to allow all these dust outputs to be re-mined in
> order to clean up the utxo set, keeping in mind the scripts may include
> large values of n?
>
> --
> Support online privacy by using email encryption whenever possible.
> Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
>
>
> --
>
> ___
> 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] Tree-chains preliminary summary

[Mark Friedenbach]

I'm afraid I'm going to be the jerk that requested more details and then
only nitpicks seemingly minor points in your introduction. But its
because I need more time to digest the contents of your proposal. Until
then:

> But moving value between chains is inconvenient; right now moving
> value requires trusted third parties. Two-way atomic chain transfers
> does help here, but as recent discussions on the topic showed there's
> all sorts of edge cases with reorganizations that are tricky to 
> handle; at worst they could lead to inflation.

This isn't true. The re-org issue is fairly handled in the 2-way pegging
scheme that Greg Maxwell developed and Adam Back described a week ago on
this list. Depending on the implementation it could even be configurable
by the person performing the peg too - allowing the transfer to specify
the confirmation depth required during the quieting period in order to
protect against re-orgs up to a sufficient depth. I think this is worked
out quite well with sufficient enumeration of edge cases, and I don't
think they are particularly tricky to handle or lead to money-losing
situations under the explicit security assumptions.

More importantly, to your last point there is absolutely no way this
scheme can lead to inflation. The worst that could happen is theft of
coins willingly put into the pegging pool. But in no way is it possible
to inflate the coin supply.

I will look at your proposal in more depth. But I also think you should
give 2-way pegging a fair shake as pegging to side chains and private
accounting servers may eliminate the need.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

[Mark Friedenbach]

On 03/24/2014 01:34 PM, Troy Benjegerdes wrote:
> I'm here because I want to sell corn for bitcoin, and I believe it will be
> more profitable for me to do that with a bitcoin-blockchain-based system
> in which I have the capability to audit the code that executes the trade.

A discussion over such a system would be on-topic. Indeed I have made my
own proposals for systems with that capability in the past:

http://sourceforge.net/p/bitcoin/mailman/message/31322676/

There's no reason to invoke alts however. There are ways where this can
be done within the bitcoin ecosystem, using bitcoins:

http://sourceforge.net/p/bitcoin/mailman/message/32108143/

> I think that's fair, so long as we limit bitcoin-development discussion to
> issues that are relevant to the owners of the hashrate and companies that
> pay developer salaries.
> 
> What I'm asking for is some honesty that Bitcoin is a centralized system
> and to stop arguing technical points on the altar of distributed/decentralized
> whatever. It's pretty clear if you want decentralized you should go with 
> altchains.

Bitcoin is not a centralized system, and neither is its development. I
don't even know how to respond to that. Bringing up altchains is a total
red herring.

This is *bitcoin*-development. Please don't make it have to become a
moderated mailing list.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

[Mark Friedenbach]

This isn't distributed-systems-development, it is bitcoin-development.
Discussion over chain parameters is a fine thing to have among people
who are interested in that sort of thing. But not here.

On 03/23/2014 04:17 PM, Troy Benjegerdes wrote:
> I find it very irresponsible for Bitcoiners to on one hand extol the virtues
> of distributed systems and then in the same message claim any discussion
> about alternate chains as 'off-topic'.
> 
> If bitcoin-core is for *distributed systems*, then all the different altcoins
> with different hash algorithms should be viable topics for discussion.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

[Mark Friedenbach]

Jeff, there are *plenty* of places that lack local Internet access for
one or both participants.

Obviously making the case where both participants lack access to the
bitcoin network is difficult to secure, but not impossible (e.g. use a
telephany-based system to connect to a centralized double-spend
database, as VISA does).

I expect the case where one participant has Internet access (the
merchant) and the other does not to be very, very common. The majority
of transactions I do on a daily basis are like this, and I live in
Silicon Valley!

On 03/22/2014 09:35 AM, Jeff Garzik wrote:
> Let's not pull out silly examples.  Of course you can find locations
> that lack Internet.
> 
> Those locations are completely unsuitable to bitcoin transactions,
> since the receiver cannot verify double-spending or anything else
> about the transaction.

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

[Mark Friedenbach]

Please, by all means: ignore our well-reasoned arguments about
externalized storage and validation cost and alternative solutions.
Please re-discover how proof of publication doesn't require burdening
the network with silly extra data that must be transmitted, kept, and
validated from now until the heat death of the universe. Your failure
will make my meager bitcoin holdings all the more valuable! As despite
persistent assertions to the contrary, making quality software freely
available at zero cost does not pay well, even in finance. You will not
find core developers in the Bitcoin 1%.

Please feel free to flame me back, but off-list. This is for *bitcoin*
development.

On 03/22/2014 08:08 AM, Troy Benjegerdes wrote:
> On Sat, Mar 22, 2014 at 04:47:02AM -0400, Peter Todd wrote:
>> There's been a lot of recent hoopla over proof-of-publication, with the
>> OP_RETURN  length getting reduced to a rather useless 40 bytes at
>> the last minute prior to the 0.9 release. Secondly I noticed a
>> overlooked security flaw in that OP_CHECKMULTISIG sigops weren't taken
>> into account, making it possible to broadcast unminable transactions and
>> bloat mempools.(1) My suggestion was to just ditch bare OP_CHECKMULTISIG
>> outputs given that the sigops limit and the way they use up a fixed 20
>> sigops per op makes them hard to do fee calculations for. They also make
>> it easy to bloat the UTXO set, potentially a bad thing. This would of
>> course require things using them to change. Currently that's just
>> Counterparty, so I gave them the heads up in my email.
> 
> I've spend some time looking at the Datacoin code, and I've come to the 
> conclusion the next copycatcoin I release will have an explicit 'data' 
> field with something like 169 bytes (a bakers dozen squared), which will 
> add 1 byte to each transaction if unused, and provide a small, but usable
> data field for proof of publication. As a new coin, I can also do a
> hardfork that increases the data size limit much easier if there is a
> compelling reason to make it bigger.
> 
> I think this will prove to be a much more reliable infrastructure for 
> proof of publication than various hacks to overcome 40 byte limits with
> Bitcoin.
> 
> I am disclosing this here so the bitcoin 1% has plenty of time to evaluate
> the market risk they face from the 40 byte limit, and put some pressure to
> implement some of the alternatives Todd proposes.
> 

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Compact SPV proofs via block header commitments

[Mark Friedenbach]

effect on SPV proof sizes, as the compact proofs scale logarithmically
with the number of blocks.

Finally the most important and driving use case: symmetrical two-way
pegging between bitcoin and side-chains is made efficient enough to be
reduced to practice by the availability of compact SPV proofs[1]. The
compact SPV proofs allow both the necessary proofs-of-spend and
proofs-of-reorg to fit within current blockchain size limitations, and
provide incentives for keeping this data out of the block chain until it
is absolutely necessary.

==References==

This specific compact SPV proof proposal arose from pegging discussion
involving a number of people #bitcoin-wizards: Greg Maxwell, Matt
Corallo, Pieter Wuille, Luke-Jr, Jorge Timon, and Mark Friedenbach. It
is believed that the first explanation of this general idea is due to
Andrew Miller in his 7 Aug 2012 forum post titled "The High-Value-Hash
Highway"[2].

[1]http://sourceforge.net/p/bitcoin/mailman/message/32108143/
[2]https://bitcointalk.org/index.php?topic=98986.0
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTJy/eAAoJEAdzVfsmodw4zC4P/izBRTutwypwQ70TxPxxHYfH
I4QOpf+MgWHxrD+DKKyqkC2icgUBQz96K1vEhA86PrmK8DITs5yGHLSw7CEF/rlG
hZErVY65IpowPt+JnlwOqHcqaoJ277s+4qpd/D9F7L1ROAMUDzzonf7V1Znr/fax
lL4b8whfUI5jeRQby/tMiGPUB/1YJcbGmFccTW9gkGWMvoqZiiXcW7ZKuLrq5tbW
RFIsrSt7rv3D0Cp2Fiyaxnryr2F0QOTqahHLn50+585eHpVFrA9A5T6xiBcEMzlQ
l5cHRZb+lVIktWuYomBiqWljPLo5qercVDrehIq9FFSYuJqzudNx9ZXrpF1ZR4in
UfZvlYqMFO/ZOTG33JWeeMonKlVwfHH2WreggzSq/JD/cH8dUj63A266Gaf6cl83
vEfhgVBDTXZnl5H9Z7wymja6R9m9Eo/Xf+GwRV4vyx1b9gcZXML4Zm4bTp4EXFHA
StBGrYKmMpEb/gguk/hxJLsm0i9pVaQpMC0u3kClHTA5o0IFF9F5+mVjOb59HlDX
AQx96TSwJzhl0l0jcxYye8bXmZFJvpzpsKRPwNISllLEagjplwK2Ub8q5du27lH5
R2qukcso6N5weGggUu1f7NrqcBALdz4E80SSpwu4YtJ6wdI4zsypaq4leqbSRSKh
/hLKeOV5fEGNmwTtrDmN
=j9cm
-END PGP SIGNATURE-

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] moving the default display to mbtc

[Mark Friedenbach]

A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude
numbers in both Chinas, Thailand, and other economically important East
Asian countries. Expect to pay hundreds of rupees in India, or thousands
of rupees in Indonesia.

This concept that money should have low, single digits for everyday
prices is not just Western-centric, it's English-centric. An expresso in
Rome would have cost you a few (tens of?) thousand lira in recent
memory. It was pegging of the Euro to the U.S. dollar that brought
European states in line with the English-speaking world (who themselves
trace lineage to the pound sterling).

No, there is no culturally-neutral common standards for currency and
pricing. But there are ill-advised, ill-informed "standards" in
accounting software that we nevertheless must live with. These software
packages do not handle more than two decimal places gracefully. That
gives technical justifications for moving to either uBTC or accounting
in Satoshis directly. An argument for uBTC is that it retains alignment
with the existing kBTC/BTC/mBTC/uBTC conventions.

However another limitation of these accounting software practices is
that they do not always handle SI notation very well, particularly
sub-unit prefixes. By relabeling uBTC to be a new three-digit symbol
(XBT, XBC, IBT, NBC, or whatever--I really don't care), we are now fully
compliant with any software accounting package out there.

We are still very, very early in the adoption period. These are changes
that could be made now simply by a few big players and/or the bitcoin
foundation changing their practice and their users following suit.

On 03/14/2014 07:49 AM, Andreas Schildbach wrote:
> How much do you pay for an Espresso in your local currency?
> 
> At least for the Euro and the Dollar, mBTC 3.56 is very close to what
> people would expect. Certainly more familiar than µBTC 3558 or BTC
> 0.003578.
> 
> Anyway, I was just sharing real-world experience: nobody is confused.
> 
> 
> On 03/14/2014 03:14 PM, Tamas Blummer wrote:
>> You give them a hard to interpret thing like mBTC and then wonder
>> why they rather look at local currency. Because the choices you
>> gave them are bad.
>>
>> I think Bitcoin would have a better chance to be percieved as a
>> currency of its own if it had prices and fractions like currencies
>> do.
>>
>> 3.558 mBTC or 0.003578 BTC will never be as accepted as 3558 bits
>> would be.
>>
>>
>> Tamas Blummer Bits of Proof
>>
>> On 14.03.2014, at 15:05, Andreas Schildbach 
>> wrote:
>>
>>> btw. None of Bitcoin Wallet's users complained about confusion
>>> because of the mBTC switch. In contrast, I get many mails and
>>> questions if exchange rates happen to differ by >10%.
>>>
>>> I suspect nobody looks at the Bitcoin price. It's the amount in
>>> local currency that matters to the users.
>>>
>>>
>>> On 03/13/2014 02:40 PM, Andreas Schildbach wrote:
 Indeed. And users were crying for mBTC. Nobody was asking for
 µBTC.

 I must admit I was not aware if this thread. I just watched
 other wallets and at some point decided its time to switch to
 mBTC.


 On 03/13/2014 02:31 PM, Mike Hearn wrote:
> The standard has become mBTC and that's what was adopted.
> It's too late to try and sway this on a mailing list thread
> now.
>
>
> On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe
> mailto:g.r...@froot.co.uk>> wrote:
>
> The MultiBit HD view is that this is a locale-sensitive
> presentation issue. As a result we offer a simple
> configuration panel giving pretty much every possible
> combination: icon, m+icon,  μ+icon, BTC, mBTC,  μBTC, XBT,
> mXBT,  μXBT, sat along with settings for leading/trailing
> symbol, commas, spaces and points. This allows anyone to
> customise to meet their own needs beyond the offered default.
>
>
> We apply the NIST guidelines for representation of SI unit
> symbols (i.e no conversion to native language, no RTL giving
> icon+m etc).
>
> Right now MultiBit HD is configured to use m+icon taken from
> the Font Awesome icon set. However reading earlier posts it
> seems that μ+icon is more sensible.
>
> Let us know what you'd like.
>
> Links: m+icon screenshot: http://imgur.com/a/WCDoG Font
> Awesome icon:
> http://fortawesome.github.io/Font-Awesome/icon/btc/ NIST SI
> guidelines: http://physics.nist.gov/Pubs/SP811/sec07.html
>
>
> On 13 March 2014 12:56, Jeff Garzik  > wrote:
>
> Resurrecting this topic.  Bitcoin Wallet moved to mBTC
> several weeks ago, which was disappointing -- it sounded like
> the consensus was uBTC, and moving to uBTC later --which will
> happen-- may result in additional user confusion, thanks to
> yet another decimal place transition.
>
>
>
> On Sun, Nov 17, 2013 at 9:28 PM, Wendell  > wrote:
>> We're w

Re: [Bitcoin-development] moving the default display to mbtc

[Mark Friedenbach]

This ship may have already sailed, but...

Using milli- and micro- notation for currency units is also not very
well supported. Last time this thread was active, I believe there was a
suggestion to use 1 XBT == 1 uBTC. This would bring us completely within
the realm of supported behavior in accounting applications.

On 03/13/2014 09:29 AM, Jeff Garzik wrote:
> On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner  wrote:
>> Of course, as Mike said, this ship may have already sailed, but if
>> there's any way to revisit this, I'm there.  We're just about to do
>> another Armory release and could support this very easily.
> 
> mBTC now just means the issue -will- be revisited in the future.  Just
> a question of when, not if.
> 
> People and software in various nations handle big numbers for small
> values (e.g. Yen) just fine.
> People and software do -not- handle extra decimal places well, field
> experience shows.
> 
>   To roll out QuickBooks support --without converting
> any numbers, a key financial attribute-- mBTC is simply insufficient
> today, not in the future.
> 
> I also argue that it is a security risk, as follows:  To support
> accounting packages limited to 2 decimal places, decimal point
> conversion must be performed.  This produces a situation where your
> accounting system shows numbers that do not visually match the numbers
> in the bitcoin software.  That, in turn, making auditing more
> difficult, particularly for outsiders.
> 
> Shipping with mBTC defaults was decidedly unwise, considering that --
> like BTC -- it fails to solve existing, known problems that uBTC can
> solve, and considering the inevitable mBTC->uBTC switch.
> 

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

[Mark Friedenbach]

Only if you view bitcoin as no more than a payment network.
On Mar 1, 2014 10:24 AM, "Jeff Garzik"  wrote:

> This is wandering far off-topic for this mailing list.
>
> On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes  wrote:
> >> > You can make the same argument against Bitcoin itself you know...
> >> >
> >> > A Bitmessage-like network would be trivial to front-run via a sybil
> >> > attack. It's the fundemental problem with marketplaces - the data
> >> > they're trying to publish has to be public.
> >>
> >> I don't see the Bitcoin analogy...
> >> Anyway, I still don't think the seller cares, if he sells at the price
> >> he was asking, what would he care about "front running" those parallel
> >> networks.
> >> I've seen many street markets without "public information" and they
> >> work just well.
> >
> > The spot price for ammonia fertilizer, refined gasoline at terminals,
> > and price of tea in china are not 'public information', yet these are
> > some of the largest traded commodities in the world, far exceeding
> > the drop in the bucket that all cryptocoin transactions make.
> >
> > I'd further argue that the *actual* price of corn (cash bid price at
> > elevators and ethanol plants) is not public information either. There
> > is a great deal of money traded in collecting and then distributing the
> > 'cleared price' information. Have a look at
> >
> http://www.interquote.com/template.cfm?navgroup=aboutlist&urlcode=12&view=1
> >
> >
> >> >> I don't think this will be a tragedy, because like we discussed on
> >> >> IRC, I don't think the primary goal of markets is price discovery,
> but
> >> >> trade itself.
> >> >>
> >> >> About historic data, the actual trades are always public, and some
> >> >> kind of "archivers" could collect and maintain old orders for
> historic
> >> >> bid and asks, etc.
> >> >
> >> > And again, how do you know that record is honest? Fact is without
> >> > proof-of-publication you just don't.
> >>
> >> Well, the trades that appeared in the chain actually occurred.
> >> Buying to yourself at fake prices? Be careful, the miner could just
> >> separate the order and fill it himself. Or anyone paying a higher fee,
> >> for that matter.
> >
> > You just made my long-term strategic argument for investing in my own
> > mining hardware so I can be sure to trade reliably.
> >
> >> Again, you haven't addressed why the seller cares more about "accurate
> >> historic market data" than just his own fees and sell.
> >>
> >> > You mean a reverse nLockTime that makes a transaction invalid after a
> >> > certain amount of time - that's dangerous in a reorg unfortunately as
> it
> >> > can make transactions permenantly invalid.
> >
> > People who take money from buyers and sellers care most about 'accurate
> > historic market data'. I just want to exchange my corn for e85,
> fertilizer,
> > and electricity, and audit the code that runs accounting for the
> exchange.
> >
> > I really don't give a shit if there is 'accurate historic market data' as
> > long as **MY** personal trade data is accurate and I got a good enough
> price,
> > and I know who I'm dealing with.
> >
> > I know someone smarter than me and with more money, market leverage, and
> > political connections **WILL** game the system and distort the market
> data
> > history so they can take more money from buyers and sellers without
> actually
> > doing some usefull market function.
> >
> > As long as use buyers and sellers can see the code, and have a good eye
> for
> > knowing when someone's pushing the market around, we can just put our
> orders
> > in and relieve some speculators of their money.
> >
> > Just get me working code for cross-chain trades, and we'll work on the
> > accurate historic data problem later.
> >
> >
> 
> > Troy Benjegerdes 'da hozer'
> ho...@hozed.org
> > 7 elements  earth::water::air::fire::mind::spirit::soul
> grid.coop
> >
> >   Never pick a fight with someone who buys ink by the barrel,
> >  nor try buy a hacker who makes money by the megahash
> >
> >
> >
> --
> > Flow-based real-time traffic analytics software. Cisco certified tool.
> > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> > Customize your own dashboards, set traffic alerts and generate reports.
> > Network behavioral analysis & security monitoring. All-in-one tool.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> > ___
> > 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/
>
>
> --

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Transaction fees are a DoS mitigating cost to the person making the
transaction, but they are generally not paid to the people who
actually incur costs in validating the blockchain. Actual transaction
processing costs are an externality that is completely unpaid for.

When I add a 1Kb transaction to the blockchain, there is an attached
fee which probabilistically goes to one of the miners. But every other
full node on the network also receives this transaction, processes it,
and adds it to local storage. From now until the heat death of the
universe that 1Kb of data will be redundantly stored and transmitted
to every single person who validates the block chain. None of these
countless people are reimbursed for their storage, bandwidth, and
processing costs. Not even a single satoshi.

Yes, transaction fees are broken. But it is their very nature which is
broken (sending coins to the miners, not the greater validator set),
and no little tweak like the one Warren links to will fix this.

But, in the absence of a reformed fee regime - which it is not clear
is even possible - one could at least make the hand-wavey argument
that people who validate the block chain receive benefit from it as a
payment network. Therefore processing of the block chain is "paid for"
by the utility it provides once fully synced.

However even this weak argument does not extend to general data
storage. If you want to put all of wikileaks or whatever in the block
chain, then you are extracting a rent from every full node which is
forced to process and store this data for eternity without
compensation or derived utility. You are extorting users of the
payment network into providing a storage service at no cost, because
the alternative (losing bitcoin as a payment network) would cost them
more.

That is not ethical behavior. That is not behavior which responsible
developers should allow in the reference client.

Mark

On 02/28/2014 06:42 AM, Warren Togami Jr. wrote:
> On Thu, Feb 27, 2014 at 7:25 PM, Troy Benjegerdes  > wrote:
> 
> 
> Either the transaction fees are sufficient to pay the cost for
> whatever random junk anyone wants to put there, or they are not,
> and if they are not, then I suggest you re-think the fee structure
> rather than trying to pre-regulate me putting 80 character pithy
> quotes in the blockhain.
> 
> 
> https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d
>
>  In one way in particular, the transaction fees per kilobyte
> completely failed to account for the actual cost to the network.
> If Bitcoin had adopted a common-sense rule like this, I would have
> had no reason to join Litecoin development last year.  This is one
> of the few economic design flaws that Satoshi overlooked in the
> original design.
> 
> As much as I personally hate the idea of data storage in the
> blockchain, this at least discourages the creation of permanent
> UTXO.
> 
> Warren Togami
> 
> 
> --
>
> 
Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow
> Analyzer Customize your own dashboards, set traffic alerts and
> generate reports. Network behavioral analysis & security
> monitoring. All-in-one tool. 
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
>
> 
> 
> 
> ___ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTEOKjAAoJEAdzVfsmodw4vGIQAJ9OQvHl1+dIaDelrf03lGIf
kQsiuB4JG1rRghsZZiW4NixPbB/Bdm4+m4pep01eiVOPXa+/32AgWVzSYyyMVRYB
oTu24ITgtCu5vkjiHyzSavFnqsi+zMxVpscUekA6l6Tkr3RBNnrIssMiazYc+Bkx
fP2vZehmPHQtp09WkapZ3DMqbMzQ7qPTGlKd1V+9X4S5uUNTdfT6JkC0HIqUSdVQ
PHjjbuulgkdz4b7A6C2dE5kwXVKF9YFHL3zEtObfWDCiyY8wf2XHYI6nVGLbyQeN
nrYCsMH99lUy+zmnbccqSPKhe0p5IaBLauk75zcLxEfzxuKVTvVg2LCaCXQaworv
vBoAURdrB2pCfK8dZ7mllVLLLcNk+iOG0NDZHYE9e884OBfeuaG/zNgmgOD8GC1H
FaDkIpm79x/i3ti3h8vdZPeY0fWdI8yuD9aCQZtvONM9hXdd7Qb07eHqIk7tY/In
7h6zdq27GQUdWN37yslxtDENY2q3yQ39+fjMGQEKVIE6rNwDyjurMCNHAWJp0hZO
7S/rDe2W2tHGPYakscHQh1g/uMAEEb4mGGc5yrfWxyOn5eb9OZiZb8RVXlnDwwH9
qr8qwLJ1b0Uxo981lyEmnLZSpCpAZvDLpjmocqirycNZpvyPnJJbE809vS/koD3d
OutJkMja4TBuqaMSdKEI
=KbW/
-END PGP SIGNATURE-

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://p

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

OP_RETURN outputs are provably unspendable *and* not included in the
UTXO set, so they're not dust (the client makes this check and handles
TX_NULL_DATA outputs separately).

On 02/24/2014 10:13 AM, Tamas Blummer wrote:
> It costs at least 5430 satoshis to create an output at the moment.
>  Is the same spam limit applied if the script is OP_RETURN? If not,
> I would be concerned od opening a cheap spam.
> 
> Tamas Blummer
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTC8lNAAoJEAdzVfsmodw4vpAP/1/wJFRq9x3rhETtUlS/3+F3
UrgBhfNDP7rq1P9wqZm20cssF0VcG+SVG94m/kH/H8cfJsjGB3/NW2IGxf9J6wOT
vWiGqz4b7lkh5nywBe0TK0smkqMFtyNAESX1WdJpdNLAd5OK/wj2X7Dl3/r7K9tk
SN1Oi4nlQD+GkbQBNeqf659BKlFAIYONl9SrPXvrEoSuTm0CjFLsST3Go3El0tyx
rLrApXCAR+iGs9bZONdkC3rRWGGa3V8HLNeCyBaLA7dsipnk2kMsjbrLB9NZU54L
Dz07e1oelFJErsbYKD+AQy3KiZ4+7dZRoi9FtPqlXtCGAObW0fi5Rm2HDzCG+iMU
f+6xgCCyyP++fET/EnJj1Jxjrn6suoAl2hjZLpaGgJ67lsxq5rqmXetID5X+cGRU
HX6Ar5+LIjRixfoCF3dJoZT0Ko1S0b58oRzyapwbB+2Fi0/G7ujEwErWE33ARXad
vTYznlAXG5YzIrjAJUF3PG3MlbaX4TWywJxRCMRcTQC7Ak+dP2cdOBuzvLdAsYXG
xcmqfl3ETH5xLxLWYnzNplTkt9ENs8UHrG0StWOyCg4+MG8yC/jPFp6qzRlAaZEv
vFsIPGD+jzftrqBQ1GgjbG8bofUYCMnYRKQtQ377GNw8s8wVASb8CxyI8yhXKpdv
zdCwIlvHM0A8CofmDDot
=6Jux
-END PGP SIGNATURE-

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

[Mark Friedenbach]

Given our standardization on 128-bit security / 256-bit primitives, I
can't think of any crypto related data payload which requires more than
40 bytes. Even DER encoded compressed public keys will fit in there. A
signature won't fit, but why would you need one in there?

There's no need to design for 64-byte hashes, and the 80-char line
length comparison is a good point. As an Engineer I'd want to have a
little more room as a 32-byte hash or EC point + 8 bytes identifying
prefix data is the bare minimum, but it is also very important that we
send a message: This is for payment related applications like stealth
addresses only. Don't burden everybody by putting your junk on the block
chain.

On 02/24/2014 08:39 AM, Wladimir wrote:
> 
> On Mon, Feb 24, 2014 at 5:03 PM, Jeff Garzik  > wrote:
> 
> A common IRC proposal seems to lean towards reducing that from 80.
> I'll leave it to the crowd to argue about size from there. I do think
> regular transactions should have the ability to include some metadata.
> 
> 
> I'd be in favor of bringing it down to 40 for 0.9.
> 
> That'd be enough for <8 byte header/identifier><32 byte hash>.
> 
> 80, as the standard line length, is almost asking for "insert your
> graffiti message here". I also see no need for 64 bytes hashes such as
> SHA512 in the context of bitcoin, as that only offers 256-bit security
> (at most) in the first place.
> 
> And if this is not abused, these kind of transactions become popular,
> and more space is really needed, the limit can always be increased in a
> future version.
> 
> Wladimir
> 
> 
> --
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> 
> 
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Base-32 error correction coding

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

What follows is a proposed BIP for human-friendly base-32
serialization with error correction encoding. A formatted version is
viewable as part of a gist with related code:

https://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki

An implementation of this BIP and associated APIs is made available as
a pull request, with comprehensive testing:

https://github.com/bitcoin/bitcoin/pull/3713

This format is anticipated to be useful for helpdesk-related data
(e.g. the proposed normalized transaction ID), and future wallet
backup & paper wallet serialization formats.


== Abstract ==

The BIP proposes an human-centered encoding format for base-32 data
serialization. It differs from the presumptive default hexadecimal or
base58 encodings in the following ways:

1. Visually distinctive in that it includes the full range of
alphanumeric digits in its base-32 encoding, except the characters 0,
l, v, and 2. which are too easily confused with 1, i, u, r, or z in
font or handwriting.

2. Automatic correction of up to 1 transcription error per 31 coded
digits (130 bits of payload data). For a 256-bit hash or secret key,
this enables seamless recovery from up to two transcription errors so
long as they occur in separate halves of the coded representation.

3. Highly probable detection of errors beyond the error correction
threshold, with a false negative rate on the order of 25 bits, or 1 in
33 million likelihood.

4. Case-insensitive encoding ensures that it may be displayed in an
easier to read uniform case, and it is faster and more comfortable to
vocally read off a base-32 encoded number than the alternatives of
hexadecimal or base58.

In addition to the error correction code transformation of base-32
data, a padding scheme is specified for extending numbers or bit
vectors of any length to a multiple of 5 bits suitable for base-32
encoding.

== z-base-32 ==

The bitcoin reference client already has one implementation of base-32
encoding following the RFC 3548 standard, using the following alphabet:

const char *pbase32 = "abcdefghijklmnopqrstuvwxyz234567";

For error correction coded strings this BIP specifies usage of Phil
Zimmermann's z-base-32 encoding alphabet[], which provides better
resistance to transcriptive errors than the RFC 3548 standard:

const char *pzbase32 = "ybndrfg8ejkmcpqxot1uwisza345h769";

The same RFC 3548 coder is used for z-base-32, except that unnecessary
'=' padding characters are stripped before performing the alphabet
substitution. For example, the hexadecimal string 'ae653be0049be3' is
RFC 3548 encoded as 'vzstxyaetprq', and z-base-32 encoded as
'i31uzayruxto'.

== CRC-5-USB error correction coding ==

Herein we describe an error correction encoding using cyclic
redundancy check polynomial division[], which requires 5 error
correction digits per 26 digits of input, instead of the theoretically
optimal 4, but is much, much easier to implement correctly then
available non-patented error correction codes. Cyclic redundancy check
polynomial division provides a very straightforward, patent-free
mechanism for reliably detecting transcription errors in input, and
performing up to 1-digit corrections per 26 digit block.

=== Encoding ===

The input to this error correction encoder is a sequence of 26 base-32
digits. These digits are decoded into 5-bit unsigned integers with
values equal to their offset into the base-32 alphabet string. If the
input is less than 26 digits in length, it is extended with
zero-valued digits. If For example, the string 'vzstxyaetprq' using
the RFC 3548 alphabet becomes the code point sequence:

<21 25 18 19 23 24 0 4 19 15 17 16 0 0 0 0 0 0 0 0 0 0 0 0 0 0>'
 |--input-|-padding--|

Expositionally it helps to think of this array as a 26-element column
vector of 5-bit binary integers:

<0b10101
 0b11001
 0b10010
 0b10011
 0b10111
 0b11000
 0b0
 0b00100
 0b10011
 0b0
 0b10001
 0b1
 ... 14 zero elements ...>

If we explode the bits of each element into 5, 1-bit columns, we get a
26 x 5 matrix:

<1 0 1 0 1
 1 1 0 0 1
 1 0 0 1 0
 1 0 0 1 1
 1 0 1 1 1
 1 1 0 0 0
 0 0 0 0 0
 0 0 1 0 0
 1 0 0 1 1
 0 1 1 1 1
 1 0 0 0 1
 1 0 0 0 0
 ... 14 x 5 zero elements ...>

The array is then transposed, such that we get a 5 x 26 matrix where
each row represents the 5th, 4th, 3rd, 2nd, or 1st bit, respectfully,
of each element:

<1 1 1 1 1 1 0 0 1 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 1 0 0 0 1 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 0 0 1 1 1 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
 1 1 0 1 1 0 0 0 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>
 |-input|--padding-|

We then use each of these rows separately as input into a cyclic
redundancy check polynomial divisio

Re: [Bitcoin-development] working with the blockchain: transaction fees & sum(inputs) != sum(outputs) (newbie questions)

[Mark Friedenbach]

Still straightforward: get a list of transaction hashes for the block
from bitcoind, then query these transactions from the UTXO changestate
database.

On 02/14/2014 12:56 PM, Denis Andrejew wrote:
> Thanks Wladimir, perfect info!
> 
> Mark, sounds good. But most likely this DB is keeping this
> information only for the current state of the blockchain and what I
> need really is to be able to get the unspent outputs (and calculate
> the balance for all addresses) for any particular block I happen to
> be interested in :)
> 
> - Denis
> 
> "Be the change you want to see in the world." (Mahatma Gandhi)
> 
> 
> On Fri, Feb 14, 2014 at 5:42 PM, Mark Friedenbach
> mailto:m...@monetize.io>> wrote:
> 
> On 02/14/2014 04:20 AM, Denis Andrejew wrote:
>> What I'm trying to do is read the blockchain in order to find
>> all unspent outputs. I'm using bitcoind via rpc as my source of 
>> information about the blockchain.
> 
> By the way, bitcoind keeps this information in a special LevelDB 
> database in the chainstate directory. It would be rather simple to 
> iterate over the database for the list of al unspent outputs.
> 
> 

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

[Mark Friedenbach]

On 02/12/2014 08:44 AM, Alan Reiner wrote:
> Changing the protocol to use these static IDs is a pretty fundamental
> change that would never happen in Bitcoin.   But they can still be
> useful at the application level to mitigate these issues.

Not to mention that it would be potentially very insecure to have
consensus depend on data (scriptSigs) which are not hashed in the Merkle
structure of a block.

Not that anyone on this list has suggested such a change, but I've seen
it raised multiple times on the forum

Mark

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP0039: Final call

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Proper Unicode handling is a serious issue however. You don't want
someone to move from one input method / machine to another and
suddenly find that their coins are inaccessible, because of an issue
of decomposed vs. compatibility forms or whatever.

On 01/20/2014 03:14 PM, Adam Back wrote:
> Because the mnemonic is an encoding of a 128-bit random number
> using its hash as a private key (or derived part of one) is not a
> problem, its just an alternate alphabet encoding of the random
> private key.
> 
> Not being able to generically understand the checksum.  Seems
> tricky to solve other than say brute force eg H(mnemonic||1) mod
> 2^k == 0 where k is the amount of check digit redundancy.  But that
> might be expensive for a trezor if k is very big at all.  And then
> key = H(mnemonic).
> 
> Adam
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS3a7MAAoJEAdzVfsmodw4/MAP/3Rk4sbQBv5aGqM2iAMBZkjq
CxGNSrzxKKgAYf+aFka6FVrBZJRHU39mEon53H0DR92+3vA2BHns8YEKH18LneQ9
16qJAp4y+ml5jbdCI6TY1JCM4ObmXsZbsPF17lKdVPISkz8DhUMUNLHdOx8cZHkw
Kj5RXuLBFwqFiCcAqYdoIpFmDpfaJfZ3k9OHzPRsto1oyOrXdwc+TK8YZHISWR3M
nzsMcp2z9Uu8M/NeDo4gM0WFpIZ41W9JsYeMeJzdU6xd1HKdmC0CZCyc8EmAre58
XGc2gtc9PjXIwWW+FTkZ5pYJz718WBq4Wja1hir5eaTJZurs1fp+1iJ7jiDkloJH
h/pWp8wcXVaAklaImota3PASr5qnP8zjzaKZALn/0gJEkIKnIJz3N32BLw7QsoEL
k5VaMQ5x7/9zK+Qc5kWvtTjleRO23DnW+XVud0jbAHTM1wfTQH0dJIgEpe3HQZOR
9a09/ZKN8kC+2fj/u6EjkVh5RvwTv0iq+RvBDmsFjaVOfBzRL1LVKgKJvdG+0hix
XyPtnBflC1uNLNg/yjBEP7/cKePJVMcDzVBwjpbnEOo9ZGO2ixSh8qMQ/nn6V96R
hZZv8mVI1bGhWlvQEoMw5X7M4xyP25GboCv4wJrYT/8VQfe56BSKXS+AHfl+hIoa
Jjmcqvm+sfk/0awxj4Ce
=1crJ
-END PGP SIGNATURE-

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP0039: Final call

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Since you are taking the hash of Unicode data, I would strongly
recommend using a canonical form, e.g. Normalized Form C.

On 01/20/2014 09:42 AM, slush wrote:
> Hi all,
> 
> during recent months we've reconsidered all comments which we
> received from the community about our BIP39 proposal and we tried
> to meet all requirements for such standard. Specifically the
> proposal now doesn't require any specific wordlist, so every client
> can use its very own list of preferred words. Generated mnemonic
> can be then applied to any other BIP39-compatible client. Please
> follow current draft at
> https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
> 
> Because we're quickly moving towards release of Trezor firmware and
> we need to finalize this part of the firmware, we're asking for the
> last comments to current BIP39 draft.
> 
> Thanks, slush
> 
> 
> --
>
> 
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For 
> Critical Workloads, Development Environments & Everything In
> Between. Get a Quote or Start a Free Trial Today. 
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>
> 
> 
> 
> ___ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS3ZzAAAoJEAdzVfsmodw4L3sP/2VjvICLTYlkZcY6brBIZhoU
P6ei6qECzmBCWpW5iC1r99j76bPwP3M6jH6P7iBljj72J5NgHXq+K8GvA5M6qu0o
6s+WJ7HYJ8KwRZuvGPvcopXBKJAJXadrN7xSPikYD2zMm2KCZTUI5IurR1p/dpUR
3HzL2RdjbDugBOiAjiMMq0dAs1x9/vmF0F2KDZHiCJEtP/+gbtOE/KmXrnrAJSNI
Aswb/lZg1GWGpOs+iCdEaRfST2PIL/jGgnteJ4iKHvh2+dOW0/AhINo5g56LTVvU
Q+pAv8SRLad/30PVaWAStrtLMxu+j0JQ1wgEkRCrsQ0xE3iKtmbppzh2dIQ8Idrt
EkjqoykB2wn4Kw+QcT2TXIcBV7LBqSurE/jDWWIFtHxdV0++8PDYFOesq2Xf9Rif
VStYnUVvUhuzGXD3oOnIGpEvMm2i30Qyi33oJLvqfWUBkzJzFdtZ+YYBYlbpwBOQ
YLEr2DmVHLk/MXWL1POruvnIT4N+6uyh59HKHKRJI0nGMmRR3cBLkM8vEEHerD3P
ucg++TTdqXM6XoSmIk55CQnGdglDJEOGc+gzaGffqeDMJhmz/apEawN5en7ogN0o
XfWDWSdtwMvlza3F6cMejvBkuFZTLUxyaedP13vOTDhUIbmqsliyhwA2YrXE7udQ
1JMYADuvb18LYE/hQJX3
=Ycdc
-END PGP SIGNATURE-

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

[Mark Friedenbach]

On 01/18/2014 03:05 AM, Wladimir wrote:
> On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla
> 
> 
> 
> regarding:
> stuff not getting into blockchain in a day's time,
> microdonations not facilitated as much as they could be,
> 
> Please point to your pull requests improving these issues.
> 
> If your organization didn't contribute anything to further these issues
> then there can't be much surprise that they didn't make it in, either.

https://github.com/bitcoin/bitcoin/pull/1647

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CPFP is *extremely* important. People have lost money because this
feature is missing. I think it's critical that it makes it into 0.9

If I get a low-priority donation from a blockchain.info wallet, that
money can disappear if it doesn't make it into a block in 24 hours -
bc.i will forget the transaction and happily respend its inputs on the
next transaction that user makes.

I wouldn't mind paying $1 in fees to receive a $50 donation. But
without CPFP there's no way to do that.


On 01/17/2014 12:53 PM, Jeff Garzik wrote:
>   BitPay sure would like to see CPFP in upstream.
> 
> I think the main hurdle to merging was that various people
> disagreed on various edge case handling and implementation details,
> but no fundamental objections.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS2ZrQAAoJEAdzVfsmodw4CrwP+gM2iXLcvQK2VlhoN7kRCnvH
+YJ87fXlMl0IcRqVDyaCF6w3+U/9VG+p+/eFvBNzxMMTbylWbsSXF6GxavwPhVt4
zw//VNLIfOu+88HsUofamvZJGHQOArwzlOYRgX1Lr9ms3KSQ2QWkW+Z6QD7qmkO2
bJNzxJ+vffmz24mQ6hg7a33YW+403TbeqxcPewbjNr76hvPEjzlTPhpVo4A/gqSu
6rcJPQIkFdTZX/xy5hyZsQzswNv/bYyrE9XhEIimsqt96sjTDrB4EZKzfkQ/jLeP
fudEcGEvRzJL9BSsa6mfUBzct2ilpii33q1vIIVYfIQIJmYl7U6YubloT235l2C7
0v0RWn5Kux2R9B4YFKjR09Jc2273mrnGuUj7hKD0LPHfn/Jzxy1Ce4AIcaodlgwP
u7vpvWiVEUcJkl3rn3enAyKCtD7zqe4k73ALq4yWjnDZRFEQ9DJEdEPEy+H8HlXY
RFOtFxAr/Vdyp9STAgjve46M4g/Qc5C10qIueTyJO1h8XDPfV8HnZJNVJP3wtj0K
pC5vq7ADxkQ60F9w+vNEdo85AVWhITQ/Kq7dbSq5J1LxddivzRurnp2uX+U2LEkV
9Hd2HuIM7E4uR0JZKRqPsFCJrpBuI4YPGHQB5pbq9eYAG4BdmTwTXUvd2FacI3mL
beN/c4m26MKQJTiMQyTl
=u7Qb
-END PGP SIGNATURE-

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Stealth Addresses

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/17/2014 01:15 AM, Mike Hearn wrote:
> I must say, this shed is mighty fine looking. It'd be a great place
> to store our bikes. But, what colour should we paint it?
> 
> How about we split the difference and go with "privacy address"?
> As

Too close to private key, IMHO.

> Peter notes, that's what people actually like and want. The problem
> with stealth is it's got strong connotations with American military
> hardware and perhaps thieves sneaking around in the night:

And ninjas.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS2PWHAAoJEAdzVfsmodw4QKoP/iCB62bthf+VyOAZFtP/LbU3
op//I06zOd6oj3zSM0B3Qwz0+H3L9OqWeo9yP1KzYb8YG7RelGf6KOh0LBQoo0bY
eEv8EqvJiW0JOi7gmMsaBgxtZ99TKibGVWMramAV+pSOkKbbbQ23O8a3Y2uopZIg
eypB9sUO9STTc/vwEKZRtefoXHWDUF8bXel/YfTGJQjOuxN/z6gsXRPp4xDvySL3
Ll3OvgEGrqIjIodvMZY+V5wzxj/TlU5kCKS6Vug/JEM1U0DmiBBikaR6Yus5m/fC
yyxEQH8jATLZVsAac4Z16rQXj1nTRh4w6X9KCTynEaba5Z8fz38habUNxyjT8JG+
cP+QDQac9Nnxuw6gzM4QRkOiQas5eVNRdzNJ48k2SGDLb7AYPBO/URAV8Cd05caY
Gx1ruC3MVGu7Fu1/9rtKeWMcNyAvpklzs9DhHfqNmYcRCl6NcoaCvxfq3NesI4Z9
uQrTfL9VBUXJJ2z8ZLe3ZAdBz46159JXCBKHIWwZ+fm0uPkelvoUo8oP+OdxwP1x
wGCYmfvuf8lSnud8WM5EDDGo4+7GUU5Pnh9p+o6Lyp4d0WoplUmSvz2XriiANQjq
z/Xo3B321sdLOEI/Nrqnn3S/hMveru7HO7xQx1aUATvYga4ZyFZh/Yp0bwOAESBZ
GoG0piwQbQhoQZMslV4T
=40o3
-END PGP SIGNATURE-

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Stealth Addresses

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/15/2014 04:05 PM, Jeremy Spilman wrote:
> Might I propose "reusable address".

Say it like it is. This is the only suggestion so far that I really like.

No amount of finger wagging got people to stop using the block chain
for data storage, but news of the OP_RETURN change to relay rules in
0.9 got people to at least be less damaging in how they do it.

Having an officially named "reusable address" format won't stop people
from doing dumb things (e.g. vanity addresses), but at least maybe
they'll stop using traditional addresses for it.

Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS1yafAAoJEAdzVfsmodw40ccQAI0EFAyODzx7yXvlq9idctSd
xisH4xsOMlsW4lV7xReMnhQsCZ5A+qTMcCd7n7a0bveAxWg1srqBDONLXtHZfwiN
Px/TfoJKPt1oIHnCoyN8G6pcuHhbUbL3lV19sH02dGnM9Ystf9F4oeqwDTITYb5i
huqShMfaTdLEig76zPCLQcOT88deIWZgIxc3R4Do4aCDoyh//2LVZKfzQyEJzVms
njgxcVLVRlomofPW+a+60zm/iLsrbmDjwvWSH8IB4d5ik1aO3732pWgNz3X4HSLk
1s9hVEnpN3GLIWmCcPkbrE9RZtcitghjwrt/xOMKQaqprUuFW4COc0fsfzdLIRtP
bhrA/dnhVSxiUnjc7gLJBnB9+udVKdk2aTdJvSMB1PvhW9QKPjU/H4AW/yQYmism
rSr9imurbi3WosTewtwdcQD47SNS4ALMh//3MeHWOBUMEHP7Tki6i8qR+/xOK+vx
zMc4dnnTQsbgu9bKhrU7ia4eoe/UDvPoLck5cb2+PwYTInfdYBWn1ivbHO7S5ppP
R+/Tc8h3TyLLcPQmH0tpSX+C/YwvctiGsd+iXBRfSTe7o+0wLn8NcDNGi7QI0ipQ
iCHJup9K0FJqf9OuH9qYeaWht7cyuRJ5H4P/HNESGZaPSdTHDpStSmAzdtbBZOkI
qrFg7irL2+CxXwI4H6vC
=XEtz
-END PGP SIGNATURE-

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/06/2014 10:31 PM, Thomas Voegtlin wrote:
> You are right. The 256-way branching follows from the fact that the
> tree was implemented using a key-value database operating with byte
> strings (leveldb). With this implementation constraint, a different
> branching would probably be possible but wasteful.

Not really. Just use a suffix to determine the number of bits used in
the final key byte. For example, the string "abc" would have the key

0x61626308 // "abc\x08"

Dropping the final bit would mean masking it off and having a
different terminating value:

0x61626207 // "abb\x07"

That way you keep the lexical ordering of keys necessary for database
iteration, and the efficient binary encoding.

> I see the advantage of doing that, but this looks really
> far-fetched.. My understanding is that it would require a complete
> change in the way clients and miners work. Could such a change be
> brought iteratively?

It is an iterative change, I believe. You might be confusing this idea
with Peter Todd's TXO commitment proposal using MMR trees, which is a
drastic change with its own set of tradeoffs. Just to be clear, here's
what I'm proposing:

1) Restructure the current UTXO index to be a Merkle tree, basically
by splitting coins into individual outputs and adding interior nodes
to the leveldb database.

2) Add hash commitments of this structure to the coinbase.

It's still mapping txid's to unspent outputs, just as before - this
has nothing to do with the script keyed "wallet index." It's just now
nodes can prefix optional proofs to block or transaction messages
which prove by reference to the current best block's hash the spend
status of the inputs of a transaction, or all the inputs of all the
transactions of a block.

If the more expensive proof-updatable hashing is used, then these
proofs can even be composed or "rebased" onto a new block by applying
the contents of an "operational proof" representing the diff between
two blocks / the application of a series of transactions.

This means that a node which does not have access to the UTXO set can
nevertheless receive transactions or entire blocks with prefixed
proofs and check the validity of the transaction with just the
information available (proof + transaction contents).

All that is required after the above soft-fork is a protocol version
update and/or a service bit to indicate the ability to send or receive
proof-prefixed messages. I'd call that an incremental update.

[Aside: adding the wallet index requires storing the entire UTXO set
in duplicated form, indexed this time by scriptPubKey or
H(scriptPubKey), and including proofs of this structure as well. It is
unlikely that any soft-fork would occur forcing consensus over the
wallet index, but it could be done as a meta-chain or as an index
covering just the contents of the block.]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSzKQ2AAoJEAdzVfsmodw4hyoQAJ0f6P3ijZCEw7IPd/RcrmkI
Viv4j17ZyAAcbNUplvjzhr/tIIKYPg51ltvfkp8cGRHgez88QsljzvM8B5n+nbPa
jaaI6eiJ3AU1bR8hWYKtlXFwMvRjyr3ofl8hhTvYptGv9x3/Tr+2FwxIRY0413m6
2h95vItsvBs8v7clqLoBEqx9uyUpsH3+J32V4oGubrNAFXh1oOHi4Ban+TOKYaQV
GHZaIZ3bVAvcMd5riaWSPUPLHwJnxQ8w6SlVRy2UNUPe+9yTuy4n1GW4vk4WHvop
FgZFrM3LBmh1MhlYHRdEUUtwk3mfDuGbfW5UJVMri0Nis1PsXr5VK4qQaMbd/9e6
M2uWKslY9QCnzMajnHen9OwotteAJy2I1KHVcxXb0tFqrvqZ6o/auIe0G4VdKYuI
XfNF3mokX93tiSflmphDba6qgB/W+Y6UD2gG2AeFuMGhFF/Hy62pVC6Zx7PKZ3vL
Kh27rKkO/0FJau2JCQm5xBiQgCnKghqOiHefY3o+l+Y9kJ8fXKWCuwJ0lJ3LxZ2u
8H6sp6Jm9Ct9L90wSn7VmmI5H3bRe8sa7sylH4BR2T6jP3/tKDYTEeNWj+F9FfO1
FxsjYrjAyv1HxYYKd/Y1svEVSsKMv3a2SR9pF36ynBABdFjvx+oEuCyCO4tspFe6
15eA1QoMKvEQe/Ww5kRC
=L9WT
-END PGP SIGNATURE-

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees

[Mark Friedenbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/06/2014 10:13 AM, Peter Todd wrote:
> On Sun, Jan 05, 2014 at 07:43:58PM +0100, Thomas Voegtlin wrote:
>> I have written a Python-levelDB implementation of this UTXO
>> hashtree, which is currently being tested, and will be added to
>> Electrum servers.
> 
> Along the lines of my recent post on blockchain data:
> 
> Is it going to be possible to do partial prefix queries on that
> tree?

There's really two tree structures being talked about here. Correct me
if I'm wrong Thomas, but last time I looked at your code it was still
implementing a 256-way PATRICIA trie, correct? This structure lends
itself to indexing either scriptPubKey or H(scriptPubKey) with
approximately the same performance characteristics, and in the
"Ultimate blockchain compression" thread there is much debate about
which to use.

In the process of experimentation I've since moved from a 256-way
PATRICIA trie to a bitwise, non-level-compressed trie structure - what
I call proof-updatable trees in the BIP. These have the advantage of
allowing stateless application of one proof to another, and as
consequence enable mining & mempool operations without access to the
UTXO set, so long as proofs are initially provided in the transaction
& block wire format.

The "disadvantage" is that performance is closely tied to key length,
making H(scriptPubKey) the much more desirable option. I'm sure you
see that as an advantage, however :)

> Also have you considered creating per-block indexes of all 
> scriptPubKeys, spent or unspent, queryable via the same partial
> prefix method?

This would be quite easy to do, separate from the UTXO structure but
using the same trie format.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSy0iFAAoJEAdzVfsmodw434MQAIA/fDYT7SfMtfLEgDQKhXCn
slRqFEx/HXjvgHHSYnbr9V+8LrGzNvT2ImebbV9ge8VlziAFNGIUq2EYhFs4kHWu
GVm9aL8Jj/27SvM0tRwr9n2XIifKOh2sVINAjbv+UwPv/O+cULU95/b53DEF6aqI
OWxioOR50TPe4t9AevAGVypNLm1DsyDdymhO9xyBN92xGTNj5QKL5hHG3kcsLIl1
7KaxO0w4UC2sdSGj9FeyH1b0zYg8FlzjJHc1CUshHwUwyYo8LRJtRypL5lrayERg
Er/kIGEDovcenNBW8G79l+8VKPfB/lMTssT2pDiQL+1e1fg46CIQxHSyap2JSFTE
jgleRk/+1NK/ZjOQ8dEBPZK3TE1WY3qlm/ekjG/8W5kXqcxzFBoAkeBNXuJ/8UMi
mKe+DTmbp0xnvLO1p+hpugXKfrQSpcFL+ZvJHlFS1lz7O1N3WvuDCNP9El+L6ueM
nFzjr1NTnX0z4vYtscI7qBKVqUrB7Z84c3O/lSYpw4Jilxl4trzV4cn7+AF7KWGM
ktR9JJeIoNcJ2Zx4EpRp6OSwhtLkWZyLpPnidQ2p6ev2ytXpTpGsW/i5XS2w57UD
2IG5E0Q7Xzvd58lI/YollWQcagVOZdyzYXa+wVZoFQ6gLF47andpUmtUJOhI7gxv
T/rWhPhkTMUn8TdvUcV/
=N9zM
-END PGP SIGNATURE-

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development