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

2015-06-19 Thread 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 andr...@petersson.at
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

2015-06-18 Thread Mark Friedenbach
On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn m...@plan99.net 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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Mark Friedenbach
On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com 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

2015-06-18 Thread 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 b...@mattwhitlock.name
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] User vote in blocksize through fees

2015-06-12 Thread 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 p...@petertodd.org wrote:

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

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

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

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


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


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

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


 --

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


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


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

2015-06-06 Thread 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 laa...@gmail.com 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

2015-06-05 Thread 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 ru...@rustcorp.com.au wrote:

 Title: Canonical Input and Output Ordering
 Author: Rusty Russell ru...@rustcorp.com.au
 Discussions-To: Bitcoin Dev bitcoin-development@lists.sourceforge.net
 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}

2015-06-04 Thread 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 svenb...@airmail.cc 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

2015-06-02 Thread 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 a...@cypherspace.org 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 stephencalebmo...@gmail.com 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 m...@friedenbach.org
 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 m...@friedenbach.org
  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

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

2015-06-01 Thread 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

2015-05-27 Thread Mark Friedenbach
On Wed, May 27, 2015 at 3:11 AM, Mike Hearn m...@plan99.net 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

2015-05-26 Thread 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%

2015-05-26 Thread Mark Friedenbach
Please let's at least have some civility and decorum on this list.

On Tue, May 26, 2015 at 1:30 PM, joli...@airmail.cc 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


 --
 ___
 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

2015-05-10 Thread 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 thom...@electrum.org 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 x0).


 --
 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

2015-05-10 Thread 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 ogun...@phauna.org 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

2015-05-08 Thread 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 burning

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread 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 . rayst...@hotmail.com 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 vois...@gmail.com 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] Proposed alternatives to the 20MB step function

2015-05-08 Thread Mark Friedenbach
On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine vois...@gmail.com 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

2015-05-08 Thread 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 vois...@gmail.com 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 m...@friedenbach.org
 wrote:

 On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine vois...@gmail.com 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

2015-05-08 Thread 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 rayst...@hotmail.com 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] 75%/95% threshold for transaction versions

2015-04-16 Thread Mark Friedenbach
At this moment anyone can alter the txid. Assume transactions are 100%
malleable.
On Apr 16, 2015 9:13 AM, s7r s...@sky-ip.org 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 s...@sky-ip.org 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_15utm_medium=emailutm_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_15utm_medium=emailutm_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

2015-02-21 Thread 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 jti...@jtimon.cc 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 ho...@hozed.org 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-idUSKBN0LK1QV20150216
 
 
 --
  Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
  from 

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

2014-08-11 Thread 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 ctpa...@gmail.com 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

2014-08-09 Thread Mark Friedenbach
On Sat, Aug 9, 2014 at 6:10 AM, Sergio Lerner sergioler...@certimix.com
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

2014-08-06 Thread Mark Friedenbach
On 08/06/2014 11:42 AM, Peter Todd wrote:
 On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
 decker.christ...@gmail.com 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=153845071iu=/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

2014-08-06 Thread 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=153845071iu=/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

2014-08-06 Thread 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=153845071iu=/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

2014-07-17 Thread 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:

2014-06-19 Thread 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 http://nimbleCoin.org, 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 to the block interval time, e.g.
 20%. This seems not to be a problem since if 

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

2014-06-19 Thread 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] Fidelity bonds for decentralized instant confirmation guarantees

2014-06-17 Thread 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] Future Feature Proposal - getgist

2014-06-05 Thread 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 mailto:ric...@geneticmistakes.com
 www: http://GeneticMistakes.com 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] PSA: Please sign your git commits

2014-05-23 Thread 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 jgar...@bitpay.com 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] Bug with handing of OP_RETURN?

2014-05-03 Thread 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] Bug with handing of OP_RETURN?

2014-05-03 Thread 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 m...@monetize.io 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] About Compact SPV proofs via block header commitments

2014-04-28 Thread 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

2014-04-27 Thread 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] Proposal for extra nonce in block header

2014-04-27 Thread 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.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-04-27 Thread 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] BIP - Selector Script

2014-04-26 Thread 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 l...@dashjr.org
 mailto:l...@dashjr.org 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
 mailto: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] Proof-of-Stake branch?

2014-04-26 Thread 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] Proof-of-Stake branch?

2014-04-26 Thread 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 m...@monetize.io 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 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
 

--
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

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

2014-04-26 Thread 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 shows a different block, then we should
 carefully detect which of the two 

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

2014-04-22 Thread 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

2014-04-21 Thread 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

2014-04-20 Thread 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 jonathan.le...@sant.ox.ac.uk
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
  Date: Sun, 20 Apr 2014 20:43:24 +0200
  From: Oliver Egginger bitc...@olivere.de
  Subject: Re: 

Re: [Bitcoin-development] Timed testing

2014-04-17 Thread 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?)

2014-04-16 Thread 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 kevinsisco61...@gmail.com 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] Warning message when running wallet in Windows XP (or drop support?)

2014-04-16 Thread 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?)

2014-04-16 Thread 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 m...@monetize.io 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?)

2014-04-16 Thread 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] Chain pruning

2014-04-10 Thread 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] Chain pruning

2014-04-10 Thread 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
 https://bitcointalk.org/index.php?topic=194078.0.
 
 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] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread 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] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread 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 sl...@centrum.cz
 mailto:sl...@centrum.cz 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 gmaxw...@gmail.com
 mailto:gmaxw...@gmail.com wrote:
 
 On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier
 justusranv...@gmail.com 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
 mailto:Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 
 
 
 
 

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

2014-04-07 Thread 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 jti...@monetize.io
 mailto:jti...@monetize.io wrote:
 
 On 4/7/14, Flavien Charlon flavien.char...@coinprism.com
 mailto:flavien.char...@coinprism.com 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] Why are we bleeding nodes?

2014-04-07 Thread 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 justusranv...@gmail.com 
 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] Why are we bleeding nodes?

2014-04-07 Thread 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?

2014-04-07 Thread 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?

2014-04-07 Thread 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] Tree-chains preliminary summary

2014-03-25 Thread 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

2014-03-24 Thread 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

2014-03-23 Thread 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] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

2014-03-22 Thread 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 data 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


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

2014-03-22 Thread 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


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

2014-03-17 Thread Mark Friedenbach
, 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

2014-03-13 Thread 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 etothe...@gmail.com 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.
 
 vendor hat: on  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

2014-03-01 Thread Mark Friedenbach
Only if you view bitcoin as no more than a payment network.
On Mar 1, 2014 10:24 AM, Jeff Garzik jgar...@bitpay.com wrote:

 This is wandering far off-topic for this mailing list.

 On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org 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=aboutlisturlcode=12view=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=126839071iu=/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/


 --
 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 

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

2014-02-28 Thread 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 ho...@hozed.org 
 mailto:ho...@hozed.org 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=126839071iu=/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.

[Bitcoin-development] Base-32 error correction coding

2014-02-20 Thread 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 division operation, 

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

2014-02-12 Thread 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=124407151iu=/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

2014-01-20 Thread 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=119420431iu=/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=119420431iu=/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

2014-01-20 Thread 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=119420431iu=/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

2014-01-18 Thread Mark Friedenbach
On 01/18/2014 03:05 AM, Wladimir wrote:
 On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla
 
 ABISprotocol hat: on
 
 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=119420431iu=/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

2014-01-17 Thread 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=119420431iu=/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

2014-01-17 Thread 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:
 vendor hat: on  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=119420431iu=/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

2014-01-15 Thread 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=119420431iu=/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

2014-01-07 Thread 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=84349831iu=/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

2014-01-06 Thread 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=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bitcoin-qt

2013-12-20 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

JSON-RPC is a huge security risk. It's perfectly reasonable that
enabling it requires some technical mumbo-jumbo.

Are there specific configuration settings that you would like to see
exposed by the GUI?


On 12/19/2013 11:49 PM, Chris Evans wrote:
 maybe make it so bitcoin.conf settings can be edited with in the
 app instead of external editor,  and make it easier to enable rpc
 server mode...
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSs/e3AAoJEAdzVfsmodw4mEkP/3XdrWMoly5t2ALN/YAj1QCv
nviQfzcv7vQKEO1ZnLMmyo1npIMRf5UqZCD6kfWS7g4vtEHjP2KNQXdwcNkDPbdL
7BjHGHghoGfjPosTz2HV8I79g+6o+f9KCYxUz56dRVs1eNjF/QAMKbHY5M2QD7UZ
3BVxdEGD2UkIN89dUSq+Ljrt+ugPlOYFiehrLhOSqYTLtoG2von7JQR8q6HRKmzC
hWSuT20aV66VL03ps5Dt/c8NVr0p0nNYRVY1vPzkcjN+1UpMBUvgn8E2d5XrchD+
uqTeWCMv2bhmFTr0qaVQwBY5Et5q6/OBJbWcF02qFq0/hy/SuZPIp/5fZEOuSpns
/QJRGRyMLtCpRH4iNxlhcZeiQs8MoV02AHYiSN/9Z9yZDEBZkpbKO9Ce6S0GwmEX
iXeloVaIil5dqtr8P9aWXW12jgohGy84oFGwK0Bxrk+HfT04OCSU0lqjRQVFzfdl
/K0jqgRdrXZz2wQYOO6+GjQvb8CP/7WfRxivKqcKdQT9CrsW+DvgaAkTy3tBJcel
aGrPynsNnDdatXK0Nyhirn/gSvxSW/Z2x2CIaPCq+jw4HrnmJu+j5AXcD8yKo8+c
FsTap1/TXeFPcDP6B7eUT+nV+hR6qXYLOuHpFwbTvt/8SJ0jAgj9Yhyq8PmL4rok
mdrqhFHk3i/RMYqGK59Q
=WCub
-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=84349831iu=/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

2013-12-20 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Jeremy, Let's give a preview of the application-oriented BIPs I
mentioned:

Stateless validation and mining involves prefixing transaction and
block messages with proofs of their UTxO state changes. These are the
operational proofs I describe in the draft, and they work on prefix
trees whose root hashes committed to the coinbase in a soft-fork
upgrade of the validation rules.

Ultimate blockchain compression involves consensus over an address
index, which can be queried over the p2p network by lightweight nodes.
The structure of the index is an authenticated prefix tree, and the
results of such a query is an an inclusion proof.

Document time-stamping and this new method of merged mining use the
same structure: a prefix tree whose root hash value is committed to a
pruneable output of the coinbase transaction. Document timestamp
proofs and merged mining proof-of-works are inclusion proofs over this
tree.

I hope that shows how the BIP directly affects interoperability of the
bitcoin protocol and clients which use these applications. I released
this BIP first to get some feedback on the structure itself, which
will be used by all of the application-specific BIPs which follow.


Stepping back and speaking generically, the purpose of a BIP as I see
it is to standardize details which affect interoperability between
clients. In fact, at a cursory glance only about half of the BIPs deal
with protocol issues directly - the rest deal with local /
user-interface issues like key derivation or JSON-RPC APIs. Even if
none of the applications involved protocol changes, I still think BIPs
like this would be of value in that they serve to standardize things
which are or will seek to become commonly used and widely implemented.

Cheers,
Mark

On 12/19/2013 10:48 PM, Jeremy Spilman wrote:
 Wow there's a lot here to think about. I'm pretty sure I haven't
 grasped the full implications yet.
 
 I see it proposes to also introduce additional BIPs describing the
 use of the data stucture for stateless validation  mining, the UBC
 address index for SPV+ operating modes, document timestamping and
 merged mining.
 
 Can the BIP stand alone as a BIP without some specific changes to
 the protocol or end-user accessible features defined within it? It
 seems like an extremely useful data stucture, but as I understand
 it the purpose of BIPS is defining interoperability points, not
 implementation details?
 
 Unless the tree itself is becoming part of the protocol, seems like
 its spec, test vectors, and reference implementation can live
 elsewhere, but I would love to read about BIPS which use this tree
 to accomplish some amazing scalability or security benefits.
 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJStChCAAoJEAdzVfsmodw42DcQAIlgkukh5K/XYloIiT5pgaHS
xCZXtOvxpNUep8x35rvEO1ePjvPvUkbUE2jRw2se1rSMkhzw3PpHHtXV/gIOGqUe
WVKeeIM5pZX56sEcEdUQ1pTwB2rmtSNeyCuHl8fLatk8eLhcAHcpv/7esLuAjWCr
EE840s8+q3ltuzKi3nqxK84bwIohgSMKhncfonNp5lMAtug8Itqopq3DPDoxwiK/
qUwSz5UCEMH6oNHnywzhKGUhBErqo4q8IgAKcZYBZZ9n4BRjf4ngoCw9n5wCef8v
tyTvwrg0nSQTQa67cg7RCsY7SisrI9gaMvCYTSvEMKdw9X0aqAX1p0yZpTbV+dIr
Q2ZT6gJmg2sD22zKY1/58oq+PiNO+nRS81OG2znZofsIfhOVW0bIZAQ8+zZtFW40
vXxMuHCNieCK8e7f9A6LLv/Zz7rmNxdQ6cHBEL1nIs1Y4d1FpHJVI2LHi54QmVXf
C5PKF/e7K2eD3LZMNxS818rZaiJJ7qmpjS3rkG2owHyJHEhBJIlkYXfI1YCraT+b
R5AzAh2Oz0Nyb5ChP2VSaecJNjGvRMo7Z6HCytmgAGOEcDDZkxSv0kkprbvchqXx
XziFgA4iSajBKYWPiPLGMADfMPT6zd4fhDjyaN8+LPO3d3ZK1VwmQDLRQ3DxfeIP
RgchHR/pS77XI7hCFwtN
=ao17
-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=84349831iu=/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

2013-12-20 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

(Sorry Peter, this was meant for the whole list:)

On 12/20/2013 05:17 AM, Peter Todd wrote:
 I've thought about this for awhile and come to the conclusion that 
 UTXO commitments are a really bad idea. I myself wanted to see them
 implemented about a year ago for fidelity bonded banks, but I've
 changed my mind and I hope you do too.
 
 They force miners and every full node with SPV clients to store the
 entire UTXO set in perpetuity.

This is incorrect. If the slower proof-updatable hashes are used, then
mining only requires what I've called operational proofs to be
attached to received transactions and blocks.

Access to the UTXO set is required to make new transactions, at least
for the outputs of the transaction, but I do not believe this is as
significant a problem as you do. It is a service that can be
outsourced for a minimal fee - include an explicit output of the
necessary amount to a scriptPubKey specified by the archival node, and
they will make sure the proper proofs are attached.

 This is bad by itself, but then they make it even worse by making 
 Bitcoin really useful and convenient to use as a decentralized 
 database; UTXO commitments make it easy and convenient to
 implement systems like Namecoin on top of Bitcoin, yet we don't
 have the UTXO expiration that might make such uses reasonable.
 Right now the UTXO set is reasonable small - ~300MB - but that can
 and will change if we make it an attractive way to store data.
 UTXO commitments do exactly that.

You might have to explain this to me, but it is not clear to me how
the validation index could be twisted into providing a Namecoin-like
system. Or the address index either, which I presume is what you are
referring to. Namecoin works by assigning domains to outputs, and then
tracking ownership and configuration of that domain through chains of
outputs. But the UTXO set doesn't contain connecting information. At
best all it would be is a glorified, and expensive time-stamper,
unattractive because there are already better solutions.

 You're also *not* giving users what they actually want: the 
 transactions associated with their wallets. Even though Electrum 
 could easily work via a pure UTXO database they implemented 
 transaction lookup instead; Electrum servers cough up every 
 transaction associated with a user's wallet. If you're going to do 
 that, it's just as easy to do per-block lookup trees which don't 
 force the UTXO set to be stored.

At the cost of having the supposedly lightweight client query for each
of its coins on every single block, to construct a negative
proof-of-spend.

 There's also a more subtle issue: the security model of UTXO 
 commitments sucks. It encourages wallets to essentially trust 
 single confirmations because it's unlikely that nodes will want to 
 store the multiple copies of the UTXO set required to provide
 proof of multiple confirmations. Basically the issue is when you
 start your wallet you get a proof of UTXO set for the most recent
 block; that's just one confirmation. To get more confirmations you
 have to wait for subsequent blocks, checking the set on each block.
 Per block indexes on the other hand naturally lead wallets to
 count confirmations properly.

I don't think this is true, or at least you are not considering
available optimizations. You certainly don't need to store multiple
copies of the UTXO set.

I'm a little confused as to the exact situation you are describing.
When a key is loaded into a wallet, or a wallet comes online after a
significant absence, it looks for coins in the current UTXO set. If
any coins are found, their attached transaction record has a block
height field, so the confirmation count can be derived from that. As
blocks go by that count is naturally increased. I'm not sure how this
is different from the current situation.

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

iQIcBAEBAgAGBQJStI9aAAoJEAdzVfsmodw4IooP/1uK9cvP1vxXyQRbAHf9oFXw
AmZ8p1+t8f6MHUpjkv/Xn0poFNU8qSnNz65drQdq8ErcJnqe4V3Wt6G32/uCxvZs
6AX6bRYQIfhHY0DBPgfacO5/ALdlnS4NdjWFCA5hHDgLd30BpbU1WK1ze985TXrd
+ucQkzcMYEDW2lb+sFvfhpi9ZPFd34ZrNzH//oS794eYKWAmj7jXqdgxk5AKat61
Xileq5beE4xom3pChXc3PtIJKsoil5SjE20/FW52wcCdyaEFG0kwl937pEGjQnlP
mylK/ilfZ6cvRC8MmVnl/6AC4V2hjB4Ncej03jG3JI2FdaJEOHuHg0uh8/Zl1I4A
YVIKyrHQhQb/VGsfXtW3zokHzDeEtJwlx+PPFaLc9QurFirNjSnenhbw4Vpbg3Xt
dH1Qd9xWcT85a19Oz8Q4rt3z7UmX9J/geZrUHCuPtr47yXU0e1Cc6ZP9zDYNtfKU
q6MjNZiaLJ/Wp0n4IeQ/4/wqy0rM/psP9i5d6IdP96tayVM9aKj5Lh9lU/Od5wGO
2PPB4kvhJfMbx3o+S7UK5vra7ysZzULpoVGDpUR3xRM72l//vlNhSLK5nILVO3r8
sIC5+3WoZLUKvuNo45/BDxXHZajrWLCU84WrwHVm1u7SHfBQcoES/rhcx2zlgyx0
/Iwxsgb7Fznl+eM2bEpZ
=TtaV
-END PGP SIGNATURE-

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations 

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

2013-12-20 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/20/2013 11:48 AM, Gregory Maxwell wrote:
 A couple very early comments— I shared some of these with you on
 IRC but I thought I'd post them to make them more likely to not get
 lost.

I got the inputs from IRC, but thank you for posting to the list so
that others can see and review.

 Whats a VARCHAR()  A zero terminated string?  A length prefixed 
 string? How is the length encoded?  Hopefully not in a way that
 has redundancy, since things that don't survive a serialization
 round trip is a major trap.

A length-prefixed string, using the shortest representation VARINT for
the length. Same as how scripts are serialized in transactions.

 Is the 'middle' the best place for the extradata? Have you 
 contemplated the possibility that some applications might use
 midstate compression?

Yes I considered midstate compression which is why the branch hashes
come last, but extra was an oversight. In every application I've
considered it's either not used (and therefore a single byte), or
updated whenever the node or its children updates.

Honestly I don't expect midestate compression to offer much since in
the nodes that are updated frequently it is unlikely that there will
be enough static data at the front to fill even a 512 bit block of the
smaller hash function.

But it doesn't hurt to prepare just in case. I'll move it to the end.

 On that general subject, since the structure here pretty much
 always guarantees two compression function invocations. SHA512/256
 might actually be faster in this application.

Yes, this is a great suggestion. Moving to SHA-512/256 will let most
inner nodes fit inside a single block, so long as the extra field is
not too long. Also apparently SHA-512 is faster on 64-bit CPUs, which
is a nice advantage. I didn't know that.

I'm concerned about speed but I did not go with a faster hash function
because users are more likely to have hardware acceleration for the
SHA-2 family.

 Re: using sha256 instead of sha256^2, we need to think carefully
 about the implications of Merkle-Damgard generic length extension
 attacks. It would be unfortunately to introduce them here, even
 though they're currently mostly theoretical for sha256.

The serialization format encodes lengths in such a way that you cannot
extend the data structure merely by appending bits. You would have to
change the prior, already hashed bits as well. I believe this makes it
immune to length extension attacks.

 WRT hash function performance, hash functions are so ludicrously
 fast (and will be more so as processors get SHA2 instructions) that
 the performance of the raw compression function would hardly ever
 be a performance consideration unless you're using a slow
 interpreted language (... and that sounds like a personal problem
 to me). So I don't think CPU performance should be a major
 consideration in this BIP.

Well.. the UTXO tree is big. Let's assume 5,000 transactions per
block, with an average of 3 inputs/outputs per transaction. This is
close to the worst-case scenario with the current block size. That's
15,000 insert, update, or delete operations.

The number of hashes required when level-compression is used is log2
the number of items in the tree, which for bitcoin is currently about
2.5 million transactions. So that's about ~21 hashes per input/ouput,
or 315,000 hash operations. A CPU is able to do about 100,000 hashes
per second per core, that'll probably take about a second on a modern
4- or 8-core machine.

For updatable proofs, the number of hash operations is equal to the
number of bits in the key, which for the validation index is always
256. That means 3.84 million hashes, or about 10 seconds on a 4-core
machine.

The numbers for the wallet index are worse, as it scales with the
number of outputs, which is necessarily larger, and the keys are longer.

This is not an insignificant cost in the near term, although it is the
type of operation that could be easily offloaded to a GPU or FPGA.

 What I do think should be a consideration is the cost of
 validating the structure under a zero-knowledge proof. An example
 application is a blind proof for a SIN or a proof of how much coin
 you control... or even a proof that a block was a correctly
 validated one, and in these cases additional compression function
 calls are indeed pretty expensive. But they're not the only cost,
 any conditional logic in the hash tree evaluation is expensive, and
 particular, I think that any place where data from children will be
 combined with a variable offset (especially if its not word
 aligned) would potentially be rather expensive.

This is something I know less about, and I welcome constructive input.
There is *no* reason that the hash serialization needs to have fancy
space-saving features. You could even make the SIG_HASH node
serialization into fixed-size, word-aligned data structures.

But this is absolutely not my field, and I may need some hand-holding.
Do 

[Bitcoin-development] BIP proposal: Authenticated prefix trees

2013-12-19 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello fellow bitcoin developers. Included below is the first draft of
a BIP for a new Merkle-compressed data structure. The need for this
data structure arose out of the misnamed Ultimate blockchain
compression project, but it has since been recognized to have many
other applications.

In addition to this BIP I am preparing three additional BIPs
describing the use of this data structure in stateless validation 
mining, the UBC address index for SPV+ operating modes, document
timestamping and merged mining.

A Python implementation of this data structure is available here:

https://github.com/monetizeio/python-bitcoin

A C++ implementation is being worked on.

As per the BIP-1 procedure, I am submitting this rough draft to the
community for discussion. I welcome all comments and criticisms of
both form and content.

- -Mark


==Abstract==

This BIP describes a [http://en.wikipedia.org/wiki/Hash_tree Merkle
hash tree] variant of the [http://en.wikipedia.org/wiki/Trie
prefix-tree data structure], ideally suited for encoding key-value
indices which support memory-efficient proofs.

==Motivation==

There are a number of applications which would benefit from having a
data structure with the following properties:

* '''Arbitrary mapping of keys to values.''' A ''key'' can be any
bytestring, and its ''value'' any other bytestring.
* '''Duplicate keys disallowed.''' Every key has one, and only one
value associated with it. Some applications demand assurance that no
key value is reused, and that this constraint can be checked without
requiring access to the entire data structure.
* '''Efficient look-up by key.''' The data structure should support
sub-linear lookup operations with respect to the number of keys in the
mapping. Logarithmic time or linear with respect to the length of the
key should be achievable and would be sufficient for realistic
applications.
* '''Merkle compression of mapping structure.''' It should be possible
to produce a reduced description of the tree consisting of a single
root hash value which is deterministically calculated from the mapping
structure.
* '''Efficient proofs of inclusion.''' It should be possible to
extract a proof of key/value mapping which is limited in size and
verification time by the length of the key in the worst case.
* '''Computation of updates using local information.''' Given a set of
inclusion proofs, it should be possible to calculate adjustments to
the local mapping structure (update or deletion of included mappings,
or insertion between two included mappings which are adjacent in the
global structure).

Such applications include committed validation indices which enable
stateless mining nodes, committed wallet indices which enable
trust-less querying of the unspent transaction output set by
codescriptPubKey/code, efficient document time-stamping, and
secure  efficient merged mining. This BIP describes an authenticated
prefix tree which has the above properties, but leaves the myriad
applications to be formalized in future BIPs.

==Data structure==

This BIP defines a binary prefix tree. Such a structure provides a
mapping of bitstrings (the ''keys'') to bytestrings (the ''values'').
It is an acyclic binary tree which implicitly encodes keys within the
traversal path -- a left branch is a 0, and a right branch is a 1.
Each node is reachable by only one unique path, and reading off the
branches taken (0 for each left, 1 for each right) as one follows the
path from root to target yields the node's key.

The particular binary prefix tree defined by this BIP is a hybrid
PATRICIA / de la Brandais tree structure.
[http://en.wikipedia.org/wiki/Radix_tree PATRICIA trees] compress a
long sequence of non-branching nodes into a single interior node with
a per-branch ''skip prefix''. This achieves significant savings in
storage space, root hash calculation, and traversal time.

A de la Brandais trie achieves compression by only storing branches
actually taken in a node. The space savings are minimal for a binary
tree, but place the serialized size of a non-branching interior node
under the SHA-256 block size, thereby reducing the number of hash
operations required to perform updates and validate proofs.

This BIP describes the authenticated prefix tree and its many
variations in terms of its serialized representation. Additional BIPs
describe the application of authenticated prefix trees to such
applications as committed indices, document time-stamping, and merged
mining.

==Serialization format==

As a hierarchical structure, the serialization of an entire tree is
the serialization of its root node. A serialized node is the
concatenation of five structures:

node := flags || VARCHAR(extra) || value || left || right

The codeflags/code is a single byte field whose composite values
determine the bytes that follow.

flags = (left_flags   0) |
(right_flags  2) |
(has_value4) |

Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains

2013-12-17 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Transactions != blocks. There is no need for a merge block.

You are free to trade transactions off-line, so long as you are
certain the other parties are not secretly double-spending coins they
send you on the block chain.

When connection to the bitcoin network is re-established, you simply
transmit the transactions and in the regular course of things they
make their way into one of the next blocks.

Any transactions which derive from the double-spent one are invalid.
But that's your problem, not the miners - chase after Bob and get him
to give you the money he owes.

On 12/17/2013 02:41 PM, Troy Benjegerdes wrote:
 I want to get some feedback.. I've used distributed version control
  systems for a long time, and the most useful feature is to be
 able to merge two different forks.
 
 So what's the equivalent of this for Bitcoin or other
 crypto-currencies?
 
 Let's suppose that me and my friends get 'islanded' from the rest
 of the internet for a week, but we still want to trade bitcoin. It
 would work if there are local miners, until we reconnect.
 
 Suppose we have the main chain (Alice), while bob is on a boat,
 trading with some friends, but has no network connectivity.
 
 When bob reconnects with Alice, a 'Merge' transaction happens where
 a miner looks at bob's forked blockchain, sees no double-spends,
 and includes BOTH chains.
 
 Now suppose someone on bob's boat has a buggy client, or sent a 
 transaction before disconnect that results in a double-spend on the
  merge.
 
 So we have a merge conflict, which generally requires human
 interaction, so bob and his friends broadcast a MERGE request with
 a transaction fee sufficient to cover reconciling the
 double-spends, AND incentivize a miner to do some extra work to
 merge.
 
 Thoughts everyone?
 
 -- Troy
 
 --

 
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=84349831iu=/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/

iQIcBAEBAgAGBQJSsNTOAAoJEAdzVfsmodw4rBUP/jBFvPks4h0k1GQEPQPYvqNa
3OhuSlC9EfHmjXxftj6j0lH6JO60BFIoA3P76oFycQRqzNSw3YoldQ1MttpNAAZg
ftiJJjYcuVmDYYWxfWPZN7ZsHrrhGkMn+i0PB1vXU3PB3sStb18vhbIoTZmwH7Rk
vaUaX8EKFh6R8Y+6nqFMKu8eALaFQPJFP1aNo31ixsFFJrl02zQeIZiTbrOensEj
6AhXm2oYRqB1aolMmy/m5zcA3IicayJ6seoCQcRhPty6G2l+/4opgATdEBjzgczW
Yhw20YkayyvPa+Fsqwad5AzgGYbm7OA0U6mO/pfeNhglNSt/TGfuSPe1oM9hWt9/
8gP3PG4O4Fxi+gOAlNABgmoRKvQK8T3TX+eoayxPJiLxi+5l3+1CK0FK1+mKPThr
heFrc5e9QlUIgATOpLYSs/elgAFM6N2Sez+RNiOg201M10VVKqXzBgZRQ+IYRRk6
jbaBKxsQ/ql5+2vwaUkplg/6Y6rfvRItQ+8xwXEvxazPAAh3Mp0fPbqas+F0e1Ie
SwVTq517iV7eu+kMxOJEqaCky8ihbaUmshjeEccXdbodpygxCR2dZ0xAkvwXYtnK
+ZjLQ7o8ySZs89Jvdx8H2fsu6m3hS/7Mm+zJVGV/hLHLoL7IrYPzTHcOHv8eT106
IYM30Hv+vDrt+f8ZRZ80
=09Pt
-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=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-13 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/13/2013 09:26 AM, Mike Hearn wrote:
 I'm thinking about a use case I hope will become common next year
 - pastebin style hosting sites for payment requests. Like, if I as
 a regular end user wish to use the payment protocol, I could just
 upload a (possibly signed) payment request to:
 
 payr.com/a62gahZ http://payr.com/a62gahZ
 
 or whatever, and then payr.com http://payr.com can take care of 
 incrementing the iteration count on each download of my file.
 That's why it's useful for it to be unsigned.

Or alternatively, the user-signed payment request without iteration
count is enclosed within a payr.com-signed envelope that contains the
iteration count. Having fields completely unsigned by anybody leaves
me a little nervous.

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/

iQIcBAEBAgAGBQJSq12pAAoJEAdzVfsmodw4MC4QAI9cjmQXz8AVawwr1htFc6b+
DVAAs1Y4hzbChPeeJCmy13m8a/BuXqc6G0WEWGSzIIa1or3IXCd01JQ2a5waD0IC
uOjlIMD0tTT7yxwxRjxPc2df82s82traGJC2caOMYjrN4T5VPtj7erB2poNyvOF+
p0lmj+duxUZ8IoyDaih5mgNKzIVujfX7o3lPoOMDdIi6Q1LF9SZ9XbUAxHCpCLfw
ieqVIm8zqtH0NprZ7/JLbqstl1iq5jCPKbORc+9qQWESZH1hFAeS29/ptjnRR8y6
HqrpDP236vSlrLDW4dLcW9UiQP42tSTwrLCgud08VqeKapSlMX8fjukLyNlTD7h5
GtPHEo1/j+LmpMfwsXA2OotUIVQBeFfEoi7PwV/Jd+SRVqC6zCTPky1lfg0P7JXA
7qD9m3u/Ey0+nk888zzff8N7AfBe7GaqFuUByXIyHh6dkcr0xUHBU4afiadFpNhg
8dTvmP4yqY0g05uz/Cq/ZqrSb5y/yPqsysuruAjWG2GT0M8rFM9oYepVHpUJr01K
QOHY6qSoqyX/KDCkZgpTMZFDq9gvyPyMFuCQbdecNcCeMPV5kiwPyqqH4rHliJ8I
gsXW44re5GfdL90nCOTboYFf2CFEn+66zyJ5vBskKSyDRDcU3t5YyCtrDzXdtJMu
MjVeMFRluY700zLBajw0
=+MjP
-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=84349831iu=/4140/ostg.clktrk
___
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

2013-11-15 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/15/13 4:41 PM, Drak wrote:
 For years, people had a problem with  email address, instead
 using email number but they got there eventually. Most people
 nowadays use email address So payment address or bitcoin
 address make better sense here when qualified as a foo address
 and not just an address
 
 You could also call it payment id, but I dont think invoice id
 since no-one pays to an invoice id that's just a reference for a
 payment, not the destination.
 
 People are very familiar with Paypal these days, and are familiar
 with paypal address or their paypal id so again I think valid
 contenders are bitcoin address or bitcoin id.

No, no no. That's precisely the problem! Bitcoin pubkey-hashes are not
like email address, physical address, or paypal address. These latter
things are fixed pieces of information that stay constant over time.
Bitcoin keys, on the other hand, must be one-use-only. We want to
break this association, not strengthen it.


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShsDqAAoJEAdzVfsmodw4e+UQAJBk3N7y/1ph8k6K/tPn2RB4
t0TiI46j0WuUghnCiDSOhQiL0EnUWUX8tCa6jH/3ASafBLKVey2LA7LeYoFZXpqJ
QEk5S7+eroA6uzzhViDTcoJJ7yH+ivd6dioVApirfnHVYiq6TZuTULhN/5zM6g1J
WehI9Rg2C7wj+I71yPJDeGAdtyOeX0iKQy3hN+q7+RIgeZC1viwsq81u6dzVjIZM
aPIk6S2VYHSUKhd7wSg+AprCV7jwftKhxDrW6R6KmOGYIG+JdqVnaErc5Wm7ujXk
Jnoh6UsQrcx9ck8I4sRTcbb5jGme1taN8RDcKifYqzTVQAr/ziVRqYY57fNAJMm2
lJZ0ctVD1+UB96DzQB4wCuWRoFF5+I9kD2hoEAXA4O9tqcou48lTQ25DAnkcusd+
dD0SfcRsgda8XqnWffGPYaW0E0dQuvu6elO+rzSh4DSCMkroKIvUwdak8Ah5M2lC
DyE/efwO9csImbTc1QukedkPskbOqPOo36sH5GdmObKKFCpORIzIO0aDQE1NM2Ib
rJurpU0iJ8eA+QT9lpyWG+jjahYpqyVhPcpfVsIewKhI0izBa352IYPbpCv/pdfM
oMO/tBfIwUW3jjav3zyFE47hAwistqfV4xds93K9rqpOmLtDIhSuzfmbuXwmciCM
d7/3rYQ6FxtyNkEUa27L
=5MWw
-END PGP SIGNATURE-

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
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

2013-11-15 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/15/13 5:19 PM, Drak wrote:
 Maybe, but again from the user's perspective they pay someone, and
 they receive money - just like you do with paypal using an email
 address. The technical bits in the middle dont matter to the user
 and trying to crap stuff in to be technically correct is just
 confusing to them.
 
 The UI needs to be about the user and fit with his experience of
 the world.

It's not about being technically correct. It is about protecting the
user from grave breaches of privacy. It is for their own benefit that
they should not be reusing addresses, and if they understood why they
wouldn't.

Unfortunately calling it a bitcoin address and including an address
book in the reference client has had the effect of making people
think that these objects are like paypal address, or email addresses,
but they are not and they should not be treated the same.

Mark

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShsr4AAoJEAdzVfsmodw46nIP/AlDcJh2ET9qYT2ZvddciTk3
dtQDArCkwCW3kYbVjIFT8YtNFftEfkq/qBNnILipLJNN49QduAIlt3aetEE6eJBZ
oqYOV2R7GW2yhLDv/GrT6GnB1C9nQ4OuKC6RNpXX4bMpZSrbP9yfyyLqecF1tMBV
i8De4XLz1uUvZOo/jwHNeYy/BAZktwdk5hWlgG2yKebRbqVX1Xv70Qb1cPpBgCWm
uRDL3bqdZuh6i8NNDQpBqMJ/MP4ZWpIgdHkfO6a3QCq3H0JXyug4t5lkNngCrAI3
KGlSOuYK4Fsfw97xQUBFIaSYFOU+yPDRQK4UGcTqWPLt5YHzUxBFNkOXSnVReudq
Em/wlbDkPqm7R6by54fVkG85snJrwmTbD7uxGz2fe1LyzB3HhdOTZyZ1KiyDHqGA
zDUFxmH0XNhvVcJvcSFlc38A54oOHTJmfJ3rxJU/q0/5N3ZIBdF8fQ4xIvXXDeeA
dO+tul5q78tbO6xyTrbsHO8JRYt4Un8Hjc5mkdqp9gzA8beJFm5+jMZlGBfdl5jR
lS9sW7QBxr6m+n2PJ97i+1CgoxTfzOh3jyj93G6Hqx3reTfCu5fSWUhwRnFzJXav
qqPBP4Cl+6ocK7+4V1lyfAzMqpYx+GCJ1JZhD0hhwrGglgVPfE0bz7BUGea8U3+T
0pCTlkhWzEbzDp7NtFdY
=ShxL
-END PGP SIGNATURE-

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
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

2013-11-14 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

For this reason I'm in favor of skipping mBTC and moving straight to
uBTC. Having eight, or even five decimal places is not intuitive to
the average user. Two decimal places is becoming standard for new
national currencies, and we wouldn't be too far from human scale
everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't think very
many people on this list would consider bitcoin overvalued in the long
term perspective.

Better to go through a confusing renumbering only once.

Mark

On 11/14/13 12:01 PM, Alan Reiner wrote:
 ... I'm also of the opinion that it's freakin' hard to change the
 base unit in such an established system.  There is no easy way to
 do this that doesn't cause more heartache than it's worth...
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShT2JAAoJEAdzVfsmodw4DXAQAIJTNbpwBGTXuFyaxXQULf20
hMs7OlQZSOZOdsmSiPv2augxzbpa2DhhZjiosrScSBCjxMeYd4S6WgTt/b8moAYR
HD8pm88JyCKDOd7bOmzTkgDOTBBFfH+islmOY9VTdeKGHeOHH6yyLMKwnUpa+S89
4YtdzlIXAtfT37dpR5E4cHPmAYCbrRsNOB6j5ohVl2VqRou2vkwoJr/YvaW54M8i
ucIZyai2qjNWyJLcZC9QWi9Yw/W/n9QYE2mHyL0qWNaIrZVn6WGty8KpYq+i7aeU
4N4UdtLT7FAhWYec9nmEec868WsUsd+H3/WSWViMinUKO4YA3cyxWDL7MTmTRsci
g0R4WGYCzMM3cEWz5ycf5KEBPH/nDlbqFmEartTffqKXgrK5Ohhw+28Iqw5KcDX8
SVx34lw2yHWmTeIMY8d3qYKqBdcsvixDUD3xvq+ZqEIa+bZw12s4LIzqmir84TB8
fB4bdq5GddXX0PK4pboXL+Nib0OVK72YgYnVs/ejlBmeiG8Ixoz4/ygR5MHm8jcw
tSiwH0xohOJWg3lJj0vZorubXoECcOqwPzsZkwnT9irbrvOuk2jCPvrkEC8U9fgA
XHgirStS49/lI/iUWrRchoTt5iuwG18G4+E81V/DMsrSkYlipuf2DlEXiapn3hWz
ccP053+6o5Rgpc7J1aa0
=QW1i
-END PGP SIGNATURE-

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
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

2013-11-14 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/14/13 2:00 PM, Alan Reiner wrote:
 Just keep in mind it will be a little awkward that 54.3 uBTC is
 the smallest unit that can be transferred [easily] and the standard
 fees are 500 uBTC.It's not a deal breaker, it's just something
 that needs to be taken into consideration when it comes to user
 perception (which is one of the reasons we would make such a change
 in the first place).
 
 Holy crap these fees are huge!  I thought Bitcoin didn't have
 fees!

Well.. they are huge. 20 cents suggested fee for a irrevocable
transaction?
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShU0EAAoJEAdzVfsmodw4TlAP/33KPX3ypMZ0PyHQVg3OCX21
hUXhTQBBO3JjO7x4HoNqdV0fApfCldq4cl/pNENG74inVuYNH+dUwUBIF6q6Qzfs
RU45++yytPob28ZojgrQgZq7/lAvi9qvsg5tLMyLt72uf3Kz1whmiRAHI5qaJ/xW
5w9LfOxXHFVkTQsUPzIjbD2kYAqUNILMzndKSv4YwRruYNm60gxCh2mQvgNr3s1Z
oGdLsPhx6AA1+Y6tgvnZVm71dwYUyg7OAafzGtpGEz953/cQwbgTqsZ3CrOiPk67
OJ9XxRPREOyKTDYo1WcM1GlQAq9LOHkMcU5OWS7TX2DzZAbLc7TqmqSMuAHdn6d5
eh+AgRWN1ppgVzHaCfgGSfP4NdXHRuMbDvSSoeiP+JLZ1ateT1aesklOaPRFfieW
NUJ61XAFWYCuVEK/ctUhSKMd19Rao23yuly+PtrMHvCw6Zn/LrpA4z2nD4vTFTXi
WeFyYwjIDjKBeuQMfWg5I2uMpo+9vC/DA3cwPticV7+LD7wsATHVNWVzuHlmjgTX
CPO4tVkqBPk7NsqDreOaVhvgnbAUHknyeDqguYS2LppDGu4P4XiOIHpS3reRyHuc
/NbXAvDkR23JGQFeHgdR/E983TdsqUiH3US43Cy3ikEcWm79eNG0cPGuHHVZBjPh
AACKjmPS+JR7rBAKFSGl
=f9P7
-END PGP SIGNATURE-

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
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

2013-11-14 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/14/13 3:01 PM, Luke-Jr wrote:
 I think we all know the problems with the term address. People
 naturally compare it to postal addresses, email addresses, etc,
 which operate fundamentally different. I suggest that we switch to
 using invoice id to refer to what is now known as addresses, as
 that seems to get the more natural understanding to people. On the
 other hand, with the advent of the payment protocol, perhaps
 address/invoice id use will die out soon?
 
 Thoughts?

key id (thanks sipa).

I know it's a more technical term, but that is rather the point. It
was a fundamental error to call hashed-pubkeys addresses as people
either associate this with account or physical addresses, which also
rarely change.

Security and privacy guarantees of the system are defeated when key
pairs are reused. We should ideally adopt terminology that lead people
to associations of ephemeral, temporary use. key id is at least
neutral in this regard. Can anyone think of something better?

Mark

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJShVieAAoJEAdzVfsmodw4TlkP/i2cZm9NolReIsv6WBNQUGZ6
0VJveOcsOmEXj3ixSyzPRitFl52EOfU+LZaM3liwFPczuIOXZUXOLAJqakxGGsFa
cWwvZjrBk13aTR+4dXZ6OWcCNmTfm6+st2+v1MpQcXlHD8J1WtrdrzKr3fNSntir
yHbNmF6hPfgLr64m52BhUVrxBg9eiIFDI6VCzmUgk+paNmIxs9dgx7POnz1/hQb3
2FGfNt2J81t4F78mpzjtKx+vHRyHpIKJ2+3mjzcQ7IBkhBgPYnp69TwBSGXbg7l9
6yV0P7DGjWepO5+s96GCjbScYpmZO0gx0ZTn/eamfxh20XuX2fZBEVNd1KnhX4Xq
D4UwylGNa5FteRgURtVN5Xdb82jB2qhhr/IkGSgKds24zhHzgvBgvLJBgwtQHwil
M/y2DMC70WVEXf0Fz96L1kNYUA6062/ZNlwITRWxkUUJprF+xyN3R+BVWMggBMnR
Vjht74MZMkJyYlPQr8BRbYdhgMwv6dh0v5T4M6ck6MjKYj/GLsnEfHyY2d/BNg8c
2nkcBC8Dtv9KoFOk6STS1n7R4ooqepmdsRNPBZUzKvv/NN1B1A8jeluLiN9hSzl1
ubDF/34LJTji8bP9jfDBEND94xdaKjTl+2ISweRttBOOVqCtQlzCQ4udiT7vAntb
AYYMBYmYO/A926T+K6Lp
=kFj9
-END PGP SIGNATURE-

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Committing to extra block data/a better merge-mine standard

2013-11-04 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/4/13 10:16 AM, Peter Todd wrote:
 Again, the right way to do this is define the standard to use the
 last txout so that midstate compression can be applied in the
 future. We can re-use this for merge-mining and other commitments
 easily by defining a simple standard based on defined path
 directions. Essentially for each thing you might want to commit,
 perhaps a merge-mined coin, a p2pool share, a UTXO commitment,
 whatever, generate a random 128-bit UUID.
 
 Now interpret the bits of that UUID as an allowed path: 0 = left, 1
 = right, from the top of the tree. When you build the tree, make
 sure everything that is going to be committed to uses it's allowed
 path; the tree will look a bit jagged. If everyone picks their
 per-purpose UUIDs randomly the paths won't collide for very many
 levels on average, and path lengths will remain short. Validating
 that some given data was committed properly is simple and easy:
 just check the path, and check that the directions from the top of
 the tree followed the spec.

You mean... an authenticated prefix tree? Composable/commutative
properties are not needed as far as I can see, so you could make the
path validation, traversal, and proof size smaller by using level
compression.

I had previously proposed to this list a hash256-to-UUID mechanism
explicitly for this purpose. Recap: use 122 of the low 128 bits of the
aux-chain's genesis block to form a version=4 (random) or version=6
(previously unused) UUID. However since making that proposal I am now
leaning towards simply using the hash of the genesis block directly to
identify aux chains since level compression will allow longer keys
with the same path length.

I'm in the middle of writing BIPs to this end, among my many other
tasks. But basically it's the same as you describe (OP_RETURN
32-byte auth tree root for the last output), except keys don't
necessarily have to be UUIDs.

If there is general interest, I can make finishing this a higher priority.

Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSd/FmAAoJEAdzVfsmodw4pA0QALtgKLKsMNFocUanKGNp5T1F
918IjFt/HASRMs4GXiPpIeTB+o5Id6aCsg1ikKRuL9xD+WKoSyo83JP5UmcxGjFA
WTPi/0/ArYRh8L7ECvWoBSanNrun3z72p3KMI1Aa8qcJCgWbPx88AYeJv0Ki4JOo
1Pxc883772bOJnazrh4f/C4gcrqrlgs29PwI1rc3yCD9dmJhVmkz+O0/yfq+U8Gg
FXrpqR14mUM36wGX2HjqEual7Ry/7TEz5Ne4o8uncaVHtGgaYVw45a5Hk6rdo1rH
F3EV9nIpsLhGyqbKPqSxSju2h3eYQxQXKUP14mJS+ja/mKFXVc3PXDV+IHtXAplk
4gW8vtTWtVIDJAGTTh5RkJu5yAr57vq9lUMTNGGk6v1C3xOPP2C097sHRLaD4kD+
olsw5M9NW/Qpn1X3SCN3K85f7dvV3+fucmWL8mPM9KMLfc38fgs7I5SQgurMngsS
2D5jSwcZVjI/4n6ocgK3Y66yKC5xuzOOi2ZV+pPM38TjUeCF8fbjRnoIWyaBPDWy
mKA0bJiw5NMzi+IsNK5YDS5Gqb3qxS6tYLCp1+hesW3pBj35Zv/LdSh5DyecRETW
J0ye56lw/DfRAfNf+YERvrznqC2WVDZcQaElACq8R/nPJ2HD53p+SfxMSbljVO+I
SDsDOSvAzfQjQBLGdkx7
=5fPS
-END PGP SIGNATURE-

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Committing to extra block data/a better merge-mine standard

2013-11-04 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/4/13 11:38 AM, Mike Hearn wrote:
 The Merkle branch doesn't get stored indefinitely though, whereas
 the coinbase hash does. The data stored in the coinbase [output]
 can always just be the 256-bit root hash truncated to less.
 
 I doubt the additional bytes make much difference really, so the 
 additional complexity may not be worth it. But it wouldn't be an
 issue to do.

The bits make a difference if you are merged mining. You can use the
birthday attack to construct two data trees whose hash match the
(truncated) value, each containing separate aux block headers. This
allows you to double-count the bitcoin PoW for more than one aux block
on the same chain, potentially facilitating aux chain attacks.

If you want 128 bits of security for merged mined aux chains, you need
256 bits of hash in the coinbase.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSd/shAAoJEAdzVfsmodw48a0P/RaCOctBDvhU0THnsUw6nRBm
A8oH3Kpio4ZltU4oIT0tznZbUOG2j2xVrmATqXDYOZQ6FuGihjmkKJ9jHgl57pb5
0qDdCBiEuWtLIh2+Awrb3Y0s8czyCQP9/1CJyzdEFmI8rSwCaqJMa6B2Ny6Xz6+8
eiK45YdXCPgdTAb56FKOi9WzOe0g1aOO5KiUOci22xRkXvh4qPYrt2F0LIgjZTdC
koyXU6dcKON9H8Cecu+ag7jJ5A9ZDj7oIq5rflEyolh2V4ie0tGQ50rFGg/ii6iQ
Tz9AWwigsHEkuinBTuN5041Xb8nAgHLvA60RQ41lWUHJxfAvDE+wN6NqgHmMVaRo
NHqlZcCuEl1jn7HW81XQTpgarrXHk1G7b2vK10pB/lUxUNIstZvCSjcp8QdtmC9v
tIhC2czSnsQaE6kIBuHxDNZxOlZ8DxBYCAgXSkycwznwzGhFPP0xB1lV9HfaP5+i
aikmx5SQmqBXQQKsxmIacoykrfu5x+O2TB/bq8JhJ1ak2jG9LVFyQqjorABVAgA7
pLEN6EomWht5qstaLVfHYpNsLMf6WA7UzRG08HKItUeDPtG7bDx8vBx5TvIUjT44
A0i09bOt8ZIgp+lJ8lFLWiPLChViAoy7fqKy2vrdsZerOF3l4LUQeQO/xnfZc+dG
AEG+7iCBOMxJSVoJ5bP6
=nydG
-END PGP SIGNATURE-

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Message Signing based authentication

2013-11-02 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Or SIGHASH of a transaction spending those coins or updating the SIN...

On 11/2/13 2:14 PM, Johnathan Corgan wrote: On 11/01/2013 10:01 PM,
bitcoingr...@gmx.com wrote:
 
 Server provides a token for the client to sign.
 
 Anyone else concerned about signing an arbitrary string?  Could be
 a hash of $EVIL_DOCUMENT, no?  I'd want to XOR the string with my
 own randomly generated nonce, sign that, then pass the nonce and
 the signature back to the server for verification.
 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSdXPaAAoJEAdzVfsmodw4+m8P/1Ce/PwZOYfiFuFJ8pmT2tb2
ro7tw7zSr12RSTvs+qRl7lDzJzQ6BDXOdXZCkcU0Vj3TDm8fdrrXN/iw3iQYU/5Y
3K7hj2mGqQUMovCLw0CbrMWrMvor7FhO6MZsRwe0+VxDV/dDrX5f5vSEhnkR26be
NrzOFU4hqGM3R4eLq8Bmw5rVD/VCrRzKoXXAvJb1EwM1+fQPjKi+bNMJu3reyfXU
5eMbbiM6tUMmPXy9M6vZrN+6ad53x3KUVP6+/hXxsrnfPp57WQzRZlvwTo/qdJ1C
Oxl71m6o2zkXbLTFmg1xmK/A4V1BPTLD6nLDIsw+wTBBfdn22pfDv6Q8d3VRctrd
6x+PMkwysoMjhemmkXCY/7G9GD6AGsrYSqIShSULd9QO5WxAFzRO01ewiRUCUFHi
Dn0LEjy8/R/CWK3jvj9uL3vQh9DLdOtqf/X7cEtjF3LThVP+stFTsmXObhTh/8Ai
YYjpnwOFG5ZtDzRZfP3OCwyhqlsaMlNgN4xnyR4GPaoJRP3a0zllblIbTWzg6nhY
jbON5Ec9N9txGhagYOoAvcQYqGyJdffkBzW82CRUsFYuYYmW2oLUQXPhAGDBIzzj
g/7RjMlM1OEp3qctxMZQlrTj7VJmhD768PRLh2XvEDmEC5Qb8Tcq28Nq5t85/O/6
i3+pzT5rMuiIZWLx7Msv
=tAUY
-END PGP SIGNATURE-

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Feedback requested: reject p2p message

2013-10-30 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

If I understand the code correctly, it's not about rejecting blocks.
It's about noticing that 50% of recent blocks are declaring a version
number that is meaningless to you. Chances are, there's been a soft
fork and you should upgrade.

On 10/30/13 1:24 AM, Mike Hearn wrote:
 
 But if you are getting soft-forked recent versions of the
 reference implementation WILL alert you; see this code in
 main.cpp:
 
 
 Perhaps I'm confused about how we're using the term soft fork. My 
 understanding is that this is where a new upgrade is designed to
 look valid to old nodes, and if you don't upgrade you rely on the
 miner majority to get you back on track. For instance, P2SH was
 done this way - old nodes that didn't upgrade during that
 transition believed all spends of P2SH outputs were valid, even
 those spending someone elses coins.
 
 In this case, the code you cite won't do anything because your
 client will never reject a block during a soft-forking upgrade,
 even if it does something that's supposed to be invalid or
 nonsensical.
 
 If a new block version changes the serialization format or script 
 language or SIGHASH rules such that old clients reject the block,
 then they will end up on a hard fork and the alerting code will
 trigger, which is correct and as it should be.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJScMvBAAoJEAdzVfsmodw4I5sQAL0Wq4e7b6/KX2zl9RmtFl5S
qM9ZJkJV8qzirj1hMgVwvnuOj147Vb3EkJujxeMa8ujepXKZ215mMCLnCHPzWPpJ
jTtOBn1FCkCUbyt9uSbZ+56NR+ElmSOsDpAJ8IR9VywHriCxm4OIAMCLTR6CKRfr
6NWySvjEMlsSHyr7DFaJTlMqo+KIUWGmP7tdPu1L2AvNE+613dI5q76IjUHYoxhu
2dDtanYUvFCsdLZEnjTr1N45BBf1mTSlPfmA1ZWHgM779h6VIyb0TeO+iCaxpvWp
2RpSDj3+diFdMUK2uu69ZcwkREH0/RoQLOys6U5DfaGkpPtjY0YXB5DwN9quKgzX
padWzbQ0flpwWLYOPYrWATz4sWflxZJu6wHAcUkRS5k9crOLVjritXs1205x7YET
0H9jtbqXmBRXidCP2BOZPdq0PGDF8g2VeEHR69JRe3F3dBfSvbgHfKoiF1jpLLqb
rttoP+nD4ZRX8FesV2E/DEZgDZJMd8eqDKNDjq7Db4BTDg24Nq2ATNE2fBtenXwI
nXVNdmnvjDxjF0weJGlYgaQTfgVwHRxs+j4qgY4VLM0qEYplhHgg+KmOMFUtxAF/
sZv6w56XtCZS3LdNONAJSZzXIcqgmcodiWKVxkTL29dsWKikcBL5cG9ipdfmjQKT
eccFOHArsbW3eSfKP/Mb
=FSQI
-END PGP SIGNATURE-

--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Making fee estimation better

2013-10-25 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

There's no reason the signing can't be done all at once. The wallet
app would create and sign three transactions, paying avg-std.D, avg,
and avg+std.D fee. It just waits to broadcast the latter two until it
has to.

On 10/25/13 5:02 AM, Andreas Petersson wrote:
 
 
 Worth thinking about the whole ecosystem of wallets involved;
 they all have to handle double-spends gracefully to make tx
 replacement of any kind user friendly. We should try to give
 people a heads up that this is coming soon if that's your
 thinking.
 
 If there is a situation where wallets are supposed to constantly
 monitor the tx propagation and recreate their transactions with
 different fees, this would make a lot of usecases inconvenient. 
 half-offline bluetooth transactions, users with unstable
 connections, battery power lost, etc, etc. - and last but not least
 power concerns on hardware wallets on the bitcoincard (tx signing
 drains a significant amount of power and should therefore only be
 done once)
 
 -Andreas
 
 --

 
October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application
 performance. Explore tips for MPI, OpenMP, advanced profiling, and
 more. Get the most from the latest Intel processors and
 coprocessors. See abstracts and register  
 http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/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/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSanJVAAoJEAdzVfsmodw4RHYQAKBrku4S80GXtbt4wBgkRMgx
EQuobBrwtknxHOhKyYuBeAJ+h8ao1zSSNeqLvS5fJShH7vwBD2UOePLw4Nsy5p9U
pe56c07pRmgi+EWdq/3o1tggp9HN0FR3HDRwt03U4qrPTx449kHb11aOw5KZH7VS
ZiG09gKxkMPOtUy9dmVukjkG3zQ1AWjax+aOoseCnkU8u1I4kfhOyWLIjD7ciMm4
07gD8MzBLHTfJ6/pwUczQCby76Xdg51G/5d/toT3EnXyEOC7tCbI4xunAn1eIyg3
eCUNYaOQ7WYV9tjBUDGFwjVkGDJ8KdzEUqMPEK5nAWF29vmrwBSGJ4H2C47OkTQA
58Ie0hEYc5FMNuUCUWz3IGt2zoQ/8YENtNUDKG8oVoNhAIp5zkLK8wsMAJjZP6WM
z56JUl8NZ2Ka5U1OelImGGVZIx4NXrXlccyxemAn3/c+krkpNv0CHAeMCeNbPG8i
e4l2vQandiBW4NBGVYcm5A/EO6VJHAJhLEPT0pjmbuq4qTACo4Fgeb0LpOnWb/1a
6b1SdGGhMMrXeR2IaIbnx0+0WArixsOPl9w+R9WbrMh8g7hYBLH8EpGrRj0omim7
OoJb+W599HU37XZyWtuov+8Ouh5DpnP9l4hvNxHmro77uPPq10i/ibMd0Bnm4zZd
ALtIYpYYgUCN1D9lQwPQ
=BjIH
-END PGP SIGNATURE-

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Faster databases than LevelDB

2013-09-17 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Also somewhat related, I have been looking for some time now to
abstract out the UTXO and block databases so that a variety of
key/value stores could be used as a backend, configured by a command
line parameter. In particular, it would be interesting for some server
applications to support HyperDex, which is basically a distributed,
fault-tolerant version of LevelDB:

http://hyperdex.org/

By the same mechanism you could just as easily support a Sophia backend.

Mark


On 9/17/13 4:00 AM, Mike Hearn wrote:
 LevelDB is fast - very fast if you give it enough CPU time and
 disk seeks. But it's not the last word in performance.
 
 HyperLevelDB is a forked LevelDB with some changes, mostly, finer 
 grained locking and changes to how compaction works:
 
 http://hyperdex.org/performance/leveldb/
 
 However, it comes with a caveat - one of the changes they made is
 to take away write throttling if compaction falls behind, the app
 itself is expected to do that.
 
 Sophia is a competitor to LevelDB. The website claims that in
 benchmarks it completely smokes LevelDB. I have not explored how it
 does this or tried to replicate their benchmarks myself:
 
 http://sphia.org/index.html http://sphia.org/benchmarks.html
 
 It's written in C and BSD licensed.
 
 As an example of the kind of speedup they claim to be capable of,
 they say LevelDB could do 167,476 random reads per second on their
 SSD based machine. Sophia could do 438,084 reads/sec. Random reads
 are of course the most interesting for us because that's what UTXO
 lookups involve.
 
 They also compare against HyperLevelDB, where the differences are
 much less pronounced and actually HyperLevelDB appears to be able
 to do random writes faster than Sophia.
 
 
 
 
 --

 
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
 1,500+ hours of tutorials including VisualStudio 2012, Windows 8,
 SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New
 Multi-Library Power Pack includes Mobile, Cloud, Java, and UX
 Design. Lowest price ever! Ends 9/20/13. 
 http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/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/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSOIymAAoJEAdzVfsmodw4H48QALC+ae4wRLEg3lrg9sgayfOn
ukLM079PXgEbARFPt6WxkLnNGYzEbb7IzT0uvaKH4VIW/rrORy9VqNPmliF+834h
XygUwfAzU04K/oLyCsdWZcOugj2P8aufNeA6whLS5IijDLtHb3Ueu4ORNcfLBGqp
KKfqPj0QHseusiLJ9f3IW+LrdM1vAoT1jryTngpQy2i+qFFDM6CN3THCq4adJvjr
AnYlfLoJSZ0/obz/krwLv6vP1BbwxXzv5CfD0Q2bdoEV/EgWDP3Bd5tUzUCjj53/
qMmhaACoVlarohh64s3JNSDSkHDFSbHFt65ZgNQbNY1wmSeyilQcd8FGWOF/WRzW
Z/pl2IdhoCm3t86xSggRGivj/EVeBJlD36i7ohpDbVWFPsf6B4e5M6xSdso/2WBp
fr55TwehCaGE+UHa0gITkE/si1txvY4gti0bLNvwFDEcZ3qsXRsz4CyLlZLMBbPX
4aRNGyqv2yJ2AivkEyNOUugo1Q8RKEKZWfWWDecI53DHdebzKX1zu9GLJwlGJqGw
Qzm7Tdb7S8J/D6IIHf4Xq2LDhQ2fnPylmGSmtuVFEMxeDhmdbNqKSr3kqlWQf3T8
Oa8bm6kUQFJ+11jLEkVEGZJC4e42+faQBxR+CsqvVsTEezDCP1dE7D3QV8ry9YBc
DwXt3299Q03B5LoxpWTq
=KseH
-END PGP SIGNATURE-

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys

2013-09-10 Thread Mark Friedenbach
Getting OT...

For a while I've wanted to combine one of these mnemonic code generators
with an NLP engine to do something like output a short story as the
passphrase, even a humorous onem with the key encoded in the story
itself (remember the gist of the story and that's sufficient to
reconstruct the key).

Also, obligatory link about the failures of unsanitized word lists:

http://iam.peteashton.com/keep-calm-rape-tshirt-amazon/

It can really backfire to get one of these things wrong.
Mark

On 9/10/13 3:08 PM, Gregory Maxwell wrote:
 On Tue, Sep 10, 2013 at 2:03 PM, Matthew Mitchell
 matthewmitch...@godofgod.co.uk wrote:
 Well let's hope something like murder black people, stupid asian person 
 or whip african slave doesn't come up. :-) Maybe it would have been better 
 without the aggressive words?
 
 Ouch.
 
 This sounds like something that $20 of mechanical turk time could help
 out with a lot.  Put up the 2048 words and ask people to rate them for
 potential offensiveness and threatening. :)
 
 Nouns often make for fairly neutral words, though careful for place
 names which have had political complications. E.g. gdansk vs danzig.

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Freimarkets: a proposal for user assets, distributed exchange, and off-chain txns

2013-08-23 Thread Mark Friedenbach

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Off-and-on for the past couple years, Jorge Timón and I have been
developing an extension of the Bitcoin and (pre-OpenCoin) Ripple
distributed protocols which enable user-specified bearer instruments,
distributed peer-to-peer exchange, off-chain accounting, auctions,
derivatives and transitive transactions, and the multitude of financial
contracts having such primitives would make possible. The specification
is now reasonably complete enough that we would like to receive input
from the community. The PDF is available for viewing here:

http://freico.in/docs/freimarkets-v0.0.1.pdf

We're looking for public comments about this or related approaches. In
particular we've spent a fair chunk of time working out how to handle
coordination of private accounting servers with the public chain and
derivatives contracts, both of which are basically cryptographic
protocols expressed as bitcoin scripts. Input from any of the resident
cryptographers would be very appreciated.

Happy hacking,
Mark Friedenbach
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSF/rKAAoJEAdzVfsmodw4xVYP/jLoB6eDlgREawfbcW6kXe4s
25YnP19Hvk0NBk0Fv9G6zhAaOdHlR4dkcq2TueAqGHA+Drtp06eVkWDfqQOioGjx
LrQF6ct9AbBZNN8glo7+JY70hecbEgWeW77cSrDTFxQAWwNnq0hVwVFb6++9rY9+
6Q4jwJtqawWlMYRlFOiK1VW/MvI2WV4bypAjuOYsTnXZ8eFjyO+obZYUuMs6JUWd
XojkDeL60NB6JHVoeyx270bvbP1Of5ErLZRuhC26MA9K4S6jlgfvLCqYBHnjRMHI
KI/K7wqcpbbyldCSIcIsVtSrwBZRUgYfUFEFXvFjwzC0EwgGFwQC3pCqTWzskpo4
KS8ZMpgr7BjI+M0GSpRyh5x0aqZkptaaogCssHzoykmEwm6dyK8cdtdhtFAsGAMs
dYpftZ/NJ17tOkUd22TXpIxWPckFBOmuV/hlr0wFpj50glttMH/8NwqKtGcjO21e
ecuiJzXbjCGlFpKIG+JI5BOXvEeD5VoegsfLTwA9Egkuhh8FXyiqIPUEEV0W1DAC
0CIsX8XmWnKeRBWWa/2AHVuSQlBlut9gX1zRElaU5YSW58zsE3UeVPvSOJOh6ZKZ
eLkRjzuyDrpuJiRKXFdTS857grUhYs+E5xeVkkZWy+q3XqQ7LofcZjp3Xt8tmx4j
LSaZTewUL15MjQR0Ow8a
=xyHR
-END PGP SIGNATURE-


--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-19 Thread Mark Friedenbach

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 8/18/13 8:09 PM, John Dillon wrote:
 On the other hand, a tx with some txin proofs can be safely relayed by SPV
 nodes, an interesting concept. Do the UTXO commitment people have
keeping proof
 size small in mind?
More than a kilobyte, probably less than a few tens of kilobytes. It
depends on parameters (branching factor, script vs hash(script)) that
are tweakable with time/space and long-term/short-term tradeoffs.
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSEakMAAoJEAdzVfsmodw4B9wQAIu82nxMAyMiTpFcWW6v0fQ9
26bzOznyIhzAlFUeCXvgwtqoxjRcheLOnsFsAr0TLdLYrx00o4+MS0GepV40gEpd
Ds/itvAnW8aWdCls0qy1hljWrsp8R3IfXWchXy13kjOhTIx8JaALeHEzOCsJVxCf
nWrV7UNLRO1eXhLUnFLnZ3/HdljMZnLqLexSGXorn4I2zwg5HGNMJxIenU3vDj8s
68k4rSk/eUptG97ZmJxCysn7nt5F1cxRutsVOPxsC/4+FptMYf9YJRJDNpvttYyl
ztI2xV+ARfEvSZs0lqGAcpvKwVV4IvZDGXhUCiS6LQ99tvMid4kjIGYPwlyK6SJW
LoYVbvjbauEIPn4URW8XilMB5EEJisr5/7ZV/aDLEFcBA/is5ePuQioo/81yOWUw
k5PghJ/TBMBQhxOGCz86onCI1YwrWfhu2sz6xNIHm9lbyZQcw3N/ai77FQqxxkxp
iBbIAvhk4sQ7lPt4QHmiL4isPzaiScKVTjvzfc5hAHSmu6xQysf8VA/SwUSgAJZB
iUPYRz5URaw8a/WDlo7YA6BRV/l7RloEcWGs6br3jVYxtJSaxqDwwrUV3SdDtzBR
uiE1OVPp8ihY3OJbnZkbvy3lXXlLjwrLVwMUgprhUo793QtktZH+O0V+StcGKLGD
4rdK6Z3C8Wx9FY2fvkBy
=HZdx
-END PGP SIGNATURE-


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


  1   2   >